After the Allies broke Enigma during the Second World War, they faced an unusual problem. The difficult part was no longer decrypting German communications. It was deciding how to act on that intelligence without revealing they had it.

If every convoy suddenly avoided every submarine and every bombing raid was intercepted, the Germans would eventually realise that Enigma had been compromised. Sometimes intelligence was deliberately left unused because preserving the secret was more valuable than stopping a single attack.

Over the last few days, I have been wondering whether open source application security is starting to face a similar problem.

A few months ago, I wrote that defenders finally have the edge. AI helps maintainers understand vulnerability reports, review code, write patches and deploy fixes much faster than before. Defenders can keep improving their codebase every week and regularly break exploit chains, while attackers still need to understand the vulnerability, develop an exploit and find targets that have not updated.

I still believe that. What has changed is the capability of attackers.

AI has made it dramatically cheaper to understand vulnerabilities and turn small pieces of public information into working exploits. The time between a maintainer fixing a vulnerability and someone else reconstructing it is shrinking quickly.

For years, publishing a patch usually bought defenders some time. Someone had to identify the security-relevant change, understand why the code had changed, reconstruct the original vulnerability and build a working exploit. That required experience, persistence and enough motivation to spend hours reading code.

Today, the opportunity cost of trying is almost zero. Finding the relevant commit takes minutes. Asking an LLM to explain the change takes seconds. If its first explanation is wrong, asking it to try again costs almost nothing.

We have seen this twice in the last few days.

In the Fastjson RCE case, the researchers mentioned the vulnerability publicly before releasing the full technical details. That signal was enough for other people to begin investigating, and working exploits appeared before the complete write-up was available.

The recent WordPress wp2shell vulnerability followed a similar pattern. Before the original researchers had published their research, other people had already reconstructed the vulnerability and developed working exploits.

Spaceraccoon's article on "Negative Days" describes the same problem from another angle. Once a patch lands in a public repository, the patch itself effectively becomes the advisory. Attackers do not need a CVE description or a detailed write-up. They can diff the release, identify the interesting changes and recover the vulnerability before many defenders have deployed the fix. Browser vendors have known this problem as patch gapping for years. LLMs are now bringing it to every public repository.

In both the Fastjson and WordPress cases, the full details were not necessary. The knowledge that something interesting existed was enough.

Announcing on social media that you have a working exploit is Churchill going on the radio to announce that Enigma has been broken. You are not sharing the details, but you are telling everyone that there is something worth finding, and roughly where to look. Bletchley Park kept its secret for decades: the breaking of Enigma only became public knowledge in the 1970s, almost thirty years after the war ended. Nowadays, exploits do not survive a teaser tweet.

None of this is completely new.

The Linux kernel was criticised for years for quietly fixing security bugs without calling them security fixes. No CVE, no advisory, just a small commit with an innocuous message. The official position was that a security fix is just another fix. Whatever you think of that argument, the effect was the same: the patch shipped without telling attackers where to look.

Maintainers have tried to make security patches harder to reverse engineer for years. If you have spent enough time reading patches, you have probably seen security fixes mixed with unrelated refactoring, formatting changes, variable renaming or large amounts of otherwise unnecessary code movement.

The goal was not to hide the vulnerability forever. It was to increase the cost of understanding the fix and give defenders more time.

That approach worked reasonably well because humans have limited attention. If understanding a vulnerability required reading through a few thousand changed lines, many people decided it was not worth the effort.

I am not convinced that assumption still holds.

LLMs do not get tired of reading diffs. They do not care whether the relevant change is surrounded by twenty lines of code or two thousand. They are increasingly good at filtering out noise, comparing behaviour and identifying the handful of changes that matter.

Making the haystack bigger no longer makes the needle much harder to find.

Security patches are usually judged using traditional criteria. Is the patch correct? Does it completely fix the issue? Is it easy to review? Is it easy to backport?

Those are all sensible goals, but a clean and minimal patch can also provide an attacker with an unusually precise description of the vulnerability.

Perhaps we need to ask another question:

How much intelligence does this patch reveal?

This is not an argument for security through obscurity. Open source depends on transparency. Users need timely patches, maintainers need to collaborate, and responsible disclosure still matters.

But the information contained in a patch has become part of the attack surface.

Maintainers may need to think beyond fixing the exact line where a vulnerability appears. Removing an exploit primitive may reveal less than applying a narrow fix. Preparatory refactoring could happen before a security release, rather than inside it. Projects may need to consider whether a patch is safe to publish before most users have had a realistic opportunity to deploy it. Bletchley Park invented reconnaissance planes to explain away its intelligence. Maintainers may need their own cover stories: fixes that ship as optimisations, refactoring or routine cleanups. Adding noise to a diff no longer works, but misdirection about why the code changed still might.

I do not know what the right solution is, or whether open source projects can meaningfully solve this without sacrificing the transparency that makes them open source in the first place.

What I do know is that the economics have changed.

Reverse engineering a security patch used to require time, skill and motivation. Increasingly, it requires curiosity, a public repository and access to an LLM.

Bletchley Park understood that intelligence has its greatest value before the adversary knows what you know.

Open source maintainers may now have to think about the same problem.