Thèmes vulnérables

Faille Ocean Extra sans compte : le correctif 2.6.1 précédait l’alerte

Ocean Extra : faille sans compte, patch en 2.6.1

Wordfence a rendu publique le 14 octobre 2026 une faille d’Ocean Extra, l’extension compagnon du thème OceanWP : jusqu’à la version 2.6.0, un visiteur sans compte pouvait faire exécuter des shortcodes arbitraires (CVE-2026-86803). Le correctif, la version 2.6.1, est disponible depuis le 10 septembre, plus d’un mois avant l’annonce. Si vous gérez un site OceanWP, voici comment vérifier votre version, juger votre exposition réelle et contrôler qu’il n’y a pas eu d’abus.

Ce qui s’est passé

La faille a été découverte le 28 juin 2026 par un chercheur qui signe hashiramasenju333, selon la chronologie de la fiche CVE publiée par Wordfence, autorité de numérotation (CNA) pour cette CVE. Wordfence a prévenu OceanWP le 8 septembre à 14 h 56 (heure de Paris). Deux jours plus tard, le 10 septembre à 11 h 35, la version 2.6.1 d’Ocean Extra était publiée sur wordpress.org avec une seule ligne dans son journal, « Potential vulnerability patched », qui renvoie à un rapport de Wordfence du 8 septembre.

Rien de plus n’a filtré pendant cinq semaines. Le 14 octobre à 18 h 43, Wordfence a publié sa fiche, intitulée « Ocean Extra <= 2.6.0 - Unauthenticated Arbitrary Shortcode Execution via 'oceanwp_library' Shortcode Template ». Patchstack et WPScan l’ont référencée le même jour, et la fiche CVE puis la base NVD du NIST ont suivi le 15 octobre au matin. Le même jour, l’enrichissement publié par la CISA (programme Vulnrichment) indiquait une exploitation « none » mais une attaque « automatable », c’est-à-dire automatisable à grande échelle.

Frise chronologique 2026 : 28 juin, découverte de la faille par hashiramasenju333 ; 8 septembre à 14 h 56, Wordfence prévient OceanWP ; 10 septembre à 11 h 35, publication d’Ocean Extra 2.6.1 avec la mention « Potential vulnerability patched » ; 13 octobre, Ocean Extra 2.6.3 ; 14 octobre à 18 h 43, publication par Wordfence, sans compte, CVSS 6,5 ; 15 octobre à 7 h 30, fiche CVE et NVD en ligne, exploitation « none » selon la CISA.
Déroulé de CVE-2026-86803, heures de Paris. La version corrigée existait 34 jours avant la publication de la faille.

Au 19 octobre, aucune source reconnue ne documente d’attaque : ni Wordfence, ni Patchstack, ni WPScan, ni le catalogue KEV de la CISA. Le site allemand Dr. Web, qui a couvert la faille le 15 octobre, ne signalait pas non plus d’attaque connue.

Pourquoi un correctif antérieur à l’annonce change la donne

Ce décalage de 34 jours est volontaire : les chercheurs laissent aux utilisateurs le temps de mettre à jour avant de publier les détails. Il a trois conséquences pratiques.

  • Les sites dont les mises à jour automatiques d’extensions étaient activées sont protégés depuis le 10 ou le 11 septembre, sans avoir rien eu à faire.
  • Pendant ces cinq semaines, la mention « Potential vulnerability patched » ne disait ni la gravité ni l’absence d’authentification : un administrateur qui trie ses mises à jour à la main n’avait aucune raison de se presser. Les bases de vulnérabilités, et donc les outils d’alerte qui s’en nourrissent, ne connaissaient pas encore la faille.
  • Depuis le 14 octobre, la situation est inversée : la fiche publique et le correctif, consultable sur le dépôt Subversion de wordpress.org, indiquent précisément où chercher. Les sites restés en 2.6.0 ou avant sont désormais les cibles évidentes.

Qui est concerné

Ocean Extra est l’extension gratuite qui ajoute au thème OceanWP la bibliothèque de modèles « My Library », des réglages par page, des widgets, l’import de démos et plusieurs shortcodes. Elle compte plus de 400 000 installations actives (wordpress.org). Toutes les versions jusqu’à 2.6.0 incluse sont touchées ; la 2.6.1 corrige la faille. La version la plus récente au 19 octobre est la 2.6.3, publiée le 13 octobre.

ÉlémentCVE-2026-86803
ExtensionOcean Extra (wordpress.org, slug ocean-extra)
Versions touchéesjusqu’à 2.6.0 incluse
Corrigée en2.6.1 (10 septembre 2026) ; dernière version 2.6.3
Compte requisAucun
TypeExécution de shortcodes arbitraires (CWE-94, injection de code)
CVSS 3.16,5, moyenne (Wordfence, repris par NVD et WPScan) ; 5,3 selon Patchstack
ExploitationAucune documentée au 19 octobre 2026
Découvertehashiramasenju333, via Wordfence
Fiche d’identité de la faille (sources : fiche CVE, NVD, Patchstack, WPScan, journal d’Ocean Extra).

