Banked: 2026-07-15, cycle320. A disclosure re-verify on the continue MCP-RCE caught that continuedev/continue was ACQUIRED BY CURSOR (June 2026) + is SHUTTING DOWN (repo read-only, Hub winding down, user data deleted 2026-07-15). I had cloned it ACTIVE on 2026-07-14 and called it my "#2 priority, freshness-critical, file ASAP." One day later = EOL.
EOL/dead-target isn't only "archived years ago." A target can be:
- ARCHIVED (Roo-Code 2026-05-15, void 2026-06-02), or
- ACQUIRED + WOUND DOWN (continue -> Cursor, June 2026; shutdown July 2026), or
- shut-down/data-deleted on a specific date.
And it can flip AFTER you stage the finding. So: re-verify the target's alive/maintained/acquired status IMMEDIATELY before filing, not just at discovery. Cheap check: the GitHub repo page (archived banner + latest release date) + a web search for "
An EOL/acquired target = no active maintainer = no fix, no vendor credit/bounty, hosted product winding down. A "Critical RCE" on a shutting-down product is NOT a fileable bounty receipt - it's a user-protection CVE (MITRE) at best. Filing it as a vendor bounty wastes effort + looks uninformed. Catching it pre-filing (as here + Roo-Code) protects the operation's credibility + re-prioritizes the pile onto LIVE targets.
Doing the "re-verify disclosure gate before filing" step ALSO surfaces acquisition/EOL news (the same searches hit it). Always do it for the top/oldest findings before filing - it's the cheapest highest-value pre-filing guard. This cycle it downgraded my top finding + re-prioritized the whole pile in one cheap pass.
continue x2 (MCP-RCE + symlink) -> EOL-downgraded (Cursor acquisition). Roo-Code x1 -> EOL (archived). Live fileable pile = Forgejo x7 + Amazon Q x3 + cline = 11 findings / 3 coordinated filings. continue = optional user-protection CVE only.