CVE-2026-98432: die TCP-Lücke im Linux-Kernel auf Debian, Ubuntu und Proxmox schließen

Mitte Oktober 2026 ist eine Lücke im TCP-Verbindungsaufbau des Linux-Kernels bekannt geworden, die über jeden per IPv4 erreichbaren Port angreifbar ist, ganz ohne Anmeldung. Debian und Proxmox haben gefixte Kernel ausgeliefert, Ubuntu noch nicht. Dieser Beitrag erklärt, wer betroffen ist, welche Stände sicher sind, was bis zum Patch hilft und wie Sie mit unserem freien Prüfskript Ihre Server bewerten.

Was ist passiert?

Gemeldet hat die Lücke Xinyang Ge von Anthropic, den Fix hat Eric Dumazet geschrieben und am 1. Oktober eingereicht. Er steckt in Linux 7.3-rc7 und in allen gepflegten Stable-Zweigen. Die Distributionen haben sehr unterschiedlich schnell nachgezogen:

• 01.10.: Der Patch „ipv4: free inet_opt and ireq_opt after an RCU grace period“ geht an die Netzwerk-Maintainer.
• 15.10.: Das Kernel-CVE-Team veröffentlicht CVE-2026-98432 samt der gefixten Stable-Versionen.
• 16.10.: Debian liefert für Debian 13 linux 6.12.113-1 aus (DSA-6568-1).
• 17.10.: Debian LTS folgt für Debian 12 mit linux 6.1.190-1 (DLA-4841-1). Am Abend baut Proxmox den Kernel 7.0.14-25 auf den Quellen von Ubuntu-7.0.0-43.43.
• 22.10.: Debian LTS liefert den optionalen Kernel linux-6.12 für Debian 12 nach (DLA-4850-1); Proxmox baut 7.0.14-26.
• 26.10.: Ubuntu legt die gefixten Kernel 6.8.0-149.149 (24.04) und 5.15.0-203.213 (22.04) in die Vorabstufe -proposed.
• 27.10.: Anthropic beschreibt einen Exploit, den ein Claude-Modell geschrieben hat: Root-Rechte ohne Zutun des Opfers auf Servern mit MPTCP-Listener.
• 28.10.: Für 26.04 folgt 7.0.0-43.43 in -proposed. Am selben Tag erscheint regulär 7.0.0-42, noch ohne Fix.
• 29.10.: Ubuntu führt die Fixversionen für 22.04 bis 26.10 im CVE-Tracker als „in Arbeit“, freigegeben ist keine; am Abend des 30.10. kommen weitere Kernelvarianten dazu.
• 30.10.: Laut Proxmox stehen 7.0.14-25 und -26 nun auch im Enterprise-Repository.

Die Lücke verständlich erklärt

Beim TCP-Verbindungsaufbau legt der Kernel für jedes eingehende SYN eine Verbindungsanfrage an und merkt sich dort auch die IPv4-Optionen des Pakets, etwa Record Route oder Timestamp. Kommt das abschließende ACK, entsteht daraus der eigentliche Socket. Die Funktion tcp_v4_syn_recv_sock() übergibt ihm die Optionen, ohne sie zu kopieren.

Schickt der Client sein SYN genau in diesem Moment erneut, baut eine andere CPU aus denselben Optionen noch ein SYN-ACK, während der neue Socket schon wieder abgebaut und der Speicher freigegeben wird: ein use-after-free in ip_options_build(). Dasselbe Rennen gibt es bei der Migration von Verbindungsanfragen zwischen Sockets (net.ipv4.tcp_migrate_req=1 oder ein BPF-Programm für SO_REUSEPORT). Der Fix gibt die Optionen erst nach einer RCU-Wartefrist frei, mit kfree_rcu() statt kfree().

