GHSA-4W3Q-QPFQ-V992

Vulnerability from github – Published: 2026-07-13 18:26 – Updated: 2026-07-13 18:26
VLAI
Summary
Apollo ConfigService access key authentication bypass via appId parsing and non-canonical matching
Details

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.ctrip.framework.apollo:apollo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T18:26:30Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nApollo 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.\n\n### Details\nConfigService 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.\n\nThis 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.\n\n### Impact\nAn 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.\n\n### Affected endpoints\nThe primary impact is on ConfigService configuration read endpoints under /configs and /configfiles. Notification endpoints using appId parameters are also hardened as defense-in-depth.\n\n### Status\nFixed in Apollo 2.5.2. Users should upgrade to Apollo 2.5.2 or later.\n\n### Related advisory\nThe 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.",
  "id": "GHSA-4w3q-qpfq-v992",
  "modified": "2026-07-13T18:26:30Z",
  "published": "2026-07-13T18:26:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apolloconfig/apollo/security/advisories/GHSA-4w3q-qpfq-v992"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apolloconfig/apollo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apolloconfig/apollo/releases/tag/v2.5.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apollo ConfigService access key authentication bypass via appId parsing and non-canonical matching"
}



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…