PHP2Shell: qué hacer si tu web o tu tienda funcionan con PHP

Si tu web funciona con WordPress, PrestaShop u otra plataforma basada en PHP, pide a tu proveedor que confirme si ha aplicado las actualizaciones de seguridad de PHP2Shell. Actualizar los plugins no corrige estos fallos: la solución debe aplicarse en el servidor.

PHP2Shell es el nombre con el que se conocen dos vulnerabilidades críticas del propio PHP, CVE-2026-109618 (se abre en una pestaña nueva) y CVE-2026-109619 (se abre en una pestaña nueva). El equipo de PHP publicó las versiones corregidas (se abre en una pestaña nueva) el 21 de octubre de 2026, un día antes de lo previsto porque la existencia de los fallos se había filtrado la víspera.

Qué se ha descubierto y por qué es grave

Los dos fallos permiten a un atacante ejecutar código en el servidor sin usuario ni contraseña, y por tanto tomar el control de la web y de los datos a los que accede. El equipo de PHP los puntúa con un 9,2 sobre 10 en la escala CVSS; el 10 que circuló con la filtración no es la puntuación oficial.

Sobre el riesgo real conviene distinguir tres cosas que a menudo se mezclan:

• Demostraciones de los investigadores. Quienes encontraron los fallos demostraron la ejecución remota de código con la configuración por defecto de Apache y mod_php, y también la confirmaron en PHP-FPM a través de rutas de la propia aplicación.
• Pruebas de concepto públicas. Tras la publicación han empezado a circular pruebas de concepto, lo que acorta el tiempo hasta que aparezcan ataques automatizados.
• Ataques en circulación. Empresas de seguridad han reportado intentos de ataque. Cuando se publicó el aviso, el equipo de seguridad de PHP (se abre en una pestaña nueva) no tenía constancia de exploits funcionales en uso, pero eso puede cambiar en cualquier momento, y cualquier exploit que aparezca funcionará contra todos los servidores que sigan sin actualizar.

La conclusión es la misma en los tres casos: hay que actualizar cuanto antes.

A qué webs afecta

A cualquier web o aplicación que funcione con una versión de PHP anterior a las corregidas, da igual el programa que corra encima: WordPress, WooCommerce, PrestaShop, Magento, Drupal, Joomla, Laravel o un desarrollo propio. El proyecto PrestaShop (se abre en una pestaña nueva) lo resume bien: el fallo no está en PrestaShop ni en ninguno de sus módulos, pero las tiendas quedan expuestas a través del PHP del servidor.

Estas son las versiones que corrigen los fallos en cada rama con soporte:

• PHP 8.5: versión 8.5.12 o posterior.
• PHP 8.4: versión 8.4.27 o posterior.
• PHP 8.3: versión 8.3.36 o posterior.
• PHP 8.2: versión 8.2.35 o posterior.
• PHP 8.1 y anteriores, incluida la 5.6: sin versión oficial nueva (ver más abajo).

Qué preguntar a tu hosting o a quien mantiene la web

La actualización de PHP es un trabajo sobre el servidor, así que normalmente no lo hace tu equipo, sino quien gestiona ese servidor. Si la web está en un hosting compartido, lo actualiza el proveedor de hosting; si está en un servidor propio o en la nube y una agencia se encarga de mantenerlo, le corresponde a la agencia. Si no sabes cuál es tu caso, mira quién tiene el acceso de administrador al servidor, algo que explicamos en quién tiene las llaves de tu web. Estas son las preguntas que conviene hacer, pidiendo la respuesta por escrito:

1. Qué versión de PHP usa cada uno de nuestros entornos: producción, pruebas y subdominios antiguos.
2. Si esa versión, o el paquete instalado, incluye la corrección de CVE-2026-109618 y CVE-2026-109619.
3. Si se ha reiniciado PHP después de actualizar, porque un parche instalado sin reiniciar no protege.
4. Si se ha aplicado alguna medida provisional mientras tanto y hasta cuándo.
5. Si se han revisado los registros del servidor en busca de ficheros nuevos o modificados.

La segunda pregunta es la importante. Si el servidor usa los paquetes de PHP de su distribución de Linux (Debian, Ubuntu, Red Hat y similares), el número de versión de PHP puede seguir siendo anterior a 8.2.35 aunque la corrección ya esté aplicada, porque la distribución lo incorpora sin cambiar ese número. En ese caso lo que confirma la corrección es la versión del paquete, no la de PHP, así que pide que te lo confirmen expresamente.

Si tu web usa PHP 5.6, 7, 8.0 u 8.1

