CVE-2026-12985

Executive Summary

CVE-2026-12985 is a redirect URI validation bypass in Mattermost's Dynamic Client Registration (DCR) handling, affecting versions 11.7.x <= 11.7.7, 11.8.x <= 11.8.4, and 11.9.x <= 11.9.0. The server failed to validate OAuth redirect URIs by URL component, instead matching glob patterns against the raw URI string, which allows a remote unauthenticated attacker to register an OAuth client whose attacker-controlled callback host bypasses the configured redirect URI allowlist. Successful abuse can redirect authorization codes or tokens to an attacker-controlled endpoint, enabling account access and integrity impact (CVSS 6.8, C:H/I:H), contingent on victim interaction during an OAuth authorization flow.

Technical Analysis

CWE-601 (URL Redirection to Untrusted Site / Open Redirect class) is triggered here in the context of OAuth 2.0 Dynamic Client Registration. Per the NVD description, Mattermost "failed to validate Dynamic Client Registration redirect URIs by URL component (matching glob patterns against the raw URI string instead)." This is the core defect: the allowlist check operated on the unparsed URI string rather than on discrete URL components (scheme, host, port, path, query). Because allowlisting was evaluated against a raw string using glob matching, an attacker can construct a redirect URI that embeds an allowlisted host/path suffix inside the query string. A naive glob match against the whole string will see the allowlisted suffix and pass, but an OAuth authorization server will, at authorization time, send the user agent to the actual attacker-controlled host indicated by the URI's authority component — not to a host that merely appears as query-string content.

The practical consequence is that a remote, unauthenticated attacker can register an OAuth client with a callback host they control while satisfying the string-based allowlist, thereby placing the attacker in a position to receive a redirected authorization response (code or token) intended for a legitimate client. No public PoC is available and the source contains no specific parameter names, endpoints, or function names beyond the DCR redirect URI concept itself, so lower-level implementation details (exact handler names, request field names, or code paths) cannot be asserted and are deliberately not invented here. Class-level mechanism only: string-pattern allowlist bypass → attacker-controlled redirect target within OAuth flows.

The CVSS vector reflects this: AV:N (network), AC:H (attack complexity high, reflecting the crafted-URI and flow-interaction conditions), PR:N (no privileges required to register a client), UI:R (victim must interact by initiating/authorizing a flow), S:U (scope unchanged), C:H, I:H, A:N. EPSS is 0.00280 (~20.5th percentile), indicating low predicted exploitation likelihood at time of writing; there is no CISA KEV listing and no public exploit or Nuclei template.

Exploitation Scenarios

The following chain is inferred strictly from the vulnerability class (CWE-601 / allowlist bypass in DCR) and the NVD description; no public PoC exists and no specific internal identifiers are asserted.

1. Reconnaissance / target identification: The attacker locates an internet-facing Mattermost deployment in an affected version range. Mattermost exposes an OAuth-based integration surface; DCR permits client registration. The attacker needs the deployment URL and must understand which redirect URI host/path values are allowlisted (these can often be discovered through error messages, documentation, or trial registration attempts).

2. Triggering the flaw: The attacker sends a Dynamic Client Registration request that supplies a redirect URI crafted so that an allowlisted host/path suffix appears inside the query string component while the actual authority (host) is attacker-controlled. Because the server validates the raw URI string with glob patterns rather than parsing by URL component, the crafted URI passes the allowlist check and the OAuth client is registered with an attacker-controlled callback host.

3. Execution method (class-level): With the malicious client registered, the attacker induces a victim to begin the OAuth authorization flow for that client. The victim authenticates/authorizes, and the authorization response (code or token) is delivered to the attacker-controlled redirect target. This step requires victim interaction (UI:R), consistent with the CVSS vector.

4. Post-exploitation impact: Intercepted authorization artifacts can be used to obtain tokens and access resources in the victim's Mattermost context, yielding high confidentiality and integrity impact per the CVSS subscores. Because registration is remote and unauthenticated (PR:N), the attacker can attempt this repeatedly against multiple users.

Note: No public PoC available; attack chain is inferred from the vulnerability class. Do not expect a specific exploit artifact; TTPs are generic to OAuth redirect URI allowlist bypass.

Impact Assessment

Business impact centers on unauthorized access to Mattermost workspaces and communications, which often contain sensitive operational, security, and business data. The CVSS base score of 6.8 (medium) with C:H/I:H indicates that a successful exploitation can expose and modify data within an affected user's scope. The attack surface is the OAuth DCR / authorization flow, which is network-reachable (AV:N) but requires crafted conditions and user interaction (AC:H, UI:R). Blast radius is bounded by the scope granted to the abused OAuth client and by which users can be induced to authorize, but because the attacker registers the client without authentication, the barrier to entry is low. Integrity impact (I:H) suggests potential for actions performed as the victim, including integration-related manipulation. Availability is unaffected (A:N).

Detection Guidance

Sigma Rule

title: Mattermost OAuth Dynamic Client Registration with Suspicious Redirect URI
id: 7f3b9c1e-4a2d-4b6e-9c1f-202612985a01
status: experimental
description: Detects DCR requests embedding an allowlisted host/path suffix inside the query string of a redirect URI (allowlist bypass pattern).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-12985
author: Valters IT Threat Intelligence
date: 2026-01-01
logsource:
  product: mattermost
  category: application
