Exim 4.99.5 drops critical security patches, credits AI training data for the find
Two privilege escalation flaws close, but the unusual attribution is where the real story lives.
Exim 4.99.5 landed today with patches for two privilege escalation flaws, and it comes with a credit line that will leave most security researchers baffled. The advisory thanks "the unnamed and uncredited authors whose works were ingested as the training corpus." In short, someone ran a large language model over decades of security research and surfaced two nasty bugs in a thirty-year-old mail server.
Exim has been the quiet workhorse of internet email since 1995. Philip Hazel wrote it for the University of Cambridge, and it has grown to power roughly 59% of publicly reachable mail servers. It ships as the default MTA on Debian, lives inside cPanel, and probably handles your corporate email. Keeping that much infrastructure healthy means it gets patched. Constantly.
Two local access bugs, two very different attack paths
The first flaw (GCVE-25-2026-07-45-1, rated HIGH) is a directory traversal issue that creeps through command-line arguments meant to move queue names around. An attacker who already has shell access on the box can step outside Exim's spool directory and read or rewrite sensitive files. The patch locks those flags down to already-privileged users and restricts what characters can show up in queue names.
The second one (GCVE-25-2026-07-45-3, rated MEDIUM) rides on .forward file expansion. If your Exim config includes a redirect router that processes .forward files, a pipe transport that uses the force_command option, and that pipe is set to run as a privileged user, a local account can trick Exim into running arbitrary commands with elevated privileges.
Not a common setup, sure, but enterprises that rely on Mailman or older cPanel legacy routes often hit this exact combination. The quick fix before the patch dropped was simple enough. Drop the force_command option entirely and the attack surface vanishes.
A 30-day window and a credit line that doesn't make sense
The disclosure timeline reads unusually fast on the backend but took nearly a month to hit the public mirror. Report came in June 22. Jeremy Harris's team drafted the fix the next day. German CERT handed out the GCVE identifiers twelve days later. The actual public release finally went out July 22. That gap between private patching and public disclosure is long by modern standards, though Exim's release cadence has historically prioritized stability over speed.
For what it's worth, the training corpus attribution is the most interesting part of this whole thing. We've seen automated fuzzers and LLM-assisted static analyzers surface bugs before. What's rare is the maintainers actually putting it in the changelog instead of quietly crediting a vendor tool.
It raises quiet questions about how we track discovery credit in an era where models train on public CVE databases. You won't get a paper citation for that. You'll get an OpenPGP-signed tarball and a note in an advisory.
The code is now sitting in the standard Exim release channel at ftp.exim.org. You can pull the changes directly from the exim-4.99+fixes branch and verify the exim-4.99.5 tag against Harris's key fingerprint A986F3A6BD6377D8730958DEBCE58C8CE41F32DF. Keys pull cleanly through the project's WKD endpoint if you'd rather skip the manual SFTP.
It's a solid release. The patch window is generous, the mitigations are straightforward, and the codebase stays actively maintained decades after its initial commit. If you're running Exim anywhere between 4.82 and 4.99.4, upgrade today. Then audit your force_command settings and check your .forward routing. Two decades of email infrastructure doesn't get a second life without this kind of hygiene.
Head here to the official advisories EXIM-Security-2026-06-22.1 and EXIM-Security-2026-06-22.3 at exim.org.
