Een 7,8 met een patchdeadline van drie dagen
Acronis publiceerde woensdag 16 september advisory SEC-10986 voor CVE-2026-87886, een lokale privilege escalation in de Acronis Backup plugin voor cPanel en WHM op Linux. De oorzaak is saai: onveilige bestandsrechten, CWE-276, CVSS 7,8. Security.NL had het bericht die ochtend om 10:52.
Wat eromheen gebeurde is interessanter dan het cijfer. Acronis zegt misbruik te hebben gezien in beperkte, gerichte aanvallen. CISA zette de CVE nog diezelfde dag op de lijst met actief misbruikte kwetsbaarheden, met 19 september als uiterste patchdatum voor Amerikaanse overheidsdiensten. Drie dagen, voor iets dat geen 9,8 is en geen remote code execution.
Kwetsbaar zijn builds onder 1.9.3.1021, gerepareerd in 1.9.3 HF3. De Plesk-extensie heeft dezelfde fout onder build 1.8.11.638. Daar is volgens Acronis nog geen misbruik waargenomen, wat iets anders is dan dat het er niet is.
Lokaal is op een webshopserver nauwelijks een drempel
De aanvaller moet al toegang hebben. Met dat argument zakt een lokaal lek in de meeste triages naar de stapel van volgende sprint. Op een machine waar een webshop draait klopt die redenering niet.
De eerste helft van de keten is daar namelijk goedkoop. Eén plugin met een uploadlek, één adminaccount van een oud-collega, één composer-package die je vijftien maanden niet hebt aangeraakt, en er draait code onder de user van je site. Dat is precies het startpunt dat CVE-2026-87886 nodig heeft. Van die user naar root is dan geen tweede aanval meer, maar een vervolgstap van een paar seconden.
Uitgerekend de backupagent is het component dat je daarbij kwijtraakt. Dat maakt dit vervelender dan een willekeurige rootexploit. Root op een WHM-machine betekent elke andere site op dat blik, en het betekent de credentials waarmee die agent bij je backupopslag komt. Je herstelpad zit dus in dezelfde blast radius als het probleem zelf.
Wat wij zouden doen, en wat niet
Kijk naar het buildnummer, niet naar het versienummer. In WHM zie je de pluginversie staan; alles onder 1.9.3.1021 is kwetsbaar, ook als het label 1.9.3 geruststellend oogt. Voor Plesk is 1.8.11.638 de ondergrens. Weet je niet welke build draait, dan weet je ook niet of je te laat was. Dat is bij een securityscan vaker het echte probleem dan achterstallig patchen zelf.
Draai je bij een managed hoster, dan is dit hun werk en niet dat van je team. Vraag er wel naar, en vraag concreet. Niet of ze gepatcht zijn, want daar komt altijd ja op terug. Wel op welke datum en welk tijdstip de plugin is bijgewerkt, naar welke build, en op welke hosts de oude build nog draaide tussen advisory en patch. Een partij die dat binnen een dag beantwoordt heeft zijn beheer op orde. Eentje die er een week over doet vertelt je ook iets.
Dan wat we zouden laten. We zouden een restore niet vertrouwen zonder te kijken uit welk venster hij komt: heeft er root op die machine gestaan, dan is een backup van daarna geen schone backup maar een momentopname inclusief indringer. We zouden de installer ook niet via curl naar sh pipen op een host waarvan je vermoedt dat hij al gecompromitteerd is. Opnieuw uitrollen en de data apart terugzetten kost een dag, en je weet daarna tenminste wat er draait.
En we zouden dit soort meldingen niet wegzetten als hostingnieuws dat langs je heen mag gaan omdat je de server niet zelf beheert. Je webshop staat erop.