WordPress PHP-sårbarhed PHP2Shell: Hvad driftsansvarlige skal gøre

Kort sagt: PHP-sårbarheden, som WordPress-sites pt. høres om, sidder ikke i WordPress, men i PHP på serveren nedenunder. En WordPress-opdatering lukker derfor ikke PHP2Shell. Det afgørende er PHP's patch-status, genstart af alle PHP-processer og en kontrol af typiske skjulesteder som wp-content/uploads og mu-plugins.

Hvorfor en WordPress-opdatering ikke afhjælper PHP2Shell

WordPress er en applikation, der er skrevet i PHP. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 ligger et lag dybere, i selve PHP-fortolkeren. Ifølge PHP-teamet gør de det muligt at køre skadelig kode på afstand uden login. Ved Apache med mod_php er der vist et exploit, før der overhovedet kører WordPress-kode.

Et website med en aktuel kerne, aktuelle plugins og stærke adgangskoder kan altså alligevel være sårbart, hvis PHP nedenunder er gammelt. Omvendt beviser en patchet PHP ikke, at der ikke er sket noget tidligere. Baggrunden forklarer vi under Hvad er PHP2Shell?.

WordPress PHP-sårbarhed: kontrollér PHP-versionen

I dashboardet finder I under Værktøjer > Webstedets tilstand > Info i afsnittet "Server" den PHP-version, som jeres website faktisk kører med. Det er mere sigende end php -v på kommandolinjen, for kommandolinjen bruger ofte en anden PHP-installation end webserveren.

Det viste nummer alene er alligevel ikke nok. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Mange hostingudbydere indspiller dog rettelserne som backport; så står der fortsat et ældre nummer, selv om der er patchet. Hvordan I finder den reelle status, står i Kontrollér PHP-version og patch-status korrekt. Hvilke PHP-versioner jeres WordPress-version understøtter, kontrollerer I ifølge systemkravene på wordpress.org.

Hvor skadelig kode gerne gemmer sig i WordPress

Efter et vellykket angreb lægger gerningsmændene som regel en bagdør, så de kan vende tilbage selv efter rettelsen. WordPress har kendte steder til det:

• wp-content/uploads/: beregnet til billeder og PDF-filer, ikke til PHP-filer.
• wp-content/mu-plugins/: "must-use"-plugins indlæses automatisk og kan ikke deaktiveres i dashboardet.
• wp-config.php: indeholder databaseadgang og sikkerhedsnøgler; en indskudt linje opdages her næsten ikke.
• .htaccess i hovedmappen og i undermapper: omdirigeringer kun for søgemaskiner eller kørsel af usædvanlige filendelser.
• Temaer, især functions.php, samt deaktiverede, glemte plugins.
• Database: nye administratorer i wp_users, fremmed JavaScript i wp_options eller i indlæg.

Ufarlige første kontroller med WP-CLI og standardværktøjer:

# Sammenlign kernefiler med de officielle kontrolsummer
wp core verify-checksums
# Kontrollér plugins fra biblioteket på wordpress.org
wp plugin verify-checksums --all
# List PHP-filer i upload-mappen
find wp-content/uploads -type f -name "*.php"
# Vis alle administratorer
wp user list --role=administrator

Et fund er en anledning til en nøjere undersøgelse, endnu ikke et bevis. Kommercielle plugins kan ikke kontrolleres på den måde. Mere udførligt fortsætter vejledningen Find bagdøre i WordPress.

Plugins, temaer og admin-adgange som yderligere risiko

PHP2Shell kræver ingen plugin-sårbarhed. I hverdagen er plugins og temaer dog fortsat den hyppigste indgang til WordPress-websites. Hvert plugin medbringer egen kode, egne upload-funktioner og egne opdateringscyklusser. Ubrugte plugins bør I slette i stedet for blot at deaktivere dem, for deaktiverede filer ligger fortsat på serveren.

For wp-login.php og wp-admin gælder: få administratorer, personlige konti i stedet for delte adgange og totrinsgodkendelse. Hvis I ikke har brug for XML-RPC, kan det spærres. Ved mistanke bør alle adgangskoder og sikkerhedsnøglerne i wp-config.php fornyes. Filredigeringen i dashboardet slår I ligeledes fra dér:

define( 'DISALLOW_FILE_EDIT', true );

Hvad I som WordPress-driftsansvarlige bør gøre nu

1. Lad hostingudbyderen skriftligt bekræfte PHP-patch-status og genstarten af alle PHP-processer.
2. Lad serverlogs fra 20.10.2026 blive opbevaret.
3. Gennemfør kontrollerne ovenfor, eller lad dem gennemføre.
4. Opdatér WordPress, plugins og temaer. Det er rigtigt, men ingen erstatning for trin 1.
5. Ved uregelmæssigheder bør websitet ikke bare drives videre, men renses.

En platformsopdatering kan lukke kendte sårbarheder i WordPress og plugins. Den kan hverken reparere PHP eller fjerne indsmuglede filer, der ikke hører til kernen.

Hvordan hjælper PHP SOS konkret?

• Vi afklarer sammen med jer eller jeres hostingudbyder den faktiske PHP-status for jeres WordPress-website, inklusive backports og genstart.
• Vi sikrer logs, filer og database, før noget ændres.
• Vi kontrollerer kerne, plugins, uploads, mu-plugins, .htaccess og brugerkonti for bagdøre.
• Ved fund overtager vores fjernelse af malware oprydningen, indtil hændelsen er afsluttet og dokumenteret; uden fund hærder vi installationen som led i PHP2Shell-akuthjælpen.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• WordPress.org
• BSI