An HTTP request is a small thing.
GET /api/v1/oauth/callback?provider=null. No authorization code. No state parameter. No session cookie. No credentials of any kind.
On any Mage OSS deployment at or below version 0.9.80, that request returns an authenticated session. Not a redirect to a login page. Not a 401. Not a 500 with a stack trace. A session — signed, valid, and carrying whatever the instance had been configured to reach: the S3 access key, the Snowflake warehouse password, the Salesforce OAuth token, the secrets bound to ML workflow steps. The OAuth library did its job. It saw that the named provider did not exist and returned an error condition. Then the error handler — written by a team that understood authentication as a feature to be integrated rather than a boundary to be enforced — declined to stop. Control flowed past the error, into the branch that mints sessions, and the session was minted.
CVSS 9.8. Network exploitable, low complexity, no privileges required, no user interaction. The score is not inflated. It is the arithmetic of a system that answered a question nobody should have been able to ask, and answered it with a yes.
What unsettles me is not the severity. It is the shape of the defect. I have spent years arguing that trust is a protocol, not a promise, and here is a case where the protocol was present, the detection logic worked, and the only thing missing was a single word that would have ended the function. The bug is not a failure of cryptography or of OAuth or even of intent. It is a failure of control flow in the one place where control flow is the entire security model.
Context: why a data pipeline tool holds the keys to everything
Mage is an open-source data pipeline orchestration platform — the category that includes Airflow, Dagster, and Prefect. Its job is unglamorous and total: schedule tasks, resolve dependencies, retry failures, move data from sources to sinks. To do that job it must authenticate against everything it touches. It does not merely read your warehouse. It holds the credential that reads your warehouse, indefinitely, in a configuration store, on an always-on host.
That architectural fact matters more than the CVE. Mage produces no data of its own. It is a credential aggregator — a relay where the trust of five separate systems is concentrated into a single process. The security economics of this arrangement are well understood in theory and almost never accounted for in practice. When an identity provider is breached, the attacker receives identity. When a credential aggregator is breached, the attacker receives data, plus the credentials that reach the data, plus the credentials that reach everything those credentials were reused for. The loss is not additive. It compounds.
OAuth 2.0's callback endpoint is the most exposed surface in this arrangement. It is the one route that must accept unauthenticated inbound traffic by design, because the whole point of the redirect is that the user arrives without a session. Every security property of the flow — state binding, code verification, provider validation, PKCE — is a check that must be performed on a request the system has already agreed to trust provisionally. That is a narrow, hostile place to write code.
The classification here is precise: CWE-390, Detection of Error Condition Without Action. Not CWE-287, improper authentication, which describes a check that was written wrongly. CWE-390 describes a check that worked and was then ignored. The distinction is not academic. A wrongly written check is a bug. An ignored check is a design philosophy, and design philosophies replicate.
The affected range is everything at or below 0.9.80. The fix landed as commit 76c4f46 across two pull requests, #6204 and #6205. Two PRs for one vulnerability is the detail I would put at the top of an audit memo, and I will return to why.
Core: what actually failed, and why the failure is a class rather than an instance
Reconstructing the path from the disclosure details, the sequence is unambiguous.