• Voraussetzung: ein per IPv4 erreichbarer TCP-Port im Zustand LISTEN und Pakete mit IP-Optionen, die bis zum Server durchkommen. Eine Anmeldung braucht der Angreifer nicht.
• Wiederholbar: Ein verlorenes Rennen bricht laut Anthropic nur den Handshake ab, der Server stürzt nicht ab. Der Angreifer kann es also beliebig oft versuchen.
• MPTCP: Der Exploit von Anthropic zielt auf Server mit einem Multipath-TCP-Listener; warum, sagt Anthropic nicht. Der Fehler selbst sitzt im normalen TCP, die CVE-Meldung erwähnt MPTCP nicht.
• IPv6: tcp_v6_syn_recv_sock() kopiert die Optionen, native IPv6-Verbindungen sind vom Hauptfehler nicht betroffen. Den IPv6-Teil der Migration soll ein eigener Patch beheben. IPv4-Verbindungen auf Dual-Stack-Sockets ([::]) laufen im Kernel aber durch den IPv4-Pfad.

Wer ist betroffen?

Betroffen ist jeder Kernel ab Linux 4.4, der per IPv4 Verbindungen annimmt: SSH, Webserver, Mailserver, Datenbanken, die Verwaltungsoberfläche eines Hypervisors. Entscheidend ist, welcher Kernel die Verbindung annimmt:

Sichere Versionen

Die Fixstände, Stand 31. Oktober 2026. Maßgeblich ist der laufende Kernel, nicht der installierte. Upstream sind diese Stable-Versionen korrigiert: 5.10.272 · 5.15.223 · 6.1.190 · 6.6.159 · 6.12.113 · 6.18.56 · 7.2.10 · 7.3.

Die Cloud-Kernel von Ubuntu (linux-aws, -azure, -gcp, -oracle, -ibm) haben eigene Versionsnummern; das Prüfskript kennt die angekündigten Stände aller Varianten. Ob Canonical Livepatch die Lücke abdeckt, haben wir nicht geprüft; maßgeblich ist canonical-livepatch status.

1.Patchen und neu starten

Auf Debian und Proxmox genügen die normalen Paketquellen. Der zweite Schritt ist der wichtige: Ein neuer Kernel wirkt erst nach dem Neustart.

sudo apt update
sudo apt full-upgrade            # pulls the fixed linux-image package
sudo reboot

# afterwards: Debian package version of the running kernel
uname -v | grep -oP 'Debian \K\S+'

apt update && apt full-upgrade
apt install proxmox-kernel-7.0          # only if the node still runs 6.17
proxmox-boot-tool kernel list           # no old kernel pinned?
reboot
uname -r                                # 7.0.14-25-pve or newer

Im Cluster die Knoten nacheinander neu starten: VMs vorher migrieren, bei Ceph vorher ceph osd set noout setzen und nach dem Neustart wieder aufheben. Ob der laufende Kernel den Fix hat, zeigen diese Einzeiler mit fertigem Ergebnis:

# Proxmox VE
k=$(uname -r); dpkg --compare-versions "${k%-pve}" ge 7.0.14-25 && echo "OK: $k" || echo "VULNERABLE: $k"

# Debian
v=$(uname -v | grep -oP 'Debian \K\S+'); case "$v" in 6.1.*) t=6.1.190-1;; 6.12.*) t=6.12.113-1~deb12u1;; *) t=;; esac; [ -z "$t" ] && echo "CHECK: $v" || { dpkg --compare-versions "$v" ge "$t" && echo "OK: $v" || echo "VULNERABLE: $v"; }

Ubuntu: den Fix vorab aus -proposed holen

Bis zur Freigabe gilt für Ubuntu: Notbehelf setzen, dann apt update && apt full-upgrade und Neustart, sobald das Update erscheint. Wer exponierte Server nicht so lange offen lassen will, kann den Kernel gezielt aus der Vorabstufe -proposed holen. Dort liegen 7.0.0-43.43 für 26.04 seit 28.10., 6.8.0-149.149 für 24.04 und 5.15.0-203.213 für 22.04 seit 26.10.; das Changelog von 7.0.0-43.43 führt den Fix „ipv4: free inet_opt and ireq_opt after an RCU grace period“ auf. Wir haben die Schritte in einem Ubuntu-26.04-Container nachvollzogen: Ohne -t bleibt apt bei 7.0.0-42, mit -t kommt 7.0.0-43.43.

