Four Updates, Two Security Labels, and a Check That Could Only Report Clean

redis, nginx, BoringSSL and the AdGuard Home fork all moved on 21 August. Two of the four upstream releases were labelled security, and neither label described this deployment: the redis fixes need a TCP or TLS listener that is not open here, and the AdGuard advisory is a dnsproxy one this fork had already answered on 31 July, eighteen days before it published. The item that did apply was named in neither headline, a Go toolchain bump answered by rebuilding rather than merging, and the one code change worth taking could not be copied as written: upstream echoes the client's raw EDNS buffer size and this resolver clamps it to 1,232 bytes on purpose. Found along the way, the update checker's Go row was never a measurement at all.

The update checker's Go row read go 1.26.5 · current, and it was not a measurement. The watcher that reports which upstreams have moved runs from a systemd timer, and that timer's PATH does not contain /usr/local/go/bin. Its go version call resolved to nothing, so the check was skipped rather than failed, and the row kept whatever an earlier interactive run had left behind. Go had been at 1.26.6 since 13 August. A second fault sat beside it: the marker for which upstream release had been reviewed read the newest local v*.*.* git tag, and those tags arrive from upstream on an ordinary fetch, so fetching alone would have declared a release reviewed before anyone had read it. Neither cost anything this time, and neither was found by the check. Both were found while updating. The Go probe now tries absolute paths before falling back to the PATH, and upstream's tags are kept under upstream-v*, separate from the fork's own.

Four components moved on 21 August: redis 8.10.0 to 8.10.1, nginx 1.31.3 to 1.31.4, nginx's copy of BoringSSL from 0.20260803.0 to 0.20260813.0, and the AdGuard Home fork from v0.107.78-edge to v0.107.79-edge. Two of those upstream releases were labelled security. A label is a claim about upstream's code, not about a deployment, and it took reading to find out which claim applied here.

redis 8.10.1 lists nine security fixes. Among them: CVE-2026-62356, a miscalculated buffer size in CMSketch RDB loading that can write past the end of the heap; an out-of-range SLOT_INFO slot id in a malicious RDB payload, which upstream describes as possibly leading to remote code execution; and a TLS client-certificate authentication bypass, where a Common Name containing an embedded NUL byte is truncated and lets a client authenticate as a different, possibly privileged, ACL user. On this box redis runs with port 0 and a unix socket with group-restricted permissions, and ss -lntp shows no redis listener at all. The certificate bypass has no listener to reach, and the RDB paths are not fed by anything remote. The update was taken the same day because it was cheap, not because there was an exposure to close. The reusable part is the gate rather than the patch: the build refuses to proceed unless the tarball from download.redis.io matches the digest published in the redis-hashes repository. Two different origins is the only reason that check is worth anything.

nginx and BoringSSL were one rebuild. nginx 1.31.4 is not a security release; the security fixes were in 1.31.3. It carries three QUIC commits and none of them is ours: our report of an Initial CRYPTO deadlock is still open as nginx/nginx#1616, and the one-line fix proposed for it, #1617, is open and unmerged, both re-checked at 22:08 on 22 August. Two BoringSSL changes were checked before the rebuild rather than discovered after it. SSL_GROUP_X25519_KYBER768_DRAFT00 was removed in the new tag, and this site offers X25519MLKEM768:X25519:prime256v1:secp384r1, which never referenced it. BORINGSSL_API_VERSION went from 42 to 43, and the ECH patch applied to a fresh 1.31.4 tree with one hunk offset by two lines. Measured at 22:27 that evening, the running master process had been started at 18:34 while the service unit had not restarted since 11 August: the binary was replaced under a live socket.

The AdGuard Home advisory was not ours to fix. GHSA-w6v6-f44j-3rj2, published 18 August, is a dnsproxy advisory: a client opens the highest-numbered unidirectional QUIC stream, stream-ID semantics implicitly open all 65,535 below it, and dnsproxy never reads or cancels them, so receive-stream state stays pinned for the life of the connection. This fork has capped that number since 24 May, at 64 rather than 65,535, and since 31 July it refuses unidirectional streams outright on DoQ, which reads none, with a separate configuration for the HTTP/3 control and QPACK streams that DoH3 does need. That was a review of upstream's own dnsproxy v0.83.1, taken three days after it shipped and eighteen days before the advisory published. It was not an independent find, and there was nothing left to port.

The security item that did apply was the toolchain, which no release note leads with. The binary in production had been built with Go 1.26.5, and Go 1.26.6, released 13 August, carries security fixes to the go command and to crypto/tls, encoding/asn1, encoding/xml, html/template, net, net/http and net/url. The answer was a rebuild, not a merge. Read back from the preserved binaries: the build replaced at 18:47 reports go1.26.5, the one that replaced it reports go1.26.6, and a second rebuild at 20:44 the same evening moved the deployed binary to Go 1.27.0, released 19 August, which is what it reports now.

The one code change taken could not be copied as written. Upstream closed issue #8183: responses the server generates itself, meaning blocked answers, NXDOMAIN, REFUSED, SERVFAIL and NODATA, did not echo the request's EDNS(0) state, which breaks systemd-resolved. Upstream's fix echoes the client's advertised buffer size unchanged. This stack clamps that number to 1,232 bytes, both for the buffer it honours and for the point at which it truncates, because amplification floods advertise large buffers on purpose. Echoing the raw value would have advertised a size this resolver never honours, on exactly the responses that are cheapest for a reflector to trigger, so the fork echoes the smaller of the two instead. Its own test fails against upstream's version on that number. Measured on the resolver:

$ dig @127.0.0.1 +dnssec doubleclick.net A
; EDNS: version: 0, flags: do; udp: 1232

$ dig @127.0.0.1 +dnssec +bufsize=10000 doubleclick.net A
; EDNS: version: 0, flags: do; udp: 1232

$ dig @127.0.0.1 +noedns doubleclick.net A
(no OPT PSEUDOSECTION)

The DO bit and the buffer size come back on a generated answer, the clamp holds against a client asking for 10,000 bytes, and a request that carried no OPT record still gets a reply with none, as RFC 6891 requires. Two security labels on the day, and neither described what actually needed doing: one names code this deployment does not expose, the other names code this fork had already replaced in May and again in July. What needed doing was a rebuild against a newer compiler, and a one-line upstream fix that had to be rewritten before it could be taken. That is the case for reading releases instead of merging them.

Highlights