CVE-2026-56862 dotyczy pakietu crypto/tls w Go. Złośliwy klient może wielokrotnie wysyłać wiadomości TLS KeyUpdate, zmuszając serwer do ciągłego wyprowadzania nowych kluczy — powstaje pętla kosztownych operacji kryptograficznych i możliwe jest wyczerpanie zasobów CPU. Red Hat klasyfikuje problem jako Important (zdalny, nieuwierzytelniony DoS). Ciekawe dla VM: golang może występować w inventory jako toolchain, zależność build-time albo runtime statycznie skompilowanego programu — i tylko ostatni przypadek bywa realnie istotny dla działającej usługi.
KeyUpdate → pętla derywacji kluczy → wyczerpanie CPU.crypto/tls, terminujące TLS, wystawione niezaufanym klientom.golang installed nie znaczy crypto/tls reachable
Najprostszy scanner powie golang package present → CVE present. Ale Go bardzo często tworzy statyczne binaria, a aplikacja może używać innej wersji toolchaina niż ta zainstalowana na hoście. Poprawne pytania: które binaria zbudowano podatnym Go? czy importują crypto/tls? czy terminują TLS? czy są wystawione niezaufanym klientom?
SBOM powinien zejść do build provenance
Dla aplikacji Go przydatne są: wersja Go użyta do kompilacji, build provenance, digest artefaktu i deployment mapping. Jeżeli host zaktualizowano do nowego toolchaina, stare binarium nadal może zawierać podatny kod: host package fixed ≠ deployed binary rebuilt.
Remediation: patch toolchain czy rebuild?
W statycznie kompilowanych aplikacjach aktualizacja pakietu Go na builderze nie usuwa podatności z istniejących artefaktów. Pełna ścieżka: update Go toolchain → rebuild affected binaries → regenerate images → redeploy → verify binary build version. Dojrzały finding zawiera też: affected build? TLS server role? network exposure? rate/connection limits? reverse proxy?
Wniosek
CVE-2026-56862 pokazuje, że dla Go jednostką remediation nie zawsze jest pakiet systemowy. Najważniejsze pytanie VE brzmi: które uruchomione binaria rzeczywiście zawierają podatny crypto/tls i są osiągalne dla niezaufanych klientów?
Powiązane na blogu
- containerd w SBOM, ale nieuruchomiony — obecność ≠ osiągalność podatnego kodu
- OpenSSL: Low CVE tylko gdy używasz QUIC — feature/runtime decyduje o affectedness
Źródła
- Red Hat — CVE-2026-56862 — access.redhat.com
- CVE.org — CVE-2026-56862 — cve.org
Nota redakcyjna: stan informacji 2 września 2026. CVE-2026-56862 to remote unauthenticated DoS w Go crypto/tls (powtarzane KeyUpdate). Artykuł koncentruje się na runtime reachability i build provenance dla statycznie kompilowanych aplikacji Go.