Mehrere kritische CVEs in openssl_encrypt vor 1.4.0: Codeausführung, Token-Diebstahl und Auth-Bypass

Kurzfassung

In openssl_encrypt vor Version 1.4.0 steckt eine ganze Kette kritischer Schwachstellen. Betroffen sind unter anderem CVE-2026-74872, CVE-2026-74875, CVE-2026-74878, CVE-2026-74880, CVE-2026-74886, CVE-2026-74889, CVE-2026-74891, CVE-2026-74894 und CVE-2026-74895.

Die Spannbreite ist unschön: native Codeausführung, Authentifizierungsfehler, unsaubere Token-Verarbeitung, schwache Schlüsselableitung und hart kodierte Datenbankzugänge. Wer die Bibliothek in internen Diensten, Keyservern oder Plattformkomponenten einsetzt, sollte das als Priorität 1 behandeln.

Was ist passiert?

Die Schwachstellen betreffen Versionen vor 1.4.0 von openssl_encrypt. Nach Angaben der NVD reicht das Spektrum von direkter Codeausführung bis zu Umgehungen bei der Authentifizierung und beim Sandbox-Schutz. Es geht also nicht um einen einzelnen Randfehler, sondern um mehrere grundlegende Schutzmechanismen, die zu locker oder gar nicht greifen.

Für Unternehmen im DACH-Raum ist das vor allem dann relevant, wenn openssl_encrypt in eigenen Python-Diensten, in Automatisierungs-Stacks oder in internen Plattformen steckt. Wer solche Komponenten in Produktion betreibt, muss davon ausgehen, dass ein Angreifer bei Ausnutzung je nach Fehler sehr tief ins System kommt. Bei den kritischsten Fällen kann das bis zur vollständigen Übernahme eines Dienstes reichen.

Technische Details

CVE-2026-74872 betrifft die Whirlpool-Implementierung. Dort lädt die Bibliothek .so-Module über breite Glob-Muster, ohne die Integrität sauber zu prüfen. Gelingt es einem Angreifer, passende Dateien in einem site-packages-Verzeichnis abzulegen, kann beim Laden nativer Code laufen.

CVE-2026-74875 ist leiser, aber gefährlich genug: Wenn die Bibliothek jsonschema nicht findet, springt sie stillschweigend über die JSON-Schema-Prüfung hinweg. Malformte Metadaten werden dann akzeptiert. Das öffnet die Tür für manipulierte Daten, die eigentlich schon am Eingang hätten scheitern müssen.

CVE-2026-74878 beschreibt einen In-Memory-Rate-Limiter für TOTP-Bruteforce-Schutz, der nicht über Worker hinweg geteilt wird und nach einem Neustart verschwindet. Wer Anfragen über mehrere Instanzen verteilt oder direkt nach einem Restart erneut angreift, kann die Sperre aushebeln.

CVE-2026-74880 ist ein klassischer Geheimnisfehler. Refresh Tokens landen als URL-Parameter in Keyserver- und Telemetrie-Routen. Solche Tokens tauchen dann schnell in Logs, Browser-Historien, Proxy-Mitschnitten oder Referer-Headern auf. Das ist in der Praxis oft der schnellste Weg zum Datenabfluss.

CVE-2026-74886 und CVE-2026-74895 drehen sich um den Plugin-Schutz. Laut Beschreibung blockiert der Guard andere Module als der AST-Analyzer und die Sandbox greift im Standard-Isolationsmodus nicht sauber. Mit Obfuskation oder Encoding lassen sich gefährliche Imports wie sys, shutil, multiprocessing, importlib oder pickle einschleusen. Damit wird aus einem Plugin schnell beliebiger Code mit Dateisystem-, Netzwerk- und Subprozess-Zugriff.

CVE-2026-74889 betrifft die Schlüsselableitung. HKDF läuft dort ohne Salt und mit statischem Info-Parameter. Das schwächt die Entropie und macht abgeleitete Schlüssel berechenbarer, vor allem wenn gleiche Eingaben wiederkehren. Für Angreifer wird das bei Mehrzielangriffen interessanter, als es sein sollte.

CVE-2026-74891 ist ein Klassiker, der trotzdem immer wieder auftaucht: hart kodierte Datenbank-Zugangsdaten in Standalone-Server-Konfigurationsdateien. Laut Beschreibung können Angreifer im selben Netz mit bekannten Standardzugängen auf PostgreSQL zugreifen und Daten abziehen.

CVE-2026-74894 ist der direkte Auth-Bypass. Die Funktion zur Token-Prüfung akzeptiert jeden nicht leeren Bearer-Token. Das heißt: Ein beliebiger String im Authorization-Header reicht offenbar aus, um Funktionen wie das Hochladen öffentlicher Schlüssel, das Auflisten aller Schlüssel oder das Sperren fremder Schlüssel freizuschalten.

