Der Fehler sitzt im Parser für FTP-Verzeichnislisten von Squid. Hintergrund ist Code, der einst für alte NetWare-Server ergänzt wurde, deren Verzeichnislisten zusätzliche Leerzeichen enthielten. Dabei überspringt eine Schleife Leerraum mit der Anweisung, sinngemäß, solange das aktuelle Zeichen in der Menge der Leerraumzeichen vorkommt, rücke den Zeiger weiter.
Genau dort entsteht das Problem: Liefert ein vom Angreifer betriebener FTP-Server eine Verzeichniszeile, die unmittelbar nach dem Zeitstempel endet und keinen Dateinamen mehr enthält, landet der interne Zeiger auf dem Null-Terminierungszeichen der Zeichenkette. Da strchr dieses abschließende Null-Zeichen als Teil der durchsuchten Zeichenkette behandelt, liefert der Aufruf weiterhin einen Zeiger statt eines Nullwerts. Die Schleife endet dadurch nicht, liest über das Ende des Puffers hinaus, und xstrdup kopiert nachfolgende Speicherinhalte zurück an den Angreifer – als angeblichen Dateinamen.
Brisant wird das laut Calif.io dadurch, dass Squid freigegebene Speicherpuffer wiederverwendet, ohne sie zu nullen. Wenn ein 4-KB-Puffer kurz zuvor die HTTP-Anfrage eines anderen Nutzers enthalten hat, bleiben große Teile dieser Daten erhalten. Eine kurze FTP-Zeile überschreibt nur die ersten Bytes; der Over-Read gibt den Rest preis.
In der Demonstration von Calif.io wurde auf diese Weise ein Authorization-Header eines anderen Nutzers ausgelesen, der denselben Proxy verwendete. Das reiche aus, um als dieser Nutzer aufzutreten. Zugleich betonen die Forscher die Grenzen des Angriffs: Betroffen ist nur Datenverkehr, den Squid im Klartext sieht. Normales HTTPS im CONNECT-Tunnel fällt nicht darunter, wohl aber Klartext-HTTP und TLS-terminierende Prüfaufbauten.
Squid beschreibt das Szenario als Angriff durch einen „vertrauenswürdigen Client“, also einen bereits zugelassenen Proxy-Nutzer. Der Angreifer benötigt außerdem einen erreichbaren FTP-Server unter eigener Kontrolle auf Port 21. Beides passt laut Quelle zu typischen Einsatzorten von Squid in gemeinsam genutzten Netzen.
Die Behebung ist klein: ein Null-Terminierungs-Check vor den verwundbaren strchr-Aufrufen. Der Fix wurde im April in den Entwicklungszweig und im Mai in v7 übernommen. Allerdings ist die öffentliche Diskussion über die korrigierten Versionen noch uneinheitlich. Maintainer Amos Jeffries schrieb zunächst, Squid 7.6 enthalte den Fix, korrigierte dies dann auf 7.7. Am 22. Juni merkte Debians Salvatore Bonaccorso an, der referenzierte Commit sehe so aus, als sei er bereits in 7.6 enthalten. Wer patcht, soll deshalb laut Quelle die tatsächliche Korrektur in FtpGateway.cc oder einen Backport der jeweiligen Distribution prüfen und nicht nur auf die Versionsnummer schauen. Debian paketiert etwa Squid 5.7.
Separat behebt Squid 7.6 auch CVE-2026-50012, einen nicht verwandten Heap-Overflow in cache_digest. Als grundsätzlich sauberere Maßnahme empfehlen die Forscher, FTP ganz abzuschalten. Chromium habe FTP bereits vor Jahren entfernt, und in den meisten Netzen spiele das Protokoll kaum noch eine Rolle. SUSE bewertet das Risiko als moderat mit CVSS 6.5; laut Vektor sind geringe Privilegien nötig, und betroffen ist nur die Vertraulichkeit, nicht Integrität oder Verfügbarkeit.
Calif.io schreibt die Entdeckung des strchr-Problems Anthropic’s Claude Mythos Preview zu, dem Modell hinter Project Glasswing. Nach Angaben der Forscher erkannte es die Besonderheit nahezu sofort. Calif.io deutet zudem an, dass der FTP-Code von Squid womöglich nicht die einzige Stelle ist, an der ein Parser zu weit liest.