CVE-2017-9841 lets anyone on the internet run code through a developer testing file that should never have been public. It was fixed in 2016, CISA lists it as exploited, and botnets still scan for it. Here's what it means for your business.
Some of the most dangerous files on a website's server aren't part of the website at all. They belong to tools the developers used to build and test it, copied to the live server by accident and left where anyone on the internet can reach them.
A flaw known as CVE-2017-9841 is the best-known example. It affects PHPUnit, the standard tool PHP developers use to test their code automatically. One small file inside older copies of PHPUnit would run whatever instructions it received from a web visitor. On a website where that file can be reached from a browser, an attacker needs just one request to run their own code on your server. They don't need a password or an account, and nothing needs to be wrong with your website's own code.
The flaw was fixed in November 2016. Nearly ten years later, it still matters, because exposed copies keep turning up and automated attack tools still look for them.
A developer's tool left open on the live website
Modern PHP applications are built from many ready-made components, kept in a folder on the server alongside the application itself. Some of those components are needed to run the website. Others, like PHPUnit, are only meant for developers, on their own machines, while they build and test.
In 2015, PHPUnit added a small helper file designed to run code passed to it by another program on the developer's own computer. The mistake was in where it read that code from. When the file was reached through a web server, it took its instructions from the incoming web request instead. In effect, it became an open door that would carry out anything sent to it.
The US National Vulnerability Database (NVD) rates the flaw 9.8 out of 10, critical, and describes it being exploited through "a site with an exposed /vendor folder", the folder where those components live. The fix was released on 14 November 2016, and the flaw received its public identifier in June 2017.
For an attack to work, two things have to be true: an old, unfixed copy of PHPUnit is on the live server, and the server lets visitors reach the folder it sits in. The second condition is a set-up mistake rather than a flaw in PHPUnit, and it's what keeps this problem alive. Modern frameworks are designed to avoid it. Laravel's documentation, for example, warns that setting a site up the wrong way "will expose many sensitive configuration files to the public Internet."
Is it being exploited? Yes. The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2017-9841 to its catalogue of vulnerabilities known to be exploited on 15 February 2022. CISA lists its use in ransomware as "Unknown", meaning that hasn't been confirmed either way. In January 2024, CISA and the FBI published a joint advisory on malware called Androxgh0st, saying its operators "have been observed exploiting CVE-2017-9841" to run code on vulnerable websites.
What could go wrong for your business
Once an attacker can run code on your server, the website is only the start. Realistic consequences include:
- Stolen passwords and keys. The CISA and FBI advisory says the Androxgh0st botnet scans for Laravel sites and goes after files that hold passwords and API keys: the credentials your application uses to reach databases, payment providers, email services and cloud accounts. Those can open doors well beyond the website.
- Customer data exposure. Anything your application stores or can reach may be read or copied.
- Hidden access. Attackers can add their own files to the server so they can return later. CISA's advisory tells organisations to look for unrecognised PHP files for exactly this reason.
- Downtime and recovery costs. Investigating a compromise, rebuilding the server and changing every password and key takes time and money, usually under pressure.
- Reputation and compliance. If customer data or partner credentials are exposed, you may have to explain how a tool that was never meant to be on the live site let attackers in.
These are potential outcomes, not certainties. But because the attack needs no password, the gap between "exposed" and "compromised" can be very short.
Could your website be next?
Attackers don't need to know in advance which websites are affected. Botnets such as Androxgh0st scan automatically, checking the same well-known file location across large numbers of websites and sending their attack wherever it answers.
That means a website doesn't have to be famous or valuable to be found. A small business site, a forgotten campaign microsite or an internal tool that happens to be reachable from the internet looks the same to an automated scanner as a large company's site. If the file is there and reachable, the scanner can find it.
Nor does a quiet history mean safety. A site may have carried an exposed copy for years without anyone noticing, either because scanners haven't reached it yet or because they have and left no visible sign.
Most websites are not affected by this flaw. It only matters where an old copy of the tool has been deployed and its folder can be reached. But that combination is exactly what older, hand-deployed PHP applications are prone to, and the only way to know is to check.
Why legacy PHP applications deserve attention
The fix has been available since 2016. The problem is everything around it.
Old applications freeze their components. An application built in 2015 or 2016 often still carries the component versions it was built with. Nobody updates a testing tool on a system that "just works", so the vulnerable copy goes along with every deployment.
Developer tools end up on the live server. Many older deployments simply upload the whole project, exactly as it was on the developer's laptop, including tools that never belonged in production.
Hosting shapes the risk. On many shared hosting plans, older PHP applications were squeezed into a single public folder, which can give every component a public web address.
Nobody owns it. In a system that has outlived its original developers, it's rarely anyone's job to ask what is actually sitting on the live server. This flaw became public in 2017, was added to CISA's catalogue in 2022 and was named in a joint advisory in 2024. On a well-maintained system, it would have been dealt with long before any of that.
None of this is unique to PHP. Any platform, Node.js included, can leak development tools or private folders to the web if it's deployed carelessly. What makes older PHP applications stand out is the combination of years-old components, manual deployment habits and hosting set-ups that are hard to change.
What this means for your organisation
An exposed testing tool is rarely an isolated mistake. It usually points to a deployment process that nobody designed and nobody reviews. If your business runs an older PHP application, it's worth asking:
- Does anyone know exactly what is on the live server, and which versions?
- Is the way the site is deployed documented and repeatable, or does it depend on one person's habits?
- If credentials had been exposed, would you know, and could you change them all quickly?
- Who is responsible for reviewing the application's components on a regular schedule?
If those questions are hard to answer, that's useful information in itself. Understanding how your application is built, deployed and hosted is the first step towards deciding whether it needs tidying up, upgrading or replacing.
Recommended next step
Don't wait for an automated scanner to discover what's on your server before you do. Our free Legacy PHP assessment reviews your PHP version, hosting set-up, deployment process and the components your application ships with, so you can see whether tools like this may be exposed and where else your application may be at risk.
Afterwards, our team can talk through what the findings mean for you. For some applications, a cleaner deployment and an upgrade are enough. For others, a planned move to a modern Node.js stack, with build processes designed to ship only what the live site needs, may be the better long-term path, depending on the application and your business goals. No stack is secure by default; what matters is making the safe deployment the normal one.
Free Legacy PHP Risk Assessment
Not sure what's sitting in your vendor/ folder, or whether the internet can see it? We'll review your PHP version, hosting setup, deployment process and dependencies, and tell you plainly where you're exposed and what your options are, whether that's a quick fix, an upgrade or a migration.
