CVE-2026-32236: @backstage plugin-auth-backend · Server-Side Request Forgery (SSRF)
Affects @backstage plugin-auth-backendSource CVE Database V5
Not known to be exploited · CVSS 1.7 Low : upgrade to 0.27.1 when convenient.
Data as of 30 Oct 2026, 11:52 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 23% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.27.1
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:UExploitation evidence
Disclosed: evidence found.
CVE published 12 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade @backstage plugin-auth-backend to 0.27.1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| @backstageplugin-auth-backend | Affected
| Fixed in
|
AI-suggested
Upgrade @backstage/plugin-auth-backend to version 0.27.1 or later, where this SSRF vulnerability is fixed. If upgrading is not immediately possible, ensure that the experimental flag auth.experimentalClientIdMetadataDocuments.enabled remains disabled (default off) and restrict allowedClientIdPatterns to trusted domains to prevent exposure. Patch status is confirmed by the vendor advisory indicating the fix in version 0.27.1.
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.