NGINX Is Being Actively Exploited Right Now. Is Your Web Server Patched?
CVE-2026-42945 landed last week. By the time researchers at VulnCheck confirmed active exploitation in the wild, the disclosure was barely days old. NGINX, the web server software running on somewhere between a quarter and a third of all internet-facing infrastructure, has a heap buffer overflow vulnerability that allows unauthenticated remote code execution. The patch is available. The question is whether your infrastructure has it.
This is the kind of vulnerability that separates businesses with a functioning patch process from those who find out they were compromised three months later during an ICO investigation.
What CVE-2026-42945 Actually Is
A heap buffer overflow, in plain terms, is a flaw where an attacker can write data beyond the boundaries of an allocated memory region. NGINX handles this incorrectly in versions 0.6.27 through 1.30.0, which covers essentially the entire modern deployment history of the software.
The consequence: an unauthenticated attacker, someone who does not need any credentials or prior access, can send a malformed request that either crashes the NGINX worker process or, in the more serious scenario, achieves remote code execution. RCE means they run commands on your server. Their commands, your hardware, your data.
The CVSS score is 9.2. That sits in the critical band. A proof-of-concept exploit is publicly available, which explains why exploitation followed disclosure in a matter of days rather than weeks.
Why This Hits UK Small Businesses Specifically
Most small business owners do not know which web server software their infrastructure runs. That is not ignorance, it is reasonable: web server choice is an infrastructure decision made by whoever built or manages the site, not by the business owner.
The problem is that NGINX is ubiquitous. It ships as the default reverse proxy in a large proportion of managed WordPress hosting environments. It is the standard choice for many MSP-managed server configurations. It sits behind load balancers, content delivery setups, and custom web applications.
If your business has any internet-facing service, the probability that NGINX is somewhere in the chain is not trivial. And if your MSP has not already contacted you about this patch, you should be contacting them.
The supply chain dimension matters here too. If you are a supplier to a larger organisation, your web infrastructure is part of their attack surface. A compromised supplier web server has been the entry point for numerous high-profile breaches. Being the weak link in someone else’s supply chain is not a position any business wants to occupy.
What the Exploitation Looks Like in Practice
VulnCheck’s reporting indicates that exploitation is producing worker process crashes alongside attempts at remote code execution. Worker crashes are observable: your web server becomes intermittently unavailable, requests fail, logs fill with errors.
If you have seen unexplained instability in any internet-facing service in the last week, do not assume it is a hosting issue. Treat it as a potential indicator of compromise until proven otherwise. Check your NGINX access logs for anomalous request patterns. Look for requests that should not be possible given your application’s expected behaviour.
More concerning is successful RCE that does not produce visible crashes. An attacker who achieves code execution without crashing the process has a foothold they can develop quietly. This is where detection without active monitoring becomes essentially impossible.
The Wider Context: Three Vulnerabilities Worth Noting
The NGINX flaw is the priority this week, but two other items from the vulnerability intelligence warrant brief attention.
CVE-2018-25332 affects GitBucket 4.23.1, a self-hosted Git repository platform used by some small development businesses and agencies. The vulnerability allows unauthenticated remote code execution by combining weak secret token generation with an insecure file upload endpoint. If anyone in your organisation runs a self-hosted GitBucket instance, treat it as compromised until patched or replaced.
CVE-2018-25335 affects a WordPress plugin, specifically the Peugeot Music plugin version 1.0, and allows unauthenticated file upload leading to code execution. While this particular plugin has a limited install base, the vulnerability class, unauthenticated arbitrary file upload in WordPress plugins, is one of the most consistently exploited vectors against small business websites. The specific plugin matters less than the pattern: unpatched WordPress plugins are an ongoing problem that requires systematic management, not ad hoc attention.
Neither of these matches the immediate urgency of CVE-2026-42945, but both are representative of the categories of risk that routinely catch small businesses unprepared.
How to Turn This Into a Competitive Advantage
There is a practical commercial argument here that goes beyond risk mitigation.
When clients ask about your security posture, being able to demonstrate that you have a functioning vulnerability management process, one that identifies critical CVEs within 24 hours and patches within a defined window, is increasingly a procurement differentiator. Larger organisations are asking suppliers about patch management as part of due diligence. Having a documented process and evidence of it working is a concrete, verifiable answer to those questions.
The businesses that will struggle are those whose answer to “how do you handle critical vulnerabilities” is “we wait for our IT person to mention it.” That answer is losing contracts as procurement teams get more sophisticated about supply chain risk.
Making the Business Case for Faster Patch Management
Three points worth putting in front of decision-makers:
The window between disclosure and exploitation is now measured in days. CVE-2026-42945 was exploited within days of public disclosure. The old assumption that businesses have weeks to assess and patch critical vulnerabilities is no longer accurate. Your patch process needs to match the actual threat timeline, not a theoretical one.
Unpatched critical vulnerabilities are a GDPR liability. If customer or employee data is exposed through a known, patchable vulnerability, the ICO’s position is unambiguous: failure to implement appropriate technical measures is a breach of Article 32. The defence “we hadn’t got round to it” does not hold. The fine calculation starts with the data at risk, not with the technical sophistication of the attacker.
The cost of patching is fixed. The cost of breach is unbounded. Emergency incident response, legal notification obligations, regulatory investigation, reputational damage: these are not theoretical costs. They are costs that businesses of all sizes have paid. The comparison with the cost of a maintenance window is not close.
What to Do Before the End of This Week
1. Establish whether your infrastructure runs NGINX. Contact your hosting provider or MSP today. Ask them directly: does any component of our web infrastructure run NGINX, and if so, which version? Expect a response within hours, not days. If they cannot answer that question quickly, escalate.
2. Confirm patching status and timeline. The patched version is above 1.30.0. If your infrastructure is on an affected version, get a confirmed date for the patch. “We’ll look at it” is not an acceptable answer for a CVSS 9.2 vulnerability with confirmed active exploitation.
3. Review logs for indicators of compromise. If you have access to NGINX access and error logs, look for anomalous patterns from the last week, particularly unusual request volumes, unexpected 5xx errors, or worker process restarts. If you do not have access to your own server logs, that is a separate conversation to have with your MSP.
4. Check your WordPress plugin inventory. Log into your WordPress admin dashboard. Go to Plugins and filter for those that are out of date. Update everything. The Peugeot Music plugin is unlikely to be in your install, but the broader pattern of unpatched WordPress plugins is a real and ongoing risk. If you do not recognise a plugin, investigate before dismissing it.
5. Ask your MSP for written confirmation of patching. Not a verbal assurance. A written record noting the version patched to and the date. Keep it. If something goes wrong later, the difference between “we asked and they confirmed in writing” and “we assumed they’d handled it” is significant in any regulatory or legal context.