CVE-2026-12171: auto-changelog: code execution via untrusted in-repository configuration (handlebarsSetup/plugins), plus argument injection, path traversal, and SSRF

Q: Which environments are realistically exposed?

Any CI job or local workflow that runs auto-changelog against attacker-controlled repository content is exposed, including workflows that check out an untrusted pull-request head and users running it in a forked or third-party repository. Execution occurs with the privileges of the invoking user or CI job, which can include workflow-secret access.

Q: What does an attacker need to exploit this?

The attacker needs control over in-repository auto-changelog configuration, either through .auto-changelog or the auto-changelog key in package.json, and must cause auto-changelog to run on that repository content. Repository dependencies do not need to be installed for handlebarsSetup-based code execution.

Q: How can I tell whether a repository is using a dangerous configuration?

Inspect .auto-changelog and package.json for the auto-changelog key, especially handlebarsSetup, plugins, appendGitLog, appendGitTag, output, and template. Before 2.6.1, these in-repository settings can respectively enable module loading, git argument injection, arbitrary-path writes, or outbound requests when auto-changelog runs.

Q: What should be done if patching is not immediately possible?

Do not run the affected tool against untrusted pull-request, fork, or third-party repository content. Avoid allowing attacker-controlled in-repository configuration to supply the listed security-sensitive options.

Published Oct 5, 2026

Updated

auto-changelog before 2.6.1 merges configuration from inside the target repository (the .auto-changelog file and the auto-changelog key in package.json) into its options, and honors security-sensitive options from that untrusted source. The handlebarsSetup option is passed to require(), so running auto-changelog over attacker-controlled repository content (for example, in a CI workflow that checks out an untrusted pull request head, or locally on a forked or third-party repository) executes attacker-chosen code with the privileges of the invoking user or CI job, including access to workflow secrets, without the repository dependencies ever being installed. The plugins option similarly loads attacker-controlled modules from the repository. Under the same conditions, appendGitLog/appendGitTag allow git argument injection (e.g. --output= to write arbitrary files), output allows writing attacker-influenced content to arbitrary paths, and template causes an outbound request to an attacker-chosen URL. Version 2.6.1 treats in-repository configuration as untrusted and refuses to run when it sets these options, unless the new --unsafe-config flag is passed.

Affected Software

1 affected component

npm/auto-changelog<2.6.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade auto-changelog to a version that resolves this vulnerability.
Fixed in 2.6.1

Event History

Oct 5, 2026

CVE Published

via MITRE·04:25 PM

Data Sourced

via MITRE·04:25 PM

RemedyDescriptionSeverityWeakness

Data Sourced

via NVD·05:17 PM

DescriptionSeverityWeakness

Aug 28, 58731

Event

via NVD·06:59 PM

Frequently Asked Questions

Which environments are realistically exposed?

Any CI job or local workflow that runs auto-changelog against attacker-controlled repository content is exposed, including workflows that check out an untrusted pull-request head and users running it in a forked or third-party repository. Execution occurs with the privileges of the invoking user or CI job, which can include workflow-secret access.

What does an attacker need to exploit this?

The attacker needs control over in-repository auto-changelog configuration, either through .auto-changelog or the auto-changelog key in package.json, and must cause auto-changelog to run on that repository content. Repository dependencies do not need to be installed for handlebarsSetup-based code execution.

How can I tell whether a repository is using a dangerous configuration?

Inspect .auto-changelog and package.json for the auto-changelog key, especially handlebarsSetup, plugins, appendGitLog, appendGitTag, output, and template. Before 2.6.1, these in-repository settings can respectively enable module loading, git argument injection, arbitrary-path writes, or outbound requests when auto-changelog runs.

What should be done if patching is not immediately possible?

Do not run the affected tool against untrusted pull-request, fork, or third-party repository content. Avoid allowing attacker-controlled in-repository configuration to supply the listed security-sensitive options.

What changes in version 2.6.1, and is there a way to bypass it?

Version 2.6.1 treats in-repository configuration as untrusted and refuses to run when it sets the affected options. The protection can be overridden with --unsafe-config, so that flag should not be used for untrusted repository content.