Lerwee Alert To Fault Handling

• Outcome: Review
• Latest audit: Sep 12, 2026 · 12:39 AM UTC
• Version: 1.0.0

Overview

This skill is meant to run operational remediation scripts and close alerts, but its artifacts show weak controls around who can execute actions, what targets are allowed, and when alerts may be closed.

Install only after reviewing and tightening execution controls. Require authenticated, action-specific approvals; bind each execution to a recommended alert, host, script ID, user, and short-lived confirmation token; fail closed when group or classification is missing; verify remediation before closing alerts; and remove packaged runtime logs containing internal identifiers.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (4)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: alert_workflow.py:120

Finding

Remediation Execution Bypasses Confirmation, Authorization, and Script Allowlisting

Content

View full analysis

4 else None user = sys.argv[5] if len(sys.argv) > 5 else None print(f"🔧 Executing a script for host {ip}...") result = execute_script(ip, script_id, eventid, user) ``` ### Technical Analysis The `execute` command accepts an arbitrary host and integer script ID from command-line arguments and forwards them directly to the adjacent `fault-handling/run_script.py` component. No code in this execution path: - Requires or validates explicit user confirmation. - Authenticates or authorizes the caller. - Verifies that the script ID exists in `.scripts_map.json`. - Verifies that the target host belongs to an approved inventory. - Binds the execution to a previously generated recommendation. - Verifies that the supplied user identifier represents the actual caller. This contradicts the documented controls requiring explicit confirmation and limiting execution to predefined or explicitly approved scripts. Argument-array invocation avoids direct shell metacharacter injection, but it does not prevent unauthorized use of valid downstream script IDs. The implementation of the adjacent ...[truncated 1358 chars]

Remediation

View remediation

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: alert_workflow.py:180

Finding

Alerts Can Be Closed Without Successful Remediation or Caller Authorization

Content

View full analysis

3 else "Script execution succeeded; automatically closing alert" if close_alert(eventid, message): print(f"✅ Alert {eventid} has been closed") else: print("❌ Failed to close alert", file=sys.stderr) sys.exit(1) ``` ### Technical Analysis The `close` command forwards any supplied event ID to the alert acknowledgment API. It does not verify: - The identity or authority of the caller. - That the event belongs to a system managed by the caller. - That a remediation script was executed for the event. - That the execution completed successfully. - That the successful execution targeted the same host associated with the alert. - That explicit confirmation to close the alert was obtained. - That the event remains in a state where closure is appropriate. The default acknowledgment message asserts that script execution succeeded even though no execution record is consulted. This violates the documented requirement that alerts may only be closed after successful script execution has been confirmed. ### Attack Path 1. ...[truncated 1015 chars]

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Warning

• Location: match_script.py:49

Finding

Missing Group or Classification Values Bypass Script-Matching Restrictions

Content

View full analysis

