CodeCatalyst Blueprints Command Injection: Upgrade Now

Short answer: The CodeCatalyst Blueprints command injection vulnerability, CVE-2026-85012, affects @amazon-codecatalyst/blueprints.blueprint versions earlier than 0.3.156. Direct package users should upgrade to 0.3.156 or later immediately; AWS says the hosted Amazon CodeCatalyst service is already protected and requires no customer action.

AWS disclosed the high-severity flaw on September 3, 2026. A repository contributor could craft a .ownership-file so that blueprint resynthesis passes attacker-controlled shell metacharacters into an operating-system command. Successful exploitation could run commands with the permissions and credentials of the resynthesis environment.

What is the CodeCatalyst Blueprints command injection?

Amazon CodeCatalyst blueprints are reusable templates that generate software projects. The npm package @amazon-codecatalyst/blueprints.blueprint provides the framework used by blueprint authors.

During a resynthesis operation, the framework reads .ownership-file from the existing project. That file describes which files a blueprint may modify. In vulnerable versions, the owner value for a [local] merge-strategy entry was passed to an operating-system command through a shell without adequate validation.

That creates a command-injection boundary: a user who can commit a malicious .ownership-file can add shell metacharacters to the owner field. If someone then runs blueprint resynthesis, the injected command can execute with the privileges of that process. AWS assigned the issue CVE-2026-85012; the corresponding GitHub advisory is GHSA-c7rj-fr2j-64w7 with a CVSS 3.1 score of 8.0.

This is a vulnerability disclosure, not evidence that the npm package or AWS publisher account was compromised. The public advisories also do not report active exploitation.

Which package versions are affected?

At the time of writing, npm lists 0.3.159 as the latest release. Version 0.3.156 removed shell interpretation of the owner field, executes the command directly, and rejects values outside an allowlisted command form. AWS says upgrading is the only mitigation for direct consumers because .ownership-file is a normal project file and the vulnerable merge strategy does not require extra configuration.

Important scope distinction: AWS states that no action is required for users of the hosted Amazon CodeCatalyst service. Its resynthesis environment is isolated per project, uses scoped credentials, and applies server-side validation that restricts local merge-strategy commands, including for blueprints created with older package versions. The upgrade requirement applies to direct npm consumers and to forks or derivative implementations that contain the vulnerable logic.

How can I check whether my project is exposed?

1. Inspect the resolved dependency tree

Run this command from every Node.js repository that builds or resynthesizes CodeCatalyst blueprints:

npm ls @amazon-codecatalyst/blueprints.blueprint --all

If the command reports a version below 0.3.156, the resolved tree is vulnerable. The --all flag matters because the package may be transitive rather than declared directly.

To understand why it is installed, use:

npm explain @amazon-codecatalyst/blueprints.blueprint

Repeat the check in each workspace when using a monorepo, and inspect the dependency tree used by CI rather than relying only on a developer laptop.

2. Search every lockfile and build definition

Search package-lock.json, npm-shrinkwrap.json, yarn.lock, and pnpm-lock.yaml for the full scoped package name. Also inspect container build files, cached CI workspaces, release branches, and generated projects. A safe package.json range does not prove safety if a stale lockfile still resolves an affected version.

rg -n '@amazon-codecatalyst/blueprints\.blueprint' \
  package.json package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml

3. Determine whether the vulnerable path ran

Finding an affected version establishes vulnerability, but not exploitation. The dangerous path requires blueprint resynthesis and a crafted local merge-strategy owner value in .ownership-file. Review repository history for unexpected edits to that file, especially changes from contributors who could not otherwise run commands in the resynthesis environment.

Check CI and resynthesis logs for unusual child processes, shell errors, outbound connections, file writes, or commands that do not match the expected owner tool. If the affected workflow had access to cloud, GitHub, npm, signing, or deployment credentials, include those systems in the review.

How do I remediate CVE-2026-85012?

