Kort sagt: En webbplatsens leveranskedja sträcker sig från PHP-projektet via distribution och hostingleverantör till CMS, tillägg, byrå och inbundna tjänster. För IT-säkerheten räknas varje led, eftersom en patch först når er webbplats när alla har fört den vidare. Den som skriver ner kedjan, fastställer en ansvarig instans och ett underlag för varje led och begränsar åtkomsterna gör den hållbar.
En patch och dess långa resa
Den 21.10.2026 kl. 14:00 UTC publicerade PHP-projektet rättelserna för PHP2Shell. Därmed var luckan inte stängd för en enda webbplats. Först måste distributioner som Debian, Ubuntu eller RHEL-familjen föra in rättelserna i sina paket; enligt rapporter levererades backporter delvis redan samma dag. Därefter måste hostingleverantörer och administratörer installera dessa paket och starta om alla PHP-processer. Först efter det var respektive webbplats skyddad.
Varje led i denna kedja kan fördröja. Och vid varje led hänger en annan organisation med egna prioriteringar. Den som inte vet hur dess kedja ser ut kan inte säga var patchen just nu befinner sig.
Vissa kedjor har extra led som knappt någon känner till. Många Debian- och Ubuntu-servrar hämtar PHP inte från distributionen utan från Ondřej Surýs repository på sury.org, en utbredd tredjepartskälla. Enligt rapporter har den tillhandahållit byggen för alla grenar från 5.6 till 8.5. Det är hjälpsamt, men det är inte Debians säkerhetsarkiv: Den som använder den källan hänger på ett annat led, med egen takt och eget ansvar. Om en server är inrättad så visar listan över paketkällor, och just den uppgiften hör hemma i dokumentationen av kedjan.
Leveranskedjans led i översikt
Följande tabell visar de typiska leden för en PHP-webbplats och vad ni kan kräva av varje led.
| Led | Typisk risk | Vad ni bör fastställa |
|---|---|---|
| PHP-projektet | lucka i tolken, supportens slut | version som stöds i bruk, plan för supportens slut |
| Distribution eller tredjepartskälla | backport saknas eller kommer sent | känd paketkälla, säkerhetsmeddelanden prenumererade |
| Hostingleverantör eller plattformstjänst | uppdatering utan omstart, ingen information | skyldighet till uppdatering, omstart, underlag och avisering |
| CMS-tillverkare | lucka i kärnan | uppdateringskanal, ansvarig person |
| Leverantör av tillägg och teman | övergivna eller osäkra tillägg | bara underhållna tillägg från officiella källor |
| Byrå eller utvecklare | långtgående åtkomster, oklart ansvar | personliga åtkomster, skriftliga uppgifter |
| Externa skript och tjänster | främmande kod i webbläsaren, dataläckage | lista, fasta versioner, syftet prövat |
Två exempel från PHP2Shell-veckan visar hur lätt ett led förbises. Vercel påpekar att en uppdatering av den lokala utvecklingsmiljön, applikationskoden eller tilläggen inte räcker; avgörande är den PHP-miljö som faktiskt levererar. Coolify råder att uppdatera varje applikations PHP-miljö för sig, även bakom Cloudflare. Och enligt rapporter planerar WordPress.org ingen egen uppdatering mot PHP2Shell eftersom luckan ligger i tolken. Den som väntar på CMS:et väntar förgäves.
Gör kedjan synlig: fem steg
Så skapar ni ordning bland era webbplatsers beroenden:
- Skriv ner kedjan per webbplats: från PHP-miljön till externa skript, med leverantörens eller personens namn.
- Fastställ ansvar per led: Vem installerar uppdateringar, vem kontrollerar, vem informerar vem?
- Överenskomma underlag: Vad räknas som utfört? För PHP-miljön till exempel paketstatus och omstart, såsom beskrivs i Så frågar ni er hostingleverantör om patchstatus.
- Begränsa åtkomster: Varje byrå och leverantör får bara de rättigheter som behövs, med personliga konton.
- Planera reservvägar: Vad gör man om ett led faller bort, till exempel om en tilläggsleverantör ger upp eller en leverantör inte kan nås?
Fråga varje leverantör hur han informerar er om kritiska luckor. Den som bara svarar på förfrågan är i ett läge som PHP2Shell en risk för er tidsplan. Dokumentera svaret skriftligt.
Tillägg och utökningar: det mest oöverskådliga stället
På många webbplatser är största delen av leveranskedjan osynlig: tillägg och teman som tillkommit under åren. Vart och ett kommer från en annan leverantör, med eget tempo för säkerhetsuppdateringar. Vissa leverantörer ger upp sin produkt utan att meddela det. Andra utökningar hämtas från inofficiella källor och får aldrig några uppdateringar.
Här hjälper en enkel regel: Varje tillägg behöver ett syfte, en underhållen leverantör och en officiell källa. Saknas något av detta hamnar det på listan över sådant som ska ersättas. Detsamma gäller inbundna tjänster som betalningsleverantörer, bokningssystem, chattfönster eller analysverktyg. De för in egen kod på er sida eller får uppgifter om era besökare. Dokumentera vilka tjänster som är inbundna, vem som har beställt dem och om de fortfarande behövs. Ett bortglömt skript från en leverantör som man sedan länge inte har något avtal med är ett led utan ansvarig.
Hur ni håller tillägg och paket varaktigt aktuella beskriver Håll beroenden aktuella: Composer, npm och tillägg.
Leveranskedja, avtal och NIS2
För företag som omfattas av NIS2 hör säkerheten i leveranskedjan uttryckligen till riskhanteringen, alltså även relationerna till leverantörer och tillhandahållare. Detaljer finns under NIS2 och säkerhet för webbservrar. Men även utan lagstadgad skyldighet gäller: Utlagda uppgifter förblir er risk. Därför hör resultaten av de fem stegen hemma i avtalen med byrå, hostingleverantör och leverantörer; vilka punkter som bör regleras där beskriver Avtal med IT-leverantörer: tydliga säkerhetsskyldigheter. Den här sidan är allmän information och ingen juridisk rådgivning.
Hur hjälper PHP SOS konkret?
- Vi ritar tillsammans med er upp leveranskedjan för varje webbplats, från PHP-miljön till externa skript.
- Vi granskar tillägg, teman och paket med avseende på underhållsstatus och ursprung och rekommenderar ersättning där det behövs.
- Vi stämmer av med hostingleverantör och byrå vem som ansvarar för vilka led och vilka underlag som levereras.
- Där ett led är obemannat tar vi över det varaktigt via ett säkerhetsunderhållsavtal.
Slutsats: En webbplats säkerhet är lika stark som det långsammaste ledet i dess leveranskedja. Den som känner kedjan och kopplar varje led till en ansvarig instans och ett underlag vet i ett skarpt läge var patchen befinner sig.
Vanliga frågor
Vad betyder leveranskedja för en webbplats?
Alla inblandade vars arbete säkerheten på er webbplats beror på: PHP-projektet, Linux-distributionen, hostingleverantören eller plattformstjänsten, CMS-tillverkaren, leverantörer av tillägg och teman, byrån och inbundna tjänster som betalningsleverantörer eller externa skript.
Är jag ansvarig om en leverantör inte patchar?
Ansvaret för den egna webbplatsen och uppgifterna på den ligger som regel kvar hos er, även om uppgifter har lagts ut. Därför bör ansvarsfördelningen vara tydlig i avtalet och kontrolleras. För den juridiska bedömningen är advokat och dataskyddsombud behöriga.
Räcker det att hostingleverantören uppdaterar PHP?
För PHP-miljön hos hostingleverantören ja, förutsatt att han också startar om alla processer och styrker det. Körs delar av er applikation någon annanstans, till exempel i containrar, på plattformstjänster eller på en andra server, måste varje körmiljö uppdateras för sig.
Hur känner jag igen riskfyllda tillägg?
Varningstecken är att det inte kommit några uppdateringar på länge, en leverantör utan synlig säkerhetskontakt, källor som inte är officiella och funktioner som ingen längre använder. Sådana tillägg bör ersättas eller tas bort.