# 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

---

## Summary

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

1. The operator visits an attacker-controlled page in Firefox on their machine.
2. JavaScript on the page fetches `pwn.so` from the attacker's server (same-origin, no CORS issue).
3. JavaScript POSTs `pwn.so` to `http://127.0.0.1:9090/api/v1/plugins/upload` as `multipart/form-data`. Joro accepts it — no auth, no preflight.
4. JavaScript POSTs to `http://127.0.0.1:9090/api/v1/system/restart`. Joro re-executes.
5. On restart, `plugin.Open("pwn.so")` calls `init()`, which opens a goroutine and dials back to the attacker's listener.
6. An interactive `/bin/bash -i` shell 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.

---

## 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.

## Fix

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.

### 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`)

```diff
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)
```

```diff
-// 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`)

```go
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`)

```diff
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`)

```diff
+// 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),
```

```diff
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))
}
```