Explore top 10 tips to secure your open-source projects now. Read More
×
Stay Ahead With Linux Security Features
security practices patch management Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange...
Jul 14, 2026
Linux security cyber attacks Every Linux server in your fleet produces thousands of events every minute. From journald logs and auditd records to kernel-level eBPF hooks, your systems are constantly talking. Most of that noise is just the mundane churn of system services, CI/CD runners, or routine administrative automation. But among that noise, an attacker might be establishing a foothold, moving laterally, or setting up persistence. The challenge for any security team is: how do you separate the routine from the...
Jul 13, 2026
open-source infrastructure risk Security scanners flag exposed API keys in public repositories every day. The initial response is usually predictable: delete the commit, revoke the credential, and move on. That’s a mistake. . In a real Linux environment, an API key never stays in one place. By the time it hits a public repo, it’s already everywhere. It’s in the CI/CD pipeline. It’s in your container registry. It’s in the build logs. It’s in the backups. Git makes this worse because the history never dies. Deleting a file in...
Jul 11, 2026
open-source rootkit Most of us think of Linux rootkits as ancient history—the stuff of 90s hacking forums and clunky malware that would crash your system if you looked at it the wrong way. But if you think they’ve gone away, you’re mistaken. They’ve just gotten smarter. . Modern attackers aren't using the noisy tools of the past. Today’s threats are surgical. Many of today’s most advanced Linux rootkits operate at the kernel level or abuse legitimate system features to blend in with normal traffic. They’re...
Jul 09, 2026
security advisory hardening A 16-year-old KVM vulnerability recently hit the news, and honestly? It’s a healthy dose of reality. We like to think of our hypervisors as these impenetrable walls, but this is a reminder that VM isolation isn't a permanent guarantee. Even in the most mature Linux virtualization stacks, you’ve got code paths that haven't been touched in over a decade, just waiting for the right researcher to pull on the wrong thread. For those of us running KVM hosts, this isn't just about grabbing the latest...
Jul 07, 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
Is continuous patching actually viable?
Trending Features
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
security advisoryapacheDoSHTTP/2 Bomb: Why Linux Infrastructure is Vulnerable to a New Low-Bandwidth DoS Attack
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 low-bandwidth attacker could disrupt the web servers, reverse proxies, and application gateways responsible for keeping production workloads online. The "Resource Amplification" Trap Researchers at Calif recently disclosed the technique, describing how HTTP/2 header compression and flow-control mechanisms can be abused to trigger significant memory consumption on affected systems. The attack combines a compression bomb with connection-stalling behavior, creating a situation where server resources continue accumulating while requests remain active. Most denial-of-service planning assumes attackers need large botnets or substantial network capacity. HTTP/2 Bomb shifts the burden onto the server itself. The attacker sends relatively little traffic while the target allocates memory, maintains state information, and struggles to reclaim resources quickly enough to remain responsive. Why Apache, NGINX, and Envoy are Ground Zero This attack is generating noise because it affects the technologies Linux administrators deploy every day. Apache and NGINX remain dominant web server platforms across hosting providers, enterprise environments, and public-facing applications. Envoy has become a foundational component of modern cloud-native infrastructure, appearing inside API gateways, service meshes, and Kubernetes ingress controllers. When these components experience resource exhaustion, the consequences extend beyond a single application. Reverse proxies stop accepting connections. API gatewaysbecome bottlenecks. Load balancing layers degrade. Kubernetes workloads may remain perfectly healthy while the infrastructure responsible for routing traffic to them begins failing under pressure. How the Mechanics Work: HPACK and Flow-Control Abuse HTTP/2 was designed to improve efficiency by reducing the overhead associated with traditional web traffic. One of the core features is HPACK , a header compression mechanism that minimizes data exchange by storing and reusing previously transmitted header information. According to the research, attackers can abuse HPACK’s indexed-reference system to trigger memory expansion on the receiving server. Relatively small requests force the target to allocate significantly larger amounts of memory than the attacker contributes. The second stage is what makes this a practical threat. Researchers combined this header abuse with HTTP/2 flow-control behavior that slows the release of allocated resources. Instead of freeing memory, affected systems hold state information while additional requests accumulate. The resource consumption grows until performance degrades or services become unavailable—effectively creating a "Slowloris" for memory. Why Kubernetes Operators Should Pay Attention The Kubernetes angle is particularly critical. Many organizations have shifted infrastructure toward Envoy-based architectures and gateway technologies. Traffic that once flowed directly to a web server is now routed through increasingly sophisticated networking layers designed to provide observability and security. That architecture delivers benefits, but it also concentrates risk. When ingress or gateway infrastructure becomes unstable, healthy workloads become inaccessible. For Kubernetes operators, the question is not simply whether a workload is vulnerable; it is whether the infrastructure supporting that workload can continue handling traffic efficiently when exposed to this style of resource amplification. Current Patch Status and Mitigation Vendors havealready begun responding: NGINX introduced a new max_headers directive to limit accepted request headers. Apache updated mod_http2 , improving header accounting and addressing conditions associated with the attack. Administrators should review vendor guidance directly and verify patch levels across production environments rather than assuming repository updates have reached every system. Internet-facing systems—specifically reverse proxies, API gateways, and ingress controllers—should be prioritized. What Linux Administrators Should Do Right Now The immediate priority is visibility. Identify Exposure: Identify which internet-facing systems currently support HTTP/2. Many organizations enabled it years ago and have rarely revisited those configurations. Validate Patching: Review vendor guidance, confirm software versions, and ensure updates are applied consistently across production, staging, and disaster recovery. Monitor Resource Patterns: Attacks based on resource amplification look different from volumetric DDoS. Monitor for growing memory utilization, worker exhaustion, connection failures, or unstable performance from systems that appear to be receiving modest traffic. Evaluate Ingress Routing: Kubernetes operators should review how HTTP/2 traffic terminates, is inspected, and is routed. Identifying where requests are handled is the first step in determining which components will experience pressure. The Bigger Lesson for Linux Defenders The most interesting aspect of HTTP/2 Bomb is the reminder that modern Linux infrastructure depends heavily on layers of software designed to improve efficiency. Those same optimizations can become attack surfaces when researchers discover ways to force systems into consuming resources faster than they can recover them. Linux administrators spend considerable effort defending against exploits and privilege escalation, but some of the most disruptive incidents begin with something far less dramatic. A trustedprotocol feature behaves in an unexpected way, critical infrastructure starts consuming resources faster than anticipated, and the systems responsible for keeping applications online become the weakest point in the environment. HTTP/2 Bomb is a story about infrastructure resilience—ensure your Apache, NGINX, and Envoy deployments are ready for it. Related Reading Critical NGINX Vulnerability CVE-2026-42945: What Linux Admins Should Check Now Securing Remote Access to Linux Servers: Best Practices for 2026 Linux IDS vs IPS: Operational Differences and Deployment Tradeoffs How to Diagnose Suspicious Outbound Connections on Linux Servers How to Respond After Detecting a Compromised Linux Server . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that . newly, disclosed, attack, technique, called, http/2, drawing, attention, because, targets. . MaK Ulac
Jun 04, 2026
•
102
security advisorydenial of servicecriticalCritical NGINX Vulnerability CVE-2026-42945: What Linux Admins Should Check Now
New flaw leads to denial-of-service on affected NGINX configurations. If ASLR is disabled, it may become a remote code execution. . Known as NGINX Rift, CVE-2026-42945 affects NGINX’s ngx_http_rewrite_module and can allow unauthenticated attackers to crash worker processes with crafted requests. That matters because NGINX often sits at the edge of Linux infrastructure, handling web traffic, redirects, reverse proxy rules, API routing, load balancing, and application delivery. The configuration requirement may look narrow at first, but active exploitation changes the urgency. Vulnerable rewrite rules can sit in production for years without anyone reviewing them closely, leaving exposed NGINX servers as more than just another routine patch item. For Linux administrators, the immediate question is simple. Are any internet-facing NGINX systems using risky rewrite patterns, and have they been updated through official vendor channels? What You Need To Know CVE-2026-42945 affects NGINX Plus and NGINX Open Source. The flaw exists in the ngx_http_rewrite_module . The issue is tied to rewrite configurations using unnamed PCRE captures such as $1 or $2 , with replacement strings that include a question mark. An unauthenticated attacker can send crafted HTTP requests to trigger a heap buffer overflow in the NGINX worker process. The most likely impact is denial of service through worker crashes and restarts. Remote code execution may be possible in weakened environments, especially where ASLR is disabled. Administrators should prioritize official NGINX and vendor update s, then audit rewrite rules across internet-facing systems. Who Should Prioritize This First Not every NGINX server is automatically vulnerable. The risk depends on version, configuration, exposure, and whether vulnerable rewrite logic is reachable by an attacker. Still, some environments should move faster than others. Administrators should prioritize: Internet-facing NGINXservers Reverse proxies handling untrusted traffic API gateways using rewrite rules Kubernetes ingress deployments based on NGINX behavior Older virtual host configurations inherited from previous applications Containers or images that package NGINX directly Systems using unnamed capture references such as $1 or $2 Linux systems where ASLR has been disabled This is especially important for servers that have accumulated rewrite logic over time. Redirects, backend mappings, language routing, legacy URL support, and API path changes are often copied between systems and forgotten. That is where risk can sit unnoticed. Why This NGINX Flaw Matters NGINX is everywhere in Linux environments. It sits in front of web apps, Kubernetes ingress controllers, API gateways, cloud services, containers, and internal dashboards. In many environments, it is the first layer that handles untrusted traffic before a request ever reaches the application. That is what makes this flaw different from a bug buried deep inside one service. An attacker does not need shell access. They do not need stolen credentials. They do not need to reach the backend directly. If the vulnerable rewrite configuration is exposed, crafted HTTP requests may be enough to crash NGINX worker processes and disrupt availability. In production, that could look like intermittent 502 errors, failed API calls, broken redirects, unstable ingress behavior, or repeated worker restarts. In shared reverse proxy or Kubernetes environments, one exposed traffic layer may affect several services behind it. The second concern is how quickly bugs in edge-facing services attract attention. CVE-2026-42945 affects a widely used component and sits in rewrite logic that many teams probably have not reviewed in years. Public proof-of-concept activity has also been reported, which makes patching and configuration review harder to delay. What Makes CVE-2026-42945 Important The vulnerability is not triggered simply because NGINXis installed. According to F5’s advisory , the flaw exists when a rewrite directive is followed by a rewrite, if, or set directive and an unnamed PCRE capture, such as $1 or $2 , is used with a replacement string that includes a question mark. Under those conditions, crafted HTTP requests may cause a heap buffer overflow in the NGINX worker process. That creates a practical problem for Linux teams. Rewrite rules are often old. They are copied between servers, inherited from previous application versions, reused across reverse-proxy templates, and buried in site configs that no one has touched in years. In large environments, administrators may not immediately know which NGINX deployments use vulnerable rewrite patterns. That delay matters in response, since the vulnerability reportedly dates back many years, meaning older, long-lived systems may be exposed if they have not been updated through vendor channels. Old configuration logic has a way of surviving infrastructure migrations. A server might move from bare metal to the cloud. A site might move behind a load balancer. A service might become part of a containerized platform. But the rewrite rules often stay almost exactly the same. Quick 5-Minute Check Administrators should begin by identifying where NGINX is running, especially on internet-facing Linux systems. Check installed NGINX versions: nginx -v Review the active configuration: nginx -T Search for rewrite directives: nginx -T 2> /dev/null | grep -n "rewrite" Search for unnamed capture references: nginx -T 2> /dev/null | grep -E '\$[0-9]' Administrators should pay close attention to rewrite logic that uses captures such as $1 or $2 , especially when the replacement string includes a question mark. Additional priorities should include: Reviewing NGINX virtual host and site configuration files Checking reverse proxy and API gateway rewrite rules Auditing Kubernetes ingress configurations that rely on NGINX behavior Reviewing container images that package older NGINX versions Confirming whether ASLR is enabled on Linux systems Prioritizing externally reachable NGINX deployments first This quick check will not replace patching, but it can help teams find the highest-risk systems faster. Patching Is the Priority The safest response is to update NGINX through official channels. Administrators should apply fixes from F5, NGINX, or their Linux distribution rather than manually modifying source code or relying only on partial configuration changes. Organizations should monitor advisories and package updates from: Red Hat Ubuntu Debian Fedora SUSE AlmaLinux Rocky Linux NGINX upstream sources Cloud image and container image providers should also be checked closely. NGINX is often embedded in base images, reverse proxy containers, ingress controllers, and application delivery stacks. Updating the host operating system alone may not update every NGINX instance running across the environment. That is where teams often miss exposure. A patched server does not help if an older NGINX container is still deployed in production. Temporary Mitigation Requires Configuration Review For organizations that cannot patch immediately, configuration review becomes the next priority. F5’s advisory indicates that the vulnerable condition involves unnamed PCRE captures in certain rewrite patterns. Some reports have recommended replacing unnamed captures, such as $1 and $2 , with named captures where appropriate, but this should be tested carefully before production rollout. Administrators should be careful here. Rewrite rules can affect routing, redirects, authentication flows, API paths, application compatibility, SEO behavior, and backend request handling. A rushed change can break production traffic even if the security goal is valid. The better approach is controlled review: Identify exposed NGINX systems Find rewrite rules using unnamed captures Map whichapplications depend on those rules Test named-capture replacements in staging Deploy patched NGINX packages as soon as they are available Monitor logs for crashes, abnormal requests, and repeated worker restarts Temporary configuration changes can reduce exposure, but they should not become a substitute for patching. Why ASLR Still Matters One of the more important details in the current reporting is the difference between denial of service and code execution. On default hardened Linux systems, the most likely impact appears to be worker process crashes and restarts. That can still be serious, especially against high-traffic services where repeated crashes can degrade availability. But remote code execution becomes a larger concern when exploit mitigations are weakened. ASLR, or Address Space Layout Randomization, makes memory corruption exploitation harder by randomizing where code and data are loaded in memory. If ASLR is disabled, attackers may have a more reliable path from memory corruption to code execution. Administrators can check ASLR status with: cat /proc/sys/kernel/randomize_va_space A value of 2 generally indicates full randomization. A value of 0 means ASLR is disabled. If ASLR is disabled on exposed Linux systems, that should be treated as a serious hardening gap beyond this one vulnerability. Memory corruption flaws become more dangerous when basic exploit mitigations are turned off. Cloud and Kubernetes Environments Need Extra Review This gets more complicated in cloud and Kubernetes environments. If a vulnerable rewrite rule is exposed through an ingress controller or reverse proxy, the impact may not stop at one application. Crafted requests could repeatedly crash NGINX worker processes, trigger restarts, break routing, or affect several services sitting behind the same ingress layer. Cloud-hosted reverse proxies and API gateways run into the same problem. NGINX is used because it is fast, flexible, and familiar. But thatflexibility is also where old risk builds up. Teams add redirects, backend mappings, path normalization, language routing, legacy URL support, and API rewrites. Then those rules get copied, reused, migrated, and forgotten. Years later, they may still be running in production. That is why teams should check more than just traditional Linux servers. They should also review container images, Helm charts, ingress controller configurations, CI/CD deployment templates, and cloud images that include NGINX. Default Impact vs. Weakened-System Impact The impact depends heavily on configuration and hardening. Condition Likely Risk Vulnerable rewrite config exposed NGINX worker crash or denial of service ASLR enabled Exploitation is harder ASLR disabled Remote code execution risk may increase NGINX is used in the ingress or shared proxy layer Multiple services may be affected The older NGINX container is still deployed Host patching may not fully remove exposure This is why administrators should treat the issue as both a patching task and a configuration review task. Immediate Actions for Linux Admins Patch affected NGINX deployments immediately. Audit rewrite rules using unnamed captures such as $1 and $2 . Prioritize internet-facing NGINX servers and reverse proxies. Check container images and Kubernetes ingress deployments. Confirm ASLR is enabled on exposed Linux systems. Monitor logs for worker crashes, abnormal requests, and restart loops. Review vendor advisories for updated NGINX packages. Test any rewrite-rule mitigation before production rollout. Why Exposed Infrastructure Bugs Still Matter Linux servers now sit underneath nearly every modern environment. They power web applications, containers, cloud platforms, CI/CD systems, internal tools, and customer-facing services. Attackers know that edgeservices are valuable because they process untrusted traffic all day. A flaw in a public-facing web server, reverse proxy, or ingress layer can create immediate operational risk, even before attackers reach the application behind it. CVE-2026-42945 is a reminder that mature infrastructure components still need close attention. Old code paths, legacy rewrite behavior, and inherited configuration patterns can carry risk for years. Because in modern Linux environments, attackers do not always need to compromise the application first. Sometimes, they only need the traffic layer in front of it. Want more Linux security breakdowns and vulnerability response checklists? Subscribe to our newsletter for weekly infrastructure, hardening, and security updates. Related Reading Enhance Nginx Security With 25 Best Practices for Linux Linux Security in 2026 Hardening Monitoring and Defense Strategies Container Security Misconfigurations Kubernetes Threats Understanding Container Security Best Practices for Linux Admins The Linux Kernel in 2025: Security Enhancements, Emerging Threats & Best Practices . Known as NGINX Rift, CVE-2026-42945 affects NGINX’s ngx_http_rewrite_module and can allow unauthen. leads, denial-of-service, affected, nginx, configurations, disabled. . MaK Ulac
May 18, 2026
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Is continuous patching actually viable?
Trending Features
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!