Angreifer können die volle Kontrolle über Wave-7-Router von Acer erlangen. Schuld sind zwei „kritische“ Sicherheitslücken mit Höchstwertung, gegen die es bislang kein Sicherheitsupdate gibt. Acer stellt den Patch für Ende Juni in Aussicht.

Zugangsdaten einsehbar

In einer Warnmeldung führt der Hardwarehersteller aus, dass beide Lücken (CVE-2026-49200, CVE-2026-49201) mit dem maximalen CVSS Score 10 von 10 eingestuft sind. Der Hersteller gibt an, dass davon alle Router bis inklusive der Firmware T7c_GBL_1.01.000055 bedroht sind.

Aufgrund einer fehlenden Abschottung können Angreifer ohne Authentifizierung über das Webinterface auf die Firmware von Routern zugreifen und dort die Datei acer_cgi.log einsehen. Darin finden sich unverschlüsselte Zugangsdaten, sodass Angreifern im Anschluss die volle Kontrolle über Geräte erlangen.

Im zweiten Fall können Angreifer auf die upload.cgi-Binary zum Verarbeiten von Gerätebackups zugreifen und Firmwares modifizieren. So können sie etwa eine Hintertür im Code platzieren. Wie solche Attacken im Detail ablaufen, ist bislang unklar. Aufgrund der kritischen Einstufung ist aber davon auszugehen, dass Angreifer keine großen Hürden für eine erfolgreiche Attacke überwinden müssen.

Router vom Internet trennen

Weil es derzeit keinen Sicherheitspatch und auch keine Übergangslösung zum Absichern der Router gibt, sollten Besitzer das Gerät von Internet trennen, um Angreifern keinen Ansatzpunkt zu geben. Da ein Router der Eingang ins eigene Netzwerk ist, gilt er als besonders schützenswert. Bislang gibt es seitens Acer keine Hinweise darauf, dass Angreifer bereits Geräte attackieren. Das kann sich aber schnell ändern.

Mitte März wurden Sicherheitslücken in TP-Links Router der Archer-Serie bekannt, die unter anderem ebenfalls das Flashen einer manipulierten Firmware ermöglichten.

(des)

Wer Google Chrome zum Surfen im Netz nutzt, sollte sicherstellen, dass das Update aus dieser Woche installiert ist: Es schließt 429 Sicherheitslücken, ein neuer Höchstwert. Davon sind 22 sogar als kritisches Risiko eingestuft.

Inzwischen hat Google die Versionsankündigung um die damit geschlossenen Schwachstellen angereichtert – bei 429 Einträgen hat das offenbar etwas Zeit beansprucht. Die gravierendste Schwachstelle ermöglicht Lese- und Schreibzugriffe außerhalb der vorgesehenen Speichergrenzen in der Angle-Komponente (Almost Native Graphics Layer Engine). Das führt potenziell zum Ausbruch aus der Sandbox (CVE-2026-10881, CVSS 9.6, Risiko „kritisch“). Den Meldern der Lücke bringt das 97.000 US-Dollar Belohnung ein, eine bemerkenswert hohe Summe.

Neben den 22 kritischen Sicherheitslücken stufen die Entwickler 87 als hochriskant, 226 als mittleren Bedrohungsgrad und 94 als niedriges Risiko für Nutzerinnen und Nutzer ein. Immerhin: Google erwähnt nichts davon, dass ein oder mehrere der Sicherheitslecks bereits in freier Wildbahn missbraucht würden. Chrome 149.0.7827.59 für Android, 149.0.7827.53 für Linux und 149.0.7827.53/54 für macOS und Windows enthalten die zahlreichen Fehlerkorrekturen.

Aktualisierte Software

