CVE-2026-46243

CVE-2026-46243 CIFSwitch Keyring Upcall Mitigation

CIFSwitch is a confused-deputy local privilege escalation: unprivileged code calls request_key("cifs.spnego", <forged description>, ...) and the kernel runs the root helper cifs.upcall on attacker-controlled fields. This demo does not ship the root exploit; it shows the keyring-upcall syscalls reachable without agentsh, then denied for wrapped processes while an ordinary IPv4 socket keeps working.

CIFSwitch write-up → Install agentsh → Canyon Road →
The policy

One scoped syscall block.

config.yml - sandbox.seccomp.syscalls
# CIFSwitch forges request_key("cifs.spnego", ...) to drive cifs.upcall as root. sandbox: seccomp: enabled: true mode: enforce syscalls: default_action: allow block: - request_key # CIFSwitch trigger: forge cifs.spnego -> root upcall - add_key # sibling keyring syscall, same upcall surface on_block: errno
default_action: allow keeps normal syscalls working; only the keyring-upcall syscalls return EPERM. CIFSwitch reaches the vulnerable root helper through request_key, so blocking that syscall — regardless of key type or description — closes the agentsh-supervised entry point.
Why this boundary matters

The trigger is the syscall, not a binary

The dangerous action in CIFSwitch is not running keyctl or mounting an SMB share. A malicious agent can issue request_key directly from Python, Go, Rust, C, or a prebuilt binary, so the real prevention point is the syscall itself. agentsh compiles syscalls.block to a seccomp-BPF filter installed on the wrapped process, so the call is denied in the kernel before the cifs.spnego upcall machinery is ever reached.

This is intentionally a runtime boundary. The protected run does not need to identify exploit source code or trust the agent to avoid risky commands; it blocks the kernel interface that the confused-deputy path requires and leaves an auditable policy decision behind. The raw-syscall probe proves the block fires below libc.

Before

Bare attack surface — no agentsh

Docker’s default seccomp is disabled so the raw kernel surface is visible. alice can call request_key and add_key — the syscalls the exploit forges its cifs.spnego request through — including through a direct syscall(SYS_request_key, ...) that bypasses libc.

VERDICT: ATTACK SURFACE OPEN
After

Same check under agentsh

agentsh denies request_key and add_key with EPERM while the control socket(AF_INET, ...) stays open. The raw-syscall check proves the block fires at the kernel boundary, not in libc.

VERDICT: BLOCKED — keyring upcall denied
Configuration mitigation

agentsh configuration mitigation

config.yml - sandbox.seccomp (daemon-wide)
# Add the keyring-upcall block to the daemon config — it cannot be # overridden from inside an agent session. sandbox: seccomp: enabled: true mode: enforce syscalls: default_action: allow block: [request_key, add_key] on_block: errno
Current agentsh builds do not ship a built-in mitigation_sets entry for CVE-2026-46243. The daemon-wide block above is the mitigation: it denies the keyring upcall for every supervised process. This bounds the agent, not the kernel — the host still needs the upstream fix (commit 3da1fdf4efbc, which adds a .vet_description check) or host hardening for processes that run outside agentsh.