Apollo ConfigService EUVD-2026-44725

Exploitation requires that AccessKey/management-key authentication is enabled for the target app (the very control being bypassed) AND that the deployment's backing database uses a collation that treats a non-canonical appId variant as equivalent to the canonical appId - specifically accent-insensitive collations (accent-variant appIds) or PAD SPACE collations such as MySQL utf8_general_ci (trailing-space appId variants). The attacker must also know or guess the real protected appId to craft the variant. Limiting factors: apps without AccessKey auth enabled are not protected by the bypassed control in the first place, and deployments using strictly binary/case-and-space-sensitive collations for appId are not exploitable; the impact is confined to read access to configuration data (C:H, with I:N/A:N) on the /configs and /configfiles endpoints. No user interaction and no authentication are needed against a vulnerable-collation deployment.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 High) presents a network, unauthenticated, low-complexity confidentiality breach, which overstates real-world ease: the description makes clear that exploitation is conditional on (1) AccessKey/management-key authentication actually being enabled for the target app, and (2) the deployment's database collation treating a non-canonical appId variant as equivalent to the real one. That second condition is a non-default, environment-specific factor, so AC:L is arguably optimistic - a case-by-case AC:H is defensible. No EPSS score, no SSVC decision, and no KEV entry were provided; there is no evidence of active exploitation and no public POC was supplied, so this is currently a patch-in-normal-cycle priority rather than an emergency, weighted upward for deployments that rely on AccessKey auth as their primary confidentiality control. Note also a data conflict: the GitHub advisory package metadata lists 'vulnerable <= 2.0.1, fixed in: None' while the advisory text and release notes state the fix is 2.5.2 - the version range in the machine-readable feed appears incomplete and should be verified against the vendor advisory.

An attacker who knows the protected appId of a target Apollo deployment (e.g. 'orders-service') sends an unauthenticated GET to the ConfigService /configs endpoint using a non-canonical variant such as a trailing-space or accented form of that appId. Because the variant misses the AccessKey cache and skips signature verification but still matches the real app under a PAD SPACE or accent-insensitive collation, the service returns the protected application's configuration - potentially exposing database credentials, API keys, and other secrets stored in config. No public POC was provided, but the technique requires only crafted HTTP requests.