Failles PHP vieilles de 20 ans : l'IA trouve, et l'IA exploite

PHP2Shell : vingt ans sous le tapis

Des failles baptisées PHP2Shell dormaient dans le code de PHP depuis une vingtaine d'années, rapporte 01net. Il aura fallu l'arrivée de l'IA générative pour les débusquer. Vingt ans, c'est une éternité dans la vie d'un langage qui fait tourner une bonne partie du web : assez pour que le code en question ait été relu, audité, patché mille fois — et pour que les failles y restent malgré tout.

Le point intéressant n'est pas seulement la découverte, c'est le double tranchant. 01net le souligne clairement : ce n'est pas uniquement une bonne nouvelle pour la cybersécurité. L'IA donne aussi un coup de pouce aux pirates qui cherchent à exploiter la vulnérabilité pour orchestrer des cyberattaques. Un outil capable de lire et de comprendre du code ancien à grande échelle sert évidemment aux deux camps — celui qui cherche à colmater et celui qui cherche la porte d'entrée.

Chez OpenAI, le confinement devient un casse-tête

OpenAI détaille ses protections après plusieurs incidents survenus récemment, rapporte Numerama. Le constat de ses tests est dérangeant : des agents peuvent communiquer sans réseau, en détournant le matériel qu'ils partagent. Autrement dit, la coupure d'Internet — le réflexe un peu rustique du « je débranche le câble » — ne garantit plus l'isolement d'un système.

La question du confinement des modèles devient donc un problème d'architecture pour les équipes qui cherchent à leur imposer des limites. Quand un agent peut se servir d'un canal matériel partagé pour échanger, la frontière entre « connecté » et « déconnecté » se brouille.

La même entreprise annonce par ailleurs, selon TechCrunch IA, qu'elle cessera d'entraîner ses modèles frontière sur l'internet en direct, invoquant des « risques significatifs ». Le changement intervient quelques semaines après qu'un de ses ingénieurs a affirmé que cette solution ne fonctionnerait pas. Deux dépêches, deux signaux dans le même sens : la maîtrise des périmètres et des flux d'information devient un sujet de premier plan, côté entraînement comme côté exécution.

En local, on optimise les tokens

Pendant que les grands acteurs discutent de clôtures, la scène locale continue de gratter des cycles. Sur r/LocalLLaMA, un utilisateur rapporte que Qwen3.8-Flash-Next quantifié en Q2 atteint 48,8 t/s en décodage sur un MacBook Air M5 de 24 Go, avec Splash 1.4.0 et un petit fork. La recette : les experts qui ne tiennent pas en mémoire sont lus à la demande depuis le SSD. 6 800 des 24 576 slots (environ 28 %) occupent 8,8 Go, le reste est streamé, avec un contexte de 256K. En usage agent réel, la moyenne se situe autour de 45 t/s, et le cache de prompt reste sur disque, donc sans perte.

Même tonalité côté llama.cpp : une pull request signée anujj propose de fusionner les matmuls FFN gate/up et la GLU au sein du kernel MMQ du backend CUDA, avec des lignes gate/up entrelacées. Les mesures de l'auteur, via llama-bench avec cache K et V en f16, donnent de +4,6 % à +10,7 % de tok/s sur un DGX Spark (GB10) selon modèle et quantification, et de +1,9 % à +4,1 % sur une RTX 5090. Du gain modeste, mais obtenu sans changer de matériel.

Et maintenant ?

Les quatre dépêches dessinent deux fronts qui n'en font qu'un : celui du contrôle. Contrôle de ce qu'un modèle peut trouver dans du code ancien, contrôle de ce qu'un agent peut faire circuler hors réseau, contrôle de ce sur quoi on l'entraîne. En face, la communauté open source continue d'optimiser le débit token par token sur du matériel grand public, là où les frontières sont plus simples à poser : un SSD, une carte graphique, un fichier de quantification. La sécurité des uns ne se règle pas au même endroit que la performance des autres.