Falla crítica en PHP (php2shell): qué significa para tu sitio WordPress y cómo solucionarla

¿Qué pasó con PHP y por qué es noticia en todo el mundo?

Se descubrieron dos fallas graves en el núcleo de PHP, el lenguaje de programación que usa la mayoría de los sitios web. El 20 de octubre de 2026, el equipo de seguridad de PHP anunció una versión de seguridad crítica para el día siguiente; según Cloudflare, los detalles se filtraron antes de la fecha oficial, y el 21 de octubre el proyecto publicó las versiones corregidas con una recomendación inusualmente directa: actualizar de inmediato.

Las fallas las reportaron investigadores de Calif, Wiz, OpenAI y Quarkslab, según Cloudflare; Calif y Wiz explican que usaron modelos de inteligencia artificial para encontrarlas. La reacción fue global: el Centro Canadiense de Ciberseguridad advirtió que algunos sitios y servicios en línea pueden quedar temporalmente fuera de servicio mientras se aplican los parches.

Las autoridades también se movieron rápido. La Comisión Europea, ENISA (Agencia de la Unión Europea para la Ciberseguridad), CERT-EU (equipo de respuesta a emergencias informáticas de las instituciones de la UE) y Europol firmaron una declaración conjunta que pide identificar las aplicaciones en PHP, coordinarse con los proveedores de hosting y aplicar las actualizaciones, empezando por los sistemas expuestos a internet. En Estados Unidos, la CISA (Agencia de Ciberseguridad y Seguridad de las Infraestructuras) pidió parchear de inmediato y desconectar los sistemas que no puedan actualizarse o que sigan en PHP 8.1 o anteriores, y la NSA (Agencia de Seguridad Nacional) también recomendó desconectar los sitios que no puedan actualizarse.

La magnitud, en cifras

• PHP es el lenguaje de servidor del 69,3 % de los sitios web cuyo lenguaje de servidor se conoce, según W3Techs (23 de octubre de 2026).
• WordPress, que está escrito en PHP, mueve el 39,6 % de todos los sitios web del mundo (W3Techs).
• Uno de cada tres sitios en PHP todavía usa las versiones 7 (26,9 %) o 5 (7,7 %) (W3Techs), ramas que ya no tienen soporte oficial.

¿Por qué la falla de PHP afecta a WordPress si no está en WordPress?

Afecta porque WordPress funciona sobre PHP: cada vez que alguien abre tu página, el servidor usa PHP para armarla. Piénsalo como una casa: WordPress, tu tema y tus plugins son la construcción, y PHP es el cimiento. Puedes tener la casa impecable, con todo actualizado, y aun así estar en riesgo si el cimiento tiene una grieta.

Esa es la gran diferencia con los incidentes habituales, que suelen estar en un plugin. Aquí la corrección no aparece en el escritorio de WordPress: depende de quién administra el servidor. Si tienes un hosting compartido o administrado, lo hace tu proveedor; si tienes un servidor propio (VPS, servidor privado virtual, o nube), lo hace tu equipo técnico.

Las dos vulnerabilidades de php2shell, en lenguaje sencillo

Ambas fallas están en la forma en que PHP maneja la memoria cuando algo sale mal durante una petición web. Así las describe el aviso oficial de PHP:

El proyecto PHP aclara que están en riesgo todas las instalaciones que atienden peticiones web: PHP-FPM (FastCGI Process Manager), Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Considera que el riesgo es mayor con mod_php y validó una de las rutas de ataque también en PHP-FPM, así que ningún tipo de servidor queda por fuera. Un atacante que aproveche las fallas podría ejecutar código con los permisos del proceso web del servidor, sin necesidad de iniciar sesión. Los detalles técnicos están en los avisos de GitHub GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp.

¿Mi sitio WordPress está en riesgo? Cómo comprobarlo en dos minutos

Para saberlo, compara la versión de PHP de tu sitio con la tabla de versiones corregidas. Sigue estos pasos:

1. Entra al escritorio de WordPress con un usuario administrador.
2. Ve a Herramientas > Salud del sitio y abre la pestaña Información.
3. Despliega la sección Servidor y busca la línea «Versión de PHP».
4. Compara el número completo con esta tabla:

Ten en cuenta dos detalles. El primero: mira el número completo, no solo la rama; un sitio en PHP 8.3.35 está en una rama con soporte y aun así es vulnerable. El segundo: muchos proveedores y distribuciones de Linux aplican el parche sobre su propia versión (lo que se llama backport), así que el número puede no cambiar. En ese caso, pide a tu proveedor que te confirme por escrito que su versión incluye la corrección de ambas fallas.

Si administras varios sitios, revisa cada uno: en un mismo hosting, dominios distintos pueden usar versiones de PHP distintas.

Cómo solucionar php2shell en WordPress: plan de acción en 7 pasos

La solución definitiva es actualizar PHP en el servidor; los demás pasos sirven para hacerlo sin romper nada y para confirmar que nadie entró antes.

