WordPress, c’est bien. Mais WordPress qui injecte des scripts d’emojis, des styles Gutenberg, des shortlinks et 47 autres trucs dont vous n’avez pas besoin dans chaque page de votre site… c’est moins bien évidemment. Heureusement, Terence Eden, un dev qui en avait marre de voir son code source ressembler à un plat de spaghetti, a compilé une petite liste de tout ce qu’on peut virer .

Car WordPress a adopté une philosophie de type “Decisions, not options” (des décisions, pas des options) où en gros, au lieu de vous laisser choisir, ils décident pour vous de ce qui est bon pour vous. Un peu comme Macron ^^. Le problème c’est que leurs décisions incluent un tas de fonctionnalités dont la plupart des gens n’ont rien à faire 🥲.

Par exemple les emojis. J’sais pas si vous savez, mais WordPress charge un script de détection d’emojis et une feuille de style dédiée sur CHAQUE page de votre site. Pourquoi tant de haine ? Hé bien parce que si vous tapez :-) dans un article, WordPress veut le transformer en joli emoji. Sauf que si vous utilisez les vrais emojis Unicode (comme tout le monde en 2025), hé ce script ne sert à rien. Et il y a aussi le grand remplacement des emojis dans les flux RSS…. Bref, tout ça, ça dégage.

Ensuite y’a le formatage automatique avec wptexturize qui transforme vos guillemets droits en guillemets typographiques “comme ça”. Et mon préféré, capital_P_dangit qui remplace automatiquement “Wordpress” par “WordPress” avec le P majuscule. Oui, vous ne le saviez pas, mais WordPress corrige l’orthographe de son propre nom dans vos articles. Mais quelle bande de nazes ^^.

Gutenberg, l’éditeur de blocs que j’adore, injecte lui aussi ses styles globaux même si vous utilisez l’éditeur classique. Et c’est pareil pour les styles de la librairie de blocs et l’éditeur de widgets basé sur les blocs. Si vous êtes resté sur le Classic Editor comme beaucoup de gens, tout ça ne sert alors qu’à alourdir vos pages.

Côté métadonnées, WordPress ajoute aussi pleiiiiin de trucs dans le code de vos pages comme les shortlinks, le RSD (Real Simple Discovery, un truc d’il y a 20 ans), des liens vers les flux de commentaires, les liens JSON de l’API REST…

Aux chiottes toutes ces conneries !

Le script de Terence fait aussi sauter l’ajout automatique des tailles d’images (wp_img_tag_add_auto_sizes), les templates de pièces jointes, et les block hooks qui modifient votre contenu. L’idée c’est donc de reprendre le contrôle sur ce que WordPress génère, au lieu de le laisser décider tout seul.

Et grâce à son script, le site de Terence (sans Philippe) obtient d’excellents scores sur PageSpeed Insights , ce qui prouve que tout ce bloat n’est vraiment pas nécessaire. Son script PHP complet fait environ 190 lignes et il est dispo sur son GitLab , bien commenté pour que vous puissiez choisir ce que vous voulez garder ou virer.

Attention quand même, certaines de ces désactivations peuvent casser des fonctionnalités si vous les utilisez vraiment. Par exemple, si vous avez des plugins qui dépendent de l’API REST, la virer complètement serait une mauvaise idée. Même chose pour les blocks Gutenberg si vous utilisez cet éditeur. L’astuce c’est donc de tester chaque modification une par une et de voir ce qui se passe.

Amusez-vous bien et un grand merci à Terence !

ImunifyAV, le scanner AV qui protège 56 millions de sites Linux, vient de se faire pwn par le malware qu’il essayait de détecter. Et c’est pas la première fois…

En effet, Patchstack vient de révéler une faille RCE critique dans ImunifyAV, qui je le rappelle est un scanner antivirus gratuit ultra répandu dans l’hébergement mutualisé. Le problème en fait c’est que AI-bolit, le composant qui déobfusque le code PHP malveillant pour l’analyser, utilise la fonction call_user_func_array sans vérifier les noms de fonctions qu’elle exécute.

Boooh ! Du coup, vous uploadez un fichier PHP malveillant spécialement conçu pour l’occasion par un attaquant, ImunifyAV le scanne pour voir si c’est un malware, le déobfusque pour comprendre ce qu’il fait, et hop, le code malveillant s’exécute avec les privilèges du scanner.

Game over.

Hé pour qu’un antimalware détecte un virus, il doit analyser son code mais si les cybercriminels obfusquent leur malware pour cacher le code, l’antimalware doit alors le déobfusquer avant d’analyser. Mais déobfusquer du code PHP, ça veut dire aussi l’exécuter partiellement pour voir ce qu’il fait vraiment… d’où cette RCE.

La faille affecte donc toutes les versions avant la 32.7.4.0 et le correctif apporte juste une fonctionnalité de whitelist de fonctions autorisées pendant la déobfuscation. Il était temps, même si maintenir une whitelist de fonctions safe, à terme c’est un cauchemar car y’a des centaines de fonctions dans PHP. Certaines sont safe seules mais dangereuses combinées et je pense que les cybercriminels trouveront toujours un moyen de contourner cette whitelist.

