Apollo Portal: There is a risk of unauthorized access to the Apollo configuration centerGHSA-jxpj-9j24-w337
MEDIUMFix: apolloconfig/apollo#5378GHSA-jxpj-9j24-w337 is a medium-severity (CVSS 6.5) CWE-639 vulnerability in com.ctrip.framework.apollo:apollo. The records list no fixed version yet; check the vendor advisory below and apply the mitigations in the meantime.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jxpj-9j24-w337.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
The records we use list no patched version of com.ctrip.framework.apollo:apollo for GHSA-jxpj-9j24-w337. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.
Mitigate without a patch
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-jxpj-9j24-w337 in your dependencies?
Find it across Maven, including transitive dependencies.