CVE-2026-45537: Was ein CVSS 9.1 SIP-Pufferüberlauf tatsächlich für Underwriter, CISOs und Risikomanager bedeutet

Schweregrad: KRITISCH (CVSS v3.1: 9,1) · CWE-120 Pufferüberlauf · Veröffentlicht im NVD am 04.08.2026

Wenn eine CVE mit kritischem Schweregrad in Software für Telekommunikationsinfrastruktur veröffentlicht wird, ist der Reflex der meisten Sicherheitsteams: “Jetzt alles patchen.” Für Underwriter und Risikomanager sollte der Reflex ein anderer sein: Trennen Sie, was schwerwiegend ist, von dem, was wahrscheinlich ist, und kalkulieren Sie die Lücke zwischen beidem. CVE-2026-45537 ist ein nützliches Fallbeispiel genau für diese Disziplin – eine Schwachstelle, deren technischer Schweregrad und deren kurzfristige Ausnutzungswahrscheinlichkeit in entgegengesetzte Richtungen zeigen und deren tatsächliche Auswirkungen nahezu vollständig vom Einsatzkontext abhängen: der in Produktion laufenden Version, der Konfiguration der Routing-Skripte und der Frage, ob der Proxy aus dem öffentlichen Internet erreichbar ist.

Die Schwachstelle in einfachen Worten

CVE-2026-45537 ist ein kritischer globaler Pufferüberlauf in OpenSIPS, einem Open-Source-SIP-Server (Session Initiation Protocol), der in der Telekommunikations- und VoIP-Infrastruktur weitverbreitet eingesetzt wird. SIP ist das Signalisierungsprotokoll zum Aufbau, zur Änderung und zum Abbau von Sprach- und Videositzungen. Das bedeutet, dass eine OpenSIPS-Installation typischerweise im logischen Zentrum des Sprachverkehrs eines Betreibers sitzt – sie übernimmt Registrierung, Routing-Entscheidungen und Sitzungsaushandlung für jeden Anruf, den die Organisation tätigt oder empfängt. Ein Fehler auf dieser Ebene ist kein peripherischer Anwendungsfehler; es ist ein Fehler in der Steuerungsebene des Sprachnetzes.

Der Fehler liegt in der Funktion construct_uri(), die mehrere URI-Komponenten (Protokoll, Benutzername, Domäne, Port, Parameter) ohne jegliche Längenprüfung in einen festen 1024-Byte großen globalen BSS-Puffer zusammenfügt. In der Praxis bedeutet das: Die Funktion verbindet mehrere variabel lange Zeichenketten – von denen mehrere direkt oder indirekt vom Anfragenden geliefert werden – und schreibt das Ergebnis in einen statisch reservierten Speicherblock fester Größe. Es wird nicht überprüft, ob die kombinierte Länge hineinpasst. Es ist die Speichersicherheits-Entsprechung davon, einen Quart in einen Pint-Behälter zu gießen und den Überlauf dorthin laufen zu lassen, wohin es die Speicheranordnung des Prozesses entscheidet.

Der Ausnutzungspfad ist entsprechend einfach: Ein entfernter, unauthentifizierter Angreifer sendet eine SIP-Nachricht mit einem ausreichend langen Benutzernamen. Wenn ein Routing-Skript diesen vom Angreifer kontrollierten Benutzernamen an construct_uri() übergibt, überschreiten die kombinierten Komponenten die 1024-Byte-Grenze und überschreiben angrenzenden globalen Speicher. Es werden keine Anmeldedaten benötigt, kein vorheriger Zugriff ist erforderlich, und kein Benutzer auf der Opferseite muss in irgendeiner Weise getäuscht werden – eine einzelne manipulierte Anfrage von jedem Ort, der den Proxy erreichen kann, genügt.

Zwei Details heben diese Schwachstelle über einen gewöhnlichen Überlauf hinaus:

