The Livewire v3 RCE That Broke the Magic: Understanding CVE-2025–54068

How a Reactive Framework’s Design Became Its Downfall

If you’ve built a Laravel application with Livewire, you know the appeal. Write server-side PHP components, bind them to the frontend, and let the framework handle synchronizing state between client and server. No API routes to manage. No tedious JSON payloads. No context switching between frontend and backend code. It’s the kind of developer experience that feels almost magical until something goes wrong.

In March 2026, something went very wrong.

CVE-2025–54068 exposed a critical remote code execution vulnerability in Livewire v3 (versions 3.0.0-beta.1 through 3.6.3) that allowed unauthenticated attackers to execute arbitrary PHP code on any vulnerable server. The vulnerability didn’t require knowledge of the application’s APP_KEY. It didn’t require authentication. It didn’t even require a valid session. A single HTTP POST request to a publicly accessible endpoint was all an attacker needed.

By March 20, 2026, the US Cybersecurity and Infrastructure Security Agency added CVE-2025–54068 to its Known Exploited Vulnerabilities catalog, with a mandatory patch deadline for federal agencies set to April 3, 2026. The inclusion on the KEV list meant one thing: active exploitation was already happening in the wild.

This article explains how the vulnerability works, why Livewire’s architecture made it possible and what developers need to understand to protect their applications.

The Hydration Architecture

To understand why this vulnerability exists, you first need to understand how Livewire works at its core.

Livewire is a full-stack reactive framework. When you define a Livewire component, you’re writing a PHP class that lives on the server. The component has public properties that represent state, and public methods that represent actions. When a user interacts with the UI (clicks a button, types in an input), Livewire sends that interaction to the server, the server updates the component’s state, and Livewire sends back an updated view to render on the client.

The mechanism that makes this work is called hydration.

Here’s the conceptual flow:

Initial page load: Server renders the component, serializes its state into JSON, embeds that JSON in the HTML as a data attribute.
User interaction: Client detects the interaction (a button click, form submission, etc.), creates an HTTP POST request to a Livewire endpoint, and includes the component’s current state as a JSON payload.
Server receives the request: Livewire reconstructs the component from that JSON payload (hydration), applies the requested method or property update, and generates a response.
Response: The server sends back the updated component state and any new HTML that needs to render.

This architecture is elegant. It keeps all the business logic on the server where PHP developers are comfortable, while creating a responsive frontend experience without building a separate API.

The hydration payload is where developers need to pay attention. Here’s a simplified example of what gets sent in an HTTP request:

{
  "fingerprint": "abc123def456",
  "serverMemo": {
    "name": "counter",
    "path": "components.counter"
  },
  "updates": [
    {
      "type": "callMethod",
      "payload": {
        "method": "increment",
        "params": []
      }
    }
  ]
}

That updates array is the vector for this vulnerability.

Where the Synthesizer Fits In

Livewire uses a system called the synthesizer to handle complex PHP types during hydration. Eloquent models, collections, enums, datetime objects and other structured types can’t be simply converted to JSON and back. They need custom serialization and deserialization logic.

The synthesizer’s job is to handle that conversion. When Livewire receives an update from the client, it inspects the data structure and determines which synthesizer to use to reconstruct the original PHP type. For example, if the client sends data marked as an Eloquent model, the ModelSynthesizer reconstructs that model. If it’s a collection, the CollectionSynthesizer handles it.

This is where the vulnerability lies.

Inside Livewire’s HandleComponents class, which processes incoming hydration requests, the framework accepts update payloads that can include what's called a "synthetic tuple". A synthetic tuple is a specially formatted array that tells Livewire which synthesizer to use to reconstruct a type.

Here’s what a simplified synthetic tuple looks like:

[
  "object" => "synthetic",
  "type" => "Model",
  "payload" => [
    "class" => "App\\Models\\User",
    "attributes" => [...]
  ]
]

The vulnerability exists because Livewire did not properly validate the type and payload fields before passing them to the synthesizer. An attacker could craft a synthetic tuple that tells Livewire to reconstruct any PHP object, not just the legitimate types that should be there.

