Impact

An authenticated user with Kubernetes read permissions could access Kubernetes workload data beyond their intended scope by supplying crafted entity data to the deprecated services endpoint. The exposure is limited to read-only access to Kubernetes object metadata across configured clusters.

Patches

Patched in @backstage/plugin-kubernetes-backend version 0.21.8.

Workarounds

- Disable the deprecated /services/:serviceId route by deploying a custom Kubernetes router that omits it. - Restrict access to the kubernetes.resources.read permission to limit the set of users who can reach the endpoint.

Impact

An authenticated Backstage user subject to a DENY policy for search document types could receive search results they were not authorized to view. This affects deployments with permission.enabled: true and an Elasticsearch or OpenSearch search backend.

Patches

- Upgrade @backstage/plugin-search-backend to 2.1.6 - Upgrade @backstage/plugin-search-backend-module-elasticsearch to 1.8.7

Workarounds

If you are unable to upgrade immediately:

- Temporarily modify permission policies to use CONDITIONAL decisions with per-result filtering rather than blanket DENY for search document types - Restrict Elasticsearch/OpenSearch index access at the cluster level so that the search service account can only reach expected Backstage indices, limiting the blast radius if the authorization bypass is triggered.

Impact

An authenticated user holding the standard Kubernetes resource read permission could retrieve sensitive values that the Kubernetes plugin is designed to mask, potentially exposing credentials and other confidential material held in the connected clusters. Exposure is limited to resources that the Backstage service account is permitted to read and that match the targeted catalog entity's namespace and label selector. Deployments whose cluster credentials do not grant read access to these resources are unaffected.

Patches

Fixed in @backstage/plugin-kubernetes-backend version 0.21.9

One behavior change is worth noting for adopters who expose custom resources: a custom resource whose list kind is reported by the API server as SecretList now has the values of its data field masked, matching how core Kubernetes Secrets have always been handled on other query paths.

Workarounds

- Enable the permission framework and restrict kubernetes.resources.read to trusted users. - Scope the RBAC of the service account used to reach each cluster so that it cannot read sensitive resource types. The recommended ClusterRole in the Kubernetes plugin configuration documentation does not grant this access.

Impact

An authenticated user who can execute an affected template and control its repository file location may cause generated content to be written outside the task workspace, within locations writable by the Backstage backend process.

Patches

Patched in @backstage/plugin-scaffolder-backend-module-confluence-to-markdown version 0.3.25

Workarounds

- Restrict execution of templates using the affected action to trusted users. - Remove or disable the affected action until the patched package is deployed.

Impact

Insufficient input validation in the Confluence to Markdown scaffolder module could allow an attacker to influence file write operations during template execution. Exploitation requires a Backstage user to run a template that processes attacker-influenced Confluence content.

Patches

Patched in @backstage/plugin-scaffolder-backend-module-confluence-to-markdown version 0.3.25

Workarounds

If unable to update immediately:

- Restrict Confluence edit access to trusted users. - Review Confluence page content before running scaffolder templates against untrusted pages.

Impact

An attacker who can provide configuration to a TechDocs build may execute code in the generator runtime. Impact is greatest when documentation generation runs with backend credentials or host access.

Patches

Patched in @backstage/plugin-techdocs-node version 1.15.4.

Workarounds

Use external TechDocs generation in an isolated environment without sensitive credentials or host access. Restrict and review changes to documentation configuration before generation.

Backstage is an open framework for building developer portals. Prior to 1.14.6, the @backstage/plugin-techdocs-node package is affected by configuration bypass in techdocs mkdocs.yml sanitization. Insufficient validation of MkDocs configuration during TechDocs generation could allow an authenticated user who can register or modify documentation sources to execute arbitrary commands in the build environment. Impact is limited to resources accessible to the TechDocs backend or build container. This issue is fixed in versions 1.14.6 and 1.15.4.

Impact