1. Deterministische Zustandsbeschädigung, nicht ein Absturz-Lotteriespiel. Der Überlauf beschädigt zuverlässig das globale Flag disable_503_translation, das die Behandlung von SIP-503-Antworten steuert. Wie SentinelOne anmerkt, “können entfernte unauthentifizierte Angreifer den globalen Serverzustand beschädigen und das SIP-Routing-Verhalten verändern, indem sie manipulierte URI-Benutzernamen senden, was die Integrität und Verfügbarkeit von OpenSIPS-Installationen untergräbt.” Ein Angreifer, der die Art und Weise verändern kann, wie ein SIP-Proxy den Verkehr routet und beantwortet, ist ein Angreifer mit Position in der Mitte der Sprachinfrastruktur – in der Lage, Failover-Verhalten zu beeinflussen, Fehlersignalisierung zu verzerren und zu bestimmen, welcher vorgelagerte Server welchen Verkehr erhält.

2. Stille Kollateralschäden. Der gleiche 1024-Byte-Puffer wird mit contact_builder() geteilt, das bei jeder Anfrage mit einem langen Benutzernamen stillschweigend beschädigt wird, wenn kein Speichersanitizer eingesetzt ist. Die Ausnutzung hinterlässt möglicherweise weder einen Absturz noch einen Logeintrag und kein offensichtliches Artefakt – der Server läuft mit beschädigtem internen Zustand weiter. Diese Kombination ist ein Vorfallreaktions- und Forensikproblem der schlimmsten Art und hat direkte Konsequenzen für Erkennung und Versicherbarkeit, worauf weiter unten eingegangen wird.

Betroffene Versionen: alle Versionen vor 3.6.6 und vor 4.0.0-rc1. Behoben in: 3.6.6 und 4.0.0-rc1, gemäß dem notcve.org-Eintrag.

Was stille Beschädigung für Erkennung und Schadenfälle bedeutet

Die meisten Schwachstellen-Narrative gehen von einem erkennbaren Ereignis aus: einem Absturz, einem Neustart, einem Anstieg der Fehlerraten. CVE-2026-45537 bricht mit dieser Annahme. Da der Überlauf in den globalen Zustand und einen geteilten Puffer statt in eine Rücksprungadresse trifft, ist die wahrscheinliche Folge kein sterbender Daemon, sondern ein Daemon, der sich subtil anders verhält – die SIP-503-Behandlung wird umgeschaltet, Kontakt-Kopfzeilen werden aus beschädigtem Speicher zusammengesetzt, Routing-Entscheidungen driften von der Konfigurationsabsicht ab.

Für den Security-Betrieb bedeutet dies, dass standardmäßige erkennende Kontrollen unterdurchschnittlich abschneiden. Verfügbarkeitsüberwachung sieht einen gesunden Dienst. SIP-Fehlerraten-Dashboards bleiben möglicherweise flach. Das verbleibende Signal – ungewöhnlich lange Benutzernamen in Anfrage-URIs – ist günstig zu alarmieren, aber standardmäßig selten instrumentiert. Genau deshalb wird es im folgenden Reaktionsplan explizit hervorgehoben.

Für Versicherer verändert stille Beschädigung das Schadenbild auf drei Arten. Erstens kann sich das Intervall zwischen Kompromittierung und Entdeckung über Wochen oder Monate erstrecken, sodass sich Unterbrechungsverluste ansammeln, bevor jemand eine Schadenmeldung einreicht. Zweitens wird die Ursachenattribution tatsächlich schwierig: Routing-Anomalien ohne Absturz-Artefakte laden zu Streitigkeiten darüber ein, ob ein Schadenereignis ein Sicherheitsvorfall oder ein operativer Fehler war. Drittens können sich Toll-Fraud-Verluste, die auf beschädigtem Routing reiten, wie gewöhnliche Arbitrage darstellen, bis die Call Detail Records forensisch untersucht werden. Nichts davon macht das Risiko unversicherbar, aber es macht die Erkennungsfähigkeit zu einem legitimen Underwriting-Faktor statt zu einer Formalität.

Das Spannungsfeld zwischen CVSS 9,1 und EPSS: Warum Risikoteams nicht in Panik preisen sollten

Hier wird CVE-2026-45537 für jeden interessant, dessen Aufgabe quantifiziertes Risiko statt Vulnerability-Scanning ist:

