If the Backstage instance is configured with integration credentials, such as broad GitHub tokens, these credentials may be implicitly used to fetch data from resources outside the intended source repository. This behavior increases the risk of unauthorized data disclosure, as the application fails to enforce appropriate path or domain boundaries during the placeholder resolution process. Defenders should prioritize updating the plugin to version 3.9.1 and reviewing the scope of all configured integration credentials to follow the principle of least privilege.

Impact

The vulnerability affects users of the Backstage catalog who have permissions to manage entity definitions. Successful exploitation can lead to unauthorized access to sensitive internal data or repository content that the attacker would not otherwise be permitted to view, depending on the scope of the integration tokens assigned to the Backstage service.

Recommendation

• Upgrade the @backstage/plugin-catalog-backend package to version 3.9.1 or later to remediate CVE-2026-106498.
• Review and restrict the scope of integration credentials (such as GitHub, GitLab, or Bitbucket tokens) assigned to the Backstage backend to limit access to only required repositories.
• Audit existing catalog entity definitions for suspicious placeholder directives that reference unauthorized internal or external endpoints.

This flaw allows an attacker or a compromised service to perform actions beyond its intended scope, including executing write operations on plugins that were explicitly restricted to read-only access. Because this bypass occurs within the internal delegation logic, the risk is higher in environments where service-to-service authentication relies heavily on delegated credentials. Defenders must prioritize upgrading the vulnerable package or implementing network-level access controls to restrict access to the backend API.

Impact

The vulnerability poses a significant risk to the integrity of systems integrated with Backstage. If exploited, an attacker could gain unauthorized write access to resources managed by plugins, potentially modifying sensitive configurations or data. This bypass affects organizations using Backstage for service-to-service interactions where granular access control is enforced via credential delegation. The scope of impact is contingent upon the number of plugins relying on these specific delegation paths and the privilege level of the credentials involved.

Recommendation

• Upgrade the @backstage/backend-defaults package to version 0.17.8 or later immediately to address CVE-2026-106492.
• If an immediate upgrade is not possible, rotate restricted credentials and replace them with purpose-specific, unrestricted credentials scoped strictly to trusted consumers.
• Restrict network-level access to all Backstage backend API endpoints, ensuring only authorized callers and internal services can communicate with the API.

Impact

Successful exploitation allows for unauthorized access to catalog entities and sensitive resources managed by Backstage by assuming the identity of another user. This can lead to privilege escalation if the spoofed user account holds administrative roles or high-level access to internal developer portal documentation, service metadata, or infrastructure configurations. No specific victim counts have been reported, but organizations utilizing email-based OIDC identity resolution are at risk if their provider allows unverified addresses.

Recommendation

• Upgrade the @backstage/plugin-auth-backend-module-oidc-provider package to version 0.4.20 or later to include the patch for CVE-2026-106488.
• Review OIDC provider configurations and disable email-based identity resolution if email verification cannot be strictly enforced at the provider level.
• Monitor authentication logs for unexpected account mappings or user sessions originating from non-standard or untrusted OIDC provider issuers.

Impact

Successful exploitation allows an authenticated attacker to perform unauthorized file operations on the host running the Backstage backend. This can result in the compromise of backend confidentiality (sensitive file exfiltration), integrity (malicious code injection), or availability (system file deletion). The scope of impact is limited by the permissions of the process running the Backstage backend service.

Recommendation

• Upgrade @backstage/plugin-scaffolder-backend-module-bitbucket-cloud to version 0.3.10 or later.
• Upgrade @backstage/plugin-scaffolder-backend-module-bitbucket-server to version 0.2.25 or later.
• Apply administrative restrictions on Scaffolder template execution, limiting them to trusted users only.
• Audit existing Scaffolder templates to identify and restrict actions that accept user-controlled target repository inputs until patching is complete.

Impact

Successful exploitation allows an authenticated internal user to abuse the Sentry scaffolder action to conduct SSRF attacks. This leads to the potential exfiltration of sensitive integration credentials and provides a foothold to pivot into internal network segments reachable by the Backstage backend service. The severity is high as it facilitates unauthorized credential access and lateral movement potential within the internal development environment.

Recommendation

• Upgrade the @backstage/plugin-scaffolder-backend-module-sentry package to version 0.3.8 or later.
• Apply the configuration change by moving any custom apiBaseUrl values from action-level definitions to the scaffolder.sentry.apiBaseUrl global setting.
• Restrict the scaffolder.action.execute permission for Sentry-related actions to a strictly controlled list of trusted users and templates until patching is complete.
• Disable the vulnerable Sentry scaffolder actions as a temporary workaround if immediate patching is not possible.

Impact

The vulnerability poses a critical risk to organizations relying on Backstage for service orchestration and workflow automation. If successfully exploited, attackers or malicious insiders can obtain privileged credentials that permit unauthorized interaction with integrated third-party systems. This can result in significant data breaches or unauthorized system state changes across the organization's cloud and development infrastructure.

Recommendation

• Upgrade @backstage/plugin-scaffolder-backend to version 4.1.0 or later immediately to patch CVE-2026-106501.
• If an upgrade is not immediately possible, modify the Scaffolder configuration to apply the isTaskOwner condition to scaffolder.task.read, ensuring that users are restricted to viewing only their own tasks.
• Audit active Scaffolder workflows and their integrated services for any potentially compromised credentials that may have been exposed through unauthorized task access.

When TechDocs is configured to perform documentation builds locally or within a container environment, an attacker with repository write access can inject malicious configuration directives. These directives are processed during the documentation build stage, leading to the execution of arbitrary commands on the build infrastructure. This vulnerability poses a high risk to organizations that permit documentation builds from untrusted or compromised repository contributors. The vulnerability was remediated in @backstage/plugin-techdocs-node version 1.15.4.

Attack Chain

1. Attacker gains write access to a repository registered in the Backstage catalog.
2. Attacker modifies the mkdocs.yml file within the repository to include malicious configuration parameters.
3. The TechDocs plugin triggers a build process for the documentation, either locally or within a container runner.
4. The build process, facilitated by plugin-techdocs-node, parses the manipulated mkdocs.yml file.
5. The plugin fails to properly sanitize or validate the user-controlled configuration values.
6. The underlying build engine executes the injected commands as part of the MkDocs build process.
7. Attacker achieves remote code execution within the build environment (e.g., the Backstage host or the container instance).

Impact

Successful exploitation allows an attacker to execute arbitrary code on the infrastructure hosting the TechDocs build service. This can lead to credential theft, lateral movement within the build environment, or exposure of sensitive data processed by the documentation pipeline. Organizations using TechDocs in 'local' build mode are at the highest risk, though containerized deployments may also be compromised depending on the container runtime's isolation capabilities.

Recommendation

Prioritize the upgrade of @backstage/plugin-techdocs-node to version 1.15.4 or later across all Backstage instances to address CVE-2026-106509. As a compensatory control for environments where immediate patching is not possible, modify the techdocs.generator.runIn configuration to use 'docker' instead of 'local' to enforce container-level isolation. Furthermore, strictly enforce repository write permissions to ensure only trusted users can modify documentation configurations and trigger builds.