CVE-2025-54068

What it actually does

Livewire v3 through v3.6.3 can incorrectly hydrate certain component property updates, allowing a specially crafted unauthenticated Livewire request to reach unsafe server-side behavior in specific component configurations. When exploitable components are mounted, an attacker can achieve remote command execution in the context of the PHP/Laravel application process, with potential access to application files, environment variables, database credentials, queues, cache backends, and any permissions granted to the web server user. The issue is unique to Livewire v3 and is fixed in Livewire v3.6.4 and in the upstream commit ef04be759da41b14d2d129e670533180a44987dc.

Why it matters to the business

This is a critical internet-facing application risk because exploitation can give an unauthenticated attacker direct code execution on a Laravel server. Successful compromise may lead to website takeover, theft of secrets from .env files, database access using application credentials, malware or web shell deployment, lateral movement, service disruption, and data exfiltration. The vulnerability is listed in CISA KEV with a remediation due date of 2026-04-03, has very high EPSS probability, and is reported as actively exploited in the wild, including activity associated with an Interlock ransomware campaign, so exposed applications should be treated as urgent even though exploitation depends on specific Livewire component configuration.

How an attack unfolds

An attacker first identifies Laravel applications using Livewire v3 by probing common Livewire routes and front-end assets. They then enumerate mounted components and send crafted unauthenticated POST requests to Livewire update/message endpoints that manipulate component property hydration data. If the application has a component configured in the vulnerable pattern, the malicious property update is processed server-side and can be transformed into command execution under the PHP worker or web server account. After initial execution, attackers commonly run discovery commands, read Laravel configuration and .env secrets, test outbound connectivity, download additional payloads, deploy web shells or persistence mechanisms, and use application credentials to access databases, object storage, mail systems, or internal services. In active campaigns, post-exploitation may include credential theft, data staging, encryption tooling, or hands-on-keyboard lateral movement.

How to fix it

Upgrade Livewire v3 to version 3.6.4 or later immediately. For Composer-based Laravel projects, update the livewire/livewire package and regenerate the lockfile as appropriate, then redeploy from a trusted build pipeline. The upstream fixed Git commit is ef04be759da41b14d2d129e670533180a44987dc. Prior major versions of Livewire are not affected by this issue, but applications on Livewire v3 up to and including v3.6.3 should be considered vulnerable if they expose mounted components in the affected configuration. There are no known reliable workarounds; network filtering can reduce exposure but should not be treated as a substitute for upgrading. After patching, rotate credentials that may have been exposed through the Laravel runtime, especially .env secrets, database passwords, API keys, mail credentials, queue/cache credentials, and cloud tokens if exploitation cannot be ruled out. Remove unexpected PHP files, rebuild application containers or hosts from trusted images where compromise is suspected, and invalidate application caches after deployment.

How to confirm the fix worked

Confirm the deployed package version is Livewire 3.6.4 or later by checking composer.lock, running composer show livewire/livewire, or validating the deployed vendor package against the fixed release or commit ef04be759da41b14d2d129e670533180a44987dc. Verify that no production deployment is still using Livewire v3.6.3 or earlier. Confirm exposed web routes still function after the upgrade and that Livewire endpoints are not returning server errors from incompatible cached code. Clear Laravel and framework caches after deployment using the organization’s standard release process. Validate exposure by reviewing application routes and internet-facing access to Livewire endpoints; Livewire endpoints may still exist after patching, so the key validation is fixed package version rather than endpoint absence. If exploitation is suspected, validate system integrity by comparing deployed code to known-good artifacts, checking file modification times, reviewing outbound network activity, and confirming no unexpected PHP files, cron entries, supervisor jobs, queue workers, or startup scripts were added.

Typical attack path

