CVE-2026-61701 in laravel-magiclink
Summary
by MITRE • 09/14/2026
Laravel MagicLink creates links for authentication without a password or for accessing private content. From 2.0.0 until 2.25.1, MagicLink stores serialized action objects in the magic_links.action database column and deserializes them through src/MagicLink.php and src/Actions/ResponseAction.php without sufficient integrity protection, while an unsafe legacy unserialize() fallback remains reachable. An attacker who can manipulate database records, such as through a separate SQL injection or compromised administrative access, can insert a malicious serialized object graph containing executable closure behavior; visiting the associated magic link then deserializes the record and can execute arbitrary code in the application process. The affected path is restricted to manipulated action records and does not independently provide database-write access. This issue is fixed in version 2.25.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The Laravel MagicLink package facilitates authentication flows that allow users to access private content or authenticate without a traditional password by generating unique, time-limited links. A critical security vulnerability exists within versions ranging from 2.0.0 through 2.25.1 involving the handling of serialized action objects stored in the magic_links.action database column. The core technical flaw lies in the deserialization process executed via src/MagicLink.php and src/Actions/ResponseAction.php, which fails to implement sufficient integrity protection for these serialized payloads. This lack of cryptographic verification allows an attacker who has gained the ability to manipulate database records to inject maliciously crafted serialized data structures into the action column.
The severity of this vulnerability is compounded by the presence of an unsafe legacy unserialize() fallback mechanism that remains reachable during the deserialization process. When a user visits a magic link associated with a manipulated record, the application retrieves and processes the stored action object. Because there are no integrity checks such as digital signatures or message authentication codes to validate the authenticity of the serialized data before processing, the system blindly executes the contents of the payload. This architectural weakness enables an attacker who can insert malicious serialized objects containing executable closure behavior to achieve arbitrary code execution within the context of the application process.
The attack vector requires a prerequisite condition where the adversary possesses either administrative access to the database or exploits a separate vulnerability such as SQL injection that permits write operations against the magic_links table. It is important to note that this issue does not independently provide database-write capabilities; rather, it leverages existing unauthorized write access to escalate privileges and execute code remotely. The operational impact includes full compromise of the application server's runtime environment, potentially leading to data exfiltration, lateral movement within the network, or complete system takeover depending on the permissions granted to the web application process.
This vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, as well as CWE-749, related to Exposure of Dangerous Method for Security Misconfiguration in PHP applications using legacy unserialize functions. In terms of offensive security frameworks, this scenario maps to MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter sub-techniques, where the attacker uses serialized objects as a vehicle for executing arbitrary commands on the target system. The exploitation chain relies heavily on the initial access vector provided by database manipulation, highlighting the importance of defense-in-depth strategies that include input validation at multiple layers rather than relying solely on application-level security controls.
To mitigate this risk, organizations must immediately upgrade to version 2.25.1 or later, where the deserialization logic has been hardened and the unsafe legacy fallback is no longer reachable under normal operation conditions. For environments unable to patch immediately due to compatibility constraints, it is critical to ensure that database access controls are strictly enforced to prevent unauthorized write operations against application tables. Additionally implementing strict input validation on all data entering the system can reduce the attack surface for initial exploitation vectors like SQL injection. Security teams should also audit their use of PHP's unserialize function and consider migrating to safer serialization formats such as JSON or utilizing signed serialized payloads with integrity verification mechanisms provided by modern frameworks.