Security 29.05.2026 Aktualisiert: 02.06.2026

CIFSwitch: Linux cifs.spnego LPE prüfen, mitigieren und patchen

CIFSwitch betrifft Linux-Kernel mit cifs-utils und User-Namespaces. Betroffene Distributionen, Angriffsweg, Checks, Mitigation und Patchstände.

Stand: 02.06.2026, 18:30 Uhr CEST. CIFSwitch ist inzwischen als CVE-2026-46243 geführt. AlmaLinux hat die zuvor getesteten Kernel in die Production-Repositories übernommen, Debian listet fixe Security-Kernel und CloudLinux nennt konkrete Kernel-, KernelCare- und Feed-Stände. Entscheidend ist trotzdem nicht nur uname -r, sondern ob dein laufender Kernel den Fix smb: client: reject userspace cifs.spnego descriptions enthält oder ob cifs-utils, cifs.spnego und unprivileged user namespaces den bekannten Angriffspfad nicht mehr zulassen.

Kurzfassung

Worum es geht: CIFSwitch ist eine lokale Rechteausweitung im Zusammenspiel aus Linux-Kernel-CIFS-Client und cifs-utils. Ein unprivilegierter lokaler Benutzer kann unter passenden Bedingungen Root werden.
CVE-ID: CVE-2026-46243.
Remote allein ausnutzbar: Nein. Der Angreifer braucht lokale Code-Ausführung, zum Beispiel Shell-Zugriff, kompromittierten Webcode, CI-Code, Plugin-Code oder einen Container-/Build-Job.
Warum es trotzdem dringend ist: Auf Multi-User-Systemen, Plesk- oder Shared-Hosting-Hosts, CI-Runnern, Entwickler-Workstations und Container-Nodes kann aus einem eingeschränkten Benutzerkonto direkt Root werden.
Bekannte Voraussetzungen: cifs-utils mit cifs.upcall muss vorhanden sein, die cifs.spnego-Request-Key-Regel muss erreichbar sein, der CIFS-Kernelpfad muss vorhanden oder ladbar sein, und unprivileged user/mount namespaces müssen den PoC-Pfad zulassen.
Nicht überall standardmäßig ausnutzbar: Viele Server haben cifs-utils nicht installiert. Fedora, AlmaLinux 10, Rocky 10, CentOS Stream 10 und mehrere SUSE-16-/openSUSE-16-Varianten blockieren den bekannten PoC laut Testtabelle durch SELinux oder AppArmor in der Standardkonfiguration. Das ist aber keine Kernel-Entwarnung.
Saubere Lösung: Vendor-Kernel mit dem Upstream-Fix installieren, danach rebooten oder einen passenden Livepatch nachweisen. AlmaLinux 8/9/10 hat die Fix-Kernel seit 02.06.2026 in Production-Repositories. Debian führt fixe Security-Kernel. CloudLinux nennt feste Kernelstände für CL7h/CL8 und AlmaLinux-basierte Zielstände für CL9/CL10.
Zwischenlösung: Wenn CIFS/SMB nicht gebraucht wird: cifs-utils entfernen, cifs blockieren oder die cifs.spnego-Request-Key-Regel neutralisieren. Alternativ unprivileged user namespaces deaktivieren. Jede dieser Maßnahmen kann produktive Workloads brechen.
Nicht machen: Den öffentlichen PoC nicht auf Produktivsystemen starten. Er schreibt unter anderem eine sudoers-Regel und ist kein harmloser Scanner.

Was ist CIFSwitch?

CIFSwitch ist eine Lücke im Übergang zwischen Kernel und Userspace. Der Kernel-CIFS-Client nutzt für Kerberos/SPNEGO-Authentifizierung nicht alles selbst im Kernel, sondern ruft über den Linux-Keyring-Mechanismus einen Userspace-Helfer aus cifs-utils auf. Dieser Helfer heißt typischerweise cifs.upcall und läuft über /sbin/request-key mit Root-Rechten.

Der normale Ablauf sieht vereinfacht so aus:

Der Kernel-CIFS-Client braucht für einen SMB/CIFS-Mount ein Kerberos-/SPNEGO-Token.
Der Kernel baut eine cifs.spnego-Beschreibung aus echten Kernel-Daten, zum Beispiel Server, UID, Credential-UID, PID und Namespace-Ziel.
Der Kernel ruft request_key() für den Key-Typ cifs.spnego auf.
/sbin/request-key liest die passende Regel, etwa create cifs.spnego * * /usr/sbin/cifs.upcall %k.
cifs.upcall verarbeitet die Beschreibung, sucht Credentials und gibt das SPNEGO-Material an den Kernel zurück.

Der Fehler: Vor dem Upstream-Fix hat der Kernel nicht geprüft, ob eine cifs.spnego-Beschreibung wirklich vom Kernel-CIFS-Code kommt. Ein normaler lokaler Prozess konnte selbst request_key("cifs.spnego", "...") mit einer gefälschten Beschreibung auslösen. Weil der Key-Typ passt, startet trotzdem der Root-Helfer cifs.upcall.