• CVSS v3.1 Basis-Score: 9,1 (Kritisch) – getrieben vom Netzwerkangriffsvektor, fehlenden Privilegien, fehlender Benutzerinteraktion und hoher Integritäts-/Verfügbarkeitsauswirkung (SentinelOne).
• EPSS Ausnutzungswahrscheinlichkeit: unter 1 % in den ersten 30 Tagen (notcve.org).
• CISA KEV: nicht gelistet. Keine bestätigte Ausnutzung in freier Wildbahn.
• CISA SSVC-Entscheidung: “Attend” – nicht “Act”, was bedeutet, dass die Behebung geplant werden sollte, anstatt als Notfall behandelt zu werden.
• Blast-Radius: nur 2 NIST-validierte CPEs, ein enger Footprint im Vergleich zu Schlagzeilen-CVE in Browsern oder VPN-Appliances.

Lesen Sie diese Signale zusammen, nicht isoliert. CVSS beantwortet “wie schlimm, wenn ausgenutzt”; EPSS beantwortet “wie wahrscheinlich in Kürze ausgenutzt”; KEV beantwortet “wird es gerade ausgenutzt”; SSVC synthetisiert diese Eingaben zu einer Entscheidung. Eine 9,1 mit sub-1 % EPSS, ohne KEV-Eintrag und einem “Attend”-Verdikt ist ein bedingtes Risiko: katastrophal, wenn es auf einem ungepatchten SIP-Proxy auf Carrier-Niveau ausgenutzt wird, aber mit geringer kurzfristiger Ausnutzungswahrscheinlichkeit – teilweise weil OpenSIPS-Installationen weitaus seltener sind als Browser-Installationen oder Edge-Appliances.

Die CPE-Anzahl verdient einen Vorbehalt. Exposure-Management-Tools, die auf CPE-Matching basieren, finden nur das, was Anbieter validiert haben, und Open-Source-SIP-Server sind häufig in OEM-Plattformen, PBX-Distributionen und Session-Border-Controller-Produkten eingebettet, in denen der nachgelagerte Anbieter, nicht das vorgelagerte Projekt, die Versionsidentifikation verantwortet. Ein Zwei-CPE-Footprint unterschätzt daher die tatsächliche Installationsbasis um einen unbekannten Spielraum – genau die Art von Unsicherheit, die die Verlustverteilung, die Sie modellieren, erweitern und nicht verengen sollte.

Der Haken – und der Grund, warum dies nicht unter “ignorieren” abgeheftet werden kann – ist, dass EPSS ein nachlaufender Indikator für Nischeninfrastruktur-Software ist. Das Modell lernt aus öffentlichem Exploit-Code, Threat-Intelligence-Berichten und KEV-Einträgen; bevor eines davon existiert, erhält eine Nischen-CVE aus der Konstruktion heraus einen niedrigen Score. Öffentlicher Exploit-Code für einen deterministischen, unauthentifizierten Überlauf in einer Telekommunikations-Steuerungsebene könnte diese Wahrscheinlichkeit schnell verschieben, und Telekommunikationsziele sind sowohl für staatlich ausgerichtete Akteure als auch für Toll-Fraud-Gruppen attraktiv. Vorsichtige Teams behandeln den EPSS-Score als Momentaufnahme mit breiten Fehlertoleranzen, nicht als Urteil.

Für Underwriter: Was bei der Erneuerung zu fragen ist

Bei der Bewertung des Telekommunikations- oder UCaaS-Stacks eines Versicherungsnehmers liefert CVE-2026-45537 einen konkreten Fragenkatalog:

