Mage OSS: A Fail-Open OAuth Bug Is the Quiet Signal Nobody Priced

A callback endpoint received a provider parameter that did not exist. The OAuth library returned an error state. The code detected that error. And then it kept going. That is the entire vulnerability. Mage OSS, the open-source data pipeline orchestrator, shipped an authentication bypass that requires no credential, no user interaction, and no prior access. CVSS 9.8. Network exploitable. Low complexity. Every prerequisite in the attacker's favor box is checked. The fix is in commit 76c4f46 across PR #6204 and #6205. Everything below 0.9.80 is exposed. I want to be precise about what class of bug this is, because the precision determines whether you find its siblings. This is CWE-390. Detection of error condition without action. The library said failure. The application said proceed. In safety engineering terms this is fail-open, and fail-open is not an implementation bug you patch with an if-statement. It is a philosophy. Somewhere in the middleware stack, the error handler and the session creator were coupled in the wrong order. The error got swallowed, Execution fell through into the session creation branch, and a fully authenticated session was issued to an unauthenticated stranger. This matters because the two-PR structure implies two distinct code paths, not a single point of patching. When a maintainer files two PRs for one advisory, they are telling you they found the defect twice. Which means the correct question is not 'is it fixed' but 'what else in this codebase does the same thing.' Token refresh. State validation. PKCE downgrade. Every branch that handles a third-party response is a candidate. Now, the credential map. Mage is not a data store. It is a credential aggregator. It holds AWS IAM keys with S3 read-write reach. It holds Snowflake connection strings that open an entire warehouse. It holds Salesforce OAuth tokens carrying customer PII. It holds ML workflow secrets that gate feature stores and training artifacts. Read that list again and count the blast radius. One bypass equals every key on the board. This is the part the market consistently misprices. Identity-layer breaches hand the attacker an identity. Data-layer breaches hand the attacker the data, the keys to the data, and the keys to everything those keys unlock. The multiplier is not linear. It is exponential, and it compounds silently because the orchestrator is the last place anyone looks for an authentication flaw. I have watched this failure mode for eight years, and the structural driver never changes. The identity security team polices IAM and SAML. The data team polices pipeline runtime. Mage sits in the seam between them, holding production credentials, and neither team owns its auth logic. Vendors assume the OAuth library handles it. The library assumes the application handles error branches. Everyone assumes, nobody audits, and the risk is externalized onto whoever runs the instance. The disclosure picture is muddier than the technical one, and that ambiguity is itself a signal. Feedly reports no evidence of a working proof of concept. The Core Group claims exploit material exists. When two credible parties contradict each other on PoC status, the defensible posture is to assume a PoC and act accordingly. The cost of pessimism is a log review. The cost of optimism is a warehouse dump. The advisory is not in CISA KEV. Do not read that as absolution. This bug leaves no brute-force signature. No failed password spray, no credential-stuffing waveform, no lockout events. The session simply appears, born legitimate. That absence of forensic noise is precisely why KEV listings would lag real-world exploitation. You cannot alert on what looks like a normal login. The count of ten authentication-bypass disclosures in twenty-one days is doing rhetorical work, not statistical work. I have been around long enough to distrust a denominator nobody publishes. It could be coordinated research. It could be better detection. It could be a genuine wave. What I know is that the density of the phenomenon is being sold harder than the mechanism is being explained, and those are different currencies. But here is the contrarian read, the one that survives scrutiny while the headline count does not. The story is not that a tool got hacked. The story is that a class of software with the highest permission tier in the enterprise receives the weakest authentication testing. Data orchestrators hold more privilege than most domain controllers and are validated against a test suite that treats OAuth as a checkbox integration, not a security boundary. So treat the patch as the opening event of the incident response, not the close. Patch, then rotate every credential Mage ever touched. Patch, then pull session logs from before the advisory and hunt for sessions created without a matching authentication sequence. Patch, then audit every error branch in your own authentication code for the fail-open pattern that produced this CVE in the first place. A rotation takes an afternoon. A stolen warehouse takes a quarter to discover. There is one structural correction worth more than the incident itself. Stop granting long-lived production credentials to orchestration tools. Short-lived STS tokens, scoped OAuth refresh flows, permission ceilings that expire. The aggregator's power should be revocable by default, not by intervention. The upstream root cause was fixed. The design philosophy that produced it was not. Somewhere right now, another pipeline tool is swallowing an error and issuing a session, and no scanner will catch it, because the flaw lives in what the code does after it already knows something is wrong. Liquidity vanishes. Code remains.