# Skifte CMS efter hacket? Hvornår det hjælper, og hvornår ikke

> Skifte CMS efter et hack? Hvornår et nyt system virkelig hjælper, hvornår det blot flytter indsatsen, og hvordan I flytter indhold uden skadelig kode.

Kilde: https://phpsos.de/da/blog/cms-wechsel-nach-hack/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** At skifte CMS efter et hack hjælper kun, hvis det gamle system selv var årsagen, f.eks. fordi producenten ikke længere leverer sikkerhedsopdateringer, eller vigtige udvidelser ikke længere vedligeholdes. Lå årsagen i forældede plugins, svage adgange eller en sårbarhed som PHP2Shell i det underliggende PHP, flytter et skifte blot indsatsen. I alle tilfælde gælder: Kontrollér indhold først, flyt så, ellers følger den skadelige kode med.

## Når tilliden er væk

Efter et indbrud er stemningen ofte entydig: "Aldrig mere med dette system." Det er forståeligt. Websitet har omdirigeret besøgende til fremmede sider, Google har advaret, kunder har spurgt. Et nyt CMS føles som en nystart.

Situationen omkring PHP2Shell viser dog, hvorfor denne refleks kan lede på afveje. Sårbarheden sidder i PHP-fortolkeren, ikke i WordPress, TYPO3, Shopware eller et andet system. WordPress.org planlægger ifølge drweb.de derfor ikke en egen opdatering mod den. Den, der nu skifter fra et PHP-CMS til et andet PHP-CMS, har til sidst den samme afhængighed, blot med et andet logo. Hvilke systemer der kører på PHP, viser oversigten [Hvilke CMS- og shopsystemer der kører på PHP](https://phpsos.de/da/php/cms-und-shops-auf-php/).

## Hvad årsagen var, afgør

Før I overvejer et skifte, skal indbruddets årsag være afklaret. Typiske indgangsveje er forældede udvidelser, genbrugte eller svage adgangskoder, manglende totrinslogin, en upatchet server eller glemte testinstallationer. Ingen af disse årsager er knyttet til et bestemt CMS.

Den, der ikke kender årsagen, risikerer at tage den med over i det nye system. Et team, der hidtil har udskudt opdateringer, vil gøre det samme i det nye CMS. Et bureau, der brugte fælles admin-konti, vil gentage det, hvis ingen ændrer forløbet. Spørgsmålet er altså mindre "hvilket CMS?" end "hvilken proces?".

## Skifte CMS efter hacket: afvejningen

| Kriterium | Blive ved det eksisterende CMS og hærde | Skifte til et andet CMS |
|---|---|---|
| Indbruddets årsag | Kendt og kan udbedres, f.eks. forældet plugin | Ligger i selve systemet, f.eks. manglende producentopdateringer |
| Producentens vedligeholdelse | Sikkerhedsopdateringer leveres | Producenten har indstillet vedligeholdelsen |
| Afhængighed af udvidelser | Få, vedligeholdte udvidelser | Mange udvidelser uden aktiv vedligeholdelse |
| Indsats | Oprydning, hærdning, procesændring | Genopbygning, migrering, uddannelse, ofte nyt design |
| Tid til et sikkert website | Kortere | Længere, overgangsløsning nødvendig |
| Beskyttelse mod PHP-sårbarheder | Ingen ændring, PHP skal patches | Ingen ændring, så længe det nye system bruger PHP |
| Langsigtet nytte | Høj, hvis processerne forbedres | Høj, hvis det gamle system alligevel var udtjent |

Hvis de fleste rækker i jeres situation lander til venstre, kan et skifte næppe betale sig. At blive, rydde op, hærde og forbedre vedligeholdelsesforløbet giver mere sikkerhed for færre penge. For WordPress-driftsansvarlige opsummerer [WordPress og PHP2Shell](https://phpsos.de/da/plattformen/wordpress/) de vigtigste skridt.

En leverandør har I ikke altid brug for til denne beslutning. Var årsagen entydig, f.eks. et kendt plugin med en offentliggjort sårbarhed, og har jeres bureau eller jeres administrator sat websitet rent op på ny, kan I selv beslutte. Ekstern hjælp kan betale sig, hvis årsagen forbliver uklar, eller personoplysninger kan være berørt.

## Hvis I skifter: Tag ikke den skadelige kode med

Falder beslutningen på et skifte, er selve migreringen en sikkerhedsrisiko. Angribere efterlader spor ikke kun i filer, men også i databasen. Disse skridt hjælper med at flytte rent:

1. **Sikre og isolere det gamle system:** Fuldstændig sikring som bevis, tag så det gamle system af nettet, eller gør det kun tilgængeligt internt.
2. **Eksportere indhold målrettet:** Tekster, sidestruktur og medier, ikke hele databasen. Overtag ikke brugerkonti, men opret dem på ny.
3. **Kontrollere indhold:** Gennemse tekster for indsmuglede scripts, skjulte links og fremmede omdirigeringer. Hvordan det gøres, beskriver [Kontrollér databasen for indsmuglet kode](https://phpsos.de/da/blog/datenbank-auf-schadcode-pruefen/).
4. **Filtrere medier:** Overtag kun forventede filtyper, sortér filer med dobbelte endelser eller scriptindhold fra.
5. **Sætte det nye system rent op:** Fra producentens originalkilde, på en server med patchet PHP, med nye adgangsoplysninger og totrinslogin.
6. **Planlægge omdirigeringer:** Omdirigér gamle adresser til nye, så søgemaskiner og besøgende når frem, uden at gamle stier forbliver åbne.

> **Vigtigt:**
> Et CMS-skifte erstatter ikke en oprydning af den gamle server. Kører det gamle system videre, f.eks. som en glemt kopi under et subdomæne, forbliver bagdøren åben.

## Alternativet, der ofte overses

Nogle virksomheder konstaterer efter et hack, at de slet ikke har brug for funktionerne i et stort CMS. Et virksomhedswebsite med få sider, der sjældent ændres, klarer sig også uden PHP på serveren. En generator til statiske sider producerer færdige HTML-filer, som ikke længere kræver serverside-programlogik. Hvilke fordele og ulemper det har, beskriver [Statiske websites: Mindre PHP, mindre angrebsflade](https://phpsos.de/da/blog/statische-website-alternative/).

Omvendt er det for shops, portaler eller websites med mange redaktører som regel ikke en mulighed. Her forbliver et dynamisk system fornuftigt, og sikkerheden opstår gennem vedligeholdelse, hærdning og overvågning.

Den, der er usikker på, om der i den gamle WordPress stadig lurer skjulte adgange, finder i [Find bagdøre i WordPress](https://phpsos.de/da/ratgeber/backdoor-wordpress-finden/) de typiske fundsteder. Det hjælper også ved beslutningen om, hvorvidt en oprydning er realistisk.

## Hvordan hjælper PHP SOS konkret?

- Vi afklarer først indbruddets årsag og siger jer, om den ligger i CMS'et eller i proces og server.
- Vi rydder det eksisterende system op inden for rammerne af [fjernelse af malware](https://phpsos.de/da/leistungen/malware-entfernung/) eller forbereder det som bevis til en genopbygning.
- Ved et skifte kontrollerer vi de indhold og medier, der skal overtages, for skadelig kode, før de når ind i det nye system.
- Vi sætter den nye server op med patchet PHP og hærdet konfiguration.

## Konklusion

Et CMS-skifte efter et hack er sjældent løsningen, men nogle gange den rette anledning. Hvis det gamle system ikke længere vedligeholdes, kan nystarten betale sig. Hvis årsagen lå i processer eller på serveren, giver arbejdet med processen mere end et nyt logo. I begge tilfælde gælder: Først kontrollere, så flytte.


## Ofte stillede spørgsmål

**Hjælper et CMS-skifte mod PHP2Shell?**  
Nej, så længe det nye CMS også kører på PHP. PHP2Shell sidder i PHP-fortolkeren, ikke i CMS'et. Afgørende er PHP's patch-status på serveren, ikke systemet ovenpå.

**Er WordPress mindre sikkert end andre CMS?**  
Det kan ikke siges generelt. Mange indbrud opstår på grund af forældede udvidelser, svage adgange eller manglende opdateringer, og disse årsager findes i ethvert system. Udbredelsen gør dog et CMS til et hyppigere mål for automatiserede scanninger.

**Kan jeg bare eksportere indhold fra det hackede CMS?**  
Kun efter kontrol. Databasen kan indeholde indsmuglede scripts, skjulte links eller fremmede admin-konti. Uploadede filer kan skjule skadelig kode. Eksportér indhold målrettet, og kontrollér det før import.

**Hvornår er et CMS-skifte virkelig fornuftigt?**  
Hvis producenten ikke længere leverer sikkerhedsopdateringer, hvis websitet er afhængigt af udvidelser, der ikke længere vedligeholdes, eller hvis systemet simpelthen ikke længere passer til nutidens krav. Hacket er så anledningen, ikke grunden.

## Kilder

- [WordPress.org](https://wordpress.org/)
- [TYPO3](https://typo3.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Dr. Web: PHP2Shell og WordPress](https://www.drweb.de/php2shell-update-php-versionen/)