1. Betreiben Sie OpenSIPS, und in welcher Version? Alles unterhalb von 3.6.6 (bzw. unter 4.0.0-rc1 in der 4.x-Linie) ist einem bekannten, veröffentlichten, unauthentifizierten Überlauf ausgesetzt. Fragen Sie auch nach eingebetteten Instanzen – die SIP-Engine innerhalb eines Drittanbieter-PBX oder Session-Border-Controllers kann den vorgelagerten Versionen um Quartale hinterherhinken.
2. Ist der SIP-Proxy aus dem Internet erreichbar? Der Angriff erfordert keine Authentifizierung, daher ist die Angriffsfläche wichtiger als üblich. Ein Proxy, der auf Peering-Schnittstellen und Carrier-VLANs beschränkt ist, stellt ein anderes Risiko dar als einer, der von beliebigen Quelladressen erreichbar ist.
3. Gibt Ihr Routing-Skript benutzerkontrollierte Eingaben an construct_uri() weiter? Die Ausnutzung ist vom Skriptverhalten abhängig, nicht nur von der Version. Ein Versicherter, der dies korrekt beantworten kann, zeigt Konfigurationsmanagement-Reife; einer, der es nicht kann, rät.
4. Können Sie es erkennen? Angesichts der stillen Beschädigung geteilter Puffer hat ein Versicherter, der keine SIP-Anomalieerkennung, keine Alarmierung bei übergroßen URI-Feldern oder keine sanitizer-instrumentierten Testumgebungen nachweisen kann, eine materiell schlechtere Schadenposition für “Silent Failure”-Szenarien – Routing-Beschädigung, die wochenlang unentdeckt bleibt.
5. Wie lautet das Patch-SLA für Open-Source-Komponenten von Drittanbietern? Das Intervall zwischen Offenlegung auf vorgelagerter Seite und Bereitstellung auf nachgelagerter Seite ist der Ort, an dem diese Schadenklasse entsteht.

Telekommunikations- und UCaaS-Versicherte, die ungepatchte, aus dem Internet erreichbare OpenSIPS-Instanzen ohne kompensierende Kontrollen präsentieren, sind das Profil, bei dem diese CVE Ausschlüsse, Sublimits oder Prämienanpassungen rechtfertigt. Wenn Sie die Platzierung mit einem Makler durchgehen, hält eine strukturierte Broker-Scorecard diese Fragen beim Submission-Antrag verankert, statt sie in der Antragsnarrative zu vergraben.

Für CISOs und Risikomanager: Ein sachlicher Reaktionsplan

Das SSVC-Verdikt “Attend” stützt einen geplanten Patch-Zyklus statt eines Notfall-Änderungsfensters – aber der Zeitplan sollte angesichts der Integritätsauswirkung aggressiv sein:

• Patch auf 3.6.6 oder 4.0.0-rc1 als primäre Kontrolle (notcve.org). Wenn Sie ein nachgelagertes Produkt betreiben, das OpenSIPS einbettet, öffnen Sie jetzt ein Ticket beim Anbieter; eingebettete Kopien erscheinen nicht in den vorgelagerten Release Notes.
• Inventarisieren Sie Ihre Routing-Skripte. Die Ausnutzung erfordert ein Skript, das vom Angreifer kontrollierte Benutzernamen an construct_uri() übergibt. Zu wissen, ob Ihre Konfiguration dies tut, verwandelt theoretische Exposition in gemessene Exposition – und in vielen Installationen lautet die Antwort “nein”, was diesen Patch gegenüber konkurrierenden Anforderungen legitim nachordnet.
• Validierung mit Sanitizer. Da der Überlauf ohne Speichersanitisierung still ist, führen Sie ASan oder ein Äquivalent auf Staging-Instanzen unter produktionsähnlichen Nachrichtenlasten aus, um festzustellen, ob bereits eine Beschädigung aufgetreten ist.
• Lange Benutzernamen protokollieren und alarmieren. Eine kostengünstige erkennende Kontrolle: Alarmierung bei SIP-Anfragen, deren URI-Benutzernamenfeld einen sinnvollen Schwellenwert überschreitet. Es ist die eine zuverlässig beobachtbare Spur, die diese Schwachstelle hinterlässt.
• Überprüfen Sie Ihre tatsächliche Exposition. Ein externes Domain-Exposure-Review deckt SIP-Listener auf, die durch Akquisitionen oder Schatten-IT in den Bestand gelangt sind und nie im Asset-Inventar erfasst wurden.
• Verfolgen Sie es formell. Erfassen Sie den Befund in Ihrem Risikoregister mit einem Owner, einer Patch-Frist und einem Erkennungsstatus, damit er den nächsten Sprint-Zyklus überlebt, anstatt in einem Chat-Thread zu verenden.

