Cursor AI's Git Hook RCE Flaw: Patch Now to Secure Your Workflow

If you use an AI coding assistant that can clone repositories, run shell commands, and commit on your behalf, you have given a fast, tireless junior developer access to your machine. Most of the time that is exactly what you want. But there is one corner of Git where convenience turns into code execution without any further click, and every developer who lets an agent touch Git should understand it: Git hooks.

A Git hook is a script that Git runs automatically when a particular event happens — after a checkout, before a commit, after a merge, and so on. Hooks live in the .git/hooks directory of every repository, and when they fire, they run with your user privileges. That behavior is documented, intended, and genuinely useful. It is also a code-execution primitive hiding in plain sight, which is why security-minded teams treat unfamiliar repositories the way they treat unfamiliar binaries: with suspicion until inspected.

This post explains the mechanism, why AI-assisted Git workflows widen the attack surface, and the concrete checklist that keeps you safe. It makes no claims about any specific product vulnerability, advisory, or patch version — only about how Git itself works, which you can verify in the primary sources below.

How git hooks become code execution

When you initialize or clone a repository, Git populates .git/hooks with sample scripts ending in .sample. Samples do nothing until renamed, but any executable file in that directory with a recognized hook name — post-checkout, pre-commit, post-merge, pre-push, and others — runs automatically at the matching lifecycle event. The Git hooks documentation lists every hook and the exact moment each one fires, and the Pro Git chapter on hooks walks through client-side and server-side hooks with examples.

Here is the part that matters for security: hooks execute as ordinary programs under your account. A post-checkout hook fires every time a branch is checked out — including the initial checkout that follows a fresh clone. So the sequence "clone an unfamiliar repository, check out its branch" is enough to run whatever script the repository ships in .git/hooks/post-checkout. No compile step, no explicit run command, no confirmation dialog. Git assumes that whoever controls the repository contents is trusted, because historically the person cloning chose the source.

One mitigating fact is worth stating precisely: hook scripts are local configuration, not versioned content. Cloning does not copy hooks — .git/hooks is created fresh from templates on clone. An attacker therefore cannot deliver a hook through a plain git clone alone; they need a second step, such as a setup script you run or tooling that performs local operations on their behalf. That second step is exactly where AI agents re-enter the picture, as the next section explains.

A minimal example makes the mechanics concrete:

# Inspect the hooks directory of any repository before trusting it
ls -la .git/hooks/

#!/bin/sh
# This runs automatically after every checkout — with your privileges.
echo "hook fired" >> /tmp/hook-demo.log

Nothing about that script is exotic. The risk is not sophistication; it is automaticity. Events you trigger dozens of times a day — checkout, commit, merge, push — each have a hook slot, and each slot runs code you may never have read.

Why agent git operations widen the surface

Two patterns expand the moments when untrusted content meets automatic execution: shared bare repositories and autonomous Git operations performed by AI coding assistants.

A bare repository — one created with git init --bare, or the kind that lives on a server — has no working tree, but it still supports server-side hooks such as pre-receive, update, and post-receive. Anyone who can write to a shared bare repository's hooks directory controls code that runs on push. In self-hosted setups where several developers or several agents share infrastructure, the hooks directory of a central repository deserves the same access controls as a deployment pipeline, because functionally it is one: a post-receive hook that deploys a site on push is convenient right up until someone unauthorized edits it.

AI assistants widen the surface differently: through volume and autonomy. A human developer clones a handful of repositories a week and usually knows why. An agent executing a research or scaffolding task can clone, fetch, check out, and run setup scripts across many repositories in minutes — including repositories assembled from search results or dependency graphs the agent itself discovered. Each operation is a chance for the "second step" described above: a README instructing a setup script, a package install hook, or a contributed configuration redirecting Git's hook lookup. Git supports redirecting hook lookup with core.hooksPath (documented in the git-config reference), so a single configuration change can point Git at attacker-controlled scripts for every hook event. An agent applying a dotfiles change or a repository-suggested config include could make that change faster than a human would notice.

None of this requires a vulnerability in the assistant itself. It falls out of two true statements: Git hooks execute code automatically, and agents perform Git operations at machine speed on sources a human never personally vetted. The defense is therefore not a patch to wait for but a workflow to adopt.

Hardening checklist for AI-assisted git workflows

Treat every unfamiliar repository as untrusted input until you have done these five things. They take minutes and they neutralize the hook-execution path regardless of which editor or agent you use.

First, inspect hooks before the first checkout-triggered event fires. Because post-checkout runs on the initial checkout of a clone, the safest order is: clone without checking out, inspect, then check out:

# Clone without triggering a checkout, then look before you leap
git clone --no-checkout <url> target-dir
cd target-dir
ls -la .git/hooks/
git checkout main

If any file in .git/hooks is executable and lacks the .sample suffix — and you did not put it there — stop and investigate before proceeding.

Second, pin down where Git looks for hooks. The core.hooksPath setting overrides the default directory, and repositories can suggest configuration through included config files. Check both:

# Confirm hooks resolve to the default directory (empty output is good)
git config --get core.hooksPath

If core.hooksPath points somewhere unexpected, find out what set it before running further Git commands in that repository.

Third, isolate agent Git operations. Give your coding assistant a dedicated working area — a container, a virtual machine, or at minimum a separate user account — for tasks involving unfamiliar sources. Hooks firing inside an isolated sandbox inherit only sandbox privileges, converting a potential workstation compromise into disposable-environment cleanup. This is the same principle behind running untrusted builds in CI rather than on a laptop, applied to agent-driven exploration.

Fourth, review setup scripts with the same care as hooks. A setup script, Makefile target, or package install hook that an agent runs on your behalf can write into .git/hooks, set core.hooksPath, or do anything else your account can do. Read the script first, or have the agent summarize every filesystem and network effect before approving execution. Convenience scripts from unknown repositories are the most plausible delivery vehicle for the "second step" — treat them as installers, because they are.

Fifth, keep tools current and permissions tight as general hygiene. Updating your editor and Git client on their regular release cadence, restricting write access to shared bare repositories, and auditing hook directories on infrastructure you operate will not make headlines, but they close the boring gaps through which real incidents walk.

What this means for template-based builds

Starting from a known-good template you control eliminates the entire "unfamiliar repository" risk class: every hook, script, and configuration line is yours or audited by you before the first clone. Teams that scaffold from reviewed starters — rather than letting agents assemble stacks from whatever search returns — get speed and a trust boundary for free. Our safe agent permissions guide covers the broader least-privilege principle for AI tooling, and the OTF templates collection offers production-ready starters whose setup scripts have already been read so you do not take them on faith. Verify the mechanism in the sources below, apply the checklist above, and build from sources you trust.

Sources

• Git Contributors. "githooks — Hooks used by Git." Git Reference Manual. https://git-scm.com/docs/githooks
• Chacon, S. and Straub, B. "Customizing Git: Git Hooks." Pro Git, 2nd ed. https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
• Git Contributors. "git-config — core.hooksPath." Git Reference Manual. https://git-scm.com/docs/git-config
• Cursor. "Changelog — What's New in Cursor." https://cursor.com/changelog (checked 2026-09-06; release-notes index live, no advisory content relied upon in this article)