CVE-2026-106502: Sensitive Information Exposure in Backstage Scaffolder Backend

The Backstage Open-Source Developer Portal Framework provides a Software Templates feature (the Scaffolder) to automate infrastructure provisioning and codebase bootstrap tasks. This functionality is managed by the @backstage/plugin-scaffolder-backend package, which coordinates step-by-step actions like cloning repositories, creating directories, and registering catalog entities.

To perform operations on behalf of users or the organization, the Scaffolder backend requires access to backend-managed secrets. These secrets include personal access tokens (PATs) for version control platforms like GitHub or GitLab, as well as cloud platform access keys.

Prior to version 4.1.0, a vulnerability existed in the error handling and logging paths of the Scaffolder execution engine. Under certain conditions, when a template execution step or persistence checkpoint failed, the backend leaked the secrets used during task execution into the task's failure events. These unredacted events were recorded in the backend database and exposed to authenticated users via the Scaffolder API.

The underlying flaw resides in how the NunjucksWorkflowRunner and the associated Winston logging mechanism managed exceptions. In the event of a step failure, the workflow runner caught the raw error object thrown by the step and serialized it into the database via the taskTrack.markFailed(step, err) method.

Because Node.js Error objects, third-party API client exceptions, and database errors often preserve input parameters within their message or stack trace strings, the unredacted secrets were written directly into the DB. This bypasses the typical stdout/stderr logging layers that might otherwise apply basic masking rules.

Furthermore, several specific design factors exacerbated the leak:

1. Checkpoint Failures: If checkpoint state updates failed, the system stringified the raw error via stringifyError(err) without invoking log-redaction filters.

2. AggregateError Traps: When multiple parallel actions or actions combined with checkpoint updates failed, the runtime raised an AggregateError. Native JavaScript AggregateError objects retain their constituent error payloads in an internal .errors array. Standard redaction systems that operate on top-level properties missed these deeply nested child errors.

3. Transformation Gaps: The Winston log redacter used basic key-value equality to build redaction lists. If a template transformed a secret (such as changing uppercase or lowercase using Nunjucks filters like ${{ secrets.token | upper }}), the redacter could not correlate the transformed token with the original secret representation, allowing the transformed secret to bypass validation filters.

An analysis of the patch in commit 3f1e869708f002fb9838624b7379deb251691b47 reveals the precise architectural changes made to mitigate this exposure.

In plugins/scaffolder-backend/src/scaffolder/tasks/NunjucksWorkflowRunner.ts, the exception handling was modified to actively redact the caught errors before passing them to the state recorder:

// Before Patch
} catch (err) {
  await taskTrack.markFailed(step, err);
  await stepTrack.markFailed();
  throw err;
}
 
// After Patch
} catch (cause) {
  const err = taskLogger.redactError(cause);
  await taskTrack.markFailed(step, err);
  await stepTrack.markFailed();
  throw err;
}

The implementation of redactError in logger.ts was rewritten to sanitize errors. Instead of modifying the error object in-place, which could leave nested fields intact, the patch creates a brand-new, sterile error replica holding only sanitized name, message, and stack properties:

const redactError = (error: unknown): ErrorLike => {
  if ((typeof error !== 'object' || error === null) && typeof error !== 'function') {
    return typeof error === 'string'
      ? createSanitizedError('Error', redact(error))
      : createUnknownError(error);
  }
 
  const errorLike = error as Partial<ErrorLike>;
  let originalName: unknown;
  let originalMessage: unknown;
  let originalStack: unknown;
 
  try {
    originalName = errorLike.name;
    originalMessage = errorLike.message;
    originalStack = errorLike.stack;
  } catch {
    return createSanitizedError(); // Safe fallback for throwing getters
  }
 
  if (typeof originalName !== 'string' || !originalName || typeof originalMessage !== 'string') {
    return createUnknownError(error);
  }
 
  const name = redact(originalName);
  const message = redact(originalMessage);
  const stack = typeof originalStack === 'string' ? redact(originalStack) : undefined;
 
  return createSanitizedError(name, message, stack);
};

This defensive approach effectively strips out any non-standard metadata, custom error attributes, or nested prototype properties, preventing data leaks from alternative object fields.

In terms of completeness, this fix is highly robust. By detaching custom attributes and recreating a standardized object rather than attempting to recursively filter unknown nested fields, the patch addresses both the AggregateError issue and any potential exploitation involving custom getter functions on error objects.

To exploit this vulnerability, an attacker must have authenticated access to the Backstage instance with permissions sufficient to register a template, trigger a template run, or read the event log of an existing task.

An attacker can trigger this information leak by crafting a software template that deliberately forces a failure within an action executing with elevated credentials.

For example, an attacker can define a step that relies on a secret but targets an invalid endpoint or provides bad parameters to a CLI execution. When the step fails, the action handler raises an exception containing the evaluated secret parameter. This unredacted string is written directly to the task_events database.

The attacker then makes an authorized HTTP request to the Scaffolder events endpoint for that specific task: /api/scaffolder/v2/tasks/<task_id>/events. The response contains the raw execution logs, including the error object fields containing the plain-text credentials.

The security impact of this vulnerability is classified as Medium. Although it leads to high confidentiality compromise (C:H), exploitation is restricted by attack complexity and privileges required. The attacker must possess authenticated access to the Backstage platform and the ability to trigger or monitor specific Scaffolder tasks.

Despite the Medium CVSS rating, the operational risk remains significant. The credentials stored in Backstage software templates typically belong to high-privilege service accounts or organization-wide deploy tokens. Exfiltration of these tokens can allow attackers to bypass standard access controls on Git repositories, enabling supply chain attacks or giving them the ability to write malicious code to production branches.

Remediation requires upgrading the @backstage/plugin-scaffolder-backend package or the overarching Backstage release.

Because task events are stored in the database, upgrading the software prevents future leaks but does not delete historical records. Security teams should run cleanup scripts to purge potentially leaked secrets from the database.

For teams unable to patch immediately, temporary mitigations include implementing strict access controls on the task events API and monitoring database event tables for standard credential regular expressions.