T09 · Insecure Skill Coding Practices
- Location
scripts/render.mjs:190- Finding
Chromium Browser Sandbox Is Unconditionally Disabled
- Content
View full analysis
Vulnerability Details
File Location:
scripts/render.mjs, lines 190–197
Vulnerability Type: Browser sandbox disabled during processing of user-controlled input
Risk Level: Highjs const browser = await puppeteer.launch({ executablePath: chrome.includes("\\") || chrome.includes("/") ? chrome : undefined, headless: true, args: [ "--disable-gpu", "--no-sandbox", "--disable-dev-shm-usage", ],Technical Analysis
The script unconditionally launches Chrome or Edge with the
--no-sandboxargument. The Chromium sandbox is a primary defense-in-depth boundary that limits the operating-system access available to compromised renderer processes.The browser loads the bundled
assets/regulex.htmlpage and processes a user-supplied regular expression through its embedded JavaScript renderer. No malicious behavior was identified in that bundled page. However, if specially crafted input triggers a vulnerability in the browser or rendering code, disabling the sandbox substantially increases the potential consequences. Code executing through a compromised renderer would not benefit from Chromium's normal sandbox containment.The regular expression is URL-encoded before being placed in the fragment, so the reviewed code does not establish direct HTML or JavaScript injection. Exploitation would require a separate vulnerability in Chromium or the bundled rendering implementation; therefore, this finding represents unsafe hardening rather than a demonstrated direct code-execution primitive.
Attack Path
- An attacker supplies a specially crafted regular expression to the
--reargument. - The script URL-encodes the expression and includes it in the fragment of the local
assets/regulex.htmlURL. - Puppeteer launches the local browser with
--no-sandbox. - The bundled JavaScript renderer and browser process the attacker-controlled expression.
- If the input triggers an exploitable vulnerability in Chromium or the render ...[truncated 855 chars]
- An attacker supplies a specially crafted regular expression to the
- Remediation
View remediation
Remediation Suggestions
- Remove
--no-sandboxfrom the default Chromium arguments and run with the browser sandbox enabled. - If a deployment environment cannot support Chromium sandboxing, fail safely and document the required host or container configuration instead of silently weakening isolation.
- If sandbox disabling must remain available for compatibility, require an explicit opt-in command-line option with a prominent security warning.
- Run any explicitly unsandboxed browser inside an additional isolation boundary, such as a locked-down container, virtual machine, or dedicated low-privilege operating-system account.
- Restrict container permissions, mount only required files, use a read-only root filesystem where possible, disable unnecessary capabilities, and deny access to sensitive host paths and metadata services.
- Keep Chrome or Edge and the bundled renderer updated to minimize exposure to known browser and rendering vulnerabilities.
- Consider validating limits for input length, rendering scale, and timeout to reduce the attack surface for resource-exhaustion inputs.
- Remove