Kort sagt: Med en managed server tar leverantören över en del av säkerheten, typiskt operativsystem, PHP-paket och standardtjänster. Applikation, plugin, åtkomster och det dataskyddsrättsliga ansvaret ligger oftast kvar hos er. Efter PHP2Shell bör ni klargöra båda delarna skriftligt: vad har leverantören gjort, och vad ligger fortfarande på er?
Vad ”managed” betyder och vad det inte betyder
Begreppet är inte skyddat. En leverantör avser kanske bara installation av uppdateringar för operativsystemet, en annan tar även hand om webbserver, PHP, databas och säkerhetskopior. Vissa abonnemang omfattar övervakning dygnet runt, andra bara en kontaktperson under kontorstid.
Just i ett läge som PHP2Shell visar det sig hur exakt tjänstebeskrivningen är. De två sårbarheterna CVE-2026-109618 och CVE-2026-109619 finns i själva PHP. Om er leverantör underhåller PHP som en del av sin plattform eller om PHP räknas som ”er programvara” framgår av avtalet. Förlita er inte på antagandet att någon redan tar hand om det.
Säkerhet på managed server: typisk arbetsfördelning
Följande tabell visar en vanlig fördelning. Den ersätter inte en titt i ert avtal men hjälper er att ställa rätt frågor.
| Område | Oftast hos leverantören | Oftast hos er |
|---|---|---|
| Hårdvara, nät, virtualisering | ja | nej |
| Operativsystemsuppdateringar | ja | nej |
| PHP-paket från plattformen | ofta | om ni installerat själva |
| Omstart av PHP-FPM och webbserver | ofta | för egna tjänster |
| Serveromfattande PHP-konfiguration | ofta | vid specialönskemål |
| CMS, butik, plugin, egen kod | nej | ja |
| Applikationens administratörskonton | nej | ja |
| Säkerhetskopior | ofta | kontroll av återställningen |
| Bedömning och anmälan av personuppgiftsincidenter | nej | ja |
| Övervakning av angrepp | beroende på abonnemang | beroende på abonnemang |
Oklara fält är den egentliga risken. Där ni skulle behöva skriva ”beroende på abonnemang” eller ”ofta” saknas en reglering.
Vilka frågor ni bör ställa nu
Skicka en kort, saklig förfrågan till er leverantör. Be om svar i textform så att ni kan visa upp det senare. Följande punkter bör ingå:
- Vilka PHP-versioner körs på vår server, och är de skyddade mot CVE-2026-109618 och CVE-2026-109619?
- Sedan när gäller det, och startades alla PHP-processer och webbservern om efteråt?
- Installerades rättningen som backport? Om ja, vilken paketversion styrker det?
- Fanns det tecken på angreppsförsök eller avvikande processer på vår server?
- Sparas webbserverloggarna från och med den 20 oktober 2026, och hur får vi tillgång till dem?
En färdigformulerad mall finns under Fråga webbhotellet om patchstatus. Versionsnumret i kundmenyn är inget belägg: vid backports förblir det ofta oförändrat, till exempel 8.2.34.
Även om leverantören har patchat PHP måste er applikation kontrolleras. En patch tar inte bort skadlig programvara som fördes in före uppdateringen och bevisar inte att ingenting har hänt.
Det som ligger kvar hos er
Er del omfattar framför allt applikationen. Kontrollera att CMS, butik och plugin är aktuella, ta bort tillägg som inte längre används och granska listan över administratörer. Håll utkik efter nya filer i uppladdningsmappar, främmande omdirigeringar och ovanliga schemalagda uppgifter i applikationen.
Därtill kommer den rättsliga sidan. Om personuppgifter vid en incident hamnar i orätta händer är i regel ert företag som personuppgiftsansvarig anmälningsskyldigt, inte leverantören. Denne måste som personuppgiftsbiträde informera er utan dröjsmål. Grunderna förklaras under Anmälningsplikt enligt GDPR: 72 timmar. Det är allmän information, inte juridisk rådgivning; det enskilda fallet bedöms av dataskyddsombud eller jurister.
En ytterligare punkt förbises ofta: programvara som ni eller er byrå själva har installerat på den hanterade servern, till exempel en extra PHP-version från en tredjepartskälla, en container eller ett hjälpprogram, omfattas oftast inte av leverantörens underhåll. Fråga därför också om leverantören vet vad som körs vid sidan av standardutrustningen. Och klargör vem som tar över undersökningen vid misstanke. Många leverantörer återställer plattformen men undersöker inte om och vilka data som berördes. Just det svaret behöver ni dock för bedömningen av möjliga anmälningsplikter.
Förbättra avtalen inför framtiden
Använd läget för att fastlägga arbetsfördelningen. Meningsfullt är regler om säkerhetsuppdateringar inklusive omstart, om information vid kritiska sårbarheter, om lagring och utlämnande av loggar och om stöd vid incidenter. Fråga också om leverantören underrättar er aktivt eller om ni själva måste fråga.
En egen server utan skötsel är alternativet men flyttar hela arbetet till er. Vad det innebär beskrivs under Säkra root-server och vServer på egen hand.
Hur hjälper PHP SOS konkret?
- Vi läser er tjänstebeskrivning och upprättar en uppgiftsmatris som gör luckor synliga.
- Vi formulerar de tekniska frågorna till er leverantör och bedömer svaren.
- Vi kontrollerar applikationsdelen som ligger hos er med avseende på spår och föråldrade komponenter.
- Det leverantören inte täcker tar vi på begäran över via ett säkerhetsunderhållsavtal eller kompletterar med säkerhetsövervakning.
Vanliga frågor
Är allt automatiskt säkrat med en managed server?
Nej. Managed betyder att leverantören tar över vissa avtalsenligt fastställda uppgifter, oftast operativsystem och standardtjänster. Applikation, plugin, åtkomster och egen programvara ligger ofta kvar hos er.
Var står det vad min leverantör ansvarar för?
I tjänstebeskrivningen och avtalsvillkoren, ofta också i ett dokument om arbetsfördelning. För personuppgifter tillkommer personuppgiftsbiträdesavtalet. Saknas en tydlig reglering av säkerhetsuppdateringar frågar ni skriftligt.
Måste jag själv göra något åt PHP2Shell trots managed server?
Ja. Inhämta en bekräftelse på att alla PHP-versioner är patchade och att processerna har startats om. Kontrollera dessutom er applikation med avseende på spår och klargör om det finns en anmälningsplikt.
Vem anmäler en personuppgiftsincident om webbhotellet berördes?
Anmälningsskyldig gentemot tillsynsmyndigheten är i regel den personuppgiftsansvarige, alltså ert företag. Webbhotellet måste som personuppgiftsbiträde informera er utan dröjsmål. Låt ert dataskyddsombud bedöma det enskilda fallet.