En sikkerhetsrettelse beskytter ikke en server før den som drifter den, kan ta den i bruk. Under håndteringen av PHP2Shell bidro den frivillige vedlikeholderen Ondřej Surý med PHP-pakker for Debian og Ubuntu, også for eldre PHP-versjoner.
17
28 Arbeidet hans viser hvorfor sikkerhet i åpen kildekode ikke bare handler om å finne og rette feil, men også om å holde kanalene for oppdateringer i gang.
Hva var PHP2Shell?
PHP2Shell er navnet på to sårbarheter: CVE-2026-109618 og CVE-2026-109619. PHPs sikkerhetsteam ga begge en alvorlighetsgrad på 9,2 etter CVSS v4.0.
6
7 Dersom sårbarhetene ble utnyttet, kunne en angriper uten innlogging kjøre kode på en berørt PHP-installasjon som behandlet nettrafikk.
3
8
- oktober 2026 publiserte PHP rettede versjoner: 8.2.35, 8.3.36, 8.4.27 og 8.5.12.
3 Dette var oppdateringene fra PHP-prosjektet. For at serveradministratorer enkelt skulle kunne installere dem, måtte rettingene også bygges og distribueres som pakker tilpasset systemene deres.
Fra rettelse til installerbar pakke
Mange administratorer installerer PHP som en ferdig pakke i stedet for å bygge programvaren fra kildekoden selv. Å klargjøre slike pakker er et eget arbeid, adskilt fra å skrive eller slå sammen selve rettelsen. Surý har vedlikeholdt PHP-pakker for Debian og Ubuntu på frivillig basis i mer enn 20 år, for det meste på fritiden.
17
32
Ifølge rapporter var rettede pakker tilgjengelige i repositoriet hans samme dag som PHP slapp oppdateringen, for versjoner fra PHP 5.6 til 8.5.
28 Det var særlig relevant for eldre installasjoner. PHP 8.1 og eldre får ikke lenger vanlige oppdateringer fra PHP-prosjektet, selv om prosjektet publiserte kildekoderettinger for versjon 7.4, 8.0 og 8.1, og andre leverandører også tilbød rettelser.
2
33
Forskjellen er praktisk: En rettelse i kildekoden er nyttig for dem som kan hente den inn og bygge programvaren. En ferdig pakke gir administratorer en enklere vei til å installere oppdateringen. Surýs arbeid bidro med et slikt alternativ for Debian- og Ubuntu-brukere, også for noen eldre PHP-versjoner.
24
28 Kildene dokumenterer at pakkene ble klargjort, men ikke hvor mange servere som installerte dem eller hvor raskt det skjedde.
Uenighet om tidspunktet for publisering
PHPs sikkerhetsteam hadde varslet at oppdateringen skulle komme 21. oktober, og skrev at tidspunktet kunne fremskyndes hvis opplysninger om sårbarhetene ble kjent eller man fikk tegn til aktiv utnyttelse.
7 Selve publiseringsforløpet ble også omstridt. PHP Foundation sa at Chainguard publiserte rettede containerbilder mer enn seks timer før den samordnede lanseringen, og beskrev det som et brudd på embargoen.
34 En annen framstilling sier at Chainguards administrerende direktør forklarte beslutningen med at utnyttelser allerede var i omløp.
36 Dette er ulike parters framstillinger; kildene avgjør ikke uavhengig hvem som hadde rett i striden.
Sikkerhet avhenger også av vedlikehold
Håndteringen av PHP2Shell involverte flere ledd: sikkerhetsforskning, rettelser i PHP-prosjektet, pakking for ulike distribusjoner og administratorer som installerer oppdateringene. Surýs langvarige frivillige innsats gjorde pakkevedlikeholdet ekstra synlig, men hovedpoenget er bredere: En rettelse må passere gjennom vedlikeholdere og distribusjoner før den kan beskytte systemene som bruker programvaren.
17
24
Dermed er vedlikeholdslaget også en del av sikkerhetsarbeidet. Oppdateringer avhenger av at personer og prosjekter kan holde pakkene aktuelle – også når PHP-prosjektet selv ikke lenger gir vanlige oppdateringer til eldre versjoner.
28
33