# make -proposed known; priority 100 means apt takes nothing from it unasked
sudo tee /etc/apt/sources.list.d/proposed.sources >/dev/null <<'EOF'
Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: resolute-proposed
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
EOF
printf 'Package: *\nPin: release a=resolute-proposed\nPin-Priority: 100\n' | sudo tee /etc/apt/preferences.d/proposed-updates
sudo apt update

# dry run first: which packages would come from -proposed?
sudo apt install -s -t resolute-proposed linux-generic | grep '^Inst'
sudo apt install -t resolute-proposed linux-generic
sudo reboot
uname -r                                  # 7.0.0-43-generic

• Nur den Kernel: Die Priorität 100 sorgt dafür, dass apt full-upgrade nichts aus -proposed holt; unter 22.04 ist die Datei in preferences.d Pflicht, ab 24.04 setzt Ubuntu diese Priorität schon selbst. Andere Kernelvarianten holen Sie über ihr Metapaket, etwa linux-aws oder linux-generic-hwe-22.04, sofern Ubuntu sie schon nach -proposed gelegt hat; die Simulation mit -s zeigt das. Auf ARM-Servern lautet die Quelle http://ports.ubuntu.com/ubuntu-ports.
• Vorabstufe heißt Teststufe: Nicht jeder Kernel aus -proposed wird freigegeben; unter 26.04 kamen etwa 7.0.0-17, -26 und -39 nie in die regulären Quellen. Erst auf einem Testsystem installieren, dann auf den exponierten Servern.
• Danach aufräumen: Ist der Kernel regulär freigegeben, die beiden Dateien löschen und apt update ausführen. Ab dann kommen Kernel wieder nur aus den normalen Quellen.

Das Prüfskript kennt die angekündigten Fixversionen und bewertet einen Kernel aus -proposed deshalb schon als gefixt.

2.Sonderfall Proxmox VE 8

Proxmox VE 8 hat seit August 2026 keinen Support mehr. Der letzte Kernel des 8er-Zweigs, 6.8.12-43, stammt vom 18. August, der optionale 6.14.11-9 vom 15. Mai. Beide sind älter als der Patch; den 7.0-Kernel gibt es für Proxmox VE 8 laut Proxmox nicht. Es bleibt nur das Upgrade auf Proxmox VE 9, mit diesen Voraussetzungen aus der Upgrade-Anleitung:

• alle Knoten auf 8.4 mit pve-manager ab 8.4.1 und mindestens ein fehlerfreier Lauf von pve8to9 --full;
• hyperkonvergentes Ceph vorher auf Squid 19.2;
• getestete Sicherungen aller VMs und Container, Konsolenzugang über IPMI oder vor Ort, mindestens 5 GB frei auf /;
• keine Container mit systemd 230 oder älter (cgroup v1), etwa CentOS 7 oder Ubuntu 16.04.

Bis das Upgrade durch ist, gehört eine Regel gegen IPv4-Optionen an die Firewall vor dem Cluster und die Verwaltungsdienste dürfen nur aus dem Verwaltungsnetz erreichbar sein.

3.Notbehelf bis zum Patch

Der Angriff braucht IPv4-Pakete mit Optionen. Wer sie verwirft, bevor sie den Kernel erreichen, nimmt ihm die Grundlage. Am wirksamsten ist das an der Firewall vor den Servern, weil es dort alle Systeme auf einmal schützt.

An der Firewall: Palo Alto Networks

Port- und Anwendungsregeln helfen nicht: Das erste SYN zu einem freigegebenen Port kommt durch, bevor App-ID die Anwendung kennt. PAN-OS verwirft IP-Optionen über ein Zone-Protection-Profil:

1. Network › Network Profiles › Zone Protection: Profil anlegen, im Reiter Packet Based Attack Protection › IP Drop Timestamp und Record Route anhaken. Die Best Practice von Palo Alto empfiehlt zusätzlich Strict und Loose Source Routing, Unknown und Malformed.
2. Network › Zones: das Profil der Internet-Zone zuweisen und committen.

Auf dem Host: nftables