1. Haz un inventario de tus sitios y de quién administra cada servidor

Anota todos los sitios de la empresa: el principal, las tiendas, las landing pages, los entornos de prueba y esos micrositios viejos que nadie recuerda. Al lado de cada uno, escribe quién administra el servidor y cómo contactarlo. ENISA recomienda además revisar productos de terceros que traen PHP por dentro aunque no lo parezca; el Centro Nacional de Ciberseguridad de Países Bajos (NCSC-NL) mantiene una lista pública de software afectado.

2. Saca una copia de seguridad completa antes de tocar nada

Respalda archivos y base de datos, guarda la copia fuera del servidor y comprueba que se puede restaurar. Una actualización de PHP puede dejar al descubierto incompatibilidades de plugins antiguos, y la copia es tu red de seguridad.

3. Actualiza PHP en el servidor

Si tienes hosting compartido o administrado: revisa el panel (cPanel, Plesk u otro) para ver la versión disponible o abre un ticket. Puedes usar este mensaje:

«Hola. Mi sitio [dominio] funciona con WordPress. ¿Pueden confirmarme por escrito que la versión de PHP que lo atiende ya incluye los parches de CVE-2026-109618 y CVE-2026-109619 publicados el 21 de octubre de 2026 (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o posterior, o una versión con backport equivalente), que reiniciaron todos los procesos de PHP y que la opción session.upload_progress.enabled quedó desactivada en php.ini o en el pool de PHP-FPM, como recomienda PHP desde el 21 de octubre y reiteró el 23? Gracias».

Si tienes un servidor propio o en la nube: instala los paquetes corregidos de tu distribución o proveedor y reinicia todos los procesos de PHP (PHP-FPM, Apache o el que uses), porque los procesos que siguen vivos mantienen el código viejo. Si trabajas con contenedores, reconstruye las imágenes. Según el SANS Internet Storm Center, la mayoría de los sitios no usa PHP compilado desde php.net, sino los paquetes de su distribución, y casi con certeza será más rápido esperar la actualización de esa distribución.

4. Si usas PHP 8.1 o una versión anterior, migra a una con soporte

El proyecto PHP ya no actualiza las ramas 8.1 y anteriores. Por la gravedad del caso publicó correcciones mínimas en código fuente para 7.4, 8.0 y 8.1, pensadas para quien compila PHP o no tiene un proveedor de soporte extendido (LTS); para 7.3 y versiones anteriores, el proyecto no publicó corrección. Algunas distribuciones y proveedores LTS ofrecen sus propios parches para ramas antiguas: pide confirmación por escrito, pero planea la migración igual. Para un sitio WordPress, el camino es migrar: WordPress recomienda PHP 8.3 o superior y advierte que las versiones sin soporte pueden exponer el sitio. Evita quedarte en 8.2, porque su soporte termina el 31 de diciembre de 2026 y tendrías que repetir el trabajo en dos meses.

Haz la migración primero en un entorno de prueba: plugins o temas abandonados pueden fallar con PHP moderno. Si tu sitio depende de muchos de ellos, quizás convenga un rediseño sobre una base actual en lugar de seguir parchando; en nuestra guía sobre cuánto cuesta una página web explicamos qué define ese presupuesto.

5. Si no puedes actualizar hoy: aísla el sitio o, como mínimo, aplica medidas temporales

Si no puedes actualizar de inmediato, la recomendación de ENISA, la CISA y la NSA es aislar el sitio de internet hasta parchearlo. Aislar significa bloquear el acceso público desde el servidor, el firewall o el proveedor. Un plugin de «modo mantenimiento» no sirve para esto, porque PHP sigue procesando cada petición.

Si tampoco puedes aislarlo, estas medidas, tomadas del aviso oficial de PHP, reducen la exposición a rutas de ataque concretas mientras actualizas, pero no hacen seguro un servidor sin parchear. Son para tu equipo técnico o tu proveedor:

• session.upload_progress.enabled=0 en php.ini, en el pool de PHP-FPM o en la configuración del servidor, y reiniciar todos los procesos. No sirve ponerla con ini_set(), con un plugin de WordPress ni en un archivo .user.ini, porque llegan tarde: la opción debe aplicarse antes de que PHP procese la petición. Mantenla desactivada incluso después de actualizar: PHP ya la recomendaba el 21 de octubre y el 23 publicó un aviso informativo (CVE-2026-115560) sobre una falla que solo aparece con una configuración inusual y que, según Cloudflare, alcanza también a las versiones ya corregidas. PHP recomienda mantenerla desactivada hasta su próxima versión regular.
• Bajar post_max_size a 8M si el sitio no recibe archivos, o a 32M si los recibe, con upload_max_filesize siempre por debajo; y limitar el tamaño de las peticiones también en el servidor web o el proxy.
• En PHP 8.5, fatal_error_backtraces=0 y reiniciar los procesos.
• Ocultar los errores no sirve: el proyecto PHP aclara que desactivar su visualización no protege.
• Esta es una selección: el aviso oficial y los avisos de GitHub traen más medidas para tu equipo técnico (ajustes del límite de memoria, límites en el servidor web o el proxy, contenedores). Si se limita la memoria desde el sistema operativo, que sea con contenedores o cgroups, nunca con RLIMIT_AS ni RLIMIT_DATA, que pueden provocar la falla.

