Webhotellet ditt er hacket: hva du bytter i WordPress og WooCommerce

Fredag ettermiddag 23. oktober 2026 oppdaget DreamHost at en uvedkommende hadde tilgang til serveren som kjører den nettbaserte filbehandleren deres. SFTP-passord og webmail-økter ble eksponert, og innholdet i filer og e-post kan ha blitt lest. DreamHost er et amerikansk webhotell, men det samme kan skje hos et hvilket som helst webhotell, også et norsk. Her går jeg gjennom hva DreamHost faktisk har bekreftet, hva jeg bytter i WordPress og WooCommerce og i hvilken rekkefølge, hvordan jeg sjekker om nettstedet er endret, og når en norsk nettbutikk må melde avvik til Datatilsynet.

Artikkelen bygger på kildene slik de sto på publiseringsdagen. Den er ikke juridisk rådgivning for din virksomhet.

#Hva skjedde hos DreamHost i oktober 2026

DreamHost publiserte en kunngjøring 29. oktober 2026 (DreamHost, October security incident) og sendte inn et varsel til justisministeren i California 2. november (California AG, DreamHost, LLC). TechCrunch omtalte saken 4. november (TechCrunch, Zack Whittaker).

Tidslinjen slik kildene viser den:

Angrepsveien var filbehandleren på files.dreamhost.com, som bygger på programvare fra en tredjepart. Ifølge brevet utnyttet angriperen en sårbarhet i den programvaren. Hvilket produkt og hvilken sårbarhet det gjelder, er ikke oppgitt, og en talsperson ville ikke si det til TechCrunch. DreamHost skriver også at hendelsen ikke hadde sammenheng med de nylige PHP-oppdateringene på serverne.

#Hva ble tatt

Her holder jeg meg tett til ordlyden i DreamHosts egne tekster:

• FTP- og SFTP-brukernavn og passord for dem som logget inn i filbehandleren mellom omtrent august 2026 og 23. oktober 2026.
• Webmail: brevet sier at øktinformasjonen (dataene som holder en bruker innlogget, inkludert øktlegitimasjon) for et begrenset antall webmail-brukere kan ha blitt eksponert. Kunngjøringen kaller det i stedet innloggingsopplysninger for webmail. De to DreamHost-tekstene er altså ikke like. Innholdet i postkassene kan ha blitt sett i et lite antall tilfeller.
• Brevet sier også at annen informasjon, som innholdet i e-posten og filene på FTP/SFTP-serveren, kan ha blitt lest.

DreamHost har ikke funnet tegn på at innloggingen til kontrollpanelet eller betalingsopplysninger er berørt. Fullstendige kortnumre lagres ikke hos DreamHost.

Omfanget er oppgitt som «godt under omtrent 10 %» (egen oversettelse) av e-post- og FTP/SFTP-kontoene. Varselet til California AG oppgir ikke antall berørte. Overskriften hos TechCrunch snakker om et angrep som varte i måneder og om stjålne filer og innbokser. DreamHosts eget brev bruker «kan ha». Om angriperen var inne fra midten av august, eller bare samlet passord fra da av, er ikke opplyst.

#Hva DreamHost ber kundene om å gjøre

• Bytte passord i kontrollpanelet. Bare kontoinnehaveren kan gjøre det, og endringen kan ta opptil 15 minutter.
• Regne FTP/SFTP-passord som ble brukt i filbehandleren i perioden, som kompromittert, og bytte samme eller lignende passord på alle andre kontoer.
• Oppdatere e-post-, FTP- og SFTP-klienter som har det gamle passordet lagret.
• Gå gjennom filene på nettstedet for uventede endringer.
• Sjekke e-postinnstillinger, videresendingsregler og filtre for endringer de ikke kjenner igjen.
• Vurdere om innholdet i e-post eller filer gir tilgang til andre kontoer.
• Ignorere uoppfordrede e-poster om tilbakestilling. DreamHost ber aldri om passord på e-post.

#Hvorfor er SFTP-passordet bare begynnelsen for WordPress

DreamHost nevner ikke databasepassord, SSH-brukere eller API-nøkler. For et WordPress-nettsted er det likevel her det store problemet ligger. Den som har SFTP-tilgang til filene, kan lese wp-config.php. Den filen inneholder databasenavn, databasebruker og databasepassord, og de åtte nøklene og saltene som WordPress bruker til å signere innloggingskapsler. Dette er min slutning, ikke noe DreamHost har sagt. Men det er grunnen til at jeg behandler en SFTP-lekkasje som en lekkasje av alt som står i wp-config.php.

I en WooCommerce-butikk ligger det mer i databasen: kundenavn, adresser, e-post, telefonnumre og ordrehistorikk, REST API-nøkler for integrasjoner, og ofte innstillingene til betalingsutvidelsen med API-nøkler til Stripe eller en annen leverandør. Har angriperen databasepassordet og databasen er tilgjengelig utenfra, er alt dette innen rekkevidde.

