Skip to content
Tech News
← Back to articles

Just the rumour of a bug is enough to find an exploit these days

read original more articles
Why This Matters

This article highlights how the traditional security response model in open source is becoming inadequate as attackers can quickly exploit vulnerabilities based on mere rumors or early indicators. It emphasizes the need for the industry to rethink how security issues are managed and disclosed to better protect users and systems. The rapid probing and exploitation underscore the urgency for faster, more proactive security measures in open source projects.

Key Takeaways

Thinking through how the conventional OSS security embargoes no longer buy us time, and what open source maintainers might do instead to respond

I released a security fix for OCaml's cohttp 6.3.0 today, fixing a path traversal issue. The patch itself was straightforward and in normal times, the security procedure would have been to fix it privately, inform affected users, and then issue a public advisory. This time around though, I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue.

What's worse, I found I could use my own agents to find the exploit just by knowing roughly what it was about and so could have been exploiting it well before the public patch was available! Given that just the rumour of a security issue seems enough to give attackers enough info to find new exploits, we're going to need to change the way we deal with security responses in open source.

1 The rumour of a bug is all new agentic exploit systems need

This particular report arrived privately on a Slack channel via Jane Street last week, and was itself found via Claude Fable. That compresses all timelines considerably...

1.1 The timeline of a modern security report

Before examining the patch in detail, I pointed my own Claude at the affected code to see what else was lurking (asking it to investigate path normalisation issues). Fable frustratingly refused outright due to its security block since I don't have access to Glasswing, but DeepSeek V4 Pro obliged me and independently turned up several related issues. My agent also trivially created an exploit to probe a local live server in under a minute.

After some back and forth with the bug reporter about possible fixes, I quietly opened cohttp#1145 publicly to get more eyes on it. This normally takes a few days and a release within a week or two is reasonable. Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences, indicating that automated watchers are keeping an eye on public repositories.

If it took me just a minute to create my own exploit locally, then ten minutes actually seems quite long for an automated attack window to start! A determined attacker who is monitoring package repositories could easily be exploiting them within seconds.

1.2 Security embargoes are no longer effective

... continue reading