GHSA-jxpj-9j24-w337
MEDIUMGHSA-jxpj-9j24-w337 is a medium-severity (CVSS 6.5) CWE-639 vulnerability in com.ctrip.framework.apollo:apollo. O3 Security confirms whether GHSA-jxpj-9j24-w337 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Apollo Portal: There is a risk of unauthorized access to the Apollo configuration center
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 Portal versions before 2.5.0 do not verify application and namespace permissions when an authenticated user requests a release by ID through GET /envs/{env}/releases/{releaseId}.
When configView.memberOnly.envs is enabled for the requested environment, a low-privileged Portal user can supply a valid release ID belonging to an application or namespace they are not authorized to view. The endpoint returns the release data without calling UserPermissionValidator.shouldHideConfigToCurrentUser(...).
Impact
An authenticated attacker who obtains or guesses a valid release ID can read configuration data from other applications and namespaces. Exposed configuration may contain sensitive values such as credentials or service endpoints. The issue does not allow configuration modification and does not directly affect availability.
Affected versions
Apollo Portal versions earlier than 2.5.0 are affected when configView.memberOnly.envs is enabled.
Patches
The issue is fixed in Apollo 2.5.0. The fix adds the missing application and namespace permission check before returning release data.
- Fix: https://github.com/apolloconfig/apollo/pull/5378
- Fix commit: https://github.com/apolloconfig/apollo/commit/362735ded4f13b62f6ab9df135d7096066e8e291
- Patched release: https://github.com/apolloconfig/apollo/releases/tag/v2.5.0
Workarounds
Upgrade to Apollo 2.5.0 or later. If an immediate upgrade is not possible, backport the permission check from PR #5378 and restrict Apollo Portal access to trusted users until the fix is deployed.
Credits
Apollo Portal thanks @lesignals for reporting this issue.
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-jxpj-9j24-w337 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-jxpj-9j24-w337 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-jxpj-9j24-w337. 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-jxpj-9j24-w337 in your dependencies?
O3 detects GHSA-jxpj-9j24-w337 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.