A day to remember: learning from every security fix

On October 21 PHP fixed two remote code execution bugs, CVE-2026-109618 and CVE-2026-109619. The first one had turned up two years earlier.

• In 2024 PHP had its first external security audit in years, carried out by Quarkslab. A PHP core developer who was fixing one of Quarkslab’s findings saw the first signs of an out-of-memory bug. Someone theorized an exploit. Nobody found a concrete attack, and bugs with clearer impact went first.
• On August 11, 2026, Ryan A at Calif reported an unconditional remote code execution with the same root cause. OpenAI reported it independently on the same day.
• Wiz on August 24 and OpenAI on September 18 reported more attack vectors.
• Around 15:00 UTC on October 20, the two CVE IDs started to circulate on forums and social media, without technical details. At 19:30 UTC php.net posted an advance notice.
• At 14:00 UTC on October 21, a day earlier than planned, PHP shipped the fixes.

That afternoon the PHP release sat near the top of Hacker News, a few lines from a Railway security disclosure, a GitLab critical patch release and a compromised LiteLLM package on PyPI.

More days like October 21

Days like October 21 are the new normal, and we have to get ready for them. Every mature codebase carries bugs that wait years for a second look, and AI-assisted research now makes that second look cheap for anyone, attackers included.

The same tools let us find those bugs ourselves before anyone else does. Our August audits found three high-severity bugs in Chainloop that our tests, reviewers and CI scanners had all missed. But we have to target the agents at the right places. An agent told to “find vulnerabilities” across all 3,304 files of the open-source Chainloop repository spends most of its budget on code that has never had a problem.

PHP’s own history already pointed at the right place, because the sign from the 2024 audit sat on the same root cause that Calif and OpenAI turned into remote code execution two years later. A project’s confirmed fixes mark the places where its code went wrong before, and the code around them deserves the first look.

Learning from past fixes

Defect-prediction research has shown for decades that bugs concentrate in a small share of files, and that past fixes in a file predict its future faults better than its size does (Ostrand and Weyuker, ISSTA 2002). Google Project Zero found that a large share of the 0-days exploited in the wild in 2021 were variants of bugs already disclosed, reachable through a path the original fix missed. We collected more of this research in Predicting the next vulnerability from a codebase’s own fix history.

We built AI Code Security Analysis to find those hotspots in a repository’s own history. It reads the commit history, finds the commits that fixed a security bug, confirms them, and compiles the result into a security context. Each confirmed fix records the rule it established in plain language, with a link back to the exact lines of code.

Hotspots tell an investigator where to start, so an agent that hunts for siblings of past fixes in authz.go spends its budget where the code already failed ten times, instead of spreading it across 3,304 files.

Hotspots also guard against regressions, because a new code path can skip a patch a year later and its reviewer may never have seen the original bug.

What it found in Chainloop

We have been running all of this on Chainloop itself, over the open-source Chainloop repository, from its first commit on March 6, 2023 to this week. The analysis triaged 2,618 commits, flagged 294 as candidates and confirmed 91 security fixes. Of those, 25 are high severity. Access control accounts for 38 of the 91, and the authorization code in authz.go needed 10 fixes on its own.

Over half of those fixes, 49 of the 91, landed in 2026, the year we started pointing agents at our own code. Most were old bugs, and 30 of the 49 had been open for more than a year. The red bars for flaws introduced shrink over the same quarters, but I wouldn’t read that as fewer regressions yet. A flaw only shows up in this history once someone fixes it, so the hatched quarters will fill in as we find what we introduced this year.

One of them sat open for about 3.6 years: the login flow put a reusable session token in the callback URL until we fixed it this month. Each confirmed fix records the flaw, how long it stayed open, and the rule it left behind.

The same record also reaches every pull request to the open-source repository, as a Chainloop comment. When a change touches one of those hotspots, the comment lists the rules their past fixes left behind, so the developer and the coding agent can take them into account before the change merges.

Last week, for example, our team wrote PR #3621 with the help of Claude Code. It lets operators add trusted origins that the login flow may redirect to after sign-in. That kind of change can reopen an old bug. In August we had fixed an open redirect in the same login flow that leaked freshly minted tokens to URLs an attacker chose, and the security context comment put the rule from that fix on the pull request:

“A post-login redirect that can carry a Chainloop bearer token must only target a relative path, a loopback CLI callback, or an explicitly configured Chainloop origin.”

Claude Code checked the change against the rule and said so on the pull request. The new setting only accepts explicitly configured origins, matched exactly, and its tests try the lookalike URLs an attacker would use.

I can’t tell you that the comment caused that design, because the PR description listed the strict validation before the comment arrived. For me the useful part is the timing, because a fix from August came back ten weeks later, on the day someone widened where the login flow may redirect.

Before the next October 21

AI makes old bugs cheaper to find, and we also write more code than we used to, more and more of it with AI, like the pull request above. We need ways to find bugs before attackers do, and to predict where the next ones are likely to appear.

A security context built from your own fix history is one of those tools, and only one. It points investigators at the code that already failed, like the 10 fixes in authz.go, and it keeps the rules of past fixes in front of every new change, whether a person or an agent wrote it. It fixes nothing by itself. Someone still has to act on those rules and triage what turns up.

Take one recent security fix in your repository, write the rule it established in a single sentence, and check one related path or one open pull request against it. To run the same check over your whole history, follow the AI Code Security Analysis docs, and if you want a hand switching it on, talk to us.