React Router V7

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 3:19 AM UTC
• Version: 1.1.1

Overview

This is a documentation-only React Router skill with one unsafe error-handling example users should correct before copying into production.

Installers can treat this as a normal documentation skill, but developers should not copy the displayed error.stack or raw error.message pattern into production UIs. Use generic user-facing errors and send detailed diagnostics to protected logs or show them only in development.

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 (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: ADVANCED.md:18
• Finding: Production Error Boundary Exposes Exception Messages and Stack Traces<![CDATA[ ## Vulnerability Details **File Location**: `ADVANCED.md:18-25` **Vulnerability Type**: Sensitive diagnostic information exposure **Risk Level**: Medium ### Vulnerable Code ```tsx } else if (error instanceof Error) { return ( <div> <h1>Error</h1> <p>{error.message}</p> <pre>{error.stack}</pre> </div> ); } ``` ### Technical Analysis The documented root error boundary renders both `error.message` and `error.stack` directly in the browser without restricting this behavior to development environments. Stack traces and raw exception messages may reveal source paths, module and component names, application structure, implementation details, dependency internals, database-related errors, or sensitive values included in exception messages. Because the section presents this as a required root error boundary without a production safety warning, users of the Skill may reproduce the unsafe pattern in deployed applications. ### Attack Path 1. An attacker identifies a route or input that causes an unhandled application exception. 2. The exception propagates to `RootErrorBoundary`. 3. The boundary recognizes the value as an `Error`. 4. The application returns `error.message` and `error.stack` in the rendered page. 5. The attacker uses the disclosed diagnostic information to map internal application components, source layout, dependencies, or vulnerable code paths. ### Impact Assessment This issue does not directly grant additional system privileges or execute attacker-controlled code. Its scope is information disclosure to any user able to trigger or observe an error boundary. Disclosed implementation details may support reconnaissance and make subsequent attacks more precise. The exact exposure depends on the contents of runtime exceptions. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace raw exception output with a generic production-safe message. - Render stack traces only behind an explicit development-environment check such as `import.meta.env.DEV`. - Send detailed diagnostics to an access-controlled server-side logging or monitoring system instead of returning them to clients. - Sanitize exception messages and ensure secrets, credentials, tokens, personal data, and database details are never embedded in user-visible errors. - Add guidance distinguishing development diagnostics from production error handling. Example hardened pattern: ```tsx } else if (error instanceof Error) { if (import.meta.env.DEV) { return ( <div> <h1>Error</h1> <p>{error.message}</p> <pre>{error.stack}</pre> </div> ); } return ( <div> <h1>Something went wrong</h1> <p>Please try again later.</p> </div> ); } ``` ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/advanced.md:38
• Finding: Duplicated Error Boundary Guidance Exposes Exception Messages and Stack Traces<![CDATA[ ## Vulnerability Details **File Location**: `references/advanced.md:38-45` **Vulnerability Type**: Sensitive diagnostic information exposure **Risk Level**: Medium ### Vulnerable Code ```tsx } else if (error instanceof Error) { return ( <div> <h1>Error</h1> <p>{error.message}</p> <pre>{error.stack}</pre> </div> ); } ``` ### Technical Analysis The reference documentation duplicates the unsafe error-boundary pattern and renders raw exception messages and stack traces to the client without a development-only condition. Applications generated from this reference may consequently expose internal diagnostic data in production. The vulnerability is based on excessive error detail rather than direct privilege escalation. The exposed data can include source paths, module names, dependency internals, and sensitive values carried in exception messages. ### Attack Path 1. An attacker sends malformed input or accesses a route that produces an unhandled exception. 2. The exception reaches the documented root error boundary. 3. The `Error` branch renders its message and complete stack trace. 4. The attacker reads the diagnostic output in the application response. 5. The disclosed information is used for application reconnaissance or to refine follow-on attacks. ### Impact Assessment No direct code execution or elevated privilege is obtained from this flaw alone. The affected scope includes production users who can trigger and view application errors. The confidentiality impact depends on the information present in exception messages and stack frames. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Update the reference example to return a generic message in production. - Permit stack-trace rendering only in explicitly detected development environments. - Record full errors through protected server-side observability tooling. - Prevent credentials, tokens, personal data, database statements, and internal paths from entering client-visible error messages. - Keep the primary and reference documentation synchronized so the corrected pattern appears in both locations. Example hardened pattern: ```tsx } else if (error instanceof Error) { if (import.meta.env.DEV) { return ( <div> <h1>Error</h1> <p>{error.message}</p> <pre>{error.stack}</pre> </div> ); } return ( <div> <h1>Something went wrong</h1> <p>Please try again later.</p> </div> ); } ``` ]]>

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: The root error boundary example renders `error.message` and especially `error.stack` directly into the UI, which can expose internal file paths, source structure, implementation details, and sensitive debugging context to end users. In a public-facing routing best-practices skill, normalizing stack-trace disclosure can lead downstream developers to ship information exposure into production.

Context-Inappropriate Capability

Medium

• Confidence: 96% confidence
• Finding: The root error boundary example renders `error.stack` directly to the UI, which can expose sensitive debugging details such as file paths, internal code structure, library versions, and implementation hints to end users. In a best-practices reference for routing, presenting stack-trace disclosure as an unqualified example is risky because developers may copy it into production applications.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The example not only exposes stack traces but does so without any warning that this is sensitive diagnostic information inappropriate for production UIs. Because this skill is documentation for React Router best practices, omission of that warning increases the chance that users will adopt insecure error handling patterns verbatim.

Static analysis

No suspicious patterns detected.