Kort sagt: White-Label-IT-säkerhet innebär för er byrå: Ni behåller kundrelationen, vi gör säkerhetsarbetet i bakgrunden. Vid PHP2Shell betyder det en förteckning över alla kundsidor, prioritering efter risk, patch och omstart per server och ett underlag per kund som ni kan lämna vidare.
Varför byråer är särskilt pressade vid PHP2Shell
En byrå med många kunder sköter sällan ett enhetligt landskap. En del av sidorna ligger på egna servrar med Plesk, en del hos kundernas webbhotell, några äldre projekt på PHP-versioner som för länge sedan inte får några officiella uppdateringar. Dessutom finns olika system: WordPress, TYPO3, Shopware, Craft CMS, egenutvecklade Laravel-lösningar.
Vid en sårbarhet i PHP självt drabbas alla projekt samtidigt. Kunder förväntar sig svar på om deras sida är säker, och projektteamet är fullt upptaget med pågående uppdrag. Många underhållsavtal reglerar CMS:et men inte servern under det.
Dessutom finns system som inte längre förekommer i någon projektlista: staging-miljöer på underdomäner, kampanjsidor från avslutade projekt, testinstallationer från utvecklare på egna vServers. De körs ofta på äldre PHP-versioner, övervakas inte och bär ändå er byrås eller er kunds namn. För automatiserade skanningar är de lika synliga som huvudsidan.
Vilka frågor era kunder ställer nu
- Berörs min webbplats, och är den numera patchad?
- Fördes något in redan före patchen?
- Räknas CMS-uppdateringen som skydd? Nej, en CMS-uppdatering stänger inte PHP-sårbarheten.
- Måste jag ta min webbplats offline? BSI rekommenderar det för servrar som inte kan uppdateras direkt.
På var och en av dessa frågor behöver er byrå ett belagt svar per kund, inte ett massmejl med allmänna uttalanden.
Så går White-Label-IT-säkerhet för byråer till
Vi arbetar som en del av ert team men utan egen kundkontakt. Uppdelningen är tydlig:
| Uppgift | Er byrå | PHP SOS |
|---|---|---|
| Kundkommunikation och fakturering | ja | nej |
| Förteckning över alla kundsidor med PHP-nivå | lämnar åtkomster | upprättar och underhåller den |
| Patch, omstart, kontroll per server | godkänner underhållsfönster | utför eller samordnar med webbhotell |
| Kontroll av kompromettering | får fyndrapport | söker efter webshells och avvikelser |
| Underlag per kund | lämnar vidare | upprättar neutralt eller i ert format |
För sidor hos främmande webbhotell inhämtar vi bekräftelsen av paketstatusen. Det visade versionsnumret ensamt räcker inte, eftersom backports kan lämna det oförändrat.
Prioritera först servrar med Apache och mod_php, där PHP-teamet bedömer risken som högst, därefter butiker och sidor med inloggning, sedan projekt på PHP 8.1 och äldre. Statiska äldre projekt som ingen längre behöver stänger ni hellre av än patchar.
Flera kundsidor på en server: kontrollera isoleringen
På byråservrar delar ofta många kundsidor på en maskin. Komprometteras en av dem avgör separeringen om angriparen också kommer åt de andra. Viktiga är egna systemanvändare och PHP-FPM-pooler per webbplats, korrekta filrättigheter och gränser som open_basedir. På Plesk-servrar kan dessa inställningar kontrolleras per abonnemang.
Efter patchen gäller: Starta om alla pooler och workers. Först då körs inga gamla PHP-processer längre i minnet. Loggar från och med den 20 oktober 2026 bör bevaras för varje kundsida.
Kundinformation: vad som är belagt och vad som inte är det
Den största frestelsen i det här läget är ett lugnande massmejl. Säkrare är ett uttalande per kund som bara innehåller det som är belagt: vilken server, vilken PHP-paketnivå, när omstart skedde, om en kontroll av kompromettering har gjorts och med vilket resultat. Det som fortfarande är öppet står också där.
Formuleringar som ”Er sida är säker” bör ni hellre undvika. En patch stänger sårbarheten men bevisar inte att inget hände tidigare. Den som skiljer det ärligt åt hamnar senare inte i förklaringsnöd om ändå ett fynd skulle dyka upp.
Skriv om underhållsavtalen efter PHP2Shell
Många byråavtal reglerar uppdateringar av CMS och tillägg men tiger om servern. Använd läget för att för varje kund fastlägga vem som uppdaterar PHP, vem som ansvarar för omstarter, vem som beslutar vid en incident och vilka tjänster som beställs separat. Även ett personuppgiftsbiträdesavtal med alla inblandade leverantörer hör dit. Den avtalsmässiga utformningen klarlägger ni med er juridiska rådgivning.
Hur hjälper PHP SOS konkret?
- Vi tar över inventeringen av alla kundsidor med PHP-version, driftläge, webbhotell och ansvar.
- Via vår PHP-patchtjänst patchar vi era egna servrar, startar om alla workers och styrker det per kund.
- Vi kontrollerar prioriterade sidor efter kompromettering och rensar vid fynd, tills incidenten är avslutad och dokumenterad.
- Vi levererar textbitar till er kundinformation som ni anpassar och skickar själva.
- Därefter tar vi på begäran med ett säkerhetsunderhållsavtal över den löpande säkerhetsskötseln i bakgrunden.
Vanliga frågor
Uppträder ni gentemot våra kunder?
Bara om ni vill det. I white label-modellen arbetar vi uteslutande i bakgrunden, och all kommunikation går via er byrå. Vår dokumentation levererar vi neutral eller i ert format.
Behöver vi ett personuppgiftsbiträdesavtal för det?
Om vi får åtkomst till system med personuppgifter från era kunder behövs i regel ett avtal om personuppgiftsbehandling, ofta som underbiträde. Hur det passar in i era befintliga avtal klarar ni ut med er juridiska rådgivning. Vi tillhandahåller de nödvändiga uppgifterna om vår verksamhet.
Hur blir det med kundsidor vars servrar vi inte alls förvaltar?
Ligger kundsidor hos främmande webbhotell inhämtar vi i ert namn eller med era mallar bekräftelser om patchnivå och omstart. Där det bara finns FTP- eller CMS-åtkomst prövar vi vad som går att göra därifrån och markerar öppet vad bara webbhotellet kan belägga.
Kan vi lägga ut detta permanent även efter PHP2Shell?
Ja. Många uppgifter upprepas vid varje sårbarhet: underhålla förteckningen, installera patchar, styrka omstarter, rapportera avvikelser. Det arbetet kan organiseras som löpande skötsel i bakgrunden.