EUVD-2025-210473
GHSA-jxpj-9j24-w337
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network-accessible API (AV:N), straightforward enumeration once account held (AC:L), any Portal account required (PR:L), no write or availability impact confirmed by description.
Primary rating from Vendor (https://github.com/apolloconfig/apollo).
CVSS VectorVendor: https://github.com/apolloconfig/apollo
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
{env}/releases/{releaseId} endpoint fetches and returns a release payload without invoking UserPermissionValidator.shouldHideConfigToCurrentUser(...), meaning a low-privileged user who supplies a valid release ID belonging to a restricted application receives the full configuration - potentially including embedded credentials, database connection strings, and service endpoints. No public exploit has been identified at time of analysis, and exploitation is gated by a non-default configuration setting (configView.memberOnly.envs`), but the practical data sensitivity of Apollo configuration stores makes this a meaningful confidentiality risk.
Technical ContextAI
Apollo is an open-source distributed configuration management platform originally developed by Ctrip, distributed as the Maven artifact com.ctrip.framework.apollo:apollo. Its Portal component exposes a REST API and web UI for operators to manage configuration releases across environments and namespaces. The vulnerable endpoint GET /envs/{env}/releases/{releaseId} accepts a release ID as a path parameter - a sequential integer - and returns the corresponding release object. When the configView.memberOnly.envs feature is enabled for an environment, access to configuration data is supposed to be restricted to users with explicit membership in the owning application or namespace. The enforcement mechanism is UserPermissionValidator.shouldHideConfigToCurrentUser(appId, env, clusterName, namespaceName), which was called in other endpoints but was entirely absent from the release-by-ID handler. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the user controls the releaseId key, the system resolves it to a resource object, but never checks whether the resolved resource belongs to a namespace the requesting user is authorized to access. The fix in PR #5378 inserts a four-line permission check immediately after the release is fetched, throwing AccessDeniedException on unauthorized access.
RemediationAI
Upgrade to Apollo 2.5.0 or later, which adds the missing UserPermissionValidator.shouldHideConfigToCurrentUser(...) call in ReleaseController.java before returning release data (fix PR: https://github.com/apolloconfig/apollo/pull/5378, fix commit: https://github.com/apolloconfig/apollo/commit/362735ded4f13b62f6ab9df135d7096066e8e291, release: https://github.com/apolloconfig/apollo/releases/tag/v2.5.0). If an immediate upgrade is not feasible, the vendor recommends backporting the four-line permission check from PR #5378 directly into the GET /envs/{env}/releases/{releaseId} handler - this is a surgical, low-risk change. As a compensating control prior to patching, restrict Portal access to only fully-trusted personnel by revoking low-privilege accounts, eliminating the PR:L attack surface at the cost of reduced operational access for non-admin users. Do not disable configView.memberOnly.envs as a workaround - doing so broadens configuration visibility to all Portal users rather than restricting it, which is the opposite of the intended control. The vendor-released patch in v2.5.0 is the authoritative fix; the upstream PR and commit are confirmed merged.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today