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, hvad der sker ved hukommelsesmangel inde i PHP, forklarer memory_limit og 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:
- Sæt
memory_limit=-1, helst så applikationer ikke kan overskrive værdien, f.eks. medphp_admin_valuei FPM-poolen eller i Apache-konfigurationen. - 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.
- Sæt en hukommelsesgrænse via container eller cgroup, som beskyttelse af tilgængeligheden, helst så kun den berørte worker afsluttes ved overskridelse.
- Brug ikke
RLIMIT_ASellerRLIMIT_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.
; FPM-pool, f.eks. /etc/php/8.3/fpm/pool.d/www.conf (kun indtil opdateringen)
php_admin_value[memory_limit] = -1
# 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. Uden denne ydre grænse kan en enkelt forespørgsel bringe hele serveren i hukommelsesnød.
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.
# 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_limitsæ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 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.