Hacked Laravel Application: Where to Look

By Glenn Lyvers · Updated September 21, 2026 · 4 min read

Laravel itself has a good security record, and when a Laravel application is compromised the cause is almost never the framework. It is how the application was deployed and configured — a handful of specific, recurring mistakes that turn a well-built framework into an open door. Here is where to look, roughly in order of likelihood.

Debug mode in production

This is the most common serious mistake and it is worth checking before anything else. With debug enabled, an unhandled error renders a detailed diagnostic page showing stack traces, file paths, configuration values and, depending on the error, environment variables including database credentials and the application key.

Attackers trigger errors deliberately to harvest exactly that. Confirm debug is disabled in production, and if it was enabled, treat everything in your environment configuration as exposed and rotate all of it. My guide on exposed environment files covers what that rotation involves.

Exposed configuration and document root

Laravel expects your web server's document root to point at the public directory so that nothing above it is reachable by URL. When a site is deployed by pointing the domain at the project root instead, the environment file, your application code, your storage directory and your dependency manifests all become fetchable.

Check by requesting the environment file path directly. Check whether your storage and framework directories are reachable. And check whether version control metadata is exposed, since a fetchable repository directory can hand over your entire source history including credentials that were committed and later removed.

The application key

The application key encrypts and signs data, including session payloads and anything you encrypt yourself. If it leaked — through debug output, an exposed config file, or a committed repository — an attacker can potentially forge signed data rather than merely reading it.

That is a different order of problem from a leaked database password, because it undermines the integrity of things your application trusts. Regenerate it if there is any reasonable chance it was exposed, accepting that doing so invalidates existing encrypted values and sessions.

Queues, jobs and scheduled tasks

Laravel's queue and scheduler are the equivalent of the WordPress cron problem: legitimate mechanisms for running code on a schedule, ideal for persistence. Check what is scheduled and what is sitting in your queue tables or queue backend, and account for every job class you find.

A job whose class does not exist in your codebase, or whose payload contains something you did not put there, is a finding. Because queued payloads are serialized, an application that deserializes untrusted input has its own well-known risks worth reviewing. My guide on malicious scheduled tasks covers the same pattern in a different framework.

The rest of the sweep

Check for uploaded files in your public directory and storage, particularly anything executable. Check your routes for endpoints you did not write and your middleware for changes. Compare your codebase against version control, which on a properly managed Laravel project is the fastest integrity check available to you — a diff against a known-good commit tells you exactly what changed.

Check your dependencies too: an outdated package with a known vulnerability is a realistic entry point, and your lock file plus a vulnerability audit will tell you where you stand. Then check the database for injected content and unexpected admin users, and read your logs for the timeline.

Closing it out

Rotate everything in the environment: database password, application key, mail credentials, queue and cache credentials, and every third-party API key. Redeploy from a known-good commit rather than repairing the running code in place, which is the significant advantage a version-controlled application has over a typical CMS site.

Then fix the deployment: document root pointed at public, debug disabled, configuration cached, storage not web-reachable, and dependencies current. If the application handles customer or payment data and you want it properly assessed rather than assumed clean, that is work I take on — see the platforms I clean.

Common questions

Is Laravel itself insecure?

No. The framework has a good security record and compromises are overwhelmingly caused by deployment and configuration mistakes rather than framework flaws — debug mode left on in production, a document root pointed at the project instead of the public directory, or outdated dependencies.

Why is debug mode such a problem?

Because an unhandled error renders a detailed diagnostic page exposing stack traces, file paths, configuration and often environment variables including database credentials and the application key. Attackers trigger errors deliberately to collect that. Anything shown that way should be treated as public.

What happens if my application key leaked?

It undermines the integrity of signed and encrypted data, meaning an attacker may be able to forge values your application trusts rather than only read them. Regenerate it, accepting that existing encrypted data and sessions become invalid, which is disruptive but preferable to leaving a known key in use.

Where does persistence hide in a Laravel app?

The queue and the scheduler, most often — they run code on a schedule by design, which is exactly what persistence needs. Check scheduled tasks and queued jobs, and account for every job class. Also check routes and middleware for additions you did not write.

What is the fastest way to check a Laravel app for changes?

Diff the deployed code against a known-good commit in version control. That is the single biggest advantage a version-controlled application has over a typical CMS site: you can see exactly which files differ from what you intended to deploy, rather than inferring it.