Back to skill

Security audit

Landing Page Generator

Security checks for vulnerabilities and agentic risk

Overview

This is a small landing-page generator with a real HTML-escaping weakness, but its behavior is disclosed, local, and limited to generating static output.

Reasonable to install for trusted local page generation. Do not pass untrusted product copy into it or publish generated pages from third-party input unless the script is updated to HTML-escape values first.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Warning
Location
generate.sh:4
Finding
Unsanitized User Input Allows HTML and JavaScript Injection in Generated Pages<![CDATA[ ## Vulnerability Details **File Location**: `generate.sh`, lines 4-6 and 13-72 **Vulnerability Type**: HTML injection / stored cross-site scripting in generated output **Risk Level**: Medium ### Vulnerable Code ```bash PRODUCT="${1:?Usage: generate.sh \"Product Name\" \"Tagline\" \"Description\"}" TAGLINE="${2:?Missing tagline}" DESC="${3:?Missing description}" ``` The untrusted values are subsequently inserted into multiple HTML contexts without encoding: ```html <title>${PRODUCT}</title> ``` ```html <header class="hero"> <h1>${PRODUCT}</h1> <p>${TAGLINE}</p> <a href="#cta" class="btn btn-primary">Get Started</a> </header> <section class="features"> <h2>Why ${PRODUCT}?</h2> <div class="grid"> <div class="card"> <h3>⚡ Fast</h3> <p>${DESC}</p> </div> ``` ```html <div class="cta-banner" id="cta"> <h2>Ready to get started?</h2> <p style="margin-bottom:24px;opacity:.9">Join thousands who already use ${PRODUCT}.</p> <a href="#" class="btn btn-secondary">Sign Up Free</a> </div> <footer> <p>&copy; ${YEAR} ${PRODUCT}. All rights reserved.</p> </footer> ``` ### Technical Analysis The script treats its three command-line arguments as trusted text and interpolates them directly into an HTML heredoc. It does not encode HTML metacharacters such as `&`, `<`, `>`, `"`, and `'`. An attacker who can control any of these arguments can terminate the intended text node or element and inject arbitrary HTML. For example, a description containing: ```html </p><img src=x onerror="alert(document.domain)"><p> ``` would be emitted as executable markup rather than displayed as text. When the generated page is opened in a browser, the injected event handler executes. A script element or other active HTML content could similarly be introduced. This is an HTML-generation vulnerability rather than shell command injection. Shell syntax contained inside an already supplied argument is not re-evaluated as shell code by parameter expa ...[truncated 1477 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Encode every user-provided value for the HTML context before inserting it into the template. 1. Replace direct interpolation with a template engine or generator that performs HTML escaping automatically. 2. At minimum, encode `&`, `<`, `>`, `"`, and `'` in `PRODUCT`, `TAGLINE`, and `DESC`. 3. Apply encoding at output time and according to the destination context. The current inputs are used in HTML text and title content; future use in attributes, URLs, CSS, or JavaScript would require different context-specific encoding. 4. Validate input lengths and reject control characters or content outside the expected product-text format where appropriate. 5. Add regression tests using payloads such as `<script>`, closing tags, event-handler attributes, ampersands, and quotation marks. Tests should verify that these values appear only as visible text in the generated page. 6. Consider deploying generated pages with a restrictive Content Security Policy as defense in depth. CSP should not replace correct output encoding. A safe implementation can use an HTML-escaping helper before rendering: ```bash html_escape() { local value=$1 value=${value//&/&amp;} value=${value//</&lt;} value=${value//>/&gt;} value=${value//\"/&quot;} value=${value//\'/&#39;} printf '%s' "$value" } PRODUCT_ESCAPED=$(html_escape "$PRODUCT") TAGLINE_ESCAPED=$(html_escape "$TAGLINE") DESC_ESCAPED=$(html_escape "$DESC") ``` Only the escaped variables should then be interpolated into the HTML template. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Natural-Language Policy Violations

Low
Confidence
95% confidence
Finding
The generated document hard-codes `lang="en"`, which imposes a specific language/locale in the output. This is a natural-language policy concern because the skill does not offer a user opt-in or indicate that the output is intentionally region-specific.

Static analysis

No suspicious patterns detected.