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.
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.
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.