CVE-2026-106509 is a high severity flaw (CVSS 7.7) in @backstage/plugin-techdocs-node. When TechDocs builds documentation locally or in a container, a user with write access to a registered repository can run code through theme settings in mkdocs.yml. It is fixed in 1.14.6 and 1.15.4.
What's affected
The record says prior to 1.14.6, with a fix in versions 1.14.6 and 1.15.4. The GitHub advisory GHSA-8w7q-29mw-gf5c, published on 28 August 2026, lists affected versions below 1.14.6 and from 1.15.0 up to but not including 1.15.4. The one wording difference is that the record text says only prior to 1.14.6 while the advisory also covers the 1.15.0 to 1.15.3 range, so if you run the 1.15 line you are affected too. Both sources give the same fixed versions.
The weaknesses are CWE-1336, improper neutralisation of special elements used in a template engine, and CWE-94, code injection. Severity is High in the advisory, 7.7 in the record, and the vector uses high attack complexity, low privileges and a changed scope.
This CVE is separate from CVE-2026-106505, which concerns a bypass of the configuration sanitizer. Both are fixed in the same releases, so one upgrade covers both.
How to check if you're exposed
Check the installed version of the package:
yarn why @backstage/plugin-techdocs-node
npm ls @backstage/plugin-techdocs-node
Anything below 1.14.6, or from 1.15.0 to 1.15.3, is affected.
Then check how builds run. The advisory says the issue applies when TechDocs is configured to build documentation locally or in a container. Look at techdocs.generator.runIn in your app config. If documentation is instead built in CI and published to storage, with the backend only reading the published output, the backend does not run MkDocs for those repositories, and the exposure moves to your CI system.
List the repositories in your catalog that carry TechDocs annotations, and list who has write access to each. The advisory frames the attacker as a user with write access to a registered repository.
What to do now
- Upgrade @backstage/plugin-techdocs-node to 1.14.6 or 1.15.4 and rebuild the backend image.
- Apply the advisory workaround while you plan the upgrade: set
techdocs.generator.runInto docker. The advisory says this does not fully mitigate the risk. - Restrict write access to catalog repositories to trusted users.
- Consider building docs in CI and publishing the output, so the Backstage backend does not run MkDocs on untrusted input.
- Search recent commits for changes to the theme section of mkdocs.yml in registered repositories and review them.
Why it matters
Static site generators are programs, and their configuration files can be more powerful than they look. The advisory says a configuration value in mkdocs.yml is enough to cause code execution during the build. If a platform builds documentation for many teams, the config file in each repository is input from someone with only write access, yet it is processed on a shared backend.
The lesson from the advisory is about trust boundaries. Write access to a documentation repository should not mean code execution on the portal. When a build runs inside a container with no secrets and a read only mount, a bad config costs little. When it runs on the same host as the portal backend, it costs a lot.
Two CVEs fixed together in the same package suggest the area deserves a review, not just a patch. Look at the other places where your portal processes user supplied files. The record does not mark this CVE as known exploited.
Quick check
Is this the same as CVE-2026-106505?
No. They are separate CVEs in the same package with the same fixed versions. This one concerns validation of theme configuration and the other a bypass of the sanitizer.
Is Docker mode enough?
The advisory says it gives isolation but does not fully mitigate. Upgrade.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.