CVE-2026-59955
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk42th percentile - higher than 42% of all known CVEs
Summary
Apollo ConfigService before version 2.5.2 may allow unauthorized access to raw configuration data when AccessKey or management key authentication is enabled. The issue stems from incorrect parsing of the request path /configfiles/raw/{appId}/{clusterName}/{namespace}, where the application ID is read as 'raw' instead of the actual value from the URL, potentially bypassing signature verification for the target application.
Risk Assessment
The organization risks exposure of sensitive configuration data that could be read by unauthorized parties, potentially leading to security breaches of systems and applications using Apollo.
Recommendation
Immediately upgrade Apollo ConfigService to version 2.5.2 or later, which includes a fix that prevents unauthorized access to raw configuration data.
Other vulnerabilities in Apollo
See all- CVE-2026-59954High
Apollo ConfigService prior to version 2.5.2 may allow unauthorized access to configuration data when AccessKey or management key authentication is enabled. This occurs because ConfigService accepts non-canonical appId variants (e.g., accent or trailing-space variants) during authentication, which are later resolved to the protected app on /configs and /configfiles endpoints.
- CVE-2025-32781Medium
In Apollo Portal prior to version 2.5.0, a vulnerability exists due to missing permission checks for applications and namespaces when fetching a release by its ID. An authenticated low-privileged user can read configuration data from other applications if they know or guess a valid releaseId, bypassing the UserPermissionValidator.shouldHideConfigToCurrentUser(...) mechanism.
Original NVD description (English source)
Apollo is a reliable configuration management system suitable for microservice configuration management scenarios. Prior to 2.5.2, Apollo ConfigService may allow unauthorized access to raw configuration data when AccessKey or management key authentication is enabled because requests under /configfiles/raw/{appId}/{clusterName}/{namespace} are parsed for authentication as appId raw instead of the actual path appId, causing ConfigService to look up AccessKey secrets for raw before verifying the request signature and potentially continue without signature verification for the target appId. This issue is fixed in version 2.5.2.