Wer ist betroffen?

Betroffen sind alle Installationen von openssl_encrypt vor 1.4.0. Die Quellenlage nennt keine Ausnahmen für einzelne Plattformen, daher ist im Moment nur klar: Alles unterhalb dieser Version ist zu prüfen.

Für deutsche und europäische Unternehmen ist vor allem der Einsatz in internen Diensten relevant, die Authentifizierung, Schlüsselverwaltung, Telemetrie oder Plugin-Ausführung übernehmen. Wer die Bibliothek nur indirekt über ein Produkt eines anderen Herstellers nutzt, sollte die Abhängigkeiten in der eigenen Software-Stückliste prüfen. Ob alle Distributionen und Paketquellen die fehlerhafte Version bereits abgezogen haben, lässt die Quelle offen.

Privatnutzer sind nur dann direkt betroffen, wenn sie eine Anwendung einsetzen, die openssl_encrypt intern mitbringt oder darauf aufsetzt. Für die meisten Verbraucher dürfte das deshalb kein Alltagsrisiko sein. In Entwicklungs- und Testumgebungen sieht das anders aus: Dort landen solche Bibliotheken oft ungeprüft in Containern, VMs oder CI-Jobs.

Empfohlene Maßnahmen

Erstens: auf Version 1.4.0 oder neuer aktualisieren. Das ist die naheliegende und wichtigste Maßnahme. Ohne Patch bleibt die gesamte Fehlergruppe im Spiel.

Zweitens: Abhängigkeiten inventarisieren. Prüfen Sie, wo openssl_encrypt direkt oder transitiv eingebunden ist. Gerade Python-Umgebungen, Container-Images und interne Tools werden oft vergessen. Wer mehrere Services betreibt, sollte nicht auf das Paketmanagement einzelner Server vertrauen.

Drittens: Logs und Token-Handhabung prüfen. Refresh Tokens gehören nicht in URL-Parameter. Wenn die Anwendung das doch tut, sollten Sie die Logik sofort umstellen und vorhandene Logs auf mögliche Leaks bewerten.

Viertens: Auth, Sandbox und Plugin-Ausführung testen. Ein kurzer Funktionstest reicht hier nicht. Admins sollten prüfen, ob die Anwendung fremde Bearer-Tokens wirklich validiert, ob die Sandbox greift und ob Plugins auf Dateien, Netzwerk oder Subprozesse zugreifen können, obwohl sie das nicht sollen.

Fünftens: Workarounds aktivieren, falls ein Patch nicht sofort geht. Rate-Limits sollten nicht nur im Speicher hängen. Für TOTP und ähnliche Flows braucht es eine zentrale Durchsetzung, etwa über den Load Balancer, den API-Gateway oder eine gemeinsame Backend-Schicht. Sonst hebeln mehrere Instanzen die Sperre gegenseitig aus.

Einschätzung von CyberSecurity-News.de

Das ist keine kleine Einzelmeldung, sondern ein Paket aus gravierenden Design- und Implementierungsfehlern. Besonders unschön: Mehrere Schwachstellen betreffen Grundlagen wie Authentifizierung, Sandbox und Geheimnisverwaltung. Wenn solche Kontrollen scheitern, hilft kosmetisches Härtungsvokabular wenig.

Die Informationslage wirkt dabei teilweise schmal. Aus der Quelle geht nicht hervor, welche Produkte oder Distributionen die Bibliothek konkret einbinden. Wer Verantwortung für Produktionssysteme trägt, muss deshalb selbst nachsehen statt auf Entwarnung zu warten.

Für den DACH-Raum ist die Relevanz vor allem in Unternehmen hoch, die eigene Plattformdienste oder interne Python-Services betreiben. Dort kann ein einzelnes veraltetes Paket schnell zum Einfallstor werden. Wer openssl_encrypt einsetzt, sollte jetzt prüfen, ob Version 1.4.0 oder neuer wirklich ausgerollt ist und ob alte Images noch im Umlauf sind.

Fazit

openssl_encrypt vor 1.4.0 bringt mehrere kritische Baustellen mit, und einige davon sind direkt ausnutzbar. Besonders gefährlich sind CVE-2026-74894, CVE-2026-74872 und CVE-2026-74895, weil sie Authentifizierung, Codeausführung und Sandbox-Schutz treffen. Wer die Bibliothek im Einsatz hat, sollte nicht diskutieren, sondern patchen und die Abhängigkeiten sauber nachziehen.

Quellenangabe

NVD-Eintrag zu CVE-2026-74872 sowie die dort verknüpften CVE-Hinweise zu CVE-2026-74875, CVE-2026-74878, CVE-2026-74880, CVE-2026-74886, CVE-2026-74889, CVE-2026-74891, CVE-2026-74894 und CVE-2026-74895.