Das Update kommt etwa mittels Versionsdialog auf den Rechner. Dazu das Browser-Menü öffnen und auf „Hilfe“ und dort auf „Über “ respektive „Info“ bei einigen auf Chromium basierenden Browsern klicken. Das zeigt den derzeit aktiven Softwarestand an und lädt gegebenenfalls verfügbare Aktualisierungen herunter. Unter Linux ist dafür in der Regel die Softwareverwaltung der Distribution zuständig. Auf Mobilgeräten hingegen müssen Nutzerinnen und Nutzer im jeweiligen App-Store nachsehen, dort kommen die Aktualisierungen jedoch oftmals mit deutlicher Verzögerung an – ein beschleunigtes Update lässt sich dort leider nicht erzwingen.

Da auch andere Browser auf Chromium basieren, dürften sie ebenfalls ein umfangreiches Update ausliefern – etwa Microsoft mit dem Edge-Browser. In der vergangenen Woche hatte Google bereits einen Höchststand an Schwachstellen in Chrome ausgebessert, dort waren es jedoch „nur“ 151 Lücken.

(dmk)

Let’s Encrypt hat erstmals einen konkreten Fahrplan für quantensichere Zertifikate vorgelegt. Die Zertifizierungsstelle will dafür auf sogenannte Merkle Tree Certificates (MTCs) setzen, statt bestehende X.509-Zertifikate einfach mit größeren Post-Quantum-Signaturen zu versehen. Eine Testumgebung soll Ende 2026 starten, ein produktionsreifes Angebot 2027 folgen. Neu ist weniger das Bekenntnis zur Post-Quantum-Kryptografie als die Festlegung auf einen bestimmten technischen Weg.

Let’s Encrypt zählt zu den weltweit wichtigsten Zertifizierungsstellen für automatisiert ausgestellte TLS-Zertifikate. Die Debatte um quantensichere Kryptografie läuft seit Jahren, drehte sich bislang aber vor allem um den Schlüsselaustausch. Dahinter steht die Sorge, dass Angreifer verschlüsselten Datenverkehr heute mitschneiden und später mit Quantencomputern entschlüsseln könnten. Die Absicherung von Zertifikaten und Signaturen galt lange als weniger dringlich, weil ein Angreifer dafür schon während der laufenden Kommunikation einen leistungsfähigen Quantencomputer bräuchte. Mit den inzwischen vom US-Standardisierungsinstitut NIST verabschiedeten Verfahren und den Migrationsplänen von Google und Cloudflare rückt nun auch die Authentifizierung in den Vordergrund.

Festlegung mit Signalwirkung

Künftig sollen Merkle Tree Certificates der bevorzugte Weg sein, um das Web-PKI quantensicher zu machen. An den nötigen Standards arbeitet Let’s Encrypt bereits in der IETF-Arbeitsgruppe PLANTS mit – die Ausstellung der MTCs wird zudem über eine ACME-Erweiterung abgewickelt. Die Entscheidung wiegt schwer, denn mit Hunderten Millionen aktiven Zertifikaten prägt die Organisation die technische Entwicklung der Web-PKI maßgeblich.

Dabei steht Let’s Encrypt nicht allein. Cloudflare und Chrome testen MTCs bereits in einem Feldversuch gegen echten Internet-Traffic, und Chrome hat den Ansatz zu seinem bevorzugten Weg für quantensichere Zertifikate im öffentlichen Web erklärt.

Hinter der Wahl steckt ein handfestes Problem quantensicherer Signaturen: Sie brauchen deutlich mehr Platz als heutige Verfahren. Let’s Encrypt verweist auf ML-DSA-44, einen der NIST-Standards. Dessen Signaturen sind mit rund 2.420 Bytes etwa 38-mal größer als die heute verbreiteten ECDSA-P256-Signaturen (64 Bytes). Würde man Zertifikate und Zertifikatsketten unverändert auf solche Verfahren umstellen, würden einzelne TLS-Handshakes auf über 10 Kilobyte anschwellen. Das würde Verbindungen verlangsamen und in manchen Netzen sogar die Fehlerrate erhöhen.

Wie Merkle Tree Certificates funktionieren

