Ej patchad PHP är en öppen dörr. Vi stänger den.
Akut hjälp på distans för företag i Europa: patcha PHP, granska spår efter intrång, ta bort skadlig kod och härda servern. Direkt, med specialiserade partner, tills incidenten är avslutad och dokumenterad.
$ php -v PHP 8.3.35 (cli) (built: Sep 30 2026) ! Läge före patchen från den 21 oktober 2026 $ phpsos pruefen --ziel produktion Driftläge ........ php-fpm CVE-2026-109618 .. öppen CVE-2026-109619 .. öppen Omstart av workers .. väntar $ phpsos absichern [ok] Paket 8.3.36 installerat [ok] alla workers omstartade [ok] Filsystemet granskat efter webshells [ok] Rapport till ledningen upprättad
- Made in GermanyIT-säkerhet från Tyskland, arbete enligt europeisk dataskyddslagstiftning.
- Över 25 årSpecialiserade på IT-säkerhet och serverdrift i över 25 år, tillsammans med vårt partnernätverk.
- PartnernätverkSpecialiserade cyberproffs inom forensik, penetrationstester och serverhärdning, samordnade via en enda kontaktperson.
Är ni drabbade? Ring oss. Vi hjälper till.
Hackade, utelåsta, webbshell hittad eller osäkra på om PHP2Shell berör er: hör av er nu. Vi tar över från första meddelandet, på distans och utan resa.
Är er PHP redan patchad?
Ange er PHP-version. Testet jämför den med säkerhetsmeddelandena från php.net och visar vad som bör göras härnäst. Viktigt: Inte ens en patchad version bevisar att inget hände före uppdateringen.
Hur akut är ert läge?
Fyra frågor, en bedömning, de första stegen och ett förberett WhatsApp-meddelande till oss. Vid nivå 3 gäller: radera ingenting, installera inte om, säkra spåren.
Från nödsamtalet till den härdade servern
Vi tar hand om tekniken och levererar de underlag som ledning, dataskydd och försäkring behöver.
PHP2Shell-akuthjälp: hjälp med PHP-sårbarheten
Vi stänger PHP2Shell på era webbservrar på distans: inventering, patch eller övergångsåtgärd, omstart av alla workers och skriftligt intyg.
Läs mer →02Webbplatsen hackad, vad göra? Akuthjälp på distans
Är er webbplats hackad eller beter den sig avvikande? Vi tar på distans hand om begränsning, spårsäkring, rensning och dokumentation.
Läs mer →03PHP-patchtjänst: installera uppdateringen, med omstart och intyg
Vi installerar PHP-uppdateringen på era servrar, startar om alla PHP-processer och levererar ett skriftligt intyg om version, paketstatus och omstart.
Läs mer →04Serverhärdning för PHP-webbservrar
Vi härdar era PHP-webbservrar enligt en fast plan: isolering per webbplats, säker PHP-konfiguration, filrättigheter, åtkomster, protokoll och säkerhetskopior.
Läs mer →05Ta bort skadlig kod och webshells från webbplatsen
Vi tar bort skadlig kod, webshells och bakdörrar från webbplatser och servrar, bygger upp på nytt från tillförlitliga källor och stänger ingångsvägen.
Läs mer →06Incident response vid serverangrepp
Strukturerad incidenthantering vid angrepp mot webbservrar: lägesbild, begränsning, avlägsnande, återställning och uppföljning med fasta roller.
Läs mer →Så arbetar vi när det är allvar
Tydliga steg, en kontaktperson, allt på distans. Specialister ur vårt partnernätverk kopplas in när forensik eller penetrationstest behövs.
Kartlägga läget
Ni skriver via WhatsApp eller ringer. Vi klarlägger system, PHP-version, webbhotell och observationer.
Säkra och stänga
Säkra spår, patcha PHP eller sätta in tillfälliga åtgärder, starta om alla workers och styrka patchnivån.
Granska och rensa
Granska filer, databas, konton och loggar efter spår av intrång. Ta bort webshells och bakdörrar.
Härda och rapportera
Härda konfigurationen, ställa in övervakning, rapport till ledning, dataskydd och försäkring.
Går det inte att patcha ännu? Tillfälliga åtgärder
php.net anger inställningar som försvårar kända angreppsvägar tills uppdateringen är installerad. Välj ert driftläge, kopiera raderna och starta därefter om alla PHP-processer.
BSI (den tyska federala myndigheten för informationssäkerhet) rekommenderar: Om uppdateringen inte kan göras direkt, ta webbservern tillfälligt offline.
Tillfälliga åtgärder enligt php.net, inte en ersättning för uppdateringen. memory_limit=-1 endast tillsammans med en minnesgräns via container eller cgroup. Säkerhetskopiera konfigurationen först.
Vem gör vad? Glappet mellan webbhotell och byrå
Många företag förlitar sig på att ”någon” patchar. I regel ser fördelningen ut så här:
| Uppgift | Webbhotell (delat webbhotell) | Byrå / webbdesign | PHP SOS |
|---|---|---|---|
| Uppdatera PHP-paketet | oftast ja | oftast inte | ja, eller tillsammans med ert webbhotell |
| Starta om alla workers och styrka det | delvis | nej | ja, med underlag |
| Kontrollera om intrång skedde före patchen | i regel inte | delvis | ja |
| Ta bort webshells och bakdörrar | i regel inte | delvis | ja |
| Rapport till ledning, dataskydd och försäkring | nej | sällan | ja |
| Härdning och löpande övervakning | delvis | delvis | ja |
Vad som är belagt och vad ni gör nu
Fakta ur meddelandena från php.net och BSI, bearbetade för ledning och administratörer.
Vad är PHP2Shell? Sårbarheten enkelt förklarad
PHP2Shell är två kritiska sårbarheter i själva PHP som låter angripare köra kod på webbservrar utan inloggning. Här är läget i klartext.
Läs mer →CVE-2026-109618: RCE via out-of-memory-tillstånd
CVE-2026-109618 är en av de två PHP2Shell-sårbarheterna: Ett out-of-memory-tillstånd kan avbryta PHP mitt i bearbetningen av en förfrågan. Åtgärdad från PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35.
Läs mer →CVE-2026-109619: RCE via föråldrat globalt tillstånd
CVE-2026-109619 är den andra PHP2Shell-sårbarheten: Internt tillstånd från en förfrågan kan finnas kvar efter att minnet frigjorts och användas av nästa förfrågan i samma worker.
Läs mer →CVE-2026-115560: anvisningen om Session Upload Progress
CVE-2026-115560 är en anvisning från php.net den 23 oktober 2026: möjlig kodkörning bara vid en ovanlig sessionskonfiguration. Åtgärd till nästa release: session.upload_progress.enabled=0.
Läs mer →Vilka PHP-versioner berörs?
PHP2Shell är åtgärdat i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre. Tabellen visar läget per gren.
Läs mer →Kontrollera PHP-version och patchstatus rätt
Den visade PHP-versionen ensam säger inte om PHP2Shell är stängt. Avgörande är paketstatus, backports och om de nya processerna verkligen körs.
Läs mer →För er plattform och er server
Var skadlig kod gömmer sig i WordPress, Shopware eller TYPO3 och hur ni verkligen patchar på Plesk, cPanel eller i containern.
Plattformar
Server och webbhotell
Varje bransch har andra uppgifter att förlora
Hälsouppgifter, klientsekretess, betalningsuppgifter: Vi anpassar granskning och rapport efter era skyldigheter.
10 steg innan vi tar över
Bocka av det som är klart. Listan sparas i er webbläsare.
Bockarna sparas bara i er webbläsare.
72 timmar, NIS2, försäkring
Allmän orientering för ledningen. Ingen juridisk rådgivning.
GDPR-anmälningsplikt: 72 timmar efter incidenten
Efter ett angrepp mot en webbserver kan det finnas en skyldighet att anmäla till tillsynsmyndigheten. Här står det allmänt när de 72 timmarna börjar löpa och vad som ingår.
Läs mer →NIS2 och säkerhet för webbservrar
NIS2 förpliktar många företag till riskhantering och rapportering. Här står det allmänt vad det betyder för webbservrar och var ni hittar tillförlitliga uppgifter.
Läs mer →Cyberförsäkring: vad som räknas vid en skada
Vid ett angrepp avgör tidig information till försäkringsgivaren, säkrade bevis och samordnade steg ofta ersättningen. Här står de typiska punkterna allmänt.
Läs mer →Företagsledningens ansvar vid IT-säkerhetsbrister
IT-säkerhet är en ledningsuppgift. Här står det allmänt vilka omsorgsplikter som gäller och hur ledningen fattar spårbara beslut vid sårbarheter som PHP2Shell.
Läs mer →Fackartiklar för administratörer och utvecklare
PHP2Shell-tidslinje: kronologi från 17 till 25 oktober 2026
Alla belagda datum kring PHP2Shell i en översikt, från det första observerade angreppsförsöket till läget den 25 oktober 2026, och vad de innebär för er granskning.
Läs mer →Bekräftelse på PHP-uppdatering från webbhotellet: så frågar ni efter patchstatus
En visad PHP-version bevisar lite efter PHP2Shell. Med den här mallen begär ni en bekräftelse från ert webbhotell som ni kan dokumentera.
Läs mer →Upptäcka och ta bort webshell
Hur ni spårar upp bakdörrar på PHP-webbservrar utan att förstöra spår, och varför det sällan räcker att bara radera.
Läs mer →Hitta WordPress-bakdörrar: spåra dem systematiskt
Var bakdörrar i WordPress typiskt gömmer sig och hur administratörer spårar upp dem systematiskt med WP-CLI och några få kommandon.
Läs mer →Konfigurera php.ini säkert
Vilka inställningar i php.ini som minskar angreppsytan, hur ni skyddar dem mot överskrivning och vad som gäller extra efter PHP2Shell.
Läs mer →Använd PHP disable_functions rätt
Med disable_functions spärrar ni riskfyllda PHP-funktioner. Så fastställer ni listan efter er applikation utan att lamslå webbplatsen.
Läs mer →Läge, anvisningar, beslutsstöd
Från BSI:s varningsnivå via paketens changelogs till frågan om ni ska installera om eller rensa. Varje artikel med källor.
PHP2Shell: vad som är belagt och vad som inte är det
En faktakoll om PHP2Shell: vilka uppgifter som kommer från primärkällor, vilka från mediarapporter och vilka påståenden som inte håller.
Läs mer →Ändra PHP-version i webbhotellets kundområde
Hur ni byter PHP-version i webbhotellets kundområde, vilken version ni väljer och vad ni kontrollerar före och efter.
Läs mer →Varningssignal: webbservern startar ett skal
Startar en PHP-FPM- eller webbserverprocess ett skal är det en av de starkaste varningssignalerna för ett intrång. Så kontrollerar ni processträdet, placerar undantagen och övervakar mönstret varaktigt.
Läs mer →Isolera PHP-FPM-pooler per webbplats
En egen pool per webbplats är början, inte slutet. Så kontrollerar ni befintliga pooler och härdar sockets, filändelser, statussidor, resurser och loggar.
Läs mer →Lagra lösenord säkert i PHP: använd password_hash rätt
Hur utvecklare lagrar lösenord i PHP med password_hash och password_verify, väljer lämplig metod och ersätter gamla MD5- eller SHA-1-hashar utan lösenordsåterställning för alla användare.
Läs mer →IT-leverantörsavtal: reglera säkerhetsskyldigheter tydligt
PHP2Shell visade hur ofta det är oklart vem som måste patcha. Vilka säkerhetsskyldigheter som hör hemma i avtal med byrå, webbhotell och IT-leverantör.
Läs mer →Programmeringsspråket PHP, begripligt förklarat
Hur PHP skapar en sida, vad SAPI, PHP-FPM och OPcache är och varför just det avgör säkerheten. Dessutom finns en ordlista med alla facktermer.
Vad är PHP2Shell?
PHP2Shell är namnet på två kritiska sårbarheter i själva PHP (CVE-2026-109618 och CVE-2026-109619, CVSS 9,2). De kan göra det möjligt för angripare att köra skadlig kod på servern utan inloggning. Patchar finns sedan den 21 oktober 2026.
Vilka PHP-versioner är säkra?
Rättningarna finns i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Webbhotell och distributioner levererar ibland backports utan att ändra versionsnumret. Det avgörande är paketets status eller leverantörens skriftliga bekräftelse.
Räcker det med en uppdatering av WordPress eller butiken?
Nej. Sårbarheten finns i PHP, inte i CMS:et. En CMS-uppdatering stänger den inte. Och en PHP-patch tar inte bort skadlig kod som redan har förts in tidigare.
Hur snabbt kan ni hjälpa till?
Vi arbetar på distans och startar så snart åtkomsten finns på plats. Skriv till oss via WhatsApp med system, PHP-version och vad ni har observerat. Då går vi igenom tillvägagångssättet direkt.
Arbetar ni även för byråer och webbhotellskunder?
Ja. Vi arbetar direkt för företag, i bakgrunden på uppdrag av byråer och i samråd med ert webbhotell om det är webbhotellet som sköter servern.
Måste vi anmäla incidenten?
Om personuppgifter kan ha påverkats gäller enligt art. 33 GDPR i regel en anmälningsfrist på 72 timmar från det att ni fått kännedom. Om den gäller i ert fall klarar ni ut med ert dataskyddsombud. Vi levererar den tekniska dokumentationen till det.
Varje timme räknas. Skriv till oss nu.
Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.