Una setmana després dels pegats de PHP2Shell, la pregunta per a un comitè de direcció ja no és tècnica: és quant negoci queda exposat mentre el servidor de la botiga continuï sense actualitzar.
Què ha passat
El 21 d’octubre, el projecte PHP va publicar pegats d’urgència per a dues vulnerabilitats crítiques, batejades com a PHP2Shell. Afecten el mateix motor de PHP i permeten a un atacant executar codi al servidor sense necessitat d’usuari ni contrasenya. Tenen una puntuació de gravetat de 9,2 sobre 10 i afecten gairebé totes les versions de PHP des de la 5.4. Les versions corregides són la 8.5.12, la 8.4.27, la 8.3.36 i la 8.2.35.
Des d’aleshores, els intents d’atac han estat constants i el 26 d’octubre l’agència de ciberseguretat dels Estats Units les va incloure a la seva llista de fallades que ja s’estan explotant. Tot i així, més de 32 milions de serveis PHP del món continuen funcionant amb una versió vulnerable.
Per què importa al teu negoci
PHP és la base de WooCommerce, PrestaShop i Magento, les plataformes sobre les quals funcionen moltes botigues en línia i portals B2B d’empreses mitjanes. Una fallada així no afecta una funció concreta: dona accés a tot el servidor. I en aquest servidor hi ha les comandes, les dades de clients, les integracions amb l’ERP i, en molts casos, les credencials de passarel·les de pagament i marketplaces.
Segons la nostra experiència, el cost real d’un incident d’aquest tipus gairebé mai no és el tècnic. És el de les hores o els dies sense vendre, el de l’equip aturat intentant entendre què ha passat, el d’haver d’avisar clients les dades dels quals poden haver quedat compromeses i el de la confiança que es perd. Per a una botiga que factura 10.000 € al dia, tres dies d’aturada són 30.000 € de vendes que no tornen, sense comptar la resta.
Hi ha un matís important: no n’hi ha prou de tenir WordPress, WooCommerce o PrestaShop al dia. El pegat és a la versió de PHP del servidor, que moltes vegades depèn del proveïdor d’allotjament o de ningú en concret. I les versions anteriors a la 8.2 ja no reben pegats: si la botiga funciona sobre una d’aquestes, el problema no se soluciona amb una actualització, sinó amb un projecte de migració.
Les tres decisions que prendríem aquesta setmana
1. Saber, no suposar. Demanar avui al responsable tècnic o al proveïdor una resposta per escrit: quina versió de PHP executa cada entorn (la botiga, l’entorn de proves, el backoffice i les integracions) i quan s’ha aplicat el pegat.
2. Decidir qui és el responsable de la plataforma. Si ningú no sap respondre la primera pregunta en un dia, el risc no és PHP2Shell: és que la plataforma de la qual depèn la facturació en línia no té un responsable clar. És un bon moment per decidir si aquest manteniment ha de ser a dins de casa o en mans d’un equip amb servei 24×7.
3. Posar data al deute tècnic. Si la botiga funciona amb una versió de PHP sense suport, convé planificar ara l’actualització o la migració, amb pressupost i calendari, en lloc d’esperar el proper avís urgent.
Què faríem a TRILOGI
A les plataformes que gestionem, l’actualització de PHP forma part del manteniment i s’aplica amb proves prèvies per no trencar integracions. Quan una empresa ens demana ajuda en una situació com aquesta, comencem per una revisió ràpida de versions, accessos i registres dels últims dies, i a partir d’aquí proposem el pla: pegat immediat, migració si cal i un model de manteniment que eviti tornar a dependre de la urgència. Si vols veure com ho fem, aquí tens la nostra plataforma eCommerce gestionada 24×7.
Cada dimarts, les 5 notícies que importen: subscriu-te a la newsletter.