Damit wird eine eigentlich interne Kernelbeschreibung zu einem Angreifer-Eingabefeld. Genau das ist die Lücke.

Wie funktioniert der Angriff?

Der Angriff ist kein normaler CIFS-Mount und keine Remote-Lücke in einem SMB-Server. Er missbraucht die Vertrauensgrenze zwischen Kernel-Keyring, request-key, cifs.upcall, Namespaces und NSS.

Die gefälschte cifs.spnego-Beschreibung enthält Felder wie pid, uid, creduid und upcall_target. cifs.upcall behandelt diese Felder so, als seien sie vom Kernel erzeugt worden. Beim Wert upcall_target=app kann der Helper in die Namespaces des angegebenen Prozesses wechseln. Genau dort wird es gefährlich.

Der öffentliche PoC baut dafür eine eigene User- und Mount-Namespace-Umgebung. In dieser Umgebung liegen eine kontrollierte nsswitch.conf und ein eigenes libnss_*.so.2-Modul. Wenn cifs.upcall als Root in diese Umgebung wechselt und anschließend vor dem finalen Rechteabwurf einen Account-Lookup über NSS macht, kann das manipulierte NSS-Modul als Root-Code geladen werden.

Der bekannte PoC nutzt das, um eine Datei unter /etc/sudoers.d/ zu schreiben und dem lokalen Benutzer NOPASSWD: ALL zu geben. Danach reicht sudo, um eine Root-Shell zu bekommen.

Aus Betriebssicht sind dabei vier Punkte wichtig:

Der Angreifer braucht lokale Code-Ausführung, aber keine Root-Rechte.
Ein installiertes cifs-utils ist für den bekannten PoC zentral.
User- und Mount-Namespaces sind nicht nur ein Container-Detail, sondern Teil des Exploit-Pfads.
SELinux oder AppArmor können den veröffentlichten PoC blockieren, ersetzen aber keinen Kernel-Fix.

Der Kernel-Fix ist klein, aber wirksam: Der Key-Typ cifs.spnego bekommt eine .vet_description-Prüfung. Der Kernel akzeptiert solche Beschreibungen nur noch, wenn CIFS selbst sie mit seinen internen spnego_cred anfordert. Userspace kann sich damit nicht mehr als Kernel-CIFS ausgeben.

Was braucht ein Angreifer?

CIFSwitch ist keine unauthentifizierte Remote-Code-Execution. Ein offener Webport oder ein erreichbarer SMB-Port reicht allein nicht. Der Angreifer braucht eine Möglichkeit, Code lokal auf dem System auszuführen.

In echten Umgebungen ist das aber kein exotischer Sonderfall:

kompromittierte WordPress-, TYPO3-, Shopware-, Laravel- oder Node.js-Anwendung
Shell-Zugang eines Kunden, Entwicklers oder Dienstleisters
Plesk- oder Shared-Hosting-Server mit mehreren Systembenutzern
GitLab Runner, GitHub Actions Runner, Jenkins-Agent oder Build-Host
Docker-, Kubernetes- oder LXC-Workload mit nicht vollständig vertrauenswürdigem Code
Entwickler-Workstation mit vielen lokalen Tools und Paketquellen
ein normaler unprivilegierter Linux-Benutzer auf einem Multi-User-System

Auf einem kleinen Single-Tenant-Server ohne fremde Shells und ohne fremde Workloads ist das Risiko niedriger. Aber auch dort kann eine kompromittierte Webanwendung lokaler Code sein. Deshalb würde ich CIFSwitch nicht ignorieren, sondern sauber prüfen.

Wer ist betroffen?

Betroffen sind Linux-Systeme, auf denen der verwundbare Kernel-CIFS-Code vorhanden ist und der bekannte Userspace-Pfad erreichbar ist. Die grobe Formel lautet:

verwundbarer Kernel + cifs-utils/cifs.upcall + cifs.spnego-Regel + unprivileged namespaces = kritisch

Eine nackte Kernel-Hauptversion reicht nicht. Distributionen backporten Kernel-Fixes, und LSM-Policies unterscheiden sich stark.

