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.

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

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.

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

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

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.

Background

The CNI portmap plugin allows containers to emulate opening a host port, forwarding that traffic to the container. For example, if a host has the IP 198.51.100.42, a container may request that all packets to 198.51.100.42:53 be forwarded to the container's network.

Vulnerability

When the portmap plugin is configured with the nftables backend, it inadvertently forwards all traffic with the same destination port as the host port, ignoring the destination IP. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node.

In the given example above, traffic destined to port 53 but for a separate container would still be captured and forwarded, even though it was not destined for the host.

Impact

Containers (i.e. kubernetes pods) that request HostPort forwarding can intercept all traffic destined for that port. This requires that the portmap plugin be explicitly configured to use the nftables backend. (The iptables backend is the default.)

Patches This is fixed as of CNI plugins v1.9.0

Workarounds Configure the portmap plugin to use the iptables backend. It does not have this vulnerability.

Impact The primary impact is allowing users to fetch data from a remote URL. This data can be then injected into Spinnaker pipelines via helm or other methods to extract things LIKE idmsv1 authentication data. This ALSO includes calling INTERNAL Spinnaker API's via a get and similar endpoints. Further, depending upon the artifact configuration, auth data may be exposed to arbitrary endpoints (e.g. GitHub auth headers) leading to credentials exposure.

To trigger this, a Spinnaker installation MUST have: An artifact enabled that allows user input. This includes GitHub file artifacts, BitBucket, GitLab, HTTP artifacts and similar artifact providers. JUST enabling the http artifact provider will add a "no-auth" http provider that could be used to extract link local data (e.g. AWS Metadata information). A system that can consume the output of these artifacts. E.g. Rosco helm can use this to fetch values data. K8s account manifests if the API returns JSON can be used to inject that data into the pipeline itself though the pipeline would fail.

To note, due to the way the URLs are viable to be injected, CERTAIN systems can be used to provide DOS attacks on Spinnaker itself. These would NOT compromise the system per se, given restarts and timeout configuration, but could lead to internal attacks by a Spinnaker user against Spinnaker services. An example is that an artifact fetch reference could return an infinite response data feed or similar that can act as a DOS attack. It's recommended to set strong limits on the various http limits AND artifact URLs to known valid URLs.

Patches Fixed in clouddriver versiosn 2025.2.3, 2025.1.5, 2025.0.9. Impacts all prior Spinnaker releases.

Workarounds Disable HTTP account types that allow user input of a given URL. This is probably not feasible in MOST cases. Git, Docker and other artifact account types with explicit URL configurations bypass this limitation and should be safe as they limit artifact URL loading.

Alternatively using one of the various vendors which provide OPA policies to restrict pipelines from accessing or saving a pipeline with invalid URLs.

Impact

A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted.

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

Patches

This bug has been fixed in Moby (Docker Engine) 20.10.14. Users should update to this version as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset.

This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. Refer to capabilities(7) for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox.

Workarounds

The entrypoint of a container can be modified to use a utility like capsh(1) to drop inheritable capabilities prior to the primary process starting.

Credits

The Moby project would like to thank Andrew G. Morgan for responsibly disclosing this issue in accordance with the Moby security policy.

For more information

If you have any questions or comments about this advisory:

Open an issue Email us at security@docker.com if you think you’ve found a security bug

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

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

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

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.

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

A denial-of-service vulnerability exists in the omec-project UPF (pfcpiface component) in version upf-epc-pfcpiface:2.1.3-dev. When the UPF receives a PFCP Session Report Response that is missing the mandatory Cause Information Element, the session report handler dereferences a nil pointer instead of rejecting the malformed message. This triggers a panic and terminates the UPF process. An attacker who can send PFCP Session Report Response messages to the UPF's N4/PFCP endpoint can exploit this flaw to repeatedly crash the UPF and disrupt user-plane services.

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

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

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)

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.

All versions of package dojo are vulnerable to Prototype Pollution via the setObject function.

In affected versions of dojo (NPM package), the deepCopy method is vulnerable to Prototype Pollution. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. This has been patched in versions 1.12.8, 1.13.7, 1.14.6, 1.15.3 and 1.16.2