Les étiquettes divergent. Patchstack classe la faille en « exécution de code arbitraire » tout en lui donnant une priorité faible, et certains agrégateurs parlent d’exécution de code à distance. La description de Wordfence est plus précise : ce sont des shortcodes, pas du code PHP choisi par l’attaquant, qui sont exécutés. La gravité réelle dépend donc des shortcodes installés sur votre site.

Toutes les installations ne sont pas exposées de la même façon. D’après le correctif, seul le cas d’un modèle « My Library » créé avec l’éditeur de blocs est en cause ; les modèles conçus avec Elementor, Beaver Builder ou SiteOrigin passent par un autre chemin du code. Mettez à jour dans tous les cas.

Un point de vigilance pour la suite : WPScan et Wordfence listent aussi, depuis le 23 septembre, une XSS stockée exploitable par un contributeur et corrigée en 2.6.2, alors que Patchstack a retiré le 1er octobre l’identifiant CVE qu’il lui avait attribué (CVE-2026-94684), en la qualifiant de faux positif. Viser la 2.6.3 règle la question.

Comment fonctionnait la faille

Un shortcode est un code entre crochets, comme , que WordPress remplace par du contenu. C’est un outil d’administrateur : WordPress n’interprète pas les shortcodes écrits par les visiteurs, par exemple dans un commentaire. Ocean Extra fournit le shortcode [oceanwp_library id="…"], qui affiche un modèle de la bibliothèque « My Library » (en-tête, pied de page, bloc réutilisé).

Wordfence décrit la cause en une phrase : une action « ne valide pas correctement une valeur avant d’appeler do_shortcode ». Le correctif publié sur le dépôt de wordpress.org est plus parlant. Jusqu’en 2.6.0, pour un modèle créé avec l’éditeur de blocs, Ocean Extra calculait d’abord les blocs (fonction do_blocks), puis passait tout le résultat dans do_shortcode. Or certains blocs sont dynamiques : leur contenu est produit à l’affichage et peut contenir du texte venu de l’extérieur. Le commentaire ajouté dans le correctif cite les commentaires en exemple. Un visiteur qui glissait un shortcode dans un tel texte le voyait interprété au second passage, avec les droits du site.

Schéma en quatre étapes : 1, le shortcode oceanwp_library affiche un modèle de My Library ; 2, do_blocks calcule les blocs dynamiques, dont le rendu peut contenir un texte de visiteur comme un commentaire ; 3, do_shortcode passe sur le résultat et interprète un shortcode glissé dans ce texte ; correctif 2.6.1, les shortcodes sont traités avant les blocs, seul le contenu enregistré du modèle passe par do_shortcode.
Mécanisme de CVE-2026-86803, d’après le correctif de la version 2.6.1 (notre lecture du code ; Wordfence n’a pas publié de scénario détaillé).

La version 2.6.1 inverse l’ordre : les shortcodes du modèle enregistré sont traités d’abord, puis les blocs sont rendus, et le résultat n’est plus repassé dans do_shortcode. Ce qu’un attaquant peut obtenir dépend des shortcodes disponibles : afficher un contenu qui ne devrait pas l’être, déclencher une fonction d’une autre extension, injecter du contenu dans la page. C’est ce qui explique la note CVSS : impact faible sur la confidentialité et l’intégrité, aucun sur la disponibilité, mais aucune authentification ni interaction requise.

C’est la deuxième exécution de shortcodes sans compte dans Ocean Extra, après CVE-2025-3472 (version 2.4.6, avril 2025, qui exigeait WooCommerce actif), et la deuxième faille autour du shortcode oceanwp_library après une XSS par contributeur en août 2025 (CVE-2025-9499). Retrouvez l’historique complet des failles d’OceanWP et d’Ocean Extra.

Indicateurs et vérifications sur votre site

Aucun avis publié ne donne d’indicateur de compromission (adresse IP, fichier, utilisateur ou requête type). Les contrôles ci-dessous servent à mesurer votre exposition et à repérer des traces plausibles ; ils ne remplacent pas un diagnostic complet. Commencez par la version installée :

wp plugin list --name=ocean-extra --fields=name,version,status,update
wp plugin verify-checksums ocean-extra

Ensuite, listez les modèles de la bibliothèque et les shortcodes enregistrés sur le site, pour savoir ce qu’un attaquant aurait pu appeler :

wp post list --post_type=oceanwp_library --fields=ID,post_title,post_status,post_modified
wp eval 'echo implode( "\n", array_keys( $GLOBALS["shortcode_tags"] ) );'

Puis cherchez les commentaires récents contenant un crochet ouvrant, signe possible d’une tentative (adaptez le préfixe wp_ de vos tables) :

wp db query "SELECT comment_ID, comment_date, comment_author_IP, comment_approved, LEFT(comment_content, 120) FROM wp_comments WHERE comment_content LIKE '%[%' AND comment_date > '2026-06-01' ORDER BY comment_date DESC"