Merkle Tree Certificates gehen deshalb einen anderen Weg: Statt jedes Zertifikat einzeln zu signieren, fasst die Zertifizierungsstelle viele Zertifikate in einem Merkle-Baum zusammen. Signiert wird nicht jedes einzelne Zertifikat, sondern nur die Wurzel des Baums. Clients erhalten anschließend einen kompakten Nachweis darüber, dass ein bestimmtes Zertifikat zu diesem Baum gehört.

Das Prinzip kennen viele Administratoren aus anderen Bereichen – etwa Git-Repositories, Certificate-Transparency-Logs oder Blockchains. Einzelne Objekte werden dort nicht jeweils separat abgesichert, sondern über einen Baum auf einen gemeinsamen kryptografischen Anker zurückgeführt.

Kleinere Handshakes trotz größerer Signaturen

Nach Angaben von Let’s Encrypt schrumpfen die Authentifizierungsdaten im TLS-Handshake dadurch deutlich. Browser sollen dafür regelmäßig sogenannte Landmarks aktualisieren, die als Referenzpunkte für die Prüfung dienen. Im Regelfall genügt dann eine Signatur, ein öffentlicher Schlüssel und ein Merkle-Nachweis. So lässt sich der zusätzliche Ballast quantensicherer Signaturen weitgehend vermeiden.

Auch die Certificate Transparency profitiert von dem Ansatz. Heute stellt eine Zertifizierungsstelle ein Zertifikat zunächst aus und veröffentlicht es danach in separaten Transparenzprotokollen. Bei MTCs gehört die Transparenz dagegen zum Zertifikatsmodell selbst: Weil jedes Zertifikat Teil eines veröffentlichten Merkle-Baums ist, kann es gar nicht erst außerhalb dieser Struktur existieren. Ausstellung und Protokollierung rücken damit zusammen.

Bekannte Technik, lange Übergangsphase

Neuland ist die Technik für Let’s Encrypt nicht. Die Organisation betreibt seit 2019 eigene Certificate-Transparency-Logs, die ebenfalls auf Merkle-Bäumen basieren. Mit dem Betrieb solcher Strukturen im großen Maßstab hat sie also bereits Erfahrung.

Für Nutzer ändert sich vorerst nichts. Bestehende Zertifikate stellt Let’s Encrypt weiterhin wie gewohnt aus und verlängert sie automatisch. Die Umstellung hängt zudem von mehreren Faktoren ab: Neben der Standardisierung durch die IETF müssen Browser, Kryptobibliotheken, ACME-Clients und die Root-Programme der Browserhersteller die neuen Verfahren unterstützen.

Beim Schlüsselaustausch drängt die Zeit

Bei der Authentifizierung lässt sich die Umstellung also noch in Ruhe vorbereiten – beim Schlüsselaustausch drängt Let’s Encrypt dagegen zur Eile. Hier greift das Szenario „heute mitschneiden, später entschlüsseln“ (auch „harvest now, decrypt later“ genannt), weshalb jede Verbindung ohne quantensicheren Schlüsselaustausch ein Risiko darstellt.

Server-Betreibern rät Let’s Encrypt deshalb, hybriden Post-Quantum-Schlüsselaustausch (X25519MLKEM768) zu aktivieren. Große Browser und Betriebssysteme unterstützen das Verfahren bereits; es auf dem Server einzuschalten, sei eine der wirkungsvollsten Maßnahmen, die man in diesem Jahr ergreifen könne.

Festlegung auf einen Migrationspfad

Die Ankündigung markiert damit weniger den Start quantensicherer Zertifikate als die Festlegung auf einen konkreten Migrationspfad. Setzt sich MTC durch, dürfte das eine der größten strukturellen Änderungen der Web-PKI seit Certificate Transparency und dem ACME-Protokoll werden. Die Details hat Let’s Encrypt in einem Blogeintrag zur Post-Quantum-Zukunft veröffentlicht.

(fo)