Livewire: Authorization bypass in #[Authorize] via reordered parameter keys and #[Json] execution orderGHSA-mhf7-xp6r-6qrc
MEDIUMFix: livewire/livewire@822a4faGHSA-mhf7-xp6r-6qrc is a medium-severity (CVSS 6.5) vulnerability in livewire/livewire. A fix is available for livewire/livewire — see the affected versions and patch details below.
Real-World Exposure
livewire/livewireReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Three issues allowed actions protected by the #[Authorize] attribute to run against records the current user is not authorized for:
- Out-of-order parameter keys on actions.
#[Authorize]resolved a model parameter by its array key, while the action itself received parameters positionally. A request sending params as an object with reordered integer keys (e.g.{"1": 2, "0": 1}) could pass authorization with a record the user owns while the action received a different record. With#[Authorize('delete', 'comment')]ondeleteComment(Comment $comment), a user could delete another user's comment. - The same issue on event listeners. Methods using both
#[On]and#[Authorize]with a model parameter were affected in the same way through the__dispatchcall. #[Json]methods ran before authorization. When a method had both#[Json]and#[Authorize], the method body executed before the authorization check. The response was still a 403, but any side effects (such as database writes) had already happened.
Only applications using the #[Authorize] attribute are affected: on methods that take model parameters (issues 1 and 2), or on #[Json] methods (issue 3). Authorization performed inside the method (e.g. $this->authorize(...)) is not affected. Livewire 3.x is not affected.
Patches
Fixed in v4.4.8. Call and event parameters must now be a list or use named (string) keys, otherwise the request is rejected, and #[Json] methods are authorized before they run.
Workarounds
Upgrade to v4.4.8. If you can't upgrade right away, call $this->authorize(...) inside affected methods instead of relying on the #[Authorize] attribute.
Credits
Reported by Yousef Aman (@yousef-aman).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | livewire/livewire | ≥ 4.3.0&&< 4.4.8 | 4.4.8composer require livewire/livewire:^4.4.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for livewire/livewire, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update livewire/livewire to 4.4.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mhf7-xp6r-6qrc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-mhf7-xp6r-6qrc in your dependencies?
Find it across Packagist, including transitive dependencies.