23/10/2026
ALERTA DE CIBERSEGURIDAD: vulnerabilidades críticas en PHP
En las últimas horas se han publicado vulnerabilidades críticas que afectan distintas versiones de PHP y que, bajo determinadas condiciones, pueden permitir ejecución remota de código sin autenticación.
La situación es relevante porque PHP continúa siendo uno de los runtimes web más utilizados y está presente detrás de una gran cantidad de sitios y aplicaciones desarrolladas con WordPress, WooCommerce, Drupal, Joomla, Laravel, Symfony, Magento y múltiples soluciones empresariales.
Es importante aclarar que el problema no necesariamente está en WordPress, Joomla, Laravel o alguna otra aplicación específica. La vulnerabilidad se encuentra en el runtime PHP que ejecuta estas plataformas.
¿Qué sistemas deben revisarse?
Servidores Apache con mod_php.
Servidores Nginx con PHP-FPM.
LiteSpeed con PHP.
php-cgi.
Contenedores Docker basados en imágenes PHP.
Sitios WordPress y WooCommerce.
Drupal y Joomla.
Aplicaciones Laravel y Symfony.
Magento / Adobe Commerce.
Aplicaciones PHP desarrolladas internamente.
Appliances, paneles y herramientas que incorporen PHP.
No todos los sitios web están afectados. Aplicaciones construidas exclusivamente con tecnologías como React, Node.js, Python, Java, .NET, Go, Supabase Edge Functions o arquitecturas serverless sin PHP no son vulnerables directamente a estas fallas.
Versiones que deben revisarse
Las ramas corregidas publicadas son:
PHP 8.5.12 o superior
PHP 8.4.27 o superior
PHP 8.3.36 o superior
PHP 8.2.35 o superior
Las versiones anteriores dentro de estas ramas deben considerarse vulnerables hasta confirmar que el proveedor del sistema operativo haya aplicado un backport de seguridad.
Las versiones de PHP fuera de soporte deben tratarse con especial atención y migrarse a una rama soportada.
¿Qué debe hacer una empresa?
1. Identificar
Revisar todos los servidores, páginas, aplicaciones, contenedores y appliances que utilicen PHP.
En Linux se puede comenzar con:
php -v
También deben revisarse PHP-FPM, Apache, Docker, Kubernetes, cPanel, Plesk y cualquier otro sistema que pueda incorporar PHP internamente.
2. Validar la exposición
Determinar si el servidor está accesible directamente desde Internet.
La combinación de mayor riesgo es:
Internet
Servidor web
PHP vulnerable
Aplicación
Los sistemas expuestos públicamente deben atenderse primero.
3. Actualizar
Aplicar inmediatamente las actualizaciones de seguridad correspondientes al sistema operativo, distribución Linux, contenedor o proveedor.
No basta con saber que se utiliza PHP 8.3.
Es necesario validar el patch level exacto.
Por ejemplo:
PHP 8.3.35: vulnerable
PHP 8.3.36: corregido
4. Reiniciar los servicios
Después de actualizar PHP deben reiniciarse los workers y servicios correspondientes, por ejemplo PHP-FPM, Apache o los contenedores involucrados.
5. Si no es posible actualizar inmediatamente
Se recomienda considerar temporalmente medidas como:
Retirar el servicio de Internet.
Restringir el acceso mediante VPN.
Aplicar listas permitidas de IP.
Limitar el acceso administrativo.
Incrementar los controles mediante WAF.
Estas medidas pueden reducir la exposición, pero no sustituyen la aplicación del parche.
6. Realizar Threat Hunting
Actualizar PHP evita nuevos intentos de explotación, pero no elimina una posible intrusión que haya ocurrido antes del parche.
Por ello, es recomendable revisar:
Archivos PHP creados recientemente.
Webshells.
Procesos ejecutados por www-data, apache o php-fpm.
Cron jobs desconocidos.
Conexiones salientes inesperadas.
Cambios dentro del webroot.
Archivos sospechosos en /tmp, /var/tmp y /dev/shm.
Credenciales, API Keys y secretos expuestos.
También deben revisarse archivos sensibles como:
env
wp-config.php
config.php
credentials
tokens
API Keys
Si se detecta evidencia de compromiso, será necesario evaluar la rotación de credenciales y ejecutar un proceso formal de respuesta a incidentes.
Caso WordPress
Actualizar WordPress, plugins y temas continúa siendo una buena práctica, pero no corrige por sí solo esta vulnerabilidad.
Si el servidor ejecuta una versión vulnerable de PHP, el sitio continúa expuesto aunque WordPress esté completamente actualizado.
Caso hosting administrado
Si una página se encuentra en un hosting compartido o administrado, se recomienda preguntar directamente al proveedor:
“¿Qué versión exacta de PHP está ejecutando mi sitio y ya fueron aplicadas las correcciones para las vulnerabilidades críticas publicadas en octubre de 2026?”
Caso Docker y Kubernetes
Si se utilizan imágenes PHP, no basta con reiniciar los contenedores.
Es necesario obtener una imagen corregida, reconstruir y volver a desplegar la aplicación.
Recomendación
Las organizaciones deberían tratar este evento como una prioridad alta y seguir un proceso ordenado:
Inventario
Validación de exposición
Actualización
Reinicio
Verificación
Threat Hunting
No se trata de generar alarma, sino de actuar con rapidez, método y evidencia.
La seguridad no consiste únicamente en instalar un parche.
También implica saber qué infraestructura se tiene, qué está expuesto, qué versión se está ejecutando, cuánto tiempo estuvo vulnerable y si existe evidencia de intentos de explotación.
En DbaSys13 recomendamos revisar de inmediato cualquier infraestructura PHP expuesta a Internet, especialmente servidores web, aplicaciones empresariales, WordPress, contenedores y sistemas legacy.
