Critical Livewire RCE Vulnerability (CVE-2025-54068): What You Need to Know

On March 13, 2026, a critical security advisory was published for Livewire, the reactive frontend framework used by over 130,000 Laravel applications. The vulnerability, tracked as CVE-2025-54068, carries a CVSS score of 9.2 (Critical) and allows unauthenticated remote code execution on any server running an affected version.

This is not a theoretical risk. A proof-of-concept exploit has been publicly released, and there are confirmed cases of active exploitation in the wild.

If you are running Livewire v3, you need to check your version and upgrade immediately.

What happened

Security researchers at Synacktiv discovered a flaw in Livewire's hydration mechanism — the system that serialises and deserialises component state between the browser and server on every request.

The vulnerability allows an attacker to smuggle synthesizers (internal Livewire objects that handle type casting and data transformation) through the updates field in Livewire's POST requests. By crafting a malicious payload, an attacker can inject arbitrary PHP objects into the deserialization pipeline, achieving full remote code execution.

The critical details:

• CVE: CVE-2025-54068
• CVSS Score: 9.2 (Critical)
• Attack Vector: Network (no authentication required)
• Affected Versions: v3.0.0-beta.1 through v3.6.3
• Fixed In: v3.6.4+
• Workaround: None available

Why this is so dangerous

Three factors make this vulnerability exceptionally severe:

1. No authentication required

The attacker does not need to be logged in, have an account, or even know anything about your application. Any publicly accessible Livewire endpoint can be targeted. Since Livewire registers its update route automatically, every Livewire v3 application exposes this attack surface by default.

2. Full server compromise

This is not a data leak or privilege escalation — it is arbitrary code execution. An attacker can:

• Read and exfiltrate your .env file (database credentials, API keys, encryption keys)
• Install backdoors and web shells
• Pivot to other services on your network
• Deploy cryptocurrency miners (confirmed in the wild)
• Encrypt your data for ransomware
• Modify your application code to inject malicious content served to your users

3. Massive attack surface

Livewire v3 has been downloaded millions of times and is used across 130,000+ applications. The public proof-of-concept means that any script kiddie can now scan the internet for vulnerable targets. Automated exploitation is likely already underway.

The ecosystem response

The severity of this vulnerability triggered an unprecedented response across the Laravel ecosystem:

• Laravel Cloud blocked deployments of applications running vulnerable Livewire versions, preventing teams from deploying new code until they upgraded
• Packagist flagged the affected versions as insecure, causing Composer to warn during install and update operations
• GitHub generated automated security advisories for repositories with vulnerable composer.lock files

This level of coordinated response is rare and reflects how seriously the Laravel community is treating this issue.

How to check if you're vulnerable

Run this command in your Laravel project:

composer show livewire/livewire

If the version shown is between v3.0.0-beta.1 and v3.6.3, you are vulnerable.

You can also check your composer.lock file directly:

grep -A 2 '"name": "livewire/livewire"' composer.lock

How to fix it

Upgrade Livewire to v3.6.4 or later:

composer require livewire/livewire:^3.6.4

Or update all dependencies:

composer update livewire/livewire

After upgrading, verify the fix:

composer show livewire/livewire | grep versions

Then deploy immediately. Every hour your application remains unpatched is an hour it's exposed to automated scanning and exploitation.

If you can't upgrade immediately

There is no workaround for this vulnerability. If you absolutely cannot upgrade right now:

1. Take the application offline until you can upgrade
2. Block all POST requests to /livewire/update at the web server or load balancer level (this will break all Livewire functionality but prevent exploitation)
3. Upgrade and redeploy as soon as possible

Checking for signs of compromise

If you were running a vulnerable version, you should check for signs that your server may have been compromised:

1. Check for unexpected processes: Look for cryptocurrency miners or reverse shells

   ps aux | grep -E "(xmrig|minerd|cryptonight|nc -e|bash -i)"
   

2. Check for new cron jobs: Attackers often install persistence via crontab

   crontab -l
   for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done
   

3. Check for modified files: Look for recently changed PHP files

   find /path/to/your/app -name "*.php" -mtime -7 -not -path "*/vendor/*"
   

4. Review your .env file: If compromised, rotate all credentials — database passwords, API keys, APP_KEY, mail credentials, and any third-party service tokens

5. Check your web server access logs: Look for POST requests to /livewire/update with unusually large payloads or from suspicious IPs

What this means for Laravel security

This vulnerability highlights several important truths about Laravel application security:

Dependencies are part of your attack surface

Your application's security is only as strong as its weakest dependency. Livewire is deeply integrated into most applications that use it — it handles form submissions, real-time updates, file uploads, and more. A vulnerability in Livewire is effectively a vulnerability in your application.

Internal dependency auditing is essential

This vulnerability cannot be detected from the outside. Tools like StackShield that perform external security monitoring — scanning your live application for misconfigurations, exposed debug tools, missing headers, and other externally visible issues — are a critical layer of defence. But dependency vulnerabilities like CVE-2025-54068 live inside your composer.lock file, invisible to external scanners.

That means you need both layers: external monitoring for what's visible to attackers, and internal tooling (composer audit, GitHub Dependabot, local-php-security-checker) for what's hidden inside your codebase.

Response time matters

Between the public disclosure and proof-of-concept release, the window for safe patching was narrow. Teams with automated dependency auditing in their CI/CD pipeline were patched within hours. Teams relying on manual composer update may still be vulnerable a week later.

Protecting your Laravel application

Dependency vulnerabilities like this one are just one part of your attack surface. While you need internal tools to catch insecure packages, your externally visible attack surface is just as important — and often overlooked.

StackShield focuses on the things an attacker can see from the outside:

• Debug mode detection: Is APP_DEBUG=true leaking stack traces and credentials?
• Exposed .env files: Can an attacker download your secrets directly?
• Missing security headers: Are you missing HSTS, CSP, X-Frame-Options?
• Exposed development tools: Are Telescope, Ignition, or Horizon accessible in production?
• SSL/TLS configuration: Are your certificates valid and properly configured?

These are the misconfigurations that attackers combine with vulnerabilities like CVE-2025-54068 to maximise damage. A compromised server with an exposed .env file means the attacker gets your database credentials, API keys, and encryption keys in seconds.

Run a free scan to check your external attack surface, and use composer audit to check your dependencies. The Laravel Security Checklist covers both internal and external security across 30 checks.

Timeline

Bottom line

If you use Livewire v3, upgrade to v3.6.4+ today. Not tomorrow, not next sprint — today.

This vulnerability is:

• Trivial to exploit (public PoC available)
• Devastating in impact (full RCE, no auth required)
• Actively being exploited in the wild
• Not mitigable without upgrading

Run composer require livewire/livewire:^3.6.4 and deploy. Then run composer audit to confirm you have no other vulnerable dependencies, and scan your external attack surface to make sure the rest of your application is locked down.