Die freie Software OpenSSL für SSL/TLS-Implementierungen ist verwundbar. Der Großteil der nun geschlossenen Schwachstellen ist mit dem Bedrohungsgrad „niedrig“ eingestuft. Es kann aber auch Schadcode auf Geräte gelangen. Bislang gibt es keine Hinweise auf Attacken. Das kann sich aber jederzeit ändern, sodass Admins mit der Installation der reparierten Ausgaben nicht zu lange zögern sollten.

Schadecode-Attacken möglich

Im Sicherheitsbereich der OpenSSL-Website listen die Entwickler die Sicherheitslücken auf. Davon ist nur eine Schwachstelle (CVE-2026-45447) mit dem Bedrohungsgrad „hoch“ eingestuft. Sie steckt in der PKCS7_verify()-Funktion.

Daran können Angreifer mit einer präparierten PKCS#7-Signatur ansetzen. Bei deren Verifizierung kommt es zu einem Speicherfehler (use-after-free) und es kann Schadcode auf Systeme gelangen. Die Beschreibung der Lücke liest sich so, als seien Attacken aus der Ferne möglich.

Durch das Ausnutzen der verbleibenden Schwachstellen können Angreifer unter anderem Abstürze auslösen (etwa CVE-2026-34183 „mittel“). Ein Fehler in AuthEnvelopedData vom Cryptographic Message Service sorgt dafür, dass von Angreifern kompromittierte Nachrichten verarbeitet werden.

Außerdem können Angreifer signierte Nachrichten mit dem RSA-Schlüssel eines Opfers entschlüsseln (CVE-2026-42768 „niedrig“). Auch der Tausch eines Root-Zertifikats durch Angreifer ist vorstellbar (CVE-2026-42769 „niedrig“).

Sicherheitsupdates

Die Enwickler versichern, die Sicherheitslücken in den folgenden Versionen geschlossen zu haben:

• OpenSSL 1.0.2zq (nur für Premium-Support-Kunden)
• OpenSSL 1.1.1zh (nur für Premium-Support-Kunden)
• OpenSSL 3.0.21
• OpenSSL 3.4.6
• OpenSSL 3.5.7
• OpenSSL 3.6.3
• OpenSSL 4.0.1

(des)

Bei manchen Themen suchen sich die Hosts des heise-security-Podcasts auswärtige Hilfe, zum Beispiel beim kürzlichen Ausfall weiter Teile der Top-Level-Domain .de. DNSSEC-Experte Carsten Strotmann springt Sylvester und Christopher bei und erklärt, wo das Problem lag. Außerdem befasst sich die Folge mit der Sicherheitslücke YellowKey, dem Drama um dessen Entdecker und ganzen vier weiteren Themen. Um die alle in die Folge zu quetschen, greifen die Hosts zu einem neuen Trick.

Der kurze, aber folgenreiche Ausfall beim DENIC betraf alle Nutzer von DNSSEC-validierenden Resolvern – so viel war schnell klar. Doch was den Ausfall verursachte und was die deutsche Vergabestelle für Domains daraus gelernt hat, erläutert Carsten im ersten Teil des Podcasts. Er ist ausgewiesener DNSSEC-Experte und arbeitet seit 20 Jahren mit dem kryptografischen Protokoll zur Absicherung von DNS-Einträgen.

Nachdem der Experte das virtuelle Studio wieder verlassen hat und die Stammhosts unter sich sind, geht es zunächst um cow.fi. Der DeFI-Anbieter war aufgrund eines Kommunikationslapsus zwischen Domainvergabestelle („Registry“) und Domainanbieter („Registrar“) kurzzeitig seine Domain los – auf dieser erschien eine Phishingseite und Kriminelle erbeuteten damit Kryptoguthaben im Wert von 1,2 Millionen US-Dollar. Außerdem besprechen die Hosts YellowKey, eine Sicherheitslücke, die die Bitlocker-Verschlüsselung angreift. Ob sie eine echte Umgehung der Festplattenverschlüsselung unter Windows erlaubt, ist Gegenstand einer Diskussion (nicht nur) im Passwort-Podcast.

