Lyhyesti: memory_limit määrää, kuinka paljon muistia yksittäinen PHP-pyyntö saa varata; oletus on 128M. Normaalikäytössä asetatte sovellukseen sopivan äärellisen arvon ja lukitsette sen komennolla php_admin_value. Niin kauan kuin PHP2Shell on korjaamatta, php.net suosittelee tilapäisesti arvoa memory_limit=-1, ylikirjoittamattomana ja yhdistettynä kontin tai cgroupin kautta asetettuun rajaan, ei RLIMIT_AS- tai RLIMIT_DATA-rajojen kautta. Päivityksen jälkeen voimassa on taas äärellinen arvo.
Rutiiniasetus, josta tulee yhtäkkiä tietoturva-asia
Vuosien ajan memory_limit oli kehittäjien säätöruuvi. Kun verkkosivusto ilmoittaa ”Allowed memory size exhausted”, arvoa nostetaan ja ongelma on ratkaistu. PHP2Shellin myötä siitä on tullut tietoturvakysymys, ja php.net:n suositus vaikuttaa ensi silmäyksellä paradoksaaliselta: siirtymäajaksi PHP:n oma muistiraja jätetään kokonaan pois.
Tausta on CVE-2026-109618. PHP-projektin mukaan muistin loppuminen voi keskeyttää PHP:n, kun pyynnön tiedot on alustettu vain osittain. Pyynnön siivous voi silloin käsitellä virheellisiä tietoja kelvollisina. Tekniset yksityiskohdat ovat kohdassa CVE-2026-109618, ja mitä PHP:n sisällä tapahtuu muistin loppuessa, selittää memory_limit ja Out-of-Memory. Ylläpitäjälle tärkeä kysymys on: mikä arvo on voimassa milloin, ja missä sen pitää olla?
Mitä memory_limit tekee normaalikäytössä
PHP-käsikirjan mukaan memory_limit rajaa muistin, jonka skripti saa varata, ja suojaa siten palvelinta huonosti kirjoitetulta koodilta. Oletus on 128M, -1 tarkoittaa ei rajaa. Lyhennysmuodot kuten 256M tai 1G ovat sallittuja.
Kaksi ominaisuutta on tietoturvan kannalta tärkeitä. Ensinnäkin arvoa voi muuttaa kaikkialla, myös suoritusaikana funktiolla ini_set(). Monet CMS:t ja verkkokaupat nostavat sitä itse, esimerkiksi tuonteja tai kuvankäsittelyä varten. Joka haluaa pakottaa arvon, asettaa sen komennolla php_admin_value; käsikirjan mukaan näin asetettuja arvoja ei voi ylikirjoittaa funktiolla ini_set(). Toiseksi käsikirja suosittelee, että memory_limit on suurempi kuin post_max_size.
Mikä arvo sopii, riippuu sovelluksesta. Katse virhelokiin näyttää, esiintyykö muistin loppumista koskevia ilmoituksia ja millä kutsuilla. Käytännössä on osoittautunut hyväksi asettaa arvo sivustokohtaisesti omassa FPM-poolissa: antelias verkkokaupalle tuonteineen, niukempi yksinkertaiselle yrityssivulle. Kaikille sivustoille yleisesti erittäin korkea arvo hukkaa suojavaikutuksen, koska yksittäinen virheellinen tai väärinkäytetty pyyntö voi silloin sitoa paljon muistia.
PHP 8.5:stä lähtien on lisäksi max_memory_limit. Tämä asetus voidaan asettaa vain käynnistyksessä, ja se rajaa, kuinka korkeaksi memory_limit ylipäätään saadaan asettaa. Korkeammat arvot typistetään varoituksella. Oletus -1 tarkoittaa ei ylärajaa.
memory_limit PHP2Shellin jälkeen: php.net:n siirtymäajan toimenpide
Palvelimille, joita ei ole vielä päivitetty versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai vahvistettuun backportiin, php.net nimeää 21.10.2026 päivätyssä tietoturvailmoituksessa seuraavat vaiheet. Ne pienentävät yksittäisten hyökkäysreittien riskiä, mutta php.net:n mukaan eivät tee asennuksesta turvallista:
- Asettakaa
memory_limit=-1, mieluiten niin, etteivät sovellukset voi ylikirjoittaa arvoa, esimerkiksi komennollaphp_admin_valueFPM-poolissa tai Apachen asetuksissa. - Tarkistakaa, ettei äärellistä rajaa aseteta missään uudelleen, ei toisessa poolissa, ei hakemistokohtaisissa asetuksissa eikä sovelluksessa.
- Asettakaa muistiraja kontin tai cgroupin kautta, saatavuuden suojaksi, mieluiten niin, että ylityksessä päättyy vain vaikutuksen alainen worker.
- Älkää käyttäkö
RLIMIT_AS- taiRLIMIT_DATA-rajoja. Nämä rajat voivat php.net:n mukaan laukaista juuri haavoittuvan virheen muistinvarauksessa.
php.net selittää tähän, että -1 poistaa PHP:n muistirajan tahallisen laukaisemisen mahdollisuuden, mutta syvemmän tason muistivirhe voi silti saavuttaa haavoittuvan polun. Kaikkien siirtymäajan toimenpiteiden yleiskatsaus on kohdassa Pikatoimet, jos ette voi vielä päivittää.
; FPM-pooli, esim. /etc/php/8.3/fpm/pool.d/www.conf (vain päivitykseen asti)
php_admin_value[memory_limit] = -1
# Missä kaikkialla memory_limit asetetaan (vain lukien)
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
Miten cgroup-raja asetetaan FPM-palvelulle, kuvaa Muistirajojen asettaminen systemd:llä ja cgroupeilla. Ilman tätä ulkoista rajaa yksittäinen pyyntö voi ajaa koko palvelimen muistipulaan.
Käynnistäkää kaikki PHP-workerit uudelleen jokaisen muutoksen jälkeen. Käynnissä oleva worker säilyttää vanhat arvonsa.
Mikä on voimassa päivityksen jälkeen
Korjattujen versioiden mukana myös memory_limit-asetuksen käyttäytyminen on PHP-käsikirjan mukaan muuttunut. Versioista 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 alkaen se on pehmeä raja: rajan ylittävä muistinvaraus saa useimmissa tapauksissa vielä valmistua, ennen kuin virhe laukeaa. Uusi asetus, memory_hard_limit_percent, määrittää kovan rajan, jota ei koskaan ylitetä.
| Asetus | Arvo | Vaikutus käsikirjan mukaan |
|---|---|---|
memory_hard_limit_percent asettamatta tai -1 |
oletus | kova raja kaksi kertaa memory_limit, 1G:hen asti, sen yli memory_limit plus 1G |
memory_hard_limit_percent = 150 |
esimerkki | kun memory_limit=128M, kova raja 192M |
memory_limit = -1 |
ei rajaa | silloin ei myöskään ole kovaa rajaa |
Käsikirja mainitsee käytännöllisen tarkistuskohdan: jos memory_hard_limit_percent ei tunnisteta, käytetty PHP-versio on vaikutuksen alainen ja se on päivitettävä. Jakelujen backporttien kohdalla tarkistakaa tila lisäksi pakettien muutoslokista.
# Tunteeko FPM-binääri uuden asetuksen? (mukauttakaa versionumero)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
Päivityksen jälkeen memory_limit=-1 on täyttänyt tarkoituksensa. Palatkaa sovellukseen sopivaan äärelliseen arvoon ja lukitkaa se komennolla php_admin_value. Cgroup-raja voi jäädä lisäsuojakerrokseksi.
Miten PHP SOS auttaa konkreettisesti?
- Selvitämme, missä palvelimellanne
memory_limitasetetaan ja ylikirjoitetaan, sovellukset mukaan lukien. - Toteutamme php.net:n siirtymäajan toimenpiteet oikeassa kohdassa ja täydennämme FPM-palvelun cgroup-rajalla.
- PHP-päivityspalvelun kautta nostamme PHP:n korjattuun versioon ja käynnistämme kaikki workerit uudelleen.
- Sen jälkeen asetamme jälleen sopivan äärellisen arvon ja dokumentoimme asetukset.
Usein kysytyt kysymykset
Mikä on memory_limitin oletusarvo?
PHP-käsikirjan mukaan 128M. Arvo rajaa, kuinka paljon muistia yksittäinen skripti saa varata. Sitä voi muuttaa tiedostossa php.ini, palvelinasetuksissa, FPM-poolissa ja suoritusaikana funktiolla ini_set(), ellei sitä ole lukittu komennolla php_admin_value.
Miksi php.net suosittelee PHP2Shellin yhteydessä asetusta memory_limit=-1?
Yksi aukoista, CVE-2026-109618, liittyy tilaan muistin loppuessa. php.net:n mukaan memory_limit=-1 poistaa PHP:n muistirajan tahallisen laukaisemisen mahdollisuuden, mutta ei jokaista muistivirhettä. Toimenpide ei ole täydellinen suoja, ja se on yhdistettävä kontin tai cgroupin kautta asetettuun muistirajaan.
Saanko asettaa rajan sen sijaan ulimitillä?
Ei. php.net neuvoo nimenomaisesti olemaan käyttämättä RLIMIT_AS- tai RLIMIT_DATA-rajoja korvikkeena, koska nämä rajat voivat laukaista juuri haavoittuvan virheen muistinvarauksessa. Suositus on raja kontin tai cgroupin kautta.
Mikä on voimassa päivityksen jälkeen korjattuun PHP-versioon?
Käsikirjan mukaan memory_limit on korjatuissa versioissa pehmeä raja, jota täydentää kova raja asetuksella memory_hard_limit_percent. Siirtymäajan toimenpide arvolla -1 on silloin täyttänyt tarkoituksensa, ja sovellukseen sopivan äärellisen arvon pitäisi olla taas voimassa.