# Sæt memory_limit rigtigt

> Sæt PHP memory_limit rigtigt: Hvad værdien gør, hvor den gælder, hvad php.net midlertidigt råder til ved PHP2Shell, og hvad der skal gælde efter opdateringen.

Kilde: https://phpsos.de/da/blog/memory-limit-richtig-setzen/  
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:** `memory_limit` fastlægger, hvor meget hukommelse en enkelt PHP-forespørgsel må optage; standarden er 128M. I normal drift sætter I en endelig værdi, der passer til applikationen, og låser den med `php_admin_value`. Så længe PHP2Shell ikke er patchet, råder php.net midlertidigt til `memory_limit=-1`, ikke-overskrivelig og kombineret med en grænse via container eller cgroup, ikke via `RLIMIT_AS` eller `RLIMIT_DATA`. Efter opdateringen gælder der igen en endelig værdi.

## En rutineindstilling, der pludselig er et sikkerhedsemne

I årevis var `memory_limit` en justeringsskrue for udviklere. Melder et website "Allowed memory size exhausted", hæves værdien, og problemet er klaret. Med PHP2Shell er det blevet et sikkerhedsspørgsmål, og php.nets anbefaling virker ved første øjekast paradoksal: I overgangen skal PHP's egen hukommelsesgrænse helt bortfalde.

