GHSA-JXPJ-9J24-W337

Vulnerability from github – Published: 2026-07-13 16:47 – Updated: 2026-07-13 16:47
VLAI
Summary
Apollo Portal: There is a risk of unauthorized access to the Apollo configuration center
Details

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.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.5.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.ctrip.framework.apollo:apollo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T16:47:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nApollo 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}`.\n\nWhen `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(...)`.\n\n### Impact\n\nAn 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.\n\n### Affected versions\n\nApollo Portal versions earlier than 2.5.0 are affected when `configView.memberOnly.envs` is enabled.\n\n### Patches\n\nThe issue is fixed in Apollo 2.5.0. The fix adds the missing application and namespace permission check before returning release data.\n\n- Fix: https://github.com/apolloconfig/apollo/pull/5378\n- Fix commit: https://github.com/apolloconfig/apollo/commit/362735ded4f13b62f6ab9df135d7096066e8e291\n- Patched release: https://github.com/apolloconfig/apollo/releases/tag/v2.5.0\n\n### Workarounds\n\nUpgrade to Apollo 2.5.0 or later. If an immediate upgrade is not possible, backport the permission check from [PR #5378](https://github.com/apolloconfig/apollo/pull/5378) and restrict Apollo Portal access to trusted users until the fix is deployed.\n\n### Credits\n\nApollo Portal thanks [@lesignals](https://github.com/lesignals) for reporting this issue.",
  "id": "GHSA-jxpj-9j24-w337",
  "modified": "2026-07-13T16:47:09Z",
  "published": "2026-07-13T16:47:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apolloconfig/apollo/security/advisories/GHSA-jxpj-9j24-w337"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apolloconfig/apollo/pull/5378"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apolloconfig/apollo/commit/362735ded4f13b62f6ab9df135d7096066e8e291"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apolloconfig/apollo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apolloconfig/apollo/releases/tag/v2.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apollo Portal: There is a risk of unauthorized access to the Apollo configuration center"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…