Livewire Authorization Bypass Lets Users Act on Records They Don't Own

What Happened

Three related issues were found in how Livewire's #[Authorize] attribute enforces authorization: 1. Out-of-order parameter keys on actions: #[Authorize] resolved a model parameter by its array key, while the underlying action received parameters positionally. A request could send parameters as an object with reordered integer keys (for example, {"1": 2, "0": 1}), causing the authorization check to pass against a record the user owns while the actual action executed against a different record. For example, with #[Authorize('delete', 'comment')] on a deleteComment(Comment $comment) method, a user could delete another user's comment. 2. The same flaw affected event listeners that combine #[On] and #[Authorize] with a model parameter, exploitable through the internal __dispatch call. 3. #[Json] methods ran before authorization: when a method had both #[Json] and #[Authorize], the method body executed before the authorization check occurred. The HTTP response still returned a 403, but any side effects of the method body (such as database writes) had already taken place.

Technical Cause

The root cause is a mismatch between how #[Authorize] resolves model parameters (by array key) and how the underlying action or listener consumes parameters (positionally). This mismatch can be exploited by sending parameters with reordered integer keys. Separately, methods annotated with #[Json] executed their body before the #[Authorize] check ran, meaning authorization was effectively checked too late to prevent side effects. Applications that perform authorization manually inside the method body (e.g., via $this->authorize(...)) rather than relying on the #[Authorize] attribute are not affected. Livewire 3.x is also not affected.

Why It Matters

Any Livewire application that uses the #[Authorize] attribute on methods taking model parameters, or on #[Json] methods, may allow an authenticated user to perform unauthorized actions against another user's data — including destructive actions like deletion — despite the authorization check appearing to succeed. Because this requires only a low level of privilege and no user interaction from the victim, it is straightforward for an authenticated attacker to exploit once they understand the request structure.

Affected Versions

livewire/livewire versions from 4.3.0 up to (but not including) 4.4.8 are affected. Livewire 3.x is explicitly stated as not affected. The issue is fixed in version 4.4.8.

Fixes and Mitigation

The vendor has released version 4.4.8, which fixes all three issues: call and event parameters must now be provided as a list or with named (string) keys, otherwise the request is rejected, and #[Json] methods are now authorized before their body executes. If upgrading immediately is not possible, applications can mitigate by calling $this->authorize(...) explicitly inside affected methods instead of relying solely on the #[Authorize] attribute.

Recommended Action

Upgrade livewire/livewire to version 4.4.8 or later as soon as possible. If you cannot upgrade immediately, review all methods using the #[Authorize] attribute with model parameters or #[Json], and add explicit $this->authorize(...) calls as a temporary mitigation.