The Linux Kernel 7.1 EOL has officially arrived. Discover the final updates and learn why you must upgrade to the latest stable LTS releases immediately.
Related Posts:
The post Linux Kernel 7.1 Reaches End of Life appeared first on Daily CyberSecurity.
CVE-2026-80714 (CVSS 9.8) is a Linux kernel IPVS use-after-free with public PoC code enabling root privilege escalation on Debian. Patch now.
Related Posts:
The post CVE-2026-80714 (CVSS 9.8): Linux Root Escalation PoC Out appeared first on Daily CyberSecurity.
CVE-2026-68162, a Linux kernel vulnerability in SCTP (CVSS 7.8), has public PoC code enabling root privilege escalation on Ubuntu 26.04. Patch now.
Related Posts:
The post CVE-2026-68162: Linux Kernel Root Escalation PoC Public appeared first on Daily CyberSecurity.
Developer JPRX launched Darwin-VM to emulate Apple Silicon systems. This QEMU-based tool assists security researchers with XNU kernel debugging and analysis.
Related Posts:
The post Darwin-VM Enables Apple Silicon Security Research appeared first on Daily CyberSecurity.
A public PoC for CVE-2026-53361 turns an AF_UNIX kernel race into a local container escape on Linux. Details and exploit code are now disclosed.
Related Posts:
The post CVE-2026-53361: PoC Exploit Enables AF_UNIX Container Escape appeared first on Daily CyberSecurity.
A public PoC for the Linux kernel flaw CVE-2026-52923 allows local attackers to escalate to root privilege. Learn about the patch and technical details.
Related Posts:
The post Public PoC for CVE-2026-52923 Allows Attackers to Escalate to Root Privilege appeared first on Daily CyberSecurity.
A public PoC named VsockDrop turns CVE-2026-53365 into unprivileged local privilege escalation to root on Linux. Details and exploit code are disclosed.
Related Posts:
The post CVE-2026-53365: VsockDrop PoC Enables Unprivileged Local Privilege Escalation appeared first on Daily CyberSecurity.
CVE-2026-74480 (CVSS 9.8) enables Linux kernel privilege escalation via a bridge use-after-free. Exploit code and a demo are now public.
Related Posts:
The post CVE-2026-74480 (CVSS 9.8): Linux Kernel Privilege Escalation PoC Public appeared first on Daily CyberSecurity.
CVE-2026-52912, a Linux kernel netfilter use-after-free, now has public PoC exploit code enabling root privilege escalation.
Related Posts:
The post CVE-2026-52912: Linux Kernel Root Exploit PoC Disclosed appeared first on Daily CyberSecurity.
Public PoC exploit code for CVE-2026-52929, a Linux kernel SCTP flaw, escalates to root. Full vulnerability details are now disclosed.
Related Posts:
The post CVE-2026-52929: PoC Exploit Published for Linux SCTP Privilege Escalation appeared first on Daily CyberSecurity.
Following extensive testing, Linux Kernel 7.2 is now available. Discover the latest updates regarding hardware drivers, file systems, and kernel security.
Related Posts:
The post Linux Kernel 7.2 Arrives with Extensive Updates appeared first on Daily CyberSecurity.
A public PoC exploits a Linux AF_PACKET race for local privilege escalation to root. Fixed in commit 03390aa; no CVE assigned yet.
Related Posts:
The post Linux AF_PACKET Race (03390aa): PoC Exploit Enables Local Privilege Escalation appeared first on Daily CyberSecurity.
A Linux kernel RDMA/rxe use-after-free (CVE-2026-64582) enables local privilege escalation. Full details and PoC exploit code are now public.
Related Posts:
The post CVE-2026-64582: PoC Exploit Published for Kernel LPE appeared first on Daily CyberSecurity.
PoC exploit code is public for CVE-2026-64560, a Linux kernel CPU timer flaw that gives a root shell on Pixel 10 Pro. CVSS 7.0. Details inside.
Related Posts:
The post CVE-2026-64560: Linux Kernel CPU Timer Use-After-Free Gives a Root Shell, PoC Exploit Code Publicly Disclosed appeared first on Daily CyberSecurity.
PoC exploit code is public for CVE-2026-43074, a Linux kernel eventpoll flaw that gives a root shell on Pixel 10 Pro. CVSS 7.3. Details inside.
Related Posts:
The post CVE-2026-43074: Linux Kernel eventpoll Use-After-Free Gives a Root Shell, PoC Exploit Code Publicly Disclosed appeared first on Daily CyberSecurity.
A Linux SCTP kernel use-after-free (CVE-2026-64564) enables local privilege escalation and full container-to-host escape.
Related Posts:
The post CVE-2026-64564: SCTP Flaw Enables Container Escape appeared first on Daily CyberSecurity.
Tails 7.10.1 patches CVE-2026-64560 in the Linux kernel and expat library flaws that could let attackers deanonymize users and gain admin privileges.
Related Posts:
The post Tails 7.10.1 Fixes Critical Linux Kernel Vulnerability appeared first on Daily CyberSecurity.
PoC exploit code is public for CVE-2026-64561 (Zapscape), a KVM escape that runs commands with kernel root privilege on the host. Details inside.
Related Posts:
The post CVE-2026-64561: Zapscape KVM Escape Runs Commands With Kernel Root Privilege, PoC Exploit Code Publicly Disclosed appeared first on Daily CyberSecurity.
On April 29, 2026, a Linux kernel local privilege escalation vulnerability was publicly disclosed under the name "Copy Fail" (CVE-2026-31431). Cloudflare’s Security and Engineering teams began assessing the vulnerability as soon as it was disclosed. We reviewed the exploit technique, evaluated exposure across our infrastructure, and validated that our existing behavioral detections could identify the exploit pattern within minutes.
There was no impact to the Cloudflare environment, no customer data was at risk, and no services were disrupted at any point. Read on to learn how our preparedness paid off.
Cloudflare operates a global Linux server infrastructure at an immense scale, with datacenters located across 330 cities. We maintain a custom Linux kernel build based on the community's Long-Term Support (LTS) versions to manage updates effectively at this volume. At any given time, we may utilize multiple LTS versions from various series, such as 6.12 or 6.18, which benefit from extended update periods.
The community regularly merges and releases security and stability updates which trigger an automated job to generate a new internal kernel build approximately every week. These builds undergo testing in our staging data centers to ensure stability before a global rollout. Following a successful release, the Edge Reboot Release (ERR) pipeline manages a systematic update and reboot of the edge infrastructure on a four-week cycle. Our control plane infrastructure typically adopts the most recent kernel, with reboots scheduled according to specific workload requirements.
By the time a CVE becomes public knowledge, the necessary fix has typically been integrated into stable Linux LTS releases for several weeks. Our established procedures ensure that we have already deployed these patches.
At the time of the "Copy Fail" disclosure, the majority of our infrastructure was running the 6.12 LTS version, while a subset of machines had begun transitioning to the newer 6.18 LTS release.
It helps to understand the vulnerability before getting to the response story. A comprehensive write-up can be found in the original Xint Code disclosure post.
The Linux kernel's internal crypto API manages functions like kTLS and IPsec. Userspace programs access this via the AF_ALG socket family, allowing unprivileged processes to request encryption or decryption. The algif_aead module facilitates this for Authenticated Encryption with Associated Data (AEAD) ciphers.
An unprivileged program follows these steps:
Entrar
AF_ALG socket and binds to an AEAD template.sendmsg() or splice().recvmsg().The splice() system call is critical here, as it moves data by passing page cache references.
The page cache is a shared system cache for file contents. Modifying a page belonging to a setuid binary effectively edits that program for all users until the page is evicted.
The crypto API utilizes scatterlists, which are structures linking various memory pages. In 2017, algif_aead was optimized for in-place operations, chaining destination and reference pages together. This design lacked enforcement to prevent algorithms from writing past intended boundaries.
When the user executes recvmsg(), the authencesn wrapper in the kernel performs a 4-byte write past the legitimate output region:
By using splice(), an attacker can chain a target file's page cache pages to the scatterlist. The out-of-bounds write then taints the cached file, allowing an attacker to control which file is modified, the offset, and the specific 4 bytes written. This means the attacker can manipulate the following with this exploit:
assoclen and splice parameters.sendmsg()The default exploit targets /usr/bin/su, a setuid-root binary present on essentially every distribution.
/usr/bin/su as O_RDONLY and read() to populate the page cache. Use splice() on the file descriptor to pass these page cache references into the crypto scatterlist.AF_ALG socket, bind() to authencesn(hmac(sha256),cbc(aes)), set a key, and accept a request socket without needing privileges.sendmsg() with AAD bytes 4–7 containing the shellcode.splice() the binary into a pipe then the AF_ALG socket so assoclen + cryptlen targets the desired .text offset.recvmsg() initiates decryption. authencesn writes its scratch data to the target offset of /usr/bin/su in the page cache. Although the function returns -EBADMSG, the 4-byte write is now in the global page cache.execve("/usr/bin/su") loads the tainted page cache. Since the binary is setuid-root, the injected shellcode executes with root privileges.The upstream fix (commit a664bf3d603d) reverts the 2017 in-place optimization, removing the exploit.
When the vulnerability was disclosed, many workstreams started in parallel:
There was no customer impact at any point during this response.
One of the first things our security team did was confirm that our existing endpoint detection would catch this exploit. Our servers run behavioral detection that continuously monitors process execution patterns. It doesn't rely on knowing about specific vulnerabilities; it watches for anomalous behavior across the fleet.
When our engineers validated the vulnerability internally as part of the response, the detection platform flagged it within minutes. The system linked the entire execution chain—starting at the script interpreter, moving through the kernel’s cryptographic subsystem, and ending at the privilege escalation binary—flagging it as malicious based on fleet-wide behavioral patterns.
This happened without a signature update, without a rule change, and without human intervention. Our behavioral detection coverage existed before we wrote any custom logic for this particular Copy File exploit.
The confirmation was important because it meant we had coverage before writing a vulnerability-specific rule.
While our engineering team moved to a more targeted mitigation, our security investigation had been running since disclosure. This is our standard procedure for any critical vulnerability.
Our security team operates on a simple principle for critical vulnerabilities: assume compromise until you can prove otherwise. The investigation started from the assumption that exploitation could have occurred before the vulnerability was public, and we worked systematically to either confirm or rule it out.
The exploit leaves a distinctive trace in kernel logs when it runs. We searched for that trace across our centralized logging infrastructure, covering 48 hours before the vulnerability was publicly disclosed. If someone had exploited this before the world knew about it, we would have seen it.
We pulled access logs for affected systems and reconstructed who connected, when, and what commands they ran. This gave us a complete forensic picture of interactive activity on potentially affected infrastructure.
We checked that system binaries had not been tampered with, validated cryptographic hashes against known-good package manifests, looked for persistence mechanisms, and audited network connections for anything unusual. Everything was clean.
This graph shows the progress of our mitigation program as it progressed through our infrastructure.
Because of the long timeframe involved in deploying a patched Linux kernel, we also pursued mitigating this exploit without a reboot.
The bug was in the algif_aead kernel module. Therefore, the simple fix was to just remove this module and disallow it from being reloaded.
This mitigation was therefore exactly what the Copy Fail write-up from the security researchers who identified it recommends.
Unfortunately removing the module would have impacted software that leverages the kernel crypto API. This meant that we had to figure out a more surgical mitigation.
We’ve already developed and deployed such a tool for this exact scenario: bpf-lsm. Instead of removing the module, this tool leaves it loaded for legitimate users and uses a BPF Linux Security Module program to deny the socket_bind LSM hook for everyone else. This completely blocks the front door for any exploits.
A draft of the eBPF program was put together overnight. Team members picked it up the following morning, ran validations, and made it production-ready. The program is fairly straightforward. On every socket_bind call:
AF_ALG, allow the call through unchanged.AF_ALG, check the calling binary's path against an allow-list of the binaries we know to be legitimate users.To verify the mitigation on a given machine without exploiting it, the Copy Fail write-up gives a one-liner:
On a mitigated machine you get PermissionError: [Errno 1] Operation not permitted (or FileNotFoundError, depending on which mitigation is active) instead of a successful bind.
Before enabling enforcement, we verified that our known internal service was the sole legitimate AF_ALG user to avoid accidental outages. We used prometheus-ebpf-exporter to hook the socket() syscall and track AF_ALG usage per binary across the fleet. This required no kernel changes and provided aggregate data from hundreds of thousands of servers within hours. Results confirmed the identified service was indeed the only legitimate user.
So the bpf-lsm rollout was deliberately staged in two steps:
AF_ALG sockets.In parallel, the upstream backport for our majority LTS line finally became available, and our internal automation built a patched kernel against it.
We started to test the patched kernel in our staging datacenters as soon as possible, then we resumed the longer reboot process in order to fully patch our fleet.
While we were prepared for this scenario, at Cloudflare we’re always learning and improving. Key areas we identified for improvement:
The "Copy Fail" vulnerability presented a unique challenge for us. Despite our practice of deploying Linux patch updates every two weeks, we remained vulnerable because a month-old mainline fix had yet to be backported to our primary kernel line. Despite that, we were still able to roll out patched kernels within hours of the backport's release. In the interim, bpf-lsm provided a surgical, no-reboot mitigation that secured our fleet. While our initial attempt to disable the problematic module failed, it did so safely within our internal staging environment rather than production, allowing us to identify this dependency.
By the end of the rollout, every machine in our fleet was protected by either a patched kernel or a bpf-lsm program denying the vulnerable code path to non-allow-listed binaries. There was no customer impact at any point during this incident, and we have committed to the follow-up work above to make our response faster and our visibility better the next time something like this lands. Responsible disclosure works, in-kernel visibility tooling pays off in moments exactly like this one, and bpf-lsm continues to be one of the most useful primitives we have for runtime kernel mitigation.
At Cloudflare, critical vulnerability response is a coordinated effort across Security, Engineering, Product, and many other teams. Special thanks to Ali Adnan, Ivan Babrou, Frederik Baetens, Curtis Bray, Piers Cornwell, Everton Didone Foscarini, Rob Dinh, Elle Dougherty, Kevin Flansburg, Matt Fleming, Kimberley Hall, Brandon Harris, Jerry Ho, Oxana Kharitonova, Marek Kroemeke, Fred Lawler, James Munson, Nafeez Nazer, Walead Parviz, Miguel Pato, Evan Pratten, Josh Seba, June Slater, Ryan Timken, Michael Wolf, Jianxin Zeng and everyone else who contributed to the investigation, mitigation, and remediation of Copy Fail. We'd also like to thank the Linux upstream maintainers and Copy Fail researchers whose work helped make a rapid response possible.