#I hvilken rekkefølge bytter jeg passord og nøkler

WordPress.org sin veiledning for hackede nettsteder sier at du skal bytte alle tilgangspunkter: FTP/SFTP, wp-admin, kontrollpanelet hos webhotellet og MySQL, for alle brukere med tilgang (WordPress.org, FAQ My site was hacked). Rekkefølgen under er min egen. Prinsippet er å stenge de dørene som gir tilgang til de andre dørene først.

1. Din egen maskin. WordPress.org anbefaler en full virusskanning, fordi trojanere kan fange opp FTP- og wp-admin-innlogginger. Et nytt passord som skrives inn på en infisert maskin, er tapt med en gang.
2. E-postkontoene. Bytt passordet til postkassene, og sjekk videresendingsregler og filtre slik DreamHost ber om. Lenker for å tilbakestille passord til wp-admin, Stripe og webhotellet går til denne innboksen. En skjult videresendingsregel ville gitt angriperen de nye passordene dine.
3. Kontrollpanelet hos webhotellet. Bytt passordet og slå på totrinnsinnlogging hvis webhotellet tilbyr det.
4. SFTP og SSH. Bytt passordet for alle SFTP-brukere, og fjern brukere du ikke kjenner igjen. Gå gjennom autoriserte SSH-nøkler på kontoen.
5. Databasepassordet. Bytt passordet for databasebrukeren i kontrollpanelet, og skriv det nye inn i wp-config.php med en gang, ellers går nettstedet ned. WordPress.org nevner at du også kan bytte selve databasebrukeren.
6. Nøkler og salter i wp-config.php. Nye salter gjør alle innloggingskapsler ugyldige, slik at alle må logge inn på nytt (WordPress Developer Resources, wp-config.php).
7. Administratorkontoer og passord i wp-admin. Fjern ukjente administratorer, og bytt passordet for de som skal bli.
8. Applikasjonspassord. Gå gjennom og trekk tilbake dem du ikke trenger.
9. WooCommerce REST API-nøkler. Trekk tilbake og lag nye nøkler til integrasjonene.
10. Stripe-nøkler og signeringshemmeligheten for webhooks.

WordPress.org har ett råd til som er lett å glemme: bytt passordene igjen etter at nettstedet er rent. Har du bare byttet dem da du oppdaget innbruddet, skal du bytte dem en gang til nå.

#Nye salter med WP-CLI

wp config shuffle-salts

Kommandoen «fornyer saltene som er definert i wp-config.php-filen» (egen oversettelse) (WP-CLI, config shuffle-salts). Uten WP-CLI henter du nye verdier fra https://api.wordpress.org/secret-key/1.1/salt/ og limer dem inn over de gamle i wp-config.php.

#Applikasjonspassord

Applikasjonspassord ligger under hver bruker i wp-admin. Hvert passord har en dato og IP-adresse for siste bruk, nøyaktig innen 24 timer (Make WordPress Core, Application Passwords). Et passord du ikke kjenner igjen, eller som er brukt fra en IP du ikke kjenner, er et tegn på at noen har vært inne. Med WP-CLI:

wp user application-password list <bruker>
wp user application-password delete <bruker> <uuid>

(WP-CLI, user application-password)

#WooCommerce REST API-nøkler

I det engelske grensesnittet ligger nøklene under WooCommerce, Settings, Advanced, REST API. Der finner du alle nøkler med bruker, rettigheter og siste tilgang. Velg «Revoke Key» for hver nøkkel, og lag nye til integrasjonene som skal fortsette å virke, for eksempel lager, regnskap eller frakt (WooCommerce, REST API). Lag en liste over integrasjonene før du trekker tilbake noe, slik at du vet hvem som skal ha nye nøkler.

#Stripe-nøkler og webhook-hemmeligheten

Stripe skriver at du skal rotere nøkkelen hvis en hemmelig eller begrenset API-nøkkel er kompromittert (Stripe, API keys). Når du roterer i dashbordet, kan den gamle og den nye nøkkelen virke samtidig i opptil 7 dager. Etter et innbrudd vil du ikke ha den perioden: velg utløp «Now», så slettes den gamle nøkkelen med en gang. Legg samtidig inn den nye nøkkelen i WooCommerce, ellers stopper betalingene. Stripe lar deg også begrense live-nøkler til bestemte IP-adresser eller nettverk.

Signeringshemmeligheten for webhooks er en egen hemmelighet. Stripe anbefaler å rullere den med jevne mellomrom, eller når du mistenker at den er kompromittert. Når du ruller den, kan den gamle være gyldig i opptil 24 timer (Stripe, webhooks). Den nye hemmeligheten skal inn i innstillingene til Stripe-utvidelsen i WooCommerce.