Diese Regeln verwerfen TCP-Pakete, deren IPv4-Kopf länger als 20 Byte ist, also Optionen trägt. Die Tabelle inet sieht alles, was den Host selbst erreicht oder von ihm geroutet wird, die Tabelle bridge alles, was über eine Bridge läuft. Welche Sie brauchen, hängt davon ab, wie die Gäste angebunden sind:

Beide Tabellen zusammen decken jede dieser Anbindungen ab, die letzte ausgenommen. Die Datei lässt sich mehrfach laden und ersetzt dabei nur ihre eigenen Tabellen:

#!/usr/sbin/nft -f
# Stopgap CVE-2026-98432: drop IPv4 TCP packets that carry IP options.
# Re-running replaces only these two tables; other tables stay untouched.
table inet cve98432
delete table inet cve98432
table bridge cve98432
delete table bridge cve98432

table inet cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}
table bridge cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}

Dauerhaft laden

Mit nft -f geladen gelten die Regeln nur bis zum nächsten Neustart. Für den Dauerbetrieb gibt es zwei Wege:

• Eigene systemd-Unit: Sie lädt die Regeln vor dem Netzwerk und ist aufgebaut wie Debians nftables.service, nur ohne flush ruleset.
• Eintrag in /etc/rc.local: passt, wenn dort schon Firewall-Regeln stehen. rc.local läuft laut systemd aber erst nach network.target, beim Booten bleibt also ein kurzes Fenster ohne Schutz.

[Unit]
Description=Stopgap CVE-2026-98432: drop IPv4 TCP packets with IP options
Wants=network-pre.target
Before=network-pre.target shutdown.target
Conflicts=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/nftables.d/cve-2026-98432.nft
ExecReload=/usr/sbin/nft -f /etc/nftables.d/cve-2026-98432.nft
ExecStop=-/usr/sbin/nft delete table inet cve98432
ExecStop=-/usr/sbin/nft delete table bridge cve98432

[Install]
WantedBy=sysinit.target

systemctl daemon-reload && systemctl enable --now cve-2026-98432-stopgap.service

In /etc/rc.local gehört stattdessen dieser Block vor exit 0. Schlägt er fehl, schreibt er eine Meldung ins Journal und rc.local läuft weiter. Auch unter #!/bin/sh -e bleiben die übrigen Regeln also nicht auf der Strecke:

# CVE-2026-98432 stopgap: drop IPv4 TCP packets with IP options (host, routed and bridged guests)
nft -f - <<'EOF' || logger -t rc.local "CVE-2026-98432 stopgap: nft load failed"
table inet cve98432
delete table inet cve98432
table bridge cve98432
delete table bridge cve98432
table inet cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}
table bridge cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}
EOF

Nur mit iptables

Wer seine Regeln mit iptables pflegt, erreicht dasselbe mit der Erweiterung u32. Sie liest das Längenfeld des IPv4-Kopfes, das vorangestellte -C verhindert doppelte Einträge:

# CVE-2026-98432 stopgap: drop IPv4 TCP packets with IP options (host and routed guests)
iptables -t raw -C PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP 2>/dev/null || iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

• Reicht für: die Dienste des Hosts und Gäste an einer Bridge, die der Host nur routet.
• Reicht nicht für: Gäste an einer Bridge mit Layer-2-Uplink. iptables sieht diesen Verkehr nur mit br_netfilter und net.bridge.bridge-nf-call-iptables=1. Dann laufen aber alle gebridgten Pakete auch durch die FORWARD-Kette; im Test schnitt eine FORWARD-Policy DROP die Gäste komplett ab.
• Prüfskript: cve-2026-98432-check.sh erkennt als Notbehelf nur die nftables-Regel.

Praxistest: Greifen die Regeln?

Ob Firewall und Host die Pakete wirklich verwerfen, zeigt ein Test gegen einen offenen TCP-Port. Er baut drei Verbindungen auf: eine ohne Optionen als Gegenprobe, je eine mit Record Route und mit Timestamp. Er braucht nur Python 3 auf einem Linux-Rechner und keine Root-Rechte. Je Variante schickt er nur einen normalen Verbindungsaufbau.

