Mage AI Session Bypass (CVE-2026-111823): Invalid OAuth provider on POST /api/sessions

When “invalid provider” still mints a JWT

CVE-2026-111823 is critical authentication bypass on Mage OSS (mage-ai/mage-ai): POST /api/sessions accepts token + provider, and when the provider name is unknown, vulnerable builds still run user lookup/creation from the JSON email without OAuth verification — then return a normal session JWT (CWE-390, CWE-287, CVSS 3.1 9.8).

Affected through 0.9.80 (confirm patch on your image). Fixed in PR #6204 (76c4f46).

PoC: CVE-2026-111823 on pocbit.org. Default UI/API port: 6789.

Preconditions defenders should track

| Requirement | Why it matters | |-------------|----------------| | require_user_authentication=true | Default on OSS 0.9.78+ — bypass targets authenticated deployments | | X-API-KEY | Public OAuth client key (UI/docs) — not a secret admin key, but required for the API call | | Network reachability to Mage | Often internal MLOps; 6789 exposed to WAN is high risk |

This is not “Mage with auth disabled” only — the bug is trusting session creation when OAuth provider resolution fails open.

Cross-read: API security JWT mistakes, authentication bypass — what to check, how to prioritize critical CVEs.

Defender checklist

| # | Action | Detail | |---|--------|--------| | 1 | Version / commit | Build includes #6204 — PyPI tag alone may lag; verify git SHA in container | | 2 | Exposure | Firewall 6789 to VPN / bastion; no public Mage without SSO hardening | | 3 | Logs | Alert on POST /api/sessions with provider not in your allow-list | | 4 | Keys | Rotate X-API-KEY / OAuth client config after incident suspicion | | 5 | Downstream | Post-auth features (pipelines, file browser, terminal) — review #6205, #6206 too | | 6 | Lab | PoC --mode check --oauth-probe on disposable 0.9.80 stack |

Patch validation

python poc.py --mode check -b http://127.0.0.1:6789 --oauth-probe
python poc.py -b http://127.0.0.1:6789 -e [email protected] --save-token session.json

After upgrade, probe should fail closed (no JWT for provider: invalid).

See safe PoC lab setup.

FAQ

We only use Mage on localhost — safe?

If 6789 is bound to 0.0.0.0 on a cloud VM, treat it like production. Patch anyway.

Is this RCE?

This PoC proves session/API takeover. Further impact depends on Mage features enabled after login — scope IR accordingly.

Bottom line

CVE-2026-111823 is OAuth fail-open on session create — a pattern that shows up whenever auth middleware assumes “provider string present” equals “provider verified.” Deploy #6204, segment 6789, and monitor /api/sessions on every Mage OSS instance in your CVE Detector inventory.