Backstage Scaffolder EUVD-2026-94069

Exploitation requires all of the following concrete conditions: (1) the attacker is an authenticated Backstage user with permission to create and read scaffolder tasks; (2) the deployment uses the scaffolder permission framework with restrictive action permissions that actually DENY at least one action; (3) an affected template passes a sensitive value - a task secret ('${{ secrets.X }}'), an environment secret ('${{ environment.secrets.X }}'), or a secret-derived 'each' key - as input to that denied action. Limiting factors: this does not affect default deployments without action-level permission denials, does not affect templates that do not route secrets through denied actions, and requires authenticated task-read access to observe the logs. Absent restrictive action permissions and secret-bearing denied-action inputs, there is no exposure.

This is a genuine but conditional, moderate-severity information-disclosure flaw (CWE-532) rather than a top-tier priority. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5) signals a network-reachable, low-privilege, no-interaction issue with high confidentiality impact and no integrity/availability effect. However, PR:L correctly reflects that the attacker must be an authenticated Backstage user able to create and read scaffolder tasks, and the description adds preconditions the base vector understates: the deployment must use restrictive action permissions AND use affected templates, and exploitation requires a denied action whose input contains a sensitive value - meaning AC:L is arguably too generous (see assessed vector, where I use AC:H). No EPSS score was provided, there is no CISA KEV listing (not actively exploited), and no public exploit was supplied - the only code is the vendor patch and its regression tests, which is a fix, not a weaponized PoC. Net: a confirmed real bug worth patching, but its practical exploitability is gated by specific permission configuration and the presence of secrets in denied-action inputs, so it is 'high CVSS confidentiality but narrow real-world preconditions' rather than a mass-exploitation threat.

An authenticated Backstage user with permission to create and read scaffolder tasks submits or runs a template that passes a secret (e.g. '${{ secrets.token }}' or '${{ environment.secrets.AWS_ACCESS_KEY }}') as input to a scaffolder action that is blocked by the deployment's restrictive action permissions. When the action is denied, the pre-4.1.0 error handling renders the input (including the resolved secret) into the task log, which the same user can then read to harvest the secret. No public exploit exists; the behavior is demonstrated by the vendor's own regression tests in the patch commit.