error-patterns

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 6:12 AM UTC
• Version: 1.9.19

Overview

This is a documentation-only error-handling skill with one risky logging example users should harden before copying.

Reasonable to install if you want reusable error-handling patterns, but do not copy the logging example as-is. Redact or allowlist fields before logging context, keep alert payloads minimal, and expect the skill to appear for broad debugging/error requests.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: modules/recovery-strategies.md:103

Finding

Unredacted Error Context Logging and Alert Forwarding

Content

View full analysis

Vulnerability Details

File Location: modules/recovery-strategies.md, lines 103–121
Vulnerability Type: Sensitive data exposure through unrestricted logging and alert forwarding
Risk Level: Medium

Vulnerable Code

python

def log_error_with_context(error: LeylineError, context: dict):
    """Log error with full context for debugging."""
    log_entry = {
        "timestamp": datetime.utcnow().isoformat(),
        "error_type": type(error).__name__,
        "category": error.category.value,
        "message": str(error),
        "recoverable": error.category in [
            ErrorCategory.TRANSIENT,
            ErrorCategory.RESOURCE
        ],
        "context": context
    }

    logger.error(json.dumps(log_entry))

    # Alert on critical errors
    if error.category == ErrorCategory.PERMANENT:
        send_alert(log_entry)

Technical Analysis

The documented error-handling pattern serializes the complete caller-supplied context object and exception message without applying field allowlisting, recursive redaction, size limits, or sensitivity classification. Error context can contain authorization headers, API tokens, cookies, prompts, request bodies, personal information, service configuration, or internal identifiers.

The resulting record is written to the configured logger. For permanent errors, the same unsanitized record is also passed to the unspecified send_alert function. Alerting integrations commonly transmit records to third-party monitoring or messaging systems, expanding the number of systems and users able to access the data.

This project contains documentation and illustrative snippets rather than an executable implementation. Therefore, the finding affects implementations that adopt this pattern. The audit does not establish a specific external destination or confirmed network exfiltration.

Attack Path

1. An attacker supplies crafted input that is retained in the operation's context or causes sensitive ...[truncated 1241 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace unrestricted context logging with an explicit allowlist of operational fields, such as request ID, service name, error category, and non-sensitive status codes.
2. Recursively redact sensitive keys, including authorization, cookie, token, api_key, password, secret, credential, prompt, payload, and request-body fields.
3. Sanitize exception messages because upstream libraries may embed URLs, headers, request fragments, or credentials in exception text.
4. Apply length and nesting limits before serialization to reduce accidental data exposure and log-forging or resource-exhaustion risks.
5. Send alerts only a minimal summary and an opaque incident identifier. Keep detailed diagnostics in a separately protected system when necessary.
6. Require encrypted transport, strict access controls, short retention periods, and audit logging for both log storage and alert destinations.
7. Add automated tests using representative secrets to verify that sensitive values never appear in generated logs or alerts.
8. Document the destination and security assumptions of send_alert and prohibit forwarding raw caller-controlled context.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Vague Triggers

Medium

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

Finding

The trigger list is broad and includes generic terms such as "errors," "debugging," and "recovery," which can cause this skill to activate in many unrelated contexts. Unintended invocation can crowd out more appropriate skills, alter agent behavior unexpectedly, and increase exposure to any risky guidance embedded in the skill or its dependencies.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The logging example serializes the full error object and arbitrary context directly to logs and forwards the same payload to alerts. In an error-handling skill, context frequently contains secrets, tokens, prompts, file paths, request payloads, or user data, so this pattern can lead to inadvertent disclosure through log storage, monitoring systems, or alert transports.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.