Last week I wrote about building a scanner that writes its own exploits. A cron job runs Claude Code every night, it reads new CVEs, writes proof-of-concept checks, tests them against vulnerable and patched Docker instances, and opens PRs. I review and merge in the morning.
That post was about how the pipeline works. This one is about what happens when you point it at 1,500 real servers.
The target list
I pulled 1,500 IPs from Shodan tagged as GitLab instances. Only 41% were actually running GitLab. 36% were dead. The remaining 23% were running something completely different: WordPress, Confluence, Grafana, Jenkins, ColdFusion. 108 of the "GitLab" IPs were Confluence instances on Alibaba Cloud.
Turns out this was a better stress test than a clean list. The exploit checks had to work across multiple products, not just GitLab.
31 verified exploits
These aren't version checks. The scanner doesn't look at a header and guess. It sends a payload and reads the response. If the server does the thing it shouldn't do, the vulnerability is confirmed.
And it doesn't spray payloads blindly. Before any exploit check fires, the scanner has already fingerprinted the tech stack and mapped exposed endpoints. A ColdFusion exploit never touches a Grafana server. A WordPress plugin check skips servers that aren't running that plugin. By the time a check runs, the scanner already knows the target is a realistic candidate. That's why 31 hits out of 1,500 IPs is a high hit rate. Most of those IPs never even saw an exploit payload.
CVE-2026-1868: GitLab AI Gateway template injection (3 instances)
CVSS 9.1 Critical. Server-side code execution. No authentication required.
The pipeline pulled the patch commit from GitLab's repo and read the diff. The bug: user input gets interpolated into a prompt template string without sanitization. So the generated check sends a crafted prompt parameter containing a template expression. If the server evaluates it and returns the computed result instead of the literal string, it's vulnerable.
Three production GitLab instances returned the computed value. An attacker with this can execute arbitrary code on the server, read secrets, pivot into internal networks. This CVE was published weeks ago. The pipeline had the check ready within days of disclosure, before most teams had even read the advisory.
CVE-2021-26085: Confluence arbitrary file read (3 instances)
CVSS 5.3 Medium. Arbitrary file read. No authentication required.
Confluence's servlet resolved file paths without normalizing ../ sequences. The check requests /s/123/_/WEB-INF/web.xml through the static resource endpoint. If the server hands back the XML contents of an internal config file, you can read anything on the filesystem.
Three of the 108 Confluence instances returned their web.xml. One request. No auth. From there you pull database credentials, config files, private keys.
These weren't supposed to be in this dataset. They're "GitLab" servers according to Shodan. The pipeline had written this check weeks earlier for a completely different reason, and it caught them anyway.
CVE-2021-43798: Grafana path traversal (3 instances)
CVSS 7.5 High. Arbitrary file read. No authentication required.
Grafana's plugin API let you walk the filesystem through the plugin ID parameter. The check requests /public/plugins/alertlist/../../../../../../../../etc/passwd.
Three Grafana dashboards returned /etc/passwd. From there it's /etc/shadow for password hashes, Grafana's grafana.ini for database credentials and secret keys, whatever else is on disk. The pipeline wrote this check months ago. Still catching live instances in 2026.
CVE-2010-2861: ColdFusion directory traversal (3 instances)
CVSS 7.5 High. Admin password theft. No authentication required.
This one is from 2010.
ColdFusion's admin panel accepted a locale parameter with ../ traversal. The check requests the password properties file through this path. Three servers returned the file, which contains the admin password hash. Crack it (or use it directly in older ColdFusion versions) and you own the server. A vulnerability old enough to drive. Nobody has touched these machines in 16 years.
CVE-2026-2413: WordPress SQL injection (3 instances)
CVSS 9.8 Critical. Full database access. No authentication required.
SQL injection in the Starter Templates plugin, 200K+ active installations. The AJAX handler passes a search parameter straight into a WHERE clause without prepared statements. The check sends a time-based blind payload: ' AND SLEEP(5)--. If the response takes 5+ seconds longer than baseline, the injection is confirmed.
Three instances responded with the delay. With SQL injection on WordPress, you can dump the entire database: user credentials, emails, payment data, everything. The pipeline caught this one the week it was published.
CVE-2026-27099: Jenkins stored XSS (1 instance)
CVSS 8.0 High. Admin account takeover via stored XSS.
When a Jenkins node goes offline, the reason field gets rendered without escaping. The check looks for unescaped HTML in the node status API. Anyone who can take a node offline can inject JavaScript that runs in every admin's browser, steal their session, and take over the CI/CD pipeline. Two Jenkins boxes in the entire dataset. One was exploitable.
CVE-2017-5487: WordPress user enumeration (5 instances)
CVSS 5.3 Medium. Username disclosure, enables brute-force attacks.
/wp-json/wp/v2/users returns usernames unless you lock it down. Five instances returned their full user list. First step in every brute-force attack, wide open.
The rest
10 more WordPress plugin CVEs, each confirmed against a live server: arbitrary file upload in Contact Form 7 (CVSS 10.0, unauthenticated RCE via file upload), unauthenticated PHP object injection in LearnPress (CVSS 9.8, potential RCE), local file inclusion in Eduma (CVSS 6.5) and SiteOrigin Page Builder (CVSS 6.5), stored XSS in Elementor (CVSS 6.4) and Ultimate Review (CVSS 6.4), plus four more.
I didn't write any of these checks. claude /cve-pipeline wrote them, tested them against Docker labs, and opened PRs. I reviewed and merged.
The other stuff
237 servers had their full .git directory exposed. Entire source code, every commit, every credential that was ever checked in and "deleted." 57 had .env files at a predictable URL. Database passwords, API keys, plain text, internet-accessible.
660 (46%) weren't redirecting HTTP to HTTPS. 372 had TLS cert hostname mismatches. 347 had GraphQL endpoints open. 270 had TRACE enabled. The usual.
I wasn't looking for most of this
I didn't plan to find Confluence bugs on "GitLab" servers. But the pipeline had already processed CVE-2021-26085 weeks earlier. The check was just sitting there. When Confluence showed up on IPs that Shodan swore were GitLab, it fired.
Same with ColdFusion. Same with the WordPress plugins. The pipeline does 4-8 CVEs per night, 8 stages each. By the time I ran this scan, there were checks for products I had no reason to expect in the dataset. 31 confirmed exploits across 7 products, from checks I never wrote.
The pipeline doesn't have a plan. It has checks. When the right server shows up, they run.
Methodology
1,500 IPs from Shodan/Censys, GitLab HTTP fingerprints. Scanned over 4 days, March 2026. Full AttackerView pipeline. No login attempts. No data extraction beyond PoC verification. All results anonymized.
You can try the scanner yourself at attackerview.com
Full list of exploit checks at attackerview.com/checks/exploits.