# Blog: PHP2Shell, serversikkerhed og nødhjælp

> Blog om PHP2Shell og serversikkerhed: situation, hosting, opdagelse, hærdning, sikker udvikling, ledelse og beslutningsstøtte.

Kilde: https://phpsos.de/da/blog/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

Vurdering af situationen, vejledninger til administratorer og beslutningsstøtte til ledelsen. Sorteret efter emne, hver artikel med kilder.

- [PHP2Shell: Hvad er dokumenteret, og hvad er ikke](https://phpsos.de/da/blog/php2shell-was-belegt-ist/): Et faktatjek om PHP2Shell: Hvilke udsagn stammer fra primære kilder, hvilke fra mediedækning, og hvilke påstande ikke holder.
- [Hvorfor PHP-sårbarheden blev kendt før patchen](https://phpsos.de/da/blog/php-luecke-vorzeitig-bekannt/): Ifølge rapporter blev detaljer om PHP2Shell offentlige, før embargoen udløb. Vi forklarer forløbet og hvad det betyder for jeres patchplanlægning.
- [Myndigheder tager websites af nettet: Hvad virksomheder kan lære](https://phpsos.de/da/blog/behoerden-webseiten-offline/): Mainz, den hessiske delstatsregering og BKA tog websites af nettet som forholdsregel. Hvad virksomheder kan lære af det til deres egen beslutning.
- [BSI-advarselsniveau orange: Hvad vurderingen betyder](https://phpsos.de/da/blog/bsi-warnstufe-orange-erklaert/): BSI (det tyske forbundsagentur for informationssikkerhed) har vurderet PHP2Shell til 3 / orange. Hvad skalaen siger, hvad den ikke siger, og hvordan virksomheder omsætter vurderingen til beslutninger.
- [Hvad CERT-EU og CERT-Bund anbefaler om PHP2Shell](https://phpsos.de/da/blog/cert-eu-empfehlungen-php/): De officielle instanser er enige: patch straks, ellers isolér. Vi sammenligner anbefalingerne og viser, hvordan isolering ser ud i praksis.
- [Cloudflares beskyttelsesregler mod PHP2Shell: Hvad de udretter, og hvad ikke](https://phpsos.de/da/blog/cloudflare-waf-php2shell/): Cloudflare udrullede tidligt beskyttelsesregler mod PHP2Shell. Hvorfor det hjælper, hvorfor det alligevel ikke erstatter PHP-opdateringen, og hvilke indstillinger I bør kontrollere.
- [22,6 millioner eksponerede instanser: Sådan vurderer I tallene rigtigt](https://phpsos.de/da/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel og andre nævner meget forskellige tal om PHP2Shell. Vi forklarer, hvad der blev talt, og hvilket tal der virkelig tæller for jer.
- [PHP2Shell på fem minutter: Briefing til ledelsen](https://phpsos.de/da/blog/php2shell-briefing-geschaeftsfuehrung/): PHP-sårbarheden PHP2Shell på én side til beslutningstagere: situation, risiko, fem spørgsmål til it og beslutningerne for i dag.
- [PHP-sikkerhedssårbarheden forklaret enkelt](https://phpsos.de/da/blog/php-luecke-einfach-erklaert/): PHP2Shell for ikke-teknikere: med hverdagsbilleder, en lille ordliste og tre typiske udgangssituationer for, hvad I som website-ejere bør gøre.
- [PHP2Shell: 15 spørgsmål fra hostingkunder](https://phpsos.de/da/blog/fragen-von-hosting-kunden/): Ligger jeres website hos en hostingudbyder, og vil I vide, hvad I selv skal gøre ved PHP2Shell? Her er de 15 hyppigste spørgsmål med korte svar.
- [Hvorfor en WordPress-opdatering ikke hjælper mod PHP2Shell](https://phpsos.de/da/blog/warum-wordpress-update-nicht-hilft/): Mange driftsansvarlige har opdateret WordPress efter overskrifterne og føler sig sikre. Hvorfor det går i stå ved PHP2Shell, og hvad der tæller i stedet.
- [PHP2Shell og Log4Shell: Hvad sårbarhederne har tilfælles](https://phpsos.de/da/blog/php2shell-und-log4shell/): Mange sammenligner PHP2Shell med Log4Shell fra 2021. Hvad sammenligningen bærer, hvor den halter, og hvilke erfaringer fra dengang hjælper i dag.
- [Massescanninger efter upatchet PHP: Sådan forløber automatiserede angreb](https://phpsos.de/da/blog/automatisierte-massenscans/): Efter PHP2Shell gennemsøger angribere internettet automatiseret efter sårbare servere. Hvordan det forløber, hvorfor størrelsen er ligegyldig, og hvad der beskytter jer.
- [Tidsvinduet mellem patch og angreb](https://phpsos.de/da/blog/zeitfenster-patch-angriff/): Ved PHP2Shell var der angrebsforsøg allerede før patchen. Vi forklarer tidsvinduets faser, hvordan I måler jeres eget, og hvordan I forkorter det.
- [Efter PHP2Shell: Hvorfor flere meddelelser er sandsynlige](https://phpsos.de/da/blog/weitere-php-meldungen/): PHP2Shell er ikke afsluttet med patchen fra den 21. oktober. Hvorfor opfølgende meddelelser er at vente, og hvordan I indstiller jeres team på det.
- [PHP2Shell: Situationsbilledet for den første uge](https://phpsos.de/da/blog/lagebild-erste-woche/): En uge efter det første observerede angrebsforsøg: status for patches, myndighedsadvarsler, angreb og nedlukninger, ordnet efter kilder.
- [Farlige falske tips om PHP2Shell, der cirkulerer lige nu](https://phpsos.de/da/blog/gefaehrliche-falschtipps/): Blokere cookies, skjule fejlmeddelelser, kun opdatere CMS'et: Ni råd om PHP2Shell, der skaber falsk tryghed, og hvad der virkelig tæller.
- [Skift PHP-version i hostingens kundeområde](https://phpsos.de/da/blog/php-version-hosting-aendern/): Hvordan I omstiller PHP-versionen i jeres hostingudbyders kundeområde, hvilken version I vælger, og hvad I kontrollerer før og efter.
- [Debian og Ubuntu: Er min PHP-pakke patchet?](https://phpsos.de/da/blog/debian-ubuntu-paket-gepatcht/): Hvilke PHP-pakker Debian og Ubuntu har rettet mod PHP2Shell, hvordan I sammenligner den installerede status nøjagtigt, og hvad dokumentationen kan strande på.
- [RHEL, AlmaLinux og Rocky Linux: Kontrollér PHP-patchen](https://phpsos.de/da/blog/rhel-almalinux-rocky-php/): Hvad Red Hat har offentliggjort om PHP2Shell, hvordan I dokumenterer pakkestatus på RHEL og efterbygningerne, og hvorfor en genindlæsning ikke er nok.
- [sury.org-repositoryet: PHP-pakker fra en tredjepartskilde](https://phpsos.de/da/blog/sury-repository-php/): Mange Debian- og Ubuntu-servere får PHP fra sury-repositoryet. Hvad det betyder for opdateringer, dokumentation og gamle PHP-versioner efter PHP2Shell.
- [Remi-repositoryet: Hold PHP aktuelt på RHEL-systemer](https://phpsos.de/da/blog/remi-repository-php/): Remi leverer aktuelle PHP-versioner til RHEL-familien, som modul eller installerbart parallelt. Sådan kontrollerer I status efter PHP2Shell og undgår glemte grene.
- [Hvorfor php -v viser det samme nummer efter opdateringen](https://phpsos.de/da/blog/php-v-zeigt-alte-nummer/): Opdateringen kørte, men php -v melder den gamle version. Oftest er det en backport og ikke en fejl. Sådan skelner I harmløse fra virkelige problemer.
- [Dokumentér CVE-numre i pakkens changelog](https://phpsos.de/da/blog/cve-im-changelog-nachweisen/): Den, der skal dokumentere en PHP-patch over for ledelse, revisorer eller forsikringsselskaber, har brug for mere end et versionsnummer. Sådan bliver changelog-posten til et bevis.
- [Skift af hostingudbyder efter en sikkerhedshændelse: Hvad skal I være opmærksomme på?](https://phpsos.de/da/blog/hoster-wechseln-nach-vorfall/): Efter en hændelse er ønsket om en ny hostingudbyder forståeligt. For at skiftet ikke tager angriberen med, kommer det an på rækkefølge og valg.
- [Flere PHP-versioner på én server: Patch hver enkelt for sig](https://phpsos.de/da/blog/mehrere-php-versionen-server/): På mange servere kører tre, fire eller flere PHP-installationer side om side. Efter PHP2Shell skal hver enkelt findes, opdateres og genstartes.
- [Slå gamle PHP-versioner fra i hostingpanelet](https://phpsos.de/da/blog/alte-php-versionen-abschalten/): PHP2Shell er en god anledning til at blive af med gamle PHP-versioner. Sådan går I frem i tre faser, så intet website og intet cronjob falder ubemærket ud.
- [Plesk: Forstå PHP-handlere (FPM, FastCGI, Apache-modul)](https://phpsos.de/da/blog/plesk-php-handler/): Hvilken PHP-handler Plesk bruger til et website, afgør isolation, konfiguration og risiko. En sammenligning med blik på PHP2Shell.
- [CloudLinux og alt-php: Hvad hostingkunder bør vide](https://phpsos.de/da/blog/cloudlinux-alt-php/): På CloudLinux-servere kører websites ofte med egne alt-php-pakker. Hver af disse versioner kræver sin egen patch, og kun serveroperatøren kan indspille den.
- [PHP på NAS, firewalls og appliances: de glemte systemer](https://phpsos.de/da/blog/php-auf-nas-und-appliances/): Det er ikke kun webservere, der bruger PHP. Også NAS-systemer, firewalls og specialenheder med webgrænseflade kan være berørt. Patchen kan dér som regel kun producenten levere, tilgængeligheden regulerer I selv.
- [PHP hos cloud- og PaaS-udbydere: Hvem patcher kørselsmiljøet?](https://phpsos.de/da/blog/paas-php-laufzeit/): På platformtjenester afhænger PHP-patchen af driftsmodellen. Afgørende er det kørselsmiljø, der faktisk leverer, ikke det lokale miljø eller applikationskoden.
- [Officielle PHP Docker-images: Tags, digests og genopbygning](https://phpsos.de/da/blog/offizielle-php-docker-images/): Et tag på det officielle PHP-image er en pegepind, der med tiden flytter sig til nye statusser. Den, der ved, hvad tag, variant og digest betyder, vælger det rigtige image og kan dokumentere patchstatus.
- [CI/CD: Byg PHP-images automatisk om](https://phpsos.de/da/blog/php-images-in-ci-neu-bauen/): Et image forældes også uden kodeændringer. Med tidsstyrede builds, en versionskontrol og udrulning via digest når PHP-patches pålideligt ud i produktion.
- [Langtidssupport til gamle PHP-versioner: Muligheder og grænser](https://phpsos.de/da/blog/langzeitsupport-alte-php-versionen/): Den, der ikke straks kan skifte fra PHP 8.1 eller ældre, finder langtidssupport hos distributioner, tredjepartsudbydere og kommercielle tjenester. Hvad disse veje kan, hvad I skal have skriftligt, og hvor grænserne går.
- [Opdatér PHP under Windows](https://phpsos.de/da/blog/php-unter-windows-aktualisieren/): Under Windows findes der ingen automatisk PHP-opdatering. Den, der vælger den rette variant, kontrollerer downloadet og genstarter alle processer, får PHP2Shell-patchen rent ud på hver computer.
- [Advarselstegn: Webserveren starter en shell](https://phpsos.de/da/blog/webserver-startet-shell/): Starter en PHP-FPM- eller webserverproces en shell, er det et af de stærkeste advarselstegn på et indbrud. Sådan kontrollerer I procestræet, vurderer undtagelser og overvåger mønsteret varigt.
- [Find mistænkelige processer på Linux-servere](https://phpsos.de/da/blog/verdaechtige-prozesse-linux/): Skadelige processer camouflerer sig med harmløse navne og kører fra midlertidige mapper eller fra slettede filer. Med få læsende kommandoer finder I det påfaldende og vurderer det.
- [Genkend skjulte cronjobs som bagdør](https://phpsos.de/da/blog/cronjobs-als-hintertuer/): Angribere bruger planlagte opgaver til at vende tilbage efter en oprydning. Sådan kontrollerer I crontabs, cron-mapper, systemd-timere og at-opgaver fuldstændigt og genkender mistænkelige poster.
- [Find nyligt ændrede filer på webserveren](https://phpsos.de/da/blog/geaenderte-dateien-finden/): Efter et muligt indbrud tæller det, hvad der har ændret sig på serveren. Sådan søger I efter tidsvinduer, bruger mtime og ctime korrekt og afstemmer med pakker, Git og backups.
- [PHP-filer i upload-mappen: Tolk fundstederne korrekt](https://phpsos.de/da/blog/php-dateien-im-upload-ordner/): En PHP-fil i upload-mappen er næsten altid et alarmtegn, men ikke enhver er skadelig kode. Sådan vurderer I fundet uden at ødelægge spor og afklarer, om nogen har kaldt den.
- [Genkend tilsløret PHP-kode](https://phpsos.de/da/blog/verschleierter-php-code/): Ulæselig PHP-kode med eval og base64_decode er et klassisk tegn på indsmuglet skadelig kode. Hvilke mønstre I skal søge efter, hvordan I finder dem risikofrit, og hvornår tilsløring er legitim.
- [Kontrollér en servers udgående forbindelser](https://phpsos.de/da/blog/ausgehende-verbindungen-pruefen/): En webserver svarer først og fremmest på forespørgsler. Opbygger den selv forbindelser til ukendte mål, kan det betyde styring fra angribere eller dataudsivning. Sådan kontrollerer og begrænser I udgående trafik.
- [Find fremde admin-konti i CMS og server](https://phpsos.de/da/blog/fremde-admin-konten-finden/): En ukendt administrator er ofte den enkleste bagdør. Sådan søger I niveau for niveau efter fremmede konti, også efter dem, som grænsefladen skjuler.
- [Find og fjern ukendte SSH-nøgler](https://phpsos.de/da/blog/ssh-schluessel-pruefen/): En indsmuglet SSH-nøgle åbner døren for angribere, selv om alle adgangskoder er ændret. Sådan finder I hver authorized_keys-fil og kontrollerer hver post.
- [Kryptominer på webserveren: Tegn og fremgangsmåde](https://phpsos.de/da/blog/kryptominer-auf-dem-server/): Konstant fuld CPU, uden at der kommer flere besøgende: Det kan være en kryptominer. Sådan kontrollerer I belastningen, finder processen og dens genstartsmekanismer og går ordnet frem.
- [Serveren sender spam: Find årsagerne](https://phpsos.de/da/blog/server-verschickt-spam/): Leveringsfejl, blokeringslister, klager: Når jeres egen server sender spam, står der oftest et script eller en kapret postkasse bag. Sådan finder I kilden.
- [SEO-spam og fremmede sider i Googles indeks](https://phpsos.de/da/blog/seo-spam-im-google-index/): Pludselig rangerer sider om medicin eller mærkevarer under jeres domæne. Sådan finder I ud af, hvor SEO-spammen kommer fra, og får den væk fra indekset igen.
- [Websitet omdirigerer til fremmede sider](https://phpsos.de/da/blog/website-leitet-um/): Besøgende havner på konkurrencer eller tvivlsomme shops, men I selv ser intet? Sådan finder I det lag, hvor viderestillingen sidder, og fjerner den.
- [Sikr beviser, før I sætter serveren op påny](https://phpsos.de/da/blog/beweise-sichern-vor-neuinstallation/): En genopbygning fjerner angriberen, men også alle spor. Den, der først bruger en time på bevissikring, kan senere sige, hvad der skete.
- [Opret tidslinjen for en hændelse](https://phpsos.de/da/blog/zeitleiste-eines-vorfalls/): Hvornår kom angriberen, hvad gjorde han, hvornår blev det opdaget? En ren tidslinje besvarer de spørgsmål og er grundlaget for anmeldelser, forsikring og rapport.
- [Sammenlign CMS-kernefiler med originalen](https://phpsos.de/da/blog/cms-kerndateien-vergleichen/): Sammenligningen med en ren original viser hver ændret fil, uanset om en scanner kender den. Sådan opbygger I afstemningen for WordPress, Composer-projekter og systempakker.
- [Kontrollér databasen for indsmuglet kode](https://phpsos.de/da/blog/datenbank-auf-schadcode-pruefen/): Den, der kun kontrollerer filer, overser halvdelen. Sådan gennemsøger I databasens indhold, indstillinger, triggere og konti for indsmuglet kode, læsende og på en kopi.
- [Malwarescannere til websites: Hvad de finder, og hvad ikke](https://phpsos.de/da/blog/grenzen-von-malware-scannern/): Scanneren melder intet, så er alt godt? Ikke nødvendigvis. Hvilke slags website-scannere der findes, hvad hver enkelt ser, og hvad den principielt ikke kan se.
- [Isolér PHP-FPM-pools pr. website](https://phpsos.de/da/blog/php-fpm-pools-isolieren/): En egen pool pr. website er begyndelsen, ikke enden. Sådan kontrollerer I eksisterende pools og hærder sockets, endelser, statussider, ressourcer og logs.
- [Sæt memory_limit rigtigt](https://phpsos.de/da/blog/memory-limit-richtig-setzen/): memory_limit begrænser hukommelsen pr. PHP-forespørgsel. Efter PHP2Shell råder php.net midlertidigt til det modsatte. Hvad der gælder i normal drift, i overgangen og efter opdateringen.
- [Begræns post_max_size og upload_max_filesize fornuftigt](https://phpsos.de/da/blog/post-max-size-upload-limits/): Upload-grænser virker tre steder: i webserveren, i PHP og i applikationen. Sådan sætter I værdierne konsistent, også med php.nets overgangsværdier til PHP2Shell.
- [Slå session.upload_progress fra: rigtigt og varigt](https://phpsos.de/da/blog/session-upload-progress-abschalten/): Afhjælpningen mod CVE-2026-115560 og en af PHP2Shell-overgangsforanstaltningerne er hurtigt sat. For at den holder, skal den stå det rigtige sted, være låst og kontrolleres igen efter hver opdatering.
- [expose_php og Server-headeren: Skjul versionsangivelser](https://phpsos.de/da/blog/expose-php-versionsangaben/): PHP, Nginx og Apache nævner som standard deres versionsnummer i hvert svar. Det beskytter ikke mod angreb, men giver scannere en bekvem trefferliste. Sådan slår I det fra og bevarer alligevel overblikket.
- [display_errors off: Slå fejludskrifter fra i produktion](https://phpsos.de/da/blog/display-errors-produktion/): Synlige PHP-fejlmeddelelser afslører stier, databasenavne og versioner. Sådan slår I dem fra i PHP, i frameworket og i webserveren uden at miste fejlene af syne.
- [php_admin_value: Lås indstillinger mod overskrivning](https://phpsos.de/da/blog/php-admin-value-sperren/): En sikkerhedsindstilling nytter lidt, hvis applikationen ændrer den igen med en enkelt kodelinje. Med php_admin_value og php_admin_flag fastlægger I værdier bindende for PHP-FPM og Apache.
- [Sæt hukommelsesgrænser med systemd og cgroups](https://phpsos.de/da/blog/speichergrenzen-systemd-cgroups/): php.net anbefaler som PHP2Shell-overgangsforanstaltning memory_limit=-1 og en hukommelsesgrænse uden for PHP. Sådan sætter I grænsen med systemd og cgroups, uden at en enkelt worker trækker hele tjenesten med sig.
- [Konfigurér Nginx sikkert til PHP](https://phpsos.de/da/blog/nginx-fuer-php-absichern/): De fleste svagheder i Nginx-opsætninger til PHP sidder ikke i Nginx, men i få linjer i PHP-location'en. Sådan konfigurerer I overdragelsen til PHP-FPM, så kun de ønskede scripts udføres.
- [Konfigurér Apache sikkert til PHP](https://phpsos.de/da/blog/apache-fuer-php-absichern/): Apache er fleksibel, og netop det gør den sårbar over for fejlkonfiguration. Sådan binder I PHP på via PHP-FPM, lukker .htaccess som bagdør og indstiller de vigtigste kerneindstillinger sikkert.
- [Forbyd PHP-udførelse i upload-mapper](https://phpsos.de/da/blog/php-in-uploads-verbieten/): En webshell kræver to ting: en mappe, den kan skrives til, og en server, der udfører den. Sådan fratager I den det andet, og det i hver skrivbar mappe, ikke kun i uploads.
- [Filtrér upload-forespørgsler i kanten: Muligheder og risici](https://phpsos.de/da/blog/upload-anfragen-am-rand-filtern/): Fagforfattere foreslår at blokere upload-forespørgsler uden for rigtige upload-stier ved proxyen, indtil PHP er patchet. Det kan hjælpe, men også lamme formularer og bestillinger. Sådan går I kontrolleret frem.
- [Brug ModSecurity og OWASP Core Rule Set](https://phpsos.de/da/blog/modsecurity-owasp-crs/): En egen web application firewall med ModSecurity og OWASP Core Rule Set er gratis og stærk, men ingen selvløber. Sådan vælger I engine, starter uden udfald og afstemmer reglerne.
- [Opsæt Fail2ban til webservere](https://phpsos.de/da/blog/fail2ban-fuer-webserver/): Fail2ban spærrer adresser, der gentagne gange falder i øjnene i logs. Til webservere medfølger færdige filtre, og med få linjer kommer egne til. Sådan opsætter I det uden at låse jer selv eller jeres kunder ude.
- [Firewall til webservere: Åbn kun nødvendige porte](https://phpsos.de/da/blog/firewall-fuer-webserver/): En webserver har udadtil som regel kun brug for to porte. Alligevel lytter databaser, PHP-FPM eller administrationsflader på mange servere på internettet. Sådan finder I åbne tjenester og lukker det, der ikke bruges.
- [Automatiske sikkerhedsopdateringer på Linux-servere](https://phpsos.de/da/blog/automatische-sicherheitsupdates/): Ifølge rapporter leverede distributioner PHP-backports til dels allerede den 21. oktober 2026, dagen for patcherne. Den, der bruger automatiske sikkerhedsopdateringer, havde dem hurtigt på serveren. For at de også virker, kræves genstarter, tredjepartskilder og kontrol.
- [Least Privilege: Webserver-brugerens rettigheder](https://phpsos.de/da/blog/rechte-des-webserver-benutzers/): Indsmuglet kode kører med webserver-brugerens rettigheder. Hvad denne konto må, afgør, hvor langt en angriber kommer. Sådan begrænser I shell, sudo, cron, database og filsystem til det nødvendige.
- [Afskærm adminområder med IP, VPN eller ekstra beskyttelse](https://phpsos.de/da/blog/admin-bereiche-abschirmen/): Hvorfor et websites backend ikke behøver at kunne nås fra hele verden, og hvordan I afskærmer det med IP-frigivelse, VPN eller forudgående login uden at låse jer selv ude.
- [Konfigurer TLS og HTTPS rigtigt](https://phpsos.de/da/blog/tls-https-richtig-konfigurieren/): Hvilke TLS-versioner og cipher suites en webserver bør tilbyde i dag, hvad anbefalingerne bygger på, og hvordan I kontrollerer Nginx, Apache og PHP's udgående forbindelser.
- [CIS-benchmarks og BSI-moduler til webservere](https://phpsos.de/da/blog/cis-benchmarks-bsi-bausteine/): Hvilke hærdningsstandarder der findes til Linux-webservere, hvordan CIS-benchmarks og IT-Grundschutz-moduler adskiller sig, og hvordan I gør dem til en kontrollerbar standard for jeres PHP-servere.
- [Gem adgangskoder sikkert i PHP: Brug password_hash rigtigt](https://phpsos.de/da/blog/passwoerter-in-php-speichern/): Hvordan udviklere gemmer adgangskoder i PHP med password_hash og password_verify, vælger den passende metode og afløser gamle MD5- eller SHA-1-hashes uden at nulstille adgangskoden for alle brugere.
- [CSRF-beskyttelse i PHP-applikationer](https://phpsos.de/da/blog/csrf-schutz-php/): Hvordan udviklere forhindrer Cross-Site Request Forgery i PHP-applikationer: tokens til hver forespørgsel, der ændrer noget, kontrol af oprindelsen i headeren og SameSite-cookies som ekstra lag.
- [Validér og filtrér input i PHP med filter_var](https://phpsos.de/da/blog/eingaben-validieren-php/): Hvordan udviklere kontrollerer input i PHP med filter_var, filter_input_array og tilladelseslister, hvilke filtre der er forældede, og hvorfor validering ikke erstatter prepared statements og outputkodning.
- [Forhindr command injection i PHP](https://phpsos.de/da/blog/command-injection-php/): Hvordan udviklere undgår command injection i PHP: erstat systemkommandoer med PHP-funktioner, brug proc_open uden shell, kontrollér argumenter og find farlige steder i eksisterende kode.
- [Forhindr Server-Side Request Forgery (SSRF) i PHP](https://phpsos.de/da/blog/ssrf-in-php/): Hvordan udviklere forhindrer, at en PHP-applikation på vegne af fremmede forespørger interne systemer: tilladelseslister, protokolbegrænsning, kontrol af den opløste adresse og grænser i netværket.
- [Forhindr XML External Entities (XXE) i PHP](https://phpsos.de/da/blog/xxe-in-php/): Hvordan udviklere behandler XML sikkert i PHP: libxml's standardadfærd, risikable indstillinger som LIBXML_NOENT, beskyttelse med entity-loader og LIBXML_NO_XXE og typiske skjulte XML-indgange.
- [Type juggling i PHP: Løse sammenligninger som sikkerhedsrisiko](https://phpsos.de/da/blog/type-juggling-php/): Hvorfor løse sammenligninger med == i PHP kan føre til sårbarheder, hvad der har ændret sig med PHP 8.0, og hvordan I skriver robuste sammenligninger i logins, tokens og rettigheder.
- [Sikre tilfældige tal og tokens i PHP med random_bytes](https://phpsos.de/da/blog/sichere-tokens-php/): Hvordan udviklere i PHP genererer tokens til adgangskodelinks, API-nøgler og engangskoder: kryptografisk sikre kilder, tilstrækkelig længde, lagring som hash og begrænset gyldighed.
- [Beskyt adgangsdata og .env-filer rigtigt](https://phpsos.de/da/blog/env-dateien-schuetzen/): Sådan beskytter I databaseadgangskoder, API-nøgler og andre hemmeligheder i PHP-projekter: .env-filer uden for webroot, spærring i webserveren, snævre rettigheder og ordnet udskiftning efter en hændelse.
- [Offentlig .git-mappe: Et undervurderet datalæk](https://phpsos.de/da/blog/git-ordner-oeffentlich/): Hvorfor et webroot, der er udrullet med Git, kan afsløre hele kildekoden inklusive historik, hvordan I kontrollerer det, spærrer med det samme og varigt opbygger deployment uden .git-mappe.
- [Backupfiler i webroot: .zip, .sql og .bak](https://phpsos.de/da/blog/backup-dateien-im-webroot/): Hvorfor database-dumps, arkiver og sikkerhedskopier i den offentlige mappe hører til de hyppigste datalæk, hvordan I finder og spærrer dem og afklarer, om de er blevet hentet.
- [phpinfo()-filer: Hvorfor de skal forsvinde](https://phpsos.de/da/blog/phpinfo-dateien-entfernen/): Efter PHP2Shell opretter mange administratorer hurtigt en info.php. Hvorfor sådanne filer er et datalæk, hvordan I finder dem, og hvilke kontrolveje der er bedre.
- [Hold afhængigheder opdaterede: Composer, npm og plugins](https://phpsos.de/da/blog/abhaengigkeiten-aktuell-halten/): Et projekt består af tre pakkeverdener: Composer, npm og CMS-plugins. Sådan holder I alle tre opdaterede med fast rytme, klart ansvar og tests.
- [Sikkerhedskodereview til PHP-projekter](https://phpsos.de/da/blog/sicherheits-code-review-php/): Hvordan teams målrettet gennemgår egen PHP-kode for sikkerhedssårbarheder: typer af reviews, kritiske funktioner, fornuftige værktøjer og en tjekliste.
- [Log sikkert: Registrér fejl uden datalæk](https://phpsos.de/da/blog/sicher-loggen-php/): Logge hjælper ved fejlsøgning og forensik, men bliver hurtigt selv et datalæk. Hvad PHP-applikationer bør logge, hvad aldrig, og hvordan man beskytter logge.
- [Sikr REST-API'er i PHP](https://phpsos.de/da/blog/rest-api-php-absichern/): Grænseflader er ofte dårligere beskyttet end websitet foran dem. De vigtigste regler for REST-API'er i PHP, fra objektrettigheder til hastighedsbegrænsning.
- [IT-leverandørkontrakter: Fastlæg sikkerhedspligter klart](https://phpsos.de/da/blog/dienstleistervertrag-sicherheit/): PHP2Shell har vist, hvor ofte det er uklart, hvem der skal patche. Hvilke sikkerhedspligter der hører hjemme i kontrakter med bureau, hostingudbyder og IT-leverandør.
- [Databehandling, når leverandører får adgang til servere](https://phpsos.de/da/blog/auftragsverarbeitung-serverzugriff/): Den, der lader eksterne komme til servere med kundedata, har som regel brug for en databehandleraftale. Hvad art. 28 GDPR kræver, og hvordan I organiserer adgange i en nødsituation i overensstemmelse med databeskyttelsen.
- [Sårbarhedshåndtering for mindre og mellemstore virksomheder](https://phpsos.de/da/blog/schwachstellenmanagement-mittelstand/): Ingen mellemstor virksomhed kan behandle hver eneste melding med det samme. Et slankt kredsløb af registrering, vurdering, beslutning og dokumentation sørger for, at det vigtigste sker først.
- [Vid, hvad der kører: oversigt over alle websites og servere](https://phpsos.de/da/blog/inventar-websites-server/): Ved PHP2Shell strandede mange ikke på rettelsen, men på spørgsmålet om, hvor PHP overhovedet kører. Sådan opbygger I en oversigt over alle websites og servere.
- [Patch management som proces i stedet for brandslukning](https://phpsos.de/da/blog/patch-management-prozess/): Den, der kun patcher, når det brænder, taber tid i en nødsituation. Sådan forbinder en patch management-proces med faste klasser, vinduer og dokumentation rutine og nødsituation.
- [Nødkontakter: Hvem skal informeres hvornår?](https://phpsos.de/da/blog/notfallkontakte-liste/): I en nødsituation tæller det, hvem man får fat i, og hvornår. Sådan opbygger I en liste over it-nødkontakter med udløsende hændelser, stedfortrædere og de oplysninger, som hvert opkald kræver.
- [Hvad en hacket server koster: Omkostningsposterne](https://phpsos.de/da/blog/kostenposten-eines-hacks/): En hacket webserver giver flere omkostninger end selve reparationen. Hvilke omkostningsposter der opstår, og hvordan I med egne tal begrunder et budget til forebyggelse.
- [Underret kunder efter en hændelse](https://phpsos.de/da/blog/kunden-nach-vorfall-informieren/): Pligt eller frivilligt: Sådan afgør I efter en hændelse, hvem I informerer, hvilke kanaler der er sikre, og hvordan jeres kundeservice er forberedt.
- [Leverandørkæden på nettet: Bureau, hostingudbyder, plugin-udbyder](https://phpsos.de/da/blog/lieferkette-agentur-hoster/): PHP2Shell har vist, hvor mange led der ligger mellem en patch og jeres website. Sådan kender, sikrer og opfanger I udfald af enkelte led i jeres websites leverandørkæde.
- [Sikkerhedsbevidsthed for administratorer og redaktører: Security awareness i webteamet](https://phpsos.de/da/blog/sicherheitsbewusstsein-redaktion/): Den, der vedligeholder websites, træffer dagligt sikkerhedsbeslutninger, ofte uden at lægge mærke til det. Sådan skoler I administratorer og redaktører rollebaseret og uden slideshow-maraton.
- [Nødøvelse ved bordet: Gennemspil en hændelse på webserveren](https://phpsos.de/da/blog/notfalluebung-am-tisch/): En øvelse ved bordet koster en eftermiddag og viser, om jeres nødplan holder. Her finder I en færdig drejebog til en hændelse på en PHP-webserver.
- [ISO 27001 og TISAX: Hvad der berører webservere](https://phpsos.de/da/blog/iso-27001-tisax-webserver/): Den, der driver et ISMS efter ISO 27001 eller har et TISAX-label, skal tænke webservere med. Her står, hvilke krav de berører, og hvilken dokumentation der tæller efter PHP2Shell.
- [VdS 10000: Informationssikkerhed for små og mellemstore virksomheder](https://phpsos.de/da/blog/vds-10000-kmu/): VdS 10000 er en slank ramme for informationssikkerhed i mellemstore virksomheder. Hvad den kræver, hvad der kom nyt i 2025, og hvad det betyder for websites og webservere.
- [Lessons learned: Bliv bedre efter hændelsen](https://phpsos.de/da/blog/lessons-learned-nach-vorfall/): Efter hændelsen er før den næste. En struktureret eftergennemgang uden skyldsfordeling gør en dårlig uge til målbar fremgang.
- [Patche, lukke ned eller vente? En beslutningshjælp ved PHP-sårbarheden](https://phpsos.de/da/blog/patchen-abschalten-abwarten/): Ved en kritisk PHP-sårbarhed skal de ansvarlige beslutte hurtigt. Denne hjælp ordner de tre muligheder, nævner kriterier og viser, hvornår det er forsvarligt at vente.
- [WAF eller opdatering: Hvorfor I har brug for begge dele](https://phpsos.de/da/blog/waf-oder-update/): En Web Application Firewall kan opfange angreb, men lukker ikke en sårbarhed i PHP-fortolkeren. Hvornår en WAF hjælper, hvor den ender, og hvordan I kombinerer begge fornuftigt.
- [Opsætte serveren på ny eller rydde op? Beslutningen efter et angreb](https://phpsos.de/da/blog/neu-aufsetzen-oder-bereinigen/): Efter et indbrud står to veje åbne: rydde serveren op eller bygge den op på ny. Hvilke kriterier der afgør det, og hvorfor rækkefølgen er vigtigere end valget.
- [Udbedre selv eller hente en leverandør? En ærlig afvejning](https://phpsos.de/da/blog/selbst-beheben-oder-dienstleister/): Ikke enhver sikkerhedssituation kræver ekstern hjælp. Med disse kriterier og en kort selvtest afgør I, om jeres team klarer PHP2Shell alene, eller om det har brug for støtte.
- [Vælg en it-sikkerhedsleverandør: 12 spørgsmål før opgaven](https://phpsos.de/da/blog/sicherheitsdienstleister-auswaehlen/): Under tidspres er det svært at finde en god sikkerhedsleverandør. Disse tolv spørgsmål hjælper med at sammenligne tilbud sagligt uden at falde for reklameløfter.
- [Managed hosting eller egen server? Sikkerhedssammenligningen](https://phpsos.de/da/blog/managed-oder-eigener-server/): PHP2Shell var en stresstest for enhver driftsmodel. Sammenligningen viser, hvornår managed hosting er sikrere, hvornår egen server er, og hvilke blandingsformer der har vist sig at fungere.
- [PHP-opgradering eller backport? Beslutningen for ældre systemer](https://phpsos.de/da/blog/php-upgrade-oder-backport/): For gamle PHP-versioner findes der efter PHP2Shell flere veje: distributionens backport, tredjepartskilde, kildekodepatch, langtidssupport eller opgradering. Hvad hver vej duer til, og hvor længe den holder.
- [Skifte CMS efter hacket? Hvornår det hjælper, og hvornår ikke](https://phpsos.de/da/blog/cms-wechsel-nach-hack/): Efter et indbrud er tilliden til CMS'et ofte væk. Men et nyt system løser sjældent den egentlige årsag. Hvornår skiftet er fornuftigt, og hvordan det lykkes rent.
- [Statiske websites: Mindre PHP, mindre angrebsflade](https://phpsos.de/da/blog/statische-website-alternative/): Et statisk website leverer færdige HTML-filer og kræver ikke PHP på serveren. Det mindsker angrebsfladen betydeligt, men har egne grænser og pligter.
- [Pentest, bug bounty eller sårbarhedsscanning? Vælg den rette kontrolmetode](https://phpsos.de/da/blog/pentest-bugbounty-scan/): Scanning, penetrationstest og bug bounty kontrollerer websites på vidt forskellige måder. Hvad hver metode kan, hvor den svigter, og hvilken rækkefølge der passer til jeres virksomhed.