Why JWT-based IDE authentication facilitates data theft
Forensic reviews of cloud-connected IDEs show a recurring pattern: long-lived bearer tokens in local databases, replayable over HTTPS, and refresh material that outlives access tokens — a design that turns session theft into persistent account compromise.
Security researchers and incident responders have documented a growing class of breaches that begin not in production servers, but in the developer workstation. Cloud-connected IDEs that authenticate with JSON Web Tokens are a frequent pivot point: tokens are convenient for vendors, but they behave like bearer secrets — anyone who possesses them can act as the user until expiry or revocation.
Independent forensic work on compromised developer machines consistently shows the same artifacts: JWT access and refresh material stored in local state databases, sent on every API call as Authorization: Bearer over HTTPS, and logged using SHA-256 fingerprints alongside decoded non-secret metadata. That logging helps defenders correlate traffic with on-disk session state — and helps attackers map exactly what to steal.
The result is not theoretical. Expert study of OAuth and bearer-token deployments (including NIST and OWASP guidance on token handling) warns that possession equals authentication. When an IDE embeds that model inside Application Support directories, backup tools, and write-ahead logs, data theft and system bypass become practical rather than exotic.
How JWT sessions are stored and used
In typical cloud-IDE architectures, authentication relies on two JWT-shaped values persisted in a local state database (commonly ItemTable entries in a state.vscdb file). The access token — often keyed as serviceAuth/accessToken — authorizes every API request: agent streams, uploads, and remote service calls. The refresh token — stored separately as serviceAuth/refreshToken — mints new access tokens when the short-lived JWT expires.
Both values use the familiar three-part base64url JWT format. Security tooling that encounters opaque non-JWT values records them separately as format: opaque. On a healthy session, access and refresh fingerprints frequently match in baseline snapshots because the pair was minted together — yet they remain distinct keys with independent rotation schedules after login.
What forensic evidence reveals
Defenders and researchers instrument auth flows with SHA-256 fingerprints (fp, access_fp, refresh_fp) and selective JWT payload decoding — never logging full secrets. Baseline files such as service_jwt_baseline.json capture expected fingerprints at login. Later, mismatches between in-flight jwt.fp values and on-disk access_fp entries indicate session re-injection, cloning, or MITM replay.
Refresh tokens rarely appear on routine API traffic; they must be recovered from the local database, its WAL before checkpoint, filesystem backups, or vault exports. That asymmetry matters: an attacker who only intercepts HTTPS may capture access material, while an attacker with disk access often captures indefinite renewal capability.
Compromise paths and escalation
Access JWT only (MITM, memory scrape, or log leak): the attacker replays HTTPS as the victim until expiration. If they can write to Application Support, they may inject stolen access — and refresh, if obtained separately — back into ItemTable through tooling such as write_auth_to_vscdb(), materializing a persistent session that can leave WAL traces before checkpoint.
Refresh JWT exposure (database read, WAL recovery, backup, or vault breach): the attacker mints new access tokens until the vendor revokes the account. The material is already on disk; cloning the database, re-injecting on another host, or scrubbing and re-injecting through an approval path are documented escalation patterns in forensic casework.
Either token plus a trusted MITM CA: full bearer visibility on every API call. Analysts correlate in-flight jwt.fp with vscdb access_fp; refresh must still be read from cursorAuth/refreshToken or equivalent storage — but once combined, the session is fully portable.
Documented vulnerabilities
Bearer replay — CRITICAL. Any valid access JWT calls service APIs as the user until exp. A stolen refresh JWT extends that window until password reset or account-level revocation. Detection: MITM jwt.fp correlated with vscdb access_fp drift from baseline; unexpected API hosts in auth telemetry.
Refresh token longevity — HIGH. Refresh tokens typically outlive access tokens by design. Copying the local database once can enable long-term session re-injection through write_auth_to_vscdb even after access expiry. Mitigation requires vendor-side refresh rotation, local vscdb scrubbing, and vault gates that block silent re-injection.
What teams should do
Treat developer IDE state directories as sensitive key material, not cache. Include them in endpoint detection, backup encryption, and offboarding scrubbing. Monitor for fingerprint drift, new hosts in bearer traffic, and WAL activity around auth keys after suspected phishing or CA installation.
Prefer authentication models that do not reduce possession to unlimited API replay — machine-bound challenges, hardware-backed keys, and local-first workflows that minimize bearer exposure on every agent call. The forensic record is clear: JWT-in-vscdb designs have repeatedly bridged workstation compromise into cloud account compromise and source-code exfiltration.