How severe is GHSA-4w3q-qpfq-v992?

GHSA-4w3q-qpfq-v992 has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-4w3q-qpfq-v992?

GHSA-4w3q-qpfq-v992 affects the following packages: com.ctrip.framework.apollo:apollo (Maven). Ecosystems affected: Maven.

How do I fix GHSA-4w3q-qpfq-v992?

No patched version of com.ctrip.framework.apollo:apollo has shipped for GHSA-4w3q-qpfq-v992 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

How do I detect GHSA-4w3q-qpfq-v992 in my Maven dependencies?

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.

How do I mitigate GHSA-4w3q-qpfq-v992 if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-4w3q-qpfq-v992?

O3 pinpoints whether GHSA-4w3q-qpfq-v992 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-4w3q-qpfq-v992 actively exploited in the wild?

No public exploit code has been indexed for GHSA-4w3q-qpfq-v992 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-4w3q-qpfq-v992?

GHSA-4w3q-qpfq-v992 has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 42th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-4w3q-qpfq-v992?

GHSA-4w3q-qpfq-v992 is classified as Improper Input Validation (CWE-20), Improper Authentication (CWE-287). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-4w3q-qpfq-v992 published, and has it been updated?

GHSA-4w3q-qpfq-v992 was published on July 13, 2026 and was last updated on July 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕ Maven

GHSA-4w3q-qpfq-v992

HIGH

Apollo ConfigService access key authentication bypass via appId parsing and non-canonical matching

Also known asCVE-2026-59954

Published

Jul 13, 2026

Updated

Jul 13, 2026

Affected

1 pkg

Patched

None yet

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk42th percentile0.00%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected

☕com.ctrip.framework.apollo:apollo

Real-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 configuration data when AccessKey / management key authentication is enabled and ConfigService accepts a non-canonical appId variant during authentication while downstream request handling resolves it to the protected app.

Details

ConfigService extracts appId from configuration and notification requests and uses the extracted value to look up available AccessKey secrets. If the extracted appId is a non-canonical variant that does not exactly match the AccessKey cache key, ConfigService may treat the request as having no available secrets and allow it to continue without signature verification.

This can happen when downstream release lookup still matches the real appId under database collations that treat the values as equivalent. Examples include accent variants under accent-insensitive collations, or trailing-space variants under PAD SPACE collations.

Impact

An unauthenticated remote attacker may read configuration data from affected ConfigService endpoints when AccessKey / management key authentication is enabled for the target app and the deployment database collation treats a non-canonical appId variant as equivalent to the real appId.

Affected endpoints

The primary impact is on ConfigService configuration read endpoints under /configs and /configfiles. Notification endpoints using appId parameters are also hardened as defense-in-depth.

Status

Fixed in Apollo 2.5.2. Users should upgrade to Apollo 2.5.2 or later.

Related advisory

The raw config file endpoint parsing issue originally described in this advisory has been split into GHSA-h4pc-58cc-hc95 so each independently fixable vulnerability can receive its own CVE.

Affected Packages

1 total

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`com.ctrip.framework.apollo:apollo`	all versions	No fix

Detection & mitigation playbook

Open-source dependency

Detect
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-4w3q-qpfq-v992 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-4w3q-qpfq-v992 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-4w3q-qpfq-v992. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Apollo ConfigService may allow unauthorized access to configuration data when AccessKey / management key authentication is enabled and ConfigService accepts a non-canonical appId variant during authentication while downstream request handling resolves it to the protected app. ### Details ConfigService extracts appId from configuration and notification requests and uses the extracted value to look up available AccessKey secrets. If the extracted appId is a non-canonical variant that does not exactly match the AccessKey cache key, ConfigService may treat the request as having no ava

O3 Security · Impact-Aware SCA

Is GHSA-4w3q-qpfq-v992 in your dependencies?

O3 detects GHSA-4w3q-qpfq-v992 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works