Umgebung	Einschätzung	Worauf prüfen
Debian 11/12/13	Laut Forscher-Tabelle mit installiertem `cifs-utils` unter Standardpolicy ausnutzbar. Debian führt CVE-2026-46243 inzwischen im Security Tracker mit fixen Security-Kernelständen.	`cifs-utils`, `cifs.spnego`-Regel, User-Namespaces und Debian-Kernel-Security-Stand prüfen. Bullseye/Bookworm/Trixie brauchen die Security-Kernel oder neuere Paketstände, nicht nur die alte Base-Version.
Ubuntu 18.04/20.04/22.04	Laut Testtabelle mit installiertem `cifs-utils` ausnutzbar. `cifs-utils` ist in den getesteten Profilen nicht automatisch installiert.	Kernel-Flavour, `cifs-utils`, AppArmor/Userns-Policy und Ubuntu-USN/CVE-Seiten prüfen.
Ubuntu 24.04	Mit installiertem `cifs-utils` ist der direkte `unshare`-Weg durch AppArmor-Userns-Policy erschwert, laut Test aber über ein passendes AppArmor-Profil ausnutzbar.	Nicht nur `cifs-utils` prüfen, sondern AppArmor-Userns-Status und tatsächlich erlaubte Profile.
Ubuntu 26.04	Der bekannte PoC ist laut Testtabelle durch AppArmor-Userns-Policy blockiert, wird nach gelockerter Policy aber ausnutzbar.	Als entschärft, nicht als sauber gefixt behandeln. Kernel-Fix trotzdem nachziehen.
Linux Mint 21.3/22.3 Cinnamon	Laut Testtabelle stock-exploitable, weil `cifs-utils` vorhanden ist und AppArmor den PoC nicht blockiert.	Schnell priorisieren: `cifs-utils`, Userns, Kernel-Fix oder Mitigation.
Fedora 40 bis 44	`cifs-utils` ist laut Testtabelle vorhanden, der bekannte PoC wird aber durch SELinux enforcing blockiert. Nach `setenforce 0` ausnutzbar.	SELinux enforcing beibehalten, Kernel-Updates einspielen. Fedora 44 hatte zum geprüften Stand neue Kernelupdates im 7.0.x-Zweig; genaue Fixversion über Bodhi/DNF prüfen.
RHEL / CentOS Stream 9	CentOS Stream 9 GNOME war laut Testtabelle stock-exploitable; andere Desktops sind mit installiertem `cifs-utils` ausnutzbar. Für RHEL selbst braucht es den Red-Hat-Advisory-Stand.	Red-Hat-Errata, `cifs-utils`, SELinux-Status und Userns-Policy prüfen. Ohne eigenes Red-Hat-Advisory keine Alma-Version blind übertragen.
CentOS Stream 10	Der bekannte PoC wird laut Testtabelle durch SELinux enforcing blockiert; nach `setenforce 0` ausnutzbar.	SELinux nicht lockern, Kernel-Fix nach Vendor-Stand prüfen.
AlmaLinux 8	AlmaLinux stuft AL8 als betroffen ein, wenn `cifs-utils` installiert ist.	Production-Fix seit 02.06.2026: `kernel-4.18.0-553.126.2.el8_10` oder neuer, danach Reboot.
AlmaLinux 9	AlmaLinux 9.7 Workstation und Azure-Image-Rezept waren laut Testtabelle stock-exploitable.	Production-Fix seit 02.06.2026: `kernel-5.14.0-687.5.4.el9_8` oder neuer, danach Reboot.
AlmaLinux 10 / Kitten 10	AlmaLinux 10 ist grundsätzlich betroffen, der öffentliche PoC wird auf Stock-Systemen durch SELinux enforcing blockiert. Bei SELinux permissive/disabled als ausnutzbar behandeln.	Production-Fix seit 02.06.2026: `kernel-6.12.0-211.7.4.el10_2` oder neuer. Kitten 10 bekommt den Fix über den regulären Kernelpfad.
Rocky Linux 8/9	Rocky 9 Workstation war laut Testtabelle stock-exploitable; Rocky 8 GenericCloud ist mit installiertem `cifs-utils` ausnutzbar.	Rocky-Errata/Security-Repo prüfen. Bis ein eindeutiger Fixstand vorhanden ist: Mitigation beibehalten, besonders auf Workstations und Cloud-Images mit `cifs-utils`.
Rocky Linux 10	Der bekannte PoC wird laut Testtabelle durch SELinux enforcing blockiert; nach `setenforce 0` ausnutzbar.	SELinux enforcing nicht als endgültigen Fix dokumentieren, Kernelupdate nachziehen.
CloudLinux 7h/8/9/10	CloudLinux stuft CL7h, CL8, CL9 und CL10 als betroffen ein, wenn `cifs-utils` installiert ist und User-Namespaces erlaubt sind. Typische Shared-Hosting-Installationen haben `cifs-utils` laut CloudLinux oft nicht.	CL7h/CL8 haben eigene Fix-Kernel `kernel-4.18.0-553.126.2.lve...`; CL9/CL10 folgen den AlmaLinux-Zielständen. KernelCare-Main-Feed-Fixes sind für CL7h, CL8 und CL9 verfügbar; CL10 und CloudLinux for Ubuntu 22.04 lagen im Testing-Feed.
Oracle Linux 8/9	Laut Testtabelle mit installiertem `cifs-utils` ausnutzbar.	RHCK/UEK getrennt prüfen: `uname -r`, `rpm -q kernel kernel-uek cifs-utils`, Oracle-ELSA/Ksplice-Status.
Oracle Linux 10	Der bekannte PoC wird laut Testtabelle durch SELinux enforcing blockiert; nach `setenforce 0` ausnutzbar.	SELinux-Status und Oracle-Errata prüfen.
Amazon Linux 2023	Laut Testtabelle mit installiertem `cifs-utils` und SELinux permissive ausnutzbar.	AWS-ALAS/Bulletins prüfen, `cifs-utils` und SELinux/Userns-Status kontrollieren.
Amazon Linux 2	Laut Testtabelle durch ältere `cifs-utils`-Version im bekannten PoC-Pfad nicht betroffen.	Trotzdem Kernel- und AWS-Status prüfen, nicht auf andere Amazon-Linux-Generationen übertragen.
SUSE / openSUSE	SLES 15 SP7/SAP 15 SP7 und SAP 16 waren laut Testtabelle stock-exploitable. openSUSE Leap 15.6 ist mit installiertem `cifs-utils` ausnutzbar. Tumbleweed und Leap 16 werden im bekannten PoC durch SELinux enforcing blockiert.	Produktgenaue SUSE-CVE-/Advisory-Seite prüfen, sobald CVE-ID/Vendor-Fixstand sichtbar ist.
Proxmox VE	Proxmox ist Debian-basiert. LXC-Container teilen den Host-Kernel; KVM-Gäste haben eigene Kernel. Ein dediziertes Proxmox-CIFSwitch-Advisory war zum geprüften Stand nicht sichtbar.	Host-Kernel, `cifs-utils`, `cifs`-Modul und Userns prüfen. Wenn `cifs-utils` auf dem Host installiert ist, bis zum Proxmox/Debian-Fix mitigieren oder den passenden Kernel-Fix nachweisen.
Plesk-Server	Plesk ist nicht die Lücke. Relevant ist der darunterliegende OS-Kernel und ob `cifs-utils` installiert ist.	Auf Hosting-Hosts zuerst prüfen, ob `cifs-utils` überhaupt gebraucht wird. Wenn nicht: entfernen oder `cifs.spnego` neutralisieren.
Docker, Kubernetes, CI-Runner	Besonders relevant, wenn fremder Code läuft und User-Namespaces oder flexible Build-Umgebungen erlaubt sind.	Node-Kernel patchen, `cifs-utils` auf Hosts entfernen, rootless Workflows und Userns-Policy bewusst prüfen.
Single-Tenant-Server ohne fremde Shells	Geringeres Risiko, aber eine kompromittierte Anwendung kann lokaler Code sein.	Normal priorisiert patchen, bei installiertem `cifs-utils` nicht bis zum nächsten Quartalsfenster warten.

