Kort sagt: Efter PHP2Shell bevisar den visade PHP-versionen ensam lite, eftersom webbhotell ofta levererar rättningar som backport. Begär därför en skriftlig bekräftelse från webbhotellet: paketstatus per PHP-gren samt tidpunkt för installation och omstart av alla PHP-processer. En mall att kopiera finns längre ned.
Varför en skriftlig bekräftelse räknas just nu
Den 21 oktober 2026 publicerade PHP-projektet patcharna för två kritiska sårbarheter som är kända under namnet PHP2Shell. Båda gör det möjligt att köra skadlig kod på distans utan inloggning. BSI (Tysklands federala myndighet för informationssäkerhet) har utlyst varningsnivå 3 / orange och rekommenderar omedelbar uppdatering.
Den som driver sin webbplats hos ett webbhotell kan ofta inte installera uppdateringen själv. Samtidigt bär ni som driftansvariga ansvaret för era kunders uppgifter. En skriftlig, konkret bekräftelse från webbhotellet är därför mer än en formalitet. Den är en byggsten i er dokumentation, till exempel gentemot dataskyddsombud, försäkringsgivare eller ledning.
Dessutom gäller: En patch tar inte bort skadlig programvara som fördes in tidigare. Enligt mediarapporter observerades redan den 17 oktober ett första angreppsförsök. Den exakta tidpunkt då er server var skyddad är därför viktig för frågan om ni behöver granska vidare.
Varför den visade PHP-versionen inte räcker
Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Många distributioner och webbhotell tar dock in rättningen som backport i sitt eget paket. Då visar ett gränssnitt som Plesk fortfarande 8.2.34 fast servern är patchad.
Omvänt kan ett korrekt versionsnummer vilseleda. Nya filer skyddar inte så länge gamla PHP-processer körs i minnet. Först efter en omstart av alla workers är den nya nivån aktiv. Mer om detta finns i artikeln Kontrollera PHP-version och patchstatus rätt.
| Webbhotellets uttalande | Vad det styrker | Vad som saknas |
|---|---|---|
| ”Alla system är aktuella.” | lite | Version eller paketstatus, datum, omstart |
| ”PHP 8.3.36 är installerat.” | Version | Datum, omstart, berörda servrar |
| ”Backport i paketet xy, omstart den …” | Patch och aktivering | ev. uppgifter om PHP 8.1 och äldre |
Vilka uppgifter ni behöver från webbhotellet
Be om svar på de här punkterna, helst per webbplats eller avtal:
- Vilka PHP-grenar och versioner är aktiva för era webbplatser, även äldre som bara körs för enskilda kataloger?
- Ingår rättningarna för CVE-2026-109618 och CVE-2026-109619, som officiell version eller som backport?
- När installerades uppdateringen och när startades alla PHP-processer (FPM-pooler, Apache, LiteSpeed) om?
- Är
session.upload_progress.enabledavaktiverat på grund av CVE-2026-115560? - Vilket driftläge använder ert abonnemang, till exempel PHP-FPM eller Apache med mod_php? Vid mod_php ser PHP-teamet den högsta risken.
- Vilka åtkomst- och felloggar från och med den 20 oktober 2026 sparas, och hur får ni tag i dem?
Körs en webbplats fortfarande på PHP 8.1 eller äldre, fråga särskilt om den. För dessa grenar finns inga officiella uppdateringar längre, bara minimala backports av källkoden för 7.4, 8.0 och 8.1.
Mall: begär bekräftelse av PHP-uppdatering från webbhotellet
Kopiera texten till ett supportärende eller ett e-postmeddelande till ert webbhotell. Fyll i uppgifterna inom hakparentes.
Ämne: Begäran om bekräftelse av PHP-patchstatus (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Hej,
vi har hos er följande webbplatser / avtal:
[kundnummer, avtal, domäner]
I samband med PHP-säkerhetsluckorna CVE-2026-109618 och
CVE-2026-109619 (PHP2Shell, patchar från 21.10.2026) samt
informationen om CVE-2026-115560 från 23.10.2026 ber vi om en skriftlig
bekräftelse av följande punkter:
1. Vilka PHP-versioner respektive paketversioner är aktiva för våra webbplatser?
2. Innehåller dessa korrigeringarna (officiell version eller backport)?
3. Datum och klockslag för installationen.
4. Datum och klockslag för omstarten av alla PHP-processer (FPM, Apache,
LiteSpeed eller liknande).
5. Är session.upload_progress.enabled inaktiverat på serversidan?
6. Vilket PHP-driftläge används (t.ex. PHP-FPM, mod_php)?
7. Sparas åtkomst- och felloggar från och med 20.10.2026, och
hur kan vi få ta del av dem?
8. Om en webbplats fortfarande använder PHP 8.1 eller äldre: Vilket skydd
finns där, och vilken uppgradering rekommenderar ni?
Vi behöver uppgifterna för vår interna dokumentation.
Tack på förhand och vänliga hälsningar
[Namn, företag, befattning]
Bedöm svaret rätt och kontrollera själva
Ett bra svar anger konkreta nivåer, datum och klockslag. Allmänna formuleringar som ”vi har agerat” räcker inte för er akt. Fråga i så fall vänligt efter de saknade punkterna.
Om ert abonnemang tillåter det, kontrollera dessutom själva. Med SSH-åtkomst räcker oftast de här kommandona:
# Version på kommandoraden (kan avvika från webbversionen)
php -v
# Paketstatus på Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Paketstatus på RHEL, Alma, Rocky
rpm -qa | grep -i php
# Sedan när har PHP-FPM-processerna körts?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ligger starttidpunkten för PHP-processerna före det bekräftade installationsdatumet var omstarten inte fullständig.
Om webbhotellet inte svarar eller svarar undvikande
Uteblir svaret eller saknas de avgörande uppgifterna bör ni inte betrakta läget som klarlagt. BSI rekommenderar att tillfälligt ta webbservrar offline när en uppdatering inte kan göras direkt. Om det är proportionerligt för er webbplats avgör ledningen, helst skriftligt och med datum.
Parallellt lönar det sig att leta efter möjliga spår av ett angrepp, eftersom patchtidpunkten förblir öppen. Hållpunkter ger artikeln Är jag redan komprometterad?. Utan SSH-åtkomst är den skriftliga bekräftelsen ert viktigaste belägg. Vilka skyldigheter som ligger hos webbhotellet och vilka hos er förklarar sidan Delat webbhotell: vad webbhotellet gör; för förvaltade servrar hjälper Managed server: reda ut ansvaret.
Lägg förfrågan, svaret och era egna kontrollresultat med datum i en mapp. Den akten hjälper senare vid frågor från försäkringsgivare eller dataskyddsombud.
Hur hjälper PHP SOS konkret?
- Vi formulerar förfrågan till webbhotellet tillsammans med er och bedömer svaret fackmässigt.
- Där vi har åtkomst kontrollerar vi själva paketstatus, aktivt driftläge och omstart av PHP-processerna.
- Om luckor återstår sätter vi in tillfälliga åtgärder eller planerar bytet till en version som stöds.
- Vi dokumenterar resultat och tidpunkter i ett underlag som ni kan lämna vidare internt.
Hur uppdateringen med omstart och underlag går till beskriver vår PHP-patchtjänst.
Vanliga frågor
Räcker det att mitt webbhotell skriver att allt är aktuellt?
För er dokumentation räcker det sannolikt inte. Be om konkreta uppgifter: paketstatus eller version per PHP-gren, datum för installationen och datum för omstarten av alla PHP-processer. Först då kan ni avgränsa tidsfönstret för sårbarheten.
Varför visar mitt hostinggränssnitt fortfarande PHP 8.2.34?
Distributioner och webbhotell levererar ibland säkerhetsrättningar som backport utan att ändra versionsnumret. Plesk kan då fortsätta visa 8.2.34 fast servern är patchad. Tydlighet får ni bara genom leverantörens bekräftelse av paketstatus.
Vad gör jag om webbhotellet inte svarar?
Dokumentera er förfrågan med datum och fråga igen efter rimlig tid. Kontrollera samtidigt om ni själva kan sätta in tillfälliga åtgärder, och stäm av med ledningen om webbplatsen ska tas offline tills läget är klarlagt, så som BSI rekommenderar för ej patchade servrar.
Stänger en uppdatering av WordPress eller butiken också sårbarheten?
Nej. PHP2Shell finns i PHP självt. En uppdatering av CMS:et eller butiksprogramvaran ändrar ingenting i den PHP-tolk som körs på servern.