action-pre-commit-uv is a GitHub composite action that runs pre-commit with pre-commit-uv in a workflow. This policy says how to report a security problem and how we decide whether a report is one.
Do not open a public issue for a security problem. Use GitHub's private vulnerability reporting. If neither works for you, email gaborjbernat@gmail.com.
Include what the attacker controls and what they gain, the steps or a proof of concept, and the versions and platform you tested. Write the report yourself; unreviewed tool or model output takes longer to triage.
Volunteers maintain action-pre-commit-uv, with no on-call rotation. We aim to acknowledge a report within 5 working days and assess it within 15 working days. Fixes are developed in a private fork attached to the draft advisory, ship in a new release, and the advisory, with a CVE requested through GitHub, goes out with that release. The default embargo is 90 days from the report; we agree any change with the reporter. We credit reporters in the advisory under the name they choose, or not at all. There is no bug bounty.
Only the latest release receives fixes. Pin the action to a full commit SHA and let Dependabot move it.
A report is a vulnerability when an attacker who controls only an input that the threat model lists
as untrusted breaks a guarantee action-pre-commit-uv makes. A report that first needs control of something the threat
model trusts, such as the workflow that calls the action, the repository's .pre-commit-config.yaml, or the runner, is
a bug: we fix it in the open and publish no advisory. Classify by who supplies the dangerous input, not by how bad the
outcome sounds.
In scope
- An input (
extra_args,uv-install) reaching a shell as code rather than as data. - The action running a tool it does not name:
setup-uvat its pinned SHA, the uv release whose checksum thatsetup-uvbundles, and pre-commit and pre-commit-uv from the configured index. - A cache written by one ref being restored for a ref GitHub's cache scoping should isolate.
Out of scope
- Hooks from
.pre-commit-config.yaml: the action runs them as pre-commit would, so a workflow that runs it on untrusted pull request code must not hold secrets, as with any job that runs that code. - Choosing
pull_request_targetor granting the job write tokens; that is the calling workflow's decision. - Vulnerabilities in pre-commit, pre-commit-uv, uv or
setup-uv.
If you cannot tell which side a finding falls on, report it privately and we will decide.