Kort sagt: Et websites leverandørkæde rækker fra PHP-projektet over distribution og hostingudbyder til CMS, plugins, bureau og indbundne tjenester. For it-sikkerheden tæller hvert led, for en patch når først jeres website, når alle har givet den videre. Den, der skriver kæden ned, fastlægger en ansvarlig stilling og en dokumentation for hvert led og begrænser adgange, gør den robust.
En patch og dens lange rejse
Den 21.10.2026 kl. 14:00 UTC offentliggjorde PHP-projektet rettelserne til PHP2Shell. Dermed var sårbarheden ikke lukket for et eneste website. Først måtte distributioner som Debian, Ubuntu eller RHEL-familien overtage rettelserne i deres pakker; ifølge rapporter blev backports til dels leveret samme dag. Så måtte hostingudbydere og administratorer installere disse pakker og genstarte alle PHP-processer. Først derefter var det pågældende website beskyttet.
Hvert led i denne kæde kan forsinke. Og til hvert led hører en anden organisation med egne prioriteter. Den, der ikke ved, hvordan hans kæde ser ud, kan ikke sige, hvor patchen lige nu befinder sig.
Nogle kæder har yderligere led, som næsten ingen kender. Mange Debian- og Ubuntu-servere henter ikke PHP fra distributionen, men fra Ondřej Surýs repository på sury.org, en udbredt tredjepartskilde. Ifølge rapporter har den stillet builds til rådighed til alle grene fra 5.6 til 8.5. Det er nyttigt, men det er ikke Debians sikkerhedsarkiv: Den, der bruger denne kilde, hænger på et andet led, med egen takt og eget ansvar. Om en server er sat sådan op, viser listen over pakkekilder, og netop denne information hører med i dokumentationen af kæden.
Leverandørkædens led i overblik
Den følgende tabel viser de typiske led i et PHP-website, og hvad I kan forlange af hvert.
| Led | Typisk risiko | Hvad I bør fastlægge |
|---|---|---|
| PHP-projekt | sårbarhed i fortolkeren, supportens udløb | understøttet version i brug, plan for supportens udløb |
| Distribution eller tredjepartskilde | backport mangler eller kommer sent | kendt pakkekilde, sikkerhedsmeddelelser abonneret |
| Hostingudbyder eller platformtjeneste | opdatering uden genstart, ingen information | pligt til opdatering, genstart, dokumentation og underretning |
| CMS-producent | sårbarhed i kernen | opdateringskanal, ansvarlig person |
| Plugin- og theme-udbyder | opgivne eller usikre udvidelser | kun vedligeholdte plugins fra officielle kilder |
| Bureau eller udvikler | vidtgående adgange, uklart ansvar | personlige adgange, skriftlige opgaver |
| Eksterne scripts og tjenester | fremmed kode i browseren, dataudsivning | liste, faste versioner, formål kontrolleret |
To eksempler fra PHP2Shell-ugen viser, hvor let et led overses. Vercel peger på, at en opdatering af det lokale udviklingsmiljø, af applikationskoden eller af plugins ikke er nok; afgørende er det PHP-kørselsmiljø, der faktisk leverer. Coolify råder til at opdatere hver applikations PHP-kørselsmiljø for sig, også bag Cloudflare. Og ifølge rapporter planlægger WordPress.org ikke en egen opdatering mod PHP2Shell, fordi sårbarheden ligger i fortolkeren. Den, der venter på CMS'et, venter forgæves.
Gør kæden synlig: Fem trin
Sådan bringer I orden i afhængighederne for jeres websites:
- Skriv kæden ned pr. website: fra PHP-kørselsmiljøet til eksterne scripts, med navnet på udbyderen eller personen.
- Fastlæg ansvar pr. led: Hvem indspiller opdateringer, hvem kontrollerer, hvem informerer hvem?
- Aftal dokumentation: Hvad gælder som udført? Ved PHP-kørselsmiljøet f.eks. pakkestatus og genstart, som beskrevet under Sådan spørger I jeres hostingudbyder om patch-status.
- Begræns adgange: Hvert bureau og hver leverandør får kun de rettigheder, der er brug for, med personlige konti.
- Planlæg alternative veje: Hvad gør man, hvis et led falder ud, f.eks. en plugin-udbyder opgiver eller en leverandør ikke kan nås?
Spørg hver leverandør, hvordan vedkommende informerer jer om kritiske sårbarheder. Den, der kun svarer på forespørgsel, er i en situation som PHP2Shell en risiko for jeres tidsplan. Få svaret skriftligt.
Plugins og udvidelser: Det mest uoverskuelige sted
Ved mange websites er den største del af leverandørkæden usynlig: plugins og themes, som er kommet til gennem årene. Hver stammer fra en anden udbyder, med eget tempo ved sikkerhedsopdateringer. Nogle udbydere opgiver deres produkt uden at varsle det. Andre udvidelser hentes fra uofficielle kilder og får aldrig opdateringer.
Her hjælper en enkel regel: Hvert plugin kræver et formål, en vedligeholdt udbyder og en officiel kilde. Mangler et af delene, kommer det på listen over udskiftninger. Noget tilsvarende gælder for indbundne tjenester som betalingsudbydere, bookingsystemer, chatvinduer eller analyseværktøjer. De bringer egen kode ind på jeres side eller modtager data om jeres besøgende. Fasthold, hvilke tjenester der er indbundet, hvem der har bestilt dem, og om de stadig er nødvendige. Et glemt script fra en udbyder, som man for længst ikke har en kontrakt med, er et led uden ansvarlig.
Hvordan I holder plugins og pakker løbende opdateret, beskriver Hold afhængigheder opdateret: Composer, npm og plugins.
Leverandørkæde, kontrakter og NIS2
For virksomheder, der er omfattet af NIS2, hører leverandørkædens sikkerhed udtrykkeligt til risikostyringen, altså også forholdet til leverandører og udbydere. Enkeltheder står under NIS2 og webserversikkerhed. Men også uden lovkrav gælder: Udliciterede opgaver forbliver jeres risiko. Derfor hører resultaterne af de fem trin med i kontrakterne med bureau, hostingudbyder og leverandører; hvilke punkter der bør reguleres dér, beskriver Kontrakter med it-leverandører: Regulér sikkerhedspligter klart. Denne side er generel information og ikke juridisk rådgivning.
Hvordan hjælper PHP SOS konkret?
- Vi tegner sammen med jer leverandørkæden for hvert website, fra PHP-kørselsmiljøet til eksterne scripts.
- Vi kontrollerer plugins, themes og pakker for vedligeholdelsesstand og oprindelse og anbefaler erstatning, hvor det er nødvendigt.
- Vi afstemmer med hostingudbyder og bureau, hvem der er ansvarlig for hvilke led, og hvilken dokumentation der leveres.
- Hvor et led er ubesat, overtager vi det varigt via en sikkerhedsvedligeholdelsesaftale.
Konklusion: Et websites sikkerhed er kun så stærk som det langsomste led i dets leverandørkæde. Den, der kender kæden og knytter hvert led til en ansvarlig stilling og en dokumentation, ved i en nødsituation, hvor patchen befinder sig.
Ofte stillede spørgsmål
Hvad betyder leverandørkæde for et website?
Alle involverede, hvis arbejde jeres websites sikkerhed afhænger af: PHP-projektet, Linux-distributionen, hostingudbyderen eller platformtjenesten, CMS-producenten, plugin- og theme-udbydere, bureauet og indbundne tjenester som betalingsudbydere eller eksterne scripts.
Er jeg ansvarlig, hvis en leverandør ikke patcher?
Ansvaret for eget website og dataene derpå forbliver som regel hos jer, også når opgaver er udliciteret. Derfor bør ansvarsområder være klare i kontrakten og kontrolleres. For den juridiske vurdering er advokat og databeskyttelsesrådgiver ansvarlige.
Er det nok, at hostingudbyderen opdaterer PHP?
For PHP-kørselsmiljøet hos hostingudbyderen ja, forudsat at udbyderen også genstarter alle processer og dokumenterer det. Kører dele af jeres applikation andetsteds, f.eks. i containere, på platformtjenester eller på en anden server, skal hvert kørselsmiljø dér opdateres for sig.
Hvordan genkender jeg risikable plugins?
Advarselstegn er lang tid uden opdateringer, en udbyder uden synlig sikkerhedskontakt, anskaffelse fra uofficielle kilder og funktioner, som ingen bruger mere. Sådanne plugins bør erstattes eller fjernes.