jobsphp

ActualitéÉcosystème PHP

Mise à jour de sécurité PHP 8.3.33 et 8.4.24 : corrigez vos failles critiques

24, publiées fin juillet selon Linux Compatible.

Mise à jour de sécurité PHP 8.3.33 et 8.4.24 : corrigez vos failles critiques

L'équipe PHP vient de dégainer deux versions de sécurité coup sur coup: PHP 8.3.33 et PHP 8.4.24, publiées fin juillet selon Linux Compatible. Au menu: injection SQL PostgreSQL, corruption mémoire dans BCMath, et un crash vicieux dans Phar. Bref, si vous êtes encore sur l'une de ces branches, l'upgrade n'est plus une option.

On patche quoi, exactement?

Trois gros morceaux à avaler, et un bonus libgd pour faire bonne mesure. Le morceau de choix, c'est CVE-2026-17543: une injection SQL critique qui touche les extensions PGSQL et PDO_PGSQL. Le problème vient du mécanisme d'échappement E'...' de PostgreSQL — un attaquant peut glisser des séquences type \x00 ou \n à travers les inputs utilisateur pour casser l'échappement. Oui, on le sait, les requêtes paramétrées, c'est la vie (merci Captain Obvious). Mais combien de legacy ont encore du code qui broie de l'input utilisateur directement dans la requête? Voilà, ces gens-là, on leur dit: patchez maintenant.

Ensuite, BCMath prend une claque avec CVE-2026-17544. Un out-of-bounds write déclenché par bccomp quand on lui file des valeurs arbitraires malveillantes. Si votre projet laisse entrer des inputs non fiables dans les fonctions de comparaison de BCMath, c'est le moment de trembler (et de patcher).

Phar n'est pas en reste avec CVE-2026-7260: des liens symboliques récursifs dans une archive.phar vont faire tomber le stream handler. En vrai, c'est plus du DoS que du RCE, mais ça reste noté haute sévérité. Et tant qu'on y est, libgd remonte en version pour CVE-2026-9672, histoire de plier proprement les bugs de traitement graphique dans les deux branches.

Et pour 8.4.24, c'est juste de la sécurité?

Ah, vous pensiez que c'était fini? Que nenni! La 8.4.24 glisse en douce plus de vingt correctifs de bugs en plus des patches de sécurité. On notera pêle-mêle: des overflows d'entiers dans gregoriantojd et juliantojd qui pètent à INT_MAX, un out-of-bounds read dans le handler flatfile de DBA, des risques de sérialisation dans DOM sur des XML profondément imbriqués, et — enfin! — un patch use-after-free dans array_multisort quand le comparateur mute le tableau en plein tri (qui a déjà débugué ça à 3h du matin?). ODBC et PDO_ODBC se ramassent aussi des heap over-reads et des crashes de connection pooling. Reflection tronque sur les null bytes embarqués, et les streams partagent leurs ressources entre sockets Unix à cause d'une troncature sur null byte. Bref, le plat de résistance classique qui empêche la plateforme de craquer sous la charge.

Concrètement, on fait quoi?

On met à jour, on met à jour, on met à jour. PHP 8.3.33 est tagué par Eric Mann, PHP 8.4.24 par Calvin Buckley (alias NattyNarwhal), les deux commits sont signés GPG sur le repo php/php-src. Si vous tournez sur du 8.3 ou du 8.4, c'est non négociable. Si vous êtes sur une version plus vieille… on en reparle (mais pas dans une news, plutôt dans une thérapie). Et pour les équipes qui maintiennent du legacy: c'est le moment idéal pour auditer vos requêtes SQL et vos appels BCMath, histoire de ne pas reconstruire la même faille dans deux mois.