Lictor AI
Lictor AI shield

Retractions.

Every false positive. The apology. The fix.

Most security tools double down when they’re wrong. We publish a receipt.

8
disclosures retracted (all from GitHub Patrol cohort; 0 retractions from the 92 external-scan disclosures to date)
276
disclosures total, a 97.1% accuracy rate (184 GitHub-public + 92 direct-email CVD)
< 30 min
from detection of FP to public apology + scanner fix landed

The full log

Sorted newest-first.

RET-001 → RET-008

The May 17 IL /admin batch

Sent: 2026-05-17 09:20 to 13:12 UTC
Retracted: 2026-05-17 22:35 to 22:45 UTC (~12h later)
Fix shipped: 2026-05-17 23:00 UTC (same hour)

What we got wrong

We sent 8 contact-request issues to maintainers of Israeli sites (.co.il TLDs) flagging their /admin page as a “painted-lock” exposure. The page returns content before redirecting to login. All 8 turned out to be false positives.

Root cause

Our pilot scanner’s /admin check used urllib.request with default follow-redirects. When a site sat behind a WAF (Radware, Cloudflare anti-bot) or was a Next.js / React SPA returning the same HTML shell for any URL, the scanner saw “HTTP 200 + HTML body + no ‘login’ text in first 2KB” and flagged it. The reality: those sites were behind challenge pages or returning SPA shells, not exposing admin at all.

The retraction (sent on all 8 issues, then each was closed)

On re-verification with stricter heuristics, this report appears to be a false positive from our scanner. The pattern we flagged (/admin returning content) was triggered by your site’s SPA / framework returning the same HTML shell for unknown paths, not by an actual exposed admin panel.

This is a bug in our scanner. We’re closing this issue and fixing the detection logic so it doesn’t happen again. No action needed on your end.

Sorry for the noise. I appreciate you being patient with an automated outreach tool that’s clearly still learning its job. Voice + accuracy are the product; today this report failed on accuracy.

Thanks,
Raffa
Lictor AI · https://lictor-ai.com

The scanner fix (shipped same hour)

Built scripts/verify-finding.py, a strict re-checker that:

  • Does NOT auto-follow redirects (sees the raw response)
  • Detects 20+ WAF / bot-challenge fingerprints (Radware __uzdbm, Cloudflare cf-ray, Akamai, Imperva, PerimeterX, DataDome, etc.)
  • Requires actual admin-panel markup (dashboard, manage-user, sidebar, etc.), not just any HTML
  • For .env exposures: requires Content-Type: text/plain + ≥3 KEY=VAL lines + no <html

Every flag now passes through this verifier before becoming a contact-request. See the commits →

The 8 issues (all closed, retraction comments filed)

All 8 were closed with a public retraction comment within hours. We don’t name the affected sites here. Publicly listing someone we wrongly flagged would compound the original mistake. Aggregate only, always.

What we learned

  1. Naive HTTP probes are dangerous. WAFs and SPA fallbacks defeat almost any URL-based heuristic. Every URL-based check now needs verifier-gating.
  2. Speed without verification is more dangerous than slow + right. Catching it ourselves before more damage spread was the only thing that protected our voice promise.
  3. Public retraction with apology > silent close. Several maintainers wrote back acknowledging the apology. None expressed anger.

The retraction process, for next time

Documented in our public skill suite. Every future Lictor maintainer follows this exact sequence.

  1. Within 30 minutes of confirming a false positive: post the apology comment on the original issue. Use the template above (or a tone-matched variant).
  2. Close the issue as not_planned. Never silently delete or hide. The retraction itself is part of the record.
  3. Push the scanner fix the same day: code in scripts/verify-finding.py or the offending pilot. PR title prefixed fix: so it appears in the changelog.
  4. Append a new RET-NNN entry on this page within 24 hours. Newest-first. Never edit older entries except to add followup comments.
  5. If a maintainer asks for additional context, respond directly, even after closing. The relationship outlasts the issue.

Why we do this publicly

“Most security tools hide their false positives. We publish them. The cost of being wrong in public is the price of being trusted in public.”

Every commercial AppSec scanner has a false-positive rate. They usually publish the “catch” numbers and bury the “miss” numbers. Our 96% accuracy rate is real because the 4% lives on this page, with names and links, exactly where you can find it.

If we ever stop publishing retractions (even when we have one to publish), that’s your signal that the project has lost the plot. Walk away.