Attaque WordPress via mises à jour & Google sanctionne le back-button hijacking - Actualités Hacker News (14 avr. 2026)

On commence par la story sécurité la plus marquante du jour : une attaque de supply chain WordPress à grande échelle. D’après un chercheur, un acheteur a repris le portefeuille “Essential Plugin”, puis a utilisé le canal de mises à jour pour disséminer une backdoor dans plus de trente plugins très installés. Le scénario est classique dans l’idée — “mise à jour de confiance” qui devient un cheval de Troie — mais spectaculaire dans l’exécution : l’injection a aussi touché des fichiers sensibles comme wp-config.php, et une partie des redirections et du SEO spam ne s’activait que face à Googlebot, pour rester invisible aux visiteurs. Et détail inhabituel : la résolution du domaine de commande et contrôle passait par un smart contract Ethereum, ce qui complique les blocages traditionnels. WordPress.org a fermé les plugins concernés et poussé une mise à jour de neutralisation, mais ça ne nettoie pas automatiquement les sites déjà modifiés. Ce que ça rappelle, très concrètement : un transfert de propriété de plugin, c’est aussi un transfert de confiance — et aujourd’hui l’écosystème n’a pas toujours les garde-fous ni la transparence qui vont avec.

Dans un registre plus “hygiène du web”, Google Search ajoute une règle anti-spam explicite contre le “back button hijacking”, le détournement du bouton retour. En clair, certains sites manipulent l’historique du navigateur pour vous empêcher de revenir à la page précédente, ou pour vous renvoyer ailleurs — souvent vers des pubs, des recommandations forcées, ou des pages que vous n’avez même jamais visitées. Google dit que ça violait déjà ses consignes, mais le fait de le nommer et de le ranger dans les “pratiques malveillantes” change la donne : ça devient une cible nette pour des actions manuelles et des déclassements automatiques. À partir du 15 juin 2026, l’impact peut être direct sur la visibilité. Et pour les éditeurs sérieux, l’enjeu est aussi interne : auditer son code… et surtout les scripts tiers, les régies et bibliothèques qui pourraient déclencher ce comportement sans que personne ne s’en rende compte.

Toujours côté confiance, un utilisateur de longue date accuse Backblaze d’avoir commencé à exclure discrètement des dossiers importants des sauvegardes. Le signal d’alarme : l’historique d’un dépôt Git impossible à restaurer parce que les dossiers .git étaient ignorés. Ensuite, même logique pour des répertoires issus de services de synchronisation comme OneDrive ou Dropbox. Backblaze justifie ce virage par des questions de performance et par l’idée de “ne sauvegarder que le stockage local”, en évitant des points de montage, des caches, ou des contenus qui pourraient déjà être ailleurs. Sauf que, dans la vraie vie, la synchro n’est pas une sauvegarde : rétention limitée, erreurs propagées, risques liés au compte. Et surtout, quand ces exclusions arrivent sans notification explicite, on découvre le problème le jour où on a besoin de restaurer. Pour un outil de backup, c’est précisément le scénario qu’on veut éviter.

Passons aux outils de développement. GitHub lance un support natif des “stacked pull requests”, les PR empilées, avec une extension CLI appelée gh stack. L’idée est simple : au lieu d’un énorme lot de changements difficile à relire, on découpe en petites PR ordonnées, chacune dépendant de la précédente, jusqu’à la branche principale. Ce qui rend la nouveauté intéressante, ce n’est pas le concept — beaucoup d’équipes le faisaient déjà avec de la discipline et des scripts — c’est l’intégration dans l’interface : une vue qui clarifie la pile, une navigation entre couches, et un comportement plus prévisible quand une partie est fusionnée, parce que le reste se réaligne automatiquement. GitHub insiste aussi sur l’exécution de la CI “comme si” chaque couche visait la branche finale, pour limiter les surprises. Résultat : moins de frictions en revue de code, moins de conflits, et un chemin plus naturel vers des livraisons incrémentales — y compris quand des agents de code viennent s’inviter dans le workflow.

Dans la même veine “on peut faire mieux que Git”, un article met en avant jj, l’interface en ligne de commande de Jujutsu, un système de gestion de versions distribué. Le pitch : garder la puissance attendue par les développeurs, mais réduire la complexité mentale, avec des commandes qui se composent mieux et des opérations avancées moins pénibles qu’avec Git. Le point pratique qui peut changer l’adoption, c’est la compatibilité : Jujutsu peut s’appuyer sur un backend Git. Autrement dit, on peut expérimenter individuellement, sans imposer une migration à toute l’équipe et sans perdre l’historique. Ce genre d’approche compte, parce qu’une grande partie de la douleur autour du versioning ne vient pas du manque de fonctionnalités, mais de workflows qui deviennent fragiles dès qu’on sort des chemins “habituels”.

Côté IA, un papier attire l’attention : “Introspective Diffusion Language Models”, avec une proposition appelée I-DLM. L’objectif est ambitieux : réduire l’écart de qualité entre les modèles de langage par diffusion et les modèles autoregressifs, tout en gardant un avantage clé de la diffusion, la génération plus parallèle — donc potentiellement plus rapide quand beaucoup de requêtes arrivent en même temps. Les auteurs expliquent que le problème historique vient d’une incohérence interne : le modèle “n’évalue” pas ses propres tokens de façon suffisamment fiable. Leur solution introduit un entraînement orienté cohérence et une méthode d’inférence qui génère plusieurs tokens tout en vérifiant ceux d’avant, pour rester aligné avec le comportement d’un modèle autoregressif de référence. Ils annoncent des résultats compétitifs à taille égale, et surtout un déploiement plus simple, sans infrastructure exotique, sur des stacks de serving déjà courantes. Si ça se confirme, c’est une piste crédible pour accélérer l’inférence LLM sans payer le prix habituel en qualité ou en intégration.

Pour les données, un projet open-source nommé OpenDuck reprend des idées popularisées autour de “DuckDB dans le cloud”, mais en version auto-hébergeable et extensible. L’idée générale : permettre à DuckDB de traiter des tables distantes comme si elles étaient locales, et d’exécuter une même requête en mode hybride, une partie sur la machine de l’utilisateur, une partie sur des workers distants, en ne ramenant que des résultats intermédiaires. Pourquoi c’est intéressant : beaucoup d’équipes aiment DuckDB pour l’analytique “sur place”, mais dès que les volumes ou la collaboration augmentent, elles retombent dans des architectures plus lourdes. OpenDuck tente de combler ce fossé avec un protocole minimal et une approche qui mise sur l’interopérabilité, plutôt que sur une plateforme fermée. Pour ceux qui veulent garder la main sur l’infra tout en gagnant en flexibilité, c’est une direction à surveiller.

Et on termine par un détour rétro : une newsletter sur la publicité “à l’ancienne” revient sur Franklin Computer et sa gamme ACE, des compatibles Apple II au début des années 80. Le papier explique pourquoi ces pubs étaient mémorables — mises en scène accrocheuses, personnage de Benjamin Franklin omniprésent — tout en rappelant le problème de fond : ces machines reposaient sur une copie très proche de l’Apple II, au point d’alimenter une bataille juridique majeure. Apple finira par gagner en appel en 1983, obligeant Franklin à se réorienter. Ce qui rend l’histoire intéressante aujourd’hui, ce n’est pas juste l’anecdote marketing : c’est un instantané des débuts du PC, quand la concurrence passait parfois par le clonage pur et dur, et où le droit d’auteur sur le logiciel et le matériel était encore en train de se définir.