Hackbot finds CVE-2026-34475 and automates new vuln discovery

I got a fever and the only prescription is more fuzzing

In February 2025, Claranet discovered and patched a bug in the Varnish Cache project. The bug causes the software to panic when it receives an unexpected string. At the time I was playing around with various fuzzing techniques on other projects using standard fuzzing techniques and libraries and turning my small server into a space heater in my office. David Freedman (our CTO) messaged me about this finding and about the Varnish testing suite that is present in the project. We got to thinking: how could we use this to fuzz more and what would the art of the possible be with an LLM?

Life and work took over, and the project soon stalled, until I started work on what would later become Claranet’s internal AI Security Agent project “hackbot / AST”. Hackbot started its life a few years ago as an experiment in what at the time was a new concept for LLM “Tool Calling”. What could an LLM do if it could run its own commands and pipe that back into the LLM? 

The answer was something cool. But also something wildly risky if I let the LLM run anything it wanted on bare metal. So, not really useful outside of personal interest. Again the idea got parked for a while and the world of LLMs moved on, agents became a thing, reasoning models came out and context windows grew massively.

I picked up the project again after a few months but this time as a tool that would allow me to bring some chaos engineering to SOC rule engineering. A small tool that would talk to a custom agent and run random attacks, chains and exploits and check to see if they got picked up by the SIEM (think Breach and Attack Simulation but very rudimentary and hacky). This worked well for me and replaced my Caldera setup. After presenting the tool internally to the security team the question became: can we use this for pentesting? If it can use tools and “reason” then can we use it to automate some of the basics?

Hackbot is born 

So how does all this relate to CVE-2026-34475?

I know how to use exploits, I know how to spot exploits. I see the before and after of exploits all the time in my day job. But what I’m not very good at is spotting new ones while reviewing code, particularly in languages I don’t use all the time (if at all)! 

Using hackbot, I have been able to map out large projects, hunt for vulnerabilities and Proof-of-concept (POC) them all in the same session. This has sped up my workflow massively from finding to POC. (I’ve even used hackbot with interesting results in industry CTFs.) Varnish was particularly nice to work with as hackbot was able to hunt and then verify with varnishtests at the same time, closing the loop considerably.

Varnish, vulns and patches

The vulnerability that hackbot found is simple in its approach but has the potential to be used to bypass downstream protections, ACLs and some cache poisoning scenarios.

Making a GET request to an absolute URL without ending the GET with a / causes Varnish to treat the request slightly differently from what you might expect. In this case Varnish skips some of the normal request checks and the request can pass through while retaining the original Host header.

This behaviour occurs when handling HTTP/1.1 requests that use an “absolute form” URI with an empty path. Previously, a request such as:

GET http://example.com HTTP/1.1

would cause req.url to contain the full value http://example.com while the Host: header remained unchanged. This meant the request could effectively carry its original host information downstream without being normalised as expected.

This has now been fixed. When Varnish encounters an absolute form request with an empty path it now normalises the request so that req.url is set to / (or * if the request method is OPTIONS), and the Host: header is rewritten to match the host portion of the URI (for example example.com).

Edge cases have also been addressed. If the absolute URI contains an empty path but includes query parameters such as http://example.com?/foo, Varnish now normalises the request by adding the missing leading slash, resulting in req.url being set to /?/foo.

Why I’m excited

Vulnerability discovery with LLM powered tools is not a silver bullet by any means. Hackbot still threw up about 10 vulnerabilities that either had no path to exploit or  hackbot’s assumptions were just completely wrong. But having that information to hand made troubleshooting a lot easier and quicker and cements my ideas that these tools combined with domain specific knowledge does make them powerful. 

I’m excited to see what can be done when the tool is not just my side project developed at night. Wherever the development of AST/hackbot goes, I’ll be thinking more how we can start leveraging this more in Claranet engagements. Keep your eyes peeled for more coming soon. 

If you want to find out where your organisation is vulnerable, test security controls and the strengthen your defences, talk to our cybersecurity experts.