GHSA-Q333-F498-W2X7

Vulnerability from github – Published: 2026-10-07 20:25 – Updated: 2026-10-07 20:25
VLAI
Summary
Backstage: Insufficient audience validation in the Cloudflare Access auth provider
Details

Impact

The Cloudflare Access auth provider verifies a token's signature and team issuer, but affected versions do not verify that the token was issued for the Backstage application. A user holding a valid token for another Access application in the same Cloudflare Zero Trust team may therefore be able to authenticate to Backstage if that token reaches the auth endpoint without the Backstage application's audience already being enforced upstream.

Cloudflare Access normally evaluates the protected application before forwarding requests. The reported reproduction exercises the provider directly and does not demonstrate bypass through the ordinary Cloudflare-protected Backstage URL. Relevant deployment topologies include direct origin access, alternate routes around the intended Access application, or another proxy forwarding the assertion unchanged.

A successful sign-in also depends on the deployment's sign-in resolver mapping the presented identity to a Backstage user. The resulting impact depends on the permissions assigned to that identity.

Patches

Upgrade @backstage/plugin-auth-backend-module-cloudflare-access-provider to version 0.5.0 or later. The fixed package is available in Backstage v1.55.0.

This is a breaking configuration change. Before upgrading, set auth.providers.cfaccess.audience to the Audience (AUD) tag for the Backstage application in Cloudflare Zero Trust:

auth:
  providers:
    cfaccess:
      teamName: example
      audience: ${AUTH_CFACCESS_AUDIENCE}

Workarounds

  • Restrict access to the Backstage auth endpoint to the intended Cloudflare Access application.
  • Use a custom authenticator that validates the application audience.
  • Disable the provider until the patched package can be deployed.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@backstage/plugin-auth-backend-module-cloudflare-access-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-106457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:25:25Z",
    "nvd_published_at": "2026-10-06T21:17:16Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe Cloudflare Access auth provider verifies a token\u0027s signature and team issuer, but affected versions do not verify that the token was issued for the Backstage application. A user holding a valid token for another Access application in the same Cloudflare Zero Trust team may therefore be able to authenticate to Backstage if that token reaches the auth endpoint without the Backstage application\u0027s audience already being enforced upstream.\n\nCloudflare Access normally evaluates the protected application before forwarding requests. The reported reproduction exercises the provider directly and does not demonstrate bypass through the ordinary Cloudflare-protected Backstage URL. Relevant deployment topologies include direct origin access, alternate routes around the intended Access application, or another proxy forwarding the assertion unchanged.\n\nA successful sign-in also depends on the deployment\u0027s sign-in resolver mapping the presented identity to a Backstage user. The resulting impact depends on the permissions assigned to that identity.\n\n### Patches\n\nUpgrade `@backstage/plugin-auth-backend-module-cloudflare-access-provider` to version `0.5.0` or later. The fixed package is available in [Backstage v1.55.0](https://github.com/backstage/backstage/releases/tag/v1.55.0).\n\nThis is a breaking configuration change. Before upgrading, set `auth.providers.cfaccess.audience` to the Audience (AUD) tag for the Backstage application in Cloudflare Zero Trust:\n\n```yaml\nauth:\n  providers:\n    cfaccess:\n      teamName: example\n      audience: ${AUTH_CFACCESS_AUDIENCE}\n```\n\n### Workarounds\n\n- Restrict access to the Backstage auth endpoint to the intended Cloudflare Access application.\n- Use a custom authenticator that validates the application audience.\n- Disable the provider until the patched package can be deployed.",
  "id": "GHSA-q333-f498-w2x7",
  "modified": "2026-10-07T20:25:25Z",
  "published": "2026-10-07T20:25:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/backstage/backstage/security/advisories/GHSA-q333-f498-w2x7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106457"
    },
    {
      "type": "WEB",
      "url": "https://github.com/backstage/backstage/commit/ed9034cacd9def3b3674f0a764fe992f751e204d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/backstage/backstage"
    },
    {
      "type": "WEB",
      "url": "https://github.com/backstage/backstage/releases/tag/v1.55.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Backstage: Insufficient audience validation in the Cloudflare Access auth provider"
}



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…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…