Security researcher Simon Schwarz discovered a flaw in the first layer of pre-commit ci's execution isolation which would have allowed an attacker access to another tenant's short-lived installation access token with {"contents": "read", "statuses": "write"}.
Timeline of events:
- 2026-05-16 11:00 UTC -- automated monitoring notified of sandbox breach
- 2026-05-16 16:27 UTC -- fix is deployed to production
while a security incident is never fun -- a few things went really well:
- the monitoring caught the sandbox breach
- but unfortunately didn't terminate the rogue process(es)
- monitoring and logs indicate this has not been exploited in the wild
- private runs and public runs execute separately
- an attacker could not have accessed private source code unless they were also a paying customer
- at worst the tokens that were accessible were scoped to *mostly* non-destructive actions
- it could read the contents of another repository
- it could create a commit status as pre-commit-ci[bot]
- tokens were short lived and scoped to a single installation (github user or github org)
how did the flaw work?
- git `fsmonitor` allows configuring a different type of git hook via .git/config (rather than the usual mechanism through .git/hooks/)
- when pre-commit ci analyzes the tested repository for hook changes it executes `git diff` at the second layer of isolation
- this invokes the configured fsmonitor hook allowing arbitrary execution
- once there, the attacker could scan `ps` to find other processes invoking `git-remote-https` which contained installation access tokens (basic auth)
- (annoyingly) there had already been some care taken to avoid these tokens directly in a `git clone` command by writing the `.git/config` manually -- however git still puts the remote url into the argv of a subprocess during `git fetch`
action items:
- (completed) clear git config after execution
- (completed) reduce access to process argv in the second isolation layer
- (completed) audit other means of git client hooks
- (in progress) utilize a git credential helper to further avoid credentials in ps logs
for other interested security researchers -- please reach out to
in...@pre-commit.ci to coordinate (we'll give you access to the identical development instance rather than the production instance to play with) and as always if you find security flaws please reach out to
secu...@pre-commit.ci
anthony