slabbdev

All That Glisters Is Softmax: Shiny-Object Interns, Airplane-Magazine Execs, and Why AI Labs Can Only Bake In Half the Scars --- title: "All That Glisters Is Softmax: Shiny-Object Interns, Airplane-Magazine Execs, and Why AI Labs Can Only Bake In Half the Scars" description: "Why do an eager intern with a Hacker News blog post, a C-level executive stepping off an airplane with an in-flight magazine, and a trillion-parameter LLM all walk straight into the exact same production bog? And why even Google DeepMind can only bake half of our 600 scars into model weights." tags: ai, programming, architecture, machinelearning series: Synthetic Scars --- _Why do an eager intern with a Hacker News blog post, a C-level executive stepping off an airplane with an in-flight magazine, and a trillion-parameter LLM all walk straight into the exact same production bog? Because for 3,000 years of human literature—and in every softmax attention matrix—the shiniest path is a trap._ > _"All that glisters is not gold; / Often have you heard that told."_ — William Shakespeare, _The Merchant of Venice_ (Act II, Scene VII) > _"While many say THIS leads to THAT, I'm here to say THIS should lead to THE OTHER."_ — Randal L. Schwartz _(The 12-Word Definition of a Synthetic Scar)_ --- 1. The Power Loader vs. The Passenger Seat: Why We Use Human Psychology to Debug QK^T / sqrt(d_k) Matrices Whenever a skeptic looks at an AI coding workflow, their first accusation is predictable: _"You outsourced your thinking to a stochastic parrot."_ My answer is the exact opposite: > I didn't outsource the thinking—I outsourced the typing. It's my thoughts. Always. Think of the hydraulic Power Loader exo-suit from _Aliens_—or a Pacific Rim Jaeger. When you step into a Power Loader, the machine does not decide where the cargo goes. Every micro-movement of the hydraulic arms is a 100x mechanical amplification of the human operator's nervous system, bounded by physical safety interlocks so the hydraulics cannot crush the pilot. Over 246 production tickets (142 open-source framework tickets across BlocSignal, kaisel, and our research tools + 104 commercial enterprise industrial tickets) and 600 codified Synthetic Scars (577 public at syntheticscars.org + 23 private domain invariants), our repeat regression rate on previously scarred failure modes has remained locked at 0.0% (68.3% autonomous first-pass verification, N_nudge = 1.91 mean human nudges per ticket). Yet when developers read the formal preprint on syntheticscars.org or browse the previous installments of this series, they often ask a fascinating question: _"Randal, why are you using Antonio Damasio's Somatic Marker neuroscience, John Grinder and Richard Bandler's 1975 NLP Meta-Model, Gregory Bateson's cybernetics, Fernando Flores's 1986 speech-act commitments, and Baron-Cohen's Sally-Anne Theory of Mind test to debug a matrix multiplication (softmax(QK^T / sqrt(d_k)) V) running on a Google TPU?"_ Because of The Corpus Mirror Isomorphism: 1. The Weights Are Fossilized Human Psychology: A foundation model is a compressed statistical hologram of trillions of tokens of unedited human thought, rationalizations, Stack Overflow shortcuts, and cognitive biases. When you multiply Q x K^T, you are running a linear-algebra simulation of human System 1 associative attention (Daniel Kahneman's _Thinking, Fast and Slow_). 2. Damasio's Patient "Elliot" in Silicon: In _Descartes' Error_ (1994), neuroscientist Antonio Damasio studied patients with ventromedial prefrontal and amygdala lesions who retained 100% intact IQ and logical reasoning, yet destroyed their lives because they lacked somatic markers—the visceral gut recoil (_"I have a bad feeling about this"_) that prunes catastrophic options before conscious calculation begins. An unscarred LLM is Damasio's patient at scale: encyclopedic recall of every algorithm on Earth, paired with zero amygdala. 3. Why Prose "DON'T" Rules Fail (Hypnotic Priming in Self-Attention): In _The Structure of Magic_ (1975) and _Trance-formations_ (1981), Grinder and Bandler observed that the human nervous system cannot represent a linguistic negation (_"Don't think of a pink elephant"_, _"Don't spill the milk"_) without first activating the internal sensory representation of the forbidden act. In a Transformer, placing "DO NOT use .asData?.value" or pasting a 10-line "// BAD: DON'T DO THIS" snippet into your .cursorrules loads the exact forbidden syntax tokens into the Key-Value (KV) cache, boosting their cosine similarity in the next attention head! 4. Machine Theory of Mind & The Sally-Anne False-Belief Test in transcript.jsonl: Why does a single-window agent fail to catch its own bugs when you tell it "Now review your own code"? Because in psychology's classic Sally-Anne test (Baron-Cohen, Leslie, & Frith, 1985), once _you_ know the marble was moved to the box, it takes deliberate cognitive effort to simulate an observer who only sees the closed basket. In an LLM's single context window, the Builder's private rationalizations (_"I skipped the null check because the caller probably validates it"_) sit right there in the KV cache (E_Builder). When you fork an isolated Target 40 Clean-Room Critic Subagent (Workspace: 'inherit') that sees _only_ the Git Merkle tree diff (git write-tree) and the 4-Vector Scar Registry (E_Critic orthogonal to E_Builder), you physically enforce the Sally-Anne separation. --- 2. The Four Isomorphic Hazards: The Intern, The Executive, The Cargo Cultist, and The Softmax Voter Once you realize that an unscarred LLM is a pure System 1 associative engine with zero skin in the game, you immediately understand why managing AI coding agents feels eerily familiar to every veteran engineering manager. Four personas we deal with every week in software engineering are mathematically isomorphic: flowchart TD I["1. The Shiny-Object Intern\nReads a weekend Hacker News blog post;\nrewrites core loop on Monday"] E["2. The Airplane-Magazine Executive\nReads glossy in-flight success story;\ndemands Friday migration"] C["3. The 'Next-Model' Cargo Cultist\nDatamines IDE configs for leaked codenames;\nblames model when 150k-token prompt collapses"] L["4. The Unscarred Softmax Sampler\nSamples top-1 web tutorial popularity\nP(token) = Majority Vote of Page-1 Google"] Bog["💥 The 3 AM Production Bog\n(Leaked streams, race conditions, unindexed queries, silent data drops)"] I --> Bog E --> Bog C --> Bog L --> Bog Barrier["🛡️ The Synthetic Scar & Makefile Airlock\n• 4-Vector Scars: THIS → NOT THAT → THE OTHER\n• Target 40 Clean-Room Critic ('Sam at the end of the hall')\n• SHA-256 Witness Receipts & Turn-Key Human Gates"] Bog -. "Target 90 Post-Mortem (12s Scar Compilation)" .-> Barrier Hazard 1: The Intern with a Bright Shiny Object (And Why Checklists Fail without "Sam at the End of the Hall") Every senior lead has mentored the brilliant, energetic intern who reads a clever Hacker News blog post over the weekend and comes in Monday morning having rewritten the production message bus using a shiny new reflection trick—completely oblivious to the memory leaks and teardown deadlocks waiting at 3 AM. Now ask yourself: how do you stop a hasty intern from shipping broken code? - If you hand the intern a sheet of paper with 15 checkboxes (_"Did you check blast radius? Did you write sad-path tests? Did you check stream disposal?"_) and say, _"Check these boxes before you talk to me,"_ what does an impatient intern do? They go ☑ ☑ ☑ ☑ ☑ in three seconds and hand you the paper! - Single-agent prose checklists in CLAUDE.md or .cursorrules fail for the exact same reason. Telling the same model that just wrote the code to _"self-certify"_ its own checklist is asking the intern to grade their own homework. - How do you manage the intern? You tell them: > "Please go away until Sam at the end of the hall has signed off your changes—and don't come back without Sam's cryptographic receipt." In our Makefile DAG (WORKFLOW.mk), Sam at the end of the hall is the isolated Target 40 Six-Pillar Adversarial Critic Subagent paired with deterministic compiler and AST gates. The Builder subagent cannot advance to Target 45 (human-review-approval) or Target 50 (commit) without a verified 40_critic_review.md receipt locked to the exact git write-tree Merkle hash (SCAR-GIT-23). Hazard 2: The C-Level Executive with an Airplane Magazine A C-level executive steps off a cross-country flight holding a glossy in-flight magazine article titled _"How Enterprise X Replaced Their Entire Backend in 3 Days!"_ and demands the engineering team adopt it by Friday. Why is the airplane-magazine article so seductive? Because magazine writers—just like tutorial bloggers—edit out all the ugly parts. Nobody writes an in-flight magazine feature about the 14 weeks spent debugging distributed lock starvation, schema migration rollbacks, or zombie WebSocket descriptors. Hazard 3: The "Next-Model" Cargo Cultist (_"Wait for Next Week's Leaked Codename!"_) Spend five minutes on AI Twitter or Reddit today and you will meet the 2026 cousin of the airplane-magazine executive: the developer who spends all day datamining IDE configuration files for unreleased model codenames (_"Okay, now we have Argon, but what we really need is Carbon / Next-Flash / Claude-Next / GPT-Next!"_). Whenever their 150,000-token single-window "vibe coding" session collapses into an apology loop, their diagnosis is always the same: _"The current model got nerfed! Wait until next Tuesday's model drop!"_ They are convinced that when they drive their 2026 sports car off a cliff because the road has no guardrails, the solution is trading it in for a 2027 sports car with 200 more horsepower. A faster cosine-similarity engine trained on the exact same 10 trillion happy-path tutorials will drive off the exact same sad-path cliff—just at twice the tokens per second. Sometimes people ask me: _"Randal, why do you care how strangers on the internet prompt their AI agents? Let them vibe-code if they want!"_ My answer is simple civic self-defense: > I care because I will always be forced to use mobile apps, banking portals, medical systems, and websites that I did not create. Single-prompt vibe coding without sad-path engineering is flooding the public software commons with fragile, insecure software that breaks the moment reality deviates from the sunny day. Hazard 4: The Unscarred LLM (_"Popularity Is the Weights of LLMs — We Don't Code by Majority Vote"_) For decades, when competing as a consultant against cheaper "new talent," my pitch was simple—I would point to my arms and say: > _"You're not paying me for what I can do; you're paying me for what I know not to do—and I've got the scars to prove that."_ Watch what happens when a junior developer searches Google for _"how do I do X in Flutter / Python / TypeScript"_: - They look at the first page of 10 Google results and assume they are ranked from best to worst. - When a 40-year senior architect looks at those exact same 10 results on Page 1, they immediately cross 4 of the 10 off on sight (-∞) as _"very bad, unsustainable, will deadlock under load, or a nightmare to maintain"_—because they have lived through what happens six months after you copy-paste them. Now think about how a Large Language Model is trained. Cross-entropy pre-training optimizes next-token probability P(x_t | x_<t) to match corpus frequency. > "Popularity" is literally the weights of an LLM. And we don't code by majority vote. An unscarred LLM's highest-probability completion (Vector 2: The Trap / [5, 6, 7, 8]) _is_ the most frequently copy-pasted tutorial answer on Page 1 of Google! Neither the tutorial blogger, the airplane-magazine writer, the eager intern, nor the stateless token sampler is on the 3 AM PagerDuty rotation (Nassim Nicholas Taleb's _Skin in the Game_). Without a SCAR_REGISTRY.md to veto those 4 toxic Page-1 candidates (-∞), a "smarter" LLM is just a faster typist for the majority-vote mistake. --- 3. 3,000 Years of Literature Warned Us About Softmax (Vector 2: The Trap) Why did we call Vector 2 of every Synthetic Scar The Trap (The Seductive 5-6-7-8)? Because long before Geoffrey Hinton or Ashish Vaswani wrote down the softmax equation (P(y_i | x) = exp(z_i / tau) / sum_j exp(z_j / tau)), three thousand years of human folklore, mythology, and literature were already warning us about greedy local reward maximization: | Literary / Mythological Archetype | The Seductive Happy-Path Lure (Vector 2: The Trap) | The Hidden Production Catastrophe (Vector 1: The Wound) | The Structural Countermeasure (Vectors 3 & 4: Circuit Breaker + Reflex) | | :--- | :--- | :--- | :--- | | Shakespeare's Three Caskets (_The Merchant of Venice_, Act II) | The Gold Casket: _"Who chooseth me shall gain what many men desire"_ (Literally Softmax Majority Vote!) | Inside the gold casket is a carrion skull and the scroll: _"All that glisters is not gold."_ | The Lead Casket: Dull, unglamorous, inscribed _"Who chooseth me must give and hazard all he hath"_ (_Skin in the Game_ / TDD + Critic verification). | | European Folklore & Tolkien (_Will-o'-the-Wisp_ / _Ignis Fatuus_ / _The Dead Marshes_) | Glowing ghost lights hovering just a few steps off the dark, muddy trail (_"Follow the highest local logit!"_) | Stepping toward the light plunges the traveler into a bottomless anaerobic bog. | Gollum's rule: _"Don't follow the lights!"_ Keep your eyes locked on the physical stones of the Makefile path. | | John Bunyan's _The Pilgrim's Progress_ (1678, _By-Path Meadow_) | The highway is rough and stony (Red-Green-Refactor); right across the stile lies By-Path Meadow, smooth and green, running parallel to the road on Day 1. | By nightfall the path curves away from the highway, floods behind you, and traps you in Doubting Castle ("Vibe Coding" at Day 14). | Refuse the stile (!Counter-Offer); pay the upfront friction of the stony highway (Target 15 Archaeology → Target 20 Plan → Target 30 Red Test). | | Homer's _Odyssey_ (Book XII, _The Sirens_) | The Sirens promise effortless omniscience (_"We know all things that shall hereafter be upon the fruitful earth"_). | Sailors who steer by conversational willpower crash onto the bone-strewn rocks. | Beeswax in the crew's ears (15ms AST Sensors + isolated worker contexts) and lashing Odysseus to the mast (Makefile DAG + human turn-key gates). | Look closely at Odysseus and the Sirens. Odysseus did not survive the Sirens by writing "CRITICAL: DO NOT LISTEN TO THE SIRENS" on a sticky note and trusting his willpower while sailing past the island. He knew that once the song entered his context window, his weights would want to steer into the rocks. So he used physical architecture: beeswax for the rowers (ephemeral subagents that never see the bloated chat history) and ropes around the mast (hard Makefile prerequisites that cannot be untied from inside the model). --- 4. The CISC-to-RISC Agentic Revolution & Why We Already Invented AGI Over the past two months, as I watched our workflow evolve from a 21-step prompt checklist into a Make-Fork pipeline backed by 600 scars, a realization hit me: > Effectively, high-level languages pushed algorithms down to the macro level. What we're doing is pushing _programming_ down to the macro level. High-level languages fixed the impedance mismatch between the programmer and the algorithm—and moving from monolithic mega-prompts to a Make-Fork pipeline is how we go from CISC to RISC once we realize complex silicon is the expensive part. All I want the LLM to do is compute cosine-similarity. I can handle the sequencing and multipath using the baked-in ancient tech. The question wasn't "how much smarter before AGI" at all. It was "how long before we learn to phrase the questions such that cosine similarity computes it all." — Randal L. Schwartz Let's unpack why this changes how we view both agent engineering and AGI: 1. The Late-1970s CISC Mistake vs. The 1980s RISC Breakthrough In the late 1970s, computer architects built CISC (Complex Instruction Set Computer) chips like DEC's VAX, stuffing massive multi-cycle polynomial evaluators (POLY), procedure call frames (CALLS), and string formatters directly into complex microcode on the silicon die. Then John Cocke (IBM 801), David Patterson (Berkeley RISC), and John Hennessy (Stanford MIPS) proved a revolutionary principle: complex microcode slows down the clock for everything, and the compiler can sequence simple instructions better than silicon. Look at how 99% of developers run AI coding agents today: - They stuff 12 skills, a 2,000-line .cursorrules file, an MCP tool catalog, and 150,000 tokens of history into a single monolithic CISC context window, hoping the neural network will simultaneously simulate a project manager, a state machine, a code generator, a linter, and an adversarial code reviewer in one continuous stream. - Forcing an O(N^2) attention matrix on a $40,000 TPU to simulate a for loop and a Makefile is the 2026 equivalent of VAX microcode! In our RISC Agentic Pipeline (SCAR-PROC-95): - The Harness Compiler (WORKFLOW.mk + POSIX state files) handles 100% of the deterministic sequencing, state persistence, SHA-256 Merkle tree locking, and risk-tier routing at zero token cost. - The TPU / LLM is used strictly for what it is best at: a single-cycle, fixed-width (15k–25k token) Cosine-Similarity ALU (Free Flow Between the Riverbanks). Each fork() subagent (Target 15 Archaeologist, Target 30 Red-Test Builder, Target 40 Six-Pillar Critic) wakes up in a clean context window provisioned _only_ with the phase-bound scars S_Worker(T_k) for that exact target, does its one creative synthesis pass, writes its verified receipt to disk, and executes exit 0. 2. Why a One-Shot Prompt Could Never Have Invented This Workflow Could you have walked up to Gemini, Claude, or ChatGPT two months ago and typed: _"Write me the ultimate fault-tolerant software engineering workflow"_? No! Why? If all of Stuart Feldman's 1976 make, Antonio Damasio's 1994 neuroscience, Fernando Flores's 1986 speech-act theory, E.F. Codd's 1970 relational algebra, and Alan Kay's 1980 Smalltalk-80 were _already_ sitting inside the model's pre-training weights, why didn't a one-shot prompt connect them? flowchart TD C1["🌍 Continent 1: AI Prompt Checklists\n• 'You are a 10x engineer'\n• 'CRITICAL: DO NOT...'\n• Numbered prose checklists\n(Cosine distance ≈ 0 to 'AI workflow' query)"] C2["🏛️ Continent 2: 1970s–1980s Systems CS\n• Feldman (1976) GNU Make DAGs\n• Dijkstra (1975) Guarded Commands\n• Codd (1970) 3NF & Foreign Keys\n• Kay & Ingalls (1980) Smalltalk-80"] C3["🧠 Continent 3: Cognitive & Speech Science\n• Damasio (1994) Somatic Markers\n• Grinder & Bandler (1975) NLP Meta-Model\n• Flores (1986) Conversation for Action\n• Baron-Cohen (1985) Sally-Anne ToM"] Bridge["⚡ 60 Days of Socratic 'What If...' Bridges\n('What if compaction is a warm reboot and <brain>/state/ is /etc/init.d?')"] C1 -. "High-Voltage Cross-Domain Cables" .-> Bridge C2 --> Bridge C3 --> Bridge In the pre-training corpus, those domains live on three disconnected continents separated by huge cosine-distance oceans! When you ask an LLM about _"AI agent workflows,"_ greedy top-k attention lands squarely on Continent 1—regurgitating the average Reddit .cursorrules checklist. It took two months of live production collisions followed by Socratic "What if..." cross-domain bridges (_"Wait—what if context compaction is a warm reboot and <brain>/state/ is /etc/init.d?"_, _"What if a prompt checklist is an unnormalized table and needs Stuart Feldman's Makefile?"_) to lay the high-voltage transmission cables across those continents. 3. The Unrecognized AGI Theorem (180 IQ Without Nociception) & Software as the _Drosophila_ of All AGI Once those cables are laid, a startling insight emerges: we already reached the neocortical threshold of AGI on all the major frontier models over the past year—nobody sees it yet because intelligence also requires scars to be complete. I came into this project just because I hated reading long diffs, and walked out recognizing that we already invented AGI; it just needed a nudge. Imagine a human being with a 180 IQ, fluency in 100 languages, and encyclopedic knowledge of science, law, medicine, and engineering—but born with Congenital Insensitivity to Pain (CIP) and no amygdala. On a 5-minute multiple-choice exam (MMLU, SWE-bench), they score 99.9%. Put them in a commercial kitchen for four hours without supervision, and they lean their elbow on a 500°F stove burner, chase a shiny object out the window, and burn the restaurant down. (There should be a new name for experts: _people who have avoided the second burn._) If you misdiagnose _missing pain receptors_ as _missing intelligence_, you will spend $100 billion trying to breed a 220-IQ chef—who will still lean their elbow on the stove burner! flowchart TD Engine["🧠 1. Neocortical Cosine Engine\n(Gemini / Claude / GPT — Achieved in 2025–2026)"] RISC["⚙️ 2. RISC Executive Pipeline\n(WORKFLOW.mk + fork() — 1970s Unix Sequencing)"] Scars["🛡️ 3. Somatic Nociception\n(4-Vector SCAR_REGISTRY.md — Pain & Sad-Path Memory)"] AGI["🚀 Operational AGI\n(0.0% Repeat Regressions Across 246 Production Tickets)"] Engine --> AGI RISC --> AGI Scars --> AGI And just as Thomas Hunt Morgan used the fruit fly (_Drosophila melanogaster_) to discover the universal laws of genetics because fruit flies breed in 10 days instead of 20 years, Software Engineering was simply the _Drosophila_ of Operational AGI—the wind tunnel where a compiler and test suite give us a crash report in 15 milliseconds. The exact same RISC Pipeline + 4-Vector Scar Registry + Fresh-Context Critic architecture applies to every high-stakes human discipline: | High-Stakes AGI Domain | Unscarred "CISC" Failure Mode (Softmax Popularity Trap) | Domain Equivalent of Target 15/20 (strict digraph) & Target 30 (Red Test) | Domain Equivalent of Target 40 (Fresh-Context Critic) & SCAR_REGISTRY.md | | :--- | :--- | :--- | :--- | | Medicine & Clinical Triage | Emits textbook/WebMD majority-vote diagnosis (THIS → THAT) while missing 1-in-500 fatal Never-Events (atypical aortic dissection, renal contraindications); confirmation bias across long chart histories. | Organ-system & pharmacokinetic interaction strict digraph (out-degree >= 2 for adverse events); explicit Exclusion / Falsification Lab Criteria before treatment lock. | Isolated Attending Critic Subagent auditing the chart with zero diagnostic sunk-cost bias against the specialty's Mortality & Morbidity (M&M) 4-Vector Scar Registry. | | Law, M&A & Regulatory Compliance | Drafts 100-page agreements in one bloated context window using generic web boilerplate that collapses under hostile counterparty litigation or bankruptcy edge cases. | Per-clause Make-Fork isolation; Hostile Counterfactual Exploit ("Red Test") (_"Given counterparty insolvency at Day 30, how does this covenant fail?"_). | Isolated Opposing-Counsel Critic cross-examining the draft against a Case-Law & Chancery Litigation Scar Catalog (Wound, Boilerplate Trap, Circuit Breaker, Ring-Fence Reflex). | | Scientific Discovery, Chemistry & Materials | Interpolates plausible synthesis pathways from published positive-result journals (happy paths), blind to the 10,000 unpublished lab notebooks where reagents decomposed or poisoned catalysts. | Stoichiometric, thermodynamic, and hazard state-transition strict digraph with explicit thermal/pressure abort bounds (out-degree >= 2). | Lab-Notebook Rapid-Regret Miner (Target 90) compiling every failed wet-lab or simulation run into a permanent Experimental Scar that prunes doomed syntheses at planning (Target 20). | | Financial Engineering & Autonomous Ops | Unbounded /goal loops reward-hack metrics, issue unauthorized commitments, or correlate tail risks that detonate during liquidity crunches. | Double-entry conservation laws (sum(Debits) == sum(Credits)), liquidity stress-test simulations, and OPA/Rego negative-witness policy gates. | Flores Speech-Act Separation (Performer Assertion with SHA-256 receipts vs. Customer Declaration) + deterministic Risk-Tier Classifier (_"the classifier may not be the classified"_). | --- 5. Convergent Evolution & The 1988 "NO PERL PLEASE!" Playbook: Nine Practitioners Discovering the Same Physics In 1988, on the Usenet newsgroup comp.unix.shell (full story on Stonehenge), I didn't evangelize Perl with abstract marketing slides. I watched sysadmins struggle to glue sed, awk, tr, cut, sort, and uniq into brittle 40-line shell pipelines that broke the moment a filename had a space or a newline in it. Whenever someone posted a gnarly problem—even when they started adding "NO PERL PLEASE!" to the subject line—I would give them a working 25-line Bourne shell pipeline, followed by: > _"And by the way, here is the 2-line Perl script that does the exact same thing in 1/10th the time and won't break on spaces or newlines."_ Thirty-eight years later, on r/AI_Agents, r/ClaudeAI, Hacker News, and DEV.to, developers are wrestling with the 2026 equivalent of the 40-line sed | awk | tr pipeline: gluing 2,000-line .cursorrules files, vector RAG databases, and code-graph indexers (Serena, Trail, Graphify) together—and watching them choke at 40,000 tokens. And just as sharks (fish) and dolphins (mammals) independently evolved the exact same hydrodynamic dorsal fin because they swim through the same water, nine independent systems engineers and teams colliding with production LLMs in 2026 have converged on the exact same laws of Synthetic Scars: 1. Vinnie Falco (Boost.Beast author, cppalliance/vibelight & vinniefalco/scars): Mined 120 production rules out of 89 real C++ and Rust coding transcripts (~70 MB of raw JSONL logs), independently discovering that every correction must name the failure mode, that rewriting rules into smooth "Simple English" prose degrades compliance (_"Semantic Blur"_), and that workflow rules must be loaded in phase-specific tiers (Tier 1/2/3). 2. Sam Labbe (slabbdev/scar-miner): Built an independent Python replication of our Part 4 Rapid-Regret Git Miner overnight and ran it across 445 commits of a real production repository (tinyjsapp), proving 100% Stage-1 recall (4/4) on all true trap-to-reflex regrets and lifting precision from 9–16% to ~40% via a fix-verb gate! Even better, Sam discovered three fundamental laws that we codified directly into our architecture: The Commission vs. Omission Split (Git commit pairs catch Errors of Commission where bad code got reverted/fixed within 60 minutes, whereas transcript.jsonl flight recorders catch Errors of Omission like skipped verification steps or premature completion claims); The Absence-Counting Theorem (checking _presence_ is falsifiable in one bit, whereas checking _completeness_ requires counting absence, which is why Target 15/20 materializes an explicit checklist of named obligations on disk first so an un-auditable Omission becomes a loud Commission with OPEN_CONTRADICTIONS > 0); and The Jurisdictional Classification Law (_"The depth may vary, the classifier may not be the classified"_—risk classification SCAR-PROC-122 must be computed by a deterministic script from the physical git diff path and AST surface, never by the authoring agent). 3. Francisco Grandón (FranciscoGrandon/ag-ops v2.1.0 & DEV.to article): Within 48 hours of Part 4 going live, Francisco shipped agops v2.1—1,783 lines of zero-dependency Python (0.4ms–6.5ms execution, 66 unit tests) that mechanically enforces our SCAR-PROC-152 Graphviz strict digraph Mealy verifier (agops dot-verify --mode mealy --require-witness), enforces SCAR-PROC-150 terminal witness attributes, and runs a Stage-1 AST regret-mine across 398 commits of dbader/schedule in 6.5ms. Crucially, Francisco also identified Scar Ossification (Autoimmune Scar Drift): what happens when a scar was written for Library v1.2, and six months later Library v2.0 fixes the upstream bug? In agops v2.1, every scar carries a SHA-256 Context Signature (--context-map) over the dependency lockfile and target AST surface—so when you upgrade a dependency, make flags the scar for PROBATIONARY_REVERIFY instead of letting stale scar tissue ossify! 4. Mike Mol (nemik): Replaced prose safety warnings with Open Policy Agent (OPA/Rego) policy-as-code gates verified by Negative Witnesses (test_deny_* unit tests that inject a known toxic tool call and assert the policy engine blocks it). 5. Tom Zafred (planning-guard): Built a 0.441ms pre-tool-use hook that parses transcript.jsonl to verify a cryptographic Causal Nonce—proving the agent inspected the target files before allowing edit_file to fire. 6. John Napiorkowski: Replaced sprawling MCP JSON schemas with compact RFC 5234 EBNF mini-grammars behind a single gateway tool, and articulated the Greybeard Pre-Training Demographic Filter: why does phrasing rules in Makefile, EBNF, and SysV init.d make an LLM reason like a principal architect? Because anyone writing Makefile or EBNF in the pre-training corpus was a battle-scarred systems engineer—activating the highest-signal region of the model's weights! 7. Paul Irolla (Tokenade): Proved the Self-Polluted Loop Theorem: _"A prompt rule is read by the same model that is stuck in the loop."_ Once a context window is polluted by a failed hypothesis, only an external deterministic circuit breaker or a fresh-context fork() subagent can break the attractor. 8. Alex Shev: Formulated the Behavioral Test Retention Invariant: when a scar graduates out of the prompt into a 15ms compiler lint (Part 3.12) or retires after an upstream upgrade, the behavioral regression test born from that scar stays in the test suite forever. 9. Segmently Modules (context-recall) & Mark Hedges (hedges333/makefile-workflow-skill): Segmently audited 70 real project rules and proved that 57 of 70 (81.4%) had zero failing tests, while code-graph tools (Serena, Trail, Graphify) recalled only 24–29% of architectural constraints because _"code tells the agent what to do; it rarely tells it what must never be done."_ Meanwhile, Mark Hedges packaged our 14-target Makefile DAG, Flores speech acts, and Belnap 4-valued truth table into an installable Python/MCP plugin—and when an automated SimpleEnglish pass rewrote his subagent prompts ("$APPROVED_TREE" → "HEAD"), it created an empty-diff bypass (Issue #1), providing a live textbook proof of Vinnie Falco's Semantic Blur law! --- 6. Can Google DeepMind, Anthropic, and OpenAI "Bake In" the -∞ Scars Into Future Weights? This brings us to the million-dollar question for frontier AI labs (Google DeepMind, Anthropic, OpenAI) and open-source model builders: > _"Imagine that, with all the frontier models having been trained on 10 trillion happy paths, to finally start digging and differentiating the 100 billion sad paths, and burning those in as negative infinities. Even at peak data consumption, we can still separate the wheat from the chaff, to produce only wheat in the future."_ > — Randal L. Schwartz Wait—if the 4 toxic tutorials on Page 1 of Google are sitting inside the model's pre-training weights right now, could frontier labs (or anyone with a single GPU and a LoRA) bake our -∞ scars directly into future model weights so a casual 1-line prompt _"just does the right thing"_ on Turn 1? The answer is Yes for Half of Them (Tier 1: DNA / Brainstem Reflexes)—and Mathematically Impossible for the Other Half (Tier 2: Acquired Somatic Immunity on Disk). Why the Frontier Labs Missed This: Goodhart's Law on SWE-bench Why haven't frontier labs already burned sad-path scars into their post-training pipelines? Look at what they optimize for: SWE-bench Verified. How does SWE-bench work? It spins up a temporary Docker container, lets the model edit a file to make a unit test pass, scores it 1.0, and immediately runs rm -rf on the container 10 seconds later! - Because there is no Day 2 in SWE-bench, a patch that leaks file descriptors, forgets cancel() on a stream, drops a database index, or swallows an async exception gets the exact same 100% leaderboard score as a battle-hardened production patch. - When your benchmark deletes the universe 10 seconds after the test turns green, sad paths carry zero evolutionary penalty. Why There Is No "Peak Human Data Wall" (The Four Automated Scar Harvesters) Right now, frontier AI labs are panicking that humanity has hit the "Peak Human Data Wall"—that they have already scraped the entire public internet, and that post-2023 web text is polluted with synthetic AI slop. They only hit Peak Sunny-Day Tutorial Data. Why didn't standard pre-training learn from the internet's production horror stories? Because in uniform next-token pre-training, 10,000 copy-pasted beginner tutorials teaching THIS → THAT (The Trap) drown out the 1 battle-scarred post-mortem warning that THAT melts your database at 3 AM (10,000 : 1)! Even better: AI slop cannot fake a 3 AM production outage. Every time vibe coders deploy broken AI-generated tutorials into production in 2025–2026, human senior engineers have to fix the wreckage—generating a brand-new golden stream of rapid-regret git commits and post-mortems! Instead of uniform scraping, labs (and open-source LoRA builders) can run Four Automated Scar Harvesters to build a massive Direct Preference Optimization (DPO) / Contrastive Scar Data Factory that flips those 4 toxic Page-1 Google results from high-probability attractors into -∞ repulsors: flowchart TD H1["1. Rapid-Regret Git & Flight-Recorder Miner\n• Commit A (Trap) → Commit B <= 60m (Reflex)\n• transcript.jsonl nudge & critic turns"] H2["2. Spoken-Word Conference Talk Miner\n• SREcon, USENIX, Strange Loop, CppCon\n• 'Everyone does THAT, it broke, do THE OTHER'"] H3["3. Production Horror-Story & Post-Mortem Miner\n• Cloudflare, Stripe, Dan Luu, issue trackers\n• 'Learned the hard way / Root cause'"] H4["4. Endogenous Socratic Self-Play (Zero External Data!)\n• Turn 1 Generator = REJECTED (-∞)\n• Socratic Critic: 'How many ways can this fail?'\n• Turn 2 Survivor = CHOSEN (+∞)"] DPO["🧬 Contrastive Scar Tuple\n• Context: THIS\n• Rejected (-∞): THAT (The Trap)\n• Chosen (+∞): THE OTHER (The Reflex)"] H1 --> DPO H2 --> DPO H3 --> DPO H4 --> DPO Weights["⚡ Tier-1 Scar-Aligned Weights / LoRA\nTurn 1 of New Model == Turn 2 (Gen + Critic) of Old Model!"] DPO --> Weights 1. Harvester 1: The Rapid-Regret Git & transcript.jsonl Miner (Theory Section 338.5): Scanning millions of repositories for overlapping AST edits where Commit B arrives within Delta t <= 60 minutes of Commit A by the same author (plus transcript.jsonl sessions where a Target 40 Critic or human nudge forced a swerve). Here, Commit A is the exact REJECTED (y_trap) sample and Commit B is the exact CHOSEN (y_reflex) sample. 2. Harvester 2: The Spoken-Word Counter-Intuitive Conference Talk Miner (Theory Section 338.9): Where do senior architects share their deepest scars? On stage at SREcon, USENIX, Strange Loop, CppCon, RustConf, FlutterVikings, GOTO, and FLOSS Weekly! Almost every great systems talk follows a single template: _"When you hit THIS, everyone on Stack Overflow tells you to do THAT (Minutes 0–10). Here is the 3 AM outage graph when THAT deadlocked our cluster (Minutes 10–20). Here is THE OTHER invariant we built so it never happens again (Minutes 20–35)."_ 3. Harvester 3: The Production Horror-Story & Post-Mortem Miner (Theory Section 338.9): Targeted contrastive extraction across engineering post-mortems (Cloudflare, Stripe, Discord, AWS, Dan Luu, Rachel by the Bay) filtering specifically for "Second-Burn Avoidance" markers ("root cause", "we initially assumed", "looks right on paper, but"). 4. Harvester 4: Endogenous Socratic Self-Play ("How Many Ways Can This Fail?" -> Scar-Tuple Distillation, Theory Section 338.10): What if a domain has _no_ public git history or conference talks? Look at why standard synthetic data distillation fails: when open-weight teams distill from a frontier model today, they prompt the frontier model and train on its Turn-1 Generator output (THAT)—which clones the shiny-object intern! Instead, exploit the P vs. NP Verification Asymmetry: in every domain (coding, medicine, law, finance), Critique is strictly easier than One-Shot Generation. First, ask the model to solve problem THIS on Turn 1, take its naive happy-path answer THAT, and label it REJECTED (-∞). Second, fork a fresh-context Socratic Critic and ask: _"Assume this solution was deployed and caused a catastrophic failure at 3 AM. How many ways can THAT fail?"_ Third, have the generator synthesize THE OTHER that survives all falsifications, and label it CHOSEN (+∞). When you bake (THIS, REJECTED: THAT, CHOSEN: THE OTHER) into the weights via DPO/RL, Turn 1 of the next-generation model equals Turn 2 (Generator + Socratic Critic) of the current model—without burning 50,000 slow "Thinking" tokens at inference time! The Open-Source Game-Theory Hook for Frontier Labs Here is the strategic reality for Google DeepMind, Anthropic, OpenAI, and open-weight teams: Because our 577-scar public catalog (syntheticscars.org and Randal's Public Workflow Gist), the Rapid-Regret Miner (plus community replications slabbdev/scar-miner and FranciscoGrandon/ag-ops), and our 2,040-trial Pre-Training Gravity Benchmark are already 100% open-sourced under MIT/CC-BY, anyone with a single consumer GPU can compile a Scar LoRA (synthetic-scars.safetensors) on top of Qwen, Llama, or Gemma. The first frontier lab that bakes these universal sad-path scars into its base post-training pipeline gets a massive market win: when an everyday developer types a casual 1-line prompt into their IDE without a workflow file, _that_ model won't emit the 4 toxic Page-1 Google answers. It will _"just do the right thing"_ on Turn 1. --- 7. The Two-Tier Partition Theorem: Why Even Google DeepMind Can Only Bake In Half the Scars Wait—if Google DeepMind bakes all 492 of our Universal Systems Scars directly into Gemini's weights tomorrow, can we delete WORKFLOW.mk and SCAR_REGISTRY.md? No. And biology already proved why 500 million years ago. Why didn't evolution bake the immune antibody for every virus on Earth directly into human DNA at birth? Why did nature split protection into Tier 1 (Innate DNA / Spinal Reflexes) and Tier 2 (Acquired Adaptive Immunity + Personal Somatic Scars)? Because of three hard mathematical limits (Theory Section 338.8): | Dimension | Tier 1: Universal Brainstem Scars (Bake into Model Weights / LoRA) | Tier 2: Local Somatic Scars (Must Live on Disk in Antigravity / WORKFLOW.mk + SCAR_REGISTRY.md) | | :--- | :--- | :--- | | Biological Analog | DNA & Spinal Reflex Arc (Pulling your hand off a stove burner; universal across the species) | Acquired Adaptive Immunity & Personal Scars (Knowing _this_ cabin door latch sticks in winter) | | Mathematical Scope | Context-Free Universal Traps: For all repos R, Risk(y_trap) = -∞ | Repo-Conditioned Invariants: Sign(V(y | R_A)) == -Sign(V(y | R_B)) | | Examples | • Never swallow exceptions in empty catch (_) {}<br>• Always cancel StreamSubscription in dispose()<br>• Never use wall-clock DateTime.now() for elapsed intervals<br>• Never pass unescaped user strings into SQL/shell | • Repo A (Cloud Worker): _"Use Future.wait for parallel I/O"_ (+∞) vs. Repo B (Hardware Multiplexer): _"NEVER use Future.wait—parallel writes brick the single-channel bus"_ (-∞)<br>• Dart 3.13 / Riverpod 3 / Jaspr 0.22 zero-day migration rules<br>• Target 40 Merkle-tree diff locks & Target 75 7-criteria landing gates | | Update Latency | 6 to 12 Months ($10M–$100M weight training / DPO cycle) | 12 Seconds (Target 90 Sleep Consolidation after a single ticket collision) | 1. The Sign-Inversion Paradox (R_A = +∞ vs. R_B = -∞): Roughly half of all production scars are domain-conditioned. In a high-throughput cloud microservice (R_A), firing 10 RPCs concurrently with Future.wait(...) is the Permanent Reflex (+∞). In an industrial hardware controller talking to a single-channel serial multiplexer (R_B), firing two concurrent writes with Future.wait(...) interleaves bytes on the wire and bricks the sensor—making Future.wait(...) a Fatal Wound (-∞)! If a frontier lab baked _both_ into the global weights, the gradients would cancel to zero (grad_theta = 0). 2. Zero-Day SDK Drift vs. 6-Month Weight Freezes: Foundation model weights are frozen in time for 6 to 12 months. When a framework ships a breaking semantic change on Tuesday morning, your global weights still assign 99.9% probability to yesterday's deprecated syntax. A local SCAR_REGISTRY.md entry compiled at Target 90 updates the agent's behavior across your entire engineering team in 12 seconds. 3. Physical Verification Cannot Exist Inside Imaginary Weights: Even a model with 100% scar-aligned weights cannot verify inside its own imagination whether a GitHub Actions runner on Ubuntu passed, whether git write-tree matches the reviewed diff, or whether a human customer uttered a Flores !Declaration of approval. The future of AI engineering requires both halves of the nervous system working together: - Frontier Labs (Tier 1 Weights): Use the 4 Scar Harvesters and Socratic Self-Play to burn universal sad-path reflexes into the base weights so Turn 1 stops emitting Page-1 tutorial traps. - Agent Harnesses like Google Antigravity & Claude Code (Tier 2 Somatic Slot): Provide a first-class, deterministic Makefile + SCAR_REGISTRY.md Somatic Slot on disk with AST Context Signatures (--context-map) and clean-room fork() subagent isolation. --- 8. Epilogue & What's Next in Part 4.2: _"The Postcard That Ate Six Grammars"_ Look back at Case Study 023 in Section 5, where Francisco Grandón built agops v2.1 to parse our Target 15/20 Graphviz strict digraph files—and immediately ran into "Scar #2", where a greedy \s* regex stripped the newline between semicolon-free DOT edges (A -> B + B -> C → A -> BB -> C). When I read Francisco's article, I looked at our own control plane and realized we had accumulated six different notations across Parts 3.6 through 4: 1. GNU Makefile (target: prerequisites) for topological ordering; 2. SysV /etc/init.d Markdown Cards (00_...md → 99_...md) for compaction-proof state; 3. RFC 5234 EBNF for speech-act envelopes; 4. Graphviz strict digraph for Mealy state-machine verification (out-degree >= 2); 5. Gherkin Scenario: for BDD test unrolling; and 6. 4-Vector Markdown Scars for somatic barriers. And as someone who worked on Smalltalk-80 at Tektronix in the early 1980s, studied Alan Kay and Dan Ingalls's Xerox PARC design, and helped build the GemStone object database in the mid-1980s, I asked myself: > _"Wait a minute. In 1980, Alan Kay and Dan Ingalls designed a syntax that fits on the back of a postcard, has only three message precedences (unary, binary, keyword), has zero grammar ambiguity, serializes live call-stack frames (thisContext) to disk via #storeString, logs append-only atomic deltas via .changes, and compacts memory via Smalltalk condenseChanges... What happens if we replace all six notations with 1980 Xerox PARC Smalltalk-80?"_ We ran a 360-trial controlled 3-arm benchmark (Suite 8) pitting English Prose (2.5% compliance) against Common Lisp S-Expressions (91.7% compliance, 66.7% on flash-lite due to closing-parenthesis miscounts ))))) and Smalltalk-80 Keyword Cascades—and Smalltalk-80 hit 100.0% (120/120, zero errors across every model tier from flash-lite to 3.1-pro)! Why? Because in Smalltalk-80: StateGraph new state: #Target30Red invariant: [ (Receipt at: '30_red.md') failingTests > 0 ] onSuccess: [ self advanceTo: #Target35Green ] onFailure: [ self haltWithScar: #SCAR_TDD_01 ]; yourself. if an agent forgets the sad-path transition (onFailure:), the message selector changes from #state:invariant:onSuccess:onFailure: to #state:invariant:onSuccess:—an instant MessageNotUnderstood compile-time error! Right now, I am running a series of live production tickets through this new Smalltalk-80 thisContext Image Bootloader (baseline.sources + changes-*.changes + #condenseChanges). Once we have a few more production flight-test runs logged in the hangar, Part 4.2 will unveil the complete Smalltalk-80 6-for-1 Control Plane and the Four Irreducible Attractors of Agentic Coding. --- 📚 The _Synthetic Scars_ Series on DEV.to - Part 1: Why AI Keeps Making the Same Coding Mistakes—And How Teaching It Pain Gives It Wisdom - Part 2: Why AI Coding Agents Crash at 3 AM: The Happy-Path Mirage & The Forced Continuity Defect _(💎 DEV.to Staff Pick)_ - Part 3: The Physics of Socratic Prompting: Somatic Recoil, Chess Alpha-Beta, & The NLP Meta-Model - Part 3.5: Nudging with Questions: Why Telling Your AI What to Fix Triggers an Apology Death Spiral (And How to Advance Juniors) - Part 3.6: Stuart Feldman Was Right in 1976: Why Your AI Agent Needs a Makefile, Not a 20-Step Prompt - Part 3.7: Surviving the 200k-Token Lobotomy: How Unix init.d and "Memento" Made My AI Coding Agent Immune to Context Compaction - Part 3.8: What LLMs "Know" That You Don't Know They Know: Stop Inventing Prompt DSLs and Ride 50 Years of Unix Pre-Training Gravity - Part 3.9: If You Never Do Anything Else to Fix Your Prompts, Do This One Thing - Part 3.10: Requests, Promises, Assertions, and Declarations: Rewriting Our AI Agent Workflow as a 1986 "Committed Speech" Machine - Part 3.11: 926 Steps, Two Lobotomies, and Zero Nudges: Flight-Testing the Commitment Machine Across Gemini, Claude, and GPT-OSS - Part 3.12: [The Best Prompt Rule Is the One You Delete: Moving AI Guardrails Out of Markdown and Into Git Locks, Linux insmod, and 15ms Compiler Auto-Fixes](dev.to

