CVE-2026-111823

Executive Summary

CVE-2026-111823 is a critical authentication weakness (CWE-390) in Mage OSS through version 0.9.80, fixed after commit 76c4f46, where the platform proceeds with session creation upon encountering an unknown OAuth provider. Because the vulnerable logic is reachable pre-authentication over the network with no user interaction, an unauthenticated attacker can likely obtain a valid application session without completing a legitimate OAuth flow. The CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), reflecting potential full compromise of confidentiality, integrity, and availability.

Technical Analysis

CWE-390 ("Detection of Error Condition Without Action") describes a situation in which software detects an error condition — in this case, an OAuth provider that the application does not recognize — but takes no effective corrective action and continues processing. In the context of authentication flows, the security-relevant consequence is that a failed or unverifiable authentication step does not abort the session lifecycle: the application moves forward and establishes a session instead of rejecting the request.

The NVD description states: "Mage OSS through 0.9.80 before 76c4f46 can proceed with session creation upon encountering an unknown OAuth provider." The essential fact is the pass/fail logic inversion: an unknown provider — which should be an immediate rejection condition — is instead tolerated, and a session is created. This is an authentication bypass at the vulnerability-class level, not a memory-safety issue, and not an injection flaw.

Attack surface considerations derivable from the data:

• Reachability: The CVSS vector AV:N/PR:N/UI:N indicates the vulnerable code path is network-reachable and requires neither credentials nor user interaction. The OAuth callback/redirect handling in Mage's authentication subsystem is the natural exposure point for OAuth provider selection and callback processing, but the specific endpoint paths and parameter names are not disclosed in the available description and are therefore not asserted here.
• Authentication boundary: Session creation is the pivot point. Any application feature gated by a Mage session (project workspaces, pipeline authoring/execution, data source access) should be assumed reachable by an attacker who succeeds in forcing session establishment.
• Preconditions: The description does not state whether the attacker must first initiate a legitimate OAuth flow, present a crafted provider identifier, or replay a callback. Insufficient technical detail is available to specify the exact request sequence. The fixed commit identifier (76c4f46) is the authoritative reference for the code change; organizations with source access should diff it to confirm the precise validation logic added.

Because CWE-390 is a missing-action-on-error pattern, defenders should reason about the failure mode: every consumer of OAuth callback state (provider lookup, state/nonce validation, token exchange result) must be treated as trust-boundary logic whose failure must terminate the flow and return an explicit error rather than fall through to session issuance.

Exploitation Scenarios

No public PoC is available. The attack chain below is inferred from the vulnerability class (authentication bypass via unhandled error on unknown OAuth provider) and the NVD description; it deliberately avoids asserting undocumented endpoints or parameters.

1. Reconnaissance / target identification. An attacker enumerates internet-exposed Mage OSS instances (versions ≤ 0.9.80). Mage is typically deployed as a data-pipeline authoring platform, often behind a login/OAuth gate; exposed instances are identifiable by their login and OAuth entry points.
2. Triggering the flaw class. The attacker initiates or manipulates an OAuth authentication attempt such that the application encounters a provider it does not recognize. Rather than rejecting the request at the provider-lookup stage, the vulnerable code (per the NVD description) proceeds with session creation.
3. Execution / payload at class level. Because the bypass is logical rather than payload-based, the "payload" is simply the malformed or unknown-provider authentication request itself. The attacker needs no credentials (PR:N) and no victim interaction (UI:N). If the resulting session is bound to an attacker-controlled identity or an unauthenticated/default context, the attacker gains an authenticated foothold; the exact session contents are not specified in available data.
4. Post-exploitation. With a valid session, an attacker could reach functionality normally restricted to authenticated users of the Mage workspace. Given Mage's role in orchestrating data pipelines and connecting to data sources, meaningful follow-on activity would be expected to center on accessing pipeline definitions and stored credentials and on modifying or executing pipelines. The CVSS impact subscores (C:H/I:H/A:H) indicate the maintainers assess potential total loss of confidentiality, integrity, and availability, but the description does not enumerate specific post-auth capabilities.

Key unknowns that defenders should resolve during triage: whether the bypass requires a prior valid flow initiation, whether the created session is fully privileged or limited, and whether logs record the "unknown provider" event.

Impact Assessment

• Confidentiality (C:H): An unauthenticated attacker obtaining a session may read assets otherwise protected by the authentication boundary — plausibly workspace data, pipeline definitions, and connection metadata. The description does not enumerate exactly what a forged session can access.
• Integrity (I:H): Session-authenticated write operations (pipeline or configuration changes) would be reachable, supporting tampering with data workflows.
• Availability (A:H): High availability impact is consistent with an attacker able to modify or disrupt processing pipelines.
• Exploitability: AV:N/AC:L/PR:N/UI:N — full marks for network reachability, low complexity, no privileges, no user interaction. The combination with an authentication-boundary failure is why the score reaches 9.8.
• Blast radius: Any Mage OSS deployment ≤ 0.9.80 exposed to untrusted networks. Mage deployments frequently hold high-value credentials for downstream data systems, so compromise of the platform can cascade to connected stores.
• Exploit maturity: No public PoC, no Nuclei template, not in CISA KEV. EPSS is not yet scored by FIRST.org. However, authentication-bypass flaws of this class are typically easy to weaponize once the request sequence is understood, and the 9.8 score makes it an attractive target; treat as high-priority for internet-exposed instances.
• Patch confidence: 0/4 — no patch evidence from tracked sources; only the commit reference (76c4f46) is indicated.

Detection Guidance

