Join our Newsletter — 33% off our NHI Course

Is CVE-2025-54068 (Laravel Livewire Code Injection) being exploited in the wild?

Yes. CISA added CVE-2025-54068 to its Known Exploited Vulnerabilities catalogue on 20 March 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Laravel Livewire contain a code injection vulnerability that could allow unauthenticated attackers to achieve remote command execution in specific scenarios.

What it means for a Laravel Livewire code injection to be exploited in the wild

Yes, it means this is no longer just a theoretical flaw. For defenders, the key question shifts from “is there a bug?” to “is this service exposed, and can an attacker reach the vulnerable code path before we mitigate it?” CISA’s KEV listing is the practical signal that exploitation has moved past lab proof-of-concept into operational attacker use.

When a code injection issue is being used actively, the security impact is usually broader than the initial flaw description. Unauthenticated remote command execution can convert a web application bug into full server compromise, application data access, and potential pivot points into adjacent systems that share the same host, secrets, or trust boundary.

For a live exploitation question, the material detail is not just the CVE label itself but the operational posture it creates: exposed instances, public reachability, and delayed remediation are what turn a code injection path into an incident. Treat the KEV status as a triage trigger, not as a historical note.

See the CISA Known Exploited Vulnerabilities Catalog for the authoritative exploitation signal, and use the CVE Program and NIST National Vulnerability Database to anchor version and record details to your own environment.

What to do first when exploitation is confirmed

Confirm whether any internet-facing Laravel Livewire deployment is present, then identify every environment where the component is reachable through production, staging, or customer-facing front ends. A confirmed KEV listing means exposure should be assumed high priority even if you have not yet observed alerts, because active exploitation often outpaces local detection.

Apply the vendor’s mitigation or fix as the primary action, and do not treat compensating controls as equivalent unless you can show they block the specific injection path. If patching must wait, reduce reachability immediately: isolate the service, restrict external access, and place the application behind stronger edge filtering while you work the permanent remediation.

Use the Zero-Day and Exploited Vulnerabilities Guide as the operational model for KEV-driven triage, and pair it with the Vulnerability Management Guide for prioritisation, exception handling, and post-remediation verification.

Do not wait for a broad maintenance window if the system is reachable and business-critical. For actively exploited issues, the right sequencing is exposure reduction first, verification second, and business scheduling third.

How to check for compromise and decide whether rotation is needed

Look for signs that the vulnerable application or host has been used as an execution point, not only for generic web logs. Review process creation, unexpected command activity, outbound connections, new files, modified application code, web shells, and any unusual child processes associated with the web server account.

Because unauthenticated command execution can expose local secrets and runtime tokens, assess whether credentials, session material, or service account access may have been reachable from the compromised process context. If the application host stored API keys, database credentials, signing material, or cloud tokens in files or environment variables, assume those should be reviewed and rotated based on exposure scope.

Use the State of NHI & AI Agent Breach Report 2026 as a reminder that attacker value often lies in what the initial flaw exposes next, not just in the first command executed. In the same way, a Livewire injection may be the entry point to wider secret exposure if the host carried reusable credentials.

Risk and Threat Considerations

Actively exploited code injection is dangerous because it gives attackers a direct path from external reachability to code execution. Once that path is confirmed in the wild, the main risks are rapid compromise, secret exposure, and follow-on lateral movement from a trusted server into adjacent systems.

Failure mechanism: An attacker sends crafted input that reaches the vulnerable Livewire code path, causing the application to execute attacker-controlled commands or payloads with the privileges of the web process.

Impact: The server can be turned into an execution foothold for data theft, service disruption, persistence, and further movement into connected infrastructure, especially where the application has access to stored secrets or internal networks.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
CIS Controls v8 CIS-7 — Continuous Vulnerability Management Active exploitation makes rapid identification and remediation of exposed systems central.
Recommendation — Prioritise and remediate the exposed Livewire deployment immediately.
NIST CSF 2.0 ID.RA-01 — Asset vulnerabilities are identified and documented A KEV-listed CVE requires confirming where the vulnerable software is deployed and exposed.
RS.MA-01 — Mitigation is performed Confirmed in-the-wild exploitation demands immediate containment and remediation action.
Recommendation — Inventory every Livewire deployment and confirm exposure before remediation. Apply the vendor fix or compensating mitigation as soon as possible.
NIST SP 800-53 Rev 5 SI-2 — Flaw Remediation This is a flaw-remediation case driven by confirmed active exploitation.
Recommendation — Remediate the vulnerable component promptly and verify the fix.
MITRE ATT&CK T1190 — Exploit Public-Facing Application The issue is exploited through a reachable web application vulnerability.
Recommendation — Hunt public-facing Livewire exposure for exploitation activity.

Practitioner Guidance

What to prioritise: Prioritise externally reachable instances, production environments, and any deployment that exposes Livewire functionality to unauthenticated traffic. A local fix that leaves the application public is usually not enough if exploitation is already active.

What to verify: Verify whether the affected host has run unexpected commands, spawned unusual child processes, or made outbound connections that do not fit normal application behaviour. If those signals exist, treat the problem as potential compromise, not just vulnerability exposure.

Decision rule: If the service can be reached from outside and patching cannot happen immediately, reduce exposure first and then investigate for compromise. If evidence of execution exists, move straight to containment, credential review, and host reconstruction decisions rather than simple patch-and-forget remediation.

Practitioner takeaway: For an actively exploited injection flaw, the operational question is whether the application has already become a trusted execution point for an attacker. Once that is possible, remediation must include exposure control and compromise assessment, not just code repair.