Summary
Backstage's catalog backend may improperly validate URLs used during catalog entity placeholder resolution, allowing an authenticated user to reference resources outside an entity's source repository. Under configurations where those resources are accessible to the catalog service, this could expose data that the user was not intended to access.
Backstage's catalog backend may improperly validate URLs used during catalog entity placeholder resolution, allowing an authenticated user to reference resources outside an entity's source repository. Under configurations where those resources are accessible to the catalog service, this could expose data that the user was not intended to access.
Affected context
The issue occurs in Backstage deployments using the @backstage/plugin-catalog-backend package and catalog entity placeholder resolution. Risk depends on configurations that permit authenticated users to create or influence catalog entities and on the catalog backend's ability to retrieve resources beyond the entity's declared source repository.
The issue occurs in Backstage deployments using the @backstage/plugin-catalog-backend package and catalog entity placeholder resolution. Risk depends on configurations that permit authenticated users to create or influence catalog entities and on the catalog backend's ability to retrieve resources beyond the entity's declared source repository.
Exploit preconditions
- Attack surface: Backstage catalog entity creation or modification and placeholder resolution
- Required access: An authenticated Backstage account with permission to craft or submit catalog entities
- Trigger point: Processing a catalog entity containing a URL-based placeholder directive
- Why exploitation is possible: URL validation may not sufficiently constrain references to the entity's authorized source repository, allowing resolution of external resources under permissive deployment conditions
- Attack surface: Backstage catalog entity creation or modification and placeholder resolution
- Required access: An authenticated Backstage account with permission to craft or submit catalog entities
- Trigger point: Processing a catalog entity containing a URL-based placeholder directive
- Why exploitation is possible: URL validation may not sufficiently constrain references to the entity's authorized source repository, allowing resolution of external resources under permissive deployment conditions
Why this happens
The underlying bug is insufficient authorization-aware URL validation during catalog placeholder resolution. The implementation may validate that a reference is syntactically acceptable without adequately enforcing that it remains within the resource boundary associated with the entity's source repository.
This maps primarily to CWE-863: Incorrect Authorization, because the resolver may permit access to resources outside the caller's intended authorization scope. It is also related to CWE-918: Server-Side Request Forgery, where a backend retrieves attacker-influenced URLs without sufficiently restricting destinations.
The underlying bug is insufficient authorization-aware URL validation during catalog placeholder resolution. The implementation may validate that a reference is syntactically acceptable without adequately enforcing that it remains within the resource boundary associated with the entity's source repository.
This maps primarily to CWE-863: Incorrect Authorization, because the resolver may permit access to resources outside the caller's intended authorization scope. It is also related to CWE-918: Server-Side Request Forgery, where a backend retrieves attacker-influenced URLs without sufficiently restricting destinations.
Potential impact
- An authenticated user may access data outside the intended repository scope
- Sensitive repository or service content could be disclosed
- The catalog backend could make requests to unintended internal or external resources
- Exposed data may support further compromise or unauthorized discovery
- An authenticated user may access data outside the intended repository scope
- Sensitive repository or service content could be disclosed
- The catalog backend could make requests to unintended internal or external resources
- Exposed data may support further compromise or unauthorized discovery
General mitigation guidance
Mitigation generally focuses on enforcing authorization boundaries throughout URL parsing and resource retrieval.
Common defensive patterns include:
- Restricting placeholder references to explicitly approved repositories, hosts, schemes, and path prefixes
- Resolving URLs only after verifying ownership and authorization for the referenced source
- Applying canonicalization consistently before allowlist comparisons
- Rejecting redirects or revalidating every redirect destination against the same policy
- Limiting backend network egress and protecting access to internal services
- Applying least-privilege permissions to catalog service identities
- Separating user-controlled catalog metadata from trusted configuration
Mitigation generally focuses on enforcing authorization boundaries throughout URL parsing and resource retrieval.
Common defensive patterns include:
- Restricting placeholder references to explicitly approved repositories, hosts, schemes, and path prefixes
- Resolving URLs only after verifying ownership and authorization for the referenced source
- Applying canonicalization consistently before allowlist comparisons
- Rejecting redirects or revalidating every redirect destination against the same policy
- Limiting backend network egress and protecting access to internal services
- Applying least-privilege permissions to catalog service identities
- Separating user-controlled catalog metadata from trusted configuration
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis and code review rules targeting user-controlled URL resolution
- Review of placeholder handlers for missing host, scheme, repository, path, and redirect restrictions
- Tests that verify references outside an entity's source boundary are rejected
- Runtime monitoring for catalog-originated requests to unexpected hosts, internal address ranges, or sensitive paths
- Policy enforcement requiring explicit destination allowlists and authorization checks for backend fetches
- Automated security review tools that flag SSRF-like request flows and authorization gaps
Organizations can look for this issue through:
- Static analysis and code review rules targeting user-controlled URL resolution
- Review of placeholder handlers for missing host, scheme, repository, path, and redirect restrictions
- Tests that verify references outside an entity's source boundary are rejected
- Runtime monitoring for catalog-originated requests to unexpected hosts, internal address ranges, or sensitive paths
- Policy enforcement requiring explicit destination allowlists and authorization checks for backend fetches
- Automated security review tools that flag SSRF-like request flows and authorization gaps
