GitHub naprawił podatność, w której skonfigurowany pre-receive hook mógł przekierować trusted internal requests do uprzywilejowanej usługi i doprowadzić do remote code execution na instancji. Exploitation wymagało włączenia pre-receive hook networking oraz uprawnień pozwalających skonfigurować lub zmodyfikować hook.
Feature-aware affectedness
Dwie instancje z identycznym release mogą mieć zupełnie inny stan:
Scanner wersji nie rozstrzyga tej różnicy. Atak wykorzystuje zaufanie między usługami wewnętrznymi: low-trust extension point → trusted network position → internal privileged service. VE powinien zebrać wersję GHES, stan hook networking, listę użytkowników mogących modyfikować hooki, network isolation i egress policy.
Mitigated, nie Fixed
Jeżeli upgrade nie jest natychmiast możliwy, wyłączenie hook networking lub ograniczenie możliwości konfiguracji hooków może usunąć attack path. To jest Mitigated, nie Fixed — podatny kod nadal jest obecny, a administrator może jutro włączyć networking z powrotem.
Wniosek
CVE-2026-76851 pokazuje, że feature networking jest elementem affectedness. Dla platform DevSecOps pytanie „czy rozszerzenie może wykonywać ruch sieciowy?” jest równie ważne jak wersja produktu.
Powiązane na blogu
- „Upgrade: websocket” wyłącza uwierzytelnianie — kontrola zależna od inputu/konfiguracji
- Keycloak: CVE tylko przy niebezpiecznej konfiguracji — configuration-aware VM
Źródła
- GitHub — Enterprise Server release notes (01.09.2026) — docs.github.com
- GitHub Advisory Database — GHSA-hp6r-mrh8-47vq — github.com/advisories
Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-76851 (GitHub Enterprise Server): pre-receive hook jako SSRF-to-RCE, wymaga włączonego pre-receive hook networking i uprawnień do modyfikacji hooka. Artykuł koncentruje się na feature-aware affectedness i różnicy Mitigated vs Fixed.