The bug was old enough to rent a car. The camera on your wall is running older code than that.

In April, Anthropic published what its new model found when researchers pointed it at well-maintained open source software and typed, more or less, "please find a security vulnerability in this program."

It found a remote code execution flaw in FreeBSD's NFS server that had survived 17 years of human review. Unauthenticated root access, working exploit, no human help after the initial prompt. It found a denial of service bug in OpenBSD's TCP stack that had been sitting there for 27 years. It found a 16-year-old flaw in FFmpeg's H.264 decoder, which matters to this industry more than the other two, because H.264 decoding is what almost every video surveillance product on earth does all day.

The number that stopped me was not the age of anything. It was the price. The OpenBSD find cost under $50 of compute for that run. The full FreeBSD exploit, under $2,000. Anthropic says the model surfaced thousands of additional high and critical severity findings across about a thousand open source projects, and that when humans manually validated 198 of its reports, 89 percent matched the model's severity rating exactly.

I want to be careful about what this does and does not prove. These are vendor-reported results about the vendor's own model, most of the findings are still undisclosed because the patches do not exist yet, and Anthropic itself says the model could not crack everything. It ran several thousand scans against the Linux kernel and could not turn its findings into remote exploits, because the kernel has layers of defense that assume the code in front of them is hostile. Defense in depth held. That detail is the whole article, and I will come back to it.

Here is why I am writing this in a physical security context.

FreeBSD, OpenBSD, and FFmpeg are some of the most reviewed code on the planet. Security researchers have been staring at them for decades because they are prestigious targets. The bugs survived anyway, until the cost of looking dropped to fifty dollars.

Now think about what our industry runs on. Cameras, NVRs, access control panels, intercoms, badge readers. Embedded Linux builds assembled by the low bidder, busybox and an old kernel and a web server from 2014, often including that same FFmpeg lineage for decoding. Code that has never been a prestigious target. Nobody with Carlini's resume ever spent two weeks on your parking lot camera's firmware. The bugs in it were protected by one thing: looking for them was tedious, low-status work. Tedious is what these models eat.

And we already know what our fleet does when a patch exists, because we ran that experiment. In 2021 a command injection flaw in Hikvision cameras and NVRs was disclosed, unauthenticated, full device takeover. Hikvision shipped a fix. CISA put it in the Known Exploited Vulnerabilities catalog. It is 2026 and that five-year-old bug is still on CISA's exploited list, and scanners still find unpatched devices, because a camera that got mounted on a pole in 2021 and has worked fine ever since is a camera nobody logs into. Before that it was Mirai, which built one of the largest botnets in history mostly out of DVRs and cameras with default credentials. The pattern is stable: our devices outlive their patches by five to ten years. I have walked plenty of sites where the recording server is the oldest computer in the building and everyone is a little afraid to touch it.

So here is the collision. Vulnerability discovery just got cheap and automatic. Vulnerability repair, in physical security, still moves at the speed of a technician with a ladder. One of those curves bent this year. The other did not. You can already see the bend in public data. Epoch AI counted roughly 1,500 high and critical severity CVEs published by major vendors in June alone, more than three and a half times the monthly record from before Mythos shipped. That wave is landing on IT teams with patch pipelines. Ours mostly do not have one.

I do not think the answer is panic, and I do not think it is a new product. Anthropic's own recommendations to defenders are boring, which I mean as a compliment: use the same models to find your bugs first, treat dependency updates carrying CVE fixes as urgent, and reread the sentence they buried in the middle. Mitigations whose security value comes primarily from friction rather than hard barriers may become weaker. Friction was most of what protected embedded video hardware. That protection is gone.

What holds up is the stuff that assumed compromise from the start. The Linux kernel survived thousands of scans not because its code was cleaner but because its architecture treats every input as hostile. The physical security equivalent is not glamorous. It is a camera VLAN that cannot reach the finance VLAN. It is a device inventory that actually says what firmware is on the pole. It is asking a vendor, before the PO is signed, two questions that almost nobody asks: how long will this device receive security patches, and how will I know when it stops. It is treating a camera the way the kernel treats a packet.

If I were writing a procurement checklist this week, it would have one new line on it. Ask the vendor whether their own security team has pointed one of these models at their firmware yet. Anthropic is giving early access to critical infrastructure partners and open source maintainers for exactly this. Within a year or two, "we ran frontier-model discovery against our own code before an attacker could" will separate serious vendors from the rest, the same way signed firmware does now. The models do not care whether the person prompting them is on defense or offense. The only variable you control is who gets there first.

I keep thinking about the 27 years. That bug sat through the entire commercial history of IP video. Every camera generation, every VMS, every acquisition and rebrand, it was just there, waiting for the cost of looking to fall. The uncomfortable question for our industry is not whether there are bugs like that in the devices we install. There are. It is whether we find out from the vendor's security advisory or from the incident report.

If you run a fleet of cameras or panels: do you know, today, how many of your devices still receive patches at all? I suspect most honest answers are no. I would genuinely like to hear from anyone who has that inventory working, because that is the unglamorous thing worth copying.

Teach me something in the comments. I will be there.