5 else None chat_id = sys.argv[6] if len(sys.argv) > 6 else None ``` ```python alert_info = { 'eventid': sys.argv[2], 'ip': sys.argv[3], 'description': sys.argv[4], 'classification': int(sys.argv[5]) if len(sys.argv) > 5 else None, 'objectid': None } chat_id = sys.argv[6] if len(sys.argv) > 6 else None ``` ### Technical Analysis The matcher only enforces the group allowlist when `chat_id` is truthy and only enforces the classification allowlist when `classification` is truthy. Both values are optional in the command-line interfaces. Consequently, omitting either value disables the corresponding restriction. Omitting both reduces matching to keyword detection. This is a fail-open design: missing security context increases access instead of causing the request to be rejected. The issue directly affects recommendations rather than executing a script by itself. However, recommendations are presented as trusted automation guidance, and the separate execution path does not independently enforce these mappings. ### Attack Path 1. A caller submits an alert description containing a configured keyword, such as a keyword mapped to a service restart or disk-clean ...[truncated 900 chars]

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Note

• Location: .execution_log.json:3

Finding

Distributed Execution Log Exposes Internal Operational Identifiers

Content

View full analysis

Remediation

View remediation

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (14)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence

Finding

The skill claims an automated alert-handling workflow, but the documented implementation includes local persistence and history management behaviors while leaving key detection/matching logic vague or undeclared. This inconsistency makes security review harder and can hide unexpected data retention or command-surface expansion behind an incomplete functional description.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence

Finding

The skill claims an automated alert-handling workflow, but the documented implementation includes local persistence and history management behaviors while leaving key detection/matching logic vague or undeclared. This inconsistency makes security review harder and can hide unexpected data retention or command-surface expansion behind an incomplete functional description.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 92% confidence

Finding

The skill documents shell execution, file reads/writes, and external API use, but it declares no explicit tool scope or permissions boundary. That makes the operational capability broader and less auditable, increasing the chance that the agent can invoke dangerous actions or access local files beyond what users expect.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

The trigger condition treats the presence of generic alert-like fields such as eventid, IP, or alert names as sufficient context, which can overlap with normal conversation. In a skill that can recommend and then execute remediation scripts, broad matching increases the risk of accidental activation and can prime users to confirm actions on the wrong target.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

Using very common confirmation phrases like '执行' or '确认' makes it easy for normal conversational replies to be interpreted as authorization for a remediation script. Because the skill can run operational scripts on hosts, ambiguous confirmation handling materially raises the chance of unintended execution.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

The hard rules still permit generic confirmations including 'yes', which is especially dangerous in multilingual or casual chat because it can appear in unrelated replies. Since the skill is designed to bridge chat context into real shell-script execution and optional alert closure, weak confirmation semantics create a clear unintended-action risk.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

This Python file contains top-level documentation and multiple user-facing messages entirely in Chinese, indicating the skill is designed to operate in a single language by default. The policy requires flagging language or locale constraints when the skill does not explicitly offer the user a language choice or document a justified region-specific limitation.

Content

No source excerpt is available for this finding.

subprocess module call

Medium

• Category: Dangerous Code Execution
• Confidence: 70% confidence

Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · alert_workflow.py (reported line 33)May include surrounding context.

python

# 2. 通过 objectid 查询
    if 'objectid' in alert_info and alert_info['objectid']:
        try:
            result = subprocess.run(
                ['bash', LERCLEE_API_DIR / 'lerwee-api.sh', 'monitor', 'host-view',
                 json.dumps({'hostid': alert_info['objectid']})],
                capture_output=True, text=True, check=True

subprocess module call

Medium

• Category: Dangerous Code Execution
• Confidence: 70% confidence

Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · alert_workflow.py (reported line 68)May include surrounding context.

python

# 调用匹配脚本
    try:
        result = subprocess.run(
            ['python3', SCRIPT_DIR / 'match_script.py', 'match',
             alert_info.get('eventid', ''),
             ip,

subprocess module call

Medium

• Category: Dangerous Code Execution
• Confidence: 94% confidence

Finding

This function executes a fault-handling script selected by script_id against a host identified by ip, both of which can come from command-line or workflow input with no authorization, allowlist, or semantic validation at this layer. In the context of an automated incident-response skill, that creates a dangerous arbitrary-action primitive: if an attacker can influence these inputs or trigger this command path, they may cause execution of powerful remediation scripts on unintended hosts.

Content

Scanner excerpt · alert_workflow.py (reported line 128)May include surrounding context.

python

]

        # 执行脚本
        result = subprocess.run(
            cmd,
            capture_output=True,
            text=True,

subprocess module call

Medium

• Category: Dangerous Code Execution
• Confidence: 70% confidence

Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · alert_workflow.py (reported line 157)May include surrounding context.

python

log_record['execution_id'] = int(match.group(1))

        # 写入日志
        subprocess.run(
            ['python3', SCRIPT_DIR / 'log_execution.py', 'add',
             ip, str(script_id), log_record['script_name'], log_record['status'],
             str(log_record.get('execution_id', '')),

subprocess module call

Medium

• Category: Dangerous Code Execution
• Confidence: 90% confidence

Finding

This code acknowledges/closes alerts based solely on provided eventid and message data, with no verification that the alert corresponds to a successfully remediated event or that the caller is authorized to close it. In an alert-handling workflow, unauthorized or premature closure can suppress active incidents, hide attacks, and degrade monitoring integrity.

Content

Scanner excerpt · alert_workflow.py (reported line 183)May include surrounding context.

python

def close_alert(eventid, message="脚本执行成功，自动关闭告警"):
    """关闭告警"""
    try:
        result = subprocess.run(
            ['bash', LERCLEE_API_DIR / 'lerwee-api.sh', 'alert', 'problem-ack',
             json.dumps({
                 'eventid': eventid,

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The module docstring is entirely in Chinese and provides the skill's user-facing description only in that language. This imposes a specific language/locale without any indication of user opt-in or alternative language support, which matches the language-policy concern for natural-language content.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The module docstring and all CLI messages are written in Chinese, and the script provides no option for users to select another language or opt in to this locale. This is a natural-language policy concern because the skill imposes a specific language on all users regardless of preference or context.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.