Patchstände nach Distribution

Diese Tabelle ist eine Momentaufnahme. Weil die CVE-ID noch fehlt, sind mehrere Vendor-Datenbanken schwerer abfragbar als bei normalen Kernel-CVEs.

Distribution / Plattform	Stand / Quelle
Upstream Linux	CVE-2026-46243. Fix in Mainline-Commit `3da1fdf4efbc` mit dem Titel `smb: client: reject userspace cifs.spnego descriptions`. Der Fix ergänzt eine `.vet_description`-Prüfung im `cifs.spnego`-Key-Typ.
AlmaLinux 8	Production-Repo seit 02.06.2026: `kernel-4.18.0-553.126.2.el8_10` oder neuer.
AlmaLinux 9	Production-Repo seit 02.06.2026: `kernel-5.14.0-687.5.4.el9_8` oder neuer.
AlmaLinux 10	Production-Repo seit 02.06.2026: `kernel-6.12.0-211.7.4.el10_2` oder neuer.
AlmaLinux Kitten 10	Kein eigener Emergency-Build laut AlmaLinux; Fix soll mit dem nächsten regulären Kernelupdate kommen.
CloudLinux 7h / 8	Fix-Kernel laut CloudLinux: CL7h ab `kernel-4.18.0-553.126.2.lve.el7h`, CL8 ab `kernel-4.18.0-553.126.2.lve.el8`.
CloudLinux 9	Nutzt den AlmaLinux-9-Kernelpfad; Zielstand `kernel-5.14.0-687.5.4.el9_8` oder neuer. KernelCare-Main-Feed-Fix verfügbar.
CloudLinux 10	Nutzt den AlmaLinux-10-Kernelpfad; Zielstand `kernel-6.12.0-211.7.4.el10_2` oder neuer. KernelCare-Fix war zum CloudLinux-Update im Testing-Feed.
CloudLinux for Ubuntu 22.04	KernelCare-Fix laut CloudLinux im Testing-Feed, nicht als regulären Ubuntu-USN-Fix behandeln.
Debian 11/12/13	Debian Security Tracker: Bullseye Security ab `5.10.257-1`, Bookworm Security ab `6.1.174-1`, Trixie ab `6.12.90-2`, Forky/Sid ab `7.0.10-1` gefixt; die alten Base-Kernel von Bullseye, Bookworm und Trixie bleiben im Tracker als vulnerable markiert.
Ubuntu 18.04 bis 26.04	Kein eindeutiger Ubuntu-CIFSwitch-USN-Fixstand zum geprüften Stand sichtbar. Kernel-Flavour, Livepatch und AppArmor-Userns-Policy getrennt prüfen.
Fedora	Der bekannte PoC ist bei SELinux enforcing blockiert. Fedora-44-Kernel im 7.0.x-Zweig lagen bereits nach dem Upstream-Fix-Zeitpunkt; genaue Fixversion per `dnf update 'kernel*'`, Bodhi und Changelog prüfen.
RHEL / CentOS Stream / Rocky	Kein pauschaler öffentlicher Fixstand ohne Red-Hat-/Rocky-Erratum. Die AlmaLinux-Production-Versionen sind ein Hinweis auf den EL-Backport-Kontext, ersetzen aber nicht den jeweiligen Vendor-Stand.
Oracle Linux	Kein pauschaler Stand ohne Oracle-Erratum. RHCK, UEK, Ksplice und KernelCare getrennt prüfen.
Amazon Linux	Kein eindeutiger ALAS-Fixstand zum geprüften Stand sichtbar. Amazon Linux 2023 war laut Testtabelle mit passenden Voraussetzungen ausnutzbar; Amazon Linux 2 war durch ältere `cifs-utils` im bekannten PoC-Pfad nicht betroffen.
SUSE / openSUSE	Kein eindeutiger produktweiter SUSE-Fixstand zum geprüften Stand sichtbar. Weil mehrere SLES-/openSUSE-Varianten in der Testtabelle auftauchen, sollten SUSE-Produktstatus und Kernel-Flavour getrennt geprüft werden.
Proxmox VE	Kein dediziertes Proxmox-CIFSwitch-Advisory zum geprüften Stand sichtbar. Bis dahin Debian-/Proxmox-Kernel-Changelog prüfen und Host-Mitigation anwenden, wenn `cifs-utils` auf dem PVE-Host vorhanden ist.

