CVE-2026-106489: Authorization Bypass via Path Traversal in Spotify Backstage TechDocs Backend

Spotify Backstage is an open-source framework used to build centralized developer portals. The TechDocs plugin (@backstage/plugin-techdocs-backend) is responsible for serving technical documentation directly within the Backstage portal. In standard deployment scenarios, documentation is written in Markdown, generated as static assets (HTML, CSS, and images) using tools like MkDocs, and then hosted on external storage systems like Amazon S3, Google Cloud Storage, or Azure Blob Storage.

When the Backstage permission framework is enabled, access to specific entity documentation is regulated through access control policies. When an authenticated developer attempts to view a document, the application performs permission checks using the catalog entity details (namespace, kind, and name). This design prevents unauthorized developers from accessing proprietary designs, infrastructure schemas, or internal API structures.

A vulnerability in the routing component of @backstage/plugin-techdocs-backend breaks this isolation model. When configured with an external TechDocs builder and an external storage provider, the application fails to validate directory containment of requested subpaths. This exposes an attack surface where low-privileged authenticated users can view restricted files from unrelated entities, provided they have access to at least one valid TechDocs repository.

The core flaw resides in how Backstage routes requests for static TechDocs files. The backend application implements an Express route handler to serve these assets under /static/docs/:namespace/:kind/:name.

During request processing, the Backstage permission middleware extracts the parsed parameter values (such as namespace, kind, and name) to execute access authorization lookups. If the user is authorized to read the specified entity, the request is passed to the underlying storage publisher. However, the application uses the raw request path (req.path), which contains the subpath of the requested file, without sanitizing it for path traversal vectors.

An attacker can supply URL-encoded traversal sequences like %2e%2e within the subpath portion of the request. Since the route parameters still map to a valid, permitted entity, the authorization check succeeds. The downstream storage client receives the un-sanitized path containing traversal sequences, which are decoded and normalized during interaction with the external storage provider (e.g., S3 or GCS). This shifts the target file lookup outside of the authorized entity's directory into an unauthorized peer directory.

The official fix, introduced in commit bf6bbf7326ada7d96d7b2c4ebc4a71546106f311, addresses the root cause by validating the containment of requested subpaths before checking permissions or fetching files. It introduces the helper function isPathWithinEntity to check that the path does not escape the parent entity context.

Below is the security validation logic added in router.ts:

import path from 'node:path';
 
// Helper to evaluate if the request path stays within the entity boundary
const isPathWithinEntity = (requestPath: string): boolean => {
  // Decode URL encoding first to catch encoded patterns like %2e%2e
  const relativePath = path.posix.normalize(
    decodeURI(requestPath).replace(/^\/+/, ''),
  );
  // Ensure the path does not resolve to a parent directory
  return relativePath !== '..' && !relativePath.startsWith('../');
};

This verification functions as follows:

1. decodeURI: Decodes URL-encoded sequences like %2e to . and %2f to /. This ensures the validation detects hidden traversal characters.
2. path.posix.normalize: Resolves relative sequences such as . and ... For example, entity-a/../entity-b resolves to entity-b, which would then fail the containment check if normalized from the root.
3. Containment Check: Verifies that the normalized relative path does not equal .. and does not start with ../.

While this fix successfully mitigates standard traversal attacks, several implementation considerations exist:

• Operating System Separators: The function relies on path.posix.normalize. On Windows-based systems where Backstage is run locally with the local file publisher, native Windows path separators (\) are resolved by the OS. Since POSIX normalization does not handle backslashes, a path utilizing Windows separators (e.g., ..%5c..%5c) might bypass POSIX normalization but still cause traversal when accessed via the local Windows filesystem.
• Double Decoding: The path is decoded exactly once inside isPathWithinEntity using decodeURI. If there is an upstream proxy (e.g., NGINX, Cloudflare, or AWS Application Load Balancer) that normalizes double URL-encoded sequences, or if downstream drivers perform extra decodes, double-encoded traversal sequences (%252e%252e) might bypass this single-stage filter.

To execute this attack, an attacker must satisfy several prerequisites. First, they must possess valid credentials to authenticate to the Backstage developer portal. Second, the Backstage portal must have the permission framework enabled, utilize an external TechDocs builder, and fetch documentation from an external storage provider. Finally, the attacker must have read permissions for at least one catalog entity that hosts TechDocs.

In a typical scenario, the attacker identifies a permitted entity (entity-a) and a target restricted entity (entity-b). The attacker then constructs a GET request targeting the /api/techdocs/static/docs/ routing endpoint. By appending a URL-encoded traversal string (%2e%2e/entity-b/index.html) to the authorized endpoint, the attacker initiates the exploit.

An example HTTP request demonstrating this bypass:

GET /api/techdocs/static/docs/default/component/entity-a/%2e%2e/entity-b/index.html HTTP/1.1
Host: backstage.internal.net
Authorization: Bearer <valid_low_privilege_token>
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml

When this request is processed:

• The Express router matches the route parameter :name to entity-a.
• The permission framework validates the token and checks if the user has access to default/component/entity-a.
• Because the user is authorized for entity-a, the system permits the request.
• The backend fetches the raw request path from the storage provider, which normalizes the directory reference to retrieve files from default/component/entity-b/index.html, returning unauthorized internal information to the attacker.

The impact of this vulnerability is classified as Medium, with a CVSS 3.1 score of 6.5. This classification represents high confidentiality impact but zero direct impact on integrity or availability. The vulnerability does not allow write access, meaning attackers cannot alter documentation files, upload malicious assets, or achieve remote code execution on the underlying server.

Despite the Medium severity rating, the confidentiality risks inside corporate developer portals are significant. Technical documentation within developer portals frequently contains sensitive system architecture diagrams, internal endpoint definitions, database models, internal service dependencies, and potentially hardcoded non-production credentials or API keys.

Exposing internal system maps and service dependencies provides high-value intelligence to malicious actors. An attacker can use this information to map the internal attack surface of an organization, identifying high-value targets, security weaknesses, and authentication boundaries for secondary exploits.

The recommended path of remediation is upgrading the affected packages to their patched versions. Specifically, @backstage/plugin-techdocs-backend must be updated to version 2.2.4 or higher, and the core backstage framework must be updated to version 1.54.6 or higher.

To update these packages in your workspace, run the following commands:

# Upgrade the plugin in your backend workspace
yarn workspace backend upgrade @backstage/plugin-techdocs-backend@^2.2.4
 
# Alternatively, execute the core CLI upgrade process
yarn backstage-cli versions:bump

In situations where upgrading cannot be executed immediately, administrators should implement temporary network-level and application-level mitigations. Web Application Firewalls (WAFs) should be configured with custom rules to inspect inbound URL paths targeting the /api/techdocs/static/docs/ endpoint. Any request containing encoded traversal sequences (%2e%2e, %2f, %5c, or native ..) should be blocked immediately.