> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Backdoor ARVE (CVE-2026-18072) : quand la faille, c'est la chaîne d'approvisionnement

> Une extension WordPress à 20 000 installations a livré une porte dérobée administrateur. Ce qui s'est passé, comment vérifier vos sites, ce que ça change.

*Publié le 8 août 2026*

<Warning>
  **CVE-2026-18072, CVSS 9.8.** La version 10.8.7 de l'extension Advanced Responsive Video Embedder contient une porte dérobée délibérée. Il n'existe pas de version corrigée : WordPress.org a retiré l'extension. Si vous l'avez installée, supprimez-la.
</Warning>

## Ce n'est pas un bug

Tous les autres avis que nous publions décrivent une erreur : un contrôle oublié, une hypothèse fausse, un décalage d'indice. Celui-ci décrit une intention.

Le 28 juillet 2026, la version 10.8.7 de l'extension Advanced Responsive Video Embedder — environ 20 000 installations actives — a été publiée avec une fonction nommée `_arve_uc_init()`, accrochée à l'action `init` de WordPress en priorité 1, donc exécutée avant presque tout le reste.

La fonction lit un jeton dans le paramètre de requête `_wplogin` ou `_wpm` et le compare à une empreinte SHA-256 codée en dur dans le source de l'extension. En cas de correspondance, la requête est authentifiée comme n'importe quel compte administrateur existant désigné par l'attaquant. Aucune vérification de nonce. Aucun contrôle de capacité. Aucun mot de passe.

Une empreinte inscrite dans un code source que tout le monde peut télécharger n'est pas un secret. C'est un identifiant universel, valable sur tous les sites qui exécutent cette version. La classification le dit sans ambiguïté : CWE-506, code malveillant embarqué.

## Ce qui a limité la casse

Deux éléments ont évité la catastrophe.

**La détection a pris moins de deux heures.** L'analyse automatisée de Wordfence a signalé le code malveillant le 28 juillet, moins de deux heures après sa publication. Le dépôt de l'extension a été fermé au téléchargement le jour même.

**Les mises à jour automatiques ne l'avaient pas encore propagé.** L'équipe WordPress.org a confirmé que la version malveillante n'avait pas été largement distribuée par mise à jour automatique avant le retrait. La grande majorité de ces 20 000 sites n'a jamais reçu la 10.8.7.

L'ironie mérite d'être relevée : la mise à jour automatique, le mécanisme qui vous protège d'ordinaire, est précisément le canal qu'emprunte une compromission de la chaîne d'approvisionnement. Ici, c'est sa lenteur qui a limité les dégâts.

## Mesurer votre exposition

| Situation                                        | Exposition                     | Action                                                                          |
| ------------------------------------------------ | ------------------------------ | ------------------------------------------------------------------------------- |
| Extension jamais installée                       | Nulle                          | Rien à faire                                                                    |
| Extension installée, version inférieure à 10.8.7 | Nulle pour cette porte dérobée | La retirer ou la remplacer — l'extension n'est plus maintenue sur WordPress.org |
| Extension installée en **10.8.7**                | **Critique**                   | Présumer la compromission : supprimer, auditer, renouveler les secrets          |
| Extension installée, version inconnue            | Inconnue                       | Vérifier maintenant, traiter comme une 10.8.7 jusqu'à preuve du contraire       |

## Vérifier vos sites

Déterminez si l'extension est présente, et dans quelle version :

```bash theme={null}
# Depuis la racine du site, avec WP-CLI
wp plugin get advanced-responsive-video-embedder --field=version

# Sur plusieurs sites, depuis le répertoire qui les contient
for d in /var/www/*/; do
  printf "%s " "$d"
  wp --path="$d" plugin get advanced-responsive-video-embedder --field=version 2>/dev/null || echo "absente"
done
```

Sans WP-CLI, la version figure dans l'en-tête de l'extension :

