Was Squidbleed tatsächlich preisgibt

Squidbleed, geführt als CVE-2026-47729, ist ein Heap-Puffer-Überlesefehler im Parser für FTP-Verzeichnislisten von Squid, einem der am weitesten verbreiteten Web-Proxys im Internet. Stellt Squid eine FTP-Liste dar, in der ein Dateiname fehlt, läuft eine Schleife, die Leerzeichen überspringt, einen Schritt zu weit und liest Speicher jenseits des vorgesehenen Puffers. Weil Squid freigegebenen Speicher zwischen Anfragen wiederverwendet, sind diese verirrten Bytes oft Bruchstücke des Verkehrs anderer Nutzer: Klartext-HTTP-Anfragen mit Passwörtern, Cookies, Sitzungstoken und API-Schlüsseln.

Die Gefährdung ist enger als bei Heartbleed, aber real. Ein Angreifer muss berechtigter Nutzer eines geteilten Proxys sein und einen FTP-Server kontrollieren, den der Proxy über Port 21 erreichen kann, was das Risiko auf Insider lenkt und auf jede Aufstellung, in der der Proxy TLS terminiert. Als undurchsichtiger Tunnel weitergereichter HTTPS-Verkehr bleibt versiegelt, auf dem Spiel stehen also die Klartext-HTTP-Flüsse und die TLS-terminierten Flüsse, die täglich weiter durch Unternehmens-Proxys laufen.

Eine Zeile, neunundzwanzig Jahre und die KI, die ihn fand

Die Ursache ist fast banal. Der Code rief strchr auf einer Zeichenkette auf, die leer sein konnte, und der C-Standard bestimmt, dass strchr das abschließende Nullbyte als Teil der Zeichenkette behandelt, sodass die Prüfung, die am Ende der Eingabe hätte halten sollen, still darüber hinauslief. Das schuldige Muster geht auf einen Squid-Commit vom Januar 1997 zurück, der Fehler wurde also in Standardkonfigurationen ausgeliefert, Port 21 steht in der Standardliste Safe_ports, und zwar neunundzwanzig Jahre lang über zahllose Releases, Umschreibungen und Sicherheitsprüfungen hinweg. Die Behebung ist eine einzige zusätzliche Bedingung, eine Null-Prüfung vor strchr, oder das vollständige Abschalten von FTP, das Chromium vor Jahren fallen ließ und auf das sich kaum ein Netz noch stützt.

Das Detail, das die Aufmerksamkeit eines Betreibers verdient, ist die Frage, wer ihn fand. Zwei Forscher meldeten ihn unabhängig voneinander, Pavel Kohout von Aisle Research im März 2026 und Lam Jun Rong von Calif.io im April, die Betreuer führten die Behebung binnen weniger Tage zusammen, und das öffentliche Advisory folgte am 23. Juni. Die ursprüngliche Entdeckung kam jedoch von einem KI-Agenten, der die FTP-Zustandsmaschine durchgehen sollte, und nicht aus einem weiteren menschlichen Audit. Die bequeme Annahme, dass alter, vielfach geprüfter Code allein durch sein Alter sicher sei, ist gerade sehr öffentlich durchgefallen, und das Werkzeug, das sie zu Fall brachte, ist inzwischen billig und breit verfügbar.

Was ein Betreiber diese Woche tun sollte

Der konkrete Schritt ist klein: Erfassen Sie jede Squid-Instanz, die Sie betreiben, patchen Sie auf einen korrigierten Release, und wenn Sie FTP-Proxying nicht bewusst brauchen, schalten Sie es ab und entfernen Sie Port 21 aus Safe_ports. Priorisieren Sie jeden Proxy, der TLS terminiert oder Klartext-HTTP für mehrere Nutzer trägt, denn dort können die Zugangsdaten von Kollegen zueinander durchsickern. Im Vereinigten Königreich behandelt das National Cyber Security Centre die Preisgabe von Zugangsdaten auf geteilter Infrastruktur als meldepflichtige Vorfallklasse, und EU-weit weist das NIS2-Regime die Verantwortung für einen bekannten, ungepatchten Fehler der namentlich benannten Geschäftsleitung zu und nicht allein dem Sicherheitsteam.

Der größere Zug besteht darin, das Alter einer Abhängigkeit nicht länger als Beweis ihrer Sicherheit zu behandeln. Ein Ein-Zeilen-Fehler verbarg sich neunundzwanzig Jahre in Software, der Tausende Organisationen gerade wegen ihrer Reife vertrauten, und ein KI-Prüfer fand ihn in einem einzigen Durchgang. Rechnen Sie damit, dass weitere dieser schlummernden Fehler in Ihren ältesten und meistvertrauten Komponenten auftauchen, und kalkulieren Sie einen steten Strom kleiner, unspektakulärer Patches ein statt eines einzigen dramatischen.