An authenticated user who can register catalog entities can provide a crafted mkdocs.yml causing arbitrary OS command execution on the TechDocs build host when the docs are built.

Patches

Patched in @backstage/plugin-techdocs-node, version 1.15.4.

Workarounds

If you cannot upgrade immediately:

- Switch to techdocs.builder: external to isolate TechDocs builds in a container. - Restrict who can register catalog entities with TechDocs annotations. - Audit existing catalog entities for suspicious markdownextensions values in their mkdocs.yml files.

Impact

When TechDocs is configured to build documentation locally or in a container, a user with write access to a registered repository can include configuration values in mkdocs.yml that cause arbitrary code execution during the documentation build process.

Patches

Patched in @backstage/plugin-techdocs-node version 1.15.4

Workarounds

- Configure TechDocs with techdocs.generator.runIn: 'docker' instead of 'local' to provide container isolation, though this does not fully mitigate the risk. - Restrict write access to repositories registered in the Backstage catalog to trusted users.

Impact

When using the local TechDocs publisher (techdocs.publisher.type: 'local'), it was possible for the documentation serving endpoint to follow filesystem references outside the intended documentation tree, potentially exposing host files to authenticated users.

This is mitigated by the fact that exploration requires preconditions that do not arise through normal MkDocs operation. Cloud-based publishers (S3, GCS, Azure Blob Storage) are not affected.

Patches

Patched in @backstage/plugin-techdocs-node version 1.15.4

Workarounds

If you cannot upgrade immediately, consider switching to an external store for published TechDocs content (e.g. awsS3, googleGcs, or azureBlobStorage publishers)

Backstage is an open framework for building developer portals. Prior to 1.15.4, the @backstage/plugin-techdocs-node package is affected by techdocs arbitrary file read via mkdocs snippets. Unsafe path resolution in TechDocs source tree handling allows an authenticated user who can register documentation sources to include content from outside the intended documentation boundary. Depending on deployment, this may expose files readable by the build process. This issue is fixed in version 1.15.4.

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

Users with the ability to commit changes to a repository that uses TechDocs can circumvent the MkDocs configuration file sanitizer introduced in response to CVE-2026-25153 and execute arbitrary code on the TechDocs backend host during documentation generation.

Patches

Patched in@backstage/plugin-techdocs-node version 1.15.4

Workarounds

If you cannot upgrade immediately:

- Use Docker mode with restricted access: Configure TechDocs with runIn: docker instead of runIn: local. This provides container isolation, though it does not fully mitigate the risk. - Limit repository write access to trusted parties, since exploitation requires the ability to commit files to a repository with TechDocs enabled. - Review incoming changes to MkDocs configuration files as part of your code review process.

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

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.

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 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

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

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 Backstage user could craft a catalog entity with placeholder directives that reference resources outside the entity's source repository. Under certain configurations, this could allow access to data not intended to be available to the user.

Patches

Patched in @backstage/plugin-catalog-backend version 3.9.1

Workarounds

If you're not able to update immediately:

- Limit the scope of integration credentials (e.g., GitHub tokens) to only the repositories that Backstage needs to access.

Backstage is an open framework for building developer portals. Prior to 3.9.1, the @backstage/plugin-catalog-backend package is affected by inconsistent catalog property permission evaluation. In deployments that use affected value-based catalog permission conditions as a confidentiality boundary, an authenticated user could receive catalog entity data that policy authors intended to restrict. This issue is fixed in version 3.9.1.

Impact

Under certain configurations, the catalog backend could process location types that were not intended to be allowed, potentially leading to unintended file access on the backend host.

Patches

Patched in @backstage/plugin-catalog-backend version 3.9.1

Workarounds

No practical workarounds are available. Upgrade to the patched version.

Impact

An authenticated internal user who can execute the affected actions may cause the backend to contact unintended destinations and disclose Sentry integration credentials. Subsequent impact depends on network reachability and the privileges granted to the configured token.

Patches

