CVE-2026-23524: Laravel Reverb RCE Vulnerability

CVE-2026-23524 Overview

CVE-2026-23524 is a critical insecure deserialization vulnerability affecting Laravel Reverb, a real-time WebSocket communication backend for Laravel applications. In versions 1.6.3 and below, Reverb passes data from the Redis channel directly into PHP's unserialize() function without restricting which classes can be instantiated, leaving users vulnerable to Remote Code Execution (RCE).

Critical Impact

This vulnerability allows unauthenticated attackers to achieve remote code execution on affected Laravel Reverb instances when horizontal scaling is enabled, potentially leading to complete system compromise.

Affected Products

• Laravel Reverb versions 1.6.3 and below
• Laravel applications with horizontal scaling enabled (REVERB_SCALING_ENABLED=true)
• Environments using Redis servers without authentication

Discovery Timeline

• 2026-01-21 - CVE-2026-23524 published to NVD
• 2026-01-21 - Last updated in NVD database

Technical Details for CVE-2026-23524

Vulnerability Analysis

This vulnerability is classified as CWE-502 (Deserialization of Untrusted Data). The flaw exists in the PusherPubSubIncomingMessageHandler component, which processes messages received from Redis pub/sub channels. When horizontal scaling is enabled, Laravel Reverb uses Redis to synchronize state across multiple Reverb nodes. The vulnerable code path passes untrusted data directly to PHP's unserialize() function without implementing an allowlist of permitted classes.

PHP object injection through insecure deserialization is particularly dangerous because attackers can craft serialized objects that trigger arbitrary code execution when instantiated. This is achieved by abusing "magic methods" such as __wakeup(), __destruct(), or __toString() in existing classes within the application's codebase (known as "gadget chains").

The exploitability is significantly increased by the fact that Redis servers are commonly deployed without authentication. An attacker with network access to an unprotected Redis instance can inject malicious serialized payloads that will be processed by Reverb, leading to arbitrary code execution with the privileges of the PHP process.

Root Cause

The root cause is the unrestricted use of PHP's unserialize() function on data received from Redis channels. PHP's unserialize() function accepts an optional allowed_classes parameter that restricts which classes can be instantiated during deserialization. The vulnerable code did not specify this parameter, allowing any class available in the application's autoloader to be instantiated with attacker-controlled properties.

Attack Vector

The attack requires network access to the Redis server used by Laravel Reverb for horizontal scaling. The attack flow is as follows:

1. Attacker identifies a Laravel Reverb deployment with horizontal scaling enabled
2. Attacker gains access to the Redis server (often unauthenticated on internal networks)
3. Attacker publishes a malicious serialized PHP object to the Reverb pub/sub channel
4. Reverb processes the message and calls unserialize() on the attacker-controlled payload
5. PHP magic methods execute during object instantiation, achieving code execution

namespace Laravel\Reverb\Protocols\Pusher;

+use Laravel\Reverb\Application;
use Laravel\Reverb\Protocols\Pusher\Contracts\ChannelManager;
+use Laravel\Reverb\Protocols\Pusher\MetricType;
+use Laravel\Reverb\Protocols\Pusher\PendingMetric;
use Laravel\Reverb\Servers\Reverb\Contracts\PubSubIncomingMessageHandler;

class PusherPubSubIncomingMessageHandler implements PubSubIncomingMessageHandler

Source: GitHub Commit Details

The patch adds explicit class imports, indicating the fix implements an allowlist of permitted classes (Application, MetricType, PendingMetric) that can be deserialized, preventing arbitrary object injection.

Detection Methods for CVE-2026-23524

Indicators of Compromise

• Unusual serialized PHP objects appearing in Redis pub/sub channels used by Reverb
• Unexpected process spawning from PHP/Laravel application processes
• Modified files or new files created by the web server user
• Outbound network connections from the application server to unknown destinations
• Redis commands publishing to Reverb channels from unexpected source IPs

Detection Strategies

• Monitor Redis pub/sub activity for messages containing serialized PHP objects with unexpected class names
• Implement network segmentation monitoring to detect unauthorized access to Redis servers
• Deploy file integrity monitoring on application directories to detect post-exploitation activity
• Enable PHP error logging to capture deserialization warnings or fatal errors
• Use application-level logging to track incoming Reverb messages and their sources

Monitoring Recommendations

• Configure Redis to log all client connections and commands for forensic analysis
• Implement network-level monitoring for connections to Redis ports (default 6379) from unexpected sources
• Deploy SentinelOne agents on Laravel application servers to detect and prevent post-exploitation behaviors
• Set up alerts for process execution anomalies originating from PHP worker processes

How to Mitigate CVE-2026-23524

Immediate Actions Required

• Upgrade Laravel Reverb to version 1.7.0 or later immediately
• If immediate upgrade is not possible, set REVERB_SCALING_ENABLED=false in your environment configuration
• Ensure Redis servers require strong password authentication
• Verify Redis is only accessible via private network or local loopback interface
• Review Redis access logs for any suspicious activity prior to patching

Patch Information

Laravel has released version 1.7.0 which addresses this vulnerability by implementing an allowlist of permitted classes for the unserialize() function. The fix is available in GitHub Release v1.7.0. The specific commit addressing this issue can be reviewed at the GitHub Commit Details.

For additional details, see the GitHub Security Advisory.

Workarounds

• Set REVERB_SCALING_ENABLED=false in your .env file if your environment uses only one Reverb node
• Configure Redis to require authentication by setting requirepass directive
• Bind Redis to 127.0.0.1 or a private network interface only
• Implement network firewall rules to restrict Redis access to authorized application servers only
• Consider using Redis ACLs (Redis 6.0+) to limit which commands and channels are accessible

# Configuration example
# Disable horizontal scaling in Laravel Reverb (workaround)
echo "REVERB_SCALING_ENABLED=false" >> .env

# Configure Redis authentication (redis.conf)
# requirepass your_strong_password_here

# Bind Redis to localhost only (redis.conf)
# bind 127.0.0.1

# Firewall rule to restrict Redis access (iptables example)
iptables -A INPUT -p tcp --dport 6379 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP