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 out 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 their own code for weaknesses before it ships. Engineers trust these tools completely, which is exactly what makes them a target.
Raphael Karger, co-founder and chief technology officer of application security firm ZeroPath, will take the stage at the Black Hat USA security conference in Las Vegas next week to show how those trusted tools can be turned against the companies that use them.
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 detonate its own payload. No password theft. No phishing. Just a scan.
Many security 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 is not properly isolated, meaning kept in a walled-off environment where it cannot reach the rest of the system, a malicious file inside the repository being scanned can trick the scanner into running attacker-controlled code instead.
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 files, dependencies, and stored secrets. Rather than just 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?
The results were serious. 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 had not fixed yet |
The production database finding was particularly damaging. The researchers confirmed it held enough access to potentially modify code being delivered to major customers, including Fortune 1000 corporations, defence contractors, 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?
Karger says all five vendors were notified before the Black Hat talk. One paid a maximum-tier bug bounty, which is a reward companies offer researchers who responsibly report security flaws rather than sell them to criminals.
At the conference, Karger will release Build Canaries as a free, open-source tool (meaning anyone can inspect and use the code) with 349 validated payloads. He will 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 advice for any organisation that uses application security scanning products: ask your vendor whether their scanner runs in an isolated environment, and whether different customers' scans are kept strictly separate from each other. Those two questions alone will 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."