python3 - ZIEL-IP 22 <<'EOF'
# Practical test for the CVE-2026-98432 stopgap: does a SYN with IPv4 options reach the service?
import socket, sys
host, port = sys.argv[1], int(sys.argv[2])
OPTIONS = {"none": b"",
           "record-route": bytes([7, 7, 4, 0, 0, 0, 0]),
           "timestamp": bytes([68, 8, 5, 0, 0, 0, 0, 0])}

def probe(opt):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.settimeout(3)
    if opt:
        s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS, opt)
    try:
        s.connect((host, port))
        return "OPEN"
    except socket.timeout:
        return "DROPPED"
    except ConnectionRefusedError:
        return "REFUSED"
    except OSError as e:
        return "ERROR " + (e.strerror or str(e))
    finally:
        s.close()

res = {name: probe(opt) for name, opt in OPTIONS.items()}
for name, r in res.items():
    print(f"{name:13s} {r}")
with_opts = [r for n, r in res.items() if n != "none"]
if res["none"] != "OPEN":
    print(f"RESULT: INCONCLUSIVE, {host}:{port} accepts no connection even without options")
elif all(r == "DROPPED" for r in with_opts):
    print("RESULT: PROTECTED, SYNs with IP options are dropped on the way")
elif any(r in ("OPEN", "REFUSED") for r in with_opts):
    print("RESULT: NOT PROTECTED, SYNs with IP options reach the target")
else:
    print("RESULT: INCONCLUSIVE, check the lines above")
EOF

Was der Test prüft, hängt davon ab, wo der Prüfrechner steht. Für einen vollständigen Blick auf die eigene Infrastruktur lohnen sich alle drei Standorte:

Ein PROTECTED sagt nur, dass das Paket irgendwo verworfen wurde. Wo genau, zeigen die Zähler: auf dem Host die Zeile mit hdrlength, bei Palo Alto Networks show zone-protection zone <Zone>. Steigt kein Zähler, hat ein anderes Netz dazwischen das Paket verworfen. Der Prüfrechner selbst darf deshalb nicht hinter einer Firewall stehen, die IP-Optionen verwirft.

echo "rules: $(nft list ruleset | grep -c 'hdrlength > 5') (expected 2)"
nft list ruleset | grep 'hdrlength > 5'
iptables -t raw -L PREROUTING -v -n | grep '0xf=0x6:0xf'   # iptables variant

Weitere Schritte

• Grenzen: Wer selbst IPv4-Optionen nutzt, etwa Record Route zur Fehlersuche, verliert diese Pakete. VMs schützt die Regel auf dem Host von außen, das Kernel-Update im Gast ersetzt sie nicht.
• MPTCP abschalten: sysctl -w net.mptcp.enabled=0 und dauerhaft unter /etc/sysctl.d/. Das schließt den Weg des veröffentlichten Exploits, nicht den Fehler; laufende MPTCP-Listener bleiben bis zum Neustart des Dienstes.
• Migration aus lassen: net.ipv4.tcp_migrate_req steht ab Werk auf 0.
• Angriffsfläche verkleinern: SSH und Verwaltungsoberflächen nur aus dem Verwaltungsnetz oder über VPN erreichbar machen.

4.Das Prüfskript cve-2026-98432-check.sh

Wir haben die Prüfungen aus diesem Beitrag in ein Skript gegossen. Es läuft als root, ändert nichts am System und schreibt nur einen Bericht. Im Terminal erscheinen ausschließlich feste Texte, Kernelversionen und Zählwerte; Ports, Adressen und Prozesse stehen nur im Bericht, den nur root lesen kann. So lässt sich die Ausgabe gefahrlos weitergeben.

curl -fsSLO https://nokkela.blog/downloads/cve-2026-98432-check.sh
curl -fsSLO https://nokkela.blog/downloads/cve-2026-98432-check.sh.sha256
sha256sum -c cve-2026-98432-check.sh.sha256     # must print: cve-2026-98432-check.sh: OK

sudo bash cve-2026-98432-check.sh

