CVE-2026-99999 — PwnEscape: Erkennung und Mitigation

Praktischer Leitfaden auf Spanisch, um festzustellen, ob ein Linux-Server CVE-2026-99999 („PwnEscape") ausgesetzt ist, und wie man sie mitigiert. Enthält ein Skript, das das System prüft und ein Urteil samt Begründung liefert.

📋 Zusammenfassung

Feld	Wert
CVE	CVE-2026-99999
Name	PwnEscape
Komponente	Linux-Kernel, Verarbeitung von IPv4-Checksummen (`skb_checksum_help()`)
Schweregrad	CVSS 3.1 9.3 (Kritisch) — `AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`
Auswirkung	Eine bösartige VM kann den Speicher des Hosts lesen, ihn zum Absturz bringen und im Labor die Kontrolle mit root übernehmen
Vektor	Lokal: Der Angreifer muss Code innerhalb einer VM ausführen
Entdeckt von	Paulos Yibelo (pwn.ai), während der Sandbox Challenge von Vercel
Veröffentlicht	15. Oktober 2026
Upstream-Fix	Commit `6785011f8b16` (Michael S. Tsirkin, Red Hat)
Aktive Ausnutzung	Nicht gemeldet · Nicht im KEV-Katalog von CISA

🧠 Was ist das? (einfach erklärt)

Stell dir ein Wohnhaus vor:

Das Gebäude ist der physische Server, der Host.
Jede Wohnung ist eine virtuelle Maschine (VM).
PwnEscape ist ein Fehler in den Wänden des Gebäudes: Aus einer Wohnung heraus kann ein bösartiger Mieter die Verwaltung des Gebäudes ausspähen oder sich Zugang verschaffen.

┌──────────────────────────────────────┐
│  HOST (servidor físico + hipervisor) │  ← aquí está la falla
│  Linux con KVM / QEMU / Firecracker  │
│                                      │
│   ┌─────────┐ ┌─────────┐ ┌────────┐ │
│   │  VM  A  │ │  VM  B  │ │  VM  C │ │
│   │         │ │(atacante)│ │        │ │
│   └─────────┘ └─────────┘ └────────┘ │
└──────────────────────────────────────┘

Die Schwachstelle liegt im Host, nicht in den VMs. Deshalb:

✅ Wenn dein Server ein VPS oder eine VM ist (DigitalOcean, AWS, Hetzner, Proxmox usw.), bist du nicht das Ziel. Derjenige, der patchen muss, ist dein Anbieter oder wer den Host administriert.
⚠️ Wenn dein Server VMs hostet (Proxmox, KVM/libvirt, OpenStack, Firecracker), bist du das Ziel, vor allem wenn du VMs von Dritten oder nicht vertrauenswürdigen Code ausführst.

🔬 Wie funktioniert es? (technische Ebene)

Linux erlaubt es Netzwerkpaketen, Metadaten mitzuführen, die angeben, wo eine Prüfsumme beginnt und wo ihr Ergebnis geschrieben wird. Das ist eine legitime Optimierung für das Checksum Offloading.

Das Problem ist die Reihenfolge der Operationen:

Der Kernel empfängt ein Paket von der VM mit einem normalen IPv4-Header (IHL = 20 Bytes) und validiert es.
Danach überschreibt eine verzögerte Prüfsummenoperation, gesteuert durch die von der VM gesendeten Metadaten, denselben bereits validierten Header und ändert ihn auf IHL = 60 Bytes.
Die Fragmentierungslogik vertraut dem neuen Wert und kopiert mehr Daten, als das Paket tatsächlich enthält.
Diese zusätzlichen Bytes sind Host-Speicher (32 Bytes pro Paket im Test), und der Angriff lässt sich wiederholen.

Der Fix stellt sicher, dass der Beginn der Prüfsumme nicht in einen bereits verarbeiteten IPv4-Header zeigen kann. Er wird auf fünf betroffene Netzwerkpfade angewendet.

Der verwundbare Code existiert seit dem Kernel 2.6.27 (2008).

📦 Korrigierte Versionen

Zweig	Erste korrigierte Version
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.57
7.2	7.2.11
Mainline	7.3-rc7

⚠️ Ubuntu, RHEL/Rocky/Alma, SUSE und Proxmox verwenden ihre eigene Nummerierung (zum Beispiel 5.15.0-125-generic oder 5.14.0-503.el9). Bei diesen Distributionen sagt die Versionsnummer allein nichts aus: Man muss den Sicherheitshinweis der Distribution oder das Changelog des Kernels prüfen.

Zweige außerhalb dieser Liste (6.8, 6.19, 7.0, 7.1…) haben keinen Upstream-Support mehr und haben den Fix nicht erhalten.

🔍 Bin ich betroffen?

Option A — Automatisches Skript (empfohlen)

curl -O https://raw.githubusercontent.com/alvaroguzmancode/CVE-2026-99999/refs/heads/main/check-pwnescape.sh
sudo bash check-pwnescape.sh

Das Skript prüft drei Dinge:

Rolle des Rechners: ob es eine VM ist, ob sie VMs hostet oder ob sie sie hosten könnte, es aber derzeit nicht tut.
Patch: sucht das CVE im Changelog des Kernels und vergleicht mit den korrigierten Versionen.
Ausstehender Neustart: ob ein neuer Kernel installiert ist, der noch nicht aktiv ist.

Beispielausgabe auf einem VPS:

== VEREDICTO ==
  Rol:    Este equipo ES una máquina virtual; no hospeda otras VMs.
  Kernel: VULNERABLE — la versión del kernel es anterior a la corregida.

  NO EXPUESTO DIRECTAMENTE.
  La falla solo se explota desde una VM hacia el servidor que la hospeda.
  Este equipo no hospeda VMs, así que no hay a quién atacar desde aquí.

  Ojo: el que SÍ debe estar parchado es el host que aloja esta VM
  (tu proveedor de nube o tu servidor Proxmox/KVM). Confírmalo con ellos.

Exit-Code	Bedeutung
`0`	Nicht anfällig oder nicht exponiert
`1`	Anfällig
`2`	Konnte nicht bestätigt werden, muss manuell geprüft werden

Option B — Manuelle Prüfung

1. Bin ich eine VM oder ein Host?

systemd-detect-virt                     # "kvm", "xen", etc. = eres una VM; "none" = físico
pgrep -a qemu-ga                        # si aparece, eres una VM (QEMU Guest Agent)
lsmod | grep -E 'kvm|vhost'             # módulos de virtualización cargados
cat /sys/module/kvm_intel/refcnt 2>/dev/null || cat /sys/module/kvm_amd/refcnt   # >0 = hay VMs usando KVM
virsh list --all 2>/dev/null            # VMs de libvirt
pgrep -a '^(qemu-system|firecracker)'   # VMs / microVMs corriendo

2. Hat mein Kernel den Patch?

uname -r

# Debian / Ubuntu
zgrep -i "CVE-2026-99999" /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz

# RHEL / Rocky / Alma / Fedora
rpm -q --changelog kernel-core-$(uname -r) | grep -i "CVE-2026-99999"

3. Fehlt ein Neustart?

[ -f /var/run/reboot-required ] && echo "Falta reiniciar"   # Debian / Ubuntu
needs-restarting -r                                          # RHEL

🛡️ Mitigation

1. Den Host-Kernel aktualisieren (echte Lösung)

# Debian / Ubuntu / Proxmox
sudo apt update && sudo apt full-upgrade

# RHEL / Rocky / Alma / Fedora
sudo dnf update kernel

Die Kernel-Maintainer empfehlen, die vollständige stabile Version deiner Distribution zu installieren und nicht den einzelnen Commit anzuwenden.

2. Neu starten und überprüfen

sudo reboot
# después:
uname -r
sudo bash check-pwnescape.sh

Die Installation des Pakets reicht nicht aus: Der neue Kernel wird erst nach einem Neustart wirksam. Überprüfe in Clustern jeden Hypervisor.

3. Nur die VMs zu patchen reicht nicht

Ein Kernel-Update innerhalb der VMs beseitigt das Risiko nicht, da die Schwachstelle im Host liegt. Wenn du Kunde eines VPS bist, bestätige bei deinem Anbieter, dass er seine Hosts bereits gepatcht hat.

4. KVM deinstallieren, wenn du es nicht nutzt

Wenn auf dem Rechner KVM geladen ist, aber keine VMs gehostet werden, kannst du die Angriffsfläche reduzieren:

Beliebteste

CVE-2026-99999