Bei Distributionen ohne klare Tabelle gilt: Nicht aus einem fremden Vendor-Artikel abschreiben. Entscheidend ist, ob der eigene Vendor den Upstream-Fix 3da1fdf4efbc oder einen äquivalenten Backport für genau den laufenden Kernel ausweist.

Was ist nicht betroffen oder deutlich entschärft?

Nicht betroffen oder praktisch entschärft sind Systeme, bei denen mindestens ein notwendiger Teil der Kette fehlt oder der Kernel gefixt ist. Das muss man belegen.

Der laufende Kernel enthält den CIFSwitch-Fix für cifs.spnego-Descriptions.
Ein Livepatch ist aktiv und nennt entweder die CVE-ID, sobald sie vergeben ist, oder die Upstream-Beschreibung smb: client: reject userspace cifs.spnego descriptions.
cifs-utils ist nicht installiert und cifs.upcall existiert nicht.
Die cifs.spnego-Request-Key-Regel ist nicht vorhanden oder bewusst auf einen neutralisierenden Handler gesetzt.
Unprivileged user namespaces sind wirksam deaktiviert.
Der CIFS-Kernelpfad ist weder eingebaut noch als Modul ladbar.
SELinux oder AppArmor blockieren den bekannten PoC. Das ist eine Entschärfung, aber kein Kernel-Fix.
Amazon Linux 2 und ältere Kali-Stände waren laut Testtabelle durch zu alte cifs-utils-Versionen im bekannten PoC-Pfad nicht betroffen. Das darf nicht auf neuere Releases übertragen werden.

Wichtig: “cifs-utils ist nicht Teil der Minimalinstallation” ist keine Hostprüfung. Tools, Desktop-Pakete, Backup-Software, Fileserver-Clients oder Admins können das Paket später installiert haben. Prüfen ist schneller als raten.

Schnelle Prüfung auf einem Host

Zuerst brauchst du den laufenden Kernel:

uname -r
uname -a

Dann prüfst du, ob cifs-utils und cifs.upcall vorhanden sind.

Debian, Ubuntu und Proxmox:

dpkg -l cifs-utils 2>/dev/null | awk '/^ii/ {print $2, $3}'
command -v cifs.upcall || true

RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahe Systeme:

rpm -q cifs-utils 2>/dev/null
command -v cifs.upcall || true

SUSE und openSUSE:

rpm -q cifs-utils 2>/dev/null
command -v cifs.upcall || true

Danach geht es um die Request-Key-Regel:

grep -R 'cifs\.spnego' /etc/request-key.conf /etc/request-key.d 2>/dev/null || echo "keine cifs.spnego-Regel gefunden"

