Strona główna / Blog / GHES: TOCTOU RCE, dane „Unknown”

Blog · analiza

GitHub Enterprise Server: RCE przez wyścig między walidacją uploadu a jego użyciem. GitHub zna fixed releases, a GHSA nadal pokazuje „Unknown”

GitHub Enterprise Server ma wysoką podatność TOCTOU pozwalającą authenticated userowi z write access do repozytorium podmienić zwalidowany upload na attacker-controlled content przed jego przetworzeniem. Skutkiem może być arbitrary code execution na instancji. GitHub opublikował fixed builds 1 września 2026: 3.17.20, 3.18.14, 3.19.11, 3.20.7, 3.21.5 i 3.22.0. Jednocześnie GitHub Advisory Database pokazuje Affected versions: Unknown i Patched versions: Unknown.

CVE-2026-19118: TOCTOU między walidacją uploadu a jego użyciem → podmiana treści → arbitrary code execution.
Fixed builds: 3.17.20, 3.18.14, 3.19.11, 3.20.7, 3.21.5, 3.22.0 (release notes, 01.09.2026).
Pułapka danych: GHSA pokazuje Affected/Patched: Unknown.

Dlaczego to ważne dla VM?

To czysty przykład, że structured vulnerability record może być uboższy niż vendor release notes tego samego dostawcy. Pipeline pobierający tylko affected/patched fields może uznać CVE za niezmapowane, choć producent opublikował konkretne fixed releases. Najlepszy model zachowuje provenance:

GHSA structured mapping: unknown vendor release notes: fixed versions known confidence: high

System powinien wzbogacić rekord bez nadpisywania źródła — inaczej „Unknown” zablokuje remediation, która realnie jest dostępna.

Wniosek

CVE-2026-19118 pokazuje problem jakości danych w synchronizacji między advisory, structured database i release notes. Brak wersji w jednym źródle nie powinien blokować remediation, jeśli vendor opublikował je gdzie indziej.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-19118 (GitHub Enterprise Server, TOCTOU → arbitrary code execution); GitHub podał fixed builds 3.17.20–3.22.0, podczas gdy GitHub Advisory Database pokazuje Affected/Patched: Unknown. Artykuł koncentruje się na jakości danych i zachowaniu provenance przy mapowaniu wersji.

Zapamiętaj jedno

Structured vulnerability record może być uboższy niż release notes tego samego dostawcy. Brak wersji w jednym źródle nie powinien blokować remediation, jeśli vendor opublikował je gdzie indziej — najlepszy model zachowuje provenance zamiast nadpisywać źródło.