JFrog: Artifactory ist sicher, doch Linux-Kernel-Lücke CVE-2026-98432 kann Hosts gefährden

Worum es bei der Schwachstelle geht

Laut JFrog hat das CVE-Team des Linux-Kernels CVE-2026-98432 am 15. Oktober veröffentlicht. Es handelt sich um einen Use-after-free-Fehler in dem Code, der neue IPv4-TCP-Verbindungen aufbaut, ausgelöst durch eine Race Condition. Der Fehler reicht bis Linux 4.4 zurück.

Upstream wurde das Problem am 5. Oktober behoben, nachdem der Main-Line-Patch am 17. September eingespielt worden war. Der Fix war also zehn Tage vor der Offenlegung der CVE öffentlich. Das Kernel-Team bewertet die Lücke mit 9,8, während Red Hat, Oracle, SUSE und Amazon sie niedriger einstufen, nämlich zwischen 5,9 und 8,1.

Am 27. Oktober veröffentlichte Anthropic Forschungsergebnisse, wonach sein Modell Claude einen funktionierenden Exploit geschrieben hat. JFrog beschreibt das Szenario so: Ein Angreifer aus der Ferne erhält ohne Zugangsdaten eine Root-Shell auf Servern mit einem Multipath-TCP-Listener (MPTCP). In Anthropics Test dauerte das Auslesen einer Kernel-Adresse 48 Minuten, bis zur Befehlsausführung vergingen weitere fünf. Ein verlorenes Race beendet nur die jeweilige Verbindung, der Angreifer kann es also einfach erneut versuchen. Anthropic hat den Exploit-Code nicht veröffentlicht, und bis zum 2. November gab es laut JFrog keine Berichte über Angriffe in freier Wildbahn.

MPTCP ist weniger exotisch, als es klingt. Seit Go 1.24 fordern Go-Programme es standardmäßig auf den Sockets an, auf denen sie lauschen, und das Go Security Team betont, dass der zugrunde liegende Fehler nicht auf MPTCP beschränkt ist. JFrog weist darauf hin, dass in seinen Deployments mehrere Go-Dienste mit Versionen nach 1.24 laufen.

Wer betroffen ist und wie die Distributionen dastehen

Kunden von JFrog Cloud sind nicht betroffen. Betroffen sind dagegen Kunden mit selbst verwalteten Installationen, denn ihnen gehört das Betriebssystem unter der JFrog-Installation. JFrog verweist auf ein Modell geteilter Verantwortung: Das Unternehmen sei für seine Produkte zuständig, die Kunden für Host, Kernel und Patching.

Laut JFrog hatten Ubuntu und RHEL bis zum 30. Oktober keinen korrigierten Kernel veröffentlicht. Ubuntu 22.04 bis 26.10 sind als in Bearbeitung markiert, ältere Releases sind schlicht verwundbar. RHEL 8, 9 und 10 werden als betroffen geführt, ein Termin ist nicht genannt. Debian, Oracle Linux, SUSE und Amazon Linux haben zumindest für einige Kernel Fixes ausgeliefert. JFrog rät, das genaue Release zu prüfen, da die Abdeckung innerhalb einer Distribution variiert.

Was JFrog empfiehlt

Zuerst sollten Betreiber klären, was bei ihnen läuft. JFrog warnt, dass Versionsnummern in die Irre führen können, weil Distributionen Fixes zurückportieren, ohne die Version hochzuzählen. Deshalb sollte stattdessen das Changelog geprüft werden:

• Debian oder Ubuntu: apt changelog linux-image-$(uname -r) | grep CVE-2026-98432
• RHEL und Derivate: rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

Gibt der Befehl nichts aus, enthält der laufende Kernel den Fix nicht. Wo ein Fix existiert, sollte gepatcht und anschließend neu gestartet werden, denn ein Kernel-Update bewirkt nichts, bis der Rechner damit gebootet hat.

Für selbst gebaute Kernel nennt JFrog den Fix in den Versionen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3. Das Kernel-Team empfiehlt, auf das neueste stabile Release zu wechseln, statt nur den einen Commit herauszupicken.

Wo es keinen Fix gibt, meldet Red Hat laut JFrog, dass keine verfügbare Abhilfe die eigenen Anforderungen erfüllt. MPTCP Programm für Programm abzuschalten sei fragil, und laut Go-Team macht ein vergessener Listener das System erneut angreifbar. JFrog empfiehlt, den Netzwerkzugriff auf betroffene Hosts einzuschränken, dem Hersteller-Advisory zu folgen und am Tag des Eintreffens eines Pakets zu patchen. Außerdem nennt das Unternehmen einen L7-Load-Balancer oder Reverse-Proxy mit TCP-Terminierung als Option, um die direkte Angriffsfläche zu verringern, betont aber, dass dies den Fehler nicht behebt.

Was das für Anwender bedeutet

JFrog sieht den Fall als weiteres Beispiel für den schrumpfenden Abstand zwischen einem öffentlichen Fix und einem funktionierenden Exploit. Hier war der Fix am 5. Oktober öffentlich, die Exploit-Geschichte erschien am 27. Oktober, und am 30. Oktober hatten zwei der am weitesten verbreiteten Enterprise-Distributionen noch kein Update.

Das Unternehmen verweist zudem auf einen praktischen Schritt: Kunden, die Debian- oder RPM-Repositories über Artifactory proxyen, können den korrigierten Kernel über das Repository beziehen, das ihre Hosts ohnehin nutzen, ihn dann stagen, promoten und in Wellen ausrollen. JFrog ergänzt, dass Xray zwar Supply-Chain-Artefakte und Images scannt, aber nicht meldet, welchen Kernel ein Host betreibt. Die Changelog-Prüfung müsse daher manuell auf jedem Host laufen, auf dem JFrog betrieben wird.