Threat Intelligence Report — CVE-2026-90474

Executive Summary

CVE-2026-90474 is an authentication bypass affecting the embedded OAuth 2.0 authorization server shipped inside MCPHub prior to version 1.0.32. In affected deployments, OAuth client authentication is disabled by default and PKCE enforcement is optional, meaning the authorization server accepts token redemptions without a client secret or code verifier. An attacker who intercepts a valid authorization code can exchange it for an access token and impersonate the victim principal — including whatever privileges the victim account holds in MCPHub and any downstream MCP server integrations it governs.

The vulnerability carries a CVSS 3.1 base score of 6.8 (Medium) with the vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. The elevated complexity and user-interaction components reflect the fact that exploitation requires the attacker to first obtain an authorization code (typically via interception, referrer leak, log exfiltration, or a co-resident malicious application), rather than triggering the flaw in an unauthenticated single-shot request. Impact is high-confidentiality and high-integrity, with no direct availability impact. No EPSS score has been published by FIRST.org, no CISA KEV listing exists, and no public exploit or Nuclei template has been released. The vendor has shipped a fix in 1.0.32, but no tracked patch source has independently corroborated the release, so posture should assume unpatched by default until verification.

Technical Analysis

Vulnerability Class

This is a classical OAuth 2.0 authorization-server misconfiguration mapped to CWE-287 — Improper Authentication, with strong overlap into CWE-306 — Missing Authentication for Critical Function and the broader OAuth 2.0 Security Best Current Practice family of "public client" abuses. The NVD description is unusually specific on two root causes:

1. Client authentication is disabled by default. In a properly-configured confidential-client flow, the authorization server requires the token endpoint request to include a client_secret (or any accepted client authentication mechanism, e.g. HTTP Basic, private_key_jwt, mTLS). When client authentication is disabled by default, the token endpoint will accept a redemption request that identifies only the client_id. Everyone in possession of the client_id is effectively a valid client — and client_id values are, by design, not secret.

2. PKCE enforcement is optional. PKCE (Proof Key for Code Exchange, RFC 7636) binds the authorization request to the token request via a per-session code_verifier whose hash (code_challenge) was presented at /authorize. When the server treats PKCE as optional rather than mandatory for public clients, an attacker holding an intercepted code can redeem it without the verifier. The only remaining protection — the redirect-URI binding and the one-time-use property of the code — becomes the sole barrier, and redirect-URI validation in embedded/self-hosted OAuth servers is frequently loose.

The combination of (1) and (2) collapses the standard authorization-code interception protections to near zero: the code becomes a bearer credential redeemable by anyone who captures it before the legitimate client does.

Attack Surface

The attack surface is the embedded OAuth 2.0 authorization server inside MCPHub, exposed over the network (AV:N). MCPHub instances that expose their OAuth endpoints to the internet — or to a shared tenant network — are reachable. Because MCPHub mediates Model Context Protocol servers, the OAuth server is not a peripheral component: tokens issued by it are the credential material that grants access to MCP server integrations (tool invocations, upstream data sources, agent context stores). A compromised token is therefore not just a session cookie — it is delegated authority over downstream tool access.

Why the Component-Level Detail Is Unavailable

The NVD description does not name specific HTTP parameters, internal function names, class names, or URL paths beyond the standard OAuth 2.0 constructs (authorization code, access token, client secret, PKCE verifier). We therefore restrict the technical narrative to the protocol-level mechanism and the two explicitly-stated misconfigurations. Any claim beyond that (e.g., a specific endpoint path, a particular Go/Node/Python function) would be speculation and is deliberately omitted.

Protocol-Level Mechanism

A correct authorization-code flow proceeds as:

GET /authorize?response_type=code&client_id=...&redirect_uri=...&code_challenge=...
   -> 302 redirect_uri?code=AUTHORIZATION_CODE

POST /token
   client_id=...&client_secret=...&grant_type=authorization_code
   &code=AUTHORIZATION_CODE&redirect_uri=...&code_verifier=...
   -> {"access_token":"...", ...}

In CVE-2026-90474, MCPHub's server omits the two underlined checks. Therefore:

POST /token
   client_id=...&grant_type=authorization_code&code=AUTHORIZATION_CODE
   -> {"access_token":"...", ...}      # accepted with neither secret nor verifier

The exploitation primitive is the redeemability of an intercepted authorization code by an unauthenticated third party.