Quantifizieren statt Bauchgefühl

Für Risikomanager, die einen Vorstand oder einen Underwriter in Dollar statt in CVSS-Dezimalstellen briefen müssen, modellieren Sie dies als Einzelschadenereignis-Szenario mit niedriger annualisierter Häufigkeit – konsistent mit, wenn auch nicht identisch zu, sub-1 % EPSS, nach oben angepasst für Internet-Exposition und das Fehlen von Erkennungskontrollen – und mit hoher Verlusthöhe. Die Komponenten der Verlusthöhe sind konkret: Beschädigtes Routing auf einer Telekommunikations-Steuerungsebene führt zu Serviceausfällen, gemessen am Umsatz pro Minute für Sprachverkehr, zu Toll-Fraud-Exposition während das Routing verzerrt ist, zu regulatorischer Exposition unter NIS2 für EU-Telekommunikationsbetreiber und zu Forensikkosten für einen Vorfall, der keine Absturz-Artefakte hinterlässt.

Die Durchführung dieses Szenarios durch einen strukturierten FAIR-Risikoreport oder einen schnellen Cyber-Risk-Calculator verwandelt “9,1 Kritisch, seien Sie verängstigt” in einen Verlustüberschreitungsbereich, den Sie tatsächlich underwriten oder budgetieren können. Wenn Sie Tools für diese Art von Analyse evaluieren, deckt unser Vergleich von Tools zur Quantifizierung von Cyber-Risiken und Kosten die praktischen Trade-offs ab.

Für EU-Telekommunikationsbetreiber, in deren Geltungsbereich SIP-Infrastruktur fällt, beziehen Sie den Patch-Status in die umfassendere NIS2-Compliance-Haltung ein – eine ungepatchte, bekanntermaßen kritische Schwachstelle in der Steuerungsebene eines wesentlichen Unternehmens ist genau das, wonach Aufsichtsbehörden fragen, und eine strukturierte NIS2-Bewertung liefert Ihnen eine dokumentierte Antwort statt einer Ad-hoc-Antwort.

Fazit

CVE-2026-45537 ist eine wirklich ausgeklügelte Schwachstelle: unauthentifiziert, deterministisch, still und angesiedelt in der Signalisierungsschicht, von der die Telekommunikation abhängt. Aber ihr Risikoprofil ist bedingt – bedingt durch den Betrieb von OpenSIPS unter 3.6.6, bedingt durch ein verwundbares Routing-Skript, bedingt durch Exposition und derzeit gemäß EPSS mit niedriger Wahrscheinlichkeit und ohne KEV-Listung.

Für CISOs: Patchen Sie nach einem aggressiven, aber geplanten Zeitplan, bauen Sie die erkennenden Kontrollen auf und überprüfen Sie die Exposition, anstatt sie anzunehmen. Für Underwriter und Risikomanager: Nutzen Sie sie als Treiber, um Telekommunikations-Stack-Fragen zu stellen, die Sie möglicherweise überspringen würden, und um zwischen Schweregrad-Theater und quantifizierter Exposition zu unterscheiden. Die Organisationen, die Cyber-Risiken gut managen, sind nicht diejenigen, die auf jede 9,1 reagieren – es sind diejenigen, die in Zahlen erklären können, warum diese Ihre Verlustkurve bewegt oder nicht bewegt.

Quellen

• CVE-2026-45537 - Global Buffer Overflow in construct_uri — notcve.org
• CVE-2026-45537: OpenSIPS Buffer Overflow Vulnerability — SentinelOne Vulnerability Database
• Entdeckung zugeschrieben an “TristanInSec” gemäß dem notcve.org-Eintrag
• NVD-Veröffentlichung 04.08.2026, zuletzt aktualisiert 05.08.2026, gemäß SentinelOne

Hinweis: Mehrere weitere CVE, die diese Woche in Threat-Feeds kursieren – insbesondere CVE-2026-39980 und GHSA-36fr-4m54-94mj – betreffen die OpenCTI-Plattform und stehen in keinem Zusammenhang mit dieser OpenSIPS-Schwachstelle. Vermischen Sie diese nicht in Ihrem Monitoring.