Sigma Rule

title: Mage OSS Session Creation via Unknown OAuth Provider (CVE-2026-111823)
id: 3f6c9a2e-7b1d-4c8a-9e2f-1a5d6b8c0e11
status: experimental
description: Detects Mage OSS authentication events where a session is created despite an unrecognized OAuth provider, indicating exploitation of CVE-2026-111823.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-111823
author: valtersit.com threat intelligence
date: 2026/01/01
logsource:
  product: mage
  service: auth
detection:
  selection_session:
    event_type:
      - 'session_create'
      - 'session_created'
      - 'login_success'
  selection_oauth:
    auth_method|contains: 'oauth'
  selection_unknown_provider:
    provider_status:
      - 'unknown'
      - 'unrecognized'
      - 'invalid'
    - 'not_found'
  filter_known:
    provider_known: true
  condition: selection_session and selection_oauth and selection_unknown_provider and not filter_known
falsepositives:
  - Legitimate OAuth provider misconfiguration during onboarding
  - Stale provider registrations removed while sessions were in flight
level: critical
tags:
  - attack.t1190
  - cve.2026-111823

YARA Rule

rule CVE_2026_111823_Mage_Unknown_OAuth_Session
{
    meta:
        description = "Detects Mage OSS source/log artifacts indicating session creation on unknown OAuth provider (CVE-2026-111823)"
        author = "valtersit.com threat intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-111823"
        cve = "CVE-2026-111823"
        severity = "critical"
        date = "2026-01-01"

    strings:
        $oauth     = "oauth" ascii nocase
        $provider  = "provider" ascii nocase
        $unknown   = "unknown provider" ascii nocase
        $unrecog   = "unrecognized provider" ascii nocase
        $session   = "create_session" ascii nocase
        $session2  = "session_created" ascii nocase

    condition:
        uint16(0) == 0x7B7B or true and
        $oauth and $provider and
        ($unknown or $unrecog) and
        ($session or $session2)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-111823 Mage OSS session creation via unknown OAuth provider attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"oauth"; nocase; http.uri; content:"provider"; nocase; http.header; content:"Cookie|3a|"; nocase; threshold: type limit, track by_src, count 5, seconds 60; reference:cve,2026-111823; classtype:attempted-user; sid:2026111823; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=30s
  [network where network.protocol == "http" and
     url.path : "*oauth*" and
     url.path : "*provider*"]
  [authentication where
     event.action : ("session_create" or "session_created" or "login_success") and
     process.name : "*mage*" and not authentication.method : "oauth_success"]

Splunk SPL Query

index=mage sourcetype=mage:auth
  (event_type=session_create OR event_type=session_created OR event_type=login_success)
  (auth_method="*oauth*" OR message="*oauth*")
  (provider_status="unknown" OR provider_status="unrecognized" OR message="*unknown provider*" OR message="*unrecognized provider*")
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as source_ips values(user) as users by host, provider_name, provider_status
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="mage,cve-2026-111823,">
  <rule id="202611823" level="12">
    <if_sid>1000</if_sid>
    <decoded_as>json</decoded_as>
    <field name="event_type">^(session_create|session_created|login_success)$</field>
    <field name="auth_method">oauth</field>
    <field name="provider_status">^(unknown|unrecognized|invalid)$</field>
    <description>CVE-2026-111823: Mage OSS created a session for an unknown OAuth provider - possible authentication bypass</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>authentication_bypass,pci_dss_10.2.4,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED per tracked sources. No vendor fix or workaround is published; no affected-version list or OSV packages are available. The only authoritative reference is commit 76c4f46, which the NVD description indicates resolves the issue in releases after 0.9.80.

1. Immediate mitigations

   • Restrict network access to Mage OSS instances to trusted networks/VPN; do not expose deployments ≤ 0.9.80 directly to the internet.
   • Place the application behind an authenticating reverse proxy or identity-aware gateway so that unauthenticated requests cannot reach Mage's OAuth handling directly.
   • If only one OAuth provider is intended, disable or reject all other provider configurations at the infrastructure layer (proxy/WAF) where feasible.
   • Monitor authentication logs for session creation events tied to unknown/unrecognized providers (see detection guidance).
   • Rotate any credentials or tokens stored in Mage workspaces if unauthorized access is suspected, given the high confidentiality/integrity impact rating.

2. Patch / upgrade steps

   • Obtain the build that incorporates commit 76c4f46 (i.e., code after 0.9.80) and validate the fix in a staging environment before production rollout.
   • Diff the fix against 0.9.80 to confirm that unknown OAuth providers now result in explicit rejection and no session issuance.
   • Track the project's repository and advisories for a tagged release or CVE update, since a formal vendor advisory is not yet evidenced.

3. Long-term hardening

   • Enforce fail-closed design for all authentication state machines: any unrecognized provider, invalid state/nonce, or failed token exchange must terminate the flow.
   • Add automated tests for negative OAuth paths (unknown provider, malformed callback, replay) in CI.
   • Apply least privilege to the service account running Mage and to downstream data-source credentials stored in the platform.
   • Include authentication-bypass classes (CWE-390) in secure code review checklists and threat models.

References

• NVD — CVE-2026-111823: https://nvd.nist.gov/vuln/detail/CVE-2026-111823
• CWE-390: Detection of Error Condition Without Action: https://cwe.mitre.org/data/definitions/390.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• FIRST EPSS (score not yet assigned for this CVE): https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (CVE not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Reference fix commit cited by NVD: 76c4f46 (consult the Mage OSS repository to retrieve the diff)