Redis 3.2.7 closes HTTP-shaped connections early

A Redis server bound to localhost can still receive traffic that originates in a web page. The browser on that computer can send an HTTP request to a local address, and parts of a specially constructed request can also look like Redis protocol. Redis 3.2.7 adds an early connection-closing rule to prevent the particular cross-protocol attack described in its release notes.

The 3.2 release notes date the release to 31 January and classify its urgency as high. The versioned notes emphasize both local development instances and Redis Cluster deployments. Those are different affected groups because the release combines the protocol protection with an expiration-preservation fix in cluster migration.

I like Redis's direct command model, but a local development server still has a protocol boundary. The relevant question is which processes can cause bytes to reach it. Restricting a listener to the local machine does not imply that every request reaching that listener was deliberately issued by the developer.

Recognizable HTTP input ends the connection

The release notes describe mapping POST and Host: to connection termination, preventing Redis from processing the remaining pipeline. POST can appear as an HTTP method, and Host: is an HTTP header. Treating them only as unknown Redis commands would leave later input available for interpretation.

The networking implementation supplies the concrete behavior in securityWarningCommand. It logs a warning about a possible cross-protocol attack and schedules the client for asynchronous freeing. Its comment explains that the connection must terminate because the remaining request can contain input Redis would otherwise process.

Logging is deliberately limited. The function retains the last logged time and emits the warning only when more than 60 seconds separate the relevant times. Its comment says this avoids a denial of service through excessive logs. Connection handling and warning emission therefore have different frequencies. The absence of another warning for every attempt does not mean the connection-closing rule has stopped applying.

The important part is terminating further interpretation on that connection. A response saying that the first token was invalid would not by itself establish that the rest of a pipeline cannot run. The release describes closing the connection specifically to avoid processing those pending commands.

This correction is a backport of behavior already present in the 4.0 beta and unstable branch. That history matters because users of the stable 3.2 line receive the protection without adopting the major-version candidate. The release notes distinguish the stable maintenance update from the feature development underway elsewhere.

Loopback and protected mode cover different conditions

The 3.2.7 configuration binds the supplied example to 127.0.0.1. Its comments explain that this accepts connections from the same computer. That is useful protection against direct access through other interfaces, but it leaves local processes able to reach the listener.

Protected mode is also enabled in the supplied file. The documented rule applies when no explicit bind addresses and no password are configured. Under those conditions, it limits accepted clients to loopback addresses and Unix-domain sockets. It addresses accidental network exposure, while the cross-protocol correction addresses the interpretation of input that reaches a connection.

The relevant defaults in the shipped configuration are:

bind 127.0.0.1
protected-mode yes
port 6379

These settings explain why the release announcement mentions laptops. A developer can intentionally run Redis only on loopback and still run a browser on the same machine. The browser's ability to contact a local service is part of the scenario described by the maintainers, so local binding alone does not answer it.

The notes also explicitly limit the protection. They say another cross-protocol method that does not involve POST or Host: may be possible. The change is one protective layer against a known request shape. It does not establish that arbitrary untrusted browser-originated traffic can never reach a Redis command through any other encoding.

I regard that limitation as useful precision. It identifies what the patch checks, which makes its effect understandable alongside listener configuration. The source does not claim to solve every possible interaction between a browser and a local database service.

Migration must carry expiration with the value

The release's cluster correction concerns MIGRATE with multiple keys. The notes say that migration could turn a key with an expiration into a persistent key. This bug was introduced with the multiple-key migration implementation and affects cluster users employing resharding.

This is a correctness problem even when the value itself arrives unchanged. An expiration determines how long a key belongs in the dataset. Preserving the bytes while losing the expiration changes application behavior, potentially retaining data after the time at which it should disappear.

The release notes make the affected operation specific. They do not say that all expiring keys become persistent during normal operation. The problem occurs on the described migration path. That distinction helps connect the upgrade's urgency to deployments that actively move data between cluster nodes.

Migration is an internal placement change from the application's perspective, so preserving expiration is part of preserving the key's meaning. A successful move needs to retain that metadata as well as its value. The correction makes resharding less likely to change the dataset's lifetime rules.

Compact list storage also receives a correction

Redis 3.2.7 fixes a ziplist insertion bug that the maintainers say can corrupt data or crash the server. They also identify possible security implications without claiming a demonstrated exploit. The notes call out LINSERT and other operations that manipulate the middle of a list as reasons to upgrade.

The same release updates the bundled jemalloc to 4.4.0. That allocator change is separate from the ziplist correction and from the HTTP-input rule. The high urgency reflects several concrete issues with different triggers. Local development instances gain early termination of recognizable HTTP-shaped connections, while cluster resharding preserves the expiration metadata attached to migrated keys.