# Farlige falske tips om PHP2Shell, der cirkulerer lige nu

> PHP2Shell-tips faktatjekket: Hvilke cirkulerende råd der ikke beskytter eller endda skader, og hvad php.net, BSI og fagforfattere anbefaler i stedet.

Kilde: https://phpsos.de/da/blog/gefaehrliche-falschtipps/  
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

**Kort sagt:** Mange PHP2Shell-tips, der lige nu cirkulerer i fora og på sociale netværk, beskytter ikke eller skader endda: blokere forespørgsler med session-cookie, skjule fejlmeddelelser, indstille værdier via `.user.ini` eller kun opdatere CMS'et. php.net er entydig: Der findes ingen fuldstændige midlertidige foranstaltninger, PHP-opdateringen med genstart af alle processer er den eneste sikre vej.

## Hvorfor falske tips er farlige i denne situation

Ved en kritisk sårbarhed med stor opmærksomhed opstår et marked for hurtige løsninger. Råd deles, forkortes og gives videre, ofte uden den oprindelige kildes forbehold. Ved PHP2Shell kommer det til, at detaljer ifølge rapporter blev kendt før det officielle tidspunkt, og at situationen var uoverskuelig de første dage.

Et falsk tip skader dobbelt. Det lader sårbarheden stå åben og skaber følelsen af at have gjort noget. Netop denne følelse medfører, at den egentlige opdatering bliver liggende. Nogle råd lammer desuden ens eget website.

## Ni råd faktatjekket

Tabellen nedenfor opsummerer, hvad vi i de seneste dage ofte har læst, og stiller de primære kilders udsagn op imod det.

| Cirkulerende tip | Hvorfor det ikke holder | Hvad der gælder i stedet |
|---|---|---|
| Blokere alle forespørgsler med `PHPSESSID` | Udtrykkeligt afvist af fagforfattere; lammer logins og indkøbskurve | Opdatér PHP |
| `session.upload_progress.enabled=0` er nok | Lukker ifølge faglige rapporter ikke begge sårbarheder | Fornuftig midlertidig foranstaltning, opdatering er fortsat en pligt |
| Indstille værdier via `ini_set()` eller `.user.ini` | php.net fraråder det udtrykkeligt | På serversiden i php.ini, FPM-pool eller serverkonfiguration |
| Skjule fejlmeddelelser | Ifølge php.net hjælper `error_reporting`, `display_errors` eller `@` ikke | Opdatering; vis alligevel ikke fejludskrift offentligt |
| Begrænse hukommelse via `RLIMIT_AS` eller `RLIMIT_DATA` | php.net advarer om, at netop det kan udløse den sårbare situation | Grænse via container eller cgroup |
| Opdatere WordPress eller plugins | Sårbarheden ligger i PHP-fortolkeren, ikke i CMS'et | Opdatér PHP-kørselsmiljøet |
| Cloudflare eller en anden WAF er nok | Beskyttelse kun for trafik via tjenesten; direkte tilgængelige servere forbliver åbne | WAF som ekstra lag, ikke som erstatning |
| Genindlæse tjenesten i stedet for at genstarte | Ifølge Red Hat er en genindlæsning ikke nok, eksisterende workers kan beholde den gamle tilstand | Genstart alle workers fuldstændigt |
| Patchet betyder ren | En patch fjerner ikke skadelig software, der er smuglet ind tidligere | Sikr logs fra 20.10., og undersøg for spor |

## De tre hyppigste fejlslutninger nærmere forklaret

### Cookie-forbuddet

Tippet om at afvise alle forespørgsler med session-cookien `PHPSESSID` lyder teknisk og beslutsomt. Fagforfattere afviser det udtrykkeligt. I praksis ødelægger det alt, der kræver en session: kundekonti, indkøbskurve, administrationsområder, formularer med beskyttelse mod forfalskning. En beskyttelse mod sårbarheden er det ikke.

### Den ene indstilling, der løser alt

`session.upload_progress.enabled=0` står i php.net's anbefalinger og er den nævnte afhjælpning mod CVE-2026-115560. Heraf blev der i nogle indlæg „PHP2Shell slået fra“. Ifølge faglige rapporter lukker denne indstilling alene dog ikke begge sårbarheder. Også `memory_limit=-1` fjerner ifølge php.net kun den styrbare udløser; en hukommelsesfejl på et dybere niveau kan fortsat nå den sårbare sti. På PHP 8.5 blokerer `fatal_error_backtraces=0` ifølge php.net kun den bekræftede vej via backtraces.