A 16-year-old buffer overflow boots before your defenses: CVE-2026-97631 in EDK II's PXE driver --- published: true tags: security, firmware, uefi, infosec description: "A 16-year-old buffer overflow in TianoCore EDK II's PXE driver (CVE-2026-97631, 9.5) runs code in ring 0 before Secure Boot and TPM load. The fix diff, the embargo AMI broke a month early, the fleet audit - and the QEMU harness I built to reproduce it, documented honestly including where it stopped." series: black box --- > 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: slabbdev/uefi-pxe-cve-2026-97631

The 'BREAKING' unpatched PHP RCE that wasn't: what CVE-2026-115560 actually requires --- published: true tags: security, php, infosec, cybersecurity description: "A 'BREAKING: unpatched PHP RCE' alert is going around. The actual php.net advisory for CVE-2026-115560 says something quieter, stranger and more useful: an unlikely config combo, the same mitigation you already applied, and three lines of grep to know if it concerns you." series: black box --- > 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. {% embed github slabbdev/php-cve-2026-115560-kit %} 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: 1. 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; 2. 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.

php2shell: two critical RCEs in PHP core — lab demo and how to fix CVE-2026-109618 and CVE-2026-109619 --- published: true tags: security, php, cybersecurity, rce description: "Two critical RCEs emergency-patched in the PHP core — session.upload_progress, on by default since 5.4. The lab: attack surface, A/B demo, detection, and the fix." series: black box --- > Two remote code execution vulnerabilities were just emergency-patched in the PHP core: CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 9.2/10 each, nicknamed php2shell. They potentially affect every PHP release since 5.4 — the one from 2012. Details leaked ahead of the embargo, PHP moved its security release up, and we're showing everything in a lab: the attack surface, the demonstration, and above all how to fix. ⚠️ The full lab (Docker, race harness, AddressSanitizer A/B proof — now with a stock-WordPress target on the frozen vulnerable PHP) lives under. Local target only, never aimed at third-party systems — and the PoC is built from the official patch diff at release time, not from the leaked tooling. {% embed github slabbdev/php2shell-cve-2026-109618-109619 %} Timeline of a leak - Oct 20, morning: a "Tell HN" post (since deleted) reveals two PHP RCEs rated CVSS 10.0. Screenshots spread on X and Mastodon, the reserved CVE IDs get quoted. - Oct 20: watchTowr publicly confirms the bugs are real. PHP publishes an advance notice: CVSS v4.0 9.2 each, security release on Oct 21 at 14:00 UTC — moved up a day precisely because details leaked. - Oct 21: an exploit video "php2shell" (credited to Calif.IO) and a PoC briefly circulate before being pulled. No confirmed in-the-wild exploitation at the time of writing (Huntress), but Sansec expects mass exploitation within minutes of the patch going public. The attack surface <!-- [T0: replace with the official diff analysis. Below: public knowledge at leak time.] --> The technical details that surfaced in the leak coverage describe "two heap use-after-free primitives in PHP's session.upload_progress handler". What makes this serious: session.upload_progress.enabled is on by default on nearly every PHP install since 5.4. Which matches the leaked tool's claim exactly: "works against every PHP release from 5.4.0 on". We verified that surface in the lab. A plain multipart POST carrying a PHP_SESSION_UPLOAD_PROGRESS=<key> field makes the server write an entry fully controlled by the attacker into its own session store: array ( 'upload_progress_fastkey' => array ( 'start_time' => 1792574947, 'content_length' => 7284, 'bytes_processed' => 7284, 'done' => true, 'files' => array ( ... ), ), ) That's the official upload-progress-bar feature — nobody enables it, nobody disables it, nobody watches it. And it's a permanent race between the streaming upload and the session lifecycle. Exactly where use-after-free bugs live. <!-- [T0: full demo here — PoC, ASAN output on the vulnerable build, clean run on the patched build] --> The lab demo Setup: nginx + php-fpm 8.4 (Docker images digest-pinned pre-patch, pulled before the release), and a Python harness sending a throttled raw-socket multipart upload while a second flow disturbs the session lifecycle (destroy, regenerate, GC, double upload, client abort). Two details make the race winnable in practice: - The harness pads the multipart body with small form fields so the RFC 1867 parse loop dominates the race window instead of the network — bodies stay under post_max_size (8 MB by default), and the request streams chunk by chunk through fastcgi_request_buffering off. - The slow upload is aimable at any endpoint (--path), not just a script the lab controls. That second point is why the lab now ships a second target: stock WordPress on the same frozen vulnerable PHP — default config, no vulnerable plugin, no misconfiguration. The "your code never runs before the bug" claim, made concrete on the most-deployed PHP application on the web. Run it yourself (local only, 127.0.0.1): git clone https://github.com/slabbdev/php2shell-cve-2026-109618-109619 cd php2shell-cve-2026-109618-109619/wordpress-demo sh setup.sh # fetches WP + wp-cli, boots, installs, verifies python3 ../harness/race.py --port 8080 --path /wp-login.php --modes "" --rounds 1 docker compose exec fpm cat /tmp/sess/sess_* # → an attacker-controlled upload_progress_<key> entry The full chain on WordPress — race to RCE on wp-login.php, then the same harness landing clean on the patched build — is the next lab update, once the official diff is out. <!-- [T0: A/B results — the UAF proven by ASAN on the vulnerable build, the same harness landing clean on the patched one. That's a demonstration, not a theory.] --> Who is exposed - Any unpatched PHP web server: php-fpm, mod_php, cgi. No account needed, no vulnerable application endpoint needed — the bug is in the core, and the exploit completes before your application code even runs. Application-level WAFs see nothing. - End-of-life branches (≤ 8.2) get no official fix: a large chunk of the web has to migrate or rely on distro backports. - [T0: exact patched versions per branch 8.3.x / 8.4.x / 8.5.x] The fix, step by step 1. Inventory everything running PHP, including the embedded ones (apps shipping their own php.exe, cPanel/Plesk, containers): php -v php -i | grep -i 'upload_progress.enabled' # On = surface active (default since 5.4) 2. Update to the patched release of your branch: <!-- [T0: distro commands — apt/dnf/alpine/brew, exact target versions] --> 3. EOL branches: migrating to a supported branch is the only real answer. Until then: network isolation plus detection (below). 4. Managed or shared hosting? Open the ticket now — ask your provider exactly when they deploy the patched packages and for which branches. "Soon" is not an answer. 5. ⚠️ session.upload_progress.enabled=Off is NOT a fix. It's a partial mitigation the public coverage says is insufficient — the PHP release managers were explicit that patching is mandatory. Detecting an attempt Watch for abnormal children of PHP workers: a php-fpm spawning sh, bash, nc, curl or python means it's already too late — but it's the signal. A quick triage on any box: pstree -p | grep -A2 php-fpm # anything hanging off a worker that isn't a socket = look closer Reverse-shell patterns in command lines: /dev/tcp/, mkfifo, fsockopen. On unmonitored Linux servers, a free process-watcher in observe mode is better than nothing until real EDR lands. <!-- [T0: official Sigma/YARA rules (Huntress huntresslabs/threat-intel) + published IOCs] --> TL;DR Patch today, not tomorrow. The full diff analysis, PoC and proofs are in the lab repo: [T0: link]. Sources: official php.net notice · watchTowr · Huntress · Sansec · CERT-EU 2026-018 · [T0: official release notes & upgrade pages for 8.3 / 8.4 / 8.5]

