DevOps in the AI era: 0-day protection, for 0-day vulnerabilities.

In today's web you need to know what your infrastructure is doing, while it is doing it, and a response that can keep up with today's pace of model-assisted hacking. What you need is a live sitrep on the system, and a response that can keep up.

The job is situational awareness, a live sitrep is the tech stack and version breakdown of the system, all its dependencies and how they are connected. Looking at a couple of popular projects we can see why this is needed: the rate of findings is increasing day by day, and the time to a patch on public disclosure is decreasing.

OpenJS says Node.js usually sees six or seven vulnerability reports a month. From 15 December 2025 it took more than 30 a month. After agent-assisted scanning arrived, February ran at 4.6x the usual level, and March brought 65 reports. Its Q2 update described the June security release as 13 fixes, up from a norm of around six or seven a release. The 21 October release included CVE-2026-111497, an out-of-bounds write in the bundled Brotli decoder, reported by OpenAI Codex Security.

PHP Foundation says AI-assisted research is why its security team now receives far more reports than before. Since 1 July that team has published 15 CVEs, after setting aside more than 100 reports that were invalid, duplicated, or impossible to reproduce. Calif, OpenAI, and Wiz reported the two critical flaws patched on 21 October. Read more about that on the PHP Foundation blog.

WordPress shipped 7.0.2 on 17 July 2026, backported fixes to 6.9.5 and 6.8.6, and turned on forced automatic updates for affected sites. This release fixed CVE-2026-63030 and CVE-2026-60137, discovered on the 6.9 and 7.0 release lines, they are unauthenticated remote code execution on a default install, no plugin required, as bad as it gets for a CMS. Dark Reading reported widespread exploitation and a public proof-of-concept within a day. Adam Kues, credited on the WordPress release for the remote-code-execution report, wrote that GPT-5.6 Sol Ultra took the work from the bug to a finished chain in 10 hours: "I make no general claims, but I can say with complete confidence that no security researcher could have found and completed this exploit chain in 10 hours without AI."

The system kernel itself is also at continued risk. CVE-2026-98432, published on 15 October, is a flaw in Linux that accepts IPv4 connections, and it has been there since kernel 4.4, and the kernel CVE team scored it 9.8. Ubuntu says this can lead to remote code execution without a login, and at this low level it could be used to take over a server.

Anthropic, on 27 October, said an unreleased Claude model with directed prompts wrote an exploit that runs commands as root. Their proof of concept reached that in about 53 minutes. They have not published the exploit. They showed it on a server listening with Multipath TCP, and Go 1.24 and later turn that on for listening sockets on Linux unless you opt out, so a normal Go service can already be in the setup they took over. Turning Multipath TCP off only steps out of that setup. The flaw is in ordinary IPv4 TCP, so the kernel update is what closes it.

The patch has not reached a normal Ubuntu update yet. Canonical's note on 2 November places kernels for 22.04, 24.04, and 26.04 as proposed. Packages there do not install it on their own, and no date has been published by Canonical on the regular channels. Updated on 3 November, the tracker still marks those generic kernels, including 26.10, as a work in progress, and 20.04, 18.04, and 16.04 as vulnerable with no fix yet. Cloud and hardware-enablement kernels are the same, many of them still open. Red Hat shipped fixes on 1 November for RHEL 8, 9, and 10, and raised its own score to 9.8 after first rating the issue moderate. Debian, SUSE, Oracle Linux, and Amazon Linux have already shipped fixes in October. It's important to detail that a kernel fix is not live until the machine is rebooted. Until then, every site on the box shares this vulnerability.

To simplify, yes. A small business website can be a collection of tech stacks: PHP runtime, a CMS, a collection of plugins, a host firewall, a DNS provider, and a mail path. Those pieces are often looked after by different providers across different systems, and none of these entities alone can read every advisory, every log, and action the fixes at the speed these findings now move.

This gap is the hard part. The person responsible for the business services is responsible for holding three problems at once:

• They have to know what part of their stack is actually exposed today.
• They have to keep the service standing for the hours between disclosure and a verified patch.
• They have to assume the next person reading the advisory already has an open-weight model on the attacker's own hardware.

Tools like Wordfence, Patchstack, Cloudflare, and many others already provide a live feed of a system and specific attack vectors. What's changing is that this stops being an upgrade for security-focused services, and becomes the default way any web service is run. Wordfence Premium receives firewall rules and malware signatures as their research team releases them, plus a live IP blocklist. The free plugin gets that feed 30 days later, which is far too late to be useful in the context of these vulnerabilities.

