Entre la publication d’une faille et l’installation du correctif sur votre site, il s’écoule toujours un délai : l’éditeur n’a pas encore publié de version corrigée, la mise à jour casse une fonction, ou personne n’a eu le temps de la tester. Le patch virtuel (on dit aussi correctif virtuel, ou « vPatch » chez certains éditeurs) sert à combler ce délai. L’OWASP le décrit comme une couche d’application de règles qui détecte et bloque les tentatives d’exploitation d’une vulnérabilité connue, sans retirer la faille elle-même.
Comment fonctionne un patch virtuel
Une fois la faille analysée (paramètre vulnérable, versions touchées, conditions d’exploitation), on écrit une règle qui reconnaît les requêtes dangereuses pour ce cas précis. Deux approches existent :
- Modèle positif (liste d’autorisation) : on définit ce qu’est une valeur valide pour le paramètre visé, par exemple un nombre entier, et tout le reste est rejeté. C’est le plus solide, mais il demande un travail manuel.
- Modèle négatif (liste de blocage) : on bloque les motifs d’attaque connus. Plus rapide à déployer, mais plus facile à contourner par un encodage différent.
L’OWASP recommande de tester la règle en mode journalisation avant de bloquer, d’éviter les règles qui ne reconnaissent que la charge exacte publiée dans l’alerte, et de retirer le patch virtuel une fois le code corrigé.
Où il s’applique
Un patch virtuel peut être appliqué à plusieurs niveaux du chemin d’une requête : par un pare-feu applicatif en ligne, par le serveur web (ModSecurity sur Apache ou Nginx), ou par un agent installé dans l’application. Pour WordPress, Patchstack déploie ses règles uniquement pour les composants vulnérables réellement installés sur le site, grâce à l’inventaire des versions, et les exécute dans l’application ou, selon la faille, dès Apache ou Nginx.
Quand c’est utile
- Une faille est publiée sans version corrigée, ou l’éditeur tarde.
- Une extension n’est plus maintenue mais le site en dépend encore : une situation à régler, comme l’explique notre article sur les extensions abandonnées, mais qui ne se règle pas en un jour.
- Vous gérez beaucoup de sites et les mises à jour passent d’abord par une préproduction.
- Une faille est exploitée en masse quelques heures après sa publication, plus vite que votre cycle de maintenance.
Pour WordPress : outils et limites
Patchstack (dans ses offres payantes), Wordfence et les pare-feu en ligne comme Cloudflare publient des règles propres à des failles WordPress connues, avec des délais et des modèles différents ; notre comparatif des pare-feu détaille ces différences. Quelques limites à garder en tête :
- Une règle n’existe qu’une fois la faille connue : face à une faille zero-day, il n’y a rien à déployer.
- La couverture dépend de la base de l’éditeur, souvent plus faible pour les extensions premium vendues hors de wordpress.org.
- Une requête qui n’est pas inspectée (par exemple une attaque qui ne passe pas par le pare-feu) n’est pas protégée.
WP Masquerade n’est pas un pare-feu et n’applique pas de patchs virtuels. Il intervient avant et à côté : il rend vos extensions moins faciles à inventorier depuis l’extérieur, et ses alertes de vulnérabilités vous disent quelle extension installée est concernée par une CVE et dans quelle version elle est corrigée. L’association avec Patchstack montre comment répartir les rôles entre les deux.