Acronis-Backup-cPanel-Plugin (CVE-2026-87886) wird ausgenutzt

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastruktur-Sicherheit für Unternehmensteams in den USA und der EU

Die kurze Antwort

Was Acronis offengelegt hat

Das Acronis-Backup-Plugin für cPanel & WHM und die passende Erweiterung für Plesk verbinden ein Hosting-Control-Panel mit der Acronis-Backup-Infrastruktur. Administratoren können damit Websites, Datenbanken, Mailboxen und ganze Server direkt aus dem Panel sichern und wiederherstellen — das Plugin läuft also mit weitreichendem Zugriff auf Dateien und Prozesse der Maschine. So privilegierte Software ist ein hochwertiges Ziel: Eine Schwäche darin bleibt nicht auf ein Konto beschränkt.

Im September 2026 legte Acronis CVE-2026-87886 offen, eine lokale Rechteausweitung, die in unsicheren Standard-Dateiberechtigungen (CWE-276) wurzelt. Weil bestimmte vom Plugin installierte Dateien oder Verzeichnisse für Konten schreib- oder ausführbar sind, die diesen Zugriff nicht haben sollten, kann ein authentifizierter Angreifer, der bereits eine Position mit geringen Rechten auf dem Linux-Server hält, sie nutzen, um seine Rechte — bis zu root — ohne jede Interaktion eines legitimen Nutzers auszuweiten. Die Lücke trägt CVSS 7.8, und Acronis beschreibt die Ausnutzung als wenig komplex.

Entscheidend: Acronis erklärte, eine Ausnutzung sei in begrenzten, gezielten Angriffen gegen das cPanel-&-WHM-Plugin festgestellt worden; die Plesk-Erweiterung sah man nicht ausgenutzt, obwohl auch sie betroffen ist und gepatcht werden sollte. Kurz nach der Offenlegung nahm die CISA CVE-2026-87886 am 16. September 2026 in ihren KEV-Katalog auf, mit einer Frist zum 19. September für US-Bundesbehörden — dieselbe Behandlung wie die weit spektakuläreren Maximal-Lücken des Tages, denn die tatsächliche Ausnutzung, nicht der reine Score, verdient einen KEV-Eintrag. Die Behebung ist unkompliziert: das Plugin auf den gepatchten Build aktualisieren. Genau die Härtungsdisziplin, die wir über eine Cloud- und DevOps-Plattform anwenden — least privilege, enge Dateirechte und eine schnelle Patch-Pipeline —, ist das, was diese Lücke gerade nicht hatte.

Warum eine „lokale“ Lücke gefährlich ist

Es ist verlockend, eine lokale, authentifizierte 7.8 unter die Vor-Authentifizierungs-10.0-Schlagzeilen einzuordnen — und genau dieser Reflex ist, wie solche Lücken ausgenutzt werden. Echte Einbrüche sind Ketten, keine Einzelschritte. Angreifer verschaffen sich billig einen Fuß in der Tür mit geringen Rechten: eine verwundbare Webanwendung, ein geleakter SSH-Schlüssel, eine über ein kompromittiertes CMS abgelegte Web-Shell oder schlicht ein einzelnes Mandantenkonto auf einer geteilten Maschine. Für sich genommen ist dieser Zugang begrenzt. Eine Rechteausweitung ist die zweite Hälfte der Kette — der Schritt, der aus „ich kann Code als eingeschränkter Nutzer ausführen“ ein „ich besitze die Maschine“ macht.

Auf einem mandantenfähigen Hosting-Server ist dieser Wirkungsradius enorm. Root bedeutet nicht eine Site, sondern jede Website, Datenbank und Mailbox auf dem Host plus die Backup-Steuerebene selbst. Gerade dieser letzte Punkt macht eine backup-nahe Eskalation besonders gefährlich: Wer die Ebene erreicht, die Backups verwaltet, kann sie lesen, exfiltrieren oder zerstören und still den Wiederherstellungsweg kappen, auf den eine Organisation zählt, falls Ransomware folgt. Das Werkzeug, das die Wiederherstellbarkeit garantieren sollte, wird zum Hebel, der sie untergräbt.

Es gibt keine clevere Konfiguration, die unsichere Dateirechte in Drittanbietercode behebt — die korrigierten Rechte kommen im gepatchten Build, weshalb das Update die gesamte Behebung ist. Das verschiebt das eigentliche Risiko auf die Patch-Geschwindigkeit bei Software, die Sie nicht geschrieben haben: Control-Panel-Plugins, Backup-Agenten und Management-Add-ons fallen genau deshalb aus Ihrem Update-Rhythmus, weil sie sich wie Infrastruktur anfühlen und nicht wie Anwendungscode — und in dieser Lücke wartet eine in freier Wildbahn ausgenutzte Eskalation.

