CVE-2026-59954: 
Java Análisis y mitigación de vulnerabilidades

CVE-2026-59954 is an access key authentication bypass vulnerability in Apollo ConfigService that allows unauthenticated remote attackers to read protected configuration data. The flaw affects Apollo versions up to and including 2.5.1 (Maven package com.ctrip.framework.apollo:apollo), and was published on July 12–13, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Apollo Advisory).

The root cause is improper input validation and improper authentication (CWE-20, CWE-287) in how Apollo ConfigService extracts and validates the appId parameter from incoming configuration and notification requests. When ConfigService looks up AccessKey secrets for a given appId, it performs an exact cache key match; if an attacker supplies a non-canonical variant of the appId (e.g., an accent-modified string under an accent-insensitive database collation, or a trailing-space variant under a PAD SPACE collation), the cache lookup finds no secrets and skips signature verification entirely. However, the downstream release lookup still resolves the non-canonical variant to the real app's data because the database collation treats them as equivalent, effectively granting unauthenticated access to protected configuration. The attack requires no privileges or user interaction and is exploitable over the network (GitHub Advisory, Apollo Advisory).

A successful exploit allows an unauthenticated remote attacker to read sensitive configuration data from Apollo ConfigService endpoints — specifically those under /configs and /configfiles — even when AccessKey or management key authentication is enabled for the target application. Configuration data stored in Apollo may include database credentials, API keys, internal service endpoints, and other secrets, making this a high-confidentiality-impact vulnerability. There is no integrity or availability impact, but exposure of configuration secrets could enable lateral movement or further compromise of dependent services (GitHub Advisory, Apollo Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible Apollo ConfigService instances. Determine the appId of a target application that has AccessKey authentication enabled (this may be discoverable via error messages, documentation, or other information leakage.
2. Identify database collation behavior: Determine whether the target deployment uses a database collation that treats non-canonical appId variants as equivalent (e.g., accent-insensitive collation or PAD SPACE collation in MySQL/MariaDB).
3. Craft non-canonical appId: Construct a variant of the target appId that differs from the canonical form but will be treated as equivalent by the database — for example, by appending trailing spaces or substituting accented characters.
4. Send unauthenticated request: Issue an HTTP GET request to a ConfigService endpoint such as /configs/{non-canonical-appId}/{clusterName}/{namespaceName} or /configfiles/{non-canonical-appId}/{clusterName}/{namespaceName} without providing a valid AccessKey signature.
5. Bypass authentication: ConfigService fails to find AccessKey secrets for the non-canonical appId in its cache, skips signature verification, and forwards the request downstream. The database resolves the non-canonical appId to the real app and returns its configuration data.
6. Exfiltrate configuration data: Parse the response to extract sensitive configuration values such as credentials, API keys, or internal service addresses (GitHub Advisory, Apollo Advisory).

• Network: Unexpected HTTP GET requests to /configs/ or /configfiles/ endpoints on Apollo ConfigService from unknown or external IP addresses, particularly without valid Authorization or signature headers; requests using appId values with trailing spaces, accent characters, or other non-standard character variants.
• Logs: Apollo ConfigService access logs showing requests to configuration read endpoints that lack AccessKey signature headers but receive successful (HTTP 200) responses; log entries where the appId in the request does not exactly match any registered application ID.
• Application Behavior: Absence of authentication failure or 401/403 responses for requests to protected configuration endpoints when AccessKey is enabled, indicating the signature verification step was skipped.

The vulnerability is fixed in Apollo 2.5.2, which validates ConfigService AccessKey app IDs during client authentication. Users should upgrade to Apollo 2.5.2 or later immediately. The upgrade from v2.5.1 to v2.5.2 requires no database schema changes — simply redeploy the updated executables in the order: apollo-configservice, apollo-adminservice, then apollo-portal. No configuration-based workaround is documented; upgrading is the recommended remediation (Apollo 2.5.2 Release, Apollo Advisory).

The vulnerability was discovered and reported by researchers zhou-youyou and Jarvis-Huanglz, and was published by Apollo maintainer nobodyiam on July 12, 2026. A related advisory (GHSA-h4pc-58cc-hc95) was split from this one to address a separate raw config file endpoint parsing issue, each receiving its own CVE. No broader media coverage or notable community commentary has been identified beyond the official advisory (Apollo Advisory).