# Bien régler memory_limit

> Bien régler le memory_limit de PHP : portée de la valeur, conseil transitoire de php.net pour PHP2Shell et réglage à retrouver après la mise à jour.

Source : https://phpsos.de/fr/blog/memory-limit-richtig-setzen/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** `memory_limit` détermine la quantité de mémoire qu'une seule requête PHP peut occuper ; la valeur par défaut est 128M. En exploitation normale, vous définissez une valeur finie adaptée à l'application et vous la verrouillez avec `php_admin_value`. Tant que PHP2Shell n'est pas corrigé, php.net conseille temporairement `memory_limit=-1`, non écrasable et combiné avec une limite au niveau du conteneur ou de cgroup, et non via `RLIMIT_AS` ou `RLIMIT_DATA`. Après la mise à jour, une valeur finie s'applique de nouveau.

## Un réglage de routine devenu soudain un sujet de sécurité

Pendant des années, `memory_limit` a été un bouton de réglage pour les développeurs. Quand un site signale « Allowed memory size exhausted », on augmente la valeur et le problème est réglé. Avec PHP2Shell, c'est devenu une question de sécurité, et la recommandation de php.net paraît paradoxale à première vue : pour la période transitoire, la limite mémoire propre à PHP doit disparaître complètement.

L'arrière-plan est CVE-2026-109618. Selon le projet PHP, un état de mémoire insuffisante peut interrompre PHP alors que les données de la requête ne sont qu'en partie initialisées. Le nettoyage de la requête peut alors traiter des données invalides comme valides. Les détails techniques figurent sous [CVE-2026-109618](https://phpsos.de/fr/php2shell/cve-2026-109618/), et ce qui se passe à l'intérieur de PHP en cas de manque de mémoire est expliqué dans [memory_limit et Out-of-Memory](https://phpsos.de/fr/php/out-of-memory/). Pour les exploitants, la question qui compte est : quelle valeur s'applique quand, et où doit-elle figurer ?

## Ce que fait memory_limit en exploitation normale

Selon le manuel PHP, `memory_limit` limite la mémoire qu'un script peut occuper et protège ainsi le serveur contre du code mal écrit. La valeur par défaut est `128M`, `-1` signifie aucune limite. Les notations abrégées comme `256M` ou `1G` sont autorisées.

Deux propriétés sont importantes pour la sécurité. Premièrement, la valeur peut être modifiée partout, y compris à l'exécution avec `ini_set()`. De nombreux CMS et boutiques l'augmentent eux-mêmes, par exemple pour des imports ou le traitement d'images. Pour imposer une valeur, il faut la définir avec `php_admin_value` ; selon le manuel, les valeurs ainsi définies ne peuvent pas être écrasées par `ini_set()`. Deuxièmement, le manuel recommande que `memory_limit` soit supérieur à `post_max_size`.

La valeur adaptée dépend de l'application. Un coup d'œil au journal d'erreurs montre si des messages de mémoire épuisée apparaissent et pour quels appels. Il est recommandé de définir la valeur site par site dans le pool FPM dédié : plus généreuse pour une boutique avec des imports, plus serrée pour un simple site d'entreprise. Une valeur très élevée appliquée à tous les sites sans distinction gaspille l'effet protecteur, car une seule requête défectueuse ou détournée peut alors mobiliser beaucoup de mémoire.

Depuis PHP 8.5, il existe en outre `max_memory_limit`. Ce paramètre ne peut être défini qu'au démarrage et limite la valeur maximale à laquelle `memory_limit` peut être fixé. Les valeurs plus élevées sont plafonnées avec un avertissement. La valeur par défaut `-1` signifie aucune limite supérieure.

## memory_limit après PHP2Shell : la mesure transitoire de php.net

Pour les serveurs qui ne sont pas encore mis à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ni vers un backport confirmé, php.net indique les étapes suivantes dans son avis de sécurité du 21 octobre 2026. Elles réduisent le risque de certaines voies d'attaque, mais selon php.net ne rendent pas une installation sûre :

1. **Définir `memory_limit=-1`,** si possible de façon à ce que les applications ne puissent pas écraser la valeur, par exemple avec `php_admin_value` dans le pool FPM ou dans la configuration d'Apache.
2. **Vérifier qu'une limite finie n'est redéfinie nulle part,** ni dans un autre pool, ni dans une configuration de répertoire, ni dans l'application.
3. **Définir une limite mémoire au niveau du conteneur ou de cgroup,** pour protéger la disponibilité, si possible de façon à ce que seul le worker concerné soit arrêté en cas de dépassement.
4. **Ne pas utiliser `RLIMIT_AS` ni `RLIMIT_DATA`.** Selon php.net, ces limites peuvent provoquer précisément l'erreur vulnérable lors de l'allocation de mémoire.

php.net explique à ce sujet que `-1` supprime l'atteinte de la limite mémoire de PHP, qui peut être provoquée de façon ciblée, mais qu'une erreur de mémoire à un niveau plus bas peut toujours atteindre le chemin vulnérable. L'aperçu de toutes les mesures transitoires figure dans [Mesures immédiates si vous ne pouvez pas encore appliquer le correctif](https://phpsos.de/fr/php2shell/sofortmassnahmen-ohne-patch/).

```ini
; Pool FPM, par ex. /etc/php/8.3/fpm/pool.d/www.conf (jusqu'à la mise à jour seulement)
php_admin_value[memory_limit] = -1
```

```bash
# Où memory_limit est défini (lecture seule)
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
```

La façon de définir la limite cgroup pour le service FPM est décrite dans [Définir des limites de mémoire avec systemd et cgroups](https://phpsos.de/fr/blog/speichergrenzen-systemd-cgroups/). Sans cette limite externe, une seule requête peut mettre tout le serveur en manque de mémoire.

> **Important:**
> Après chaque modification, redémarrer tous les workers PHP. Un worker en cours d'exécution conserve ses anciennes valeurs.

## Ce qui vaut après la mise à jour

Avec les versions corrigées, selon le manuel PHP, le comportement de `memory_limit` a également changé. À partir de 8.5.12, 8.4.27, 8.3.36 et 8.2.35, c'est une limite souple : une demande de mémoire qui la dépasse peut, dans la plupart des cas, encore aboutir avant que l'erreur ne soit déclenchée. Un nouveau paramètre, `memory_hard_limit_percent`, définit une limite stricte qui n'est jamais dépassée.

| Paramètre | Valeur | Effet selon le manuel |
|---|---|---|
| `memory_hard_limit_percent` non défini ou `-1` | par défaut | limite stricte égale au double de `memory_limit` jusqu'à 1G, au-delà `memory_limit` plus 1G |
| `memory_hard_limit_percent = 150` | exemple | avec `memory_limit=128M`, limite stricte de 192M |
| `memory_limit = -1` | aucune limite | il n'y a alors pas non plus de limite stricte |

Le manuel indique un point de contrôle pratique : si `memory_hard_limit_percent` n'est pas reconnu, la version de PHP utilisée est concernée et doit être mise à jour. Pour les backports des distributions, vérifiez en plus l'état via le journal des modifications du paquet.

```bash
# Le binaire FPM connaît-il le nouveau paramètre ? (adapter le numéro de version)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
```

Après la mise à jour, `memory_limit=-1` a rempli son rôle. Revenez à une valeur finie adaptée à l'application et verrouillez-la avec `php_admin_value`. La limite cgroup peut rester comme couche de protection supplémentaire.

## Comment PHP SOS aide-t-il concrètement ?

- Nous déterminons où `memory_limit` est défini et écrasé sur votre serveur, y compris par les applications.
- Nous mettons en œuvre les mesures transitoires de php.net au bon endroit et ajoutons une limite cgroup pour le service FPM.
- Avec le [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous amenons PHP à une version corrigée et redémarrons tous les workers.
- Ensuite, nous redéfinissons une valeur finie adaptée et documentons les paramètres.


## Questions fréquentes

**Quelle est la valeur par défaut de memory_limit ?**  
Selon le manuel PHP, 128M. La valeur limite la mémoire qu'un script individuel peut occuper. Elle peut être modifiée dans php.ini, dans la configuration du serveur, dans le pool FPM et à l'exécution avec ini_set(), tant qu'elle n'est pas verrouillée avec php_admin_value.

**Pourquoi php.net conseille-t-il memory_limit=-1 pour PHP2Shell ?**  
L'une des failles, CVE-2026-109618, est liée à l'état de manque de mémoire. Selon php.net, memory_limit=-1 supprime l'atteinte de la limite mémoire de PHP, qui peut être provoquée de façon ciblée, mais pas toutes les erreurs de mémoire. La mesure n'est pas une protection complète et doit être combinée avec une limite mémoire au niveau du conteneur ou de cgroup.

**Puis-je fixer la limite avec ulimit à la place ?**  
Non. php.net déconseille expressément d'utiliser RLIMIT_AS ou RLIMIT_DATA en remplacement, car ces limites peuvent provoquer précisément l'erreur vulnérable lors de l'allocation de mémoire. Une limite au niveau du conteneur ou de cgroup est recommandée.

**Que vaut-il après la mise à jour vers une version corrigée de PHP ?**  
Selon le manuel, dans les versions corrigées, memory_limit est une limite souple, complétée par une limite stricte via memory_hard_limit_percent. La mesure transitoire avec -1 a alors rempli son rôle, et une valeur finie, adaptée à l'application, devrait de nouveau s'appliquer.

## Sources

- [php.net : avis de sécurité du 21 octobre 2026](https://www.php.net/)
- [Manuel PHP : directives du noyau (memory_limit)](https://www.php.net/manual/en/ini.core.php)
- [Manuel PHP : configuration de FPM](https://www.php.net/manual/en/install.fpm.configuration.php)