On older Laravel applications, a developer setting left switched on let anyone on the internet run code on the server. The US government lists the flaw, CVE-2021-3129, as used in ransomware campaigns. Here's what that means for your business.
Every web application has a way of reporting its own errors. While it is being built, developers need detailed error pages that show exactly what went wrong. On a live website, those same pages can show the inner workings of your system, including passwords and keys, to anyone who manages to trigger an error.
For many businesses running older Laravel applications, the risk went much further. A single setting, left switched on by mistake, could let a stranger on the internet take control of the server without ever logging in. The flaw is tracked as CVE-2021-3129. A fix has existed since November 2020, yet as of 23 October 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) lists it as exploited, including in ransomware campaigns.
When a helpful error page becomes an open door
Laravel is a popular framework: a ready-made foundation that developers use to build web applications in PHP. Like most frameworks, it has a "debug mode" that shows detailed error information to help developers fix problems. Laravel's own documentation is clear that on a live website this setting "should always be false", and warns that otherwise "you risk exposing sensitive configuration values to your application's end users."
Between Laravel 6 and Laravel 8, those error pages came from a companion tool called Ignition. Ignition tried to be helpful. As well as showing errors, it offered one-click "solutions" for common developer mistakes. They only worked with debug mode on.
In November 2020, Charles Fol of the security firm Ambionics found that one of these solutions could be abused. It didn't properly check which file it was being asked to change, so an attacker could use it to read and rewrite files on the server, and from there run their own code. In plain terms, anyone on the internet who could reach that error page could make the server do what they wanted, without a username or password.
The researcher reported the problem along with a fix, and a corrected version of Ignition was published the next day. The US National Vulnerability Database rates the flaw 9.8 out of 10, which is critical.
Three things had to be true at once for an application to be exposed: it used an older version of Ignition, Ignition was present on the live server, and debug mode was switched on.
What could go wrong for your business
The ability to run code on someone else's server is about as serious as website flaws get. Where an attacker succeeds, the realistic consequences include:
- Exposure of customer and business data. Anything the application can reach, such as customer records, orders and internal documents, may be read or copied.
- Stolen passwords and keys. Even without this specific flaw, debug pages can reveal configuration values such as database passwords and the keys your application uses to connect to cloud, email and payment services. Those keys can open doors well beyond your website.
- Ransomware and downtime. CISA's catalogue marks this flaw as known to be used in ransomware campaigns. It doesn't name the groups involved. For a business, ransomware can mean systems locked, services offline and difficult decisions made under pressure. Recovery costs and lost trust. Investigating a break-in, rebuilding servers and telling customers all take time and money.
- Compliance concerns. Depending on your sector and the data you hold, a breach may bring reporting obligations and questions from regulators or partners.
Not every application with debug mode switched on has been compromised, and not every compromise leads to ransomware. But the possible outcomes are serious enough that "we think it's fine" is not a good enough answer.
Could your website be next?
Many business owners assume attackers choose their targets carefully, and that a mid-sized company or a low-profile website won't attract attention. That isn't how most attacks begin. Attackers use automated tools to scan very large numbers of websites for known flaws. They don't need to know who you are. If your site is reachable and shows the signs they are looking for, it can end up on their list.
This flaw shows how that works in practice. In January 2024, CISA published an advisory on Androxgh0st, a botnet (a network of compromised machines working together) that scans for Laravel websites to steal credentials. The advisory says one of its methods "appears to be used for websites in debug mode", and its first recommendation reads: "Ensure that any live Laravel applications are not in 'debug' or testing mode."
Debug mode also hides in plain sight. It is often switched on to chase a problem on the live site and never switched off again. Nothing breaks, so nobody notices. A clean record so far doesn't mean the setting is right, or that nobody will come looking.
None of this means your website is vulnerable. It means the answer depends on a few specific facts about your live servers, and someone should confirm them rather than assume.
Why legacy PHP applications deserve attention
The fix for this flaw has been available since November 2020. It still matters because of the way older applications age.
According to Laravel's support policy, security fixes ended for Laravel 7 on 3 March 2021, for Laravel 6 on 6 September 2022 and for Laravel 8 on 24 January 2023. Applications still on those versions receive no framework security fixes at all, and they usually hold on to old versions of the tools around them too.
That older code is still widely used. From Laravel 9, a rewritten error-page package replaced the original, and the original hasn't had a release since January 2023. Yet as of 23 October 2026, Packagist, the main registry for PHP packages, records about 511,000 downloads of it in the past month. Downloads don't show which versions are installed or whether debug mode is on, but they do show how much older Laravel code is still being built and deployed.
Older applications also carry habits from launch: developer tools left on the live server, settings nobody has reviewed since, and an original developer who has long since moved on.
This is not a criticism of Laravel or of PHP. Current Laravel, set up and deployed with care, is a well-maintained framework. The risk sits in ageing applications on unsupported versions that nobody is actively looking after.
What this means for your organisation
If your business runs a Laravel application, especially one built on Laravel 8 or earlier, a few questions deserve a clear answer:
- Which version of Laravel is it running, and does that version still receive security fixes?
- Is debug mode switched off on every live and publicly reachable server, including test or staging copies?
- Has debug mode ever been on in production, and if so, could passwords or keys have been exposed?
- Who is responsible for checking these things, and when did they last check?
If nobody can answer confidently, that is a finding in itself. A forgotten debug setting is rarely the only issue in an application that has drifted out of support. More often, it is a sign that the whole platform needs a closer look.
Understanding your application's current condition is the foundation for any sensible decision, whether that means tightening up what you have, upgrading in stages or moving to a new platform.
Recommended next step
Don't wait for a security incident to find out how your Laravel application is set up. Our free Legacy PHP assessment looks at the areas this flaw touches: your framework and PHP versions, how your live servers are configured, and the age of the packages your application depends on. The aim is a clear, plain-language picture of potential security concerns, maintenance challenges and modernisation opportunities.
From there, we're glad to talk through what we find and what your options are. For some applications, the right answer is to bring the existing system up to date. For others, a move to the modern Node.js stack, which Sketchmonk builds on, may be the better long-term path, depending on how the application is built and where your business is heading. No platform is secure by default, and Node.js applications need the same care with settings and dependencies. What matters is a foundation your team can keep current.
Understand your risk before an incident forces you to.
Free Legacy PHP Risk Assessment
Not sure how your Laravel application is configured in production? We'll review your framework and PHP versions, production settings, 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.
