Kort sagt: Den som vill uppdatera beroenden behöver en process för tre paketvärldar: Composer-paket i PHP-koden, npm-moduler i frontend-bygget och tillägg eller teman i CMS:et. Dit hör en fast rytm, en ansvarig person, tester före utrullning och en plan för paket utan uppdatering. Mot PHP2Shell hjälper det inte, för den sårbarheten sitter i PHP självt, men mot de många sårbarheterna i främmande kod.
Tre paketvärldar, en blind fläck
Veckan efter den 21 oktober 2026 handlade allt om PHP-tolken. Många team märkte då att de inte exakt känner till versionerna på sina egna byggstenar. Webbplatsen fungerar, byrån tar hand om det, tillägget hör av sig när det finns något nytt: Så eller liknande lyder antagandena tills någon tittar efter.
Ett typiskt PHP-projekt består i dag av betydligt mer främmande än egen kod. OWASP Top 10 för sårbara och föråldrade komponenter som en egen riskkategori. Problemet är sällan det saknade verktyget utan den saknade rutinen: Uppdateringar sker när någon har tid, och säkerhetsmeddelanden hamnar i en postlåda som ingen läser.
Vilka beroenden uppdaterar ni var?
Varje paketvärld har egna verktyg och egna fallgropar. Följande översikt hjälper till att inte missa något.
| Paketvärld | Visa bestånd | Kontrollera sårbarheter | Typisk fallgrop |
|---|---|---|---|
| Composer (PHP-bibliotek) | composer show |
composer audit |
indirekta paket som ingen känner till |
| npm (frontend-bygge) | npm ls |
npm audit |
uppdatering utan ombyggnad når aldrig servern |
| CMS-tillägg och teman | adminytan eller CLI | tillverkarmeddelanden, säkerhetstjänster | övergivna tillägg, köptillägg utan uppdateringskanal |
| PHP och tillägg | pakethantering | distributionens säkerhetsspårare | visad version säger lite om backporter |
Den sista raden hör strängt taget inte till applikationens beroenden, men glöms ofta i samma andetag. Detsamma gäller skript som binds in direkt från främmande servrar, till exempel bibliotek från ett CDN, chattwidgets eller spårningskod. De dyker inte upp i någon låsfil men körs i era besökares webbläsare. Ta med dem på listan och kontrollera om fasta versioner är inbundna i stället för ”alltid den senaste”. Detaljerna om composer audit, låsfil och integrering i bygget står i guiden Kontrollera Composer-beroenden efter sårbarheter. Hur Composer i grunden fungerar förklarar Composer: pakethanteraren för PHP.
Underhållscykeln i sex steg
En hållbar process behöver inte vara komplicerad. Den här ordningen har visat sig fungera:
- Dokumentera beståndet: För varje projekt en lista över de direkta beroendena med version, ursprung och syfte. Låsfiler (
composer.lock,package-lock.json) hör hemma i repositoryt. - Samla meddelanden: Kontrollverktyg körs vid varje bygge och dessutom regelbundet på den levererade versionen, även utan kodändring.
- Bedöma: Används det berörda paketet i produktionsdrift, är den berörda funktionen nåbar, finns det en åtgärdad version?
- Uppdatera och testa i staging: Först säkerhetsuppdateringar inom samma huvudversion, hopp till nya huvudversioner planeras som ett eget projekt.
- Rulla ut med återväg: Den föregående versionen finns kvar som paket eller release, databasbackup före uppdateringen.
- Dokumentera: Vad som uppdaterades när, vad som medvetet inte uppdaterades och varför.
Se då upp med versionsangivelserna i composer.json och package.json. För snäva föreskrifter förhindrar att säkerhetsrättelser över huvud taget kan installeras. För vida föreskrifter hämtar däremot ogranskade nya huvudversioner in i projektet. Det har visat sig fungera att tillåta uppdateringar inom huvudversionen och planera hoppet till nästa medvetet.
För tillägg i CMS:et går tillgängliga uppdateringar ofta att visa även på kommandoraden, i WordPress till exempel med WP-CLI:
# Visa tillgängliga uppdateringar utan att ändra något
wp plugin list --update=available
wp theme list --update=available
# Frontend-paket: föråldrade versioner och kända sårbarheter
npm outdated
npm audit --omit=dev
Automatiska tilläggsuppdateringar direkt i produktionssystemet är bekväma men riskabla om ingen kontrollerar efteråt. Slå bara på dem om en backup före varje körning och en kontroll efteråt är säkerställda.
När det inte finns någon uppdatering
Inte varje meddelande går att lösa med ett klick. OWASP:s cheat sheet om hantering av sårbara beroenden skiljer mellan flera fall som går bra att överföra till vardagen:
- Patch tillgänglig: lägg in i staging, testa, rulla ut. Går något sönder, anpassa den egna koden i stället för att låta uppdateringen ligga.
- Patch aviserad men inte på plats än: genomför tillverkarens workaround, stäng av eller avskärma den berörda funktionen om möjligt, dokumentera beslutet.
- Ingen patch att vänta: leta efter ett ersättningspaket eller backporta rättelsen själva, med ett test som skiljer sårbarheten före och efter patchen.
För CMS-tillägg förekommer ofta ett fjärde fall: Tillägget är övergivet. Då hjälper bara ersättning eller borttagning. Detsamma gäller tillägg från oklara källor, till exempel ”gratis” kopior av köptillägg. De får inga uppdateringar via den officiella kanalen och innehåller inte sällan själva skadlig kod. Anvisningar för WordPress-driftansvariga samlar WordPress och PHP2Shell.
Klargör ansvaret innan nästa meddelande kommer
Den vanligaste orsaken till föråldrade paket är inget tekniskt hinder utan en öppen fråga: Vem gör det? För projekt som en byrå har byggt och som drivs internt känner sig ofta ingen ansvarig. Fastställ för varje projekt vem som får meddelanden, vem som bedömer och vem som godkänner, och skriv ner det.
Planera dessutom in tid. En fast underhållstid i månaden, då beroenden kontrolleras och uppdateras, förhindrar att uppdateringar hopar sig över år. Ju längre ett projekt inte har uppdaterats, desto större och riskablare blir nästa hopp. Hur uppdateringar av PHP och paket passar in i ett övergripande förlopp beskriver Patchhantering som process i stället för brandkår.
Hur hjälper PHP SOS konkret?
- Vi registrerar alla beroenden i era projekt från Composer, npm och CMS och markerar föråldrade, sårbara och övergivna paket.
- Vi inrättar automatiska kontroller och fastställer vem som bedömer vilket meddelande.
- Vi uppdaterar i staging, testar de viktigaste förloppen och rullar ut med återväg.
- Inom ramen för ett säkerhetsunderhållsavtal tar vi hand om den månatliga cykeln varaktigt, PHP-uppdateringar inkluderade.
Slutsats: Aktuella beroenden är inget projekt utan rutin. Den som en gång reglerar bestånd, rytm och ansvar rent behöver vid nästa stora meddelande bara kontrollera, inte först leta.
Vanliga frågor
Hur ofta bör man uppdatera beroenden?
Säkerhetsuppdateringar så snart som möjligt efter bedömning, rutinuppdateringar i fast rytm, till exempel varje månad. Viktigare än den exakta frekvensen är att tidpunkten är fastlagd och att någon ansvarar för den.
Skyddar ett aktuellt tillägg mot PHP2Shell?
Nej. PHP2Shell sitter i själva PHP-tolken. Mot det hjälper bara en PHP-uppdatering med omstart av alla PHP-processer. Aktuella tillägg och paket är ändå viktiga, eftersom de täpper till egna sårbarheter.
Vad gör jag med ett tillägg som inte längre underhålls?
Ersätt eller ta bort det. Ett övergivet tillägg får inga rättelser längre, även om det fungerar i dag. Fram till ersättningen bör ni kontrollera om funktionen verkligen behövs och dokumentera beslutet.
Måste frontend med npm också uppdateras på servern?
Ofta ligger npm-paket bara i bygget och hamnar som färdiga filer på servern. En sårbarhet i ett paket kan ändå sitta i det levererade JavaScriptet. Efter en uppdatering måste man därför bygga om och leverera på nytt.