Exploitation Scenarios

Note: No public PoC or exploit code is available for CVE-2026-90474. The following chain is inferred from the vulnerability class (OAuth 2.0 auth-code interception + missing client auth + optional PKCE) and the explicit statements in the NVD description. No specific function names, file paths, or parameter names beyond the standard OAuth 2.0 vocabulary given in the description are asserted.

Step 1 — Reconnaissance / Target Identification

The attacker identifies reachable MCPHub instances prior to 1.0.32. Because the OAuth authorization server is embedded, the identifying markers are MCPHub's HTTP responses and any OAuth discovery/metadata documents the deployment exposes. Shodan queries such as http.title:"MCPHub" or http.html:"MCPHub" enumerate candidate hosts; in shared-network or multi-tenant setups, the attacker may already have a foothold that can observe OAuth traffic in transit. The attacker must determine: (a) that the instance is running a version < 1.0.32, and (b) which OAuth clients are registered and use the authorization-code flow.

Step 2 — Triggering the Flaw Class

The attacker does not exploit a malformed request; they exploit the absence of enforcement. Two conditions must coincide:

• The authorization server issues a code to a legitimate client during a victim-initiated login.
• The attacker obtains that code. The NVD description lists interception as the acquisition method (UI:R, AC:H). Plausible interception vectors consistent with the class include: an open redirect or referrer-leak on the redirect URI, a logging system that records the code query parameter, a malicious or compromised client registered against the same server, or an on-path observer on plaintext/weak-TLS deployments.

Step 3 — Redemption (Vulnerability-Class Level)

The attacker submits a token-endpoint request (grant_type=authorization_code) containing the captured code and client_id. Because client authentication is disabled by default, the absence of a client_secret is not fatal. Because PKCE enforcement is optional, the absence of the code_verifier is not fatal. The server issues a valid access_token. No request forgery, no injection, no buffer manipulation — the flaw is purely a missing check.

Step 4 — Post-Exploitation Impact

Possession of the access token yields the victim's privileges (C:H/I:H). In an MCPHub context that means the attacker inherits the victim's MCP session: the ability to invoke the same MCP servers, read the same tool outputs, and perform the same actions the victim account is authorized to perform. Because authorization codes are single-use, timing matters — the attacker races the legitimate client, which is why AC:H is appropriate. A successful race yields durable access until token expiry or explicit revocation.

Attacker Requirements

Impact Assessment

Confidentiality: High. The token grants read access to everything the victim identity can read through MCPHub and the MCP servers it brokers — which in agentic deployments frequently includes tool outputs, retrieved documents, and connected data sources.

Integrity: High. The same token authorizes tool invocations. An attacker holding a delegated token can cause the victim's agents to execute actions, write data, or trigger downstream workflows under the victim's identity. In environments where MCP servers hold credentials for SaaS APIs (Git repositories, ticketing systems, CI), the blast radius extends well beyond MCPHub itself.

Availability: None (per CVSS). No direct denial of service; the scope is unchanged (S:U), meaning the vulnerable component and the impacted component are the same security authority — the authorization server and the resources it protects.

Blast Radius. Every MCPHub deployment < 1.0.32 that uses the embedded OAuth authorization server with the default configuration is in scope. Because defaults are the issue, default installations are vulnerable and only explicit hardening (enabling client authentication, forcing PKCE) mitigates the flaw prior to upgrade. Multi-tenant MCPHub deployments compound the risk: one compromised token is one compromised tenant, but an interception capability often spans tenants.

Business Impact. MCPHub is used to centralize and mediate MCP tool access for AI agents. A forged delegated token therefore exposes the organization's agentic supply chain: any action an AI agent can take on behalf of a user becomes an action an attacker can take silently, with attribution falling on the legitimate user.

Detection Guidance

Detection for this CVE is challenging because the malicious token request is syntactically valid — it simply omits fields a correct client would include. Detection must therefore key on the absence of expected parameters alongside presence of grant_type=authorization_code, and on anomalies in the code-redemption timeline (two redemptions of the same code, or a redemption from an unexpected source).

Sigma Rule

title: MCPHub OAuth Authorization Code Redeemed Without Client Authentication or PKCE
id: 8f4c1e2a-9d3b-4a77-8b21-mcphub90474
status: experimental
description: Detects token endpoint requests to MCPHub's embedded OAuth 2.0
    authorization server that redeem an authorization code without a client_secret
    and without a code_verifier, exploiting CVE-2026-90474.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-90474
