Security readout for executives and security teams
Plain-English summary
Backstage deployments using vulnerable `@backstage/backend-defaults` may let a low-privileged attacker abuse an allowed external URL to make Backstage request an internal or sensitive URL after a redirect. The issue is rated low because exploitation needs control of an allowed host and does not add request headers, but exposure matters if Backstage can reach sensitive internal systems.
Executive priority
Treat as a targeted, configuration-dependent SSRF issue. Patch during the next normal security maintenance window, sooner if Backstage can reach sensitive internal systems or if allowlisted hosts are not tightly controlled.
Technical view
`FetchUrlReader`, used by the catalog and other plugins, automatically followed HTTP redirects from hosts listed in `backend.reading.allow`. An attacker controlling an allowed host could redirect Backstage to non-allowlisted internal URLs, bypassing the allowlist and creating SSRF. Fixed versions are `@backstage/backend-defaults` 0.12.2, 0.13.2, 0.14.1, and 0.15.0.
Likely exposure
Relevant to organizations running Backstage with affected `@backstage/backend-defaults` versions and configured `backend.reading.allow` entries. Risk is higher when allowed hosts are attacker-controlled, less trusted, or have open redirects, and when Backstage has network access to sensitive internal endpoints.
Exploitation context
The source bundle does not indicate active exploitation, and CISA KEV status is false. Exploitation requires a host in `backend.reading.allow` that the attacker controls or can redirect. The advisory notes attackers cannot add extra request headers, limiting some SSRF impact.
Researcher notes
Focus review on URL-reading paths using `FetchUrlReader`, especially catalog and plugin fetch behavior. The core issue is redirect-following after allowlist approval. Evidence is limited to the CVE and GitHub advisory/commit; no exploit activity is cited in the provided sources.
Mitigation direction
- Upgrade `@backstage/backend-defaults` to 0.12.2, 0.13.2, 0.14.1, 0.15.0, or later.
- Restrict `backend.reading.allow` to trusted hosts you control.
- Ensure allowed hosts do not issue unsafe redirects.
- Check allowed hosts for open redirect vulnerabilities.
- Use network controls to block Backstage access to sensitive internal endpoints.
Validation and detection
- Inventory Backstage deployments and `@backstage/backend-defaults` versions.
- Review `backend.reading.allow` entries for untrusted or externally controlled hosts.
- Confirm upgraded versions are deployed in all Backstage backend environments.
- Assess whether Backstage can reach sensitive internal services.
- Review allowed hosts for redirects to non-allowlisted destinations.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-918: Information exposure and cloud metadata lookup
Information exposure and SSRF weaknesses can make discovery, cloud metadata, and credential material review relevant. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupCloud metadata behavior lookup
The CVE wording references SSRF or metadata access, so cloud discovery and credential material review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupCVE-2026-24048 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Low
- CVSS
- 3.5 (3.1)
- Known Exploited
- No
- Published
Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
CVSS vector scores
1 official scoreWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N1.81.4Primary CVE scoreVulnerability scoring details
Base CVSS 3.1 score
3.5LowVector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N
Source materials
- CVE List V5 sourceCVE List V5
- https://github.com/backstage/backstage/security/advisories/GHSA-q2x5-4xjx-c6p9CVE reference · x_refsource_CONFIRM
- https://github.com/backstage/backstage/commit/27f9061d24affd1b9212fe0abd476bfc3fbaedcbCVE reference · x_refsource_MISC
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.