GHSA-vwp5-f99x-x3rq: Medium severity npm/@backstage/plugin-scaffolder-backend vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@backstage/plugin-scaffolder-backendto a version that resolves this vulnerability.Fixed in 4.1.0 - Upgrade
Upgrade
@backstage/plugin-scaffolder-backendto a version that resolves this vulnerability.Fixed in 4.1.0 - Configuration
Disable task recovery to reduce secret retention after a task is claimed; this does not protect secrets in queued tasks and is not a complete mitigation.
Backstage scaffolder task recovery = disabled - Compensating control
At the gateway or reverse proxy, reject task-list requests that specify custom ordering, or allow ordering only by created_at, status, and created_by.
- Compensating control
Restrict scaffolder task creation and task-read permissions to trusted users, preferably using owner-based task-read conditions.
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
An authenticated Backstage user who can create and read the relevant scaffolder tasks may be able to exploit it. Restricting task creation and read access to trusted users, preferably with owner-based task-read conditions, reduces exposure.
What conditions are required to recover confidential task data?
The target task's secrets must still be retained, the attacker must be able to view that task, and they must know the secret structure. Exploitation also requires repeated requests and is only possible under these specific conditions.
What can be done before upgrading?
Configure the gateway or reverse proxy to reject task-list requests with custom ordering, or permit ordering only by created_at, status, and created_by. You can also restrict scaffolder task permissions; disabling task recovery may reduce retention after a task is claimed but does not protect queued-task secrets.
What version contains the fix?
The issue is patched in @backstage/plugin-scaffolder-backend version 4.1.0.