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.
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
- Follow the recommendation in the Backstage Threat Model to limit access to creating and updating templates - Restrict who can create and execute Scaffolder templates using the permissions framework - Audit existing templates for symlink usage - Run Backstage in a containerized environment with limited filesystem access
References
- CWE-59: Improper Link Resolution Before File Access - OWASP Path Traversal
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
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.
Backstage is an open framework for building developer portals. 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 read arbitrary files via the debug:log action by creating a symlink pointing to sensitive files (e.g., /etc/passwd, configuration files, secrets); delete arbitrary files via the fs:delete action by creating symlinks pointing outside the workspace, and 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. This vulnerability is fixed in @backstage/backend-defaults versions 0.12.2, 0.13.2, 0.14.1, and 0.15.0; @backstage/plugin-scaffolder-backend versions 2.2.2, 3.0.2, and 3.1.1; and @backstage/plugin-scaffolder-node versions 0.11.2 and 0.12.3. Users should upgrade to these versions or later. Some workarounds are available. Follow the recommendation in the Backstage Threat Model to limit access to creating and updating templates, restrict who can create and execute Scaffolder templates using the permissions framework, audit existing templates for symlink usage, and/or run Backstage in a containerized environment with limited filesystem access.
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
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.
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.
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.
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.