Si tu empresa tiene un sitio web, una tienda en línea, un portal de clientes o una API, es muy probable que corra sobre PHP — el lenguaje detrás de la mayoría de los gestores de contenido y plataformas de e-commerce del mundo. Esta semana, PHP publicó un parche de emergencia para dos fallas que un atacante puede usar desde internet, sin usuario ni contraseña, para tomar control del servidor. Este artículo explica, sin rodeos, qué pasó, por qué debería importarte y qué hacer hoy.
Qué pasó: dos CVEs, misma gravedad
Se trata de dos vulnerabilidades distintas en el núcleo de PHP, ambas calificadas como críticas con una puntuación CVSS 4.0 de 9.2 sobre 10. Ambas permiten lo mismo: ejecución remota de código (RCE) sin autenticación.
No hace falta estar logueado, ni explotar un plugin, ni conocer la aplicación: basta con enviar peticiones web al servidor. Afecta a todas las formas habituales de servir PHP: PHP-FPM, Apache (mod_php), php-cgi, FrankenPHP y LiteSpeed.
Cómo se ve el ataque
// un atacante no autenticado → peticiones web → PHP vulnerable → ejecución de código en tu servidor
En términos de negocio, “ejecución remota de código” significa que un atacante puede correr sus propios comandos dentro de tu servidor como si estuviera sentado frente a él: leer o robar tu base de datos, cifrarla para pedir rescate (ransomware), modificar tu sitio, o usarlo como trampolín hacia el resto de tu red interna.
Por qué importa (aunque no seas técnico)
Esto no es "una actualización más"
Una falla de este tipo no discrimina: cualquiera en internet puede escanear y disparar el ataque de forma automatizada, a escala, contra miles de sitios. No es cuestión de si te escanean, sino de cuándo — y la ventana entre la publicación del parche y el primer exploit masivo suele medirse en días, no meses.
¿Estás afectado? Versiones
Estás expuesto si corres una versión de PHP anterior a la parcheada. Revisa tu versión con php -v en el servidor (o pregunta a tu proveedor de hosting / equipo de desarrollo).
PHP 8.5 < 8.5.12
PHP 8.4 < 8.4.27
PHP 8.3 < 8.3.36
PHP 8.2 < 8.2.35
⚠ Las versiones ya sin soporte (8.1 y anteriores) también están en riesgo y no recibirán parche: la única solución es migrar.
PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35
Publicadas el 21 de octubre de 2026. Aplica la del tren de versión que ya usas.
Qué hacer hoy
- Actualiza PHP ya a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 según tu versión. Si usas hosting administrado, exige a tu proveedor la fecha de aplicación del parche.
- Inventaría dónde corre PHP: no sólo tu sitio principal — también paneles, micrositios, APIs, contenedores y aplicaciones de terceros. Lo que no sabes que tienes es lo que te compromete.
- Si no puedes parchear de inmediato: aplica mitigación con un WAF (virtual patching), reduce la exposición del servicio y refuerza el monitoreo mientras agendas la actualización. Es un puente, no una solución.
- Vigila señales de compromiso: procesos inusuales, archivos nuevos en el webroot, tráfico saliente extraño o picos de errores. Ante la duda, activa respuesta a incidentes.
- Valida que el parche quedó bien aplicado y que ningún atacante entró antes de que actualizaras — un escaneo reactivo no sustituye una verificación real.
La lección de fondo: parchear rápido no es un lujo técnico, es gestión de riesgo del negocio. Las organizaciones que mantienen un inventario vivo de su superficie expuesta y una cadencia disciplinada de actualización convierten una alerta crítica como ésta en un trámite de horas — no en una crisis de días.
// ¿No sabes si estás expuesto?
En Haak identificamos dónde corre PHP en tu infraestructura, confirmamos si estás en versión vulnerable y verificamos que nadie se haya aprovechado antes del parche. Gestión de vulnerabilidades, pentesting y respuesta a incidentes.
Ver servicios de ciberseguridad →