Kort sagt: För att kontrollera CMS-kärnfiler jämför ni de installerade filerna med ett rent original av samma version: för WordPress via de officiella kontrollsummorna, för andra system via en ny nedladdning eller en uppbyggnad utifrån composer.lock. Varje avvikelse är ett kontrolluppdrag. Jämförelsen hittar även okänd skadlig kod, men täcker bara filer som det finns ett original till.
Varför jämförelsen hittar mer än varje signatur
Skannrar för skadlig kod letar efter kända mönster. Det de inte känner igen missar de. En jämförelse med originalet arbetar tvärtom: den frågar inte om en fil ser misstänkt ut, utan om den exakt motsvarar det tillverkaren har levererat. Varje avvikelse upptäcks, oavsett om den följer ett känt mönster eller inte.
Det är särskilt värdefullt efter PHP2Shell. För sårbarheterna CVE-2026-109618 och CVE-2026-109619 finns inga publicerade, bekräftade Indicators of Compromise. Skannrar kan alltså inte söka riktat efter PHP2Shell-spår. En jämförelse med originalet hittar däremot varje förändring i kärnan, oavsett hur den har uppstått. Varför skannrar ensamma inte räcker förklarar inlägget Skannrar för skadlig kod på webbplatser: vad de hittar och vad de inte hittar.
Principen: samma version, ren källa
En jämförelse är bara så bra som sin referens. Tre villkor måste vara uppfyllda:
- Exakt samma version: En jämförelse mot en nyare version visar hundratals ofarliga skillnader. Ta reda på den installerade versionen i applikationen eller i
composer.lock. - Officiell källa: Originalet kommer från tillverkaren, från den officiella paketkatalogen eller från ert eget versionshanteringssystem. Inte från en gammal säkerhetskopia av den berörda servern.
- Jämförelse på en kopia: Arbeta på en säkrad kopia av webbkatalogen så att tidsstämplar och spår bevaras.
| System | Referens | Verktyg |
|---|---|---|
| WordPress-kärna och tillägg från katalogen | Kontrollsummor från WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer-projekt (t.ex. Shopware 6, Laravel, Symfony, Drupal, TYPO3 i Composer-läge) | Uppbyggnad utifrån composer.lock |
composer install i en tom katalog, sedan diff |
| CMS med nedladdningspaket | Paket av samma version från tillverkaren | diff -rq |
| Egna projekt med Git | senast kända commit | git status, git diff |
| Serverns systempaket | Distributionens paketdatabas | dpkg --verify, rpm -Va |
WordPress: mer än verify-checksums
Hur ni kontrollerar kärna och tillägg med WP-CLI står i guiden Hitta bakdörrar i WordPress. Ett tillägg lönar sig: enligt WP-CLI-dokumentationen kontrollerar alternativet --include-root alla filer och mappar i rotkatalogen och varnar för poster som inte hör till WordPress. Där lägger angripare gärna filer vars namn påminner om kärnfiler.
# Kärnan mot officiella kontrollsummor, inklusive främmande filer i rotkatalogen
wp core verify-checksums --include-root
Kommersiella tillägg och teman fångas inte av den vägen. För dem laddar ni ned originalpaketet av samma version hos leverantören och jämför med diff.
Kontrollera CMS-kärnfiler i Composer-projekt
Många moderna PHP-applikationer består till största delen av paket som Composer installerar, pakethanteraren för PHP. Hur den fungerar förklarar sidan Composer: pakethanteraren för PHP. Filen composer.lock fastställer exakt vilka versioner som är installerade. Enligt Composer-dokumentationen använder composer install dessa exakta versioner. Därmed går leveransläget att bygga upp på nytt:
# På ett rent system, inte på den berörda servern
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Lista skillnaderna i vendor-mappen
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Alternativen --no-scripts och --no-plugins hindrar att skript från paketen körs vid uppbyggnaden. Om produktionen installerades med --no-dev använder ni det alternativet även vid uppbyggnaden, annars dyker utvecklingspaket upp som skillnad. Lägg märke till två slags resultat: filer som skiljer sig åt och filer som bara finns på servern. Den andra gruppen är ofta den intressantare. Hur ni dessutom kontrollerar de installerade paketen efter kända sårbarheter beskriver guiden Kontrollera Composer-beroenden efter sårbarheter.
Jämför även operativsystemet
Hade en angripare root-rättigheter kan han också ha ersatt systemprogram. Pakethanterarna har en egen avstämning:
# Debian, Ubuntu: filer vars innehåll avviker från paketet
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: kontrollera alla paket
sudo rpm -Va
En 5 på tredje plats i utdata betyder att en fils innehåll har ändrats. Enligt dpkg-manualen är innehållsjämförelsen där för närvarande den enda verksamma kontrollen. Ändrade konfigurationsfiler är normala och markeras med c. Ett ändrat program i /usr/bin är däremot ett allvarligt larmtecken. Observera: en angripare med root-rättigheter kan också manipulera paketdatabasen. Vid misstanke om root-åtkomst är en ominstallation mer tillförlitlig än varje avstämning.
Ett versionshanteringssystem för applikationskoden gör framtida avstämningar till en fråga om sekunder. git status visar då varje avvikelse från den godkända versionen.
Bedöma avvikelser och känna till gränserna
Inte varje avvikelse är ett angrepp. Vissa byråer har tidigare anpassat kärnfiler direkt i stället för att använda tillägg. Språkpaket, radslut efter en överföring via FTP eller i efterhand installerade rättelser ger också skillnader. Avgörande är om någon kan förklara ändringen.
Gå igenom varje avvikelse för sig och notera resultatet: känd och dokumenterad, ofarlig och förklarlig eller oklar. Oklara filer öppnar ni bara som text på en kopia och ersätter från den rena källan. För filer som bara finns på servern är frågan enklare: den som inte känner igen dem bör säkra dem och låta ta bort dem efter att deras innehåll har granskats.
Uppladdningar, konfigurationsfiler som wp-config.php eller .env, egna anpassningar och cacher har inget original. De måste kontrolleras riktat, liksom databasen, cronjobb, användarkonton och SSH-nycklar. En ren avstämning är därför en viktig byggsten men ingen friskrivning för hela servern.
Hur hjälper PHP SOS konkret?
- Vi tar reda på de installerade versionerna och bygger upp en ren referens från officiella källor.
- Vi jämför kärna, tillägg, Composer-paket och systemprogram och bedömer varje avvikelse.
- Vi kontrollerar områdena utan original riktat och ersätter ändrade filer från ren källa inom ramen för borttagning av skadlig kod.
- På begäran inrättar vi en version mot vilken framtida kontroller körs.
Vanliga frågor
Hur kontrollerar jag om WordPress kärnfiler har ändrats?
Med WP-CLI och kommandot wp core verify-checksums. Det jämför filerna med de kontrollsummor som WordPress.org publicerar för den installerade versionen. Med alternativet --include-root varnar WP-CLI dessutom för filer i rotkatalogen som inte hör till WordPress.
Vad gör jag med ett CMS utan inbyggd kontrollfunktion?
Ni laddar ned exakt samma version från tillverkarens officiella källa och jämför de båda katalogerna med diff. För Composer-projekt bygger ni upp versionen från composer.lock i en tom katalog och jämför vendor-mappen.
Hittar jämförelsen också skadlig kod i tillägg och teman?
Bara om det finns ett rent original till dem, till exempel från den officiella katalogen eller från leverantören. Egna anpassningar, uppladdningar och konfigurationsfiler har inget original och måste kontrolleras separat.
Ersätter jämförelsen en skanner för skadlig kod?
Den kompletterar den. Jämförelsen hittar varje förändring av kända filer, även okänd skadlig kod. Men den säger ingenting om filer utan original, databasen, cronjobb eller åtkomster.