PHP Deserialization and Gadget Chains

To exploit this vulnerability, you need to understand PHP deserialization and the concept of a gadget chain.

When PHP deserializes an object (converts serialized PHP code back into a live object), it calls that object’s __wakeup() method if it exists. When an object is garbage collected or explicitly destroyed, PHP calls its __destruct() method. Clever attackers can chain together these magic methods across multiple classes to achieve code execution.

A gadget chain is a sequence of existing PHP classes (already loaded in your application) whose magic methods, when triggered in a specific order, result in code execution. The attacker doesn’t write new code. They use code that’s already there. If your Laravel application has GuzzleHttp installed (and most do, since Laravel’s HTTP client uses Guzzle), you have a gadget chain available.

Specifically, the GuzzleHttp\Psr7\FnStream class has a __destruct() method that invokes a user-defined callback:

public function __destruct()
{
    if (isset($this->_fn_close)) {
        ($this->_fn_close)();  // This is where execution happens
    }
}

An attacker can create a serialized FnStream object that holds a reference to a callback function, embed that in a synthetic tuple, and when Livewire deserializes it and the object is destroyed, the callback executes.

Here’s a conceptual diagram of how the gadget chain works:

Attacker sends synthetic tuple with FnStream object
        |
        v
Livewire deserializes the object (no validation)
        |
        v
FnStream object is stored in memory
        |
        v
Request finishes, object goes out of scope
        |
        v
PHP garbage collection triggers __destruct()
        |
        v
__destruct() calls the attacker-controlled callback
        |
        v
Arbitrary code executes

In practice, the payload might use PHP’s call_user_func() or similar functions to execute arbitrary commands. By the time Livewire or Laravel processes the request normally, the damage is already done.

Why APP_KEY Didn’t Protect You

Laravel developers often rely on the APP_KEY environment variable to protect against exactly this kind of attack. When Laravel serializes sensitive data like session data, cookies or queue jobs, it encrypts or signs them with the APP_KEY. An attacker without the APP_KEY can’t forge a valid payload because Laravel will reject anything that doesn’t have a valid signature.

Livewire’s hydration endpoint was different. It accepted the JSON payload, passed it directly to the synthesizer system, and processed synthetic tuples before Laravel’s standard request validation and signature verification happened. The assumption was that data coming from the frontend was safe because it came from the browser. But the browser sends exactly what the attacker wants it to send.

This is a classic example of trusting the client. The data might have come from your legitimate frontend once, but Livewire had no way to verify that the current request still had a valid fingerprint, valid encryption or any other integrity check.

The Attack in Practice

An unauthenticated attacker needs only a few things:

The URL of your Livewire endpoint (usually something like /livewire/update or /livewire/message)
A component name (easily discovered by inspecting the HTML or checking error messages)
A crafted synthetic tuple containing a gadget chain

No login. No session. No APP_KEY. No prior knowledge of the application state.

Here’s what a simplified exploit payload looks like:

{
  "fingerprint": "doesnt_matter_much",
  "serverMemo": {
    "name": "any-component",
    "path": "any.component"
  },
  "updates": [
    {
      "type": "syncInput",
      "payload": {
        "name": "malicious_property",
        "value": {
          "object": "synthetic",
          "type": "GuzzleHttpFnStream",
          "payload": {
            "fn": [
              "system",
              "whoami > /tmp/pwned.txt"
            ]
          }
        }
      }
    }
  ]
}

When Livewire processes this, it tries to reconstruct the GuzzleHttpFnStream object. When the object is destroyed, the gadget chain activates, and system() executes the command.

The attacker can retrieve the output by making another request or by relying on side effects like writing files to the web root.

What CISA’s KEV Listing Means

When the US Cybersecurity and Infrastructure Security Agency adds a vulnerability to its Known Exploited Vulnerabilities catalog, it’s making a formal statement: this vulnerability is being actively exploited in the wild, and federal agencies must patch it by the deadline.

