Check H13 · execution family · severity MEDIUM · automatic · one of the 18 Hugging Face checks
The question this check asks: has Hugging Face's own malware and pickle-import scanner actually finished checking every file in this repository — or is RepoGates looking at a gap where an answer should be?
H13 is the direct companion to H6 and H7. Those two report what the Hub's scanner found. H13 reports something different: that the Hub hasn't finished looking yet. "The Hub scanned it and found nothing" and "the Hub hasn't finished scanning it" are not the same fact, and treating them as interchangeable would quietly turn every unscanned file into a false clearance.
The two nullifAI models are the concrete case for why this matters (see /intel/malicious-models.html). glockr1/ballr7 and who-r-u0000/0000…0000 both fired H13 alongside H5 (access flags) in the 12 September 2026 roster run — not because their scans found anything, but because Hugging Face had already disabled both repositories before the scan could resolve. The roster reports REVIEW on that gap rather than silently reading "no scan result" as "no problem."
Contrast that with star23/baller13 from the same table: still live and still scannable, it fires H6 and H7 directly — a completed scan that found something — not H13. Between the three, you can see exactly the boundary H13 is drawn around: incomplete, completed-and-clean, and completed-and-positive are three different states, and H13 is the only one of the eighteen checks that covers the first.
H13 reads the scan status the Hub's own API reports for each file. When a file's scan has not resolved, the finding hf-scan-pending fires at MEDIUM, costing 4 points, with a deliberately short TTL so the check is retried rather than cached stale. The evidence note in the scoring table:
“an unscanned file is not a clean one; short TTL retries it”
H13 never resolves to PASS on the file it's watching — by construction it only fires while a result is pending. Once the Hub's scan actually completes, H13 stops firing on that file and H6 or H7 report whatever the scan actually found, positive or clean. H13 sits in the install and run dimension alongside H6–H10 — the checks that together ask what happens when this artifact is actually used, not merely cloned. Verdict math is the same engine used across all 18 checks: any CRITICAL finding zeroes the score and reads BLOCK outright; otherwise the score starts at 100 and fired findings' points are subtracted, floored at 0, graded green (PASS, ≥ 80), amber (REVIEW, 50–79) or red (BLOCK, < 50 or any CRIT). In the two documented nullifAI cases the reported outcome was REVIEW, driven by H13 alongside H5, not by H13 in isolation.
The 12 September 2026 top-100 measurement (/intel/malicious-models.html) names individual fire counts for two checks only — H7 four times, H8 fourteen times — and does not publish a separate per-check count for H13. We don't have that number yet and won't invent one.
The two live examples we do have are both genuine incompletes tied to Hugging Face disabling the repositories, not proven-clean repositories that fired anyway. That means we don't yet have a documented case of H13 firing purely on scan latency against an otherwise healthy, fully available repository — which is a limit on what we can claim, not a claim that such a case doesn't exist.
H13 never tells you why a scan is incomplete — a file freshly uploaded and not yet queued looks the same to this check as a file whose repository was disabled before its scan could resolve, as in both nullifAI cases. It answers "is there an answer yet," not "why isn't there one."
And a completed scan — H13 not firing — is not a safety guarantee either. H6 and H7's own limits still apply: the Hub's scans are best-effort by Hugging Face's own disclaimer, and nullifAI is the proof, a pickle stream deliberately corrupted after the malicious opcode so Picklescan errored out before it ever reached the payload. H13 only ever closes the gap where there's no result at all; it says nothing about the quality of a result that does exist.
And RepoGates as a whole gates browser downloads only — it does not see git clone, package managers, curl, or fetches made by AI agents outside the browser.
Without installing anything: the Files and versions tab on the repository's Hub page shows each file's scan status directly — look for a result badge next to the file rather than a pending or missing indicator. Because the underlying state can change quickly, refresh after a short wait if you see no result; a short TTL is by design here, on both the Hub's side and RepoGates'.
To understand what a resolved result actually means once it appears, read the H6 and H7 pages — H13 only ever tells you whether you're looking at one of their results yet.
Does H13 mean the file is dangerous? No. It means the Hub's own scanner hasn't finished or couldn't complete its check — not that anything was found, and not that nothing was. Both nullifAI survivors fired H13 because Hugging Face disabled them before their scans could resolve.
Why does H13 never resolve to PASS? Because "no answer yet" is never the same fact as "checked and clean." It's a short-TTL retry, not a clearance; once the Hub's scan completes, H6 and H7 report the real result and H13 stops firing.
Does RepoGates stop git clone while a scan is pending? No. Browser-initiated downloads only.
H6 Hub malware scan hit — what H13 is standing in for until it resolves · H7 Hub pickle-import scan — the other completed-scan result H13 defers to · H5 Access flags — fired alongside H13 in both documented nullifAI cases, since a disabled repository is both an access flag and an interrupted scan.
Add RepoGates to Chrome Pricing
Numbers on this page: RepoGates' Hugging Face scoring tables (backend/repotriage/hf/catalogue.py, backend/policy/scoring.json); the 12 September 2026 roster measurement and 17 September 2026 re-verification (/intel/malicious-models.html).