Typisch verwundbar ist eine Regel, die cifs.spnego auf cifs.upcall zeigt, zum Beispiel:

create cifs.spnego * * /usr/sbin/cifs.upcall %k

Prüfen, ob das CIFS-Modul geladen oder ladbar ist:

grep -E '^cifs ' /proc/modules || echo "cifs aktuell nicht geladen"
modprobe -n -v cifs 2>/dev/null || true
find "/lib/modules/$(uname -r)" -type f -name 'cifs.ko*' -print 2>/dev/null

Falls die Kernel-Konfiguration verfügbar ist:

grep CONFIG_CIFS "/boot/config-$(uname -r)" 2>/dev/null || true
zgrep CONFIG_CIFS /proc/config.gz 2>/dev/null || true

User-Namespace-Status:

sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null
sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null

LSM-Status:

getenforce 2>/dev/null || true
aa-status 2>/dev/null | sed -n '1,20p' || true

Ein kompakter erster Exposure-Check:

echo "Kernel: $(uname -r)"

if command -v cifs.upcall >/dev/null; then
  echo "WARNUNG: cifs.upcall vorhanden: $(command -v cifs.upcall)"
else
  echo "OK: cifs.upcall nicht im PATH"
fi

grep -R 'cifs\.spnego.*cifs\.upcall' /etc/request-key.conf /etc/request-key.d 2>/dev/null \
  && echo "WARNUNG: cifs.spnego startet cifs.upcall" \
  || echo "OK/INFO: keine aktive cifs.upcall-Regel gefunden"

grep -E '^cifs ' /proc/modules \
  && echo "INFO: cifs-Modul ist geladen" \
  || echo "INFO: cifs-Modul ist aktuell nicht geladen"

sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null || true

Das ist kein vollständiger Vulnerability-Scanner. Es beantwortet aber die Fragen, die du für die erste Priorisierung brauchst:

Läuft ein Kernel, der den Fix nachweislich enthält?
Ist cifs-utils auf dem Host vorhanden?
Startet cifs.spnego noch cifs.upcall?
Sind unprivileged user namespaces erlaubt?
Blockiert SELinux/AppArmor den bekannten Weg oder wurde diese Schutzschicht gelockert?

Updates einspielen

Die saubere Lösung ist ein Kernel-Update aus den Repositories deiner Distribution. Danach muss der Host entweder rebooten oder du musst einen passenden Livepatch nachweisen.

Debian, Ubuntu und Proxmox:

sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r

Auf Proxmox zusätzlich:

pveversion -v
dpkg -l 'proxmox-kernel*' 'pve-kernel*' 'linux-image*' cifs-utils 2>/dev/null | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null
proxmox-boot-tool status 2>/dev/null || true

RHEL, AlmaLinux, Rocky Linux, CloudLinux, Oracle Linux und Fedora:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann noch yum statt dnf relevant sein.

SUSE und openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot
uname -r

Bei AlmaLinux brauchst du seit der Production-Promotion am 02.06.2026 kein Testing-Repository mehr für die genannten Fix-Kernel. Normales dnf upgrade aus den Production-Repositories reicht, danach muss der Host in den neuen Kernel booten. Vergleiche anschließend gegen die Zielstände:

AlmaLinux 8:  kernel-4.18.0-553.126.2.el8_10 oder neuer
AlmaLinux 9:  kernel-5.14.0-687.5.4.el9_8 oder neuer
AlmaLinux 10: kernel-6.12.0-211.7.4.el10_2 oder neuer

Bei KernelCare zählt nicht uname -r, sondern der Patch-Nachweis:

kcarectl --patch-info 2>/dev/null | grep -Ei 'CVE-2026-|cifs|spnego|reject userspace cifs.spnego' || true
kcarectl --uname 2>/dev/null || true

CloudLinux nennt für CIFSwitch neben CVE-2026-46243 weiterhin die Upstream-Beschreibung als Erkennungsanker:

smb: client: reject userspace cifs.spnego descriptions

Wenn die Patch-Metadaten die CVE-ID noch nicht anzeigen, bleibt die Upstream-Beschreibung der praktische Suchanker.

Temporäre Mitigation

Wenn noch kein gefixter Kernel verfügbar ist oder ein sofortiger Reboot nicht geht, gibt es mehrere Zwischenlösungen. Wähle nur eine Maßnahme, deren Nebenwirkungen du akzeptierst.

Option 1: cifs-utils entfernen

Wenn der Host keine SMB/CIFS-Shares mountet, ist das oft die sauberste Zwischenlösung:

Debian, Ubuntu und Proxmox:

sudo apt remove cifs-utils

RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahe Systeme:

sudo dnf remove cifs-utils

SUSE und openSUSE:

sudo zypper remove cifs-utils

Das bricht CIFS-Mounts, die mount.cifs, Kerberos/SPNEGO oder cifs.upcall brauchen. Vorher prüfen:

