CVE-2026-70554: Kritisk fejl i MaxSite CMS
Kritisk sårbarhed i MaxSite CMS (CVE-2026-70554) gør det muligt at overtage serveren uden login. Blokér cookien maxsite_comuser, indtil der findes en opdatering.
Hvad er det?
CVE-2026-70554 er en fejl i MaxSite CMS, hvor systemet tager data fra cookien maxsite_comuser og sender dem direkte til PHP-funktionen unserialize() uden at kontrollere, hvad der reelt står i dataene. Det kaldes objektinjektion: en angriber kan bygge et falsk, serialiseret PHP-objekt og lægge det i cookien. Når serveren genopbygger objektet, kan den utilsigtet køre kode gennem såkaldte gadget chains, kædet sammen af eksisterende PHP-klasser som SoapClient eller Imagick. Resultatet kan blive fuld fjernudførelse af kode på serveren, uden at angriberen behøver et login.
Hvem rammer det?
Sårbarheden rammer virksomheder og organisationer, der driver en hjemmeside eller webportal bygget på MaxSite CMS. Det gælder typisk mindre og mellemstore virksomheder samt kommunale institutioner, der bruger systemet til sin hjemmeside eller intranet. Alt, hvad der kræves for at blive udnyttet, er, at webserveren er tilgængelig fra internettet, og at cookien maxsite_comuser behandles af den sårbare kode.
Hvad kan ske?
En angriber kan sende en enkelt forfalsket HTTP-forespørgsel med en manipuleret cookie og derved få serveren til at udføre vilkårlig kode. I praksis betyder det, at angriberen kan installere en bagdør, stjæle databaseoplysninger, ændre eller slette indhold på hjemmesiden, eller bruge serveren som springbræt til resten af netværket. Da der ikke kræves login eller brugerinteraktion, kan angrebet ske automatiseret og i stor skala.
Hvor alvorligt er det?
CVSS-scoren er 9,8 af 10, hvilket er kritisk. Angrebet kræver ikke login (PR:N), ingen handling fra en bruger (UI:N), og det kan udføres over internettet (AV:N) med lav kompleksitet (AC:L). Konsekvensen er fuld kompromittering af fortrolighed, integritet og tilgængelighed (C:H/I:H/A:H). Der er ikke oplyst tegn på aktiv udnyttelse i offentligheden på offentliggørelsesdatoen, men sårbarhedstypen og den detaljerede beskrivelse af mulige gadget chains gør den nem at omsætte til et fungerende angreb.
Hvad gør jeg nu?
Følg trinene i denne rækkefølge for at lukke hullet og begrænse skaden, mens I venter på en officiel rettelse.
- Bloker eller fjern cookien maxsite_comuser ved webserveren, reverse proxy eller en webapplikationsfirewall, så den aldrig når frem til unserialize()-funktionen.
- Undersøg om jeres MaxSite CMS-installation er direkte tilgængelig fra internettet, og afskærm den eventuelt bag VPN eller IP-begrænsning, hvis det er muligt uden at forstyrre driften.
- Gennemgå webserver- og applikationslogfiler for usædvanlige cookie-værdier eller mistænkelig trafik mod login- eller kommentarfunktioner, hvor cookien typisk sættes.
- Hold øje med leverandørens meddelelser og installer en officiel rettelse eller opdatering af MaxSite CMS, så snart den udgives.
- Tag en sikkerhedskopi af hjemmesiden og databasen, hvis det ikke allerede er gjort, så I kan genskabe systemet, hvis det bliver kompromitteret.
- Kontakt Auroa eller en anden sikkerhedsrådgiver, hvis I ikke selv kan verificere, om jeres installation er sårbar, eller hvis I finder tegn på, at systemet allerede er kompromitteret.
Bloker cookien inden for 24 timer
Vi anbefaler, at I straks blokerer cookien maxsite_comuser ved jeres webserver eller firewall, da der endnu ikke er en officiel rettelse tilgængelig. Det er ikke forsvarligt at vente, hvis jeres MaxSite CMS er tilgængelig fra internettet, fordi angrebet kan udføres uden login og med en enkelt forespørgsel. I kan vente med øvrige tiltag, hvis systemet allerede er afskærmet bag VPN eller kun tilgængeligt internt, men vi anbefaler stadig at overvåge for opdateringer fra leverandøren.
Tidslinje
Konkrete eksempler
Webshell på en dansk virksomheds hjemmeside
En dansk virksomhed driver sin hjemmeside på MaxSite CMS uden at have opdateret systemet i lang tid. En angriber sender en enkelt forespørgsel med en manipuleret maxsite_comuser-cookie og udnytter en gadget chain til at få serveren til at skrive en webshell til disk. Herefter har angriberen fuld adgang til serveren, kan læse kundedata fra databasen og bruge serveren som udgangspunkt for yderligere angreb i virksomhedens netværk.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger MaxSite CMS?
Tjek jeres hjemmesides administrationsside eller spørg jeres webbureau, om hjemmesiden er bygget på MaxSite CMS. I kan også kigge efter cookien maxsite_comuser i browserens udviklerværktøjer, når I besøger sitet.
Er vi ramt, hvis vi ikke bruger kommentarfunktionen eller login på sitet?
Ja, sårbarheden kræver ikke login. Cookien kan sættes af en angriber direkte i en HTTP-forespørgsel, uanset om jeres besøgende normalt bruger login eller kommentarfunktioner.
Kan vi vente til weekenden med at reagere?
Hvis serveren er tilgængelig fra internettet, bør I blokere cookien nu, da angrebet kan udføres automatiseret uden varsel. Er systemet kun tilgængeligt internt eller bag VPN, kan I vente til næste arbejdsdag.
Findes der allerede en opdatering fra MaxSite CMS?
Der er ikke oplyst nogen officiel rettelse på offentliggørelsesdatoen. Følg leverandørens kanaler for opdateringer, og brug i mellemtiden blokering af cookien som midlertidig løsning.
Skal vi anmelde dette til myndighederne?
Hvis I konstaterer, at systemet faktisk er blevet kompromitteret og persondata er blevet tilgået eller lækket, skal I vurdere anmeldelsespligt efter databeskyttelsesreglerne og eventuelt kontakte Datatilsynet. Er der kun tale om en teoretisk risiko uden konstateret hændelse, er der ikke krav om anmeldelse.
Kan vi selv midlertidigt lukke hullet uden at afinstallere systemet?
Ja, den mest effektive midlertidige løsning er at blokere eller fjerne cookien maxsite_comuser ved webserveren eller en webapplikationsfirewall, indtil en officiel rettelse er på plads.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
MaxSite CMS contains a PHP object injection vulnerability that allows unauthenticated attackers to execute arbitrary code by passing attacker-controlled serialized data in the maxsite_comuser cookie directly to unserialize() without validation or class allowlisting. Attackers can craft a malicious serialized PHP object payload delivered in a single HTTP request to trigger magic methods during object graph reconstruction, enabling property-oriented programming attacks or remote code execution via available gadget chains such as those targeting SoapClient or Imagick extensions.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.