Summary
Joro: Unauthenticated Cross-Origin Plugin Upload Leads to RCE
Full technical description
Unauthenticated Cross-Origin Plugin Upload Leads to RCE (Joro ≤ v1.1.0)
Severity: Critical
CVSS v3.1: 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H)
Affected versions: Joro ≤ v1.1.0, proxy mode (default), Linux/macOS
Reporter: cstover
Date: 2026-05-27
Joro's default proxy mode (in versions <= 1.1.0) exposes a local API on 127.0.0.1:9090 that performs no authentication and applies a wildcard CORS policy. Because plugin uploads use the CORS-safelisted multipart/form-data content type, cross-origin JavaScript on any page the operator visits can reach privileged endpoints - including uploading a native plugin and triggering a restart - directly through the operator's browser, with no preflight or credentials. Since plugins execute on load, this yields unauthenticated remote code execution as the operator's user from a single page visit.
Root Cause
Three weaknesses combined into the exploit chain.
1. No authentication in proxy mode.internal/api/server.go applied AuthMiddleware only when listenerMode was true. In the default proxy mode every API endpoint, including plugin upload and system restart, accepted requests without any token, cookie, or credential.
2. Permissive CORS with an insufficient protection assumption.corsMiddleware set Access-Control-Allow-Origin: * unconditionally on all responses. SECURITY.md documented this as an intentional tradeoff on the basis that proxy mode binds to 127.0.0.1, which the document states "limits exposure to the local machine."
That assumption was incorrect. multipart/form-data is a CORS-safelisted Content-Type, so cross-origin JavaScript can POST files to the Joro API without triggering a preflight request, the browser allows it. Any web page the operator visited reached the localhost API through their browser without restriction. The localhost bind provided no protection against browser-mediated requests.
3. Plugin init() executed on plugin.Open() before symbol lookup.internal/plugins/loader.go called plugin.Open(), which ran the plugin's init() functions before any symbol lookup occurred. A plugin with no exports still executed its payload the moment Joro restarted.
Attack Chain
- The operator visits an attacker-controlled page in Firefox on their machine.
- JavaScript on the page fetches
pwn.sofrom the attacker's server (same-origin, no CORS issue). - JavaScript POSTs
pwn.sotohttp://127.0.0.1:9090/api/v1/plugins/uploadasmultipart/form-data. Joro accepts it, no auth, no preflight. - JavaScript POSTs to
http://127.0.0.1:9090/api/v1/system/restart. Joro re-executes. - On restart,
plugin.Open("pwn.so")callsinit(), which opens a goroutine and dials back to the attacker's listener. - An interactive
/bin/bash -ishell is obtained as the operator's user.
The plugin ABI matches without any access to the operator's machine. The same public v1.1.0 release tarball is downloaded and Joro's own --build-plugin feature is used, which reads runtime/debug.BuildInfo from the release binary and forwards every ABI-relevant flag. One .so works against every operator running that release.
1. Removed the wildcard CORS header and gated the proxy-mode API behind a same-origin guard
corsMiddleware (which set Access-Control-Allow-Origin: * on every response) was deleted, and proxy mode now wraps the API in originGuard instead. (internal/api/server.go, commit 5c0ca35)
var handler http.Handler = mux
if s.listenerMode {
+ // Listener/teamserver: bearer-token auth.
handler = team.AuthMiddleware(s.teamToken, handler)
+} else {
+ // Proxy mode: restrict the API to same-origin browser requests.
+ handler = originGuard(uiBind, handler)
}
-handler = corsMiddleware(handler)
-// corsMiddleware adds permissive CORS headers for dev usage.
-func corsMiddleware(next http.Handler) http.Handler {
- return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
- w.Header().Set("Access-Control-Allow-Origin", "*")
- w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
- w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Joro-Nickname")
- if r.Method == http.MethodOptions {
- w.WriteHeader(http.StatusNoContent)
- return
- }
- next.ServeHTTP(w, r)
- })
-}
2. Same-origin enforcement via Sec-Fetch-Site + Origin/Host
originGuard rejects state-changing requests (and the /ws upgrade) whose Sec-Fetch-Site indicates a cross-origin initiator or whose Origin host does not match the request Host. Non-browser local tooling (no browser headers) is still allowed. (internal/api/originguard.go, commit 5c0ca35)
func isMutating(method string) bool {
switch method {
case http.MethodPost, http.MethodPut, http.MethodDelete, http.MethodPatch:
return true
default:
return false
}
}
func sameOrigin(r *http.Request) bool {
switch r.Header.Get("Sec-Fetch-Site") {
case "", "same-origin", "none":
// Same-origin, a direct navigation, or a non-browser client.
default: // "cross-site", "same-site"
return false
}
if origin := r.Header.Get("Origin"); origin != "" {
if origin == "null" {
return false // opaque/sandboxed cross-origin context
}
u, err := url.Parse(origin)
if err != nil || !strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host)) {
return false
}
}
return true
}
3. Tightened the WebSocket origin check
The WebSocket upgrader previously accepted every origin (CheckOrigin: return true). It now rejects cross-origin handshakes while still permitting non-browser clients. (internal/api/ws.go, commit 5c0ca35)
var upgrader = websocket.Upgrader{
- CheckOrigin: func(r *http.Request) bool { return true },
+ CheckOrigin: func(r *http.Request) bool {
+ origin := r.Header.Get("Origin")
+ if origin == "" {
+ return true
+ }
+ if origin == "null" {
+ return false
+ }
+ u, err := url.Parse(origin)
+ if err != nil {
+ return false
+ }
+ return strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host))
+ },
}
4. Bound the proxy-mode UI/API to loopback and removed the wildcard host exception
The same-origin check alone can be defeated by DNS rebinding under a wildcard bind, because a rebound host (e.g. attacker.com) carries consistent Origin/Host/Sec-Fetch-Site headers. Two coordinated changes close this: the proxy-mode UI/API now binds to 127.0.0.1 regardless of --bind (which governs only the proxy port), and hostAllowed no longer has a wildcard exception, so the host must be loopback or the exact bind address. (internal/api/server.go and internal/api/originguard.go, commit 871936f)
+// In proxy mode the UI/API binds to loopback only: --bind governs the proxy
+// port, and remote collaboration is listener/teamserver mode (bearer-token auth).
+uiBind := s.cfg.BindAddr
+if !s.listenerMode {
+ uiBind = "127.0.0.1"
+}
+
var handler http.Handler = mux
...
s.srv = &http.Server{
- Addr: fmt.Sprintf("%s:%d", s.cfg.BindAddr, s.cfg.UIPort),
+ Addr: fmt.Sprintf("%s:%d", uiBind, s.cfg.UIPort),
func hostAllowed(reqHost, bindAddr string) bool {
h := reqHostname(reqHost)
if h == "" {
return false
}
switch h {
case "localhost", "127.0.0.1", "::1":
return true
}
- switch bindAddr {
- case "", "0.0.0.0", "::":
- return true
- }
return strings.EqualFold(h, reqHostname(bindAddr))
}
Impact
Unauthenticated, remote, browser-mediated code execution as the operator's user. Because the exploit pivots through the operator's browser to the loopback-bound API, the network bind offers no protection, and a single ABI-matched plugin works against every operator running the affected release.
A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.
CVE-2026-53649 has a CVSS score of 9.6 (Critical). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260601151442-5c0ca35db828); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The chain is broken at multiple layers. Cross-origin browser access to the proxy-mode API is eliminated, the API is restricted to same-origin requests targeting a loopback host, and the UI/API is bound to loopback only.
Frequently Asked Questions
- What is CVE-2026-53649? CVE-2026-53649 is a critical-severity missing authentication for critical function vulnerability in github.com/BishopFox/joro (go), affecting versions < 0.0.0-20260601151442-5c0ca35db828. It is fixed in 0.0.0-20260601151442-5c0ca35db828. A critical operation is accessible without requiring any authentication.
- How severe is CVE-2026-53649? CVE-2026-53649 has a CVSS score of 9.6 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/BishopFox/joro are affected by CVE-2026-53649? github.com/BishopFox/joro (go) versions < 0.0.0-20260601151442-5c0ca35db828 is affected.
- Is there a fix for CVE-2026-53649? Yes. CVE-2026-53649 is fixed in 0.0.0-20260601151442-5c0ca35db828. Upgrade to this version or later.
- Is CVE-2026-53649 exploitable, and should I be worried? Whether CVE-2026-53649 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-53649 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-53649? Upgrade
github.com/BishopFox/joroto 0.0.0-20260601151442-5c0ca35db828 or later.