findmnt -t cifs
grep -R ' cifs ' /etc/fstab /etc/systemd/system 2>/dev/null || true

Option 2: cifs.spnego-Request-Key-Regel neutralisieren

Wenn Kerberos-authentifizierte CIFS-Mounts nicht gebraucht werden, kannst du die Upcall-Regel überschreiben:

printf '%s\n' 'create cifs.spnego * * /bin/false' | sudo tee /etc/request-key.d/cifs.spnego.conf

Prüfen:

grep -R 'cifs\.spnego' /etc/request-key.conf /etc/request-key.d 2>/dev/null

Das lässt cifs-utils installiert, bricht aber CIFS/SPNEGO-Authentifizierung. Für Umgebungen mit Kerberos-SMB ist das keine harmlose Änderung.

Zurücknehmen nach gefixtem Kernel:

sudo rm -f /etc/request-key.d/cifs.spnego.conf

Falls dein Vendor statt /bin/false eine keyctl negate-Regel empfiehlt, nimm die Vendor-Regel. Wichtig ist nicht die Kosmetik, sondern dass die Angreifer-Anfrage nicht mehr cifs.upcall als Root startet.

Option 3: CIFS-Kernelmodul blockieren

Wenn CIFS auf dem Host nicht gebraucht wird:

printf '%s\n' 'install cifs /bin/false' | sudo tee /etc/modprobe.d/cifswitch.conf
sudo rmmod cifs 2>/dev/null || true
modprobe -n -v cifs

Wenn das Modul bereits genutzt wird, schlägt rmmod fehl. Dann hängen produktive CIFS-Mounts daran, oder der Pfad ist eingebaut. Außerdem muss die Regel in das initramfs, wenn sie über Reboots hinweg früh greifen soll.

Debian und Ubuntu:

sudo update-initramfs -u -k all

RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahe Systeme:

sudo dracut -f

Zurücknehmen nach gefixtem Kernel:

sudo rm -f /etc/modprobe.d/cifswitch.conf

if command -v update-initramfs >/dev/null; then
  sudo update-initramfs -u -k all
fi

if command -v dracut >/dev/null; then
  sudo dracut -f
fi

Option 4: unprivileged user namespaces deaktivieren

Das blockiert den bekannten PoC-Pfad, kann aber moderne Workloads treffen.

Debian/Ubuntu-typisch:

printf '%s\n' 'kernel.unprivileged_userns_clone=0' | sudo tee /etc/sysctl.d/99-cifswitch-userns.conf
sudo sysctl --system

EL-typisch:

printf '%s\n' 'user.max_user_namespaces=0' | sudo tee /etc/sysctl.d/99-cifswitch-userns.conf
sudo sysctl --system

Nebenwirkungen sind real: rootless Podman, rootless Docker, Build-Sandboxes, Flatpak, Bubblewrap, Browser-Sandboxing, manche CI-Jobs und Entwickler-Workflows können kaputtgehen. Auf einem klassischen Webhosting-Server kann das trotzdem die bessere Übergangslösung sein als ein offener Root-LPE-Pfad.

Was beim Patchen gern übersehen wird

Der erste Fehler ist ein installiertes Kernelpaket ohne Reboot. Der Fix liegt dann auf der Platte, aber der alte Kernel läuft weiter.

uname -r

Der zweite Fehler ist ein blinder Blick auf cifs-utils. Fehlt das Paket, ist der bekannte PoC-Pfad nicht erreichbar. Der Kernel-Bug ist damit aber nicht sauber behoben. Bei der nächsten Paketinstallation oder geänderten Rolle kann die Exposition wieder auftauchen.

Der dritte Fehler ist SELinux oder AppArmor als endgültigen Patch zu behandeln. Bei Fedora, AlmaLinux 10, Rocky 10 und mehreren neueren SUSE/openSUSE-Varianten blockiert die Standardpolicy den bekannten PoC. Sobald jemand SELinux auf permissive stellt, AppArmor-Userns-Restriktionen lockert oder ein anderer Exploit-Pfad auftaucht, kann diese Annahme kippen.

Der vierte Fehler ist “Container aktualisiert, Host vergessen”. Ein Docker-, Kubernetes- oder LXC-Container bringt keinen eigenen Kernel mit. CIFSwitch ist ein Host-Kernel-Thema. KVM-Gäste sind anders: Sie haben eigene Guest-Kernel und müssen separat bewertet werden.

Der fünfte Fehler ist eine CIFS-Mitigation auf Hosts mit echten SMB-Mounts. cifs-utils, cifs.upcall und die cifs.spnego-Regel sind nicht überflüssig, wenn Kerberos-authentifizierte SMB-Shares genutzt werden. Dann ist ein Kernel-Fix mit Reboot oder Livepatch meist der bessere Weg.

