Kort sagt: En WordPress-opdatering hjælper ikke mod PHP-sårbarheden PHP2Shell, fordi fejlen ikke sidder i WordPress, men i PHP, softwaren på serveren, som kører WordPress. Ifølge Dr. Web planlægger WordPress.org derfor heller ingen egen opdatering. Beskytte kan kun en PHP-opdatering på serveren med genstart af alle PHP-processer. Den indspiller som regel jeres hostingudbyder eller serverens driftsansvarlige.
Udgangspunktet: „Vi har da opdateret alt“
Efter de første overskrifter om PHP2Shell har mange driftsansvarlige gjort det nærliggende: åbnet WordPress-dashboardet, klikket på „Opdatér nu“ og opdateret plugins og temaer med det samme. Bagefter er alt grønt, og følelsen siger: afsluttet.
Ved denne sårbarhed bedrager følelsen. Det skyldes ikke WordPress, men hvor fejlen sidder. Også Cloudflare gør i sin meddelelse opmærksom på, at en opdatering af applikationskode eller plugins ikke udbedrer sårbarhederne.
WordPress-opdatering og PHP-sårbarhed: lagmodellen
Et WordPress-website består af flere lag, der bygger oven på hinanden. Hvert lag har egne opdateringer og ofte egne ansvarlige:
| Lag | Eksempel | Hvem opdaterer typisk | Berørt af PHP2Shell? |
|---|---|---|---|
| Operativsystem | Debian, Ubuntu, AlmaLinux | hostingudbyder eller serveradministrator | nej, men leverer ofte PHP-pakken |
| Webserver | Apache, Nginx, LiteSpeed | hostingudbyder eller serveradministrator | driftsformen påvirker risikoen |
| PHP-kørselsmiljø | PHP-FPM, mod_php | hostingudbyder eller serveradministrator | ja, her ligger sårbarheden |
| WordPress-kerne | WordPress | driftsansvarlig eller bureau | nej |
| Plugins og temaer | WooCommerce, page builder | driftsansvarlig eller bureau | nej |
Opdateringsknappen i dashboardet når kun de to nederste rækker. PHP-kørselsmiljøet ligger under og er usynligt for WordPress. Hvordan andre systemer bygger på PHP, beskriver indlægget CMS og shops på PHP.
Hvorfor WordPress ikke kan lukke sårbarheden
Man kunne mene, at WordPress da kan „programmere uden om“. Det fungerer ikke ved PHP2Shell af to grunde.
For det første ligger begge fejl i den måde, PHP behandler forespørgsler på og rydder op bagefter. Det sker uafhængigt af, hvilket program der kører i PHP. For det andet har PHP-teamet vist en exploit til Apache med mod_php, som virker, før der overhovedet udføres applikationskode. WordPress, dets plugins og ethvert sikkerhedsplugin kommer så slet ikke i spil.
Af samme grund hjælper heller intet „hærdningsplugin“, der ændrer indstillinger via ini_set(). php.net fraråder udtrykkeligt at indstille midlertidige foranstaltninger på den måde.
Og ved managed WordPress?
Ved managed WordPress-tilbud tager udbyderen sig ofte ikke kun af WordPress-opdateringer, men også af serveren under. Det er en fordel ved PHP2Shell, men ikke en automatik. Spørg konkret, om PHP-opdateringen er indspillet, og alle PHP-processer genstartet. Udsagnet „Vi holder jeres WordPress opdateret“ besvarer ikke det spørgsmål.
Mange websites, én PHP-installation
Bureauer og virksomheder med flere websites bør kende et særligt forhold: På en server deler mange WordPress-installationer ofte den samme PHP-version. Er den upatchet, er alle berørt, uanset hvor godt hvert enkelt website vedligeholdes. Omvendt beskytter en PHP-opdatering alle installationer på én gang, forudsat at alle tilhørende PHP-processer genstartes bagefter. Den, der driver flere PHP-versioner parallelt, må opdatere hver enkelt.
Et grønt WordPress-dashboard siger intet om PHP2Shell. Afgørende er PHP's patchstatus på serveren og genstart af alle PHP-processer.
Sådan læser I PHP-versionen i WordPress rigtigt
WordPress viser PHP-versionen: i dashboardet under Værktøjer, Webstedets tilstand, i området Rapport under afsnittet Server. Det er et godt første fingerpeg, men ikke et bevis.
Står der en gren som 8.1 eller ældre, er det et klart advarselssignal, for dertil findes der ikke længere officielle opdateringer. Står der 8.2.35, 8.3.36, 8.4.27 eller 8.5.12, er den rettede version installeret. Står der et ældre nummer på en understøttet gren, kan en backport alligevel være indspillet. Distributioner og hostingudbydere ændrer ofte ikke nummeret derved. Klarhed skaber kun hostingudbyderens bekræftelse eller et blik i pakkens changelog. Hvordan det gøres, står under Kontrollér PHP-version og patchstatus.
Hvad WordPress-ejere bør gøre i stedet
- Spørg hostingudbyderen eller serverens driftsansvarlige: Er PHP patchet, hvornår, og blev alle PHP-processer genstartet? Svar skriftligt.
- Kontrollér PHP-grenen: Kører websitet på 8.1 eller ældre, planlæg skiftet til en understøttet gren. Hvilken version jeres WordPress-version understøtter, står i systemkravene på wordpress.org. Skiftet i kundemenuen beskriver Skift PHP-version i hostingens kundeområde.
- Undersøg for spor: nye PHP-filer i
wp-content/uploads, ukendte administratorkonti, fremmede poster imu-plugins. De typiske skjulesteder beskriver siden WordPress og PHP2Shell. - Hold alligevel WordPress aktuelt: Kerne, plugins og temaer lukker andre sårbarheder. Det er fortsat en pligt, blot en anden.
- Afklar ansvaret: Hvis et bureau passer websitet, så fasthold, om det også er ansvarligt for PHP eller kun for WordPress.
Netop det sidste punkt skaber ofte huller. Bureauet vedligeholder WordPress, hostingudbyderen serveren, og begge tror, at den anden har PHP2Shell under kontrol.
Hvordan hjælper PHP SOS konkret?
- Afklare lagene: Vi fastslår, hvem der ved jeres WordPress-website er ansvarlig for hvilket lag.
- Opdatere PHP: På egne eller administrerede servere indspiller vi PHP-opdateringen og genstarter alle processer.
- Undersøge WordPress: Vi leder efter spor af et angreb i filer, database og konti.
- Dokumentation: I modtager patchstatus skriftligt, også til videregivelse til bureau eller kunder.
Forløbet beskrives under PHP-patchservice.
Konklusion
WordPress-opdateringen er god vedligeholdelse, men mod PHP2Shell det forkerte lag. Sårbarheden sidder en etage dybere, i PHP på serveren. Den, der forstår det, stiller det rigtige spørgsmål til det rigtige sted: Er PHP patchet, genstartet og dokumenteret?
Ofte stillede spørgsmål
Udgiver WordPress en sikkerhedsopdatering mod PHP2Shell?
Ifølge Dr. Web planlægger WordPress.org ingen opdatering mod PHP2Shell, fordi sårbarheden ligger i PHP-fortolkeren på serveren. Afhjælpning skaber kun en PHP-opdatering fra hostingudbyderen eller serverens driftsansvarlige.
Hvor ser jeg PHP-versionen i WordPress?
I dashboardet under Værktøjer, Webstedets tilstand, i området Rapport under afsnittet Server. Det viste nummer siger dog ikke sikkert, om patchen er indspillet, fordi hostingudbydere ofte bygger rettelser ind som backport uden nyt versionsnummer.
Beskytter et sikkerhedsplugin mod PHP2Shell?
Kun meget begrænset. Et plugin kører selv i PHP og bliver først aktivt, når WordPress er indlæst. Ved Apache med mod_php blev der ifølge PHP-teamet vist en exploit, før der overhovedet kører applikationskode. Dér kan et plugin ikke gribe ind.
Skal jeg alligevel opdatere WordPress?
Ja. Aktuelle versioner af WordPress, temaer og plugins lukker andre sårbarheder og er en del af god vedligeholdelse. De løser bare ikke problemet PHP2Shell.