author: valtersit.com
date: 2026-01-01
tags:
    - attack.t1078
    - attack.t1550
    - cve.2026.90474
logsource:
    category: webserver
    product: mcphub
detection:
    selection_grant:
        cs-method: 'POST'
        cs-uri-query|contains: 'grant_type=authorization_code'
    selection_missing_auth:
        cs-uri-query|contains: 'code='
    filter_client_secret:
        cs-uri-query|contains: 'client_secret='
    filter_pkce:
        cs-uri-query|contains: 'code_verifier='
    condition: selection_grant and selection_missing_auth and not filter_client_secret and not filter_pkce
falsepositives:
    - Public native clients configured to legitimately use PKCE-only flows
      with a registered public client that still sends code_verifier
    - Test harnesses
level: high

YARA Rule

YARA is not naturally suited to network-resident OAuth logic; the rule below targets the MCPHub component's default configuration artifact on disk. It is written conservatively — it can only fire where a configuration file that references the relevant OAuth settings is present.

rule CVE_2026_90474_MCPHub_OAuth_Misconfiguration
{
    meta:
        author = "valtersit.com"
        description = "Detects MCPHub configuration artifacts consistent with CVE-2026-90474 defaults (client auth disabled, PKCE optional)"
        cve = "CVE-2026-90474"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-90474"
        date = "2026-01-01"
        severity = "high"

    strings:
        $oauth = "oauth" ascii nocase
        $client_auth_off = "client_auth" ascii nocase
        $pkce = "pkce" ascii nocase
        $mcphub = "mcphub" ascii nocase

    condition:
        filesize < 1MB and
        $mcphub and
        $oauth and
        ($client_auth_off or $pkce)
}

Suricata IDS Rule

Detects a token-endpoint POST that carries grant_type=authorization_code and a code= value while omitting client_secret and code_verifier. MCPHub's exact URI path is not specified in the CVE record, so the rule matches on the protocol-level body parameters rather than a single path. Operators should narrow with the site-specific http_uri once the deployment path is known.

alert http any any -> any any (msg:"CVE-2026-90474 MCPHub OAuth authorization code redeemed without client_secret or PKCE verifier"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"grant_type=authorization_code"; content:"code="; nocase; pcre:"/(?=.*grant_type=authorization_code)(?!.*client_secret=)(?!.*code_verifier=)/sR"; classtype:attempted-user; reference:cve,2026-90474; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-90474; sid:9047401; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01, attack_target Server, deployment Perimeter, confidence Medium;)

Note: the negative lookahead PCRE above is a heuristic pattern intended to flag token bodies lacking both client_secret and code_verifier; tune in staging before production deployment.

Elastic Detection

EQL query against web access logs shipped into Elastic. It correlates a successful code-issuing redirect with a subsequent token request from a differing source IP that lacks the expected verifier.

sequence by user.name, client.ip with maxspan=5m
  [ network where url.path : "*" and url.query : "*code=*" and url.query : "*response_type=code*" ]
  [ network where http.request.method == "POST" and
      url.query : "*grant_type=authorization_code*" and
      url.query : "*code=*" and
      not url.query : "*client_secret=*" and
      not url.query : "*code_verifier=*" ]

Suppression guidance: most legitimate confidential clients always send client_secret; public clients using PKCE always send code_verifier. A POST that omits both is the CVE-specific signal.

Splunk SPL Query

Correlates /authorize redirects (source of the code) with token endpoint POSTs and flags requests missing both authentication elements. Replace index=web and field names (uri, clientip, status) with the schema of your log source.

index=web sourcetype=access_combined
| eval uri_decoded = urldecode(uri)
| where match(uri_decoded, "response_type=code") OR (match(uri_decoded,"grant_type=authorization_code") AND match(uri_decoded,"code="))
| eval has_secret = if(match(uri_decoded,"client_secret="),1,0)
| eval has_verifier = if(match(uri_decoded,"code_verifier="),1,0)
| eval grant_type_flow = if(match(uri_decoded,"grant_type=authorization_code"),1,0)
| where grant_type_flow=1 AND has_secret=0 AND has_verifier=0
| stats count min(_time) as first_seen max(_time) as last_seen values(clientip) as src_ips by uri
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Secondary hunt: two token endpoint POSTs referencing the same code= value within a short window (indicates the attacker raced the legitimate client).

index=web sourcetype=access_combined uri=*grant_type=authorization_code*
| rex field=uri "code=(?<auth_code>[^&]+)"
| stats count dc(clientip) as distinct_ips values(clientip) as ip_list by auth_code
| where count > 1

Wazuh OSSEC Rule

Detects the token redemption pattern in the web server access log monitored by Wazuh.

<group name="mcphub,oauth,cve-2026-90474,">
  <rule id="100474" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <url>grant_type=authorization_code</url>
    <regex type="pcre2">code=[^&amp;]+(?!.*client_secret)(?!.*code_verifier)</regex>
    <description>CVE-2026-90474: MCPHub OAuth authorization code redeemed without client_secret and without PKCE code_verifier</description>
    <mitre>
      <id>T1078</id>
      <id>T1550</id>
    </mitre>
    <group>authentication_bypass,</group>
  </rule>

  <rule id="100475" level="13">
    <if_sid>100474</if_sid>
    <same_source_ip />
    <description>CVE-2026-90474: repeat MCPHub OAuth code redemption from same source - possible automated exploitation</description>
    <group>authentication_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch source tracked by our feeds has independently confirmed a fix. The NVD description names 1.0.32 as the version boundary, but that alone is not sufficient evidence to treat 1.0.32 as a verified, reviewed fix. Treat all versions < 1.0.32 as presumed vulnerable and validate the fix before relying on the version number.

1. Immediate Mitigations (apply before or pending verified patch)

• Enable client authentication. Configure the embedded OAuth authorization server to require client authentication on the token endpoint (or, if it lacks a toggle, front the endpoint with a reverse proxy that rejects token requests missing a client secret / mTLS client cert).
• Force PKCE. Ensure the server rejects authorization-code redemptions that do not carry a code_verifier matching the previously presented code_challenge. Where configuration cannot enforce this, use a proxy or middleware layer that does.
• Reduce code exposure. Restrict redirect URIs to exact, pre-registered HTTPS values; disable any open-redirect behavior; strip fragment/query leakage via Referrer-Policy.
• Harden logging. Ensure authorization codes are never written to application, proxy, or WAF logs in cleartext.
• Network exposure. Remove MCPHub's OAuth endpoints from public internet reachability where possible; require VPN or zero-trust access for OAuth flows.

2. Patch / Upgrade

• Upgrade to MCPHub 1.0.32 or later on a staging instance first, and verify the two preconditions independently: (a) confirm the token endpoint now requires client authentication; (b) confirm PKCE is enforced for public clients.
• Validate that the upgrade does not alter existing client registrations, redirect URIs, or scopes.
• Invalidate all outstanding refresh and access tokens issued under the vulnerable configuration and force re-authentication for privileged principals.
• Rotate any downstream SaaS or MCP server credentials that were reachable through tokens issued while the flaw was live.

3. Long-Term Hardening

• Default-secure posture: treat any "authentication optional" toggle as a defect and pin configuration to fail closed.
• Standards alignment: adopt OAuth 2.0 Security Best Current Practice (draft/current), which mandates PKCE for all clients using the code flow, not only public clients.
• Continuous verification: integrate automated OAuth conformance testing (e.g. against the OAuth 2.0 security test suite) into CI for any authorization server MCPHub embeds.
• Monitoring: keep the detection rules above enabled permanently — this class of misconfiguration can recur.
• Dependency review: if MCPHub embeds a third-party OAuth library, track that library's advisories independently of MCPHub's own release cadence.

References

1. NVD — CVE-2026-90474 — https://nvd.nist.gov/vuln/detail/CVE-2026-90474
2. MITRE CWE-287 — Improper Authentication — https://cwe.mitre.org/data/definitions/287.html
3. RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients (PKCE) — https://www.rfc-editor.org/rfc/rfc7636
4. OAuth 2.0 Security Best Current Practice (IETF draft / current) — https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
5. CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-90474 is not listed as of this report)

Threat actor / exploit-in-the-wild status: No known threat actor campaigns, public exploit code, Nuclei templates, or in-the-wild exploitation evidence are associated with CVE-2026-90474 at the time of writing. First.org has not yet assigned an EPSS score. Continued monitoring is recommended, particularly given the general activity around OAuth misconfigurations in AI-agent-adjacent tooling.