Was Squidbleed tatsächlich preisgibt

Squidbleed, geführt als CVE-2026-47729, ist ein Heap-Puffer-Überlesefehler im FTP-Verzeichnislisten-Parser von Squid, einem der am weitesten verbreiteten Web-Proxys im Internet. Wenn Squid eine FTP-Liste ohne Dateinamen darstellt, läuft eine Leerzeichen-überspringende Schleife 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 ein berechtigter Nutzer eines geteilten Proxys sein und einen FTP-Server kontrollieren, den der Proxy über Port 21 erreicht, was das Risiko auf Insider lenkt und auf jede Aufstellung, in der der Proxy TLS terminiert. Als undurchsichtiger Tunnel weitergereichter HTTPS-Verkehr bleibt versiegelt, betroffen sind also die Klartext-HTTP- und 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 sagt, dass strchr das abschließende Nullbyte als Teil der Zeichenkette behandelt, sodass die Prüfung, die am Eingabeende hätte stoppen sollen, still darüber hinauslief. Das schuldige Muster geht auf einen Squid-Commit vom Januar 1997 zurück, was heißt, dass der Fehler in Standardkonfigurationen auslieferte, Port 21 steht in der Standard-Liste Safe_ports, neunundzwanzig Jahre lang über zahllose Releases, Umschreibungen und Sicherheitsprüfungen. Die Behebung ist eine einzige zusätzliche Bedingung, eine Null-Prüfung vor strchr, oder FTP ganz abzuschalten, was Chromium vor Jahren fallen ließ und worauf sich kaum ein Netz noch stützt.

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

Was ein Betreiber diese Woche tun sollte

Der konkrete Schritt ist klein: jede Squid-Instanz erfassen, die Sie betreiben, auf einen behobenen Stand patchen, und wenn Sie FTP-Proxying nicht bewusst brauchen, es abschalten und Port 21 aus Safe_ports entfernen. 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. In Deutschland behandelt das BSI die Preisgabe von Zugangsdaten auf geteilter Infrastruktur als meldepflichtige Störung, und EU-weit legt das NIS2-Umsetzungsgesetz die Verantwortung für einen ungepatchten, bekannten Fehler auf die benannte Geschäftsleitung, nicht allein auf das Sicherheitsteam.

Der größere Zug ist, 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 mehr 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.

Weiterlesen: Zwei Cursor-Lücken mit CVSS 9.8 liefern Angreifern den Entwickler-Rechner aus  |  Ein einziger Lieferanten-Hack verursachte die Hälfte der Ransomware-Opfer in Europa