The March 2026 deadline of April 3, 2026 wasn’t arbitrary. CISA had evidence that attackers were already using this exploit against real systems. By late February or early March, security researchers (including the team at Synacktiv who discovered the vulnerability) had published technical details. Exploit code was public. The window between public disclosure and widespread exploitation had already closed.

For organizations running Livewire, the KEV listing was a wake-up call. This wasn’t a theoretical vulnerability. It was a critical, actively exploited flaw in a popular framework.

Checking Your Exposure

If you’re running Livewire v3, you can quickly check your version:

composer show livewire/livewire

If the version shown is anything from 3.0.0-beta.1 through 3.6.3, you are vulnerable.

The fix is straightforward:

composer update livewire/livewire

This will install Livewire 3.6.4 or later, which patches the vulnerability.

If you can’t update immediately, you can add middleware to your Laravel application to block requests to the Livewire endpoint, though this will break Livewire functionality for all users:

// routes/web.php or middleware
Route::post('/livewire/message', function () {
    return response('Service unavailable', 503);
});

A better approach is to restrict access by IP if you know which networks should be using your application. But the best approach is to update.

What Changed in 3.6.4

Livewire’s maintainers didn’t overhaul the synthesizer system. They added validation.

In version 3.6.4, before processing a synthetic tuple, Livewire now validates that the requested type is in an allowlist of legitimate synthesizers. If an attacker tries to use a synthetic tuple with a type that isn’t explicitly allowed (like GuzzleHttpFnStream), Livewire rejects it.

Here’s the conceptual change:

// Before 3.6.4 (vulnerable)
$type = $payload['type'];
$synthesizer = $this->getSynthesizer($type);  // accepts any string
$object = $synthesizer->hydrate($payload);

// After 3.6.4 (patched)
$type = $payload['type'];
$allowlist = ['Model', 'Collection', 'Enum', 'DateTime'];
if (!in_array($type, $allowlist)) {
    throw new Exception("Invalid synthetic type");
}
$synthesizer = $this->getSynthesizer($type);
$object = $synthesizer->hydrate($payload);

The patch is simple because the vulnerability’s root cause was simple: trusting unvalidated input from the client.

The Broader Lesson

CVE-2025–54068 teaches an important lesson about reactive frameworks and server-side processing of client-supplied data.

Livewire’s architecture is elegant because it moves complexity away from the frontend. But that elegance comes with a cost: the server must accept and process structured data from the browser. Any package or framework that does this creates a large attack surface.

If you’re evaluating a framework or library that accepts serialized or structured data from the client and processes it server-side, ask these questions:

Are all updates validated before processing? What validation happens?
Is there an allowlist of permitted types or operations?
What happens if someone sends unexpected data?
Is the payload encrypted or signed? If so, how is the key protected?
Can the attacker bypass validation by crafting specific payload structures?

For Livewire specifically, the patch means you can trust the synthesizer again, but developers should still think carefully about what data they’re storing in component properties and what operations are exposed to the frontend.

The vulnerability is fixed. The lesson remains.

Updating Your Applications

Here’s a practical checklist for teams managing multiple Laravel applications with Livewire:

Run composer outdated livewire/livewire across your fleet to identify which applications are vulnerable.
Prioritize updating applications that are publicly accessible or handle sensitive data.
Test the update in a staging environment first. Livewire 3.6.4 is a patch release and should be backwards compatible, but verify your specific components work as expected.
Update production in a controlled manner. If you’re running multiple instances, update one at a time and monitor for issues.
Monitor your application logs for suspicious requests to /livewire/update or similar endpoints. If you see requests with unusual payload structures, they may have been exploitation attempts before you patched.

Livewire is still a solid framework. This vulnerability doesn’t reflect a fundamental design flaw, but rather a gap in input validation that’s been fixed. Millions of Laravel developers continue to use Livewire successfully after the patch.

The magic of Livewire is real. But like all magic, it’s only impressive when the mechanics are sound.