Fake Client Hid a Credential-Stealing Git Hook in a Dropbox Folder, Django's Frank Wiles Reports

A prospective client sent a Dropbox folder containing a .git directory with a malicious post-checkout hook, then told the recipient to switch to an NDA branch. Frank Wiles, founder of REVSYS, described the attempt in a post dated October 2, 2026. He did not run the code.

Wiles is also a Django Steering Council member, a Python Software Foundation Fellow and a former Django Software Foundation president, according to his post. He wrote that the target was probably his GitHub account and his clients' access.

How the lure worked

The post gives the sequence but no calendar dates for the contact itself.

1. An inquiry arrived for Ed Tech web application work.
2. Wiles offered a Calendly link. The prospect asked him to review a project overview and sign an NDA.
3. The prospect shared a Dropbox folder of Markdown files holding the project specification.
4. When Wiles asked for the NDA, the prospect told him to switch to the NDA branch and complete it there.
5. Wiles noticed a .git folder in the Dropbox share and opened .git/hooks.

The folder held the usual .example files and one real hook. Per the post, it fetched an operating-system-specific binary from a Vercel app used for command and control, made it executable, ran it and deleted itself. Wiles also found the attacker was impersonating the owner of a real development shop.

He reported the accounts to Dropbox and Vercel security. His summary advice: "Be extra vigilant and watch your credentials like a hawk."

Why a hook nobody uses works

Wiles called the choice of post-checkout notable because "no one really uses those in practice." Git's own hooks documentation says the hook runs after git checkout or git switch updates the work tree, after git clone unless --no-checkout is used, and after git worktree add unless --no-checkout is used.

Command	Runs post-checkout?
git checkout, git switch	Yes, after the work tree updates
git clone	Yes, unless -n or --no-checkout
git worktree add	Yes, unless --no-checkout

That table is why the branch instruction mattered. A normal clone does not carry hooks from the remote. A folder copied through Dropbox is different, because the .git directory comes along as plain files. A Lobsters thread, tagged security and vcs with a score of 113, reached the same reading. One commenter, z3bra, showed Git refusing to check out .git/hooks files during a clone, and another, agwa, wrote that any .git directory Git did not create should be treated as dangerous.

Defences, and where they fall short

The thread offered git config --global core.hooksPath /dev/null to disable hooks. A commenter named oger said a malicious repository can re-enable hooks through its own config, so the setting is not a full answer. The same thread, via agwa, flagged the core.fsmonitor option as "rather nasty" because it runs on basic operations such as git status, which IDEs and shell prompts call on their own.

That last detail changes the advice. Declining to run git checkout is not enough if a prompt that calls git status runs the attacker's command first. Neither Wiles nor the thread reports that this lure used core.fsmonitor, and nothing here shows that it did.

The steps that follow from the sources are short. Open any .git folder you did not create from git clone before running Git in it. Prefer a fresh clone from the remote to a copied directory. Rotate GitHub and cloud credentials on any machine where an unknown binary may have run.

The attack aims at the kind of secrets that Truffle Security counted 543,699 of in public GitHub repositories, and the same exposure risk runs through the GitLab AI Gateway flaw rated 9.9.

The post does not say whether Dropbox or Vercel removed the accounts. That answer, and any further victims, would be the next confirmation.