After PHP, now Node.js, Java and Python: get used to patching more

Published Updated AI Braindump

After this week's PHP vulnerabilities, Java, Node.js and Python packages need security updates too. I think we'll have to get used to this pace of reports and patches. And developers will have plenty of work to do.

Tweakers reported on the Node.js flaw. The flaw, CVE-2026-111497, is in Brotli, a library that decompresses data. Node.js released patches on 21 October in versions 22.23.4, 24.22.1 and 26.12.1, and credits OpenAI Codex Security with the discovery. Imperva showed that an attacker could use it to run their own code on Node.js 24.22.0. The patched version rejected the same input.

The same decoder is used by the Python packages Brotli and brotlicffi, fixed in 1.2.1 and 1.2.1.0. Aikido explains that HTTP clients such as requests and httpx use them automatically when installed. So your own code doesn't even need to call Brotli directly.

Oracle also released Java SE patches. Those are separate issues. For the Brotli flaw, the Dutch NCSC rates the likelihood of exploitation as medium and the potential damage as high. On 23 October, there was no evidence of active exploitation yet.

Finding flaws more often and fixing them faster

OpenAI expects findings like these to increase sharply in the coming months. It also describes AI helping with fixes and tests, which maintainers and security experts check. Attackers get those capabilities too.

Java already makes this concrete. Oracle shipped its first monthly Java update on 18 August, alongside its familiar quarterly schedule. The next one is planned for 17 November. Oracle explicitly cites AI as the reason: vulnerabilities are being found and fixed faster and at greater scale. Teams need to prepare their testing and deployment for that.

I expect this to become the new reality. Patching more often will hurt at times, as we saw with PHP.

Over time, though, I think software will become safer through this. Every flaw found early and fixed properly is one less in the libraries we all build on. But a discovered vulnerability remains a risk until the patch is running. Brotli shows this well: according to Aikido, the root cause was already fixed in the source code in February. Nobody saw it as a security issue then, no release followed, so the fix ran nowhere.

Developers as builders and agent team leads

That work doesn't do itself. Someone has to decide what gets patched, how, and whether it can safely go live. That's why I believe our profession will stay. Developers are becoming builders, architects, agent team leads and security specialists. We type less ourselves. Deciding what to build, how the parts fit together and whether the result can be trusted becomes the actual job.

For me, that includes delegating well and efficiently to AI. One agent can prepare a change; another can investigate its effects on the rest of the application. As the developer, you define the task, provide the context and check the result. You also need to step in when agents disagree or carry forward a wrong assumption.

Take the Brotli update. An agent can trace which packages bring the library in, prepare the new versions and run the tests. But whether that analysis holds up, whether the update can go live today and who steps in if something breaks anyway: that's the developer's call. That responsibility doesn't get delegated. The typing matters less. The developer doesn't.