```bash theme={null}
grep -i "^ \* Version:" wp-content/plugins/advanced-responsive-video-embedder/*.php
```

Si la version est 10.8.7, cherchez la porte dérobée elle-même avant de supprimer quoi que ce soit — mieux vaut savoir à quoi vous avez affaire :

```bash theme={null}
# La fonction de la porte dérobée et ses noms de paramètres
grep -rn "_arve_uc_init\|_wplogin\|_wpm" wp-content/plugins/advanced-responsive-video-embedder/
```

Puis contrôlez vos journaux d'accès pour voir qui s'en est servi :

```bash theme={null}
# Requêtes portant les paramètres de la porte dérobée
grep -E "_wplogin=|_wpm=" /var/log/nginx/access.log | head -50
```

Une occurrence ici n'est pas un artefact de scan. Ces noms de paramètres ne signifient rien pour aucun autre logiciel.

## Si la porte dérobée était présente

Supprimer l'extension ferme la porte. Cela ne vous dit rien sur qui l'a franchie avant.

Procédez dans cet ordre :

1. **Supprimer l'extension.** `wp plugin deactivate advanced-responsive-video-embedder && wp plugin delete advanced-responsive-video-embedder`
2. **Auditer les comptes administrateurs**, dates de création et adresses e-mail comprises. La porte dérobée s'authentifie comme un administrateur *existant* : un compte pirate n'est donc pas garanti, mais les attaquants en ajoutent couramment un pour la persistance.
3. **Chercher les fichiers ajoutés ou modifiés depuis le 28 juillet**, en particulier le PHP sous `wp-content`.
4. **Renouveler tous les secrets** : mots de passe administrateurs, mots de passe d'application, clés d'API, identifiants de base, et tout secret stocké dans `wp-config.php`. Régénérez les salts au passage.
5. **Invalider toutes les sessions** pour qu'un cookie volé cesse de fonctionner : `wp user session destroy --all --all-users`

Si l'étape 3 remonte quoi que ce soit d'inexpliqué, restaurez une sauvegarde antérieure au 28 juillet plutôt que de nettoyer sur place.

## Ce que cela change sur la confiance accordée aux extensions

La conclusion inconfortable, c'est qu'auditer le code d'une extension une fois vous renseigne sur la version auditée, pas sur celle que vous recevrez mardi prochain. Faire confiance à une extension, c'est faire confiance à qui détient les droits de commit dessus — indéfiniment, et le plus souvent sans le voir.

Cela ne rend pas les extensions inutilisables. Cela rend quelques habitudes payantes :

* **Moins d'extensions.** Chaque extension est une autorisation permanente d'exécuter du code accordée à un tiers. La meilleure défense est une liste plus courte.
* **Privilégier les extensions maintenues et largement installées**, à plusieurs mainteneurs plutôt qu'un seul. Une extension à mainteneur unique, c'est un seul compte à compromettre.
* **Supprimer ce qui est désactivé.** Une extension désactivée reste sur le disque et continue de recevoir des mises à jour. C'est de l'exposition sans bénéfice.
* **Différer de quelques jours les mises à jour non liées à la sécurité** sur les sites de production. C'est exactement la fenêtre dans laquelle cette porte dérobée a été détectée.
* **Garder des sauvegardes dont vous avez réellement testé la restauration.** Les [sauvegardes d'hébergement mutualisé](https://help.onetsolutions.net/fr/web-hosting/backup) et les [snapshots VPS](https://help.onetsolutions.net/fr/vps/snapshot) ne servent que si vous savez que la restauration fonctionne.

<Tip>
  Deux incidents WordPress en quinze jours, par deux chemins opposés : une faille du cœur et une compromission de la chaîne d'approvisionnement. Notre [checklist de durcissement](/fr/securiser-wordpress-apres-wp2shell) couvre ce qui protège des deux.
</Tip>

Besoin d'un second regard sur un site hébergé chez nous ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.
