PHP2Shell: cómo actualizar PHP en tu web y exigir pruebas de que está hecho

El 21 de octubre de 2026 el proyecto PHP publicó versiones de emergencia que corrigen dos fallos críticos conocidos como PHP2Shell. Para el dueño de una empresa el mensaje cabe en una línea: hay que actualizar PHP en cada servidor que responde peticiones web y pedir una confirmación por escrito. Los fallos están en el propio intérprete, así que las webs en WordPress o Magento están expuestas aunque todos los plugins estén al día.

Actualizar PHP hoy: qué pasó el 21 de octubre y a quién afecta

La vulnerabilidad de PHP se corrige en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que cierran CVE-2026-109618 y CVE-2026-109619, dos fallos de ejecución remota de código sin autenticación que puntúan 9,2 en CVSS v4.0. Según el aviso del proyecto, está en riesgo cualquier instalación que atienda peticiones web, como PHP-FPM, Apache con mod_php o LiteSpeed.

Un plugin de seguridad o una regla de cortafuegos dentro del CMS no sirve de nada. Según BleepingComputer, los ataques empezaron antes de las correcciones y el NCSC británico pidió parchear o desconectar los sistemas.

Primeras 48 horas: cinco preguntas para actualizar la versión de PHP

Alguien debe averiguar qué versión corre, y tu hosting o tu agencia debe cambiarla. Pregunta con precisión: «estamos en ello» no es un número de versión.

Cinco preguntas para enviar hoy

1. ¿Qué versión de PHP sirve la web en producción? No basta con la etiqueta del panel de control.
2. ¿Es 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior? Las distribuciones Linux suelen aplicar el parche sin cambiar el número, así que el registro de cambios del paquete debe citar los dos CVE.
3. ¿Se reiniciaron los procesos? PHP-FPM y Apache mantienen el código antiguo hasta entonces.
4. ¿Dónde más corre PHP? Copias de pruebas, microsites, imágenes Docker.
5. ¿Quién lo confirma por escrito y a qué hora?

Una buena respuesta indica el servidor, la versión exacta, la hora del reinicio y cómo se comprobó. Así vas a comprobar la versión de PHP sin fiarte de una captura.

Medidas temporales y lo que no sustituyen

El aviso enumera ajustes que reducen la superficie de ataque. Son un puente de horas, no de semanas: solo la actualización de PHP cierra los dos fallos. El análisis de Sansec recoge la misma lista para tiendas que aún no pueden parchear.

• Pon session.upload_progress.enabled=0 en php.ini o en el pool de PHP-FPM y reinicia los procesos; ini_set() y .user.ini no sirven.
• Fija memory_limit=-1 con php_admin_value y mantén un post_max_size bajo, por ejemplo 8M si no hay subidas.
• Si la web no tiene formularios con archivos, bloquea multipart/form-data en el servidor web. Prueba antes el pago, porque algunos formularios lo usan.

Cloudflare u otro WAF solo cubre el tráfico que pasa por él, y el modo mantenimiento de WordPress no ayuda: PHP procesa la petición antes que el CMS. Si hay que apagar la web, devuelve un código 503 desde el servidor web o la CDN.

Qué revisar tras la actualización de PHP: pedidos, pagos y formularios

Un salto dentro de la misma rama, como de 8.3.35 a 8.3.36, suele pasar desapercibido. Pasar de 7.4 a una rama con soporte puede romper plugins y temas antiguos, y un equipo de desarrollo WordPress puede arreglarlo sin rehacer la web. Tras la actualización de PHP haz siempre la misma prueba corta, primero en un entorno de pruebas:

• haz un pedido de prueba con cada método de pago y devuélvelo;
• comprueba los correos de pedido y de cambio de contraseña;
• envía el formulario de contacto con un archivo;
• lee el registro de errores de PHP y busca archivos PHP nuevos en las carpetas de subida.

Si ves señales de intrusión con datos de clientes, el RGPD exige avisar a la AEPD en 72 horas; un plan de continuidad del negocio online acorta ese trance.

Versión de PHP obsoleta como riesgo de negocio: calendario de soporte

Las fechas de fin de cada rama se conocen con años de antelación, así que el fin de soporte de PHP 8.2 el 31 de diciembre de 2026 no es sorpresa sino una tarea con dueño. La página oficial de versiones compatibles muestra estos plazos de seguridad a 22 de octubre de 2026:

Rama de PHP	Correcciones de seguridad hasta	Qué significa para ti
8.5	31/12/2029	La más nueva; revisa los plugins
8.4	31/12/2028	Opción razonable para la mayoría
8.3	31/12/2027	Segura hoy; planifica el salto para 2027
8.2	31/12/2026	Quedan dos meses; muévete este trimestre
8.1 y anteriores	Terminado	Sin parches oficiales; migrar o pagar soporte

Planifica el próximo salto como una renovación

Anota la fecha de fin en un calendario compartido, con aviso seis meses antes, y pide al hosting actualizar la versión de PHP cada año, con copia de pruebas y vuelta atrás.

Protocolo de actualizaciones urgentes: quién decide, en cuántas horas y cómo se confirma

PHP2Shell demostró que entre la noticia y los primeros ataques pasan horas. Un protocolo de una página convierte un titular alarmante en trabajo rutinario. Acuérdalo con el responsable de los servidores y, si externalizas la operación, con quien presta servicios DevOps para empresas. Las cifras son un ejemplo.

• Responsables: una persona tuya y otra del proveedor.
• Disparador: aviso crítico del fabricante o noticia de ataques en curso.
• Plazos: decisión en 4 horas laborables, parche o medida temporal en 24 horas.
• Prueba: servidor, versión, hora de reinicio y pruebas en un mensaje.

Lo básico restante lo cubre nuestra lista de 10 medidas de seguridad web. La versión del informe debe venir del correo del hosting: una actualización sin reinicio de PHP no cuenta. Escríbelo una vez y el equipo podrá actualizar PHP en horas, no en días.

Qué incluir en el contrato con el hosting o el proveedor

Unas cláusulas cortas evitan discusiones.

• La web corre solo en una rama de PHP con correcciones de seguridad.
• Las correcciones críticas se instalan en las horas pactadas, con confirmación escrita.
• El proveedor avisa seis meses antes del fin de soporte de la rama y se ofrece a actualizar tu versión de PHP.

Si prefieres un solo equipo para la auditoría, el protocolo y la migración, puedes encargarnos todo como paquete. El mantenimiento de servidores con tiempos de respuesta fijos sirve igual para WordPress, Magento o desarrollos a medida.