1. Scan the internet or target estate for Laravel applications exposing Livewire routes or assets.
2. Fingerprint Livewire v3 usage and identify applications that may be running versions up to and including v3.6.3.
3. Probe unauthenticated Livewire component update endpoints such as update/message routes.
4. Craft malicious component property update payloads that abuse the vulnerable hydration behavior.
5. Trigger server-side execution in the context of the Laravel/PHP application process when a susceptible mounted component is present.
6. Run reconnaissance commands and read application configuration, especially Laravel .env secrets and Composer package metadata.
7. Establish persistence using web shells, scheduled tasks, modified PHP files, or downloaded tooling.
8. Use stolen credentials or application trust to access databases, queues, cloud services, internal APIs, or other systems.
9. Exfiltrate data, deploy additional malware, or conduct ransomware-related follow-on activity where applicable.

How to detect it

Review historical web access logs for unauthenticated POST requests to Livewire endpoints, especially bursts of requests, unusual user agents, high error rates, large JSON bodies, or requests followed by 500 errors. Correlate those requests with Laravel application logs under storage/logs, PHP-FPM logs, Nginx/Apache error logs, container logs, and EDR process telemetry. Strong exploitation signals include the web server or PHP-FPM process spawning shells or utilities such as sh, bash, curl, wget, python, perl, php -r, base64, chmod, chattr, crontab, or openssl; unexpected outbound connections from the application server; and new or modified PHP files in public web-accessible directories. Inspect Laravel .env access patterns, suspicious reads of composer.lock, unusual cache/session files, and changes to public/, storage/, bootstrap/cache/, vendor/, and temporary directories. Search for web shells, obfuscated PHP, recently modified files, new cron entries, altered supervisor/systemd units, unauthorized SSH keys, and abnormal queue jobs. For campaign-oriented hunting, review for post-exploitation behavior consistent with ransomware intrusion chains: credential dumping, remote access tooling, discovery commands, archive creation, data staging, and lateral movement after Livewire endpoint activity. Because normal Livewire traffic also uses these endpoints, detections should correlate endpoint access with malformed payloads, unauthenticated sources, process creation, filesystem changes, and outbound network activity.

• POST /livewire/update
• POST /livewire/message/
• /livewire/livewire.js
• "snapshot"
• "updates"
• "calls"
• "memo"
• "checksum"
• storage/logs/laravel.log
• storage/logs/laravel-
• /.env
• composer.lock
• vendor/livewire/livewire
• public/storage/
• bootstrap/cache/
• php-fpm: pool
• www-data
• apache2
• nginx
• /bin/sh -c
• /bin/bash -c
• php -r
• curl http
• curl https
• wget http
• wget https
• base64 -d
• chmod +x
• crontab -l
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Immediately inventory Laravel applications using livewire/livewire and prioritize internet-facing Livewire v3 deployments.
• Upgrade all affected deployments to Livewire 3.6.4 or later; use the fixed upstream commit ef04be759da41b14d2d129e670533180a44987dc as a verification reference where source builds are used.
• Treat Livewire v3.6.3 and earlier as high-priority remediation targets because the vulnerability is in CISA KEV, has very high EPSS, and is actively exploited in the wild.
• If patching cannot be completed immediately, restrict unauthenticated access to Livewire endpoints using WAF, reverse proxy, VPN, allowlisting, or emergency route controls where business functionality permits; do not rely on this as a long-term workaround.
• Hunt for exploitation in web access logs, Laravel logs, PHP-FPM logs, web server error logs, EDR telemetry, process execution events, and outbound network logs dating back at least to the public disclosure date and preferably farther for high-value systems.
• Look for suspicious POST activity to Livewire endpoints followed by PHP child processes spawning shell utilities, network download tools, or interpreters.
• Rotate Laravel application secrets and connected service credentials if there is evidence of exploitation or if logging is insufficient to exclude compromise.
• Rebuild compromised or suspicious application hosts/containers from trusted images rather than only deleting visible artifacts.
• Add SIEM detections for anomalous unauthenticated Livewire POST volume, malformed Livewire payloads, and web server processes executing operating system commands.
• Brief incident response teams on the reported Interlock ransomware campaign context and prepare containment actions for any confirmed exploitation.