Un WAF (firewall de aplicaciones web) ayuda como freno mientras actualizas. Cloudflare activó reglas contra php2shell desde las 03:02 UTC (tiempo universal coordinado) del 21 de octubre, incluso para su plan gratuito; en los planes de pago conviene confirmar que el conjunto de reglas administrado esté en modo de bloqueo. Ten en cuenta que un WAF solo filtra el tráfico que pasa por él, que Cloudflare observó a los atacantes cambiar sus técnicas para evadir las reglas y que su regla para el aviso del 23 de octubre no cubre los servidores que cambiaron el nombre de session.upload_progress.name. La propia empresa pide parchear aunque el WAF esté activo.

6. Verifica que el parche quedó aplicado

Vuelve a Herramientas > Salud del sitio > Información > Servidor y confirma la versión. Si tu proveedor o tu distribución aplicó un backport, el número puede seguir igual: en ese caso vale su confirmación por escrito o la versión del paquete. Si no hubo backport y sigue apareciendo la versión anterior, lo más probable es que los procesos de PHP no se hayan reiniciado o que el sitio use otro manejador de PHP. Después prueba lo que sostiene tu negocio: el inicio de sesión, los formularios, el carrito y el pago en WooCommerce, y las tareas programadas. Y recuerda que session.upload_progress.enabled=0 sigue recomendado hasta la próxima versión de PHP, aunque ya hayas actualizado.

7. Revisa si hubo intrusión

Como los detalles se filtraron antes del parche y Cloudflare observó tráfico de ataque contra sus clientes, actualizar no basta: hay que mirar hacia atrás. Busca archivos .php dentro de wp-content/uploads, usuarios administradores que no reconozcas, cambios recientes en .htaccess o wp-config.php, tareas programadas extrañas y conexiones salientes inusuales. Revisa también el informe de problemas de seguridad de Google Search Console. Si algo no cuadra, cambia todas las contraseñas (WordPress, hosting, base de datos y SFTP, protocolo seguro de transferencia de archivos), regenera las claves de seguridad de wp-config.php y restaura desde una copia limpia. Si prefieres no hacerlo solo, nuestro equipo sigue un protocolo de respuesta a incidentes para estos casos.

Lo que no soluciona php2shell: errores comunes

• Actualizar WordPress, el tema o los plugins: es necesario siempre, pero no toca PHP.
• Instalar un plugin de seguridad: los plugins funcionan encima de PHP; no pueden corregir el lenguaje.
• Activar el modo mantenimiento: PHP sigue procesando las peticiones aunque el visitante vea un aviso.
• Ocultar los errores: no reduce el riesgo, según el propio proyecto PHP.
• Confiar solo en el firewall: es un freno temporal; los atacantes adaptan sus técnicas.

La lección para las empresas: el mantenimiento web dejó de ser opcional

La lección es que la seguridad de un sitio ya no se resuelve con revisiones esporádicas. En julio de 2026, una cadena de fallas en el núcleo de WordPress (CVE-2026-63030 y CVE-2026-60137), que la CISA incluyó en su catálogo de vulnerabilidades explotadas, obligó a actualizar de urgencia; en octubre, php2shell golpeó la capa de abajo. Y como la inteligencia artificial ya se usa para encontrar vulnerabilidades (Calif y Wiz cuentan que así hallaron estas), conviene asumir que entre el aviso y los primeros ataques pueden pasar apenas horas.

Por eso vale la pena que toda empresa pueda responder cuatro preguntas: ¿quién actualiza el PHP de nuestro servidor?, ¿en cuánto tiempo?, ¿tenemos copias de seguridad probadas? y ¿quién recibe las alertas de seguridad un domingo por la noche? Si alguna respuesta es «no sé», hace falta un responsable.

En DataLab ofrecemos un plan de soporte y mantenimiento web con actualizaciones probadas en un entorno de pruebas, copias de seguridad fuera del servidor, firewall, monitoreo, hosting administrado en AWS (Amazon Web Services) y tiempos de respuesta pactados en un SLA (acuerdo de nivel de servicio). Y si tu sitio está atado a versiones antiguas, nuestro equipo de diseño de páginas web puede reconstruirlo sobre una base moderna, rápida y segura.

¿No sabes quién actualiza el PHP de tu sitio? Escríbenos y revisamos tu caso: versión de PHP, hosting, copias de seguridad y señales de intrusión. Revisemos tu sitio.

Historial de actualizaciones: 23 de octubre de 2026, publicación inicial.

Aviso: este artículo es informativo y la situación evoluciona. Ante cualquier duda, sigue siempre los avisos oficiales del proyecto PHP y de las autoridades de ciberseguridad de tu país.