Magic Tricks or Dark Arts? RCE in Laravel MagicLink

We all love magic links. Users hate passwords, and developers hate managing them. cesargb/laravel-magiclink is a popular solution for this, allowing you to generate a URL that, when clicked, performs an action—usually logging a user in. It’s elegant, simple, and ostensibly secure. But as with all things in security, the devil is in the implementation details.

Under the hood, this package wasn't just storing a token and a user ID. It was storing an Action. When you generate a magic link, the package serializes a PHP object representing what that link should do and stuffs it into the database. When the user clicks the link, the application fetches that blob, wakes it up, and executes it.

This architecture relies on a fatal assumption: that the database is a sanctuary where data is immutable and trustworthy. But in the real world, databases are messy places. SQL Injection exists. Disgruntled employees exist. Leaked credentials exist. By treating the database as a trusted source for serialized objects, the developers inadvertently built a remote control for your server that anyone with write access to the magic_links table could pick up.

The root cause here is CWE-502: Deserialization of Untrusted Data. If you're new to this, think of PHP serialization as freezing an object. You take a complex data structure—with all its properties and logic—and freeze it into a string of text. unserialize() is the microwave that thaws it back out into a living, breathing object.

The problem arises when you thaw out something you didn't freeze. If an attacker can replace the frozen lasagna in your freezer with a frozen bomb, your microwave is going to have a bad time. In PHP, this is achieved via "gadget chains." These are sequences of code in existing classes (like those in Laravel or Monolog) that trigger when an object is destructed or woken up.

In laravel-magiclink versions prior to 2.25.1, the code essentially did this:

// Fetch the row from the DB
$action_data = $magicLinkRow->action;
 
// Blindly trust it
$action = unserialize($action_data);
 
// Run it
$action->run();

There was no digital signature. No HMAC. No validation. The code assumed that if the data was in the database, it must be safe. This effectively upgrades any vulnerability that allows database writes (like a limited SQL injection) into full-blown Remote Code Execution.

Let's look at the vulnerable logic found in src/MagicLink.php and src/Actions/ResponseAction.php. The vulnerability was incredibly straightforward—a direct call to unserialize on a database column.

The Vulnerable Code (Simplified):

public function getActionAttribute($value)
{
    // 💀 DANGER ZONE
    return unserialize($value);
}

This is the coding equivalent of leaving your front door unlocked because you live in a "gated community." The fix implemented in version 2.25.1 introduces a sanity check. They didn't just stop using serialization (which would be a breaking change); they wrapped it in a layer of cryptography.

The Fix (v2.25.1):

The maintainers introduced a Serializable class that handles signing. Now, when data is stored, it is hashed with the application's APP_KEY using HMAC.

// Verifying the data integrity before unserializing
if (! hash_equals($signature, hash_hmac('sha256', $payload, $secret))) {
    throw new InvalidSignatureException();
}
 
// Also adding allowed_classes to restrict what can be instantiated
return unserialize($payload, ['allowed_classes' => $allowed]);

By checking the signature, the application ensures that the data in the database was created by the application itself. If an attacker manually updates the row via SQLi, they won't know the APP_KEY to generate the correct signature, and the exploit fails.

How does a hacker actually pull this off? It requires a prerequisite: Write access to the magic_links table. This changes the CVSS vector slightly (PR:L), but don't let that lower your guard. A SQL Injection vulnerability anywhere in the app often gives read/write access to the whole DB.

The Attack Chain:

1. Recon: The attacker identifies that the target is using cesargb/laravel-magiclink and finds a way to modify the database (SQLi or perhaps a compromised internal tool).
2. Weaponization: Using a tool like PHPGGC (PHP Generic Gadget Chains), the attacker generates a malicious serialized object. Since the target is a Laravel app, chains like Laravel/RCE5 or Monolog/RCE1 are prime candidates.

   ./phpggc Laravel/RCE5 "system('id')" --base64

3. Injection: The attacker updates a valid magic link record, replacing the legitimate action blob with their malicious payload.

   UPDATE magic_links 
   SET action = 'O:40:"Illuminate\\Broadcasting\\PendingBroadcast":...' 
   WHERE id = 123;

4. Trigger: The attacker simply visits the URL associated with that magic link ID.
5. Detonation: The application fetches the row, calls unserialize(), the gadget chain fires, and the server executes system('id').

So, why is this an 8.8 High severity and not a critical 10? Solely because of the prerequisite: you need to touch the database first. However, in the context of modern web exploitation, this is a massive escalation vector.

Imagine you find a low-impact SQL injection that only lets you update a profile table, or you have credentials for a dashboard with limited permissions. Without this vulnerability, you are an annoyance. With this vulnerability, you are a God.

Once code execution is achieved, the attacker can:

• Read the .env file (stealing AWS keys, database passwords, and app secrets).
• Dump the entire user database.
• Install a persistent backdoor or webshell.
• Pivot to other servers in the internal network.

It turns a data-tampering issue into a total system compromise. The "Magic Link" becomes a portal to hell.

The remediation is simple: Update immediately.

Run the following in your terminal:

composer require cesargb/laravel-magiclink:^2.25.1

If you cannot update for some reason (legacy entanglements, fear of breaking changes), you are in a tight spot. You could theoretically write a database trigger that prevents updates to the action column, but that's a fragile band-aid.

Post-Patch Verification: After updating, existing magic links generated with the old version might become invalid because they lack the cryptographic signature required by the new version. You may need to clear out old links or regenerate them. It's a small price to pay for not getting owned.

Audit Strategy: Check your database logs. If you see mysterious UPDATE queries targeting the magic_links table that didn't originate from the application's standard flow, you might already have a visitor.