Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-14T17:17:49.613Z",
  "pubdate": "2026-09-14T17:17:49.613Z",
  "executiveSummary": "Laravel MagicLink versions 2.0.0 through 2.25.1 are susceptible to an insecure deserialization vulnerability. The flaw originates from the application's practice of storing serialized action objects in the magic_links.action database column and subsequently unserializing them without adequate integrity verification.\nBy leveraging an insecure legacy unserialize() fallback within src/MagicLink.php and src/Actions/ResponseAction.php, an attacker capable of modifying database contents can inject a malicious serialized object graph.\nUpon visiting a crafted magic link, the application process triggers the deserialization of the compromised record, potentially leading to Remote Code Execution (RCE) via executable closure behavior. This vulnerability poses a severe risk, as it allows arbitrary code execution under the context of the application server. While the vulnerability requires a prerequisite vector to achieve database-write access—such as an existing SQL injection or compromised administrative credentials—the impact of successful exploitation is critical, as it bypasses application-level security controls.",
  "technicalDetails": "The vulnerability resides in the core handling of action objects within Laravel MagicLink. The application persists state by serializing PHP objects and storing them in the magic_links.action database column. The components responsible for processing these links, specifically src/MagicLink.php and src/Actions/ResponseAction.php, perform a retrieval and subsequent deserialization of this column data.\nThe primary root cause is the reliance on PHP's native unserialize() function, which inherently supports the instantiation of arbitrary object graphs from user-provided data without validation. The application maintains an unsafe legacy fallback mechanism that remains reachable, enabling an attacker to inject serialized payloads that include malicious gadget chains or closures. Because there is no cryptographic signature or integrity check protecting the serialized payload, the application blindly trusts the content of the database record.\nThe attack flow follows a structured path: First, an attacker must gain unauthorized write access to the database. This could be achieved through secondary vulnerabilities such as SQL injection (SQLi) or compromised administrative access. Second, the attacker injects a maliciously crafted serialized object into the magic_links.action column. This payload is designed to exploit PHP object injection mechanics, specifically targeting magic methods (e.g., __destruct, __wakeup) or utilizing closures that execute upon invocation during the deserialization lifecycle.\nThird, the attacker triggers the vulnerability by accessing the specifically manipulated magic link within the application. The application retrieves the malicious string from the database, passes it to the vulnerable unserialize() routine in either src/MagicLink.php or src/Actions/ResponseAction.php, and initiates the object reconstruction process. As the object graph is populated, the malicious code encapsulated in the payload is executed by the application process.\nThis vulnerability is particularly potent because it converts a database-level integrity compromise into full application-layer code execution. Since the code runs with the permissions of the web server process, the attacker can move laterally, exfiltrate sensitive data, or establish persistence. While the vulnerability does not independently provide database-write access, it serves as a critical escalation point in any attack chain where the database layer is exposed."
}