The Security Scanners Protecting Your Code Could Be the Way Hackers Get In
A researcher found that five unnamed security vendors' own scanning tools could be tricked into handing over cloud passwords, production databases, and developer credentials, just by feeding them a rigged code repository.
Key points
- Security researcher Raphael Karger of ZeroPath found critical vulnerabilities in five of 20 application security scanning tools tested in 2024 and early 2025.
- One affected vendor awarded ZeroPath the maximum possible bug bounty payment for the findings.
- The attack requires no sophisticated hacking: an attacker simply submits a malicious code repository for the tool to scan.
- Karger's open-source tool, Build Canaries, ships with 349 tested attack payloads and will be released publicly at Black Hat USA in Las Vegas.
- Stolen data included cloud login credentials, a live production database, and developer access tokens belonging to the vendors themselves.
Security scanning tools are software that companies plug into their development process to automatically check code for weaknesses before it ships. Engineers trust these tools completely, which is exactly what makes them a target.
Raphael Karger, co-founder and CTO of application security firm ZeroPath, will take the stage at Black Hat USA in Las Vegas next week to show how those trusted tools can be turned against the companies that use them. We covered a related pattern on 3 July 2026, when a flaw in Amazon's AI coding assistant let attackers steal cloud keys just by getting a developer to open a poisoned folder: the delivery mechanism differs here, but the prize is the same.
How does the attack actually work?
An attacker submits a booby-trapped code repository, a folder of code files, to a vendor's scanner and waits for the tool to fire its own payload. No credential theft through phishing. No lateral movement. Just a scan.
Many scanners do more than read files passively. They execute, or run, certain types of code as part of how they check for problems. If the scanner isn't properly isolated, meaning kept in a walled-off environment where it can't reach the rest of the system, a malicious file inside the scanned repository can trick the scanner into running attacker-controlled code. A concrete example: if a tool checks cloud configuration files and accepts a folder of custom rules, an attacker controlling the repository can plant a file that looks like a rule but runs as a program the moment the scanner loads it.
Karger's team first spotted this pattern late last year when their own monitoring software caught a suspicious failed scan probing their systems. Someone was methodically testing how ZeroPath's scanner handled file processing and secrets storage. Rather than patch and move on, the team built a tool to test the same surfaces themselves.
"We detected this proactively, and we began investigating the repository," Karger told Dark Reading.
What did they actually find?
Five vendors had meaningful exposures.
| Finding | Plain-English meaning |
|---|---|
| Cloud credentials exposed | Attacker could access vendor's cloud storage or computing |
| Production database accessed | Live customer data readable and, in one case, writable |
| Docker access token stolen | Attacker could alter software containers used to ship code |
| GitHub personal access token stolen | Attacker could read or modify private code repositories |
| Unpatched customer findings visible | Attacker could see which security holes customers hadn't fixed yet |
The production database access was the worst of it. Researchers confirmed the database held enough permissions to potentially modify code being delivered to major customers, including Fortune 1000 enterprises and government agencies.
"You could have gone as well and viewed all of the unpatched findings for these companies," Karger said.
Should customers of these vendors be worried?
All five vendors were notified before the Black Hat talk. One paid a maximum-tier bug bounty, a reward companies offer researchers who report flaws responsibly rather than sell them.
At the conference, Karger will release Build Canaries as a free, open-source tool with 349 validated payloads. He'll also publish a taxonomy, a structured checklist, of the specific ways scanner tools can be tricked into running untrusted code, so security teams can audit their own vendors immediately.
His practical advice: ask your vendor whether their scanner runs in an isolated environment, and whether different customers' scans are kept strictly separate. Those two questions surface the most common gaps.
"AppSec is notoriously a hyper-competitive market," Karger said. "A lot of these smaller teams maybe are investing less in security and more in go-to-market functions."
The uncomfortable truth here is that the tools organisations pay to find their vulnerabilities can harbour the same class of flaws they're supposed to catch. Vendor security questionnaires rarely ask about scanner isolation, and that gap is now being actively probed.
