Just released an open-source bash checker for CIFSwitch (CVE-2026-46243) — the 19-year-old Linux kernel LPE disclosed last week that lets any unprivileged local user get root by abusing the CIFS/SPNEGO upcall path.
The script runs on bare-metal, VMs, and inside containers, and is CI/CD-friendly with JSON output and clean exit codes.
It checks:
✅ Kernel version against patched thresholds (6.18.22 / 6.19.12 / 7.0+)
✅ cifs-utils presence and exploitable version
✅ CIFS kernel module load state and blacklist status
✅ Unprivileged user namespace sysctl (the pivot point for the exploit)
✅ Active request-key cifs.spnego rules
✅ SELinux / AppArmor enforcement
✅ Container capabilities (CAP_SYS_ADMIN)
✅ Kernel symbol verification for the fix commit
Outputs human-readable or JSON for SIEM ingestion. Exit 0 = safe, exit 1 = action needed — drop it straight into a pipeline.
CIFSwitch is the fourth Linux LPE in under six weeks (after Copy Fail, Dirty Frag, and Fragnesia). If you're running multi-tenant Linux, CI runners, or container build farms, now is a good time to audit.
liamromanis101
/
cifswitch-check
Detection script for CIFSwitch - CVE-2026-46243
cifswitch-check
A shell script to check whether a Linux system is exposed to CIFSwitch (CVE-2026-46243) — a local privilege escalation vulnerability in the Linux kernel's CIFS/SMB client that has been present since 2007.
Runs on bare-metal hosts, VMs, and inside containers. Designed to drop straight into CI/CD pipelines.
Background
CIFSwitch was disclosed on 28 May 2026 by security researcher Asim Manizada. The flaw chains a missing input validation in the kernel's cifs.spnego key type with the rootful cifs.upcall helper from cifs-utils.
An unprivileged local user can call request_key() with a forged key description, causing the kernel to invoke cifs.upcall as root with attacker-controlled fields. With upcall_target=app, the helper enters the attacker's mount namespace and performs a getpwuid() lookup before dropping privileges — loading an attacker-controlled NSS module and executing arbitrary code as root.
Prerequisites for exploitation:
- A vulnerable kernel (present since 2007, fixed in 6.18.22 / 6.19.12…
I have also updated the cve_checks.conf in my my K8s-container_escape_audit toolkit to detect this issue.
liamromanis101
/
K8s-container_escape_audit
Look for possible escape vectors from a container
K8s_container-escape-audit
A bash script that runs inside a Docker or Kubernetes container and checks for escape vectors. Built for penetration testers and security teams doing container security assessments.
For authorised security assessments only. Do not run this on systems you don't have explicit written permission to test.
What it does
container_escape_audit.sh v4.0 performs 47 checks plus a config-driven CVE engine, covering: privileged configuration, dangerous capabilities, namespace isolation, filesystem mounts, kernel exposure, Kubernetes misconfigurations, cloud metadata access, kernel hardening posture, and an updateable database of recent kernel CVEs. All checks are strictly read-only — the script makes no changes to the system.
Each finding comes with a structured report entry:
- What it is: the misconfiguration or exposure
- Impact: worst-case if exploited
- Exploitability: difficulty, tooling, real-world precedent
- Recommendation: specific remediation steps
The tool ships as two files that must sit in the same directory:
container_escape_audit.sh # main script
Top comments (1)
sorry I was tired when I finished this and forgot to add the links. They are there now tho.