Ein Fehler, der seit November 2010 im Code steckt, macht Servern jetzt Sorgen. The Hacker News berichtet über CVE-2026-97631: einen Pufferüberlauf im Netzwerk-Boot-Code von EDK II, dem quelloffenen UEFI-Referenzcode. Der Code läuft bevor Secure Boot und andere Prüfungen greifen.
WAS IST DAS PROBLEM?
Der PXE-Treiber kopiert ICMP-Fehler- und Statusmeldungen in einen festen Speicherbereich von 504 Byte. Die Größenprüfung ist im IPv4- und im IPv6-Code falsch. Längere Meldungen laufen deshalb in benachbarten Speicher über.
Ein Angreifer braucht eine einzige präparierte Nachricht, während die Maschine per Netzwerk bootet. Passwort oder vorherigen Zugang braucht er nicht. Wahrscheinlichste Folge ist ein Absturz oder ein hängender Boot. Code auszuführen ist schwerer: Laut Advisory müsste der Angreifer den genauen Firmware-Build kennen. Der Code läuft einmalig und bleibt nicht von selbst bestehen, kann aber Code nachladen, der es tut.
WIE GEFÄHRLICH IST DAS WIRKLICH?
Das TianoCore-Advisory (GHSA-99cj-7hg9-mp4m, 22. Oktober) vergibt CVSS 9,5. Red Hat und SUSE stufen die Lücke als aus dem angrenzenden Netz ausnutzbar ein, nicht über das Internet. Laut Ars Technica ist sie allein kein Einstiegstor ins Netz. Realistisch sind Innentäter oder Angreifer mit einem Fuß im lokalen Netz.
HD Moore von Dragos weist auf ein weiteres Szenario hin: Dort, wo der Bootvorgang Zugriff auf das TPM hat, könnte sich der Programmfluss umlenken lassen. Bei kurzem Zugriff oder Diebstahl könnte das Festplattenverschlüsselung aushebeln.
WER IST BETROFFEN?
- EDK II bis einschließlich edk2-stable202608 (21. August 2026). PXE ist im Standard-Build aktiv.
- Firmware-Hersteller auf Basis von EDK II, laut THN unter anderem AMI, Insyde, Phoenix und Microsofts Project Mu. Ihr Produktstatus ist teils unklar, mehrere Firmen antworteten nicht.
- Linux-Distributionen: Red Hat führt edk2 in RHEL 8, 9 und 10 als betroffen und ungefixt. SUSE und Debian markieren ihre Pakete ebenso.
- Intel kennt keine betroffenen kommerziellen Produkte mit Support, Arm sieht die Lücke nicht direkt anwendbar.
Für Homelab-Fans interessant: Wer VMs mit OVMF, dem EDK-II-Build für virtuelle Maschinen, per PXE bootet, sollte das Advisory beobachten. Ob OVMF im Einzelfall betroffen ist, ergibt sich aus den Paketinformationen deiner Distribution.
WIE ES DAZU KAM
Gefunden haben die Lücke Alex Matrosov (als Anthropic gelistet) und Dan Holmes-Mitra (als Google gelistet). Geplant war eine koordinierte Offenlegung im Januar 2027. Doch am 28. September beschrieb ein öffentlicher Pull Request (#13200), abgezeichnet von einem AMI-Entwickler, die Lücke samt CVE-Nummer und Fix. Das beendete die Schweigefrist. Das Advisory folgte am 22. Oktober.
Der Fix wurde am 15. Oktober in den EDK-II-Hauptzweig gemerged (PR #13302) und kürzt zu lange Meldungen auf 504 Byte. Ein stabiles Release enthält ihn noch nicht, das Advisory führt „Not patched currently“. Project Mu hat den Fix am 26. Oktober in getaggte Builds übernommen.
SO SCHÜTZT DU DICH
- PXE abschalten, wo du es nicht brauchst. Das Advisory nennt sonst keinen Workaround.
- Netz trennen: Boot-Netze (VLAN) von Büro- und Gast-Geräten isolieren.
- BIOS-/UEFI-Updates deines Server-Herstellers verfolgen und einspielen, sobald sie erscheinen.
- Logs beobachten: Auffälligen Boot-Netzwerkverkehr überwachen.
FAZIT: Altlast mit Ansage
Die Lücke ist kein Weltuntergang, aber ein Lehrstück. Sie steckt im gleichen PXE-Code, der schon bei PixieFail im Januar 2024 auffiel, und Fuzzing-Projekte seither fanden sie nicht. Wer PXE nicht braucht, schaltet es ab. Alle anderen warten auf das Firmware-Update.