PHP2Shell: vad du kan göra just nu

Två kritiska PHP-sårbarheter, med smeknamnen PHP2Shell (CVE-2026-109618 och CVE-2026-109619), lät en angripare köra kod på en webbserver utan att logga in. PHP får båda betyget 9,2 av 10 och skickar ut korrigeringar den 21 oktober 2026 kl. 14:00 UTC. Detaljer läckte ut en dag tidigare, och attacker har redan rapporterats.

Om din webbplats körs på PHP, här är vad du kan göra idag, från den riktiga lösningen till de allra snabbaste. För den fullständiga tekniska bakgrunden och en realtidslinje, läs Sansecs rådgivande.

1. Uppdatera PHP så snart som möjligt

Att uppdatera PHP är den enda riktiga lösningen. Allt annat i den här artikeln minskar bara risken fram till dess.

• Förväntade fixade versioner: 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Dessa siffror kommer från säkerhetsforskare och Linux-distributionsspårare; PHP självt bekräftar dem först med utgåvan.
• Äldre versioner (8.1, 8.0, 7.x, 5.x) är uttjänta och får ingen officiell lösning. Om du använder en av dessa, planera en uppgradering nu och håll de tillfälliga åtgärderna nedan på plats.
• Kontrollera att ditt paket verkligen innehåller fixen. Enbart versionsnumret kan vara missvisande, eftersom distributioner ofta backportar korrigeringar. Leta efter CVE-numret i ändringsloggen, till exempel med apt ändringslogg php8.3-cli (Debian/Ubuntu) eller rpm -q --ändringslogg php (RHEL/Alma/Rocky).
• Starta om PHP efter uppdatering (till exempel systemctl omstart php8.3-fpm), annars fortsätter den gamla koden att köras.
• På delad hosting, fråga din webbhotell när de kommer att lansera den uppdaterade PHP-versionen.

2. Stäng av sessionsuppladdningsförloppet

Tidig analys pekar på PHP:s funktion för sessionsuppladdningsförlopp, som är aktiverad som standard och aktiveras när en fil laddas upp. Att stänga av den och aktivera strikt sessionsläge minskar din exponering. Det åtgärdar inte sårbarheten, och säkerhetsforskare varnar för att det bara kan blockera en av de två buggarna.

Lägg till detta php.ini, .användare.ini eller din webbhotells PHP-inställningar:

session.upload_progress.enabled = Av session.use_strict_mode = 1

Om du använder PHP-FPM kan du också ställa in det per pool:

php_admin_flag[session.upload_progress.enabled] = av

Ladda om PHP efteråt. Väldigt få webbplatser förlitar sig på uppladdningsförloppsindikatorer som är byggda med den här funktionen, så den här ändringen förstör sällan något.

3. Blockera uppladdningar på webbservern (nginx)

De kända attackvägarna använder flerpartsförfrågningar, det format webbläsare använder för att ladda upp filer. Att blockera dessa på webbservern stoppar dem innan de når PHP. Sansec rekommenderar detta som en tillfällig åtgärd.

Lägg till detta i din servern block, utanför någon plats:

om ($http_content_type ~* "multipart/form-data") { rewrite ^ /__upload_blocked last; } location = /__upload_blocked { internal; default_type text/plain; return 403 "Uppladdning är för närvarande inte tillåten på grund av en stor bugg. Återkommer snart.\n"; }

Besökare som försöker ladda upp får nu ett tydligt meddelande istället för en ren felsida. inre linje betyder att ingen kan öppna /__upload_blocked direkt, och dina andra felsidor förblir desamma.

Testa och ladda om:

nginx -t && nginx -s reload curl -i -F "x=1" https://dinwebbplats.exampel/ curl -i -F "x=1" https://dinwebbplats.exampel/någon/undersida

Både ringla tester bör återkomma 403 med meddelandet. Om en undersida fortfarande laddas, kontrollera att om sitter direkt i servern och inte inuti en plats, och att du redigerade server block som faktiskt betjänar webbplatsen. En vanlig sidförfrågan utan uppladdning borde fortfarande fungera.

4. Blockera uppladdningar på webbservern (Apache / .htaccess)

På Apache 2.4, lägg till detta i .htaccess i ditt dokumentrot. Det fungerar var som helst i filen, inklusive ovanför eller under ditt CMS egna regler:

ErrorDocument 403 "Uppladdning är för närvarande inte tillåten på grund av en stor bugg. Återkommer snart." Kräv att alla nekades.

Apache vägrar begäran innan några omskrivningsregler körs, så varje URL täcks, inte bara hemsidan. En version baserad på Omskrivningsregel [F] är lätt att göra fel: placerad under ett CMS-regler blockerar den bara hemsidan medan undersidor fortfarande når PHP.

• Använd .htaccess Apache läser faktiskt för din webbplats. För Magento 2 är det ofta den som finns i pub/.
• En undermapp med sin egen .htaccess, till exempel en andra WordPress-installation, kan behöva samma block.
• Ett 500-fel efter att ha sparat betyder vanligtvis att din värd inte tillåter dessa direktiv i .htaccess. Be dem att tillåta det eller att lägga till regeln i serverkonfigurationen.

Testa startsidan och minst en undersida. Båda ska returnera 403 med meddelandet:

curl -i -F "x=1" https://dinwebbplats.exempel/ curl -i -F "x=1" https://dinwebbplats.exempel/någon/undersida

Om en undersida fortfarande returnerar själva sidan, gäller inte blockeringen för den URL:en.

Vad man kan förvänta sig och när man ska ångra det

Webbserverblocket stoppar alla flerpartsförfrågningar, inte bara filuppladdningar. Förvänta dig att dessa slutar fungera tills du tar bort det:

• Fil- och bilduppladdningar, inklusive i ditt administratörsområde eller CMS
• Vissa vanliga formulär, såsom kontaktformulär eller produktredigeringar, som skickas in som flerdelade formulär
• Bakgrundsuppladdningar i JavaScript, vilket kan visa ett generiskt fel istället för ditt meddelande

PHP-inställningarna från steg 2 orsakar sällan problem och kan finnas kvar. Ta bort webbserverblockeringen när PHP har uppdaterats och du har bekräftat korrigeringen i din paketändringslogg. Ladda sedan om nginx eller Apache och testa en uppladdning.

Vidare läsning

• Kritisk PHP RCE: CVE-2026-109618 och CVE-2026-109619 (Sansec): rådgivning, begränsningar och realtidslinje
• Kommande kritisk PHP-säkerhetsutgåva (PHP-meddelande)
• Stor säkerhetsvarning: PHP sårbar för kritisk RCE (Patchstack)
• PHP2Shell: vad som egentligen skyddar dig före patchen (Hackernyheterna)

Senast uppdaterad 21 oktober 2026