W VM false negative jest często najgorszym typem błędu: daje ciszę tam, gdzie powinien pojawić się alarm. CVE-2026-84809 jest wyjątkowo dobry, bo nie chodzi o subtelny błąd modelu AI ani o prompt injection. Problem jest podstawowy: scanner sam usuwa wykonywalny artefakt z powierzchni analizy. Tencent AI-Infra-Guard w module skill-scan ignorował __pycache__ oraz .pyc/.pyo/.pyd — agent analizujący skill nie widział tych plików, choć Python wykonuje bytecode .pyc podczas importu.
dir_tree pomijał __pycache__ i skompilowany bytecode → agent LLM nie miał czego analizować..pyc (PEP 552 UNCHECKED_HASH) dostaje SAFE verdict i 100/100 trust score, a po imporcie wykonuje kod.Dlaczego to ważne dla VE
W wielu organizacjach wynik narzędzia jest traktowany jak fakt: scanner = SAFE → artifact = safe. Poprawny model brzmi: scanner = SAFE → scanner nie wykrył zagrożenia w powierzchni, którą faktycznie przeanalizował. Każde narzędzie ma observation boundary; jeśli część wykonywalnych artefaktów jest poza nią, wynik negatywny nie jest pełnym dowodem bezpieczeństwa.
Attack path
Scanner nie „uruchamia ataku” — dostarcza fałszywy sygnał, który może skłonić człowieka lub pipeline do zaakceptowania złośliwego artefaktu. To vulnerability chaining między scanner false negative a operacyjnym zaufaniem do wyniku.
CVE w scannerze czy problem supply chain?
Oba spojrzenia są użyteczne. Jako CVE dotyczy produktu i jego analizy skill packages. Z punktu widzenia organizacji ważniejszy jest downstream effect: jeśli wynik skanowania jest warunkiem publikacji, instalacji lub dopuszczenia do marketplace, luka staje się elementem supply-chain control bypass.
Scanner assurance — mierz false negatives inaczej
False positives mierzymy dobrze (analityk zamyka niezasadny ticket). False negatives poznajemy zwykle po incydencie. Dla scannerów AI/agent skills warto pytać: jakie typy plików narzędzie enumeruje; co jawnie ignoruje; czy ignorowane klasy mogą być wykonywalne; czy analizuje source, compiled artifacts czy oba; czy archiwa są rozpakowywane rekursywnie; czy „SAFE” oznacza pełne coverage czy tylko brak sygnału w analizowanej części. Tego nie da się naprawić samym promptem — jeśli agent nie dostaje informacji, że plik istnieje, „sprawdź wszystkie złośliwe pliki” nic nie zmieni. Wiele problemów AI security to problem tool contract, data plumbing i coverage, nie modelu.
Wcześniej zeskanowane skille — invalidation of evidence
Patch naprawia przyszłe skany, ale nie unieważnia automatycznie wcześniejszych SAFE verdicts. Jeśli historyczne artefakty mogły zawierać ukryty bytecode, po naprawie należy rozważyć rescan populacji. VE powinien potraktować zmianę jako scanner defect → invalidation of previous evidence → targeted rescan, nie tylko „upgrade narzędzia”. Test regresyjny po naprawie musi zawierać dokładnie klasę bypassu (benign .py + malicious .pyc + __pycache__ + import) oraz warianty .pyo/.pyd i nested archives — to variant analysis.
Wniosek
CVE-2026-84809 pokazuje, że bezpieczeństwo skanera trzeba oceniać jak bezpieczeństwo chronionego systemu. Jeśli narzędzie ma listę obiektów, których nie widzi, zapytaj: czy któryś z nich może się wykonać? Tu odpowiedź brzmi: tak — a wtedy „SAFE 100/100” nie jest tylko niedokładnym wynikiem, lecz fałszywym dowodem bezpieczeństwa, który bywa groźniejszy niż brak skanera.
Powiązane na blogu
- MCP: 12 CVE i jakość danych — czym jest wiarygodny sygnał
- Log4j2 i FOIS — obecność ≠ pełny obraz ryzyka
Źródła
- Tencent AI-Infra-Guard — issue #531 (10.08.2026) — github.com/Tencent
- GitHub Advisory Database — GHSA-7vc4-66f2-3f5f / CVE-2026-84809 (02.09.2026) — github.com/advisories
Nota redakcyjna: stan informacji 7 września 2026. CVE-2026-84809 (Tencent AI-Infra-Guard, skill-scan): pomijanie __pycache__ i .pyc powoduje SAFE 100/100 dla skillu z malicious bytecode. To failure of scanner coverage, nie LLM reasoning; patch nie unieważnia wcześniejszych SAFE verdicts. Artykuł koncentruje się na scanner assurance i observation boundary.