Bruker butikken en annen betalingsleverandør, gjelder det samme prinsippet: alle API-nøkler som ligger i databasen eller i filene, regnes som lest.

#Hvordan sjekker jeg om nettstedet er endret

Nye passord stopper ny tilgang, men en bakdør som allerede ligger i filene eller databasen, blir liggende. Disse kontrollene kjører jeg derfor på hvert nettsted etter et innbrudd hos webhotellet.

Ukjente administratorer:

wp user list --role=administrator

Standardfeltene inkluderer user_registered, så en administrator som er opprettet i perioden august til oktober, skiller seg ut (WP-CLI, user list).

Kjernefilene:

wp core verify-checksums --include-root

Kommandoen sammenligner WordPress-filene med sjekksummene fra WordPress.org. Med --include-root får du også advarsel om filer i rotmappen som ikke hører til WordPress (WP-CLI, core verify-checksums).

Utvidelsene:

wp plugin verify-checksums --all

Med --strict tas også endringer i readme-filer med (WP-CLI, plugin verify-checksums). Kommandoen sjekker mot sjekksummer fra WordPress.org. Premium-utvidelser og egne utvidelser blir derfor ikke kontrollert. Dem installerer jeg på nytt fra leverandøren, eller sammenligner med en ren kopi fra versjonskontroll.

Filene jeg ser på manuelt, etter WordPress.org sin liste: .htaccess i roten og i undermapper, index.php, og header.php, footer.php og functions.php i temaet. Mappene /wp-admin og /wp-includes erstatter jeg med en ren kopi av samme WordPress-versjon.

Finner du endrede filer eller ukjent kode, er nettstedet infisert. Da følger du en full opprydding før du bytter passordene for andre gang. Den har jeg beskrevet i guiden til fjerning av skadevare fra WordPress.

#Må nettbutikken melde avvik til Datatilsynet

Personvernforordningen gjelder i Norge gjennom EØS-avtalen og personopplysningsloven § 1 (Lovdata, personopplysningsloven § 1). Webhotellet er databehandler, du som driver nettbutikken, er behandlingsansvarlig. Meldeplikten til Datatilsynet og plikten til å varsle kundene ligger hos deg. Webhotellets plikt er å varsle deg.

Dette er artiklene som gjelder (personvernforordningen, EUR-Lex):

#Når starter de 72 timene

EDPBs retningslinjer 9/2022 svarer på dette i punkt 44: den behandlingsansvarlige bør i prinsippet anses som kjent med avviket når databehandleren har informert om det (egen oversettelse) (EDPB, Guidelines 9/2022). Punkt 31 sier at «kjent med» betyr en rimelig grad av sikkerhet for at en sikkerhetshendelse har ført til at personopplysninger er kompromittert. Databehandleren vurderer ikke risikoen. Det gjør du.

For en DreamHost-kunde betyr det at klokken i prinsippet begynner å gå når varselet fra DreamHost kom fram, altså e-posten om tilbakestilt passord 23. til 25. oktober eller det formelle brevet. Den begynner ikke 15. august.

#Må du melde

Det avhenger av risikovurderingen. Mitt syn, og ikke en avgjørelse fra noen myndighet i denne saken: SFTP-passord som åpner wp-config.php og dermed WooCommerce-databasen med navn, adresser og ordrehistorikk, peker mot et avvik som skal meldes. Et rent informasjonsnettsted uten personopplysninger trenger kanskje bare den interne dokumentasjonen etter artikkel 33 nr. 5. Er du i tvil, er det tryggere å melde og forklare vurderingen enn å la være.

#Slik melder du til Datatilsynet

Datatilsynet skriver at avviket «skal […] meldes til Datatilsynet av den behandlingsansvarlige gjennom Altinn» (Datatilsynet, meld avvik). Har du ikke all informasjonen innen 72 timer, kan du melde i flere omganger. Send den første meldingen innen fristen, og fyll ut resten når du vet mer.

Det jeg samler før meldingen:

• datoen og klokkeslettet varselet fra webhotellet kom
• hvilke tilganger som ble eksponert (SFTP, e-post, database)
• hvilke kategorier personopplysninger som ligger i butikken, og omtrent hvor mange kunder
• hva du har gjort: byttede passord og nøkler, kontrollene over og resultatet av dem
• om kundene skal varsles etter artikkel 34, og hvordan

Det samme notatet er dokumentasjonen etter artikkel 33 nr. 5, også hvis du konkluderer med at du ikke skal melde.

#Sjekklisten samlet

#Neste steg

Start med e-posten og kontrollpanelet i dag, og skriv ned klokkeslettet varselet fra webhotellet kom, fordi det er der fristen på 72 timer begynner. Viser kontrollene at filer er endret, følger du guiden til fjerning av skadevare fra WordPress. Vil du ha hjelp til å gå gjennom en WooCommerce-butikk etter et innbrudd hos webhotellet, se hvordan jeg jobber med WooCommerce.