Cloudflare presented their edge response rules in public on the July WordPress issues. Their WAF rules went out at 17:03 UTC on 17 July 2026, on every plan including free, for sites whose traffic they proxy. The rule reduces exposure as a temp solution while waiting for the WordPress update. On the PHP release they applied the same pattern: rules moving as new variants appeared, described by their own people as a stopgap until the patched binary was the process serving traffic. This is a real example of live sitrep with live action.

Cloudflare also released Zero Wire on 3 November: a public news wire for critical vulnerabilities in Internet-facing software, the application, the runtime, and the service on the network, exactly what the doctor ordered! Each briefing is a card: what happened, who should look, what to do now, and a breakdown of how severe it is and whether anyone is using it. It is not a list of every CVE, let's be clear, and it's a first public release. The Linux TCP flaw and the PHP runtime issue are already on it, so it's a great start. It's also very specific, such as when a WAF rule can help mitigate the attack traffic, the report says so. It also includes a prompt you can give an agent that can see your own infrastructure, and you do not need to be a Cloudflare customer to read this feed!

These tools cover different layers, and collectively they give a picture of your web services and semi-live exposure, drawn from their logs, in as quick a time as currently possible without developing your own defensive measures. This is where the full picture really binds together, live feeds from multiple reputable providers, and with your own trained AI agents acting as your system bodyguards, Kevin Costner would be proud.

The actions we can derive from these feeds are the real challenge, and ultimately the real holy grail of automation. Receive a feed, and provide the appropriate tool access, safe steps to take, and we are almost at the point where we can sleep again. This is the magic layer where you get the benefit of AI, and successful implementation here comes down to the proficiency of your tech team. Here are some examples of what we can do:

• Stop a named service and return placeholder responses.
• Force serve the cache, so a stored response can be served in its place while processing services are disabled.
• Attach a temporary WAF rule for the shape of the traffic, and take it off when the patched version is verified.
• Block a source that is repeating one payload across all services.
• Snapshot your services on a regular basis, use this as a baseline manifest for live comparisons.
• Hash the contents of a directory, and compare it to the baseline to detect changes. This one has saved many developers' hours of manual work.
• Your developers' imagination, and business requirements are the only limits here.

Make sure you have a developer who understands your business, this is one of the biggest assets you can have today, someone who cares about your products that is not afraid to ask the hard questions and tell you when an AI model is wrong or your business is unsafe.

Your action list should aim to be short, and grow to match the complexity of your business. Keep it simple applies to both the actions, your application design, and your business crisis response. Five moves you have rehearsed will beat a catalogue you have never run EVERY SINGLE TIME.

Your developer or system admin is responsible for results. How you use AI to build and maintain your web systems is irrelevant. What matters is that you can point at an individual responsible for the agents' output, someone who actually feels responsible for the systems and the urgency to act. The only way to be safe is to have a solid team who own the architecture, and who is not afraid to ask the hard questions and tell you when an AI model is wrong for your business goals.

The agent watches the logs and runs the holding actions on the list. The person responsible still owns the system, the list, and the patch. This combination of automation and responsibility is the key to success in the AI era.

The developer is your frontline defence. These are the moves an owner or an admin can make this week, without waiting on anyone you can protect yourself now.

• Enforce MFA, and make the sign-in phishing-resistant. Every account that can change the code, the mail, the DNS, the host, or handle the money. A password plus a text message is not good enough, you need a passkey or a hardware key. If a provider cannot offer that, name the account as a risk you have accepted.
• Train the people who read the mail. It's easy to spot a phishing attempt, but staff need a drill to be sure: what a real message looks like, what they do not click, and who they should call to validate the request. Get in touch if you want Pendulum to run that training.
• Audit every public surface in Arc. The security report provides is a first look at what anyone on the internet can already see. It reads the public surface: the system and version if they are leaked, the response headers, the cookies, mixed content, open admin paths, and files that should never be public, such as an environment file, a database dump, or a debug page. When a version is clear enough, it checks known advisories against that version. A clear report is a first step towards certifying that the site is safe. It is the picture you should hold daily, and this is the one an attacker gets for free just by crawling your public pages.

Any provider who wants to stay up to speed with the top model capabilities needs access to up-to-date feeds, and established actions and tooling that can be used in a live environment. This is the only way to be safe against an ever-increasing threat level.

The next issue will not arrive on a calendar. The defence has to be live when it does. This is not a reactive fix, it is a proactive measure to keep your business safe. Make sure you have the right tech team supporting your business ready when it matters most.