guru-connect/reports/2026-05-30-gc-audit.md

GuruConnect Audit Report — 2026-05-30

Auditor: Claude (claude-opus-4-8[1m]) Passes: Security & Remote-Session Integrity (--pass=security only) Previous audit: 2026-05-29 (the audit that defined the v2 secure-session-core work) Scope note: Single-pass security re-audit to formally verify the v2 secure-session-core rebuild closed the three relay CRITICALs. Independent re-derivation against the code — not an echo of the 2026-05-30 Tasks 3–5 code review.

---

Executive Summary

Pass	Total	Critical	High	Medium	Low	Info
Security & Session	5	0	1	0	1	3

The three 2026-05-29 audit CRITICALs are CLOSED with no bypass. The relay/server plane is clean. The one serious finding is net-new and outside the relay plane — the Windows agent auto-update path disables TLS verification (MITM → RCE).

Requires action: [HIGH] Agent auto-update disables TLS cert verification → MITM-to-RCE.

---

The three audit CRITICALs — verification

CRITICAL #1 — "any JWT joins any session" → CLOSED (no bypass)

• viewer_ws_handler (server/src/relay/mod.rs:463) calls validate_viewer_token, which enforces signature + expiry + purpose=="viewer" (server/src/auth/jwt.rs:268,284). A login JWT lacks the ViewerClaims shape and is rejected (test test_login_token_rejected_as_viewer_token).
• Session binding: claim_session_id != requested_session_id → 403 (relay/mod.rs:494-501).
• Mint authz: mint_viewer_token (server/src/api/sessions.rs:114-131) — is_admin() || has_permission("control") → Control; else has_permission("view") → ViewOnly; else 403.
• View-only enforcement: access mode is in the signed claim; relay drops MouseEvent/KeyEvent/SpecialKey when !access.can_control() (relay/mod.rs:1313-1335).

CRITICAL #2 — "viewer-WS blacklist bypass" → CLOSED (no bypass), documented residual

• token_blacklist.is_revoked(&token) consulted on the viewer WS path before upgrade (relay/mod.rs:476).
• Residual [TRACKED — v2-secure-session-core plan.md, MEDIUM]: logout (server/src/api/auth_logout.rs:64) revokes only the login JWT; minted viewer tokens are not blacklisted, so a leaked viewer token stays valid until natural expiry (5-min TTL, jwt.rs:56). Known follow-up; the enforcement plumbing is correct for any future force-revoke.

CRITICAL #3 — "JWT accepted as agent key" → CLOSED (no bypass), fails closed

• validate_agent_api_key (relay/mod.rs:384) has no JWT branch — only a per-agent cak_ key (verify_agent_key, server/src/auth/agent_keys.rs:71; SHA-256 vs connect_agent_keys, revoked_at IS NULL) or the deprecated shared AGENT_API_KEY (WARNING-logged).
• Identity binding fails closed: unresolved machine → 503 (relay/mod.rs:276-286); a client-supplied agent_id is overridden by the key's machine identity (relay/mod.rs:263-270).

---

Pass 5: Security & Remote-Session Integrity

[HIGH] Agent auto-update disables TLS certificate verification → MITM-to-RCE

File: agent/src/update.rs:45 and :111 (live path: agent/src/session/mod.rs:461-468,695-702) Detail: Both the check_for_update and download_update reqwest clients are built with .danger_accept_invalid_certs(true) ("for self-signed certs in dev"). This is the live auto-update path — the agent session loop calls check_for_update → perform_update → download_update → install_update → restart_with_new_version at runtime. A network MITM (the relay endpoint is a public hostname) can serve an arbitrary guruconnect-update.exe; the agent writes it over its own binary and executes it — full code execution on every managed endpoint. verify_checksum (update.rs:294) does NOT mitigate: the expected SHA-256 (version_info.checksum_sha256) arrives in the same /api/version JSON over the unverified TLS connection, so the attacker controls both binary and checksum. Recommendation: Remove danger_accept_invalid_certs(true) from both clients (gate behind a dev-only cfg/env flag never set in release). Defense-in-depth: sign the update binary/manifest with an embedded public key and verify the signature before install_update, so update trust does not rest solely on TLS.

[LOW] Chat message content logged at INFO

File: server/src/relay/mod.rs:776 and :1373 Detail: Full chat text is logged (Chat from client/technician: {content}). Support-session chat can carry sensitive data (spoken passwords, account numbers) — PII/secret-bearing content in server logs. Recommendation: Drop content from the log line (log length or hash, or move to trace!).

[INFO] Bootstrap admin password logged on credentials-file write failure

File: server/src/main.rs:200-201 Detail: Self-documented one-time fallback at first boot if .admin-credentials write fails; password is meant to be changed immediately. Awareness only, not a defect.

[INFO] Viewer-token mint not scoped to a specific machine/session ACL — [TRACKED — SPEC-002 Phase 4]

File: server/src/api/sessions.rs:27,114 Detail: Any control-permission user can mint a control token for any live session (no per-machine / per-client ACL). Intentional for Phase 1; per-tenant narrowing deferred to Phase 4.

[INFO] Verified-sound areas

Single-use support codes (atomic consume_for_bind, support_codes.rs:240 / db/support_codes.rs:110); consent gate (viewer refused until allows_viewer(), session/mod.rs:393; deny/timeout tears down before the relay loop, no pre-consent window); frame caps (agent 4 MiB / viewer 64 KiB, relay/mod.rs:330,524); input throttle (200 ev/s token bucket + non-blocking try_send); rate limiting wired + proxy-aware (main.rs:317-370, utils/ip_extract.rs:147); JWT_SECRET length-checked ≥32 at startup; Argon2id passwords; no secret/token/code logging; parameterized runtime sqlx (no format!-built SQL); wss:// default.

---

Verdict

CRITICAL	Verdict	Enforced at
#1 any-JWT-joins-any-session	CLOSED	api/sessions.rs:114 (authz) + relay/mod.rs:463,494 (token type + session bind)
#2 viewer-WS blacklist bypass	CLOSED (TTL-bounded residual tracked)	relay/mod.rs:476
#3 JWT-accepted-as-agent-key	CLOSED	relay/mod.rs:384 (no JWT branch; fail-closed binding :276)

Net-new findings: CRITICAL 0 · HIGH 1 · MEDIUM 0 · LOW 1 · INFO 2. Overall posture: The relay/server plane is clean — all three CRITICALs genuinely closed, fail-closed session/consent/code paths, bounded abuse surface, correct proxy-aware rate limiting, no SQL injection or credential logging. The one serious net-new issue is on the Windows agent (auto-update TLS bypass → MITM-RCE), independent of the v2 secure-session-core work and in no existing spec — fix before the next agent release.

---

Recommended Action Order

1. [HIGH] Remove danger_accept_invalid_certs(true) from agent/src/update.rs (+ sign update binary).
2. [LOW] Stop logging chat content (relay/mod.rs:776,1373).
3. [TRACKED/MEDIUM] Viewer-token logout revocation (existing plan.md follow-up).

Note: only --pass=security was run. The API-surface, Rust-quality, TypeScript, protocol-integrity, docs-reconciliation, and CI/CD passes were not executed this run.