CVE-2026-107177: Express Gateway Information Disclosure

CVE-2026-107177 Overview

CVE-2026-107177 affects Express Gateway through version 1.16.11. The gateway ships with a hardcoded default crypto.cipherKey value of sensitiveKey used to encrypt OAuth 2.0 token secrets stored in the datastore. An attacker who gains read access to the backing Redis datastore can decrypt tokenEncrypted values and combine them with stored token IDs to forge valid bearer tokens for any user. The weakness is tracked under CWE-1394: Use of Default Cryptographic Key and falls under the Hardcoded Credentials and Weak Encryption categories.

Critical Impact
Attackers with Redis read access can decrypt stored OAuth token secrets and impersonate any authenticated user through the gateway.

Affected Products

Express Gateway versions up to and including 1.16.11
Deployments relying on the default crypto.cipherKey value sensitiveKey
Any Express Gateway instance using Redis as the OAuth token datastore

Discovery Timeline

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

Technical Details for CVE-2026-107177

Vulnerability Analysis

Express Gateway encrypts OAuth 2.0 token secrets before persisting them to its datastore. The encryption relies on a cipher key defined in lib/config/system.config.yml under crypto.cipherKey. The default value shipped with the project is the literal string sensitiveKey.

Operators who deploy Express Gateway without overriding this value leave every encrypted token protected by a key that is public knowledge. The encryption and decryption routines in lib/services/utils.js read the key directly from configuration at runtime. An attacker who obtains the ciphertext and knows the default key can recover the plaintext token secret offline.

Root Cause

The root cause is a hardcoded default cryptographic key committed to the Express Gateway source tree. The project treats the key as a configurable value, but the default is a static, well-known string rather than a per-deployment randomly generated secret. Deployments that do not change the default inherit identical cryptographic material across unrelated installations.

Attack Vector

An attacker first needs read access to the Redis datastore that Express Gateway uses for OAuth token storage. This can be achieved through exposed Redis instances, lateral movement within an internal network, backup exfiltration, or compromised credentials. The attacker reads tokenEncrypted fields and the associated token identifiers.

Using the known default cipherKey value sensitiveKey, the attacker decrypts the token secret locally. Combining the decrypted secret with the stored token ID yields a valid bearer token. The attacker then presents the forged bearer token to the gateway and gains access as the impersonated user.

For technical details, see the VulnCheck Advisory for Express Gateway and the referenced system.config.yml and utils.js sources.

Detection Methods for CVE-2026-107177

Indicators of Compromise

Express Gateway configuration where crypto.cipherKey equals sensitiveKey or is absent from overrides.
Redis instances backing Express Gateway that are reachable from untrusted networks or lack authentication.
Unexpected bearer tokens appearing in gateway access logs that do not correspond to recent user authentications.
Access to protected upstream APIs from source IPs that have never previously authenticated to the gateway.

Detection Strategies

Audit all Express Gateway deployments for the literal string sensitiveKey in system.config.yml or environment-provided overrides.
Review Redis access logs for connections originating from hosts outside the expected gateway tier.
Correlate OAuth token issuance events with subsequent token use to flag tokens used from previously unseen clients.
Scan configuration management repositories and container images for the default cipherKey value.

Monitoring Recommendations

Enable authentication, TLS, and network segmentation controls on Redis and alert on policy violations.
Capture gateway authentication telemetry in a SIEM and alert on bearer tokens used outside their normal issuance context.
Monitor for configuration drift that reintroduces default cryptographic values in Express Gateway deployments.

How to Mitigate CVE-2026-107177

Immediate Actions Required

Replace the default crypto.cipherKey value with a per-deployment, cryptographically random secret of adequate length.
Rotate all existing OAuth 2.0 tokens and client secrets after changing the key so previously encrypted material is invalidated.
Restrict network access to the Redis datastore and require authentication and TLS for all client connections.
Audit historical Redis access and gateway logs for signs of unauthorized reads or token misuse.

Patch Information

No fixed version was listed in the NVD record at the time of publication. Monitor the Express Gateway GitHub repository and GitHub Issue #1078 for upstream remediation guidance. Until a patched release is available, operators must manually override the default cipherKey and harden datastore access.

Workarounds

Override crypto.cipherKey in system.config.yml or through environment-specific configuration with a unique random value per deployment.
Store the replacement key in a secrets manager rather than in source-controlled configuration files.
Isolate the Redis datastore on a private network segment and enforce ACLs that limit access to the gateway process only.
If OAuth 2.0 is not required, disable the OAuth token flows in Express Gateway to remove the exposure.

bash

# Configuration example
# Generate a strong random key and set it via environment or system.config.yml
export EG_CRYPTO__CIPHERKEY="$(openssl rand -base64 48)"

# system.config.yml override
# crypto:
#   cipherKey: ${EG_CRYPTO__CIPHERKEY}
#   algorithm: aes256
#   saltRounds: 10