Le Cyber Resilience Act pour les auteurs de plugins et thèmes WordPress
Vous publiez un plugin ou un thème WordPress. Depuis le 11 septembre 2026, le règlement européen sur la cyber-résilience (CRA) demande à certains d'entre vous de signaler les vulnérabilités activement exploitées dans les 24 heures. Voici comment savoir si vous êtes concerné, ce que les plateformes attendent déjà, et ce qu'il faut mettre en place cette semaine.
Êtes-vous un « fabricant » ?
Le règlement s'applique à tout produit comportant des éléments numériques mis à disposition sur le marché de l'UE dans le cadre d'une activité commerciale (règlement (UE) 2024/2847, article 2, paragraphe 1, et article 3, paragraphe 1). Un plugin est un logiciel. La seule vraie question porte sur l'activité commerciale.
Les considérants posent le test. Un logiciel libre et open source qui n'est pas monétisé par son fabricant reste hors du champ du règlement (considérant 18). Monétisé signifie, en pratique : vous fixez un prix, vous vendez une version pro ou des extensions payantes, vous vendez du support payant, vous acceptez des dons qui dépassent la simple couverture de vos coûts, ou vous traitez des données personnelles au-delà de ce que la sécurité exige (considérants 18 et 19).
- Plugin premium, vendu sur votre site, sur CodeCanyon ou via Freemius : vous êtes fabricant. Envato le dit explicitement à ses auteurs dans son centre d'aide.
- Freemium, gratuit sur WordPress.org avec une montée en gamme payante : la version gratuite fait partie d'une activité commerciale. Fabricant.
- Plugin gratuit, sans version pro, sans support payant, sans société derrière : hors du champ du règlement. Gardez cette configuration si vous voulez rester en dehors.
- Plugin gratuit maintenu par une société (l'outil utilitaire d'une agence, l'assistant d'un hébergeur) : l'activité de la société est commerciale. Fabricant, ou gestionnaire de logiciel libre si la société se contente de soutenir le projet (article 24).
Les agences qui installent des plugins tiers pour leurs clients sont des utilisatrices, pas des distributrices. Une agence qui reprend un plugin sous sa propre marque et le revend en devient le fabricant (article 22).
Ce qui s'applique maintenant, ce qui s'applique en 2027
| Depuis | Obligation | Article |
|---|---|---|
| 11 septembre 2026 | Signaler une vulnérabilité activement exploitée dans votre plugin : alerte précoce dans les 24 heures, notification dans les 72 heures, rapport final dans les 14 jours, via la plateforme de signalement unique de l'ENISA. Même délai pour un incident grave affectant la sécurité du plugin. | Article 14 |
| 11 décembre 2027 | Tout le reste : exigences de sécurité dès la conception, gestion des vulnérabilités (nomenclature logicielle SBOM, politique de divulgation coordonnée, mises à jour de sécurité pendant la période de support), documentation technique, déclaration UE de conformité, marquage CE, et les sanctions. | Articles 13, 64, 71 ; annexes I, V, VII |
« Activement exploitée » signifie que quelqu'un utilise la faille contre des sites réels, pas qu'un scanner l'a détectée. Quand un éditeur de sécurité WordPress publie une « exploitation dans la nature » visant votre plugin, vos 24 heures ont commencé, ou ont commencé plus tôt si vous étiez déjà informé avant lui.
Trois cas récents donnent une idée concrète. Everest Forms Pro (CVE-2026-3300, premium) : correctif le 18 mars 2026, exploitation constatée à partir du 13 avril. Elementor Pro (CVE-2026-32475) : correctif et exploitation confirmée le même jour, le 19 août 2026. All-in-One WP Migration (CVE-2026-19949) : signalé le 14 août, corrigé le 20 août, révélé publiquement le 3 septembre, avec 35 % des sites à jour au moment de la révélation. Au titre de l'article 14, chacun de ces fabricants devait déposer une alerte précoce dans les 24 heures suivant la connaissance de l'exploitation.
Ce que les plateformes demandent déjà
- WordPress.org vous tient responsable du contenu et des actions de votre plugin (règle 2 du répertoire des plugins) et ferme un plugin jusqu'à ce qu'une vulnérabilité signalée soit corrigée. Le répertoire ne publie pas de délai de correction. Les signalements se font à l'adresse [email protected].
- CodeCanyon exige la validation des entrées, l'usage des nonces, des vérifications de capacité et des requêtes préparées, et sa politique de support impose des correctifs de sécurité pour les vulnérabilités majeures pendant la période de support.
- Aucune des deux plateformes ne dépose votre rapport au titre de l'article 14 à votre place. Patchstack propose aux mainteneurs un service géré de divulgation et de signalement ; Envato indique qu'il renverra vers la plateforme de l'ENISA. L'obligation légale reste la vôtre.
Dans quelle classe se situe votre plugin ?
La plupart des plugins sont des produits « par défaut » : auto-évaluation, sans organisme notifié. L'annexe III liste des produits « importants » pour lesquels une évaluation par un tiers peut être exigée, sauf si vous appliquez une norme harmonisée. Deux familles concernent WordPress : les gestionnaires de mots de passe, et les « logiciels qui recherchent, suppriment ou mettent en quarantaine des logiciels malveillants ». Un plugin de sécurité doté d'un scanner de malwares, ou un plugin qui stocke et remplit des identifiants, doit lire l'annexe III, classe I, avant de présumer une simple auto-évaluation.
Cette semaine, dans l'ordre
- Déterminez votre statut avec le test de champ d'application gratuit. Huit questions, un résultat écrit avec les références d'articles. Version gratuite sans activité commerciale : arrêtez-vous ici, et consignez cette décision par écrit.
- Publiez un contact sécurité : un fichier
security.txtsur votre site et une politique de divulgation coordonnée des vulnérabilités en un paragraphe. Les chercheurs le cherchent avant de publier. L'annexe I, partie II, point 5, l'exigera en 2027 ; aujourd'hui, c'est ce qui pousse un chercheur à vous écrire plutôt qu'à publier sur un blog. - Rédigez la procédure des 24 h / 72 h sur une seule page : qui surveille les flux des éditeurs de sécurité, qui décide « exploité ou non », qui dépose le signalement sur la plateforme de l'ENISA, où se trouve le registre. À 2 heures du matin, personne ne lit un manuel de procédures.
- Générez votre SBOM. Pour un plugin PHP, cela veut dire
composer.lock; pour l'outillage de build,package-lock.json. Le scanner gratuit lit les deux et signale tout ce qui figure sur la liste CISA KEV. - Tranchez la question de la période de support. L'article 13, paragraphe 8, demande au moins cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Indiquez la date dans le readme de votre plugin et sur votre page de tarifs.
Le kit génère les treize documents qui soutiennent ces étapes à partir d'un seul formulaire, en anglais ou en français : politique de divulgation coordonnée, security.txt, procédure de signalement avec des modèles au format ENISA, déclaration de support, analyse de risques de l'annexe I et squelette de l'annexe VII. Trois d'entre eux sont visibles en entier avant tout paiement.
Où poser vos questions
Les forums de WordPress.org interdisent la promotion : posez-y vos questions, mais ne répondez pas par un produit. Le Slack Making WordPress n'a pas encore de canal dédié au CRA. Les interventions de WordCamp d'Oliver Sild (WordCamp Europe 2025) et de Simon Kraft (WordCamp Portugal 2026) sont les deux références communautaires. Le groupe de travail Eclipse ORC tient une FAQ publique sur le CRA qui couvre les questions propres à l'open source.
Sources : règlement (UE) 2024/2847 publié au Journal officiel ; règles du répertoire des plugins de WordPress.org (11 mars 2026) ; centre d'aide des auteurs Envato sur le signalement au titre du CRA (2026) ; Patchstack, State of WordPress Security 2026 (25 février 2026) ; BleepingComputer sur le CVE-2026-3300 (6 juin 2026) et le CVE-2026-32475 (3 septembre 2026) ; TechTimes sur le CVE-2026-19949 (3 septembre 2026). Ce n'est pas un conseil juridique.