Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026 
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026 
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026 
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026 
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026 
Refine features
X Clear Filters Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
security advisoryhigh severitylocal privilege escalationUbuntu Copy Fail High Local Privilege Escalation Threat Advisory 2026-31431
Most Linux hardening focuses on access. This vulnerability bypasses that entirely. . Think about Linux security like the structural integrity of a building. We spend a lot of time on the front door—locks, cameras, and ID badges. Those are just policy layers. They’re great for keeping people out, but they don't tell you what happens to the foundation if a core system component is bypassed in plain sight. The reality is that upstream kernel security moves a lot faster than enterprise adoption. Defenses are being built quietly through patch discussions and mailing lists, not through big announcements. By the time a vulnerability like this becomes a standard operational concern, the risk has already been sitting in the gap between what is "available" and what is actually "active" in your environment. Copy Fail (CVE-2026-31431 ) sits right in that gap. It’s a high-severity local privilege escalation flaw in the Linux kernel’s cryptographic subsystem ( authencesn ), and it’s easy to miss if you’re only tracking what’s been announced instead of what’s actually running. This isn't about just listing what exists; it’s about verifying what is actually working on your systems and knowing where the risk actually lives. Why This Matters in Production Environments If you're trying to figure out how to secure a server, the structural boundaries are where things usually break down. Copy Fail is not remotely exploitable on its own, but chained with a web Remote Code Execution (RCE), a compromised CI runner, or an SSH breach, it gives an external attacker an immediate express lane to host-level root. The real danger of this local privilege escalation Linux flaw isn't on a single, isolated desktop. The risk lies in the shared infrastructure that powers modern enterprise tech: Container Escape Vulnerabilities: The vulnerability represents a dangerous container escape primitive . Because the page cache is shared at the host level, an attacker doesn’t stay contained. Frominside a compromised container, this turns into a path straight to the underlying Kubernetes node. Shared Kernels: Containers aren’t isolated in the way most people assume; they all rely on the same kernel and memory. Once that boundary breaks, it doesn’t stop at one workload. How 4 Bytes Can Give You Root To understand what’s happening, you don't need to be a kernel developer. Most server security conversations stay at the surface—firewalls, access controls, patching. But this vulnerability stems from an in-place processing optimization introduced to the Linux kernel back in August 2017 (commit 72548b093ee3). The kernel uses a mechanism called the page cache to keep frequently accessed files in RAM, so the system doesn't have to keep reading the slower disk drive. When you make an AEAD (Authenticated Encryption with Associated Data) request through an AF_ALG socket to the authencesn cryptographic template, the kernel processes the data. Due to this optimization, a page from the page cache ends up in the writable destination scatterlist: The Overwrite: If an attacker binds a socket to authencesn and sends a recvmsg call with the exact offset, the kernel treats the request as an in-place operation. It writes four controlled bytes into the page cache of a target setuid binary (such as /usr/bin/su ). The Hijack: The exploit doesn't alter the file on disk. File integrity monitoring tools will see nothing. Instead, it alters the binary as it is executed . When that setuid binary is run by the system or another user, it reads the modified cache, executes the corrupted memory instead of the original code, and hands over root privileges to the unprivileged user. The Simplicity: Unlike older, complex LPEs like Dirty Pipe, there are no race conditions or tricky timing windows to worry about. With a 732-byte Python script, it works reliably on the first try across almost all enterprise Linux builds (Ubuntu, Debian, RHEL, SUSE) released since 2017. The AI Factor: Why This Problem Is About to Get Worse This isn't an isolated discovery pattern, nor is it just a theoretical milestone. Copy Fail wasn't found by a researcher spending months hunting through assembly code by hand. It was identified by Theori researcher Taeyang Lee using their Xint Code AI scanning software in about an hour. Think about the economics of vulnerability research: for years, finding a reliable, high-severity local privilege escalation flaw in the Linux kernel required deep domain expertise, patience, and manual fuzzing with tools like syzbot . The barrier to entry was high, and the turnaround time was measured in weeks or months. That barrier has completely collapsed. When an AI-driven tool can scan, identify, and trace a deep logic flaw in the kernel's cryptographic subsystem in sixty minutes, the friction of discovery drops to zero. We are looking at an exponential increase in automated vulnerability discovery. The industry is already feeling the downstream pressure of this shift—security programs and maintainers are being inundated with automated bug reports, struggling to triage deep logic vulnerabilities at scale. What does this mean for your infrastructure? It forces a change in your fundamental threat model. You can no longer treat kernel-level LPEs as rare anomalies that only affect high-value targets. If vulnerabilities are found in minutes, threat actors and automated agents can weaponize and chain them into container escapes much faster than enterprise release cycles can accommodate. When the foundation can be breached this quickly, infrastructure security stops being about patching known bugs one by one. It becomes a requirement to harden the environment against entire classes of vulnerabilities and validate those protections at the host layer before an attacker even gets a foot in the door. The System Looked Clean, but Wasn’t In internal testing, this exploit worked on fully patched enterprise Linux builds from the last several years,with no alerts triggered and no file changes on disk. What to Check and Where Mitigations Fail The gap between what’s possible and what’s deployed is where risk lives. Standard patching doesn't always validate these internal controls, and many teams assume a patch was applied without auditing the running state of the host. For instance, simply updating the base image of a container does nothing if the underlying host kernel remains vulnerable. Furthermore, disabling modules requires active host reboots or unloads that often get delayed in production. Here is a quick check for your endpoint security: Patch Your Kernels: Major Linux distributions have already rolled out updates. Debian, Ubuntu, and SUSE are pushing patches. Red Hat shifted its guidance to issue patches promptly. Check your distribution's security repository and apply the latest kernel packages. On production Kubernetes clusters, plan a rolling drain-and-reinstate procedure. Apply Temporary Mitigations: If you can't reboot or patch your kernels immediately, you can disable the vulnerable algif_aead module. Harden Container Pipelines: Restrict the creation of AF_ALG sockets using seccomp profiles to stop the exploit from being executed within containers. # Disable the vulnerable algif_aead module echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2> /dev/null || true (Note: This mitigation doesn't affect standard encryption like IPsec or OpenSSL, but you should always test it in a non-production environment first). True infrastructure security is about the foundation. Validation matters more than assumptions. The best defenses aren't the ones you read about in a memo—they’re the ones you’ve actually turned on and validated within your container workloads. Where Security Assumptions Break Nothing here throws obvious signals. The system runs, policies stay loaded, logs look routine, and the control still doesn’t behave the wayanyone expects once it’s actually exercised. The problem shows up at the boundary. A container reaches past its limits, a syscall path resolves when it shouldn’t, a restriction exists but doesn’t apply in the exact context an attacker lands in, and that’s enough. It doesn’t take much. One weak spot in a shared layer, one enforcement gap that never got tested under real conditions, and isolation starts to blur in ways that don’t show up in configs or dashboards. This isn’t about adding more controls. It’s about knowing which ones you’ve pushed hard enough to trust, and which ones are still sitting there unverified. Subscribe to the newsletter if you want direct insight into where these breaks actually happen, especially around kernel behavior and container boundaries. . Think about Linux security like the structural integrity of a building. We spend a lot of time on th. linux, hardening, focuses, vulnerability, bypasses, entirely, think, about. . MaK Ulac
May 01, 2026 •
102
security toolkernel exploitLinux kernelBlackHat USA 2022: eBPF Kernel Exploitation Detection and Prevention
Let's take a brief look at what Guillaume Fournier from Datadog presented at Blackhat USA 2022: “One of the fastest growing subsystems in the Linux Kernel is, without any doubt, eBPF (extended Berkeley Packet Filter)." . He elaborates, "Although eBPF initially targeted network monitoring and filtering use cases, its capabilities have been broadened over time. With each new kernel version, the capabilities of eBPF are getting closer to that of a kernel module with additional benefits: system safety and stability. Like any other kernel features, eBPF has introduced its fair share of kernel bugs and vulnerabilities, questioning the maturity of a solution that introduces a rich feature set but considerably increases the kernel attack surface. On the other hand, eBPF is now powering an increasing amount of endpoint protection solutions, showcasing original ideas to detect threats at runtime. Unlike many projects that aim at detecting malicious behaviors in user space, this talk focuses on how eBPF can be leveraged to detect and prevent various kernel exploitation strategies.” Now I know you may be wondering: what exactly is eBPF? Well, let's go through it together! Given the linux kernel's unrestricted ability to monitor and manage the entire operating system, it has always been the ideal location to incorporate observability, security, and networking features. At the same time, because of its key function and high requirements for stability and security, the kernel is difficult to use when it comes to applications. Berkeley Packet Filter, or BPF for short, introduced a new interface for programs to make kernel requests alongside syscalls, making a significant modification to the old kernel model. Big name companies such as Netflix and Facebook run many BPF applications due to its capability of running new types of user-defined and kernel-mode applications. BPF is essentially a kernel and user-space observability mechanism for executing code in kernel or user space that reacts to events such asfunction calls, function returns, and trace points. BPF programs offer both rapid and extremely powerful and flexible ways of deep observability of what is happening in the Linux kernel or user space. Understanding the Linux Kernel Architecture When it comes to the Linux Kernel, there are roughly three parts to it: the user space, the linux kernel itself or the OS, and then finally we have the actual hardware. Essentially, this all works together and is wrapped in a process. Anything that is not a kernel process, such as normal apps, operates in the user space. Any code that runs within the user space has restricted hardware access and relies on kernel space code for privileged activities, such as reading and writing on the disk, or even network interaction such as sending data via a BSD or TCP socket. The Kernel space, on the other hand, contains the operating system's core. It has complete and unlimited access to all hardware, including RAM, storage, and the CPU. As we stated earlier, the kernel space is secured and only permits the most trusted programs to execute, including the kernel itself and numerous device drivers, which means code within the user space has limited access. In the image below, it basically sums up the this entire process: While the system call interface might be enough in some cases, developers may require complete flexibility to handle new hardware, create new programs, etc, and this requires expanding the underlying kernel without directly modifying the kernel source code. This is where eBPF comes into play. How eBPF Works What eBPF allows users to do is quite incredible; it allows users to take a system call and run a program that takes over on its behalf. With this in mind, it can be used to create programs for networking, debugging, tracing, firewalls, and more. eBPF was inspired by dtrace, a dynamic tracing tool available primarily for the Solaris and BSD operating systems, since there was a need for better Linux tracing capabilities. Unlike dtrace, linux at thetime could not provide a layout of systems that were running hence the need to improve eBPF, giving a similar set of functionalities as dtrace. To avoid hazards such as limitless loops, eBPF applications are evaluated within the kernel. As a result, as compared to an arbitrary Linux loadable kernel module, eBPF applications represent less risk. There is an eBPF Runtime within the kernel, and the runtime ensures that these programs guarantee and meet all programmability standards. Additionally, programs are written and executed in bytecode when using eBPF. As a result, eBPF allows programmers to securely run custom bytecode within the Linux kernel without altering or adding to kernel source code, allowing applications with custom code to interact with protected hardware resources while putting the kernel at little risk. Benefits of eBPF eBPF can be adapted to do a variety of things, and its benefits are highlighted below: Performance : eBPF allows packet processing to be moved from the kernel to the user space. eBPF is also a just-in-time (JIT) compiler. eBPF is invoked after the bytecode is compiled, rather than a fresh interpretation of the bytecode for each method. Invasiveness is minimal: When used as a debugger, eBPF does not require the application to be stopped in order to examine its status. Security: Programs are essentially sandboxed, as shown in the image below, which means that kernel source code stays safe and unmodified. The verification phase guarantees that resources are not overburdened by programs that perform infinite loops. Moreover, eBPF provides a unified, robust, and user-friendly framework for tracing processes which improves both visibility and security. Convenience: It takes less effort to write code that hooks into kernel functions than it does to construct and maintain kernel modules. There are many reasons why people should use eBPF as listed above, but here are some reasons why you shouldn’t: Detecting post compromission isfighting a lost battle There are dozens of ways to disable an eBPF program eBPF can have a significant in kernel performance impact Known Issues within the Linux Kernel Critical CVEs are regularly discovered within the Linux Kernel. As of now, there are a recorded 3349 CVE Records for the linux kernel alone. This causes security administrators and daily users to worry about: Keeping up with security updates Deploying security patches Monitoring & protecting vulnerable hosts As of now, we already have 2 vulnerabilities for the month of August with regards to the linux kernel. Firstly, we have CVE-2022-1012 , which consists of a memory leak problem that was found in the TCP source port generation algorithm in the net/ipv4/tcp.c file due to the small table perturb size. This flaw could allow an attacker to leak information and can give them free rein to cause a denial of service problem or carry out a full-fledged DoS attack. The second vulnerability would be CVE-2022-1973 , which consists of a use-after-free flaw that was found in the Linux kernel in the log_replay in fs/ntfs3/fslog.c file in the NTFS journal. Essentially, this flaw allows a local attacker to crash the system and leads to a kernel information leak problem. With the implementation and modification of eBPF, we can monitor kernel activity and patch zero-day attacks and vulnerabilities before they are found. For the sake of what was presented at Blackhat USA 2022, we will be discussing how to prevent the following 3 vulnerabilities with eBPF: Execution flow redirection Logic bugs Post compromise kernel runtime alteration DataDogs Solution: KRIe Kernel Runtime Integrity with eBPF is an Open-Source, Compile Once Run Everywhere tool that aims to detect Linux Kernel exploits with eBPF. KRIe is far from being a bulletproof strategy: from eBPF related limitations to post exploitation detections that might rely on a compromised kernel to emit security events, it is clear that a motivated attacker willeventually be able to bypass it. That being said, the goal of the project is to make attackers' lives harder and ultimately prevent out-of-the-box exploits from working on a vulnerable kernel. Requirements This project was developed on Ubuntu Focal 20.04 (Linux Kernel 5.15) and has been tested on older releases down to Ubuntu Bionic 18.04 (Linux Kernel 4.15). golang 1.18+ (optional) Kernel headers are expected to be installed in lib/modules/$(uname -r), update the Makefile with their location otherwise. (optional) clang & llvm 14.0.6+ To best show how this tool works, the developers created two scenarios for us users: Scenario 1: the attacker controls the address of the next instruction executed by the kernel Scenario 2: the attacker is root on the machine and wants to persist its access by modifying the kernel runtime In scenario 1, machines with SMEP & SMAP can prevent an attacker from carrying out the instruction executed in the user space, however, what about machines without SMEP & SMAP? KRIe places a kprobe and checks if the Stack pointer / Frame pointer / Instruction pointer registers point to user space memory. Remember earlier we said that KRIe is not bulletproof and attackers can find a way around the kprobe by disabling it using the commands echo 0 > /sys/kernel/debug/kprobes/enabled Or sysctl kernel.ftrace_enabled=0 An attacker can also disable a kprobe by killing the user space process that loaded it to begin with. KRIe combats this by setting up what they call booby traps, essentially setting the Return Object Programming or ROP chain to set the instruction the attacker is trying to take over to null. In scenario 2, the attacker could: Insert a rogue kernel module Hook syscalls to hide their tracks Using kprobes By hooking the syscall table directly Use BPF filters to silently capture network traffic Use eBPF programs to implement rootkits KRIe combats thisby: Monitoring All bpf() operations and insertion of BPF filters Kernel module load / deletion events K(ret)probe registration / deletion / enable / disable / disarm events Ptrace events Sysctl commands Execution of hooked syscalls All syscall tables are checked periodically and KRIE is also able to detect and report when a process executes a hooked syscall whilst also locking down the execution flows in the kernel by controlling call sites at runtime. Moreover, every detection is configurable whether it be Log, Block, Kill, or Paranoid which are different detection definements. Our Thoughts Powerful defensive tools can be implemented with eBPF as shown with the KRIe tool however, eBPF is not really the ideal technology to detect kernel exploits. KRIe is realistically a last resort and not a bulletproof strategy but why not put that to the test! Follow along with us in our next article as we put this open-source tool through various test-environments. . Uncover the ways eBPF elevates the monitoring and protection of the Linux kernel by detecting vulnerabilities and reinforcing the overall integrity of system operations.. Kernel Exploitation, eBPF Monitoring, Security Tools, Linux Kernel, Runtime Protection. . Brian Gomez
Aug 29, 2022 • 
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More