0DIN AI Scanner RCE
Remote code execution via JavaScript injection in BrowserAutomation::PlaywrightService — exposes Rails secrets, database credentials, and tenant data
CVE-2026-41512 is a critical remote code execution vulnerability in 0DIN AI Scanner versions 1.0.0 through 1.4.0. The scanner's PlaywrightService builds Node.js scripts as Ruby heredoc strings and interpolates user-controlled URLs without escaping. A crafted URL closes the JavaScript string literal and appends arbitrary Node.js statements that execute via Open3.capture3 — granting full access to child_process, the process environment, and the Docker network. Any authenticated tenant member — with no special privileges — can exploit this to read SECRET_KEY_BASE, PostgreSQL credentials, OAuth secrets, and every other tenant's data. Tenant isolation is completely broken.
"The new AI security stack is still software — often privileged software handling credentials, API keys, model endpoints and tenant data."
— Security Point Break, May 8, 2026
CVE Details
Remote Code Execution via JavaScript Injection in BrowserAutomation::PlaywrightService
PlaywrightService in 0DIN AI Scanner builds Node.js automation scripts as Ruby heredoc strings, directly interpolating user-controlled URLs into the generated source without sanitization or escaping. A crafted URL containing a single quote character closes the JavaScript string literal inside the generated Playwright script. Ruby's URI validation accepts the single quote as a valid sub-delimiter under RFC 3986, so the injection is not rejected at the input layer. The malicious code is appended to the Node.js file, which is then executed by Open3.capture3 — giving the attacker full Node.js child_process, fs, and process.env access within the Rails container.
ROOT CAUSE — CROSS-LANGUAGE STRING INTERPOLATION
The vulnerability is a classic cross-language injection: a Ruby application dynamically constructs JavaScript source code by interpolating untrusted user input, then executes the result as a Node.js program. Each language layer only validates what it understands — Ruby's URI parser accepts the single-quote injection character as valid, and Node.js executes whatever JavaScript it receives. The generated script is executed with Open3.capture3, which has no sandboxing and shares the Rails container's full environment, including all credentials stored in environment variables. This pattern — generating source code from user input across language boundaries — is inherently unsafe regardless of input validation at either layer.
Attack Chain
Obtain Any Authenticated Session
Any tenant member account is sufficient — no administrator or elevated role is required. Default 0DIN deployments seed an admin account with credentials [email protected] / password, making first-run exploitation on unmodified deployments trivial without any prior knowledge of the target environment.
Remove default credentials immediately after deployment. Enforce strong passwords and MFA for all scanner accounts.
Craft an Injection URL
Build a URL containing a single quote character that closes the JavaScript string literal inside the generated Playwright script. The injection appends arbitrary Node.js statements after the closed string. Ruby's URI validation accepts the single quote as a valid sub-delimiter under RFC 3986, so the malicious URL passes URI parsing and is forwarded to PlaywrightService without rejection.
Validate and sanitize URL inputs at the application layer before interpolation. Never rely solely on URI parsing for security decisions.
Submit to POST /targets/auto_detect_selectors
The POST /targets/auto_detect_selectors endpoint is reachable by any authenticated tenant member. The controller passes the attacker-supplied URL directly to BrowserAutomation::PlaywrightService, which interpolates it into a temporary Node.js file using Ruby string interpolation and immediately executes the generated file.
Restrict sensitive automation endpoints to administrator roles. Apply explicit role checks, not just authentication checks.
Collect Secrets and Establish Persistence
The injected Node.js code executes within the Rails container with full access to process.env and the Docker network. The attacker reads SECRET_KEY_BASE, POSTGRES_PASSWORD, OAuth client secrets, LLM provider API keys, and model endpoint credentials. With PostgreSQL credentials and Docker-network access, the attacker can read or modify all tenant data across the entire multi-tenant deployment. Writable application directories and /tmp can be used to write backdoors or reverse shells that survive a restart.
Rotate all secrets after patching. Treat any affected container as potentially compromised. Rebuild from a trusted image.
Impact
Application Secrets
- SECRET_KEY_BASE exposure enables session forgery
- LLM provider API keys (OpenAI, Anthropic, etc.) stolen
- OAuth client secrets and integration tokens exfiltrated
- Model endpoint credentials fully accessible via process.env
Database Access
- POSTGRES_PASSWORD exposed in container environment
- Direct PostgreSQL access over Docker network
- Full read/write capability on all application tables
- Encrypted data and PII recoverable from all tenants
Tenant Isolation Collapse
- One authenticated tenant member compromises all tenants
- Multi-tenant data boundaries completely broken
- Scan configurations, results, and red-team data cross-tenant readable
- No privilege escalation required beyond initial tenant membership
Container Persistence
- Writable application directories usable for backdoors
- /tmp accessible for staging reverse shells or malicious initializers
- Docker network access for lateral movement to adjacent services
- Persistence survives application restarts if written to app directories
Response Checklist
Upgrade all deployments to version 1.4.1 or later. This is the patched release that applies security hardening to PlaywrightService — eliminating the unsafe URL interpolation and replacing it with parameterized code generation. The patch was released April 13, 2026, three days before the advisory was published. Affected versions: 1.0.0 – 1.4.0.
Locate any 0DIN AI Scanner instance accessible over the internet, VPN, or shared internal network. Prioritize instances with self-service registration, default credentials ([email protected] / password), or broad tenant membership. The attack requires only an authenticated session — any instance accessible to untrusted users should be treated as a high-priority patching target.
Rotate all credentials that were accessible to the Rails container process: Rails SECRET_KEY_BASE, PostgreSQL database password, OAuth client secrets, LLM provider API keys (OpenAI, Anthropic, Cohere, etc.), model endpoint credentials, and all integration tokens. The advisory confirms these values are readable through process.env by code running in the exploited context.
Check application, reverse-proxy, and container logs for requests to POST /targets/auto_detect_selectors containing suspicious URL parameters — specifically those with single quotes, JavaScript fragments, or Node.js keywords. Also check for unexpected files created under /tmp or writable application directories, and for unexpected outbound network connections from the Rails container.
If exploit attempts or suspicious artifacts are present in logs or writable directories, treat the vulnerable container as potentially compromised. Rebuild from a trusted base image after patching and completing secret rotation. Do not rely on patching in place if backdoors or malicious initializers may have been written to writable application directories.
Place the scanner behind SSO with device posture checks, network allow-lists, and least-privilege role enforcement. Broad internal access — such as allowing all employees to register accounts — should not be considered a sufficient control. The vulnerability requires only an authenticated session, so access controls are the first and most important compensating control for unpatched deployments.
Run the scanner as a non-root user, mount the filesystem read-only where possible, limit writable directories to only those explicitly required, disable unnecessary Linux capabilities, restrict outbound network egress to known endpoints, and define explicit Docker or Kubernetes network policies. Container runtime hardening limits the blast radius of future application-layer vulnerabilities by preventing or detecting unexpected behavior at the infrastructure layer.
AI security scanners, red-team platforms, and vulnerability assessment tools deserve the same governance treatment as CI/CD systems, SAST platforms, and production vulnerability scanners: threat modeling, change control, dependency review, defined patch SLAs, and independent security testing. These tools are often deployed with broad credentials and network access — the same properties that make them high-value targets and high-impact breach vectors.
Governance Framework
AI Security Tools Are Privileged Software
Include AI scanning platforms in your governance program alongside CI/CD systems, SAST tools, and vulnerability scanners. They handle credentials, model endpoints, scan logs, and tenant context — often with more privileged access to your infrastructure than production application services. Applying lower security standards to security tooling because it "isn't production" is a governance gap that creates critical exposure.
Ban Cross-Language String Interpolation
Never interpolate user-controlled strings into generated source code across language boundaries. The correct approach is to pass values through structured APIs, typed command arguments, data files, or safe template engines with explicit encoding. When a Ruby application must invoke a Node.js script with user-supplied parameters, those parameters should be passed as JSON arguments to a fixed script — never embedded as literals in dynamically generated source code.
Secure-by-Default Deployment Profiles
AI red-team and security platforms should ship with secure defaults: no default credentials, disabled self-service registration, explicit roles enforced on all administrative routes, tenant boundaries tested as hard security boundaries, and generated code executed in constrained sandboxes with no access to the host environment. These properties must be the default configuration — not opt-in hardening steps documented in an appendix.
References
[1] GitHub Security Advisory
GHSA-r27j-xxgx-f5vr — CVE-2026-41512: Remote code execution via JavaScript injection in BrowserAutomation::PlaywrightService. Primary disclosure, April 16, 2026.
[2] National Vulnerability Database
CVE-2026-41512 Detail — CVSS 9.9 scoring, CWE classification, and affected version range. Published May 8, 2026.
[3] GitHub Releases
0DIN AI Scanner v1.4.1 Release Notes — Patch release applying PlaywrightService security hardening. Released April 13, 2026.
[4] Security Point Break
"Critical AI Red-Team Scanner Flaw Revives an Old Security Lesson" — Analysis of the broader governance implications of privileged AI security tooling. May 8, 2026.