2 minutos de lectura
El 21 de octubre se publicaron dos vulnerabilidades críticas en PHP que permitían ejecutar código en un servidor sin autenticarse. Cinco horas después del aviso ya teníamos una medida preventiva en producción, y ocho horas después de publicarse el parche oficial estaba desplegado en la gran mayoría de medios que confían en nosotros.
Qué pasó, a quién afectaba y qué hicimos
El 21 de octubre, a las 7:21 h, nuestro equipo de Sistemas detectó el aviso del CERT de la UE: dos vulnerabilidades en PHP (CVE-2026-109618 y CVE-2026-109619), con una gravedad de 9.2 sobre 10 (nivel crítico), que permitían a un atacante ejecutar código en el servidor sin necesidad de credenciales, y afectaban a prácticamente todas las versiones del lenguaje. A esa hora, el parche oficial aún no existía y PHP no ofrecía de manera oficial más información sobre el problema ni las posibles medidas preventivas.
Desde Bitban no esperamos y reaccionamos inmediatamente. En solo dos horas, los equipos de CORE, CMS y CRM ya habían revisado todos los puntos de nuestras plataformas que aceptan subidas de ficheros, la vía de ataque más probable. Con ese mapa, diseñamos una medida preventiva: bloquear en la CDN y en el balanceador todas las subidas de este tipo, excepto la subida de imágenes editoriales que las redacciones utilizan a diario.
Realizamos pruebas en entornos de integración y preproducción, nuestro equipo de QA pasó los tests automáticos y a mediodía ya estaba en producción. Al mismo tiempo, cada responsable de cuenta avisó a sus clientes de todas nuestras actuaciones y de su posible impacto.
PHP publicó la corrección a las 15:53 h y regeneramos nuestras imágenes base en cuanto estuvieron disponibles las oficiales, a pesar de que el repositorio de extensiones de PHP estuvo caído buena parte de la tarde. A partir de las 21:20 horas, desplegamos el parche proyecto a proyecto, comprobando en cada uno que la versión era la correcta y que el CMS y los muros de pago funcionaban correctamente.
Pasados 8 minutos de la medianoche, el parche estaba disponible en producción en prácticamente todos los proyectos, incluidos los de mayor tráfico. A primera hora del 22 de octubre, justo un día después, continuamos con el resto y con los entornos de pruebas.
“El 21 de octubre fue uno de esos días que explican por qué un medio confía su plataforma a un equipo y no solo a un software”.
Alejandro García, CEO de Bitban Technologies.
Lecciones que nos llevamos
-
Velocidad sin improvisar: medida preventiva antes del parche, pruebas antes de producción y comunicación del suceso a cada cliente.
-
Una plataforma homogénea se parchea en horas: los proyectos sobre la versión actual de bCube se actualizaron con el mismo procedimiento.
-
Un equipo que responde: desarrolladores, sistemas, QA y responsables de cuenta trabajaron hasta pasada la medianoche.
−−−
Si tu medio necesita una plataforma editorial con un equipo que responde en horas cuando surge una vulnerabilidad crítica, hablemos.