Was das für DACH-Softwareteams bedeutet

Die erste Lehre lautet, dass die privilegierten Add-ons Ihres Hosting-Stacks Teil Ihrer Angriffsfläche sind. Teams inventarisieren und patchen die Frameworks in den eigenen Repos, behandeln das Control-Panel und seine Plugins aber als Blackbox, die „einfach läuft“. Doch Backup-Agenten und Panel-Erweiterungen halten einige der mächtigsten Zugriffe auf dem Server, und eine Rechtelücke in einem von ihnen ist ein direkter Weg zu root. Alles, was Sie zur Härtung von Anwendungscode tun — least privilege, minimaler Dateizugriff, prompte Updates —, muss sich auf die darunterliegende Drittanbietersoftware erstrecken.

Die zweite Lehre betrifft Defense in Depth, damit ein Fuß in der Tür nicht fatal ist. Diese Eskalation zahlt sich erst aus, nachdem ein Angreifer bereits eine Position mit geringen Rechten hat — also begrenzt jede Kontrolle, die diesen ersten Zugang erschwert oder lauter macht, direkt den Schaden: Mandanten isolieren, einschränken, was ein Webprozess ausführen darf, auf unerwartete Rechteänderungen achten und die Backup-Ebene auf getrennten Zugangsdaten und Netzen halten. Nehmen Sie an, dass es zu einem ersten Fuß in der Tür kommt, und bauen Sie so, dass der Weg zu root mehr als ein ungepatchtes Plugin braucht.

Drittens ist dies ein Compliance- und Recovery-Assurance-Ereignis, nicht bloß ein Ops-Ticket. Ein Root-Kompromiss eines Servers, der Kundensites und Mailboxen hostet, fällt in DACH und der EU unter DSGVO-, NIS2- und DORA-Erwartungen — und weil die Backup-Ebene im Umfang liegt, berührt er auch Ihre Fähigkeit, eine intakte Wiederherstellung nachzuweisen. Belegen zu können, welche Hosts das betroffene Plugin liefen, wann Sie gepatcht haben und dass Ihre Backups verifiziert und zugriffsgeschützt waren, ist der Nachweis, nach dem Prüfer und Aufsicht zuerst fragen.

Was jetzt zu tun ist

1. Betroffene Hosts inventarisieren. Finden Sie jeden Linux-Server mit cPanel & WHM oder Plesk und installiertem Acronis-Backup-Plugin bzw. -Erweiterung — auch Staging-, Alt- und Reseller-Maschinen, die außerhalb der Haupt-Asset-Liste liegen.
2. Plugin sofort aktualisieren. Installieren Sie Build 1.9.3.1021 (1.9.3 HF3) für cPanel & WHM oder 1.8.11.638 (1.8.11) für Plesk oder höher. Es gibt keinen Rechte-Workaround, behandeln Sie das also als Notfalländerung. Patchen Sie auch Plesk, obwohl nur die Ausnutzung von cPanel/WHM beobachtet wurde.
3. Nach Eskalation suchen. Prüfen Sie Server-, sudo- und Plugin-Logs auf unerwartete Rechteänderungen, neue root-eigene Dateien oder Cronjobs und Aktivität von Konten mit geringen Rechten, die plötzlich als root handelten. Ein Root-Eindringling kann diese Logs manipuliert haben — gleichen Sie daher über mehrere Quellen ab.
4. Backups verifizieren. Stellen Sie sicher, dass Backups vorhanden, wiederherstellbar und mit Zugangsdaten und Netzzugriff getrennt von den geschützten Hosts abgelegt sind — der Sinn eines Angriffs auf die Backup-Ebene ist, Ihre Wiederherstellung vor der nächsten Phase zu kappen.
5. Eindämmen, rotieren, dann testen. War ein Host erreichbar und ungepatcht, behandeln Sie ihn als potenziell kompromittiert: rotieren Sie Zugangsdaten, Schlüssel und Geheimnisse und nehmen Sie Hosting-Control-Panels und ihre Plugins in den Umfang Ihres nächsten Penetrationstests auf, damit privilegierte Infrastruktur kein blinder Fleck mehr ist.

Häufig gestellte Fragen

Quellen

Help Net Security — Acronis backup plugin flaw exploited in targeted attacks (CVE-2026-87886)
Security Affairs — CISA Adds Acronis Backup, Cisco ISE, and Google Pixel Flaws to KEV Catalog
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog