CVE-2026-107162: Express Gateway OAuth 2.0 Auth Bypass

CVE-2026-107162 Overview

CVE-2026-107162 is an authentication bypass vulnerability in Express Gateway versions through 1.16.11. The flaw resides in the OAuth 2.0 refresh_token grant handler, which fails to validate the token secret or verify that the refresh token belongs to the issuing client. An attacker holding any valid client credentials and the identifier portion of another user's refresh token can mint that user's access token. The newly issued token grants full impersonation against any oauth2-protected API fronted by the gateway. The weakness is tracked under CWE-287: Improper Authentication.

Critical Impact
Attackers with low-privilege client credentials can impersonate arbitrary users and access their protected API resources through the gateway.

Affected Products

Express Gateway versions through 1.16.11
Deployments exposing the OAuth 2.0 refresh_token grant via oauth2-server.js
Downstream APIs protected by the oauth2 policy in Express Gateway

Discovery Timeline

2026-10-07 - CVE-2026-107162 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-107162

Vulnerability Analysis

Express Gateway is a Node.js API gateway that includes a built-in OAuth 2.0 authorization server implemented in lib/policies/oauth2/oauth2-server.js. The server supports the standard grant types defined in RFC 6749, including refresh_token. When a client presents a refresh token, the gateway should verify both the integrity of the token and the identity of the client that originally received it.

In affected releases, the refresh_token handler delegates lookup to token.service.js but omits two critical checks. The service does not validate the token secret component, and it does not compare the stored consumerId against the authenticating client. As a result, any authenticated client can trade the public identifier portion of another user's refresh token for a fully valid access token bound to the victim's identity.

Root Cause

The root cause is incomplete authentication logic in the token exchange path. The handler at lines 221-247 of oauth2-server.js and the lookup logic at lines 100-136 of token.service.js treat the refresh token identifier as sufficient proof of possession. Neither the cryptographic secret portion nor the issuing client binding is enforced, violating the OAuth 2.0 requirement in RFC 6749 §10.4 to bind refresh tokens to the client to which they were issued.

Attack Vector

Exploitation requires network reachability to the gateway's token endpoint and a valid set of client credentials. An attacker also needs the identifier portion of a victim's refresh token, which can leak through logs, backups, referer headers, or secondary vulnerabilities. The attacker then issues a POST to /oauth2/token with grant_type=refresh_token, the harvested identifier, and their own client credentials. The gateway responds with a valid access token for the victim, enabling impersonation against any oauth2-protected upstream API. See the VulnCheck advisory for the complete technical write-up.

No verified exploitation code is published. Refer to the
VulnCheck advisory and GitHub Issue #1076 for the technical
description of the token exchange flow.

Detection Methods for CVE-2026-107162

Indicators of Compromise

Successful grant_type=refresh_token responses where the issued access_token is bound to a user_id that differs from any user previously associated with the authenticating client_id.
Repeated token endpoint requests from a single client identifier presenting refresh tokens that it was never issued.
Downstream API audit records showing user-scoped actions performed under access tokens minted by unexpected client identifiers.

Detection Strategies

Instrument the Express Gateway OAuth2 policy to log the client_id, submitted refresh_token identifier, and resolved consumerId for every token exchange, then alert on mismatches.
Correlate gateway access logs with upstream API logs to flag sessions where the acting user and the issuing client do not match historical pairings.
Hunt for anomalous spikes in refresh_token grant usage from service accounts or machine clients that normally use client_credentials.

Monitoring Recommendations

Forward Express Gateway access, admin, and OAuth2 policy logs to a centralized analytics platform for long-term retention and correlation.
Monitor the /oauth2/token endpoint for unusual geographic sources, user agents, or burst patterns indicative of token enumeration.
Track issuance volume per client credential and alert when a single client suddenly mints tokens for a disproportionate number of distinct users.

How to Mitigate CVE-2026-107162

Immediate Actions Required

Inventory all deployments of Express Gateway and identify any instance running version 1.16.11 or earlier with the oauth2 policy enabled.
Rotate all active refresh tokens and client secrets issued by affected gateways to invalidate any tokens that may have been harvested.
Restrict network access to the /oauth2/token endpoint using allowlists or upstream authentication until a fix is deployed.
Review upstream API audit logs for the last several months for signs of impersonation using mismatched client and user identifiers.

Patch Information

No fixed version has been published by the Express Gateway project at the time of NVD disclosure. Track GitHub Issue #1076 and the Express Gateway repository for upstream remediation. The VulnCheck advisory tracks the current patch status.

Workarounds

Disable the oauth2 policy and front Express Gateway with an external OAuth 2.0 authorization server that enforces refresh token binding, such as Keycloak, Ory Hydra, or a managed identity provider.
Shorten refresh token lifetimes and require re-authentication to minimize the window in which a leaked identifier remains valuable.
Deploy a reverse proxy or WAF rule that rejects grant_type=refresh_token requests originating from client identifiers that are not explicitly authorized to use that grant.
Apply a local patch to lib/services/tokens/token.service.js that validates both the token secret and the consumerId of the authenticating client before issuing a new access token.

bash

# Example: block the refresh_token grant at an upstream NGINX proxy
# until an official patch is available
location = /oauth2/token {
    if ($request_method = POST) {
        if ($request_body ~* "grant_type=refresh_token") {
            return 403;
        }
    }
    proxy_pass http://express_gateway_upstream;
}