CVE-2026-59955: Apollo ConfigService Auth Bypass Flaw

CVE-2026-59955 Overview

Apollo is a configuration management system designed for microservice architectures. CVE-2026-59955 affects Apollo ConfigService versions prior to 2.5.2 and allows unauthorized access to raw configuration data when AccessKey or management key authentication is enabled. The flaw resides in how requests to /configfiles/raw/{appId}/{clusterName}/{namespace} are parsed. ConfigService extracts the literal string raw as the appId for authentication rather than the actual appId value in the URL path. As a result, ConfigService looks up AccessKey secrets for raw before verifying the request signature and can proceed without signature verification for the target appId. The issue is fixed in version 2.5.2.

Critical Impact
Unauthenticated network attackers can bypass AccessKey authentication and retrieve raw configuration data from any application namespace hosted by Apollo ConfigService.

Affected Products

Apollo Configuration Management System versions prior to 2.5.2
Apollo ConfigService component with AccessKey authentication enabled
Apollo ConfigService component with management key authentication enabled

Discovery Timeline

2026-07-15 - CVE-2026-59955 published to the National Vulnerability Database
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-59955

Vulnerability Analysis

The vulnerability is an input validation flaw [CWE-20] in Apollo ConfigService's authentication filter chain. The ClientAuthenticationFilter was registered against URL patterns /configs/* and /configfiles/*, but the filter's appId extraction logic did not account for the /configfiles/raw/{appId}/... route structure. When a request targets the raw configuration endpoint, the filter treats the URL segment raw as the appId being requested. AccessKey lookup then queries secrets for a non-existent tenant named raw, returns no keys, and the signature verification path is skipped. The request proceeds to the controller, which serves configuration data for the real appId embedded deeper in the path.

Root Cause

The root cause is inconsistent path parsing between the authentication filter and the request handler. The filter and handler disagree on which URL segment identifies the tenant. The authentication logic in AccessKeyUtil did not validate that the extracted appId matched a known application before deciding whether signature verification was required, causing an authentication bypass whenever the lookup returned no configured keys.

Attack Vector

An unauthenticated remote attacker sends an HTTP GET request to /configfiles/raw/{targetAppId}/{cluster}/{namespace} on an exposed Apollo ConfigService instance. The filter extracts raw as the appId, finds no AccessKey secrets for it, and bypasses signature validation. ConfigService returns the raw configuration for {targetAppId}, exposing any secrets, database credentials, or feature flags stored in that namespace.

java

// Patch: apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/ConfigServiceAutoConfiguration.java
    filterRegistrationBean.setFilter(new ClientAuthenticationFilter(bizConfig, accessKeyUtil));
    filterRegistrationBean.addUrlPatterns("/configs/*");
    filterRegistrationBean.addUrlPatterns("/configfiles/*");
+   filterRegistrationBean.addUrlPatterns("/notifications/v2");
    filterRegistrationBean.addUrlPatterns("/notifications/v2/*");

    return filterRegistrationBean;
// Source: https://github.com/apolloconfig/apollo/commit/310809d557e01c6803051736cd525e333ffe00ec

The companion change in AccessKeyUtil.java adds InputValidator to verify that the extracted appId conforms to expected formatting before it is used in the authentication decision, preventing reserved path segments such as raw from being mistaken for tenant identifiers.

Detection Methods for CVE-2026-59955

Indicators of Compromise

HTTP GET requests to /configfiles/raw/{appId}/{cluster}/{namespace} from IP addresses outside your normal Apollo client population.
Access log entries returning HTTP 200 for /configfiles/raw/* without a valid Authorization-Timestamp header or HMAC-SHA1 signature.
Repeated enumeration of different {appId} values in the /configfiles/raw/ path from a single source.

Detection Strategies

Correlate ConfigService access logs against the configured AccessKey inventory and alert when raw endpoint responses occur for applications that have AccessKey enforcement enabled.
Deploy a WAF or reverse-proxy rule that rejects requests to /configfiles/raw/* when authentication headers are missing or malformed.
Compare requesting client identifiers against the appId present in the URL to identify cross-tenant access attempts.

Monitoring Recommendations

Forward Apollo ConfigService access and application logs to a centralized SIEM for retention and query.
Baseline normal request volume to /configfiles/* per source and alert on statistical deviations.
Track AccessKey lookup failures emitted by AccessKeyServiceWithCache and investigate spikes.

How to Mitigate CVE-2026-59955

Immediate Actions Required

Upgrade Apollo to version 2.5.2 or later on all ConfigService nodes.
Restrict network exposure of ConfigService to internal client networks until the upgrade is applied.
Rotate any AccessKey secrets and sensitive configuration values that may have been exposed through the raw endpoint.
Audit ConfigService access logs for prior unauthorized requests to /configfiles/raw/*.

Patch Information

The fix is included in Apollo 2.5.2. See the GitHub Security Advisory GHSA-h4pc-58cc-hc95, the GitHub Release v2.5.2, and the GitHub Commit Details. The commit extends the authentication filter URL patterns and adds InputValidator checks in AccessKeyUtil to prevent reserved path segments from being interpreted as tenant identifiers.

Workarounds

Block or reverse-proxy-strip requests to /configfiles/raw/* at your load balancer or ingress layer until patching is complete.
Enforce mutual TLS or network ACLs so that only trusted Apollo clients can reach the ConfigService port.
Disable the raw configuration endpoint at the proxy layer if no legitimate clients require it.

bash

# Example NGINX ingress rule to block unauthenticated raw endpoint access
location ~ ^/configfiles/raw/ {
    if ($http_authorization_timestamp = "") {
        return 403;
    }
    proxy_pass http://apollo_configservice_upstream;
}