Servicio de urgencia
El 21 de octubre de 2026, el proyecto PHP publicó dos vulnerabilidades críticas que permiten ejecutar código en el servidor sin autenticación. Afectan a cualquier web o tienda en PHP. Cezetazeta revisa tu servidor, actualiza PHP y aplica medidas de mitigación si la actualización no puede hacerse en el momento.
Publicado el · Fuente: php.net
Son dos fallos en el propio PHP, no en una aplicación concreta. Afectan a todas las formas habituales de servir PHP en la web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Cuando PHP se queda sin memoria, puede interrumpirse con datos internos de la petición a medio preparar. Al limpiar la petición, esos datos inválidos se tratan como válidos.
Parte del estado interno de una petición puede sobrevivir después de liberarse su memoria. Una petición posterior en el mismo worker puede usarlo antes de que se reinicie.
El equipo de PHP ha demostrado un ataque en el que una petición sin autenticar lo desencadena antes de que se ejecute el código de la aplicación.
Tu servidor necesita, como mínimo, la versión corregida de su rama. PHP 8.1 y anteriores no reciben actualizaciones del proyecto PHP.
Si se cumple alguna de estas situaciones, conviene revisar el servidor cuanto antes.
Comprueba la versión que sirve la web, no solo la de la línea de comandos: en un mismo servidor pueden convivir varias.
php -v con el mismo binario que usa la tienda, y la versión del pool de PHP-FPM configurado en el servidor web.php -v muestra la versión de la línea de comandos. Para la web, revisa el pool de PHP-FPM o la configuración de Apache del sitio.Actualizar es la solución completa. Mientras tanto, se reduce la exposición.
Estas son las medidas temporales que recomienda el equipo de PHP. Reducen la exposición a vías de ataque concretas, pero no hacen segura la instalación.
memory_limit=-1 fijado de forma que la aplicación no pueda cambiarlo, por ejemplo conphp_admin_value en el pool de FPM o en Apache.post_max_size bajo: 8M si no hay subida de archivos, 32M si la hay, conupload_max_filesize por debajo.session.upload_progress.enabled=0 en php.ini o en el pool, no con ini_set() ni.user.ini, y reinicio de todos los workers.fatal_error_backtraces=0 y reinicio de todos los workers.Primero se cierra la vía de ataque y después se comprueba que nada haya entrado antes.
Versión, forma de ejecución y origen de PHP en cada sitio del servidor.
Medidas temporales si la actualización necesita preparación.
PHP corregido, reinicio de todos los workers y comprobación de que la web funciona.
Revisión de logs y archivos en busca de indicios de intrusión previa.
Indica la dirección de la web, el tipo de hosting y, si la sabes, la versión de PHP. Para empezar inmediatamente, usa WhatsApp o el teléfono.
Sí, a todos los que funcionan sobre una versión de PHP sin corregir. El fallo está en el propio PHP, no en el CMS, así que actualizar WordPress, PrestaShop o Magento no lo soluciona: hay que actualizar PHP en el servidor. Lo mismo ocurre con Laravel, Symfony y cualquier aplicación en PHP.
En el panel del hosting (Plesk, cPanel u otro) aparece la versión asignada a cada dominio. En WordPress también se ve en Herramientas › Salud del sitio › Información › Servidor. Ojo: la versión de la línea de comandos puede ser distinta de la que sirve la web.
Son los identificadores de las dos vulnerabilidades críticas de PHP publicadas el 21 de octubre de 2026. La primera aprovecha cómo PHP gestiona la falta de memoria y la segunda, un estado interno que sobrevive entre peticiones. Las dos pueden permitir ejecutar código en el servidor sin autenticación.
En hosting compartido el proveedor suele actualizar los paquetes, pero conviene confirmarlo. En un VPS o un servidor dedicado, la actualización corresponde a quien administra el servidor.
No. Según el propio equipo de PHP, las mitigaciones reducen la exposición a vías de ataque concretas, pero no hacen segura la instalación. La solución completa es actualizar.
El proyecto PHP ya no publica versiones para esas ramas. Algunas distribuciones y proveedores LTS ofrecen parches propios, y el equipo de seguridad de PHP ha publicado parches mínimos para quien compila desde el código fuente. Lo recomendable es pasar a una versión con soporte, revisando antes la compatibilidad de la web.
Dentro de la misma rama, por ejemplo de 8.3.30 a 8.3.36, el riesgo es bajo. Cambiar de rama, por ejemplo de 8.1 a 8.3, puede afectar a plugins, módulos o código antiguo, y conviene probarlo antes en una copia de la web.
Actualizar cierra la vía de entrada, pero no elimina lo que un atacante haya dejado dentro. En ese caso hace falta una limpieza y un análisis de cómo entraron, como se explica en la página de web hackeada.