There is a function inside the SAP Kernel called the Extended Passport. It brokers session tokens β the small, cryptographically opaque artifacts that one SAP system hands to another so an incoming request can be trusted without the receiving system re-asking who sent it. On September 8, 2026, a researcher demonstrated that this function can be driven to corrupt its own memory, and it does so before any standard SAP security control has the chance to fire. No RFC user. No GUI account. No valid credentials of any kind. Just a crafted packet arriving at a socket, followed by memory corruption wearing a CVSS score of 10.0.
I have spent the better part of a decade auditing systems where the stakes were smaller and the marketing was louder. What made me sit with this particular disclosure was not the ERP drama. It was the shape of the mistake. I have seen that exact mistake before β in bridges, in lending markets, in governance modules, in every pitch deck that promised decentralization and delivered a database with a token stapled to it. SAP simply ran the experiment at industrial scale, in public, with a scoreboard attached.
The vulnerability was never really in the code. It was in the assumption that anything arriving from inside the perimeter deserves to be trusted.
That assumption is the expensive one. And crypto, for all its ideological hostility to perimeters, has quietly rebuilt it everywhere.
Context: why a quarterly ERP patch should terrify a DeFi native
SAP is the largest enterprise resource planning vendor on earth. Its software runs the general ledger, the supply chain, the payroll, and the industrial maintenance schedules of most of the Fortune 500. Patch Day is a quarterly ritual that most people outside enterprise IT have never heard of, in the same way most people have never heard of the compiler that renders their bank statement.
The September 2026 release was not routine. SAP shipped fixes across four distinct layers of one stack at once: the Kernel, which underlies S/4HANA, ECC and Business Warehouse; the NetWeaver Message Server, the load-balancing and cluster-communication backbone that lets application servers discover one another; the Cloud Application Programming Model, SAP's cloud-native development framework; and SAP GUI for Java, the legacy thick client that still sits on millions of desktops. Four layers, one window, one coordinated disclosure partner β Onapsis Research Labs β and more than 10,000 internet-exposed systems inside the blast radius before anyone had finished reading the notes.
The first of the two severe flaws, tracked as CVE-2026-44756 and nicknamed OVERPASS, lives in that Extended Passport parsing path. The second, CVE-2026-58240 or S4GET, lives in the Message Server on port 36NN and lets an attacker impersonate a trusted node inside an SAP cluster, collapsing the passwordless mutual trust that those systems extend to each other by design. A third, CVE-2026-76969, leaks credentials out of the sap/cds-mtxs library inside CAP β a cloud-native supply chain failure sitting on top of the memory-safety failures underneath.
You are already forming the objection. This is enterprise software. This is Oracle's world, not Ethereum's. Why should anyone in this industry care about a German accounting system's passport parser?
Because the discipline that failed here is the discipline that has cost this industry more money than every rug pull combined. I watched cross-chain bridges hemorrhage north of two and a half billion dollars across a handful of years, and the root cause was almost never exotic cryptography. It was the same thing: a component that trusted an incoming message because of where it appeared to come from, rather than because of what it could prove about itself. The bridge believed its own perimeter. The bridge believed the cluster. The bridge believed the node. And then the node lied.
Core: the three ways this exact bug eats crypto protocols
When I dissected Compound's governance mechanics back in 2020, the part that kept me awake was never the vote math. It was the timelock and the executor β the assumption that a proposal arriving through the governance pipeline had already passed the checks that mattered. That is an overpass of the mind. The check happens somewhere upstream, and everything downstream inherits the trust without inheriting the verification. Trust boundaries do not fail when they are broken. They fail when they are skipped, and nobody notices the skipping until the invoice arrives.
OVERPASS is that bug in its purest form. The Extended Passport is, functionally, a session passport. It exists so the trust question gets answered once, cheaply, at the edge, and every subsequent hop can move fast. That is a sensible engineering trade under one condition: that the edge actually holds. When memory corruption lands inside the parser that decides what the passport means, the edge dissolves and the interior β the kernel, the database, the RCE β becomes reachable by an attacker who never authenticated at all. Pre-authentication remote code execution is not a severity label. It is a statement that your security model was a perimeter with a hole where the gate should be.
Now map that onto the last three years of bridge incidents. Most of them are pre-auth in spirit. A relayer accepts a withdrawal proof written by a verifier contract. A verifier contract accepts a Merkle root submitted by a keeper. A keeper accepts a signature because the submitter is on an allowlist. Each layer is a passport. Each layer answers the trust question once and passes the answer down. When a single one of those answers is spoofable β a signature without domain separation, a root without a challenge period, a message without origin validation β the entire stack inherits the lie. The auditor's report says "no critical findings," because each individual control is individually fine. The composition is not.
True ownership begins where the server ends. I have used that line for years to talk about custody. This disclosure gives it a second meaning. Ownership also begins where the implicit trust ends β where a system stops granting privileges by proximity and starts demanding proof by construction.
S4GET is the sharper lesson, because the crypto parallel is unflattering. The NetWeaver Message Server sits in port 36NN and coordinates a cluster of application servers. Those servers trust one another without secrets, because pretending to be a member of the cluster is supposed to be impossible from outside the cluster. That is a shared-secret-in-negative-space design: security derived from an assumption about reachability rather than a key. When S4GET lands, an attacker already positioned on a vulnerable internal web app can promote themselves to a trusted cluster node and then do everything the node can do β including walk straight past segregation-of-duties controls, because those controls were designed to constrain authenticated humans, not to constrain a newly spawned peer.
This is the validator-set problem in a gorilla costume. Every proof-of-stake network has a cluster of nodes that trust one another's consensus messages. Every oracle network has a feed that a set of reporters collectively signs. Every rollup has a sequencer that downstream contracts treat as honest because the design sold the world on the fact that the sequencer is honest. Each of those is a Message Server waiting for its S4GET. The difference between a robust design and a fragile one is not whether the cluster exists. It is whether a stranger who can reach the cluster's port can convince the cluster that the stranger belongs to it. Most of the crypto systems I have examined answer yes, and most of them answer yes because nobody asked the question out loud.
The third flaw is the one that should embarrass everyone who preaches supply-chain hygiene. CVE-2026-76969 leaks credentials out of a cloud-native development library. The mechanism is mundane β bad handling of sensitive values in a multi-tenant runtime, the kind of mistake that shows up when a framework logs too much or when a secrets path is treated as ordinary config. That is the crypto failure mode too. When I sat on the audit side during DeFi Summer, the finding that mattered was almost never the clever reentrancy. It was a private key in a repo, an RPC endpoint with a shared secret, a deployment script that shipped an admin key in an environment file. The glamorous bugs get the write-ups. The boring secrets get the money.
There is a structural lesson buried under all three. SAP built four layers over two decades, each designed for a different era of networking, each piggybacking on the trust the layer beneath it had already established. Over time, the seams between layers became the attack surface. Crypto is doing this faster. A modern DeFi stack is a smart contract calling a proxy calling an implementation that calls an oracle that calls a bridge that calls a verifier that calls a keeper β and every hop is a place where a passport gets passed without being re-verified. We call this composability. We should also call it what SAP's customers are now calling it: a very large collection of inherited assumptions with poor documentation.
Contrarian: the uncomfortable part nobody wants to say out loud
Here is where I will lose half of my audience, so let me lose them explicitly. The SAP disclosure does not argue for self-hosting. It argues for the opposite, and the crypto purist instinct to read it as a vindication of "run it yourself" is precisely backwards.
SAP's cloud customers β S/4HANA Cloud tenants β had kernel patches applied centrally, on the vendor's schedule, without a change-management committee, without a maintenance window, without a basis team arguing about regression tests. They were exposed for hours. The on-premise and hybrid customers, who own their own trust boundaries and their own upgrade calendars, were exposed for days or weeks, because patching an ERP kernel in a live manufacturing company is a political act, not a technical one. Centralized managed infrastructure can be more secure than self-custody β not because centralization is good, but because the alternative requires an operational competence most organizations simply do not have.
The crypto doctrine of "not your keys, not your voice" is a genuine insight about custody and a genuine trap about operations. Not your keys can also mean not your patch pipeline, not your incident response, not your 3 a.m. person. The industry's reflexive libertarianism about infrastructure has produced an ecosystem where a disproportionate share of stolen value sits in self-custodied systems run by teams with the operational maturity of a group project. That is not freedom. That is exposure with extra steps.
The second contrarian note is about disclosure economics. Onapsis found and coordinated these bugs, SAP co-hosted a threat briefing, and both parties get something: SAP gets plausible deniability and borrowed credibility, Onapsis gets its funnel stuffed with enterprise leads. This is a functioning market, but notice what it rewards β proximity to a giant, not independence. Crypto's equivalent, the public bug bounty, is cheaper and messier and produces a very different class of researcher. Neither model is clean. Debate is the compiler for better consensus, and we have not yet compiled a security market that pays for the boring hardening work rather than the headlines.
Takeaway
SAP's September patch will be absorbed, memed, forgotten, and filed under procurement risk. The architecture that produced it will not be. The Extended Passport will survive this fix because the assumption that spawned it β that the inside is safe because it is the inside β is a design philosophy, not a line of code, and design philosophies do not patch on a quarterly cadence.
Crypto is rebuilding the same distributed system on a faster clock with a smaller safety net. When the next pre-auth flaw lands in a sequencer, an oracle, or a verifier, the industry will read its own post-mortem and recognize this document's first paragraph. The question is not whether that report gets written. It is whether we write it now, voluntarily, while the systems are still testnet-fresh β or whether we wait for a scoreboard we did not author. The perimeter is already gone. The only question left is whether we can build trust that does not depend on pretending it is still there.