detection:
  selection_method:
    http.method: 'POST'
  selection_endpoint:
    url|contains: 'register'
  selection_pattern:
    request_body|re: '(?i)redirect_uris.{0,256}https?://[^\s"&]+\?(?:[^"&\s]*)(?:localhost|127\.0\.0\.1|mattermost)[^\s"]*'
  condition: selection_method and selection_endpoint and selection_pattern
fields:
  - src_ip
  - request_body
  - user_agent
falsepositives:
  - Legitimate clients whose allowed redirect URI genuinely contains those tokens (rare)
level: medium

YARA Rule

rule CVE_2026_12985_Mattermost_DCR_Redirect_Bypass
{
    meta:
        description = "Detects crafted redirect URIs that place an allowlisted host/path suffix inside the query string to bypass Mattermost DCR redirect URI allowlisting (CVE-2026-12985)"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-12985"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $dcr = "redirect_uris" ascii nocase
        $cb  = "callback" ascii nocase
        $q   = "?" ascii
        $h1  = "http://" ascii nocase
        $h2  = "https://" ascii nocase

    condition:
        ($dcr or $cb) and ($h1 or $h2) and $q
}

Note: YARA is content-oriented and cannot reliably evaluate URL component semantics. The rule above flags DCR payloads containing redirect URI structures for downstream inspection; the query-component bypass pattern is best enforced in Sigma/Elastic/Splunk or via a URL parser, not YARA alone.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-12985 Mattermost DCR redirect_uris query-string allowlist bypass attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"register"; http.request_body; content:"redirect_uris"; nocase; pcre:"/redirect_uris[^\r\n]{0,300}https?:\/\/[^\s\"&]+\?[^\r\n\"]*(localhost|127\.0\.0\.1|mattermost)/i"; classtype:attempted-recon; sid:2026129851; rev:1; metadata:created_at 2026_01_01, reference:url,nvd.nist.gov/vuln/detail/CVE-2026-12985;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [ network where http.request.method == "POST" and
      url.path : "*register*" and
      http.request.body.content : "*redirect_uris*" ]
  [ network where http.request.method == "POST" and
      http.request.body.content : "*redirect_uris*" and
      http.request.body.content : r"""https?://[^\s"\&]+\?[^\s"\&]*(localhost|127\.0\.0\.1|mattermost)""" ]

Splunk SPL Query

index=mattermost OR index=webproxy sourcetype=access_combined OR sourcetype=mattermost:audit
| eval raw = coalesce(request_body, uri_query, url, _raw)
| where match(raw, "(?i)redirect_uris.{0,300}https?://[^\\s\"&]+\\?[^\\s\"&]*(localhost|127\\.0\\.0\\.1|mattermost)")
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as src_ips by user, client_id, raw
| where count >= 1
| sort - count

Wazuh OSSEC Rule

<group name="mattermost,web,oauth,">
  <rule id="2026129" level="10">
    <decoded_as>json</decoded_as>
    <field name="http.method">POST</field>
    <field name="url">/register</field>
    <regex type="pcre2" field="request_body">redirect_uris[^\r\n]{0,300}https?:\/\/[^\s"&]+\?[^\r\n"]*(localhost|127\.0\.0\.1|mattermost)</regex>
    <description>CVE-2026-12985: Possible Mattermost DCR redirect_uris allowlist bypass via query-string suffix</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>oauth_abuse,attack,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix or workaround is documented in the provided data. Treat detection rules as the primary control until a fix is available.

1. Immediate mitigations:

• Restrict network access to OAuth/DCR endpoints to trusted networks or require additional authentication where possible.
• If Dynamic Client Registration is not required, disable it. If required, harden the redirect URI allowlist to use exact, decomposed URL-component matching (scheme+host+path), rejecting any allowlisted token that appears only within a query string.
• Monitor Mattermost advisory MMSA-2026-00700 for an official fix and interim guidance.
• Apply the detection rules in this report (Sigma, Suricata, Elastic, Splunk, Wazuh) to alert on DCR requests containing suspicious redirect_uris.

2. Patch/upgrade steps:

• No fixed version is identified in provided data. When the vendor publishes a patched release for the 11.7.x, 11.8.x, and 11.9.x lines, upgrade to that release and verify DCR validation now parses redirect URIs by URL component.
• Stage in a test environment and validate that legitimate OAuth integrations still resolve callbacks correctly.

3. Long-term hardening:

• Enforce strict URL-component parsing for all redirect URI validation (not glob/regex against the raw string).
• Enforce HTTPS-only redirect URIs, exact-host matching, and disallow wildcards in callback hosts.
• Use PKCE and short-lived authorization codes; bind codes to the registered client and redirect URI.
• Centralize OAuth/DCR logging and correlation in the SIEM; alert on newly registered clients and redirect URI changes.
• Periodic review of registered OAuth clients to detect and remove unexpected entries.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-12985
• Mattermost Advisory ID: MMSA-2026-00700 (see Mattermost security advisories)
• CWE-601: URL Redirection to Untrusted Site ('Open Redirect'): https://cwe.mitre.org/data/definitions/601.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• EPSS data: https://www.first.org/epss/ (score 0.00280, ~20.5th percentile)

No threat actor campaigns or exploit-in-the-wild evidence are associated with CVE-2026-12985 in the provided data; CISA KEV status is NO and no public PoC or Nuclei template is available.