Le 16 mai 2023, l’équipe principale de WordPress publié WordPress 6.2.1qui contient des correctifs pour 5 vulnérabilités, dont une vulnérabilité de traversée de répertoire de gravité moyenne, une vulnérabilité de script intersite de gravité moyenne et plusieurs vulnérabilités de gravité moindre.
Ces correctifs ont été rétroportés sur toutes les versions de WordPress depuis la 4.1. WordPress prend en charge les mises à jour automatiques du noyau pour les versions de sécurité depuis WordPress 3.7, et la grande majorité des sites WordPress devraient recevoir automatiquement un correctif pour leur version principale de WordPress au cours des prochaines 24 heures. Nous vous recommandons de vérifier que votre site a été automatiquement mis à jour vers l’une des versions corrigées. Des versions corrigées sont disponibles pour toutes les versions majeures de WordPress depuis la 4.1, vous pouvez donc mettre à jour sans risquer de problèmes de compatibilité.
Si votre site n’a pas été mis à jour automatiquement, nous vous recommandons fortement de le mettre à jour manuellement dès que possible, car l’une des vulnérabilités corrigées dans cette version peut être utilisée par un attaquant avec un compte de niveau contributeur à faibles privilèges pour prendre le contrôle d’un site.
Analyse de vulnérabilité
Comme pour chaque version principale de WordPress contenant des correctifs de sécurité, l’équipe de Wordfence Threat Intelligence a analysé les modifications de code en détail pour évaluer l’impact de ces vulnérabilités sur nos clients et s’assurer que nos clients restent protégés.
WordPress Core est vulnérable à Directory Traversal dans les versions jusqu’à 6.2 incluses, via le paramètre ‘wp_lang’. Cela permet à des attaquants non authentifiés d’accéder à des fichiers de traduction arbitraires et de les charger. Dans les cas où un attaquant est en mesure de télécharger un fichier de traduction spécialement conçu sur le site, par exemple via un formulaire de téléchargement, cela pourrait également être utilisé pour effectuer une attaque de type « Cross-Site Scripting ». Cette vulnérabilité ne serait pas facile à exploiter de manière percutante sur la plupart des configurations.
WordPress Core est vulnérable à Cross-Site Request Forgery en raison d’une validation nonce manquante sur la fonction AJAX ‘wp_ajax_set_attachment_thumbnail’ dans les versions jusqu’à 6.2 incluses. Cela permet aux utilisateurs non authentifiés de mettre à jour l’image miniature associée aux pièces jointes existantes, à condition qu’ils puissent inciter un utilisateur authentifié disposant des autorisations appropriées à effectuer une action, comme cliquer sur un lien. L’impact de cette vulnérabilité est incroyablement minime et nous ne nous attendons pas à voir une quelconque exploitation de cette faiblesse.
WordPress Core est vulnérable au Cross-Site Scripting stocké dans les versions jusqu’à la version 6.2 incluse, en raison d’une validation insuffisante du protocole dans la réponse lors du traitement de la découverte oEmbed. Cela permet aux attaquants authentifiés disposant d’autorisations de niveau contributeur et supérieur d’utiliser une charge utile oEmbed spécialement conçue sur une URL distante pour injecter des scripts Web arbitraires dans des pages qui s’exécuteront chaque fois qu’un utilisateur accédera à une page injectée.
WordPress Core ne parvient pas à nettoyer suffisamment les attributs de bloc dans les versions jusqu’à la 6.2 incluse. Cela permet aux attaquants authentifiés disposant d’autorisations de niveau contributeur et supérieur d’intégrer du contenu arbitraire dans les commentaires HTML de la page, bien que les scripts intersites puissent être possibles lorsqu’ils sont combinés à une vulnérabilité supplémentaire. Veuillez noter que cela n’affectera que les sites utilisant un thème compatible avec l’éditeur de blocs.
WordPress Core traite les shortcodes dans le contenu généré par l’utilisateur sur les thèmes de blocs dans les versions jusqu’à la 6.2 incluse. Cela pourrait permettre à des attaquants non authentifiés d’exécuter des codes abrégés en soumettant des commentaires ou d’autres contenus, leur permettant d’exploiter des vulnérabilités qui nécessitent généralement des autorisations au niveau de l’abonné ou du contributeur. Bien que cela soit susceptible d’avoir un impact minimal en soi, cela peut augmenter considérablement la gravité et l’exploitabilité d’autres vulnérabilités.
Conclusion
Dans l’article d’aujourd’hui, nous avons couvert cinq vulnérabilités corrigées dans le Version de sécurité et de maintenance de WordPress 6.2.1. Les sites WordPress les plus utilisés activement devraient être corrigés via des mises à jour automatiques dans les prochaines 24 heures.
La protection de traversée de répertoire intégrée du pare-feu Wordfence devrait bloquer les tentatives d’exploitation de la vulnérabilité de traversée de répertoire, et elle n’aurait généralement d’impact que lorsqu’elle est exploitée par un attaquant qualifié dans certaines configurations. La plupart des autres problèmes résolus aujourd’hui sont similaires en ce sens qu’ils nécessitent des configurations ou des circonstances spécifiques, telles que d’autres plugins vulnérables, pour être exploités avec impact.
Cependant, nous exhortons tous les propriétaires de sites à vérifier que WordPress est mis à jour dès que possible car il n’est pas pratique de déployer une règle de pare-feu qui protège contre le problème oEmbed et, à ce titre, tout site avec des utilisateurs de niveau contributeur non approuvés peut être à risque.
Comme toujours, nous vous recommandons fortement de mettre à jour votre site vers une version corrigée de WordPress s’il n’a pas été mis à jour automatiquement. Tant que vous utilisez une version de WordPress supérieure à 4.1, une mise à jour est disponible pour corriger ces vulnérabilités tout en vous gardant sur la même version majeure, vous n’aurez donc pas à vous soucier des problèmes de compatibilité.
Un merci spécial à Wordfence QA Lead Matt Rusnak pour avoir trouvé la vulnérabilité de traversée de répertoire que nous avons divulguée de manière responsable, et à John Blackbourn de l’équipe de sécurité WordPress, Jakub Żoczek de Securitum et Liam Glady de WP Engine pour avoir divulgué ces problèmes de manière responsable.
Source link