CVE-2026-32236
Received Received - Intake
SSRF Vulnerability in Backstage Auth-Backend Plugin (Experimental

Publication date: 2026-03-12

Last updated on: 2026-04-15

Assigner: GitHub, Inc.

Description
Backstage is an open framework for building developer portals. Prior to 0.27.1, a Server-Side Request Forgery (SSRF) vulnerability exists in @backstage/plugin-auth-backend when auth.experimentalClientIdMetadataDocuments.enabled is set to true. The CIMD metadata fetch validates the initial client_id hostname against private IP ranges but does not apply the same validation after HTTP redirects. The practical impact is limited. The attacker cannot read the response body from the internal request, cannot control request headers or method, and the feature must be explicitly enabled via an experimental flag that is off by default. Deployments that restrict allowedClientIdPatterns to specific trusted domains are not affected. Patched in @backstage/plugin-auth-backend version 0.27.1.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-12
Last Modified
2026-04-15
Generated
2026-05-07
AI Q&A
2026-03-12
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linuxfoundation backstage to 0.27.0 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-918 The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-32236 is a Server-Side Request Forgery (SSRF) vulnerability found in the @backstage/plugin-auth-backend package, specifically in version 0.27.0 when the experimental feature auth.experimentalClientIdMetadataDocuments.enabled is set to true.

The vulnerability occurs because the initial client_id hostname is validated against private IP ranges, but this validation is not applied after HTTP redirects during the fetching of Client ID Metadata (CIMD) documents.

This means an attacker could potentially exploit HTTP redirects to make the server send requests to internal or private IP addresses.

However, the practical impact is limited since the attacker cannot read the response body, cannot control request headers or HTTP methods, and the feature is disabled by default.

Deployments that restrict allowedClientIdPatterns to trusted domains are not affected.

The issue was fixed in version 0.27.1 by disabling HTTP redirects during the metadata fetch process.


How can this vulnerability impact me? :

The impact of this vulnerability is limited due to several constraints.

  • An attacker cannot read the response body from the internal request.
  • An attacker cannot control request headers or HTTP methods.
  • The vulnerable feature must be explicitly enabled via an experimental flag that is off by default.
  • Deployments that restrict allowedClientIdPatterns to specific trusted domains are not affected.

Overall, the vulnerability poses a low risk and does not affect confidentiality, integrity, or availability.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability involves Server-Side Request Forgery (SSRF) via HTTP redirects during the fetching of Client ID Metadata (CIMD) documents when the experimental feature is enabled. Detection would focus on identifying if the vulnerable version of @backstage/plugin-auth-backend (prior to 0.27.1) is in use with the experimental flag enabled.'}, {'type': 'paragraph', 'content': 'Since the vulnerability is related to HTTP redirects during metadata fetches, monitoring network traffic for unexpected internal HTTP requests triggered by the plugin could help detect exploitation attempts.'}, {'type': 'paragraph', 'content': 'There are no specific commands provided in the resources to detect this vulnerability directly. However, you can check the installed version of the plugin and the configuration flag with commands such as:'}, {'type': 'list_item', 'content': 'Check the installed version of @backstage/plugin-auth-backend in your project: `npm list @backstage/plugin-auth-backend`'}, {'type': 'list_item', 'content': "Search your configuration files for the experimental flag: `grep -r 'auth.experimentalClientIdMetadataDocuments.enabled' ./`"}, {'type': 'paragraph', 'content': 'Additionally, monitoring logs for any HTTP redirect attempts during metadata fetches or unusual internal network requests originating from the plugin could indicate attempts to exploit the vulnerability.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability immediately, you should upgrade @backstage/plugin-auth-backend to version 0.27.1 or later, where the vulnerability is patched by disabling HTTP redirects during CIMD metadata fetches.

If upgrading is not immediately possible, you can disable the experimental feature by setting `auth.experimentalClientIdMetadataDocuments.enabled` to false, which is the default setting.

Alternatively, restrict the `allowedClientIdPatterns` configuration to specific trusted domains instead of using wildcard patterns, which prevents the vulnerability from being exploitable.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart