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
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 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 This is a configuration bypass vulnerability that enables arbitrary code execution. The @backstage/plugin-techdocs-node package uses an allowlist to filter dangerous MkDocs configuration keys during the documentation build process.
A gap in this allowlist allows attackers to craft an mkdocs.yml that causes arbitrary Python code execution, completely bypassing TechDocs' security controls.
Patches
Patched in @backstage/plugin-techdocs-node version 1.14.3
Workarounds If users cannot upgrade immediately:
1. 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. 2. Restrict repository access: Limit who can modify mkdocs.yml files in repositories that TechDocs processes. Only allow trusted contributors. 3. Manual review: Implement PR review requirements for changes to mkdocs.yml files to detect malicious hooks configurations before they are merged. 4. Downgrade MkDocs: Use MkDocs < 1.4.0 (e.g., 1.3.1) which does not support hooks. Note: This may limit access to newer MkDocs features.
Note: Building documentation in CI/CD pipelines using @techdocs/cli does not mitigate this vulnerability, as the CLI uses the same vulnerable @backstage/plugin-techdocs-node package.
Resources MkDocs Hooks Documentation MkDocs 1.4 Release Notes TechDocs Architecture