Backstage catalog rules can be bypassed for URL locations using encoded path segments
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.9.2, 4.0.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Backstage's catalog backend (the @backstage/plugin-catalog-backend package) is affected. An authenticated user with permission to create catalog locations can use encoded URL path characters to slip an untrusted URL past the catalog's allow-list rules, causing content from an unapproved source to be accepted as trusted catalog data.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Backstage is an open framework for building developer portals. Prior to 3.9.2 and from 4.0.0 until 4.0.2, DefaultCatalogRulesEnforcer in @backstage/plugin-catalog-backend compares the raw location.target URL against catalog.rules, while URL readers canonicalize the same URL before fetching it. An authenticated user with catalog.location.create permission can use percent-encoded path segments to make an untrusted URL match a trusted location pattern even though the canonical URL resolves outside that scope. This admits entity content from an untrusted source as trusted, while further downstream consequences depend on deployment configuration. This issue is fixed in versions 3.9.2 and 4.0.2.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- backstage backstage
fixed in 3.9.2; From 4.0.0 · fixed in 4.0.2
- @backstage/plugin-catalog-backendnpm
fixed in 3.9.2
- @backstage/plugin-catalog-backendnpm
From 4.0.0 · fixed in 4.0.2