En tout cas, comme je le laissais entendre en intro, c’est pas la première fois qu’AI-bolit se fait avoir sur la déobfuscation. En 2021, Talos avait déjà trouvé une faille sur unserialize dans le même composant. C’est la même blague car pour analyser du code malveillant sérialisé, il faut le désérialiser. Et désérialiser du contenu malveillant sans validation, ça fait “pwn” !

Voilà, 2 fois en 4 ans sur le même composant, c’est pas ce que j’appelle un accident. C’est un problème structurel car détecter du malware sans l’exécuter, c’est quasi impossible avec du code dynamique. Les signatures statiques ça marche bien pour les virus classiques mais face à du PHP obfusqué qui se reconstruit à l’exécution, vous êtes obligé de lancer le code pour voir ce qu’il fait vraiment. Et là, on est forcement en zone grise…

Même si on exécute du code potentiellement malveillant dans un environnement censé être isolé, si celui-ci “fuit” ou si le code malveillant trouve un moyen de sortir de la sandbox, vous avez une RCE. Et comme ImunifyAV tourne avec les privilèges nécessaires pour scanner tous les fichiers d’un serveur mutualisé, si vous compromettez cet antivirus, vous avez potentiellement accès à tous les sites hébergés sur la machine.

Si vous voulez tester, voici le proof of concept :

<?php
$data = "test";

$payload = "\x73\x79\x73\x74\x65\x6d"("\x74\x6f\x75\x63\x68\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74\x20\x26\x26\x20\x65\x63\x68\x6f\x20\x22\x44\x45\x46\x2d\x33\x36\x37\x38\x39\x22\x20\x3e\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74");
eval("\x70\x61\x63\x6b"($payload));
?>

php ai-bolit.php -y -j poc.php

Concocté par le français Kévin Dunglas, contributeur de longue date à l’écosystème PHP et membre de la Core Team Symfony, FrankenPHP va peut-être dépoussiérer un peu votre bon vieux serveur LAMP tout fatigué.

Il s’agit d’un serveur d’applications PHP moderne développé en Go qui s’appuie sur le serveur web de pointe Caddy. D’après son auteur, tous vos projets PHP, y compris Laravel, Symfony, Drupal, WordPress, Sulu et API Platform, seront optimisés comme jamais grâce à l’intégration native du mode worker.

Moins de lenteurs, plus de perf, et surtout pas mal de fonctionnalités avancées telles que les Early Hints pour un affichage éclair, la prise en charge d’HTTP/2 et HTTP/3 pour une navigation optimale, la compression Brotli, Zstandard et Gzip, les logs structurés, le support de Prometheus pour les métriques, et même du temps réel avec Mercure. Que vous soyez accro à Symfony, fan d’API Platform ou un inconditionnel de Laravel, FrankenPHP s’occupera de tout et d’après les benchmarks visibles sur le site officiel, il booste même les performances jusqu’à 3,5 fois plus vite que FPM sur les applications de type API Platform.

Conçu dans un souci de simplicité, ce serveur PHP n’a besoin que d’un seul service et d’un seul binaire. Pas besoin de PHP-FPM, il utilise son propre SAPI (Server API) spécialement conçu pour les serveurs web Go. Il peut être déployé facilement comme une application Cloud Native via une image Docker, et est compatible avec Kubernetes et toutes les plateformes Cloud modernes. Vous pouvez même packager votre application PHP comme un binaire statique autonome et auto-exécutable.

Si vous voulez le tester, vous pouvez soit lancer le binaire, soit utiliser Docker comme ceci :

docker run -v $PWD:/app/public -p 80:80 -p 443:443 -p 443:443/udp dunglas/frankenphp

En deux temps trois mouvements, vous voilà avec un serveur web + PHP 8.2 aux petits oignons ! Y’a plus qu’à mettre votre PHP dans le répertoire de Franken et tadaaa…

Si c’est le binaire que vous récupérez, vous pouvez servir le contenu du répertoire courant avec la commande suivante :

./frankenphp php-server

Ou lancer vos scripts en ligne de commande comme ceci :

./frankenphp php-cli /chemin/vers/votre/script.php

Bref, vous démarrez votre app une fois, et hop, elle reste en mémoire, prête à faire tourner votre site. Caddy gère l’HTTPS automatiquement avec génération, renouvellement et révocation des certificats. Il sert aussi les assets, pendant que PHP fait ce qu’il fait de mieux : exécuter votre code sans faillir. Vous pouvez même intégrer PHP dans n’importe quelle application Go en mode bibliothèque.

Et pour démarrer un serveur Caddy en prod avec FrankenPHP sans utiliser Docker, il suffit de cette configuration ultra simple:

{
    # Activer FrankenPHP 
    frankenphp
    order php_server before file_server
}

localhost {
    # Activer la compression (optionnel)
    encode zstd br gzip  
    # Exécuter les fichiers PHP dans le répertoire courant et servir les ressources
    php_server
}

Ça change un peu !

En tout cas, c’est à tester ! Bravo Kévin, j’ai hâte de voir comment ça va évoluer pour la suite !