Back to skill

Security audit

Web Form Automation

Security checks for vulnerabilities and agentic risk

Overview

This skill can help automate web forms, but it needs Review because it can reuse login sessions and submit arbitrary forms with weak safeguards.

Install only if you are comfortable with an automation helper that can act inside logged-in web sessions and submit forms. Use it only with session files you treat like passwords, verify the target domain before restoring a session, avoid payments/account changes/legal submissions unless you explicitly intend them, and prefer adding dry-run and confirmation checks before submit.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/form-submit.js:30
Finding
Chromium Runs Without Its Security Sandbox<![CDATA[ ## Vulnerability Details **File Location**: `scripts/form-submit.js`, lines 30–33 **Vulnerability Type**: Browser sandbox bypass and weakened process isolation **Risk Level**: High ### Vulnerable Code ```javascript const browser = await chromium.launch({ headless: true, args: ['--no-sandbox', '--disable-setuid-sandbox'] }); ``` The same insecure configuration is also recommended in `SKILL.md`, lines 115–119: ```javascript const browser = await chromium.launch({ headless: true, args: ['--no-sandbox'] }); ``` ### Technical Analysis The `--no-sandbox` and `--disable-setuid-sandbox` arguments disable Chromium's operating-system-level process isolation. Chromium normally separates potentially hostile website content from the host through restricted renderer processes and sandbox boundaries. The script accepts a configurable URL and renders its content. Consequently, it may process attacker-controlled JavaScript, media, fonts, and other complex browser content while these protections are disabled. A browser exploit that would ordinarily remain confined to a renderer sandbox may have direct access to the privileges of the Chromium process. Disabling the sandbox does not independently provide root access. Successful exploitation still generally requires a suitable Chromium vulnerability. However, this configuration removes a significant defense-in-depth boundary and increases the consequences of rendering malicious content. ### Attack Path 1. An attacker supplies, modifies, or influences the configuration passed to `form-submit.js`. 2. The attacker sets `config.url` to a malicious or compromised website. 3. The script launches Chromium with both sandbox mechanisms disabled. 4. Chromium processes hostile content served by that website. 5. The hostile content exploits a compatible browser vulnerability. 6. Because browser sandbox isolation is disabled, the exploit may execute with the operating-system permissions of the account running ...[truncated 943 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `--no-sandbox` and `--disable-setuid-sandbox` from the default launch configuration: ```javascript const browser = await chromium.launch({ headless: true }); ``` 2. Update `SKILL.md` so its examples do not recommend disabling Chromium's sandbox. 3. Run the process as a dedicated, unprivileged operating-system user. 4. If a specific environment cannot support Chromium's sandbox, run the browser inside a hardened container or virtual machine with: - No privileged mode. - A read-only root filesystem where practical. - Minimal mounted directories. - Dropped Linux capabilities. - Resource limits. - Restricted outbound network access. - No host credential or socket mounts. 5. Validate configured URLs and restrict navigation to explicitly approved HTTPS origins. 6. Keep Playwright and its bundled Chromium version patched to reduce exposure to known browser vulnerabilities. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/form-submit.js:38
Finding
Session Storage Is Imported Without Verifying the Destination Origin<![CDATA[ ## Vulnerability Details **File Location**: `scripts/form-submit.js`, lines 38–65 **Vulnerability Type**: Cross-origin disclosure of authentication and application state **Risk Level**: High ### Vulnerable Code ```javascript // Load session if provided if (config.sessionFile && fs.existsSync(config.sessionFile)) { console.log('🍪 Loading session...'); const session = JSON.parse(fs.readFileSync(config.sessionFile, 'utf8')); // Set cookies if (session.cookies) { for (const cookie of session.cookies) { try { await context.addCookies([cookie]); } catch (e) {} } } // Set storage await page.goto(config.url, { waitUntil: 'domcontentloaded', timeout: 10000 }); if (session.localStorage) { await page.evaluate((data) => { for (const [k, v] of Object.entries(data)) localStorage.setItem(k, v); }, session.localStorage); } if (session.sessionStorage) { await page.evaluate((data) => { for (const [k, v] of Object.entries(data)) sessionStorage.setItem(k, v); }, session.sessionStorage); } await page.reload({ waitUntil: 'domcontentloaded' }); } else { await page.goto(config.url, { waitUntil: 'domcontentloaded', timeout: 60000 }); } ``` ### Technical Analysis Web Storage is scoped to the origin of the currently loaded page. The script navigates to the independently configurable `config.url` and then inserts every key from the supplied `localStorage` and `sessionStorage` objects into that page's origin. The script does not record or verify the origin associated with the session file. If a legitimate session export is combined with an attacker-controlled URL, sensitive values from that export are deliberately placed into storage belonging to the attacker's origin. Cookie domain restrictions provide some protection for imported cookies because Chromium validates cookie attributes. They do not protect the copied Web Storage values. The empty cookie exception handler also suppresses ...[truncated 2134 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Store an explicit, canonical origin alongside exported session data: ```json { "origin": "https://example.com", "localStorage": {}, "sessionStorage": {}, "cookies": [] } ``` 2. Parse and compare the configured destination origin before importing any session state: ```javascript const destination = new URL(config.url); if (destination.protocol !== 'https:') { throw new Error('Session restoration requires HTTPS'); } if (session.origin !== destination.origin) { throw new Error( `Session origin mismatch: expected ${session.origin}, received ${destination.origin}` ); } ``` 3. Restrict navigation to an explicit allowlist of trusted origins rather than accepting arbitrary destinations. 4. Import only an allowlist of required storage keys. Do not copy every key from a session export. 5. Treat session files as credentials: - Apply restrictive filesystem permissions. - Keep them outside shared directories. - Avoid logging their contents. - Delete temporary session exports securely when no longer required. 6. Prefer Playwright storage-state facilities with origin-specific storage records instead of a custom origin-agnostic format. 7. Do not silently discard cookie import errors. Report rejected cookies without printing their sensitive values. 8. Consider requiring explicit user confirmation whenever session state is restored into a destination not already approved by policy. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (6)

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The declared description presents a web automation skill centered on interacting with websites and submitting forms. The supplied code chunk does not perform any browser automation or website interaction at all. It only converts a local input image to an output file, apparently intended for webp compression, and reports file sizes. While image compression could be a supporting component of a larger upload workflow, this code chunk by itself does not implement the primary declared functionality and therefore materially differs from the stated purpose.

Ae1

High
Category
analysis-evasion
Content
- `form-submit.js` - Generic form submission template
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Vague Triggers

Medium
Confidence
92% confidence
Finding
The activation language is very broad and can cause the skill to trigger for many generic website tasks, including sensitive account actions, uploads, or submissions. In an automation skill that can replay sessions, upload files, and submit forms, over-broad invocation increases the chance of unintended use on high-risk workflows.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
Recommending force-click on submit buttons without caution encourages bypassing UI checks that may intentionally prevent invalid, incomplete, or unreviewed submissions. In a form automation context, this can lead to unintended data submission, bypass of user-interface safety interlocks, and actions taken before the page is actually in a valid state.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The skill instructs loading cookies and localStorage/sessionStorage into a browser context without warning that these artifacts may contain bearer tokens, authentication state, and other secrets. This is dangerous because imported session material can enable account takeover-like behavior, cross-account actions, or leakage of sensitive credentials if mishandled.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The script will unconditionally click the configured submit button with force enabled, which can trigger irreversible actions such as account changes, purchases, uploads, or data submission without any final safety check. In a web-form automation skill, this is especially relevant because the explicit purpose is to interact with arbitrary websites, so misuse or operator error can cause real-world side effects immediately.

Static analysis

No suspicious patterns detected.