Upgrade @backstage/plugin-scaffolder-backend-module-sentry to version 0.3.8 or later. The fixed package is available in Backstage v1.54.8 and Backstage v1.55.0.

The update removes custom action-level apiBaseUrl values. Move any such value to scaffolder.sentry.apiBaseUrl before upgrading.

Workarounds

- Disable the affected actions until the patched package is deployed. - Restrict scaffolder.action.execute permission for the affected Sentry actions to trusted users and templates.

Impact

An authenticated attacker with control over a TechDocs source repository could cause a documentation build to retrieve and publish data from network locations reachable by the build environment. Exposure depends on deployment topology, build mode, and target endpoint protections. Modern cloud metadata services that require tokens or special headers are not directly accessible through the affected behavior.

Patches

Upgrade @backstage/plugin-techdocs-node to a patched version for the applicable release line:

- 1.14.x: upgrade to 1.14.7 or later in that line, available in Backstage v1.50.6. - 1.15.x: upgrade to 1.15.5 or later, available in Backstage v1.54.8. - Current mainline: upgrade to 2.0.0 or later, available in Backstage v1.55.0.

The update removes MkDocs plugins outside the built-in allowlist. To retain additional plugins, review them and configure techdocs.generator.mkdocs.dangerouslyAllowAdditionalPlugins, or supply dangerouslyAllowAdditionalPlugins when creating the generator directly. Plugins supplied through defaultPlugins remain permitted.

Workarounds

- Restrict control of TechDocs source repositories and catalog registration to trusted maintainers. - Run documentation builders with outbound access to private and link-local networks denied. - Require token- or header-protected cloud instance metadata services.

In ONNX before 1.21.0, the 'saveexternaldata' function builds the external-data file path from the model's externaldata location field and opens it for writing without 'ONOFOLLOW/OEXCL', after a non-atomic 'os.path.isfile()' check. A local attacker with write access to the directory where a victim serializes external data can deterministically pre-plant a symlink that is being followed, causing the victim's write to append to any file the victim can write, e.g. ~/.ssh/authorizedkeys, cron files, or application configs. Fixed in 1.21.0.

PyTorch torchvision through 0.28.0, fixed in commit 4e05dc2, contains an out-of-bounds heap read vulnerability in the GIF decoder's readfromtensor callback that passes unclamped length to memcpy. Attackers can supply malicious or truncated GIF files to cause denial of service via segmentation fault or disclose adjacent heap memory contents.

cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates. From 1.18.0 until 1.19.6 and 1.20.3, Challenge resources under acme.cert-manager.io can be created directly by namespace users without admission validation tying the Challenge to an Order, owner reference, or Issuer-selected solver, allowing attacker-controlled Challenge.spec.solver values referencing a ClusterIssuer to bypass DNS01 solver selectors such as dnsZones, dnsNames, and matchLabels and cause cert-manager to use ClusterIssuer DNS credentials for attacker-selected provider settings and DNS names, including disclosure of X-Api-User and X-Api-Key headers for acme-dns. This issue is fixed in versions 1.19.6 and 1.20.3.

Impact Kustomize bake operations allow unsafe tag processing. This can lead to RCE type exploits on the rosco pods when doing kustomize bakes. This ONLY is possible when using Kustomize. The simple solution is to block kustomize operations and instead use another provider.

Workarounds Disable kustomize bakes

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.3 and 2.12.12, a WebSocket listener could route requests for the MQTT-over-WebSocket path into MQTT handling even when MQTT was not configured, allowing an unauthenticated client with access to the WebSocket listener to reach uninitialized MQTT state and crash the server process. This issue is fixed in versions 2.14.3 and 2.12.12.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.3 and 2.12.12, a client could be registered as the configured noauthuser through a parser path used when the first client operation was not CONNECT, bypassing user-level connection restrictions such as allowedconnectiontypes or proxyrequired that normal authentication would apply. This issue is fixed in versions 2.14.3 and 2.12.12.