Dans les temps anciens…
En des temps pas si anciens que ça, le piratage de site était un exercice de style.
Les hackeurs s’amusaient à prouver leur compétence et ils se « contentaient » de défacer la page d’accueil d’un site en affichant à la place la preuve de leur méfait.
Il y a eu aussi toute une période où le défaçage était politique : un message de soutien à des terroristes avec parfois un fond sonore « Allah akbar ».
Mais ça, c’était avant.
Le business du hacking
Désormais, hacker un site se fait beaucoup plus discrètement.
Parce que l’objectif du hacker est devenu de gagner de l’argent.
Comment ?
Plusieurs méthodes :
- installer un mineur de cryptomonnaie
- installer un relais de mails pour faire du SPAM
- installer des pages de Phishing : des pages qui ont le look d’un service connu (banques…) pour en récupérer les accès
- quand ce n’est pas un relais pédopornographique…
Bref, un site n’est plus hacké pour la gloire, mais pour faire des pépettes, du flouze, de l’oseille !
Une exploitation de plus en plus rapide des failles
Lorsqu’une faille est découverte dans un logiciel et rendue publique, il fallait du temps avant que celle-ci soit exploitée.
Ce temps n’a cessé de se réduire.
Aujourd’hui (2026), il n’est plus que de 20h ! (Source : article de Next.ink).
Conséquences pratiques
Les hackeurs ont dorénavant les moyens financiers de partir à la chasse des sites comportant des failles de sécurité, parce que c’est rentable et lucratif pour eux.
Socle technique
C’est donc devenu un jeu du chat et de la souris entre ceux qui font les outils qui motorisent le web (Linux, Apache, Nginx, PHP, JavaScript, les navigateurs, WordPress, SPIP et autres CMS…) et les hackeurs.
Ainsi, la fondation PHP a choisi :
- de sortir une nouvelle version de PHP par an (en décembre)
- de ne maintenir que 3 versions (dont une seulement pour les correctifs de sécurité)
Le cas de SPIP
Et c’est poussé par PHP que SPIP a choisi une voie semblable (notation de version X.Y.Z) :
- une nouvelle version mineure en Y tous les 6 mois, avec, une fois par an, la compatibilité avec la dernière version de PHP
- une nouvelle version corrective en Z par mois, plus, si besoin, release de sécurité à la demande
- une nouvelle version majeure en X tous les 2 ans (?) : nouvelle branche (4.x.y, 5.x.y…)
- avec la dernière version Y d’une branche maintenue jusqu’à 6 mois après la sortie de la branche X+2 (la version SPIP 4.4 sera maintenue durant toute la vie de la branche 5 jusqu’à la sortie de la version 6.1)
Ceci nous change radicalement du rythme de sorties assez lent auquel SPIP nous avait habitués.
⇒ Il va falloir mettre à jour plus souvent !
Conséquences pragmatiques
Mettre à jour plus souvent, c’est y consacrer plus de temps ou d’argent :
- si vous en avez peu, restez en SPIP 4.4 jusqu’en juillet 2028
- si vous en avez plus, passez à SPIP 5 dès que vous le pourrez