1. Upgrade the package. Set @amazon-codecatalyst/blueprints.blueprint to 0.3.156 or later. Prefer the current supported release rather than stopping at the minimum fix.
2. Regenerate the lockfile. Use your normal package-manager workflow, then confirm the resolved tree with npm ls. Commit the manifest and lockfile together.
3. Rebuild from a clean environment. Remove stale dependency caches where appropriate and produce new build artifacts from the patched dependency tree.
4. Patch forks and derivative code. AWS specifically recommends incorporating the fix into copied or forked implementations. Merely updating a manifest will not repair code that duplicated the vulnerable shell call.
5. Review .ownership-file history. Treat unexplained local merge-strategy commands or shell metacharacters as a reason to investigate further.
6. Respond proportionately if exploitation is suspected. Isolate the runner, preserve relevant logs, rotate credentials accessible to the resynthesis process, and inspect downstream deployments and repositories for unauthorized changes.

Do not treat input filtering added only in your calling code as a durable workaround. AWS says direct package users have no workaround other than upgrading. The patched implementation removes shell interpretation and enforces an allowlisted command form at the vulnerable boundary.

What should CI and platform teams change?

Start by making the patched version a policy requirement. Dependency updates should be installed with a committed lockfile, and CI should fail when a vulnerable resolved version reappears through a transitive dependency or an older release branch.

Then reduce the consequence of any future build-time command execution:

• Run resynthesis in an ephemeral, isolated environment.
• Grant the job only the repository and cloud permissions it needs.
• Keep long-lived npm, cloud, and deployment credentials out of the process environment.
• Restrict network egress when the workflow does not need arbitrary internet access.
• Require review for changes to ownership, build, package-manager, and workflow files.
• Record process execution and outbound network events for high-trust build jobs.

These controls do not replace the upgrade. They make a successful exploit less useful and improve the evidence available during incident response.

How does a registry firewall help?

A registry firewall places an enforceable policy boundary between package managers and the public npm registry. Once an affected version is identified in advisory data, the firewall can deny that version before it enters developer laptops, CI runners, or AI-agent environments. This is useful when several repositories or autonomous tools install dependencies and a checklist alone is difficult to enforce.

InstallSafe uses OSV.dev advisory data to block flagged package versions at the install boundary and serves byte-for-byte upstream tarballs for allowed versions. Teams can also use the free package scanner for a quick advisory check, then enforce the same decision consistently in CI and developer workflows. See the guides to checking whether an npm package is safe, choosing an npm vulnerability scanner, and understanding the limits of npm audit.

A crucial limitation remains: an advisory-backed firewall is not a zero-hour behavioral detector. It can block CVE-2026-85012 after the advisory is available in its source feed, but it cannot guarantee detection before disclosure. Behavioral-analysis tools, code review, least-privilege build environments, and registry policy are complementary controls.

What do the primary advisories say?

The AWS security bulletin was published on September 3, 2026 and identifies direct consumers of versions through 0.3.155 as affected. The GitHub Security Advisory records the same package boundary, a high severity rating, and 0.3.156 as the patched version. The npm package page shows newer releases are available.

Use those primary sources for ongoing updates. Avoid treating later roundup dates as the disclosure date: the verified original disclosure is September 3, 2026, which matches the current year and falls within 24 hours of this alert.

FAQ

Is Amazon CodeCatalyst itself vulnerable?

AWS says no customer action is required for the hosted Amazon CodeCatalyst service because server-side validation and isolated, scoped resynthesis environments block the affected command form. Direct npm consumers still need to upgrade.

What is the minimum safe version?

Version 0.3.156 is the first patched release. Upgrade to 0.3.156 or later, preferably the newest supported version.

Does installing an affected version mean commands executed?

No. It means the project contained vulnerable code. Exploitation requires a crafted .ownership-file and blueprint resynthesis. Review file history and runner telemetry before concluding that execution occurred.

Can I mitigate the issue by disabling npm lifecycle scripts?

No. This vulnerability is in blueprint resynthesis logic, not an npm install hook. Options such as --ignore-scripts do not fix it.

Should I rotate credentials?

Rotate credentials if logs or repository history indicate suspicious resynthesis activity, or if you cannot confidently exclude execution on a runner that held sensitive credentials. A vulnerable version alone does not prove credential exposure.

Will a registry firewall block this vulnerability?

An advisory-backed registry firewall can block affected versions after its advisory source includes the disclosure. It should be combined with behavioral detection, code review, workload isolation, and least-privilege credentials.