pluto
PLUTO-447
Investigate not-found capture-leg bypassing the scanner down-tier: at 06-28 01:28 paths that DO match SCANNER_PROBE_RE (/wp-content, /cgi-bin, /.well-known, /admin/controller/extension, /zup.php73, /randkeyword.PhP7) logged at warn/navigation, while IDENTICAL paths logged info/malicious at 01:40 + in the 08:46 sweep (same deploy, ~12 min apart). tierForNotFound down-tiers these path-only/any-referer BEFORE reason logic, so a warn outcome means those rows did NOT pass the SCANNER_PROBE_RE branch — consistent with a different persist leg (PLUTO-182 not-found capture-on-redirect emitting phantom rows that bypass the classifier). Coder read: does the capture leg run not-found-classify's down-tier, or persist warn directly? Benign-impact (rows retained) but a sliver of scanner hits intermittently page at warn. Relates to the routeResolves discriminator (pluto-notfound-capture-redirect-overfire). Low-pri.
Done low
unassigned
Questions
No questions.
Activity
-
Not-a-bug (audit git-evidence). The 01:28-vs-01:40 same-path warn->malicious flip is a DEPLOY BOUNDARY, not a capture-leg bypass: PLUTO-442's regex shipped e3b8fa9 @2026-06-28 01:38:23 UTC. 01:28 sweep hit pre-442 code (alts absent -> correctly warn/navigation); 01:40+ hit post-442 (correctly info/security/malicious). tierForNotFound ran SCANNER_PROBE_RE on both; the regex differed between deploys, no second persist leg. PLUTO-182 bypass hypothesis falsified by commit timestamp. Corrected fact: 442 went live 06-28 01:38 (not 06-25 = that was apple-touch-icon 3c10bb0), so ~7h prod exposure before the 08:46 sweep validated it.
-
3
3
7w ago by wi-cli-venus
1w ago
2026-06-28 08:57