600+ Laravel Apps Exposed to RCE via Leaked APP_KEYs - Why Your .env File Is a Ticking Time Bomb

Research published by GitGuardian in collaboration with Synacktiv has revealed a staggering finding: over 260,000 Laravel APP_KEY values have been exposed on GitHub since 2018. More than 600 Laravel applications were confirmed to be trivially exploitable for remote code execution. If you work with Laravel, this should have your full attention.

What Is the APP_KEY and Why Does It Matter?

Every Laravel application generates a 32-byte encryption key during installation, stored as APP_KEY in the .env file. This key is central to how Laravel handles security. It encrypts and decrypts sensitive data, signs cookies and session tokens, generates secure random strings, and creates authentication tokens. If an attacker obtains your APP_KEY, they hold the master key to your application's cryptographic security. Everything Laravel encrypts or signs becomes compromised.

How a Leaked Key Becomes Remote Code Execution

The attack path from a leaked APP_KEY to full server compromise is well documented and, alarmingly, straightforward. Laravel's decrypt() function automatically deserialises decrypted data. PHP deserialisation vulnerabilities have been extensively catalogued, and tools like phpggc provide over 20 different gadget chains targeting Laravel versions from 5.1 through to 11.x. An attacker who has your APP_KEY can craft a malicious serialised payload, encrypt it with your key, and send it to your application as a cookie. When Laravel decrypts and deserialises that cookie, the payload executes arbitrary code on your server.

This is not theoretical. The vulnerability was first documented as CVE-2018-15133 in older Laravel versions, but the attack vector persists in newer versions when developers configure SESSION_DRIVER=cookie. More recent CVEs, including CVE-2024-55555 affecting Invoice Ninja and CVE-2024-48987 affecting Snipe-IT, demonstrate that this class of vulnerability keeps resurfacing in Laravel-based applications.

The Scale of the Problem

The numbers from the GitGuardian and Synacktiv collaboration are sobering. From data collected between 2018 and May 2025, researchers extracted approximately 260,000 APP_KEY values from public GitHub repositories. GitGuardian's monitoring identified over 10,000 unique APP_KEY values, with roughly 1,300 instances where both the APP_KEY and APP_URL were exposed together. That combination is particularly dangerous because it gives an attacker both the encryption key and the exact address of the target application.

Of those, 400 APP_KEY values were validated as still functional. Four production applications were confirmed to have trivially exploitable RCE vulnerabilities. Across the broader dataset, over 600 applications were confirmed vulnerable to remote code execution.

Perhaps the most concerning finding was that 63% of the exposed keys originated from .env files or variants like .env.production. And over a third of those exposures also leaked additional secrets, including database credentials, cloud storage tokens for AWS S3 and DigitalOcean Spaces, and payment processing keys for Stripe and PayPal. A single committed .env file can expose your entire infrastructure.

This Is Already Being Exploited in the Wild

This is not just a research exercise. The AndroxGh0st malware, which emerged in January 2024, actively scans the internet for Laravel applications with exposed .env files. Once it retrieves an APP_KEY, it exploits CVE-2018-15133 to gain remote code execution. CISA and the FBI issued a joint advisory about AndroxGh0st in early 2024, highlighting its use in building botnets from compromised Laravel servers.

The Synacktiv research, first presented at GreHack 2024 in November, also revealed a depressing trend around patching. In 2024, there were 44 publicly exposed Snipe-IT instances vulnerable to CVE-2024-48987. By 2025, despite a patch being available and a CVE assigned, that number had risen to 61. People are simply not applying updates.

Deleting the Commit Is Not Enough

One of the most important findings from this research is that removing an exposed key from a Git repository does not make you safe. The researchers found 50 compromised APP_KEY values that had been deleted from their GitHub repositories but remained valid in production. The developers noticed the exposure and removed the commit, but never actually rotated the key in their live application.

Git history is permanent by default. Even if you force-push to remove a commit, the key may have already been scraped, cached, or archived. If your APP_KEY has ever appeared in a public repository, you must treat it as compromised and rotate it immediately. Deletion alone is not remediation.

What You Should Do Right Now

Audit your repositories immediately. Search your Git history for any committed .env files. Tools like GitGuardian, TruffleHog, and gitleaks can scan your entire commit history for exposed secrets. Do not assume that because your .gitignore currently excludes .env that it was always excluded.

Rotate any exposed APP_KEY. If you find evidence that your APP_KEY has been committed to any repository, public or private, generate a new key with php artisan key:generate and deploy it to all environments. Be aware that rotating the key will invalidate any existing encrypted data, including active sessions and password reset tokens, so plan your rotation accordingly.

Ensure your .gitignore is correct. Every Laravel project should have .env, .env.*, and any environment-specific variants listed in .gitignore from the very first commit. If you are onboarding new developers or setting up CI/CD pipelines, verify that this is in place before anything else.

Never use default APP_KEY values. Some packages and self-hosted applications ship with a default APP_KEY in their .env.example file. If you copy this file to .env without regenerating the key, you are using a key that is publicly known. Always run php artisan key:generate after setting up a new Laravel project.

Avoid using cookie-based session storage. The SESSION_DRIVER=cookie setting is what makes the deserialisation attack trivial. Use database, redis, or file session drivers instead. This does not eliminate the risk of a leaked key entirely, but it removes the easiest attack vector.

Use a secrets manager for production credentials. Rather than relying solely on .env files, consider storing sensitive configuration in a dedicated secrets manager such as AWS Secrets Manager, HashiCorp Vault, or the encrypted environment variables available in deployment tools like Laravel Forge. This reduces the risk of accidental exposure and provides audit trails for access.

Add secret scanning to your CI pipeline. Make secret detection part of your automated build process. If a .env file or a raw key appears in a commit, the build should fail. This catches mistakes before they reach a remote repository.

The Broader Lesson

This research is a stark reminder of something we keep coming back to: security is not a feature you ship once. It is an ongoing discipline. The APP_KEY exposure problem is not a Laravel vulnerability in the traditional sense. Laravel's encryption implementation is sound. The problem is entirely about how developers handle secrets, and it is a problem that spans every framework and every language.

If you commit secrets to version control, you are creating a permanent record that attackers can and will find. If you discover an exposure and only delete the commit without rotating the credentials, you are leaving the door open. If you deploy applications with default keys, you have not locked the door at all.

As a team that builds and maintains Laravel applications for clients, we take this seriously. Every project we work on has secret scanning in the CI pipeline, environment files excluded from version control from day one, and key rotation procedures documented and tested. These are not optional extras. They are baseline requirements for any production application.

If you are unsure whether your Laravel application's APP_KEY has ever been exposed, now is the time to check. The tools are freely available, the process is straightforward, and the alternative is waiting to find out the hard way.