Lesen Sie das Skript vor dem ersten Lauf: Es sind gut 500 Zeilen Bash ohne Abhängigkeiten außer den Bordmitteln von Debian, Ubuntu und Proxmox. So sieht die Ausgabe in unserem Testbett aus, einem Debian-13-Container mit absichtlich gesetzten Funden; der Kernel ist dort der von WSL2 und damit unbekannter Herkunft:

### cve-2026-98432-check 1.0.1 (Linux TCP use-after-free), fixed versions as of 2026-10-31
[ INFO ] Platform Debian GNU/Linux 13 (trixie)
[ INFO ] Running kernel 6.6.114.1-microsoft-standard-WSL2 (other)
[ INFO ] Inside a container (docker): this kernel belongs to the host, fix it there

### Kernel
[FAILED] 'Kernel of unknown origin 6.6.114.1-microsoft-standard-WSL2: below the fixed version 6.6.159 upstream, ask its vendor'

### Exposure until the fixed kernel runs
[ INFO ] TCP listeners beyond loopback (IPv4 reaches dual-stack sockets too): 1 (report line 9)
[  OK  ] 'MPTCP disabled or not available'
[FAILED] 'Request socket migration on, second path of the race: 1 (report line 12)'
[ INFO ] nftables rules dropping IPv4 packets with options (stopgap): 1 (report line 15)

### Result
[FAILED] 'Yellow: 2, review and assess'
[ INFO ] Report: /opt/cve-2026-98432-check/reports/report-20261031-073818.txt
[ INFO ] View all details: tail -n +8 /opt/cve-2026-98432-check/reports/report-20261031-073818.txt

Rote Zeilen bedeuten: Der laufende Kernel hat keinen Fix. Gelbe Zeilen sind Einstellungen, die die Angriffsfläche vergrößern, oder ein Kernel, dessen Herkunft das Skript nicht kennt. Der Rückgabewert ist 2 bei Rot, 1 bei Gelb und 0 ohne Funde, damit lässt sich das Skript auch in Ansible oder ein Monitoring einbinden.

Veröffentlichte Erkennungsmerkmale eines Angriffs gibt es zum Stand dieses Beitrags nicht. Kernel-Abstürze (Oops, panic) seit Mitte Oktober auf einem Server mit offenem Port sind aus unserer Sicht ein Grund, genauer hinzusehen.

Häufige Fragen

Quellen

Externe Quellen, Stand 31. Oktober 2026 (öffnen in einem neuen Tab):

• Linux-Kernel-CVE-Team, Meldung zu CVE-2026-98432 mit den gefixten Stable-Versionen
• Linux, Commit e3f33b0a1d89 „ipv4: free inet_opt and ireq_opt after an RCU grace period“
• CVE.org, CVE-2026-98432
• Debian Security Tracker, CVE-2026-98432
• Debian, DSA-6568-1 (trixie)
• Debian LTS, DLA-4841-1 (bookworm, linux)
• Debian LTS, DLA-4850-1 (bookworm, linux-6.12)
• Ubuntu, CVE-Tracker zu CVE-2026-98432
• Launchpad, Veröffentlichungshistorie des Ubuntu-Kernels (Pockets security, updates, proposed)
• Launchpad, Changelog von linux 7.0.0-43.43
• Ubuntu-Kernel-Team, How to test kernels in -proposed
• Red Hat, CVE-2026-98432
• Proxmox-Forum, CVE-2026-98432 in Proxmox VE (Aussagen des Proxmox-Teams)
• Proxmox, pve-kernel 7.0.14-25
• Proxmox VE, FAQ mit Supportzeiträumen
• Proxmox VE, Upgrade from 8 to 9
• Anthropic, Discovering and exploiting vulnerabilities with Claude
• Palo Alto Networks, Packet-Based Attack Protection
• Proxmox VE, Firewall (nftables-Firewall und eigene Tabellen)
• Debian, systemd-rc-local-generator(8): rc.local läuft nach network.target
• Debian, iptables-extensions(8) mit der Erweiterung u32

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Prüfung im Einzelfall. Versionsstände und Befehle beziehen sich auf den genannten Stand und sind an Ihre Umgebung anzupassen. Das Prüfskript wird unter der BSD-2-Clause-Lizenz ohne Gewähr bereitgestellt. Stand: Oktober 2026.