JFrog mahnt CISOs, die Frage „Sind wir betroffen?“ nach den Vorfällen bei Curl, PHP und LiteLLM schnell zu beantworten

Drei Komponenten, drei unterschiedliche Risiken

Laut JFrog sehen sich Unternehmen und Behörden derzeit Bedrohungen durch Schwachstellen und Kompromittierungen in drei grundlegenden Bausteinen der Softwareentwicklung gegenüber: Curl, PHP und LiteLLM.

Curl. JFrog beschreibt schwerwiegende Sicherheitslücken in Curl und der Transferbibliothek libcurl, die im Oktober 2026 offengelegt wurden. Hervorgehoben wird ein HTTP/2-Use-after-free-Fehler mit hohem Schweregrad (etwa CVE-2026-92392). Dabei kann ein bösartiger Upstream-Server, der einen Upload verarbeitet, den Speicher auf Clientseite beschädigen. Unter bestimmten Bedingungen kann das Remote Code Execution oder Abstürze der Anwendung auf dem Rechner auslösen, der die Übertragung startet. JFrog weist darauf hin, dass libcurl bei HTTPS-URLs standardmäßig HTTP/2 aushandelt, sofern der Server dies unterstützt, und dass Anwendungen selten prüfen, was die Bibliothek im Hintergrund tut. Stacks und Deployment-Pipelines, die noch nicht auf eine korrigierte Version umgestellt wurden, können daher weiterhin feindlichen externen Endpunkten ausgesetzt sein. Das Unternehmen betont, dass libcurl in vielen Unternehmensumgebungen steckt, von Backend-Microservices und Container-Runtimes bis zu CI/CD-Pipelines und Shell-Skripten.

PHP. Zwei Schwachstellen im PHP-Kern mit dem Schweregrad CRITICAL (CVE-2026-109618 und CVE-2026-109619) wurden offengelegt und sind öffentlich unter dem Namen PHP2Shell bekannt. Laut öffentlichen Sicherheitshinweisen, auf die sich JFrog beruft, können die Fehler unauthentifizierte Remote Code Execution und eine Speicherpreisgabe im Stil von Heartbleed in PHP selbst ermöglichen, unabhängig von der darauf laufenden Anwendung. JFrog zufolge berichteten Medien innerhalb weniger Tage über die Lücken, und die US-Behörde CISA gab eine Warnung heraus, in der Organisationen zum sofortigen Patchen aufgefordert wurden.

LiteLLM. JFrog Security Research entdeckte innerhalb von 2 Stunden ein Problem mit der LiteLLM-Paketversion 1.107.0, die inzwischen von PyPI entfernt wurde. Die Maintainer des Pakets haben einen Bericht veröffentlicht. Laut JFrog konnten Entwickler, agentische Agenten oder Build-Systeme das Paket am 21. Oktober 2026 zwischen 11:39 und 13:23 UTC von PyPI herunterladen. Betroffene Docker-Images blieben bis 14:20 UTC verfügbar.

Die Triage-Fragen des CISO

Ein kompromittiertes Paket oder eine verwundbare Komponente betrifft laut JFrog nicht nur Entwickler und Sicherheitsteams. Sie erreicht auch den IT-Betrieb und später die Auditoren, sodass jede Änderung das gesamte Unternehmen berührt. Führungskräfte, die über Investitionen entscheiden, müssen wissen, ob sie vollständige Transparenz haben.

Der Beitrag nennt die Punkte, die die Triage eines CISO abdecken sollte:

• Handelt es sich tatsächlich um eine Bedrohung?
• Wo wird die Komponente eingesetzt?
• Welche Auswirkungen hat sie auf das Geschäft?
• Besteht eine Melde- oder Offenlegungspflicht nach Regeln oder Standards wie denen der US-Börsenaufsicht SEC, PCI DSS oder, für Produkthersteller, dem EU Cyber Resilience Act (CRA)?
• Haben wir sie blockiert?
• Wie beheben wir das Problem?

Ob sich diese Fragen sicher beantworten lassen, hängt JFrog zufolge davon ab, wie gut Tools, Mitarbeitende, Prozesse und das Sicherheitsprogramm ineinandergreifen. Das spiegle die Reife eines Sicherheitsprogramms wider und zeige, wie gut ein Unternehmen die Softwareentwicklung schützen, überwachen und steuern könne, sei es auf Entwickler-Workstations, in agentischen Workflows oder bei der direkten Umsetzung durch KI-Coding-Agenten.

Assessments und die Tool-Falle

Der Autor, der als CISO selbst solche Bewertungen für neue Einführungen und als laufende Maßnahme durchgeführt hat, hält eine breite Grundlage für nötig. Berücksichtigt werden sollten Geschäftsziele, Fähigkeiten der Beschäftigten, Workflows, Datennutzung und Reifegrad der Infrastruktur. Der Beitrag warnt vor einem klassischen Fehler: sich zu stark auf Tools zu konzentrieren, nur weil sie sich am einfachsten messen lassen. Aus Sicht von JFrog schützen Tools ohne die richtigen Mitarbeitenden und Prozesse das Unternehmen nicht.

Das Security Maturity Assessment von JFrog

JFrog gibt an, sein eigenes Security Maturity Assessment auf Grundlage der Arbeit mit zahlreichen Fortune-100-Kunden und der Expertise des hauseigenen Security-Research-Teams entwickelt zu haben. Organisationen können damit anhand ihrer Antworten den Reifegrad ihres Sicherheitsprogramms für die Software Supply Chain in 11 Bereichen selbst einschätzen. Der Autor empfiehlt, den Fragebogen auszufüllen. Er bewerte Stärken, Schwächen, Chancen und Risiken in der Softwareentwicklung und könne zeigen, wo der Einstieg lohnt.

Die Botschaft von JFrog lautet, dass die jüngsten Vorfälle CISOs keinen Spielraum lassen, tagelang auf eine Antwort zu warten, da Führungskräfte und Vorstandsmitglieder schnelle und präzise Auskünfte brauchen. Vollständige Transparenz über Mitarbeitende, Prozesse, Workflows, Tools und Abhängigkeiten verschaffe Sicherheitsverantwortlichen unter Druck Handlungsspielraum, so das Unternehmen. Es lädt Leser ein, das Assessment durchzuführen oder mit seinen Fachexperten zu sprechen. Da es sich bei dem Beitrag um Herstellerinhalt handelt, spiegeln Darstellung und Produktempfehlung die eigene Sicht von JFrog wider.