CVE-2026-106504 in Backstage
Summary
by MITRE • 10/07/2026
Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by sensitive information exposure in scaffolder task logs. An authenticated user who can create and read scaffolder tasks may be able to observe sensitive values in task logs in deployments with restrictive action permissions and affected templates. Exploitation requires a denied action whose input contains such a value. This issue is fixed in version 4.1.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The Backstage developer portal framework, prior to version 4.1.0, contained a vulnerability within the @backstage/plugin-scaffolder-backend package that resulted in the exposure of sensitive information through scaffolder task logs. This flaw specifically impacts environments where restrictive action permissions are configured alongside templates that process user-supplied input containing secret values such as API keys, passwords, or tokens. The core technical issue stems from the logging mechanism within the scaffolder backend not adequately sanitizing or masking these sensitive inputs before writing them to the execution logs. Consequently, when a task is executed, any secrets provided in the input parameters are written into the log files in plaintext, creating an unintended data leakage channel that persists regardless of other security controls like access restrictions on specific actions.
The operational impact of this vulnerability allows authenticated users who possess the ability to create and read scaffolder tasks to observe these sensitive values by inspecting the logs associated with denied or failed action executions. Exploitation does not require privilege escalation beyond standard user permissions; it only requires that a user can trigger an action for which they lack permission, provided their input contains secret data. When such an attempt is made and subsequently blocked due to restrictive permissions, the system still processes and logs the initial request parameters before denying access. This means that even though the action itself fails or is rejected, the sensitive information contained within the payload remains visible in the log output accessible to any user with read privileges on scaffolder tasks. This scenario effectively bypasses intended authorization controls by leveraging the side effect of logging rather than exploiting a direct permission flaw.
From a classification perspective, this vulnerability aligns with CWE-532, which covers information exposure through log files, and falls under the ATT&CK technique T1078, Valid Accounts, as it relies on legitimate authenticated access to extract sensitive data. The issue highlights a common pitfall in software development where logging mechanisms are implemented without considering the sensitivity of input data or implementing proper redaction policies for secrets. This lack of sanitization creates an attack vector that can be exploited by insider threats or compromised accounts with limited privileges, potentially leading to further compromise if those exposed credentials have broader access elsewhere in the infrastructure.
To mitigate this vulnerability, organizations must upgrade the @backstage/plugin-scaffolder-backend package to version 4.1.0 or later, where the issue has been resolved through improved handling of sensitive inputs within the logging pipeline. In addition to upgrading, it is recommended that administrators implement strict input validation and sanitization practices across all scaffolder templates to ensure no secret values are passed as raw parameters. Furthermore, organizations should review their logging configurations to enforce redaction policies for known sensitive data patterns such as passwords or API keys at the application level before logs are written to disk or external monitoring systems. Regular audits of log access permissions and implementation of least-privilege principles for log viewing rights can also help minimize the risk associated with any residual information exposure in complex developer portal environments.