Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Scaffolder actions that interact with source control systems may not consistently enforce the intended credential boundaries under certain configurations. An authenticated user could perform operations with broader access than intended. Patches - @backstage/plugin-scaffolder-backend version 4.1.0 - @backstage/plugin-scaffolder-backend-module-azure version 0.2.25 - @backstage/plugin-scaffolder-backend-module-bitbucket-cloud version 0.3.10 - @backstage/plugin-scaffolder-backend-module-bitbucket-server version 0.2.25 - @backstage/plugin-scaffolder-backend-module-github version 0.9.13 - @backstage/plugin-scaffolder-backend-module-gitlab version 0.11.10 The fix introduces a new configuration option that enforces user-provided credentials for supported SCM actions. The new behavior is opt-in for compatibility. After upgrading, set: Before enabling this setting, review and update your templates as described in the software templates documentation referred to below. Workarounds If you…
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated Backstage user who can read another user's Scaffolder task may receive internal execution data. In deployments where that data contains credentials for an external service, this may permit disclosure and unauthorized changes in that external service. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Configure scaffolder.task.read with the isTaskOwner condition so users can only read tasks they created. - Restrict affected integrations and workflows to trusted operators until an upgrade is available.
Recommended action: Upgrade to 4.1.0, 4.0.3, 3.4.1 or 3.3.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Deployments that configure sensitive scaffolder.defaultEnvironment.secrets and allow an attacker to create or modify Scaffolder templates are affected. A template author could cause secret-derived values used during template iteration to be persisted in task logs, exposing those values to users with access to the resulting task logs. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Restrict permission to create or update Template entities to fully trusted parties, as recommended by the Backstage threat model. - If that restriction cannot be guaranteed, remove sensitive values from scaffolder.defaultEnvironment.secrets until a patched version is available. No complete workaround is known that preserves both untrusted template authoring and access to sensitive default-environment secrets.
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user with access to affected Scaffolder templates could bypass configured action restrictions. Depending on integration credentials, this could grant unauthorized access to repositories and related source-control resources. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Restrict affected Scaffolder actions to trusted users and configure source-control integrations with least-privilege credentials.
Recommended action: Upgrade to 4.1.0, 4.0.3, 3.4.1 or 3.3.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user with permission to create and access Scaffolder tasks may, under specific timing and deployment conditions, affect files accessible to the Backstage backend. If backend application files are writable, the confidentiality, integrity, and availability of the backend may be compromised. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Restrict Scaffolder task creation and task-read permissions to trusted users through the permission policy. - Limit who can register or modify templates and which Scaffolder actions may execute. - Run backend application files read-only outside a dedicated, least-privilege Scaffolder working directory. References - Authorizing Scaffolder tasks, parameters, steps, and actions
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated internal user may be able to view metadata for scaffolder tasks outside the visibility intended by a deployment's permission policy. Stored task secrets are not included in the affected response, and no integrity or availability impact was identified. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Restrict the scaffolder task-list endpoint at the ingress or authenticating proxy to users who are permitted to view all tasks. - Avoid placing sensitive values in template input parameters until the patched package is deployed.
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Under specific template and failure conditions, an authenticated user may be able to retrieve sensitive values from Scaffolder task events. This can expose backend-managed credentials used during task execution. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Restrict Scaffolder template execution and task-event access to trusted users until the patched version is deployed.
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - Restrict scaffolder task creation and task-log reading to trusted users. - Avoid placing centrally managed sensitive values in inputs to actions that may be denied until upgrading. References - Backstage threat model - Backstage permissions overview
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated Backstage user with permission to create and read relevant scaffolder tasks may be able to infer confidential task data under specific conditions. Successful exploitation requires retained task secrets, visibility of a target task, knowledge of the secret structure, and repeated requests. Patches Patched in @backstage/plugin-scaffolder-backend version 4.1.0 Workarounds - At the gateway or reverse proxy, reject task-list requests that specify custom ordering, or allow ordering only by createdat, status, and createdby. - Restrict scaffolder task creation and task read permissions to trusted users, preferably using owner-based task-read conditions. - Disabling task recovery can reduce secret retention after a task is claimed, but it does not protect secrets in queued tasks and should not be treated as complete mitigation.
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated users with permission to execute scaffolder dry-runs can gain access to server-configured environment secrets through the dry-run API response. Secrets are properly redacted in log output but not in all parts of the response payload. Deployments that have configured scaffolder.defaultEnvironment.secrets are affected. Patches This is patched in @backstage/plugin-scaffolder-backend version 3.1.5 Workarounds Remove or empty the scaffolder.defaultEnvironment.secrets configuration from app-config.yaml. Alternatively, restrict access to the scaffolder dry-run functionality via the permissions framework. References - Backstage Scaffolder Backend documentation
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious scaffolder template can bypass the log redaction mechanism to exfiltrate secrets provided run through task event logs. The attack requires: - The ability to register a template in the catalog - A victim who executes the malicious template Patches Patched in @backstage/plugin-scaffolder-backend version 3.1.4 Workarounds - Implement a custom permission policy that restricts scaffolder.task.read so users can only read their own task logs - Restrict who can register templates in the catalog to trusted users only Resources - Backstage Scaffolder permissions documentation: https://backstage.io/docs/permissions/plugin-authors/01-setup/ - Backstage Threat Model: https://backstage.io/docs/overview/threat-model/
Recommended action: Upgrade to 3.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Multiple Scaffolder actions and archive extraction utilities were vulnerable to symlink-based path traversal attacks. An attacker with access to create and execute Scaffolder templates could exploit symlinks to: 1. Read arbitrary files via the debug:log action by creating a symlink pointing to sensitive files (e.g., /etc/passwd, configuration files, secrets) 2. Delete arbitrary files via the fs:delete action by creating symlinks pointing outside the workspace 3. Write files outside the workspace via archive extraction (tar/zip) containing malicious symlinks This affects any Backstage deployment where users can create or execute Scaffolder templates. Patches This vulnerability is fixed in the following package versions: - @backstage/backend-defaults version 0.12.2, 0.13.2, 0.14.1, 0.15.0 - @backstage/plugin-scaffolder-backend version 2.2.2, 3.0.2, 3.1.1 - @backstage/plugin-scaffolder-node version 0.11.2, 0.12.3 Users should upgrade to these versions or later. Workarounds -…
Recommended action: Upgrade to 3.1.1, 3.0.2 or 2.2.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A logging flaw in Backstage Scaffolder’s fetch:template action up to @backstage/plugin-scaffolder-backend 2.1.0 may write template secrets to logs. The action emitted a duplicate, pre-redaction copy of input parameters, so values provided via the {{ secrets }} bag could appear in local/server logs when the action ran. Exploitation requires use of the secrets argument and access to Scaffolder/build logs; integrity and availability are unaffected. Fix: upgrade to 2.1.1, which removes the duplicate log path and ensures secrets are redacted. Mitigation: avoid passing {{ secrets }} to fetch:template if upgrade is not possible. Open an issue in the Backstage repository Visit our Discord, linked to in Backstage README
Recommended action: Upgrade to 2.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Backstage scaffolder-backend plugin uses a templating library that requires a sandbox, as it by design allows for code injection. The library used for this sandbox so far has been vm2, but in light of several past vulnerabilities and existing vulnerabilities that may not have a fix, the plugin has switched to using a different sandbox library. Impact A malicious actor with write access to a registered scaffolder template could manipulate the template in a way that allows for remote code execution on the scaffolder-backend instance. This was only exploitable in the template YAML definition itself and not by user input data. Patches This is vulnerability is fixed in version 1.15.0 of @backstage/plugin-scaffolder-backend. Workarounds Note that the Backstage Threat Model states that scaffolder templates are considered to be a sensitive area that with the recommendation that you control access and perform manual reviews of changes to the scaffolder templates. The exploit is of a…
Recommended action: Upgrade to 1.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The templating library used by the scaffolder backend assumes that templates are trusted which is an undesired property of the scaffolder-backend. This has now been mitigated by sandboxing the template code execution. Impact A malicious actor with write access to a registered scaffolder template could manipulate the template in a way that allows for remote code execution on the scaffolder-backend instance. This was only exploitable in the template yaml definition itself and not by user input data. Patches This is vulnerability is patched in version 0.15.14 of @backstage/plugin-scaffolder-backend. For more information If you have any questions or comments about this advisory: Open an issue in the Backstage repository Visit our chat, linked to in Backstage README
Recommended action: Upgrade to 0.15.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious actor with write access to a registered scaffolder template is able to manipulate the template in a way that writes files to arbitrary paths on the scaffolder-backend host instance. This vulnerability can in some situation also be exploited through user input when executing a template, meaning you do not need write access to the templates. This method will not allow the attacker to control the contents of the injected file however, unless the template is also crafted in a specific way that gives control of the file contents. Patches This vulnerability is fixed in version 0.15.14 of the @backstage/plugin-scaffolder-backend. Workarounds This attack is mitigated by restricting access and requiring reviews when registering or modifying scaffolder templates. For more information If you have any questions or comments about this advisory: Open an issue in the Backstage repository Visit our chat, linked to in Backstage README
Recommended action: Upgrade to 0.15.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious actor could read sensitive files from the environment where Scaffolder tasks are run. The attack is executed by crafting a custom Scaffolder template with a publish:github:pull-request action using a particular source path. When the template is executed the sensitive files would be included in the published pull request. This vulnerability is mitigated by the fact that an attacker would need access to create and register templates in the Backstage catalog, and that the attack is very visible given that the exfiltration happens via a pull request. Patches The vulnerability is patched in the 0.15.9 release of @backstage/plugin-scaffolder-backend. For more information If you have any questions or comments about this advisory: Open an issue in the Backstage repository Visit our chat, linked to in Backstage README
Recommended action: Upgrade to 0.15.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.