Der sechste Fehler ist fehlende Reihenfolge in Clustern. Kubernetes-Nodes werden drainiert, Proxmox-HA-Workloads migriert oder bewusst gestoppt, CI-Runner aus Queues genommen. Ein Kernelupdate ist kein normales Userland-Update. Der Reboot ist Teil des Fixes.

Einordnung für Plesk, Proxmox und Hosting

Für Plesk- und Shared-Hosting-Server ist CIFSwitch vor allem dann relevant, wenn mehrere Benutzer oder Kunden-Code auf demselben Host laufen. Genau dort sind lokale Rechteausweitungen wertvoll: Ein kompromittierter Webspace, ein Cronjob oder ein SSH-Benutzer kann zum Host-Root-Problem werden.

Die gute Nachricht: Auf vielen klassischen Hosting-Servern wird cifs-utils nicht gebraucht. Dann ist das Entfernen des Pakets oder das Neutralisieren der cifs.spnego-Regel eine pragmatische Zwischenlösung. Das sollte aber dokumentiert werden, sonst installiert es später jemand für einen SMB-Mount wieder und niemand denkt an CIFSwitch.

Bei Proxmox ist die Trennung wichtig:

Proxmox-Host: Der Host-Kernel entscheidet. Wenn auf dem Host cifs-utils installiert ist, etwa für SMB-Backups oder manuelle Mounts, muss der Host geprüft werden.
LXC-Container: LXC teilt den Host-Kernel. Ein lokaler Exploit im Container kann je nach Policy den Host-Kernelpfad erreichen. Container-Images zu patchen ersetzt den Host-Fix nicht.
KVM-VMs: KVM-Gäste haben eigene Kernel. Der Gast muss separat geprüft werden. Der Host ist dadurch nicht automatisch gefixt.
Cluster: Reboots brauchen Planung. Dokumentiere pro Node, welcher Kernel wirklich läuft und ob eine temporäre CIFS-Mitigation aktiv ist.

Für CI-Runner und Build-Hosts ist die Priorität hoch, wenn fremder oder halb-vertrauenswürdiger Code gebaut wird. Gerade dort sind unshare, User-Namespaces, rootless Container und viele lokale Tools normal. Wenn zusätzlich cifs-utils installiert ist, ist das keine theoretische Lücke.

Wie wir damit umgehen würden

Bei produktiven Systemen würden wir nicht mit dem PoC anfangen. Der erste Schritt ist Inventar:

Welche Hosts erlauben lokale Benutzer, Kundenworkloads, CI-Jobs oder Container?
Wo ist cifs-utils installiert?
Wo ist cifs.spnego auf cifs.upcall verdrahtet?
Wo sind unprivileged user namespaces erlaubt?
Welche Kernel-Fixes oder Livepatches bietet der jeweilige Vendor für genau diese Systeme?

Danach wird priorisiert:

Multi-User-, Hosting-, CI- und Container-Hosts zuerst.
Systeme mit cifs-utils und erlaubten User-Namespaces zuerst.
Systeme mit SELinux permissive/disabled oder gelockertem AppArmor besonders prüfen.
Single-Tenant-Systeme mit normalem Wartungsfenster, aber nicht vergessen.

Wenn kein Kernel-Fix verfügbar ist, ist die pragmatische Übergangslösung meistens: cifs-utils entfernen, wenn es nicht gebraucht wird. Wenn SMB/CIFS gebraucht wird, hängt die Entscheidung an der konkreten Nutzung: Kerberos-CIFS-Mounts brauchen andere Maßnahmen als ein Server, auf dem das Paket nur zufällig installiert wurde.

Update-Log

2026-05-29 17:30 Uhr CEST: Erstfassung mit Stand aus oss-security, Upstream-Fix, AlmaLinux-Testing-Kerneln, CloudLinux/KernelCare-Status und veröffentlichter Distro-Testtabelle.
2026-06-01: CVE-2026-46243 ergänzt. CloudLinux aktualisierte die Advisory und nennt den CVE-Anker für Patch- und Livepatch-Prüfungen.
2026-06-02: AlmaLinux-Fixkernel aus dem Testing-Repo in Production-Repositories übernommen; Debian-Tracker mit fixen Security-Kerneln und CloudLinux-Zielstände für CL7h/CL8/CL9/CL10 ergänzt.

Kurzfassung

Was ist CIFSwitch?

Wie funktioniert der Angriff?

Was braucht ein Angreifer?

Wer ist betroffen?

Patchstände nach Distribution

Was ist nicht betroffen oder deutlich entschärft?

Schnelle Prüfung auf einem Host

Updates einspielen

Temporäre Mitigation

Option 1: cifs-utils entfernen

Option 2: cifs.spnego-Request-Key-Regel neutralisieren

Option 3: CIFS-Kernelmodul blockieren

Option 4: unprivileged user namespaces deaktivieren

Was beim Patchen gern übersehen wird

Einordnung für Plesk, Proxmox und Hosting

Wie wir damit umgehen würden

Update-Log

Quellen