Da es erneut viel mehr Themen in der Security-Welt gab, als den Hosts Aufnahmezeit zur Verfügung steht, haben sie sich ein neues Format ausgedacht: In der „Fünf-Minuten-Challenge“ erzählen sie dieses Mal drei weitere Themen in insgesamt knapp 900 Sekunden. Genug Zeit, um spaßige Details zur Fail-Zwiebel beim Cloud-Hoster Railway, eine Einordnung zu Signals Caching-Problem und eine Fortsetzung zu Googles Zero-Knowledge-Proof in der Quantenforschung unterzubringen.

Die neue Folge von „Passwort – der Podcast von heise security“ steht seit Mittwoch auf den üblichen Podcast-Plattformen bereit.

(cku)

Die französische staatliche Digitalstelle DINUM untersucht einen Einbruch in ein Konto des Regierungs-Messengers Tchap. Der oder die Angreifer haben demnach Zugriff auf Chats und Nachrichten sowie Informationen von tausenden Nutzern erlangt.

Das teilt das französische Regierungsportal numerique.gouv.fr mit. Demnach konnten die Angreifer am 7. Juni 2026 ein Nutzerkonto beim verschlüsselten Instant-Messaging-Dienst Tchap kompromittieren. Da der Dienst private Chats und Nachrichten verschlüsselt, können die Angreifer selbst im Fall einer Konto-Kompromittierung lediglich auf unverschlüsselte öffentliche Chats und Nachrichten zugreifen, erklärt die Behörde. Es seien Berichten zufolge 73.467 Nutzerinnen und Nutzer betroffen, was knapp neun Prozent der Nutzerbasis entspreche.

Nach dem Vorfall schaltete sich die ANSSI, Frankreichs nationales Cybersicherheitszentrum und BSI-Pendant, ein und untersuchte den Vorfall. Die Kompromittierung konnte dabei bestätigt und Schutzmaßnahmen ergriffen werden; das Ausmaß des Vorfalls wurde ermittelt. Die IT-Sicherheitsexperten haben das unterwanderte Konto gesperrt. Bei der Untersuchung kam heraus, dass zu den möglicherweise offengelegten Daten Vor- und Nachname, E-Mail-Adresse, Unternehmen und Avatar der Nutzerinnen und Nutzer gehören. Die privaten Chats seien hingegen geschützt.

Untersuchungen dauern an

Die Untersuchungen gingen weiter, erklärt die Behörde. Es sollen noch Ereignisprotokolle ausgewertet werden, um herauszufinden, auf welche Chats und auf welche weiteren Daten die Angreifer Zugriff hatten. Im digitalen Untergrund bieten die Angreifer die angeblich abgegriffenen Daten an. Wie ein Post von Dark Web Intelligence auf X zeigt, geht es angeblich um 73.467 Nutzerkonten, mehr als 640.000 Nachrichten, 876 Chat-Räume und knapp 60.000 Mediendateien mit einem Umfang von 13,5 GByte. Zudem sollen klassifizierte Dokumente enthalten sein. Das hat die Untersuchung bislang jedoch nicht bestätigt.

Frankreichs als sicherer Messenger für die Regierung konzipierter Tchap-Dienst, der auf Matrix basiert, hatte bereits zum Start im Jahr 2019 mit einer Sicherheitslücke zu kämpfen. Einem Hacker gelang es, unbefugt ein Konto in dem Dienst anzulegen, obwohl er nicht zur Regierung gehört, was eigentlich durch entsprechende Mail-Domains sichergestellt werden sollte. Die Lücke wurde damals in kürzester Zeit nach der Meldung durch den Entdecker geschlossen.

(dmk)