Superglobales : $_GET, $_POST, $_FILES et consorts

En bref : les superglobales sont des tableaux prédéfinis que PHP remplit automatiquement à chaque requête et qui sont disponibles partout dans le code. $_GET contient les paramètres de l'adresse, $_POST les données de formulaire, $_FILES les fichiers téléversés, $_COOKIE les cookies et $_SERVER des informations sur la requête et le serveur. PHP crée ces tableaux avant que le code de votre application ne démarre. C'est pourquoi des failles dans ce traitement précis, comme avec PHP2Shell, ne peuvent pas être interceptées par des vérifications dans l'application.

Que sont les superglobales ?

En PHP, une variable n'est normalement valable que dans la fonction où elle a été créée. Les superglobales sont l'exception : elles sont disponibles dans chaque portée, sans qu'il faille les récupérer avec global. Le manuel PHP en cite neuf.

Pour les non-techniciens, on peut le décrire ainsi : les superglobales sont la boîte aux lettres de l'application. Tout ce qu'un visiteur envoie y atterrit avant que l'application ne le lise. Et tout ce qui se trouve dans la boîte aux lettres provient potentiellement d'un inconnu.

Les superglobales en un coup d'œil

$_SERVER est particulièrement sournoise. Selon le manuel, PHP crée pour chaque en-tête de requête une entrée commençant par HTTP_, par exemple HTTP_USER_AGENT. Ces valeurs sont définies par le client lui-même. SERVER_NAME peut, selon le manuel, contenir le nom d'hôte fourni par le client et n'est pas fiable pour des décisions de sécurité.

Comment PHP remplit les superglobales

Avant que le premier caractère de votre script ne soit exécuté, PHP a déjà travaillé. Il lit l'adresse, les en-têtes et le contenu de la requête, les décompose et place les résultats dans les tableaux. Plusieurs réglages pilotent cette étape :

1. variables_order (par défaut EGPCS) détermine quelles superglobales sont créées : Environment, GET, POST, Cookie, Server.
2. request_order (par défaut vide) détermine à partir de quoi $_REQUEST est constitué. S'il est vide, variables_order s'applique. Selon le manuel, les fichiers php.ini fournis omettent les cookies pour des raisons de sécurité.
3. max_input_vars (par défaut 1000) et max_input_nesting_level (par défaut 64) limitent le nombre et l'imbrication des variables d'entrée.
4. post_max_size (par défaut 8M) limite le contenu de la requête. Si une requête est plus grande, $_POST et $_FILES restent vides.
5. enable_post_data_reading (par défaut activé) détermine si PHP analyse automatiquement le contenu des requêtes POST.

Si enable_post_data_reading est désactivé, l'application lit elle-même le contenu brut via php://input. Depuis PHP 8.4.0, il existe en outre request_parse_body(), qui analyse les données de formulaire et de téléversement aussi pour d'autres méthodes que POST et permet des limites propres. Le déroulement détaillé de la partie téléversement est expliqué sur la page Comment PHP traite les téléversements de fichiers.

Traiter les données de requête en sécurité

Le principe est simple : toute valeur de $_GET, $_POST, $_COOKIE, $_FILES et des entrées HTTP_ de $_SERVER est une entrée étrangère. Elle est vérifiée à la réception et échappée de manière adaptée à la sortie.

<?php
declare(strict_types=1);

// Entier attendu : vérifier plutôt que convertir à l'aveugle
$seite = filter_var($_GET['seite'] ?? '1', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 500],
]);
if ($seite === false) {
    http_response_code(400);
    exit('Ungültige Seitenzahl');
}

// N'autoriser que les valeurs permises
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Toujours échapper la sortie
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

Un piège fréquent concerne les indications sur l'origine d'une requête. Si un reverse proxy, un répartiteur de charge ou un CDN se trouve devant le serveur web, $_SERVER['REMOTE_ADDR'] contient l'adresse de cet intermédiaire, non celle du visiteur. L'adresse réelle figure alors dans un en-tête comme X-Forwarded-For, que chaque client peut toutefois définir lui-même. L'application ne doit exploiter de tels en-têtes que si la requête provient manifestement d'un proxy connu et sous votre contrôle. Sinon, les blocages par adresse IP ou les journaux sont facilement trompés. Il en va de même pour HTTPS : si le chiffrement prend fin au proxy, l'application doit savoir expressément que la connexion d'origine était chiffrée.

D'autres modèles de validation et de filtrage figurent dans l'article Valider et filtrer les entrées en PHP. Pour les données de session dans $_SESSION, des règles propres s'appliquent ; elles figurent sur la page Sessions et cookies en PHP.

Superglobales et PHP2Shell : ce qui se passe avant votre code

Voici le lien avec la situation actuelle. CVE-2026-109618 décrit qu'un état de mémoire insuffisante (out of memory) peut interrompre PHP alors que les données de la requête ne sont que partiellement initialisées ; lors du nettoyage de la requête, des données invalides peuvent alors être traitées comme valides. Avec CVE-2026-109619, l'état interne d'une requête peut subsister après la libération de la mémoire et être utilisé par une requête ultérieure dans le même worker.

Les deux failles se situent donc dans le traitement que PHP effectue lui-même autour de la requête, non dans le code de l'application. L'équipe PHP évalue le risque comme le plus élevé avec mod_php ; un exploit y a été démontré avant même que le code de l'application ne s'exécute. Aucun filter_var() ni aucune vérification dans l'application ne peut l'empêcher.

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

• Nous vérifions les limites effectives pour les données de requête de chaque site web et les définissons en fonction de l'application.
• Nous installons la mise à jour de PHP, redémarrons tous les workers et prouvons le niveau de correctifs dans le cadre de notre service de correctifs PHP.
• Nous examinons les développements sur mesure pour voir si des valeurs issues de superglobales parviennent sans vérification dans la base de données, le système de fichiers ou la sortie.
• Nous sécurisons les journaux du serveur web à partir du 20/10/2026, afin qu'une analyse ultérieure reste possible.

Questions fréquentes

Sources

• Manuel PHP : superglobales
• Manuel PHP : $_SERVER
• Manuel PHP : directives php.ini
• Manuel PHP : request_parse_body