Diese Ausgabe beginnt mit einer OpenSSH-Lücke, durch die ein überlanges Passwort die Anmeldung auf musl-Linux umgeht, und einer APT-Lücke in Ubuntu, über die ein Angreifer im Netzwerk Pakete als root installieren kann. Außerdem verbreitet ein trojanisierter Webserver von Control Web Panel eine unsichtbare Backdoor, und DigiCert legt Ausweisdokumente von Kunden offen.
- OpenSSH warnt vor Lücke, durch die ein langes Passwort die Anmeldung auf musl-Linux umgeht
- Ubuntu schließt APT-Lücke: Angreifer im Netzwerk kann ein bösartiges Paket als root installieren lassen
- CWPdoor: Trojanisierter Webserver von Control Web Panel enthält unsichtbare Backdoor
- DigiCert legt Daten und Ausweisdokumente von Kunden über exponiertes internes System offen
OpenSSH warnt vor Lücke, durch die ein langes Passwort die Anmeldung auf musl-Linux umgeht
| Schwachstelle | Authentifizierungs-Bypass in sshd auf Linux-Systemen mit musl libc (etwa Alpine) ohne PAM. Ein Passwort mit 257 bis 1.024 Byte lässt eine Anmeldung bei Konten ohne Passwort (Feld „*“) gelingen. Behoben in OpenSSH 10.6p2 |
| CVE-Nummer | Noch keine CVE vergeben |
| Aktiv ausgenutzt | Nein, bei Veröffentlichung am 5. November 2026 wurden keine Angriffe gemeldet |
| Patch verfügbar | Ja, OpenSSH 10.6p2 sowie Alpine-Pakete für alle Releases bis einschließlich 3.16. Alternative: PasswordAuthentication auf „no“ setzen und sshd neu starten |
Wie kann die Schwachstelle ausgenutzt werden?
Die Release Notes von OpenSSH beschreiben eine Umgehung der Passwortauthentifizierung im Portable Release, gemeldet von Özgün Kültekin von Wakefield. Laut The Hacker News schlägt die Funktion crypt() unter musl bei Passwörtern mit mehr als 256 Byte fehl und gibt „*“ zurück. Das entspricht dem gespeicherten „*“ von Konten ohne Passwort, woraufhin die Anmeldung gelingt. Ein Server ist nur verwundbar, wenn vier Bedingungen gleichzeitig erfüllt sind: sshd läuft ohne PAM, PasswordAuthentication steht auf „yes“ (Standard), mindestens ein Konto hat „*“ im Passwortfeld und mindestens ein weiteres lokales Konto hat einen $5$- oder $6$-Hash. Auf glibc-Systemen, bei PAM-Authentifizierung und unter OpenWrt mit Dropbear tritt das Problem nicht auf.
Was kann die Folge sein?
Ein Angreifer meldet sich bei Konten an, die für die Schlüsselauthentifizierung gedacht sind, etwa root unter Alpine. Bei Alpine-Cloud-Images ist das Konto „alpine“ betroffen, das passwortloses doas besitzt – die vollständige Kontrolle ist damit in Reichweite. Der Forscher empfiehlt, auch OpenWrt, Buildroot und Yocto zu überprüfen, da diese häufig musl verwenden. Für MSPs liegt das Risiko vor allem bei Containern, Cloud-Images und Embedded-Appliances von Kunden.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie Alpine mit apk upgrade -U -a und starten Sie sshd mit rc-service sshd restart neu, denn ein reines Paket-Update lässt den laufenden sshd verwundbar. Können Sie nicht sofort aktualisieren, deaktivieren Sie PasswordAuthentication, prüfen Sie die Konfiguration mit sshd -t und starten Sie sshd neu. Testen Sie zuvor, ob die Anmeldung per Schlüssel funktioniert, und halten Sie Ihre aktuelle Sitzung offen. Suchen Sie in /var/log/messages nach „Accepted password for“ bei Konten ohne Passwort. Lässt sich eine Anmeldung nicht ausschließen, betrachten Sie die Maschine als kompromittiert.
Ubuntu schließt APT-Lücke: Angreifer im Netzwerk kann ein bösartiges Paket als root installieren lassen
| Schwachstelle | Fehler im HTTP-Backend der APT-Bibliothek, durch den ein Paket installiert wird, obwohl die Signaturprüfung fehlschlägt. Alle APT-Frontends sind betroffen. Ubuntu 22.04 LTS und neuer sind standardmäßig verwundbar, ältere Releases nur, wenn Acquire::Retries auf einen Wert größer null gesetzt ist |
| CVE-Nummer | CVE-2026-109518 |
| CVSS-Score | 7,7 (CVSS 4.0, Ubuntu-Einstufung „High“) |
| Aktiv ausgenutzt | Nein, in den Quellen wird keine Ausnutzung erwähnt |
| Patch verfügbar | Ja, unter anderem apt 2.4.15ubuntu0.1 (22.04), 2.8.4ubuntu0.1 (24.04) und 3.2.1ubuntu0.1 (26.04). Für 14.04 bis einschließlich 20.04 ist ESM erforderlich |
Wie kann die Schwachstelle ausgenutzt werden?
Laut der Mitteilung von Ubuntu, gemeldet von Max Justicz, kann ein Angreifer, der den HTTP-Verkehr zwischen APT und dem Archivserver manipulieren kann, eine angeforderte .deb-Datei durch ein bösartiges Exemplar ersetzen. Auch ein bösartiger Mirror genügt. Voraussetzung für die Ausnutzung ist, dass APT einen fehlgeschlagenen Download erneut versucht. Snap-Installationen und andere Transportwege als HTTP sind nicht betroffen. Auch die niederländische Nachrichtenseite Security.nl berichtet, dass Ubuntu Updates veröffentlicht hat und Debian bereits zuvor Patches herausgab.
Was kann die Folge sein?
Installationsskripte von Paketen laufen als root, ein erfolgreicher Angriff verschafft also die vollständige Kontrolle über den Server oder Arbeitsplatz. Das Risiko besteht vor allem in nicht vertrauenswürdigen Netzwerken, etwa gemeinsam genutztem WLAN, sowie bei Servern, die über einen Proxy oder einen öffentlichen Mirror per HTTP aktualisieren.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie mit apt list --installed '?source-package(^apt$)', ob die gepatchte Version läuft. Ubuntu empfiehlt, das Update selbst mit sudo apt update && sudo apt upgrade -o Acquire::Retries=0 auszuführen, damit sich das Retry-Verhalten während des Updates nicht ausnutzen lässt. Stellen Sie Archivquellen nach Möglichkeit von http:// auf https:// um und führen Sie anschließend apt update aus, um zu sehen, ob der Mirror HTTPS unterstützt. Mit Unattended Upgrades, seit Ubuntu 16.04 standardmäßig aktiviert, kommt der Fix innerhalb von etwa 24 Stunden automatisch an.
CWPdoor: Trojanisierter Webserver von Control Web Panel enthält unsichtbare Backdoor
| Schwachstelle | Backdoor „CWPdoor“ in einer gefälschten Version von cwpsrv, dem Webserver von Control Web Panel (früher CentOS Web Panel). Ein gefälschtes Updater-Skript ersetzt die echte Binary (Versionen 1.15.10 und 1.24.0) |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Ja, XLab entdeckte die Malware am 29. Juni 2026 und kommt zu dem Schluss, dass es echte Opfer gibt; das Ausmaß ist unbekannt |
| Patch verfügbar | Nein, es handelt sich nicht um eine Softwarelücke. Spielen Sie ein legitimes cwpsrv zurück, aktualisieren Sie und rotieren Sie alle Panel-Credentials |
Wie wurde dies ausgenutzt?
Forscher von XLab entdeckten die Malware am 29. Juni über ein Skript, das sich als Updater ausgibt, schreibt BleepingComputer. Im Forschungsbericht von XLab heißt es, dass die Backdoor inaktiv bleibt, bis ein Angreifer eine HTTP-Anfrage mit drei speziellen Headern sendet: X-Ngx-Integrity-Data, -Time und -Sig. Die Signatur wird per RSA geprüft, Befehle und Ausgaben sind mit AES-256-CBC verschlüsselt. Anschließend verwischt die Malware ihre Spuren: Dateizeitstempel werden wiederhergestellt, der Befehlsverlauf verschwindet und die Auslöseanfrage wird aus den Zugriffslogs entfernt. Am 30. September tauchte ein Archiv mit CWPdoor auf VirusTotal auf, zusammen mit der Ebury-Backdoor – ohne eine einzige Erkennung. Der Zusammenhang mit Ebury ist noch unklar.
Was kann die Folge sein?
Ein Angreifer führt aus der Ferne Befehle auf dem Hosting-Server aus und hinterlässt in den Logs kaum Spuren. XLab zählte im vergangenen Monat mehr als 340.000 CWP-Instanzen im Internet. Für MSPs und Hoster, die CWP als Alternative zu cPanel oder Plesk betreiben, kann ein einziges infiziertes Panel die Websites und Postfächer sämtlicher Kunden auf diesem Server gefährden.
Was sollten IT-Administratoren jetzt tun?
Suchen Sie auf CWP-Servern nach dem Unix-Socket ngx_http_integrity_helper, verdächtigen cwpsrv-Helper-Prozessen, der Zeichenfolge „X-Ngx-Integrity“ in der Server-Binary sowie nach Dateien mit dem Namen cwpsrv.suspeito. Ist ein Server infiziert, spielen Sie eine legitime Binary zurück, aktualisieren Sie CWP, rotieren Sie alle Passwörter und Credentials des Panels und untersuchen Sie den Host auf weitere Malware. Schotten Sie die Verwaltungsoberfläche von CWP vom offenen Internet ab.
DigiCert legt Daten und Ausweisdokumente von Kunden über exponiertes internes System offen
| Schwachstelle | Bei einer Servermigration im Februar 2025 wurde ein internes Unternehmenssystem von DigiCert ohne VPN im Internet erreichbar. Eine Self-Registration-Funktion und ein Autorisierungsfehler verschafften unbefugten Konten Lesezugriff auf archivierte Kundendaten |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Ja, ein unbefugtes Konto rief zwischen dem 27. Juni und dem 2. Juli 2026 Kundendaten ab; DigiCert bestätigte dies am 19. Oktober 2026 |
| Patch verfügbar | Nein, es handelt sich um einen Konfigurationsfehler. DigiCert hat die Self-Registration deaktiviert und den Zugriff eingeschränkt; betroffene Kunden werden seit dem 5. November 2026 informiert |
Wie wurde dies ausgenutzt?
Laut BleepingComputer war das System zuvor nur per VPN erreichbar. Im Juni 2026 bemerkte DigiCert unbefugte Konten und setzte Fixes um, behandelte den Vorfall jedoch zunächst als Kontoproblem und nicht als Datenzugriff. Erst die Untersuchung vom 19. Oktober ergab, dass archivierte Daten abgerufen worden waren. Der Vorfall ist auch in einem Incident-Bericht bei Mozilla dokumentiert. Laut Security.nl verfügten die Konten über keine Multi-Faktor-Authentifizierung.
Was kann die Folge sein?
Betroffen sind Namen, geschäftliche E-Mail-Adressen, Telefonnummern und Anschriften, bei einem Teil der Kunden zudem Kopien von Reisepässen, Führerscheinen oder Versorgerrechnungen, die zur Validierung eingereicht wurden. Eine Zahl der betroffenen Kunden wurde nicht genannt. DigiCert erklärt, dass CertCentral und DigiCert ONE nicht kompromittiert wurden, Zugangsdaten und ausgestellte Zertifikate sicher bleiben und das unbefugte Konto weder Änderungen vornehmen noch Zertifikate ausstellen konnte. Die Daten lassen sich jedoch für gezieltes Phishing und Identitätsbetrug nutzen.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie, ob Ihr MSP-Unternehmen oder Ihre Kunden Zertifikate bei DigiCert beantragen und ob dabei Ausweisdokumente eingereicht wurden. Achten Sie auf Benachrichtigungen von DigiCert im Postfach der Ansprechperson. Warnen Sie betroffene Kollegen und Kunden vor Phishing, das sich als DigiCert oder als Zertifikatsverlängerung ausgibt, und prüfen Sie, ob die MFA-Einstellungen Ihrer CertCentral-Konten in Ordnung sind.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