Estas ramas ya no reciben versiones oficiales. Para 7.4, 8.0 y 8.1 el equipo de seguridad de PHP publicó parches mínimos en código fuente, y algunas distribuciones y proveedores de soporte extendido ya los incluyen en sus paquetes. Si se aplican, este fallo concreto queda resuelto; lo que no resuelven es el problema de fondo, porque una web en una versión sin soporte quedará expuesta al siguiente fallo que se descubra.

El caso más delicado es PHP 5.6 y anteriores: no tienen parche oficial y, según los investigadores, la parte de código afectada existe desde PHP 5.4. Además, es donde más cuesta actualizar. Pasar de PHP 7 a PHP 8 suele ser asumible, pero el salto desde 5.6 rompe mucho código antiguo y a menudo obliga a rehacer partes de la aplicación. Si tu web sigue en 5.6, conviene planificar ese salto cuanto antes en lugar de esperar al próximo aviso.

Es buen momento para planificar el cambio de versión. Según php.net (se abre en una pestaña nueva), PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026, así que si vas a actualizar conviene saltar a 8.3 o superior. Cambiar de versión puede romper temas, plugins o módulos antiguos, por lo que se prueba antes en un entorno de pruebas.

Qué debería hacer tu proveedor de mantenimiento

Ante un aviso así, un buen mantenimiento web no espera a que el cliente pregunte. Estas son las comprobaciones que puedes esperar:

• Inventario de todos los entornos con PHP, incluidos los de pruebas y los olvidados.
• Actualización probada antes en un entorno de pruebas, para que el parche no rompa la web.
• Despliegue en una ventana acordada, con vuelta atrás preparada, y reinicio de PHP.
• Comprobación posterior de que el parche está aplicado de verdad.
• Revisión de registros y ficheros por si alguien intentó entrar antes del parche.
• Un aviso al cliente explicando qué se ha hecho y qué queda pendiente.

Si alguna de estas respuestas no llega o es vaga, es una buena señal para revisar quién se ocupa de la seguridad de tu web.

Para el responsable del servidor: comprobación y medidas provisionales

Para comprobar la versión, php -v en el servidor. Si los paquetes de PHP son los de la distribución, confirma además que el registro de cambios del paquete menciona CVE-2026-109618 y CVE-2026-109619. Tras actualizar, hay que reiniciar PHP-FPM o Apache.

Si no se puede actualizar de inmediato, estos ajustes reducen la exposición, aunque no hacen segura la instalación. Los primeros son los que indica el equipo de PHP; los tres últimos no aparecen en su aviso, pero van en la línea de los límites de campos y anidamiento que recomienda y ayudan frente a ataques con muchas peticiones en paralelo:

; Indicados por el equipo de PHP
memory_limit = -1                  ; CVE-2026-109618, vigila el consumo de memoria
post_max_size = 8M                 ; 32M si la web recibe ficheros
upload_max_filesize = 6M           ; siempre por debajo de post_max_size
session.upload_progress.enabled = 0 ; CVE-2026-109619
fatal_error_backtraces = 0         ; solo en PHP 8.5

; Adicionales, no oficiales
max_file_uploads = 5
max_input_vars = 500
max_input_nesting_level = 8

Van en el php.ini que usa el servidor web, no en el de la línea de comandos. Por ejemplo, en Debian y Ubuntu con Apache y mod_php es /etc/php/<versión>/apache2/php.ini; con Nginx, que trabaja con PHP-FPM, es /etc/php/<versión>/fpm/php.ini. Retocar /etc/php/<versión>/cli/php.ini no protege la web. Para memory_limit, el equipo de PHP recomienda fijarlo de forma que la aplicación no pueda cambiarlo, con php_admin_value en el pool de FPM o en la configuración de Apache. No sirven ni ini_set() desde el código ni un fichero .user.ini, y hay que reiniciar PHP para que surtan efecto.

Conviene además poner límites antes de que la petición llegue a PHP, en Apache o Nginx. Por un lado, limitar el tamaño de las peticiones, por ejemplo con LimitRequestBody 10485760 (10 MB) en Apache o client_max_body_size 10m en Nginx. Por otro, CVE-2026-109618 se aprovecha sobre todo a través de envíos de formularios con ficheros (multipart/form-data), así que si la web no necesita recibir ficheros se pueden rechazar esas peticiones en la configuración de Apache o Nginx. Tiene que hacerse ahí y no desde PHP: la petición no debe llegar a procesarse.

¿No sabes si tu servidor está actualizado? Podemos revisar qué versión de PHP utiliza tu web y qué falta por corregir.