Baggrunden er CVE-2026-109618. Ifølge PHP-projektet kan en out-of-memory-tilstand afbryde PHP, mens forespørgselsdata kun er delvist initialiseret. Oprydningen af forespørgslen kan så behandle ugyldige data som gyldige. Tekniske enkeltheder står under [CVE-2026-109618](https://phpsos.de/da/php2shell/cve-2026-109618/), hvad der sker ved hukommelsesmangel inde i PHP, forklarer [memory_limit og out-of-memory](https://phpsos.de/da/php/out-of-memory/). For driftsansvarlige tæller spørgsmålet: Hvilken værdi gælder hvornår, og hvor skal den stå?

## Hvad memory_limit udretter i normal drift

Ifølge PHP-manualen begrænser `memory_limit` den hukommelse, et script må optage, og beskytter dermed serveren mod dårligt skrevet kode. Standarden er `128M`, `-1` betyder ingen grænse. Kortskrivemåder som `256M` eller `1G` er tilladt.

To egenskaber er vigtige for sikkerheden. For det første kan værdien ændres overalt, også under kørslen med `ini_set()`. Mange CMS og shops hæver den selv, f.eks. til importer eller billedbehandling. Den, der vil gennemtvinge en værdi, skal sætte den med `php_admin_value`; ifølge manualen kan værdier sat på den måde ikke overskrives med `ini_set()`. For det andet anbefaler manualen, at `memory_limit` er større end `post_max_size`.

Hvilken værdi der passer, afhænger af applikationen. Et blik i fejllogget viser, om der optræder meldinger om opbrugt hukommelse, og ved hvilke kald. Det har vist sig at fungere at fastlægge værdien pr. website i dets egen FPM-pool: rundhåndet for en shop med importer, knappere for en enkel virksomhedsside. En generelt meget høj værdi for alle websites giver beskyttelsen væk, fordi en enkelt fejlbehæftet eller misbrugt forespørgsel så kan binde meget hukommelse.

Siden PHP 8.5 findes desuden `max_memory_limit`. Denne indstilling kan kun sættes ved start og begrænser, hvor højt `memory_limit` overhovedet må sættes. Højere værdier afkortes med en advarsel. Standarden `-1` betyder ingen øvre grænse.

## memory_limit efter PHP2Shell: php.nets overgangsforanstaltning

For servere, der endnu ikke er opdateret til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en bekræftet backport, nævner php.net i sikkerhedsmeddelelsen af 21.10.2026 følgende skridt. De mindsker risikoen ved enkelte angrebsveje, men gør ifølge php.net ikke en installation sikker:

1. **Sæt `memory_limit=-1`,** helst så applikationer ikke kan overskrive værdien, f.eks. med `php_admin_value` i FPM-poolen eller i Apache-konfigurationen.
2. **Kontrollér, at der ingen steder sættes en endelig grænse igen,** hverken i en anden pool eller i en mappekonfiguration eller i applikationen.
3. **Sæt en hukommelsesgrænse via container eller cgroup,** som beskyttelse af tilgængeligheden, helst så kun den berørte worker afsluttes ved overskridelse.
4. **Brug ikke `RLIMIT_AS` eller `RLIMIT_DATA`.** Disse grænser kan ifølge php.net netop udløse den sårbare fejl ved hukommelsesanmodning.

php.net forklarer hertil, at `-1` fjerner muligheden for målrettet at udløse, at PHP's hukommelsesgrænse nås, men at en hukommelsesfejl på et dybere niveau fortsat kan nå den sårbare sti. Oversigten over alle overgangsforanstaltninger står under [Akutforanstaltninger, hvis I endnu ikke kan patche](https://phpsos.de/da/php2shell/sofortmassnahmen-ohne-patch/).

```ini
; FPM-pool, f.eks. /etc/php/8.3/fpm/pool.d/www.conf (kun indtil opdateringen)
php_admin_value[memory_limit] = -1
```

```bash
# Hvor memory_limit overalt sættes (kun læsende)
grep -rn 'memory_limit' /etc/php/ /etc/apache2/ 2>/dev/null
grep -rn --include='*.php' -E "ini_set\s*\(\s*['\"]memory_limit" /var/www | head -20
grep -rn --include='.user.ini' 'memory_limit' /var/www
```

Hvordan I sætter cgroup-grænsen for FPM-tjenesten, beskriver [Sæt hukommelsesgrænser med systemd og cgroups](https://phpsos.de/da/blog/speichergrenzen-systemd-cgroups/). Uden denne ydre grænse kan en enkelt forespørgsel bringe hele serveren i hukommelsesnød.

> **Vigtigt:**
> Genstart alle PHP-workers efter hver ændring. En kørende worker beholder sine gamle værdier.

## Hvad der gælder efter opdateringen

Med de rettede versioner har også `memory_limit`'s adfærd ifølge PHP-manualen ændret sig. Fra 8.5.12, 8.4.27, 8.3.36 og 8.2.35 er den en blød grænse: En hukommelsesanmodning, der overskrider den, må i de fleste tilfælde stadig gennemføres, før fejlen udløses. En ny indstilling, `memory_hard_limit_percent`, fastlægger en hård grænse, der aldrig overskrides.

| Indstilling | Værdi | Virkning ifølge manualen |
|---|---|---|
| `memory_hard_limit_percent` ikke sat eller `-1` | standard | hård grænse dobbelt så høj som `memory_limit` til 1G, derover `memory_limit` plus 1G |
| `memory_hard_limit_percent = 150` | eksempel | ved `memory_limit=128M` hård grænse 192M |
| `memory_limit = -1` | ingen grænse | så findes der heller ingen hård grænse |

Manualen nævner et praktisk kontrolpunkt: Genkendes `memory_hard_limit_percent` ikke, er den anvendte PHP-version berørt og skal opdateres. Ved distributionernes backports kontrollerer I desuden tilstanden via pakkens changelog.

```bash
# Kender FPM-binærfilen den nye indstilling? (tilpas versionsnummeret)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
```

Efter opdateringen har `memory_limit=-1` opfyldt sit formål. Vend tilbage til en endelig værdi, der passer til applikationen, og lås den med `php_admin_value`. Cgroup-grænsen kan blive stående som et ekstra beskyttelseslag.

## Hvordan hjælper PHP SOS konkret?

- Vi finder ud af, hvor `memory_limit` sættes og overskrives på jeres server, inklusive i applikationerne.
- Vi gennemfører php.nets overgangsforanstaltninger det rigtige sted og supplerer med en cgroup-grænse for FPM-tjenesten.
- Via [PHP-patch-servicen](https://phpsos.de/da/leistungen/php-patch-service/) bringer vi PHP op på en rettet version og genstarter alle workers.
- Derefter sætter vi igen en passende endelig værdi og dokumenterer indstillingerne.


## Ofte stillede spørgsmål

**Hvad er standardværdien for memory_limit?**  
Ifølge PHP-manualen 128M. Værdien begrænser, hvor meget hukommelse et enkelt script må optage. Den kan ændres i php.ini, i serverkonfigurationen, i FPM-poolen og under kørslen med ini_set(), medmindre den er låst med php_admin_value.

**Hvorfor råder php.net ved PHP2Shell til memory_limit=-1?**  
Én af sårbarhederne, CVE-2026-109618, hænger sammen med tilstanden ved hukommelsesmangel. Ifølge php.net fjerner memory_limit=-1 muligheden for målrettet at udløse, at PHP's hukommelsesgrænse nås, men ikke enhver hukommelsesfejl. Foranstaltningen er ingen fuldstændig beskyttelse og skal kombineres med en hukommelsesgrænse via container eller cgroup.

**Må jeg i stedet sætte grænsen med ulimit?**  
Nej. php.net fraråder udtrykkeligt at bruge RLIMIT_AS eller RLIMIT_DATA som erstatning, fordi disse grænser netop kan udløse den sårbare fejl ved hukommelsesanmodning. Anbefalet er en grænse via container eller cgroup.

**Hvad gælder efter opdateringen til en rettet PHP-version?**  
Ifølge manualen er memory_limit i de rettede versioner en blød grænse, suppleret af en hård grænse via memory_hard_limit_percent. Overgangsforanstaltningen med -1 har så opfyldt sit formål, og en endelig værdi, der passer til applikationen, bør gælde igen.

## Kilder

- [php.net: Sikkerhedsmeddelelse af 21.10.2026](https://www.php.net/)
- [PHP-manual: Kerneindstillinger (memory_limit)](https://www.php.net/manual/en/ini.core.php)
- [PHP-manual: FPM-konfiguration](https://www.php.net/manual/en/install.fpm.configuration.php)