Comment PHP traite les uploads de fichiers

En bref : lorsqu'un navigateur téléverse un fichier, il envoie une requête POST au format multipart/form-data, dans laquelle les champs du formulaire et le contenu des fichiers se suivent sous forme de parties distinctes. PHP décompose lui-même cette requête, écrit chaque partie de fichier dans un fichier temporaire du upload_tmp_dir, consigne les informations dans $_FILES et ne démarre votre script qu'ensuite. Le script déplace le fichier avec move_uploaded_file() ; tout ce qui n'est pas déplacé est supprimé par PHP à la fin de la requête.

Le trajet d'un fichier, du navigateur jusqu'au script

Pour les décideurs, un point est essentiel : un upload n'est pas une opération qui concerne la seule application. Une grande partie du travail s'effectue dans l'interpréteur PHP, avant même que le code du CMS ou de la boutique n'intervienne. C'est pourquoi les failles de cette partie de PHP touchent chaque site web, qu'il dispose ou non d'un formulaire d'upload.

Le déroulement en un coup d'œil :

1. Le formulaire avec method="POST" et enctype="multipart/form-data" est envoyé.
2. Le serveur web accepte la requête et la transmet à PHP, selon le mode de fonctionnement via PHP-FPM, mod_php ou une autre interface.
3. PHP vérifie les limites telles que post_max_size et découpe le contenu à l'aide d'une chaîne de séparation, appelée boundary.
4. Les champs normaux se retrouvent dans $_POST ; les parties de fichiers sont écrites dans des fichiers temporaires et décrites dans $_FILES.
5. Ce n'est qu'à ce moment que le script démarre, contrôle le fichier et le déplace vers sa destination.
6. À la fin de la requête, PHP supprime tous les fichiers temporaires qui n'ont pas été déplacés.

multipart/form-data : la structure d'une requête d'upload

Une requête d'upload est du texte brut contenant des données de fichier intégrées. L'en-tête Content-Type indique la boundary, et dans le contenu, cette chaîne sépare les différentes parties. Chaque partie possède ses propres en-têtes avec le nom du champ et, le cas échéant, le nom du fichier. Un exemple inoffensif, fortement abrégé :

POST /bewerbung HTTP/1.1
Content-Type: multipart/form-data; boundary=----trenner42

------trenner42
Content-Disposition: form-data; name="vorname"

Erika
------trenner42
Content-Disposition: form-data; name="lebenslauf"; filename="lebenslauf.pdf"
Content-Type: application/pdf

%PDF-1.7 ... Dateiinhalt ...
------trenner42--

Toutes les informations de ce texte proviennent de l'expéditeur, y compris le nom du fichier et le Content-Type de la partie. PHP les reprend dans $_FILES, mais n'en vérifie pas la vraisemblance.

Le tableau $_FILES

Pour un champ nommé lebenslauf, $_FILES['lebenslauf'] contient, selon le manuel PHP, les clés suivantes :

Pour les champs dont le nom contient des crochets, par exemple bilder[], chaque clé contient un tableau avec une entrée par fichier. L'application parcourt alors, par exemple, $_FILES['bilder']['error'] et accède à tmp_name et name par le même index.

Un formulaire peut en outre envoyer un champ caché MAX_FILE_SIZE avant le champ de fichier. Selon le manuel, il ne s'agit que d'une indication pour le navigateur, facile à contourner. Vous ne pouvez compter que sur les limites imposées par le serveur : dans PHP, dans le serveur web et dans l'application elle-même.

Limites : les directives php.ini pour les uploads

Ces directives pilotent le traitement des uploads. Les valeurs par défaut proviennent du manuel PHP et s'appliquent lorsqu'aucun php.ini ne les remplace.

post_max_size doit être supérieur à upload_max_filesize, et memory_limit devrait en règle générale, selon le manuel, être supérieur à post_max_size. Si upload_tmp_dir n'est pas accessible en écriture, PHP se rabat sur le répertoire temporaire du système. Avec open_basedir, le répertoire temporaire doit être autorisé, sinon les uploads échouent. Les valeurs pratiques et leurs conséquences sont décrites dans l'article Limiter judicieusement post_max_size et upload_max_filesize.

Évaluer correctement les codes d'erreur

Le champ error indique ce qui s'est passé pendant le traitement. Les constantes vont de UPLOAD_ERR_OK (0) à UPLOAD_ERR_EXTENSION (8), en passant par UPLOAD_ERR_INI_SIZE (1), UPLOAD_ERR_FORM_SIZE (2), UPLOAD_ERR_PARTIAL (3), UPLOAD_ERR_NO_FILE (4), UPLOAD_ERR_NO_TMP_DIR (6) et UPLOAD_ERR_CANT_WRITE (7).

<?php
declare(strict_types=1);

$datei = $_FILES['lebenslauf'] ?? null;
if ($datei === null) {
    exit('Keine Upload-Daten, eventuell wurde post_max_size überschritten.');   // Aucune donnée d'upload, post_max_size a peut-être été dépassé.
}

$meldung = match ($datei['error']) {
    UPLOAD_ERR_OK => null,
    UPLOAD_ERR_INI_SIZE, UPLOAD_ERR_FORM_SIZE => 'Datei zu groß.',
    UPLOAD_ERR_NO_FILE => 'Keine Datei gewählt.',
    default => 'Upload fehlgeschlagen.',
};

if ($meldung === null && is_uploaded_file($datei['tmp_name'])) {
    $ziel = '/srv/app/uploads/' . bin2hex(random_bytes(16)) . '.pdf';
    move_uploaded_file($datei['tmp_name'], $ziel);
}

L'exemple ne montre que la mécanique. Le contrôle du type de fichier, le stockage en dehors de la racine web et le blocage de l'exécution de scripts sont décrits dans le guide Mettre en œuvre les uploads de fichiers PHP en toute sécurité.

Uploads et PHP2Shell : ce que signifient les mesures transitoires

Les failles PHP2Shell CVE-2026-109618 et CVE-2026-109619 concernent le traitement des requêtes dans l'interpréteur PHP. C'est pourquoi php.net cite, parmi les mesures transitoires, notamment post_max_size = 8M (sans uploads) ou 32M (avec uploads), upload_max_filesize en dessous, ainsi que session.upload_progress.enabled=0. Ces valeurs relèvent du php.ini, du pool FPM ou de la configuration du serveur ; tous les workers doivent ensuite redémarrer.

Des auteurs spécialisés proposent en outre de bloquer au niveau du proxy ou du WAF les requêtes multipart/form-data en dehors des véritables chemins d'upload. Il s'agit d'une mesure non officielle, avec le risque de casser des formulaires ; l'article Filtrer les requêtes d'upload en périphérie décrit les compromis. Aucune de ces mesures ne remplace la mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

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

• Nous déterminons lesquels de vos sites ont réellement besoin d'uploads, et sur quels chemins.
• Nous définissons les limites et les mesures transitoires pool par pool, redémarrons tous les workers et testons les formulaires.
• Nous recherchons des fichiers exécutables dans les répertoires d'upload et bloquons l'exécution de scripts dans le cadre du durcissement de serveur.
• Nous installons la mise à jour de PHP et documentons le niveau de correctifs de chaque site.

Questions fréquentes

Sources

• Manuel PHP : envois de fichiers par POST
• Manuel PHP : messages d'erreur lors des uploads
• Manuel PHP : directives php.ini
• php.net : avis de sécurité