CVE-2019-11043 can let attackers take control of some older PHP servers. It was fixed in 2019, yet the US cybersecurity agency CISA still lists it as used in ransomware campaigns, and older PHP versions never received the fix. Here's what it means for your business.
Some security flaws fade away once they are fixed. CVE-2019-11043 hasn't. It is a flaw in PHP-FPM, the component that commonly runs PHP code for websites served by Nginx, a popular web server. It was fixed in October 2019, yet it remains on the US government's list of vulnerabilities known to be exploited, marked as used in ransomware campaigns.
The flaw only affects servers set up in a particular way, but that setup was common. It appeared in online tutorials, hosting templates and the default configuration of at least one popular open-source product. Servers built from those templates years ago, running a PHP version nobody has updated since, can still be exposed today.
For a business, ransomware is about as disruptive as an incident gets: systems locked, operations halted and difficult decisions made under pressure. That is why a seven-year-old flaw still deserves attention.
How a setup copied from tutorials left servers exposed
When someone visits a PHP website on Nginx, the work is split between two parts. Nginx receives the visitor's request and passes it on to PHP-FPM, which runs the website's code and sends back the page. Think of it as a front desk handing requests to a back office.
In 2019, security researchers found that a specially crafted request could confuse that hand-over on servers configured in a particular, widely used way. The back office received information it never expected, and that could corrupt its memory. With careful effort, an attacker could use that to make the server run instructions of their choosing. Security professionals call this remote code execution: someone on the internet running their own commands on your server.
The PHP project released fixes on 24 October 2019. The US National Vulnerability Database rates the flaw 9.8 out of 10, which is critical. The same day, Nextcloud, an open-source file-sharing platform, warned its users that its own default Nginx configuration was also vulnerable. In November 2019, Nextcloud reported that a ransomware strain called NextCry had been used against Nextcloud servers through this flaw. It said only two private servers out of about 300,000 were known to be compromised, and that no ransom payments had been made.
The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalogue on 25 March 2022. As of 23 October 2026, the catalogue marks its use in ransomware campaigns as "Known". CISA doesn't say which groups used it.
What could go wrong for your business
If an attacker can run their own instructions on your web server, the realistic consequences include:
- Ransomware and downtime. Files and systems can be locked, taking your website and any connected services offline until they are restored.
- Data exposure. Customer records, orders and anything else the server can reach could be copied before anyone notices.
- A foothold for further attacks. A compromised server can be used to reach other systems, send spam or host malicious content under your name.
- Recovery costs and lost trust. Investigating, rebuilding and explaining an incident takes time and money, and customers may not wait.
The Nextcloud case is a useful reminder to keep perspective. Few servers were known to be hit, and no ransom was paid. The flaw is serious, but it is not a prediction that any particular business will be attacked. It is a reason to know whether your servers fit the pattern.
Could your website be next?
Attackers rarely start by choosing a company. More often, they use automated tools that scan large numbers of servers for known weaknesses and try them wherever they might work. A website can be targeted simply because it is online and appears vulnerable, regardless of the size or profile of the business behind it.
This flaw is well suited to that kind of scanning. The researchers who found it published working attack code in 2019, and it is still publicly available. Automated tools don't care how old a vulnerability is; they try known ones against every server they find. A seven-year-old flaw on an unpatched server is as usable today as it was in 2019.
Having had no problems so far is not proof of safety either. A server that was exposed when it was built stays exposed until someone updates it, whether or not anyone has tried the door yet.
Not every server running PHP with Nginx is affected. The flaw needs a specific combination of an older PHP version and a particular configuration. But that combination is exactly what an older, untouched server is likely to have.
Why legacy PHP applications deserve attention
The fix has been available for seven years. It still matters because of how ageing systems tend to be run:
- Copied settings stay in place. Server configurations are rarely written from scratch. They are copied from tutorials, templates and vendor guides, then left alone because they work.
- Old versions never got the fix. If an application was stuck on PHP 7.0 or PHP 5 in 2019, the PHP project shipped it no official fix, because both versions were already out of support. As of 23 October 2026, W3Techs reports that 26.9% of websites using PHP run PHP 7 and 7.7% run PHP 5. Every PHP 7 version is now past end of life, so the next serious flaw of this kind will find many of those sites in the same position.
- Hand-built servers age quietly. Many older PHP applications run on a server someone set up years ago, often a developer or agency who has since moved on. Without routine rebuilds, the server stays exactly as it was, flaws included.
None of this is a problem with PHP-FPM as it ships today. A current, supported PHP release on a sensibly configured server is a legitimate production setup. The exposure comes from what ageing systems tend to share: an out-of-support version, a configuration nobody owns, and nobody checking either.
What this means for your organisation
You don't need to understand server configuration to act on this. You do need clear answers to a few questions:
- Which of your websites and internal tools run on PHP, and on which servers?
- Which PHP version does each one run on, and is it still supported?
- Who set up those servers, and has anyone reviewed them since?
- Are there forgotten systems, such as old marketing sites, test copies or admin tools, that nobody actively looks after?
Forgotten servers are often the ones attackers find first. If the answers are unclear, that is a sign your systems need a closer look before an incident forces one. Understanding the real condition of your servers and applications is also the basis for any sensible decision about modernising them.
Recommended next step
Don't wait for a ransom note to find out whether an old server fits this pattern. Take our free Legacy PHP assessment to understand which PHP versions and server setups your business relies on, where older configurations may be leaving you exposed, and what it would take to bring them up to date.
Then speak to our team about the right path for each application. For some, a move to a supported PHP version is the sensible answer. For others, modernising on a stack such as Node.js, with servers rebuilt from documented, versioned settings so that fixes reach every environment, may better suit the application and your business goals. Every platform has its own security updates to keep up with; what matters is having a setup where keeping current is routine.
Free Legacy PHP Risk Assessment
Not sure whether any of your servers match this pattern? We'll review your PHP version, web server configuration, hosting setup and dependencies, and tell you plainly where you're exposed and what your options are, whether that's a patch, an upgrade or a migration.