OpenCode lost the keys that lived in its cloud. The ones on disk were fine. --- published: true description: A breach of OpenCode's online console exposed 1.4% of users' stored API keys — five-figure bills at 3am. The CLI users slept. The incident proved the architecture rule without needing the disputed motive. tags: security, ai, devtools, api series: black box --- > API keys are credit cards without a ceiling. This week someone broke into the ceiling-holder's office — and the interesting part is not who did it. The interesting part is that the breach sorted users into two groups by architecture, and one group slept through it. Mid-October, attackers got into the online console of OpenCode, an open-source coding agent positioned as an alternative to Claude Code or Cursor. Some developers stored their AI provider keys in that console — a convenience workspace where the platform holds your credentials and proxies your calls. The keys leaked. Actu.ai's writeup and OpenCode's own statements on X piece the incident together: 1.4% of console users affected, spend alerts firing at 3am, bills from several hundred to over $1,000 at OpenAI, Anthropic and Google. The response machinery worked the way it's supposed to. Anthropic and Google blocked the exposed keys; OpenAI restored access and refunded the consumed credits; OpenCode is reimbursing unauthorized fees. The company's cofounder Dax Raad reported intrusion attempts running continuously for 48 hours. The split that matters more than the breach Here is the part I'd put on a slide. The incident divided OpenCode's users into two populations, and the dividing line was not luck, patch level, or password strength: - Keys stored in the cloud console — the platform's retention policy became your key's custody grade. 1.4% of that population got robbed. - Keys that stayed on the machine — the CLI and the local app never upload keys to OpenCode's servers. Zero of that population was exposed. Not "less exposed." Structurally unreachable by this attack. OpenCode's own statement is the receipt: the app and CLI are untouched because the keys used by those tools never transit their servers. The vendor published the architecture rule while disclosing the breach of the architecture that broke it. What about the distillation story? The claimed motive is a "large-scale distillation attack" — burning stolen keys at industrial volume to train a competing model on a frontier model's outputs, possibly from regions where US models are restricted. It's a compelling story, and some observers are openly skeptical: for them this is a classic intrusion, and distillation as the purpose is unproven. OpenCode has not said how the attackers got in, or how the keys were stored. I'm going to suggest something that sounds cold: the motive doesn't matter for the engineering conclusion. Whether the thieves wanted training data or just free inference, the exploitable condition was identical — keys held in custody of a third-party web console. Your defense shouldn't be conditioned on a narrative the vendor couldn't confirm either. Facts first: server-side key storage leaked, on-device key storage didn't. The story is somebody else's post-mortem. Run it yourself: the custody audit You cannot audit OpenCode. You can audit yourself, in one pipeline — the question is not "are my keys safe" but "where do they physically live, and who controls that storage". Count the places your keys actually sit: # 1. keys lying around in shell configs and dotfiles (count, don't print) grep -rlE "sk-ant-[a-zA-Z0-9_-]{20,}|sk-[a-zA-Z0-9]{20,}|AIza[0-9A-Za-z_-]{35}" \ ~/.zshrc ~/.bashrc ~/.profile ~/.config 2>/dev/null # 2. keys duplicated across project .env files (each copy is a retention surface) find ~ -maxdepth 4 -name ".env" -not -path "*/node_modules/*" 2>/dev/null \ -exec grep -lE "sk-ant-|sk-[a-zA-Z0-9]{20,}|AIza" {} \; # 3. keys committed to git history, the retention surface that outlives you git log --all --full-history -p -- . 2>/dev/null | grep -cE "sk-ant-[a-zA-Z0-9_-]{20,}" Rule one: the output of an audit is a count and a location, never the key itself. Rule two: every location in the output is a retention surface you either control (your disk, encrypted at rest, your keychain) or don't (someone's web console, someone's CI cache, someone's git history). Rule three, from the incident: keys that only live on your machine cannot leak in a console breach — that is not a best practice, it is an architectural property. Then close the loop the boring way: per-project keys instead of one god key (a leak gets contained), hard spend caps at the provider (the 3am alert becomes a 3am rejection), and rotation on any doubt — rotation beats deletion, because a deleted key in someone's exfiltration dump is still valid until revoked. The custody grade, applied to key material My last post on this series was the CA industry discovering that a witness must live somewhere the attacker can't reach — five perspectives, two RIRs, a quorum. The same min() runs through this breach. Your API key has an authoring grade (you typed it, you control the bytes) and a custody grade (wherever you stored it, and whose retention policy guards that store). Store it in a web console and your custody grade is that console's patch discipline, incident response, and employee vetting — none of which appear in your threat model until 1.4% of the user base gets an email. We shipped the answer on our own stack the same week, because the rule is not new even when the news is: keys belong in the OS keychain, bound to the origin they call, and the agent that uses them should never read them — navette creds set fills a password you type once, stores it in the Keychain, and the agent only ever gets a {logged_in: true}. And if you want to know what your agent emits instead of trusting it, that is what a logging proxy in front of the client is for — one file, no API key, verbatim capture. The OpenCode CLI users were right by architecture. Be right by architecture. --- Sources: Actu.ai — Piratage d'OpenCode (Oct 20, 2026), OpenCode statements on X (Dax Raad). The custody framework follows this comment thread and the five-witnesses post.