Hvordan I alligevel indstiller den korrekt og varigt, beskriver indlægget [Slå session.upload_progress fra](https://phpsos.de/da/blog/session-upload-progress-abschalten/). Den fuldstændige liste over midlertidige foranstaltninger står under [Akutte foranstaltninger uden patch](https://phpsos.de/da/php2shell/sofortmassnahmen-ohne-patch/).

### Skjoldet foran

Cloudflare har efter egne oplysninger siden den 21. oktober haft beskyttelsesregler aktive, også for kunder i den gratis plan. Cloudflare selv peger dog på grænser: Beskyttelsen virker kun for trafik, der løber via Cloudflare. Er oprindelsesserveren direkte tilgængelig, omgås den. Desuden kontrollerer Cloudflare yderligere serverens svar, fordi forespørgslen alene ikke altid er nok. Hvorfor en WAF ikke erstatter opdateringen, forklarer indlægget [WAF eller opdatering](https://phpsos.de/da/blog/waf-oder-update/).

## Et tip med risiko: Filtrere upload-forespørgsler i kanten

Ikke ethvert ubekvemt råd er forkert. Fagforfattere foreslår som en midlertidig, uofficiel foranstaltning at blokere `multipart/form-data`-forespørgsler uden for ægte upload-stier ved proxyen eller i WAF'en. Det kan gøre angrebsfladen mindre, men ødelægger formularer og uploads, hvis listen over tilladte stier er ufuldstændig.

Den, der går denne vej, bør afprøve den på forhånd i et testmiljø, afstemme den med fagafdelingerne og dokumentere den som en tidsbegrænset foranstaltning. En erstatning for opdateringen er heller ikke den.

Mange WAF-løsninger tilbyder hertil en observationstilstand, hvor regler først blot logger i stedet for at blokere. Lad en ny regel køre sådan i nogle dage, og vurdér, hvilke legitime forespørgsler der ville være berørt. Først derefter skifter I til blokering. Sådan undgår I, at ansøgningsformularer, kundeportaler eller billedupload i shoppen ubemærket falder ud.

## Sådan kontrollerer I et tip, før I gennemfører det

Fire spørgsmål adskiller brugbare fra farlige råd:

1. **Kilde:** Stammer anbefalingen fra php.net, jeres distribution, BSI (det tyske forbundsagentur for informationssikkerhed) eller en fagforfatter, der er nævnt ved navn?
2. **Krav:** Beskrives foranstaltningen som en overgang eller som en løsning? Ved PHP2Shell er kun opdateringen en løsning.
3. **Bivirkning:** Hvad går i stykker, når foranstaltningen virker? Et tip uden henvisning til bivirkninger er ufuldstændigt.
4. **Sted for gennemførelse:** Indstilles værdien på serversiden og så den ikke kan overskrives, efterfulgt af en genstart af alle workers?

> **Vigtigt:**
> Notér, hvilke midlertidige foranstaltninger I har indsat hvornår. Så kan I senere kontrollere dem målrettet og se, om en tilsyneladende beskyttelse har forsinket den egentlige opdatering.

## Hvordan hjælper PHP SOS konkret?

- Vi kontrollerer de foranstaltninger, der allerede er gennemført hos jer, og adskiller virksomme fra virkningsløse.
- Vi indspiller PHP-opdateringen, genstarter alle processer og dokumenterer status.
- Hvor en opdatering endnu ikke er mulig, indsætter vi midlertidige foranstaltninger efter php.net på serversiden og dokumenteret.
- Med [WAF og virtuel patching](https://phpsos.de/da/leistungen/waf-virtuelles-patching/) supplerer vi beskyttelsen i kanten uden at erstatte opdateringen.


## Ofte stillede spørgsmål

**Beskytter det at blokere forespørgsler med PHPSESSID?**  
Nej. Fagforfattere afviser udtrykkeligt dette cirkulerende tip. Det lammer logins, indkøbskurve og formularer uden at lukke sårbarheden i fortolkeren.

**Er session.upload_progress.enabled=0 nok mod PHP2Shell?**  
Nej. Indstillingen er en af flere midlertidige foranstaltninger og lukker ifølge faglige rapporter ikke begge sårbarheder. Den er fornuftig, men erstatter ikke PHP-opdateringen.

**Hjælper det at slå display_errors fra?**  
Ikke ved PHP2Shell. php.net gør opmærksom på, at det ikke hjælper at skjule diagnoser via error_reporting, display_errors eller @-operatoren. I produktion bør display_errors alligevel være slået fra af andre grunde.

**Hvordan genkender jeg et seriøst tip?**  
Et seriøst tip nævner sin kilde, beskriver grænser og betegner midlertidige foranstaltninger som sådanne. Den, der lover, at en enkelt indstilling gør opdateringen overflødig, tager fejl ved PHP2Shell.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell og PHP-versioner](https://www.drweb.de/php2shell-update-php-versionen/)
- [Cloudflare-blog](https://blog.cloudflare.com/)