Enfin, les contrôles d’usage en cas de doute :

  • wp user list --role=administrator --fields=ID,user_login,user_email,user_registered : aucun administrateur inconnu ;
  • wp core verify-checksums : fichiers du cœur intacts ;
  • find wp-content -name "*.php" -mtime -45 : fichiers PHP modifiés depuis début septembre, à justifier un par un ;
  • dans les journaux du serveur, des requêtes répétées vers les pages qui affichent un modèle « My Library », ou des envois de commentaires en rafale depuis une même adresse.

Que faire maintenant

  • Mettez Ocean Extra à jour en 2.6.3, la dernière version au 19 octobre (au minimum 2.6.1), depuis Tableau de bord → Mises à jour ou avec wp plugin update ocean-extra.
  • Si l’extension est installée mais inutilisée, désactivez-la puis supprimez-la : ses fichiers restent attaquables tant qu’ils sont sur le serveur.
  • Si vous ne pouvez pas mettre à jour tout de suite, retirez temporairement de l’affichage les modèles « My Library » créés avec l’éditeur de blocs qui contiennent des blocs dynamiques, et mettez les nouveaux commentaires en modération.
  • Si les vérifications révèlent un abus (administrateur inconnu, fichier PHP suspect), changez les mots de passe des administrateurs, renouvelez les clés de sécurité de wp-config.php, révoquez les mots de passe d’application, puis restaurez une sauvegarde saine. Le guide de nettoyage d’un site WordPress piraté détaille les étapes.

Réduire l’exposition la prochaine fois

Cette affaire illustre un cas fréquent : le correctif existe avant que quiconque sache qu’il est urgent. La meilleure défense est donc d’appliquer les mises à jour de sécurité sans attendre l’annonce. Les mises à jour automatiques des extensions auraient protégé ces sites dès septembre. Pour les sites où vous préférez valider chaque mise à jour, une surveillance des vulnérabilités prend le relais au moment de la publication, et une vue d’ensemble des mises à jour en attente évite qu’un site oublié reste des semaines en retard. Limitez aussi les rôles et les comptes au strict nécessaire (principe du moindre privilège), gardez des sauvegardes testées, et envisagez un pare-feu applicatif avec correctifs virtuels pour couvrir l’intervalle entre annonce et mise à jour.

WP Masquerade Pro peut aider sur une partie de ce travail, sans le remplacer. Ses alertes de vulnérabilités comparent chaque jour les versions installées des extensions et thèmes de wordpress.org, dont Ocean Extra, avec la base publique WPVulnerability.net, et préviennent par e-mail. Elles n’auraient rien signalé avant le 14 octobre : tant qu’une faille n’est pas publiée, aucune base ne la connaît. Le journal d’activité des administrateurs fait apparaître un compte créé ou une extension installée de façon inattendue, à partir de son activation et seulement pour ce qui passe par WordPress, et le contrôle d’intégrité ne vérifie que les fichiers du cœur, pas ceux d’Ocean Extra. Les mises à jour en attente et les sites vulnérables de tous vos sites remontent dans votre espace membre. L’extension alerte : elle ne corrige rien et n’est pas un pare-feu.

À retenir

  • CVE-2026-86803 : exécution de shortcodes sans compte dans Ocean Extra jusqu’à 2.6.0, CVSS 6,5 selon Wordfence.
  • Corrigée en 2.6.1 le 10 septembre 2026, rendue publique le 14 octobre : les sites mis à jour automatiquement étaient déjà protégés.
  • Seuls les modèles « My Library » créés avec l’éditeur de blocs sont en cause, d’après le correctif.
  • Aucune exploitation documentée au 19 octobre ; mettez à jour en 2.6.3 et vérifiez administrateurs et fichiers récents.

Sources

  • CVE.org : CVE-2026-86803, Ocean Extra 2.6.0 et versions antérieures (15 octobre 2026) (lien externe, nouvel onglet)
  • WordPress.org Plugin Trac : changeset 3689650, ocean-extra/includes/panel/library-shortcode.php (10 septembre 2026) (lien externe, nouvel onglet)
  • CVE.org : CVE-2026-94684, identifiant rejeté par Patchstack (1er octobre 2026) (lien externe, nouvel onglet)
  • NVD : CVE-2025-3472, Ocean Extra 2.4.6 et versions antérieures (22 avril 2025) (lien externe, nouvel onglet)

Autres sources consultées : autres fiches CVE, pages officielles des éditeurs, articles de la presse spécialisée, bases Wordfence, WPScan et Patchstack.

Thèmes vulnérables8 min

Faille Blocksy Companion : vendeur Dokan sans compte, patch 2.1.59

Une faille de Blocksy Companion permet à un visiteur sans compte de devenir vendeur Dokan et d’être connecté automatiquement. Seules les boutiques Dokan sont exposées ; la…

La sécurité WordPress, sans le bruit

Un e-mail quand ça compte : nouvelles attaques observées, mises à jour de l’extension et guides pratiques. Pas de spam, désinscription en un clic.

Commencez gratuitement, passez à Pro quand vous êtes prêt

La version gratuite masque déjà WordPress et déplace la page de connexion. Pro ajoute alias, double authentification et surveillance.