Kitze's pwn.watch Tracks Live Exploits and Hands Your AI Agent the Patch Brief

Gouache illustration of Chris Pirillo as a 1970s TV weatherman pointing at a map board where storm clouds and lightning hang over tiny server racks. — Illustration: LockerGnome

The counter at the bottom of pwn.watch reads “Days without an incident 0.” The longest quiet stretch in the past year was 17 days, June 24 to July 10. On October 23 the site showed 49 live incidents, 31 of them under “Patch now” and 17 marked critical.

The page’s own pitch is short: “Bugs in software you might run, and whether there’s a fix yet.” Each entry says what’s affected, what fixes it, and how to check whether you’re exposed. The site splits them into patch-now bugs, breaches and supply-chain attacks, and its llms.txt counts 730 incidents in the archive: 637 patch-now, 59 breaches, 34 supply-chain.

The part worth stealing is under the hood. “All endpoints are plain files with CORS enabled; no auth, no rate limits on our side,” the llms.txt says, and every incident’s JSON carries an agentBrief, a Markdown remediation brief written for a machine to act on. The agent page turns that into a job. Paste its instructions into your agent “and it will watch pwn.watch on a schedule, check whether new incidents affect your stack, and only ping you when one does.” The agent polls /changes.json at most hourly with ETag requests, reads each changed incident, and checks “your lockfiles and services against the fixed versions.”

This week shows why that matters. GitLab’s 19.5.1 patch release on October 21 fixed a CVSS 10.0 bug that “could have allowed an unauthenticated user to execute arbitrary code on the GitLab server,” in every version from 7.0 on. The pwn.watch brief for it gives the version check, sudo gitlab-rake gitlab:env:info, and adds a warning GitLab’s own page doesn’t spell out: instances that only took an earlier October 12 regex fix “remain vulnerable and must upgrade again.” That’s pwn.watch’s claim, so treat GitLab’s advisory as the final word, the way the site’s own footer says to: “Always check the vendor advisory before acting.”

LockerGnome has covered how fast this moves: ZDI mailing unpatched Linux kernel bugs to a public list, and a volunteer who fixed PHP2Shell bugs for a DNS engineer. Most small shops don’t have anybody reading advisories at all. An agent that already lives in your repo, already knows your lockfiles, and checks one feed an hour gives those shops somebody reading. What nobody has measured yet is how often a single maintained feed misses a bug, and an agent told to stay quiet will stay quiet about that too.

Steal this

If you self-host anything, run the check command from the incident brief today. For GitLab that’s sudo gitlab-rake gitlab:env:info, then compare the version with GitLab’s advisory. Kind of like checking the smoke detector battery before you smell smoke.
When you wire an agent to a security feed, make it cite the vendor advisory in every alert it sends you. pwn.watch says it’s “Not security advice,” and a second source keeps one wrong entry from becoming a wrong patch. This is like reading the label on the pill bottle after a friend tells you the dose.
Give the agent your lockfiles plus a written list of every service you run, including the ones with no lockfile, like a GitLab box or a router. The agent page’s design compares “your lockfiles and services against the fixed versions,” so a service missing from that list never gets checked. Kind of like a packing list: whatever you forget to write down stays home.

More Security