Every Laravel application depends on a secret key. When that key leaks, older Laravel websites and many products built on Laravel can be taken over remotely, and researchers have found hundreds of thousands of leaked keys. Here's what it means for your business.
Many business applications are built with Laravel, a popular framework for building websites and web applications in PHP. Every Laravel application relies on one secret setting, called the application key. It works a little like the master key to a building: Laravel uses it to lock and seal the small pieces of data, known as cookies, that your website hands to visitors' browsers, so it can tell later whether anyone has tampered with them.
As long as that key stays secret, the system works well. But if someone outside your company learns it, they can create data your website will trust without question. On older versions of Laravel, and on some products built with Laravel, that can be enough for an attacker to run their own instructions on your server. They need no password, no login and no phishing email. Just one line of text that should never have left the building.
For a business, that can mean losing control of the system that holds your customer records, orders and payments.
How a leaked key becomes a takeover
The original weakness was recorded in 2018 as CVE-2018-15133, a public identifier for a known security flaw. It affects Laravel versions released up to mid-2018, and Laravel described its fix at the time as a security release and an immediate upgrade for all users. The official description of the flaw included a reassuring caveat: the attacker must know the application key, "which normally would never occur".
That caveat made the problem look minor for years. Research has since shown that leaked keys are far more common than anyone assumed.
Keys leak in ordinary ways. A developer commits the settings file to a code-sharing site such as GitHub. A backup is left somewhere public. A former contractor keeps a copy. A website's server is set up so that its settings file, usually named .env, can be downloaded by anyone who asks for it. Or a product bought from a marketplace ships with the same default key for every customer, and nobody changes it.
Once an attacker has the key, they can disguise a harmful instruction as an ordinary, correctly sealed piece of data. An older Laravel application checks the seal, finds it genuine, and then unpacks the contents in a way that can lead to the attacker's instructions running on the server.
The problem did not end with the 2018 fix. Researchers at the French security firm Synacktiv have described three products built on Laravel, the invoicing tools Invoice Ninja and Crater Invoice and the asset-management tool Snipe-IT, where similar weaknesses were found years later and given their own identifiers. In two of them, default keys published in the product's own code made things worse.
What could go wrong for your business
If an attacker can run their own instructions on your server, the realistic consequences are serious:
- Data exposure. Customer details, order histories, invoices and anything else the application can reach could be copied.
- Stolen credentials. The same settings file that holds the application key often holds database passwords, email credentials and payment or cloud service keys. GitGuardian, a company that monitors GitHub for exposed secrets, found that about 35% of the leaked Laravel keys it saw coincided with other secrets.
- Downtime and recovery costs. A compromised server may need to be taken offline, investigated and rebuilt, and every credential it held replaced.
- Loss of trust. Customers and partners judge a business by how it handles their data, and explaining a breach is never easy.
There is also a direct financial signal. In IBM's Cost of a Data Breach Report 2026, "mismanaged secrets and keys" was named first among the leading factors that pushed up breach costs for organisations in the Middle East, where the average breach cost reached USD 8 million.
None of this means a breach is certain, but a leaked key makes one far more likely to succeed.
Could your website be next?
Attackers rarely sit down and choose a business to target. More often, they run automated tools that check large numbers of websites for known weaknesses, and they act on whatever they find. A website can be attacked simply because it is online and appears vulnerable, not because anyone has heard of the company behind it.
This particular weakness is a clear example. In January 2024, the US cybersecurity agency CISA and the FBI published a joint advisory on a malware strain called Androxgh0st. It scans the internet for Laravel websites with an exposed settings file, steals the credentials inside it, and, if it finds the application key, uses the 2018 flaw to take over the server. CISA added the flaw to its catalogue of vulnerabilities known to be exploited in the wild the same day, and as of 23 October 2026 it is still listed.
The research numbers show why automated scanning works:
- GitGuardian supplied 267,952 Laravel application keys found on GitHub between 2018 and 30 May 2025.
- In May 2025, Synacktiv still found 1,091 servers vulnerable to the original 2018 flaw.
- One default key, shipped with a point-of-sale product sold on an online marketplace, was in use on 1,650 servers.
That last figure matters for smaller businesses. If you bought a ready-made product and installed it as delivered, you may share a key with hundreds of other websites, and attackers already know which keys to try.
A website that has never had a security incident is not proof that the key is safe. A key that leaked years ago still works today unless someone has replaced it.
Why legacy PHP applications deserve attention
A leaked secret is a problem on any technology. What makes the older Laravel case worse is that a stolen key can lead to a complete takeover rather than just a forged login. And that risk is concentrated in ageing applications:
- Unsupported framework versions. Laravel gives each major release two years of security fixes. As of 23 October 2026, Laravel 10 and 11 no longer receive them, and anything older, including the versions affected by the 2018 flaw, receives no fixes at all.
- Bought-in products. Scripts from marketplaces, invoicing tools and admin panels often ship with a fixed key, and installers rarely replace it.
- Keys that never change. In older systems, the key is often set once, copied between test and live environments and shared with every agency or freelancer who has ever worked on the code. Changing it can log users out, so nobody does.
- Exposed settings files. Older or misconfigured hosting can leave the settings file downloadable, which is exactly what Androxgh0st looks for.
Each of these is a symptom of accumulated technical debt: an application that still works, but that nobody has had the time or budget to bring up to date. Well-maintained Laravel on a supported version is a very different proposition. The concern is the application that has quietly fallen behind.
What this means for your organisation
The important questions here are not technical ones. They are about knowledge and ownership:
Do you know every Laravel application your business runs, including products you bought rather than built?
- Do you know which version each one is on, and whether it still receives security fixes?
- Do you know who has had access to its secret key over the years, and whether it has ever been changed?
If the honest answer to any of these is "not sure", that is a reason to look more closely, not a reason to panic. Understanding the condition of your current application is also the foundation for any sensible decision about its future, whether that means updating it, replacing parts of it or modernising it entirely. It is far better to make that decision on your own timetable than after an incident has made it for you.
Recommended next step
Don't wait for a leaked key to show you where your risks are. Take our free Legacy PHP assessment to find out which of your applications run on unsupported Laravel versions, how their secrets are handled and where they may be exposed.
Then talk to our team about what the findings mean for you. For some applications, keeping Laravel on a supported version is the right answer. For others, a move to a modern stack such as Node.js may suit the application's requirements, architecture and business goals better. No technology removes the need for good security practice, but a well-maintained platform makes routine tasks such as changing secret keys far less disruptive.
Free Legacy PHP Risk Assessment
Not sure whether your keys have leaked, or which of your applications are on unsupported Laravel? We'll review your framework versions, hosting setup, secrets handling and dependencies, and tell you plainly where you're exposed and what your options are, whether that's a key rotation, an upgrade or a migration.
