CVE-2026-115923 in Backstage
Summary
by MITRE • 10/26/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Backstage prior to version 3.9.2 and within the range from 4.0.0 to 4.0.2 represents a critical logic flaw in how location targets are validated against catalog rules, specifically involving the DefaultCatalogRulesEnforcer component of the @backspace/plugin-catalog-backend module. This issue stems from an inconsistency between two distinct processes: URL canonicalization and rule enforcement. When a user submits a new entity or location for ingestion into the developer portal, the system employs URL readers to fetch content from that target. These readers automatically normalize or canonicalize URLs, resolving relative paths, removing redundant segments, and decoding percent-encoded characters to determine the actual resource endpoint. However, the DefaultCatalogRulesEnforcer performs its security checks by comparing the raw, unmodified location.target string against a list of allowed catalog rules defined in the configuration. This discrepancy creates a bypass mechanism where an attacker can craft a URL that appears compliant with trusted patterns when viewed as raw text but resolves to a completely different, potentially malicious or unauthorized resource after canonicalization occurs during the fetch operation.
This architectural flaw allows authenticated users possessing the catalog.location.create permission to exploit percent-encoded path segments to deceive the validation logic. By encoding specific characters within the URL path, an attacker can construct a target that matches a trusted domain and pattern in its raw form but decodes into a different host or unauthorized internal service when processed by the URL reader. For instance, if a rule permits locations from example.com, an attacker might submit a URL where certain segments are encoded to bypass string matching checks while still pointing to an internal IP address or a different subdomain upon resolution. This effectively admits entity content from an untrusted source into the catalog under the guise of being trusted, violating the principle of least privilege and compromising the integrity of the developer portal's data model. The severity of this issue is further amplified by its classification as CWE-20 Improper Input Validation, where the system fails to adequately validate input before relying on it for security decisions, specifically failing to ensure that the validated value matches the canonicalized version used in subsequent operations.
The operational impact of this vulnerability depends heavily on the specific deployment configuration and the downstream processing capabilities enabled within the Backstage instance. If the portal is configured to render or execute content from catalog entities, an attacker could potentially inject malicious scripts, phishing links, or other harmful payloads disguised as legitimate entity metadata. Even if direct code execution is not possible due to sandboxing or rendering limitations, the integrity of the software supply chain information managed by Backstage can be compromised. Attackers might redirect users to spoofed login pages for internal services, leading to credential theft via CWE-200 Information Exposure or phishing attacks aligned with MITRE ATT&CK technique T1566 Phishing. Furthermore, if the catalog is integrated with other systems that trust entity data for automated actions such as deployment triggers or access control decisions, this inconsistency could lead to broader security breaches by allowing unauthorized resources to influence critical infrastructure workflows.
To mitigate this vulnerability and prevent similar issues in future development, it is imperative to ensure that all URL validation logic operates on the canonicalized version of the target rather than the raw input string. The DefaultCatalogRulesEnforcer must be updated to resolve or normalize URLs before comparing them against allowed patterns, ensuring consistency between the security check and the actual resource fetch operation. Organizations running affected versions should immediately upgrade to Backstage 3.9.2 or 4.0.2 where this logic has been corrected. In environments where upgrading is not immediately feasible, administrators can implement a workaround by restricting catalog.location.create permissions to only highly trusted users who are fully vetted and understanding the risks associated with untrusted input handling. Additionally, implementing strict allow-listing of domains at the network perimeter or using web application firewalls that inspect decoded URLs for anomalies can provide an additional layer of defense against exploitation attempts targeting this specific logic flaw.