Joro Proxy Mode: Unauthenticated API + Wildcard CORS Enables Cross-Origin RCE

Vulnerability Description

This vulnerability chains three security misconfigurations in Joro's proxy mode (the default deployment):

1. Missing Authentication Layer: The internal API server (internal/api/server.go) only applies authentication middleware when running in listener mode, leaving all endpoints—including plugin upload and system restart—accessible without credentials in proxy mode.

2. Overpermissive CORS Policy: The corsMiddleware unconditionally sets Access-Control-Allow-Origin: * on all responses, contrary to the assumption documented in SECURITY.md that localhost-only binding provides sufficient isolation.

3. Plugin Auto-Execution: Uploaded plugins execute automatically on load, creating a direct pathway from upload to code execution.

The combined effect is unauthenticated remote code execution reachable from any malicious webpage the operator visits, exploiting the browser's same-origin policy enforcement (not applicable to localhost) and use of CORS-safelisted multipart/form-data to bypass preflight checks.

Proof-of-Concept Significance

This PoC demonstrates a critical trust boundary violation: the localhost API was designed with an implicit security model (local binding = safe) that is violated by wildcard CORS. The attack requires only that a victim operator visit a malicious webpage while Joro is running—no social engineering, credential compromise, or network access is required. The reliability is high: the attack exploits fundamental HTTP semantics and browser behavior. Preconditions are minimal: Joro must be running in proxy mode (default) on v1.1.0 or earlier, and the operator's browser must execute JavaScript from the attacker's domain.

Detection Guidance

Log Indicators:

• HTTP POST requests to /api/plugins/upload or /api/system/restart without Authorization headers
• Requests with Origin header not matching 127.0.0.1 or localhost
• Access-Control-Allow-Origin: * in API responses to cross-origin requests
• Unexpected plugin files appearing in the plugin directory with recent timestamps

Network Signatures:

• Outbound HTTP requests from browser processes to 127.0.0.1:9090/api/plugins/upload containing binary or obfuscated payloads
• Correlation of webpage visits with subsequent plugin installation and process behavior changes

System Monitoring:

• New executable files created in Joro's plugin directory immediately after API calls
• Process spawning or capability elevation following plugin load events
• Joro process restarts triggered by API calls without user interaction

Mitigation Steps

Immediate Actions:

1. Upgrade Joro to v1.1.1 or later (patch release addressing authentication and CORS)
2. Restrict CORS scope: If running affected versions in constrained environments, manually patch corsMiddleware to set Access-Control-Allow-Origin: http://127.0.0.1:9090 (same-origin only)
3. Enable authentication in proxy mode: Apply AuthMiddleware to all API endpoints regardless of listener mode
4. Implement network isolation: Firewall 127.0.0.1:9090 to prevent browser access; use system-level IPC or Unix sockets instead

Hardening:

• Disable plugin auto-execution; require manual approval or signed plugin verification
• Run Joro in a dedicated user account with minimal privileges
• Use Content Security Policy (CSP) headers in any web interfaces to prevent malicious script injection
• Monitor and audit plugin sources; implement plugin signing

Risk Assessment

Exploitation Likelihood: High in the wild. The attack surface is enormous—any webpage visit triggers potential exploitation. The technical barrier is low; exploitation can be automated and scaled. Threat actors with web presence (malware distribution sites, compromised legitimate sites, ad networks) would find this valuable.

Threat Actor Interest: Very high. This is a browser-to-RCE chain affecting systems administrators and developers who run proxy tools. Targeted campaigns against DevOps/security professionals are well-documented. The impact (code execution as the operator's user) enables lateral movement, data exfiltration, and supply chain attacks.

Prioritization: Organizations running Joro in proxy mode should treat this as an immediate emergency patch requiring deployment within 24–48 hours.