CVE-2026-59954: 
Java 취약성 분석 및 완화

CVE-2026-59954 is an authentication bypass vulnerability in Apollo ConfigService that allows unauthenticated remote attackers to read protected configuration data by supplying a non-canonical appId variant in requests. It affects Apollo versions up to and including 2.5.1 (all versions prior to 2.5.2). The vulnerability was published on July 12–13, 2026, and patched in Apollo 2.5.2. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Github Advisory).

The root cause is a mismatch between how Apollo ConfigService authenticates requests and how the downstream database resolves appId values, classified as CWE-20 (Improper Input Validation) and CWE-287 (Improper Authentication). When ConfigService extracts the appId from a request URL or parameter, it looks up available AccessKey secrets using that value as a cache key. If the submitted appId is a non-canonical variant — such as one with accent characters (e.g., mysql.exámple.test) under accent-insensitive database collations, or with trailing spaces under PAD SPACE collations — 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 protected app, effectively bypassing authentication on the /configs/*, /configfiles/*, and /notifications/v2 endpoints (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated remote attacker to read all configuration data accessible through the affected ConfigService endpoints (/configs and /configfiles), even when AccessKey or management key authentication is enabled. Since Apollo is a microservice configuration management system, exposed configuration data may include database credentials, API keys, service secrets, and other sensitive application parameters stored across managed microservices. There is no integrity or availability impact, but the confidentiality breach could enable lateral movement or further compromise of dependent services (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or internally accessible Apollo ConfigService instances running versions ≤ 2.5.1. Check for exposed /configs/ or /configfiles/ endpoints.
2. Identify target appId: Determine a valid appId registered in the Apollo instance (e.g., through error messages, documentation, or prior knowledge of the target environment).
3. Craft non-canonical appId: Modify the known appId to a non-canonical variant — for example, append a trailing space (mysql.example.test ) to exploit PAD SPACE collations, or substitute an ASCII character with an accented equivalent (mysql.exámple.test) to exploit accent-insensitive collations.
4. Send unauthenticated request: Issue an HTTP GET request to the ConfigService endpoint using the non-canonical appId, e.g.:

   GET /configs/mysql.example.test%20/default/application HTTP/1.1
   Host: <configservice-host>

5. Bypass authentication: ConfigService fails to find AccessKey secrets for the non-canonical appId and skips signature verification, while the database resolves the variant to the real app and returns its configuration data.
6. Exfiltrate configuration data: Parse the response to extract sensitive values such as database credentials, API keys, or service secrets stored in the application's configuration (GitHub Advisory, Patch Commit).

• Network: Unexpected HTTP GET requests to /configs/, /configfiles/, or /notifications/v2 endpoints containing URL-encoded spaces (%20) or non-ASCII/accented characters in the appId path segment or appId query parameter; requests to these endpoints lacking a valid Authorization or Signature header when AccessKey authentication is enabled.
• Logs: Apollo ConfigService access logs showing requests with appId values that differ slightly from registered app names (e.g., trailing spaces, diacritic characters); absence of authentication-related log entries for requests that successfully returned configuration data.
• Application Behavior: Successful configuration data responses returned to clients that did not supply a valid AccessKey signature, particularly from unfamiliar source IP addresses.

The fix is available in Apollo 2.5.2, which validates the extracted appId against a strict allowlist pattern before performing AccessKey lookup, rejecting non-canonical variants such as those with trailing spaces or accent characters. Upgrade from v2.5.1 to v2.5.2 requires no database schema changes — simply redeploy the apollo-configservice, apollo-adminservice, and apollo-portal components in that order. No configuration-based workaround is available for unpatched versions; upgrading is the only remediation (Apollo v2.5.2 Release, Patch Commit).