# Blogg: PHP2Shell, serversäkerhet och nödhjälp

> Blogg om PHP2Shell och serversäkerhet: läge, webbhotell, upptäckt, härdning, säker utveckling, ledning och beslutsstöd.

Källa: https://phpsos.de/sv/blog/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

Bedömning av läget, anvisningar för administratörer och beslutsstöd för ledningen. Sorterat efter ämne, varje artikel med källor.

- [PHP2Shell: vad som är belagt och vad som inte är det](https://phpsos.de/sv/blog/php2shell-was-belegt-ist/): 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.
- [Varför PHP-sårbarheten blev känd före patchen](https://phpsos.de/sv/blog/php-luecke-vorzeitig-bekannt/): Enligt rapporter blev detaljer om PHP2Shell offentliga innan embargot löpte ut. Vi förklarar förloppet och vad det betyder för er patchplanering.
- [Myndigheter tar webbplatser offline: vad företag kan lära](https://phpsos.de/sv/blog/behoerden-webseiten-offline/): Mainz, den hessiska delstatsregeringen och BKA tog webbplatser offline som försiktighetsåtgärd. Vad företag kan lära för det egna beslutet.
- [BSI:s varningsnivå orange: vad bedömningen betyder](https://phpsos.de/sv/blog/bsi-warnstufe-orange-erklaert/): BSI klassar PHP2Shell som 3 / orange. Vad skalan säger och inte säger, och hur företag omsätter bedömningen i beslut.
- [Vad CERT-EU och CERT-Bund rekommenderar om PHP2Shell](https://phpsos.de/sv/blog/cert-eu-empfehlungen-php/): De officiella instanserna är eniga: patcha direkt, annars isolera. Vi jämför rekommendationerna och visar hur isolering ser ut i praktiken.
- [Cloudflares skyddsregler mot PHP2Shell: vad de klarar och vad de inte klarar](https://phpsos.de/sv/blog/cloudflare-waf-php2shell/): Cloudflare rullade tidigt ut skyddsregler mot PHP2Shell. Varför det hjälper, varför det ändå inte ersätter PHP-uppdateringen och vilka inställningar ni bör kontrollera.
- [22,6 miljoner exponerade instanser: sätt siffrorna i rätt perspektiv](https://phpsos.de/sv/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel och andra anger mycket olika siffror för PHP2Shell. Vi förklarar vad som räknades och vilken siffra som verkligen gäller för er.
- [PHP2Shell på fem minuter: briefing för företagsledningen](https://phpsos.de/sv/blog/php2shell-briefing-geschaeftsfuehrung/): PHP-säkerhetsluckan PHP2Shell på en sida för beslutsfattare: läge, risk, fem frågor till IT och besluten för i dag.
- [PHP-säkerhetsluckan enkelt förklarad](https://phpsos.de/sv/blog/php-luecke-einfach-erklaert/): PHP2Shell för icke-tekniker: med vardagsbilder, en liten ordlista och tre typiska utgångslägen för vad ni som webbplatsägare bör göra.
- [PHP2Shell: 15 frågor från webbhotellskunder](https://phpsos.de/sv/blog/fragen-von-hosting-kunden/): Ligger er webbplats hos ett webbhotell och ni vill veta vad ni själva måste göra vid PHP2Shell? Här är de 15 vanligaste frågorna med korta svar.
- [Därför hjälper en WordPress-uppdatering inte mot PHP2Shell](https://phpsos.de/sv/blog/warum-wordpress-update-nicht-hilft/): Många ägare har efter rubrikerna uppdaterat WordPress och känner sig säkra. Varför det går i tomma intet vid PHP2Shell och vad som räknas i stället.
- [PHP2Shell och Log4Shell: vad sårbarheterna har gemensamt](https://phpsos.de/sv/blog/php2shell-und-log4shell/): Många jämför PHP2Shell med Log4Shell från 2021. Vad jämförelsen bär, var den haltar och vilka lärdomar från den tiden hjälper i dag.
- [Massskanning efter opatchad PHP: så går automatiserade angrepp till](https://phpsos.de/sv/blog/automatisierte-massenscans/): Efter PHP2Shell söker angripare automatiskt igenom internet efter sårbara servrar. Hur det går till, varför storleken inte spelar någon roll och vad som skyddar er.
- [Tidsfönstret mellan patch och angrepp](https://phpsos.de/sv/blog/zeitfenster-patch-angriff/): Vid PHP2Shell fanns angreppsförsök redan före patchen. Vi förklarar tidsfönstrets faser, hur ni mäter ert eget och hur ni förkortar det.
- [Efter PHP2Shell: varför fler rapporter är sannolika](https://phpsos.de/sv/blog/weitere-php-meldungen/): PHP2Shell är inte avslutat med patchen den 21 oktober. Varför uppföljande rapporter är att vänta och hur ni ställer in ert team på det.
- [PHP2Shell: lägesbilden efter första veckan](https://phpsos.de/sv/blog/lagebild-erste-woche/): En vecka efter det första observerade angreppsförsöket: läget för patchar, myndighetsvarningar, angrepp och avstängningar, rent uppdelat efter källor.
- [Farliga felaktiga tips om PHP2Shell som just nu cirkulerar](https://phpsos.de/sv/blog/gefaehrliche-falschtipps/): Blockera cookies, dölja felmeddelanden, bara uppdatera CMS: nio råd om PHP2Shell som skapar falsk trygghet, och vad som verkligen räknas.
- [Ändra PHP-version i webbhotellets kundområde](https://phpsos.de/sv/blog/php-version-hosting-aendern/): Hur ni byter PHP-version i webbhotellets kundområde, vilken version ni väljer och vad ni kontrollerar före och efter.
- [Debian och Ubuntu: är mitt PHP-paket patchat?](https://phpsos.de/sv/blog/debian-ubuntu-paket-gepatcht/): Vilka PHP-paket Debian och Ubuntu har rättat mot PHP2Shell, hur ni jämför den installerade nivån exakt och varför beviset ofta faller.
- [RHEL, AlmaLinux och Rocky Linux: kontrollera PHP-patchen](https://phpsos.de/sv/blog/rhel-almalinux-rocky-php/): Vad Red Hat har publicerat om PHP2Shell, hur ni styrker paketnivån på RHEL och dess efterbyggen och varför en omladdning inte räcker.
- [Förrådet sury.org: PHP-paket från tredjepartskälla](https://phpsos.de/sv/blog/sury-repository-php/): Många Debian- och Ubuntu-servrar hämtar PHP från sury-förrådet. Vad det betyder för uppdateringar, bevis och gamla PHP-versioner efter PHP2Shell.
- [Remi-förrådet: hålla PHP aktuellt på RHEL-system](https://phpsos.de/sv/blog/remi-repository-php/): Remi levererar aktuella PHP-versioner för RHEL-familjen, som modul eller installerbara parallellt. Så kontrollerar ni läget efter PHP2Shell och undviker bortglömda grenar.
- [Varför php -v visar samma nummer efter uppdateringen](https://phpsos.de/sv/blog/php-v-zeigt-alte-nummer/): Uppdateringen gick igenom, men php -v anger den gamla versionen. Oftast är det en backport och inget fel. Så skiljer ni ofarligt från verkliga problem.
- [Styrk CVE-nummer i paketets changelog](https://phpsos.de/sv/blog/cve-im-changelog-nachweisen/): Den som måste styrka en PHP-patch för ledning, revisorer eller försäkringsbolag behöver mer än ett versionsnummer. Så blir changelog-posten ett bevis.
- [Byta hostingleverantör efter en säkerhetsincident: vad bör ni tänka på?](https://phpsos.de/sv/blog/hoster-wechseln-nach-vorfall/): Efter en incident är önskan om en ny hostingleverantör begriplig. För att bytet inte ska ta med sig angriparen kommer det an på ordningsföljd och urval.
- [Flera PHP-versioner på en server: patcha var och en för sig](https://phpsos.de/sv/blog/mehrere-php-versionen-server/): På många servrar körs tre, fyra eller fler PHP-installationer sida vid sida. Efter PHP2Shell måste varje installation hittas, uppdateras och startas om.
- [Stäng av gamla PHP-versioner i hostingpanelen](https://phpsos.de/sv/blog/alte-php-versionen-abschalten/): PHP2Shell är ett bra tillfälle att bli av med gamla PHP-versioner. Så går ni tillväga i tre faser, så att ingen webbplats och inget cronjobb faller bort obemärkt.
- [Plesk: förstå PHP-handlers (FPM, FastCGI, Apache-modul)](https://phpsos.de/sv/blog/plesk-php-handler/): Vilken PHP-handler Plesk använder för en webbplats avgör isolering, konfiguration och risk. En jämförelse med blick på PHP2Shell.
- [CloudLinux och alt-php: vad hostingkunder bör veta](https://phpsos.de/sv/blog/cloudlinux-alt-php/): På CloudLinux-servrar körs webbplatser ofta med egna alt-php-paket. Varje version kräver sin egen patch, och bara serverns operatör kan installera den.
- [PHP på NAS, brandväggar och appliances: de bortglömda systemen](https://phpsos.de/sv/blog/php-auf-nas-und-appliances/): Det är inte bara webbservrar som använder PHP. Även NAS-system, brandväggar och specialenheter med webbgränssnitt kan vara berörda. Patcha kan där oftast bara tillverkaren, nåbarheten styr ni själva.
- [PHP hos moln- och PaaS-leverantörer: vem patchar körmiljön?](https://phpsos.de/sv/blog/paas-php-laufzeit/): På plattformstjänster beror PHP-patchen på driftmodellen. Avgörande är den körmiljö som faktiskt levererar, inte den lokala miljön eller applikationskoden.
- [Officiella PHP Docker-images: taggar, digests och ombyggnad](https://phpsos.de/sv/blog/offizielle-php-docker-images/): En tagg för den officiella PHP-imagen är en pekare som med tiden flyttas till nya nivåer. Den som vet vad tagg, variant och digest betyder väljer rätt image och kan styrka patchnivån.
- [CI/CD: bygg om PHP-images automatiskt](https://phpsos.de/sv/blog/php-images-in-ci-neu-bauen/): En image åldras även utan kodändring. Med tidsstyrda builds, en versionskontroll och utrullning via digest når PHP-patchar tillförlitligt produktion.
- [Långtidssupport för gamla PHP-versioner: alternativ och gränser](https://phpsos.de/sv/blog/langzeitsupport-alte-php-versionen/): Den som inte kan byta direkt från PHP 8.1 eller äldre hittar långtidssupport hos distributioner, tredjepartsleverantörer och kommersiella tjänster. Vad de vägarna ger, vad ni behöver skriftligt och var gränserna går.
- [Uppdatera PHP i Windows](https://phpsos.de/sv/blog/php-unter-windows-aktualisieren/): I Windows finns ingen automatisk PHP-uppdatering. Den som väljer rätt variant, kontrollerar nedladdningen och startar om alla processer får PHP2Shell-patchen rent på varje dator.
- [Varningssignal: webbservern startar ett skal](https://phpsos.de/sv/blog/webserver-startet-shell/): 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.
- [Hitta misstänkta processer på Linux-servrar](https://phpsos.de/sv/blog/verdaechtige-prozesse-linux/): Skadliga processer maskerar sig med harmlösa namn, körs från temporära mappar eller från raderade filer. Med några läsande kommandon hittar ni avvikelser och placerar dem.
- [Känn igen dolda cronjobb som bakdörr](https://phpsos.de/sv/blog/cronjobs-als-hintertuer/): Angripare använder schemalagda uppgifter för att komma tillbaka efter en sanering. Så kontrollerar ni crontabs, cron-kataloger, systemd-timers och at-jobb fullständigt och känner igen misstänkta poster.
- [Hitta nyligen ändrade filer på webbservern](https://phpsos.de/sv/blog/geaenderte-dateien-finden/): Efter ett möjligt intrång räknas det som har förändrats på servern. Så söker ni efter tidsfönster, använder mtime och ctime rätt och stämmer av mot paket, Git och säkerhetskopior.
- [PHP-filer i uppladdningsmappen: tolka fynden rätt](https://phpsos.de/sv/blog/php-dateien-im-upload-ordner/): En PHP-fil i uppladdningsmappen är nästan alltid ett larmtecken, men inte varje sådan är skadlig kod. Så bedömer ni fyndet utan att förstöra spår och klargör om någon har anropat den.
- [Känn igen förvrängd PHP-kod](https://phpsos.de/sv/blog/verschleierter-php-code/): Oläslig PHP-kod med eval och base64_decode är ett klassiskt tecken på insmugglad skadlig kod. Vilka mönster ni söker, hur ni hittar dem riskfritt och när förvrängning är legitim.
- [Kontrollera en servers utgående anslutningar](https://phpsos.de/sv/blog/ausgehende-verbindungen-pruefen/): En webbserver svarar framför allt på förfrågningar. Bygger den själv upp anslutningar till okända mål kan det betyda styrning av angripare eller dataläckage. Så kontrollerar och begränsar ni utgående trafik.
- [Hitta främmande adminkonton i CMS och server](https://phpsos.de/sv/blog/fremde-admin-konten-finden/): En okänd administratör är ofta den enklaste bakdörren. Så söker ni nivå för nivå efter främmande konton, även sådana som gränssnittet döljer.
- [Hitta och ta bort okända SSH-nycklar](https://phpsos.de/sv/blog/ssh-schluessel-pruefen/): En insmugglad SSH-nyckel öppnar dörren för angripare, även om alla lösenord är bytta. Så hittar ni varje authorized_keys-fil och kontrollerar varje post.
- [Kryptominer på webbservern: tecken och tillvägagångssätt](https://phpsos.de/sv/blog/kryptominer-auf-dem-server/): Ständigt full CPU utan att fler besökare kommer: det kan vara en kryptominer. Så kontrollerar ni belastningen, hittar processen och dess omstartsmekanismer och går ordnat tillväga.
- [Servern skickar spam: hitta orsakerna](https://phpsos.de/sv/blog/server-verschickt-spam/): Obeställbara e-postmeddelanden, spärrlistor, klagomål: när den egna servern skickar spam ligger oftast ett skript eller en kapad postlåda bakom. Så hittar ni källan.
- [SEO-spam och främmande sidor i Googles index](https://phpsos.de/sv/blog/seo-spam-im-google-index/): Plötsligt rankar sidor om läkemedel eller märkesvaror under er domän. Så tar ni reda på varifrån SEO-spamen kommer och får bort den ur indexet igen.
- [Webbplatsen omdirigerar till främmande sidor](https://phpsos.de/sv/blog/website-leitet-um/): Besökare hamnar på tävlingssidor eller tvivelaktiga butiker, men ni själva ser ingenting? Så hittar ni lagret där omdirigeringen sitter och åtgärdar den.
- [Säkra bevis innan ni installerar om servern](https://phpsos.de/sv/blog/beweise-sichern-vor-neuinstallation/): En ominstallation gör sig av med angriparen men också med alla spår. Den som först lägger en timme på bevissäkring kan senare säga vad som hände.
- [Upprätta tidslinjen för en incident](https://phpsos.de/sv/blog/zeitleiste-eines-vorfalls/): När kom angriparen, vad gjorde han, när märktes det? En ordentlig tidslinje besvarar de frågorna och är underlag för anmälningar, försäkring och rapport.
- [Jämför CMS-kärnfiler med originalet](https://phpsos.de/sv/blog/cms-kerndateien-vergleichen/): Jämförelsen med ett rent original visar varje ändrad fil, oavsett om en skanner känner igen den. Så bygger ni upp avstämningen för WordPress, Composer-projekt och systempaket.
- [Kontrollera databasen efter inplanterad kod](https://phpsos.de/sv/blog/datenbank-auf-schadcode-pruefen/): Den som bara kontrollerar filer missar hälften. Så söker ni igenom databasens innehåll, inställningar, trigger och konton efter inplanterad kod, läsande och på en kopia.
- [Skadekodsskanner för webbplatser: vad de hittar och vad de inte hittar](https://phpsos.de/sv/blog/grenzen-von-malware-scannern/): Skannern rapporterar ingenting, så allt är bra? Inte nödvändigtvis. Vilka slags webbplatsskannrar som finns, vad var och en ser och vad den i grunden inte kan se.
- [Isolera PHP-FPM-pooler per webbplats](https://phpsos.de/sv/blog/php-fpm-pools-isolieren/): 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.
- [Ställ in memory_limit rätt](https://phpsos.de/sv/blog/memory-limit-richtig-setzen/): memory_limit begränsar minnet per PHP-förfrågan. Efter PHP2Shell rekommenderar php.net tillfälligt motsatsen. Vad som gäller i normaldrift, under övergången och efter uppdateringen.
- [Begränsa post_max_size och upload_max_filesize förnuftigt](https://phpsos.de/sv/blog/post-max-size-upload-limits/): Uppladdningsgränser verkar på tre ställen: i webbservern, i PHP och i applikationen. Så sätter ni värdena samstämmigt, även med php.nets övergångsvärden för PHP2Shell.
- [Stäng av session.upload_progress: rätt och permanent](https://phpsos.de/sv/blog/session-upload-progress-abschalten/): Åtgärden mot CVE-2026-115560 och en av PHP2Shell-övergångsåtgärderna är snabbt satt. För att den ska hålla måste den stå på rätt ställe, vara spärrad och kontrolleras igen efter varje uppdatering.
- [expose_php och Server-huvudet: dölj versionsuppgifter](https://phpsos.de/sv/blog/expose-php-versionsangaben/): PHP, Nginx och Apache anger som standard sitt versionsnummer i varje svar. Det skyddar inte mot angrepp men ger skannrar en bekväm träfflista. Så stänger ni av det och behåller ändå överblicken.
- [display_errors off: stäng av felutskrifter i produktion](https://phpsos.de/sv/blog/display-errors-produktion/): Synliga PHP-felmeddelanden avslöjar sökvägar, databasnamn och versioner. Så stänger ni av dem i PHP, i ramverket och i webbservern utan att tappa felen ur sikte.
- [php_admin_value: spärra inställningar mot överskrivning](https://phpsos.de/sv/blog/php-admin-value-sperren/): En säkerhetsinställning hjälper föga om applikationen ändrar den igen med en kodrad. Med php_admin_value och php_admin_flag fastställer ni värden för PHP-FPM och Apache bindande.
- [Sätta minnesgränser med systemd och cgroups](https://phpsos.de/sv/blog/speichergrenzen-systemd-cgroups/): php.net rekommenderar som PHP2Shell-övergångsåtgärd memory_limit=-1 och en minnesgräns utanför PHP. Så sätter ni den gränsen med systemd och cgroups utan att en enskild worker drar med sig hela tjänsten.
- [Konfigurera Nginx för PHP säkert](https://phpsos.de/sv/blog/nginx-fuer-php-absichern/): De flesta svagheter i Nginx-upplägg för PHP sitter inte i Nginx utan i några få rader i PHP-locationen. Så konfigurerar ni överlämningen till PHP-FPM så att bara avsedda skript körs.
- [Konfigurera Apache för PHP säkert](https://phpsos.de/sv/blog/apache-fuer-php-absichern/): Apache är flexibel, och just det gör den känslig för felkonfiguration. Så kopplar ni in PHP via PHP-FPM, stänger .htaccess som bakdörr och ställer in de viktigaste kärnalternativen säkert.
- [Förbjud PHP-körning i uppladdningsmappar](https://phpsos.de/sv/blog/php-in-uploads-verbieten/): En webbshell behöver två saker: en mapp den kan skrivas till och en server som kör den. Så tar ni ifrån den det andra, och det i varje skrivbar mapp, inte bara i uploads.
- [Filtrera uppladdningsförfrågningar i kanten: möjligheter och risker](https://phpsos.de/sv/blog/upload-anfragen-am-rand-filtern/): Fackförfattare föreslår att blockera uppladdningsförfrågningar utanför riktiga uppladdningssökvägar i proxyn tills PHP är patchad. Det kan hjälpa men också lamslå formulär och beställningar. Så går ni kontrollerat tillväga.
- [Använd ModSecurity och OWASP Core Rule Set](https://phpsos.de/sv/blog/modsecurity-owasp-crs/): En egen Web Application Firewall med ModSecurity och OWASP Core Rule Set är gratis och kraftfull men ingen självgående lösning. Så väljer ni motor, startar utan avbrott och trimmar reglerna.
- [Ställ in Fail2ban för webbservrar](https://phpsos.de/sv/blog/fail2ban-fuer-webserver/): Fail2ban spärrar adresser som upprepat dyker upp i loggarna. För webbservrar medföljer färdiga filter, och med några få rader kommer egna till. Så ställer ni in det utan att spärra er själva eller era kunder.
- [Brandvägg för webbservrar: öppna bara nödvändiga portar](https://phpsos.de/sv/blog/firewall-fuer-webserver/): En webbserver behöver utåt oftast bara två portar. Ändå lyssnar på många servrar databaser, PHP-FPM eller administrationsgränssnitt mot internet. Så hittar ni öppna tjänster och stänger det som inte behövs.
- [Automatiska säkerhetsuppdateringar på Linux-servrar](https://phpsos.de/sv/blog/automatische-sicherheitsupdates/): Enligt rapporter levererade distributioner PHP-backports delvis redan den 21 oktober 2026, patchdagen. Den som använde automatiska säkerhetsuppdateringar hade dem snabbt på servern. För att de ska verka krävs omstarter, tredjepartskällor och kontroll.
- [Least Privilege: webbserveranvändarens behörigheter](https://phpsos.de/sv/blog/rechte-des-webserver-benutzers/): Inplanterad kod körs med webbserveranvändarens behörigheter. Vad det här kontot får göra avgör hur långt en angripare kommer. Så begränsar ni skal, sudo, cron, databas och filsystem till det nödvändiga.
- [Avskärma adminområden med IP, VPN eller extra skydd](https://phpsos.de/sv/blog/admin-bereiche-abschirmen/): Varför en webbplats backend inte behöver vara nåbar för hela världen och hur ni avskärmar den med IP-spärr, VPN eller förinställd inloggning utan att stänga ute er själva.
- [Konfigurera TLS och HTTPS rätt](https://phpsos.de/sv/blog/tls-https-richtig-konfigurieren/): Vilka TLS-versioner och cipher suites en webbserver bör erbjuda i dag, vad rekommendationerna utgår från och hur ni kontrollerar Nginx, Apache och utgående PHP-anslutningar.
- [CIS-benchmarks och BSI-moduler för webbservrar](https://phpsos.de/sv/blog/cis-benchmarks-bsi-bausteine/): Vilka härdningsstandarder som finns för Linux-webbservrar, hur CIS-benchmarks och IT-Grundschutz-moduler skiljer sig åt och hur ni gör en kontrollerbar föreskrift för era PHP-servrar av dem.
- [Lagra lösenord säkert i PHP: använd password_hash rätt](https://phpsos.de/sv/blog/passwoerter-in-php-speichern/): 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.
- [CSRF-skydd i PHP-applikationer](https://phpsos.de/sv/blog/csrf-schutz-php/): Hur utvecklare förhindrar Cross-Site Request Forgery i PHP-applikationer: tokens för varje förändrande förfrågan, ursprungskontroll i headern och SameSite-cookies som extra lager.
- [Validera och filtrera inmatning i PHP med filter_var](https://phpsos.de/sv/blog/eingaben-validieren-php/): Hur utvecklare kontrollerar inmatning i PHP med filter_var, filter_input_array och tillåtelselistor, vilka filter som är föråldrade och varför validering inte ersätter prepared statements och utdatakodning.
- [Förhindra command injection i PHP](https://phpsos.de/sv/blog/command-injection-php/): Hur utvecklare undviker command injection i PHP: ersätt systemkommandon med PHP-funktioner, använd proc_open utan skal, kontrollera argument och hitta farliga ställen i befintlig kod.
- [Förhindra Server-Side Request Forgery (SSRF) i PHP](https://phpsos.de/sv/blog/ssrf-in-php/): Hur utvecklare förhindrar att en PHP-applikation på uppdrag av främlingar frågar efter interna system: tillåtelselistor, protokollbegränsning, kontroll av den upplösta adressen och gränser i nätverket.
- [Förhindra XML External Entities (XXE) i PHP](https://phpsos.de/sv/blog/xxe-in-php/): Hur utvecklare bearbetar XML säkert i PHP: libxmls standardbeteende, riskabla alternativ som LIBXML_NOENT, skydd med entity-loader och LIBXML_NO_XXE samt typiska dolda XML-ingångar.
- [Type juggling i PHP: lösa jämförelser som säkerhetsrisk](https://phpsos.de/sv/blog/type-juggling-php/): Varför lösa jämförelser med == i PHP kan leda till säkerhetsluckor, vad som ändrades med PHP 8.0 och hur ni skriver robusta jämförelser i inloggningar, tokens och behörigheter.
- [Säkra slumptal och tokens i PHP med random_bytes](https://phpsos.de/sv/blog/sichere-tokens-php/): Hur utvecklare skapar tokens i PHP för lösenordslänkar, API-nycklar och engångskoder: kryptografiskt säkra källor, tillräcklig längd, lagring som hash och begränsad giltighet.
- [Skydda inloggningsuppgifter och .env-filer rätt](https://phpsos.de/sv/blog/env-dateien-schuetzen/): Hur ni skyddar databaslösenord, API-nycklar och andra hemligheter i PHP-projekt: .env-filer utanför webbroten, spärrar i webbservern, snäva rättigheter och ordnat utbyte efter en incident.
- [Offentlig .git-mapp: ett underskattat dataläckage](https://phpsos.de/sv/blog/git-ordner-oeffentlich/): Varför en webbrot som rullats ut med Git kan avslöja hela källkoden inklusive historiken, hur ni kontrollerar det, spärrar direkt och bygger driftsättningen varaktigt utan .git-mapp.
- [Backupfiler i webbroten: .zip, .sql och .bak](https://phpsos.de/sv/blog/backup-dateien-im-webroot/): Varför databasdumpar, arkiv och säkerhetskopior i den offentliga katalogen hör till de vanligaste dataläckorna, hur ni hittar dem, spärrar dem och tar reda på om de har hämtats.
- [phpinfo()-filer: varför de måste bort](https://phpsos.de/sv/blog/phpinfo-dateien-entfernen/): Efter PHP2Shell skapar många administratörer snabbt en info.php. Varför sådana filer är ett dataläckage, hur ni hittar dem och vilka kontrollvägar som är bättre.
- [Håll beroenden aktuella: Composer, npm och tillägg](https://phpsos.de/sv/blog/abhaengigkeiten-aktuell-halten/): Ett projekt består av tre paketvärldar: Composer, npm och CMS-tillägg. Så håller ni alla tre aktuella med fast rytm, tydligt ansvar och tester.
- [Säkerhetsinriktad kodgranskning för PHP-projekt](https://phpsos.de/sv/blog/sicherheits-code-review-php/): Hur team målinriktat går igenom egen PHP-kod efter säkerhetsluckor: typer av granskningar, kritiska funktioner, användbara verktyg och en checklista.
- [Logga säkert: logga fel utan dataläckage](https://phpsos.de/sv/blog/sicher-loggen-php/): Loggar hjälper vid felsökning och forensik men blir snabbt själva ett dataläckage. Vad PHP-applikationer bör logga, vad aldrig och hur man skyddar loggar.
- [Säkra REST-API:er i PHP](https://phpsos.de/sv/blog/rest-api-php-absichern/): Gränssnitt är ofta sämre skyddade än webbplatsen framför dem. De viktigaste reglerna för REST-API:er i PHP, från objektbehörighet till hastighetsbegränsning.
- [IT-leverantörsavtal: reglera säkerhetsskyldigheter tydligt](https://phpsos.de/sv/blog/dienstleistervertrag-sicherheit/): 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.
- [Personuppgiftsbehandling när leverantörer får åtkomst till servrar](https://phpsos.de/sv/blog/auftragsverarbeitung-serverzugriff/): Den som släpper in externa på servrar med kunddata behöver oftast ett personuppgiftsbiträdesavtal. Vad art. 28 GDPR kräver och hur ni organiserar åtkomster dataskyddsenligt i nödläge.
- [Sårbarhetshantering för medelstora företag](https://phpsos.de/sv/blog/schwachstellenmanagement-mittelstand/): Inget medelstort företag kan ta tag i varje varning direkt. En smal cykel av kartläggning, bedömning, beslut och underlag ser till att det viktigaste görs först.
- [Veta vad som körs: förteckning över alla webbplatser och servrar](https://phpsos.de/sv/blog/inventar-websites-server/): Vid PHP2Shell stannade många inte på patchen utan på frågan var PHP över huvud taget körs. Så bygger ni upp en förteckning över alla webbplatser och servrar.
- [Patchhantering som process i stället för brandkår](https://phpsos.de/sv/blog/patch-management-prozess/): Den som bara patchar när det brinner förlorar tid i ett skarpt läge. Så förenar en patchprocess med fasta klasser, fönster och underlag rutin och nödfall.
- [Nödkontakter: vem måste informeras och när?](https://phpsos.de/sv/blog/notfallkontakte-liste/): I ett skarpt läge avgör vem man når och när. Så bygger ni upp en lista över IT-nödkontakter, med utlösare, ersättare och de uppgifter som varje samtal kräver.
- [Vad en hackad server kostar: kostnadsposterna](https://phpsos.de/sv/blog/kostenposten-eines-hacks/): En hackad webbserver kostar mer än reparationen. Vilka kostnadsposter som uppstår och hur ni med egna siffror motiverar en budget för förebyggande arbete.
- [Informera kunder efter en incident](https://phpsos.de/sv/blog/kunden-nach-vorfall-informieren/): Oavsett om det är plikt eller frivilligt: så avgör ni efter en incident vem som ska informeras, vilka kanaler som är säkra och hur kundservice förbereds.
- [Leveranskedjan på webben: byrå, hostingleverantör, tilläggsleverantör](https://phpsos.de/sv/blog/lieferkette-agentur-hoster/): PHP2Shell visade hur många led det finns mellan en patch och er webbplats. Så lär ni känna leveranskedjan, säkrar den och fångar upp bortfall av enskilda led.
- [Säkerhetsmedvetenhet för administratörer och redaktörer: Security Awareness i webbteamet](https://phpsos.de/sv/blog/sicherheitsbewusstsein-redaktion/): Den som sköter webbplatser avgör varje dag om säkerheten, ofta utan att märka det. Så utbildar ni administratörer och redaktörer rollanpassat och utan bildspelsslag.
- [Krisövning vid bordet: spela igenom en incident på en webbserver](https://phpsos.de/sv/blog/notfalluebung-am-tisch/): En övning vid bordet kostar en eftermiddag och visar om er krisplan håller. Här hittar ni ett färdigt manus för en incident på en PHP-webbserver.
- [ISO 27001 och TISAX: vad som berör webbservrar](https://phpsos.de/sv/blog/iso-27001-tisax-webserver/): Den som driver ett ISMS enligt ISO 27001 eller har en TISAX-märkning måste tänka på webbservrar. Här står vilka krav de berör och vilka underlag som räknas efter PHP2Shell.
- [VdS 10000: informationssäkerhet för små och medelstora företag](https://phpsos.de/sv/blog/vds-10000-kmu/): VdS 10000 är en smal ram för informationssäkerhet i medelstora företag. Vad den kräver, vad som tillkom 2025 och vad det innebär för webbplatser och webbservrar.
- [Lessons learned: bli bättre efter incidenten](https://phpsos.de/sv/blog/lessons-learned-nach-vorfall/): Efter incidenten är före nästa. En strukturerad efterträff utan skuldbeläggning gör en dålig vecka till ett mätbart framsteg.
- [Patcha, stänga av eller avvakta? Ett beslutsstöd vid PHP-luckan](https://phpsos.de/sv/blog/patchen-abschalten-abwarten/): Vid en kritisk PHP-lucka måste de ansvariga besluta snabbt. Det här stödet ordnar de tre alternativen, anger kriterier och visar när det går att avvakta.
- [WAF eller uppdatering: varför ni behöver båda](https://phpsos.de/sv/blog/waf-oder-update/): En webbapplikationsbrandvägg kan fånga upp angrepp men stänger ingen lucka i PHP-tolken. När en WAF hjälper, var den slutar och hur ni kombinerar båda på ett rimligt sätt.
- [Installera om eller sanera servern? Beslutet efter ett angrepp](https://phpsos.de/sv/blog/neu-aufsetzen-oder-bereinigen/): Efter ett intrång finns två vägar: sanera servern eller bygga om den. Vilka kriterier som avgör, och varför ordningsföljden är viktigare än valet.
- [Åtgärda själv eller hämta en leverantör? En ärlig avvägning](https://phpsos.de/sv/blog/selbst-beheben-oder-dienstleister/): Inte varje säkerhetsläge kräver extern hjälp. Med dessa kriterier och ett kort självtest avgör ni om ert team klarar PHP2Shell på egen hand eller behöver stöd.
- [Välja en IT-säkerhetsleverantör: 12 frågor före uppdraget](https://phpsos.de/sv/blog/sicherheitsdienstleister-auswaehlen/): Att under tidspress hitta en bra säkerhetsleverantör är svårt. Dessa tolv frågor hjälper er att jämföra offerter sakligt utan att gå på reklamlöften.
- [Managed hosting eller egen server? Säkerhetsjämförelsen](https://phpsos.de/sv/blog/managed-oder-eigener-server/): PHP2Shell var ett stresstest för varje driftmodell. Jämförelsen visar när managed hosting är säkrare, när den egna servern är det och vilka blandformer som fungerar.
- [PHP-uppgradering eller backport? Beslutet för äldre system](https://phpsos.de/sv/blog/php-upgrade-oder-backport/): För gamla PHP-versioner finns efter PHP2Shell flera vägar: distributionens backport, tredjepartskälla, källkodspatch, långtidssupport eller uppgradering. Vad varje väg duger till och hur länge den bär.
- [Byta CMS efter hacket? När det hjälper och när inte](https://phpsos.de/sv/blog/cms-wechsel-nach-hack/): Efter ett intrång är förtroendet för CMS:et ofta borta. Men ett nytt system löser sällan den egentliga orsaken. När bytet är rimligt och hur det genomförs rent.
- [Statiska webbplatser: mindre PHP, mindre angreppsyta](https://phpsos.de/sv/blog/statische-website-alternative/): En statisk webbplats levererar färdiga HTML-filer och behöver ingen PHP på servern. Det minskar angreppsytan tydligt men för med sig egna gränser och skyldigheter.
- [Pentest, bug bounty eller sårbarhetsskanning? Välj rätt granskningsmetod](https://phpsos.de/sv/blog/pentest-bugbounty-scan/): Skanning, penetrationstest och bug bounty granskar webbplatser på helt olika sätt. Vad varje metod klarar, var den misslyckas och vilken ordning som passar ert företag.