GHSA-h4pc-58cc-hc95
HIGHApollo ConfigService access key authentication bypass via raw config file appId parsing
Blast Radius
com.ctrip.framework.apollo:apolloReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Apollo ConfigService may allow unauthorized access to raw configuration data when AccessKey / management key authentication is enabled because authentication parsed the appId incorrectly for the raw config file endpoint.
Details
Requests under /configfiles/raw/{appId}/{clusterName}/{namespace} were parsed for authentication as appId "raw" instead of the actual path appId. ConfigService used the parsed appId to look up available AccessKey secrets before verifying the request signature.
If no AccessKey is configured for an application literally named "raw", ConfigService may treat the request as having no available secrets and allow it to continue without signature verification, even when AccessKey / management key authentication is enabled for the actual target appId in the path.
Impact
An unauthenticated remote attacker may read raw configuration data from affected ConfigService endpoints when AccessKey / management key authentication is enabled for the target app and the attacker requests the raw config file endpoint.
Affected endpoints
The primary impact is on ConfigService raw config file reads under /configfiles/raw/{appId}/{clusterName}/{namespace}.
Status
Fixed in Apollo 2.5.2. Users should upgrade to Apollo 2.5.2 or later.
Related advisory
The non-canonical appId matching issue is tracked separately in GHSA-4w3q-qpfq-v992 so each independently fixable vulnerability can receive its own CVE.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.ctrip.framework.apollo:apollo | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.ctrip.framework.apollo:apollo. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of com.ctrip.framework.apollo:apollo has shipped for GHSA-h4pc-58cc-hc95 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h4pc-58cc-hc95 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h4pc-58cc-hc95. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h4pc-58cc-hc95 in your dependencies?
O3 detects GHSA-h4pc-58cc-hc95 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.