Livewire v3 RCE Vulnerability (CVE-2025-54068) - 130,000 Apps at Risk

On 17 July 2025, a critical remote code execution vulnerability was disclosed in Livewire v3, one of the most widely used packages in the Laravel ecosystem. Tracked as CVE-2025-54068 and carrying a CVSS v4.0 score of 9.2 (Critical), this vulnerability affects every Livewire installation from version 3.0.0-beta.1 through 3.6.3. According to BuiltWith, there are more than 130,000 public-facing applications running Livewire, and community surveys suggest it is used in over 30% of new Laravel projects.

If you use Livewire v3 in any capacity, you need to update to version 3.6.4 immediately. There is no workaround.

What Is the Vulnerability?

The flaw sits in Livewire's hydration mechanism - the process responsible for synchronising component state between the client (browser) and the server on every request. When a Livewire component is rendered, its state is serialised and sent to the frontend along with a checksum. On subsequent requests, the server verifies that checksum before restoring the component's state, ensuring nothing has been tampered with in transit.

CVE-2025-54068 breaks this protection entirely. The vulnerability exists in the hydrateForUpdate method within Livewire's HandleComponents class. During property update hydration, the method calls the standard hydrate function on client-supplied data without adequate validation or sanitisation. This means a specially crafted update payload can bypass the checksum verification and trick the server into interpreting untrusted input as executable PHP code.

The vulnerability is classified as CWE-94: Improper Control of Generation of Code (Code Injection). In practical terms, an attacker can send a malicious request to any exposed Livewire endpoint and achieve full remote command execution on the server.

Why This Is Particularly Dangerous

Several factors make this vulnerability especially severe:

No authentication required. The attacker does not need valid credentials or any form of session. Any publicly accessible Livewire component is a potential entry point.

No user interaction needed. There is no requirement for a user to click a link, open an email, or perform any action. The attack can be fully automated.

No APP_KEY required. Livewire normally protects its component state with a checksum signed using the application's APP_KEY. This vulnerability bypasses that requirement entirely. Even applications with properly secured keys are exposed.

Exploitation tooling already exists. Security researchers at Synacktiv, who discovered the vulnerability, have published a tool called Livepyre that automates exploitation. It identifies the Livewire version, locates accessible snapshots, and attempts to exploit the vulnerability automatically. This dramatically lowers the barrier for attackers.

The combination of these factors - unauthenticated, interaction-free, key-independent, and with public exploit tooling - makes this one of the most serious Laravel ecosystem vulnerabilities we have seen.

Which Versions Are Affected?

Every release of Livewire v3 from 3.0.0-beta.1 through 3.6.3 is vulnerable. The vulnerability is unique to the v3 architecture and does not affect Livewire v1 or v2. The architectural changes introduced in v3 to improve performance and developer experience inadvertently created this security gap in the property hydration mechanism.

The fix was released in Livewire v3.6.4, which introduces a new hydratePropertyUpdate() method with proper validation of synthetic tuples and safe handling of nested property updates.

The APP_KEY Problem Remains

While CVE-2025-54068 has been patched, the researchers also identified a broader design concern. If an attacker obtains your application's APP_KEY, they can still achieve remote code execution through Livewire's snapshot mechanism. The Livewire team considers APP_KEY exposure to be outside the framework's security boundary, but given how frequently keys are leaked - as we covered last month, over 260,000 Laravel APP_KEYs have been found on public GitHub repositories - this is a real and present risk.

This reinforces something we keep saying: protect your APP_KEY as if your entire application depends on it, because it does. Never commit .env files to version control. Rotate keys if there is any possibility of exposure. Use a secrets manager in production.

How to Check and Fix

First, check whether you are running a vulnerable version:

composer show livewire/livewire

If the version shown is anything from 3.0.0-beta.1 to 3.6.3, you need to update:

composer update livewire/livewire

Verify the update was applied by running the show command again and confirming you are on 3.6.4 or later. Then review your composer.lock file to ensure no dependency conflicts have prevented the update.

Beyond the immediate fix, there are additional steps worth taking:

Audit your Livewire components. Review which components are publicly accessible and whether any expose properties with loose typing. The researchers noted that components without strict type enforcement on parameters are particularly susceptible to type juggling attacks.

Check your logs. Look for unusual POST requests to Livewire endpoints containing malformed or suspicious payloads. Pay attention to requests with encoded or obfuscated data targeting /livewire/ routes.

Consider a WAF rule. If you cannot update immediately, implementing a web application firewall rule to inspect and block suspicious requests to Livewire endpoints can provide a temporary layer of protection. This is not a substitute for patching, but it buys time.

Disable exposed components. If you have Livewire components that are publicly accessible but not essential, consider temporarily restricting access until the patch is applied.

The Bigger Picture

This vulnerability is a clear example of something we have written about before: keeping your software updated is not optional, and it is not something you can defer indefinitely.

When people think about Laravel security, they often think about the framework itself. But your application's attack surface extends to every package in your composer.json. Livewire, Filament, Sanctum, Passport, Socialite - each of these is code running on your server, handling user input, and making security-critical decisions. A vulnerability in any one of them can compromise your entire application.

The Laravel ecosystem moves quickly. That is one of its strengths. But it also means the maintenance burden is real. Running composer update regularly, subscribing to security advisories for your key packages, and having a process for responding to critical disclosures are not nice-to-haves. They are basic operational requirements for any production Laravel application.

We run composer audit as part of our CI pipeline on every project. When a critical advisory like this drops, we know within hours which client applications are affected and can begin patching immediately. If you do not have something similar in place, CVE-2025-54068 is a good reason to set it up.

What to Do Right Now

If you use Livewire v3, update to v3.6.4 today. Not this week. Not when you get around to it. Today. The exploit tooling is public, the vulnerability requires no authentication, and there are 130,000 potential targets. Attackers will be scanning for unpatched installations.

If you are unsure whether your Laravel applications are fully patched across the ecosystem, or if you need help establishing a maintenance and patching workflow, get in touch. Keeping your stack secure is what we do.