El 21 de octubre de 2026, el equipo de PHP publicó un aviso de seguridad crítico: dos fallos (CVE-2026-109618 y CVE-2026-109619) que permiten a un desconocido ejecutar código en un servidor sin necesidad de contraseña. La prensa los llama «PHP2Shell». Ese nombre no es oficial, pero lo verás por ahí.
¿Te afecta? Si tu web va con WordPress o WooCommerce, sí, en cuanto el PHP de tu servidor no esté parcheado. Y aquí está lo que más confunde: no lo arregla una actualización de WordPress, ni de WooCommerce, ni de ningún plugin. El fallo está en PHP, que es el motor que hay debajo. WordPress.org lo dice sin rodeos: no se requiere ni se plantea ninguna actualización de WordPress para estos problemas.
Hay intentos de ataque reales. Lo confirman varias empresas de seguridad y INCIBE-CERT (aviso INCIBE-2026-762, importancia «crítica»), que habla de ataques contra servidores PHP antes de que existieran las actualizaciones.
Lo que no hay, a fecha de hoy, son hackeos masivos de WordPress documentados. Wordfence contó más de 74.000 intentos bloqueados y, a 22 de octubre, ningún compromiso confirmado. Otros analistas, como Sansec, opinan que los exploits públicos no funcionan contra una instalación de PHP por defecto. Aun así, ninguna fuente seria da por segura una web con el PHP sin parchear.
Qué versiones están corregidas
PHP publicó el parche el 21 de octubre. Estas son las versiones que lo incluyen:
| Rama de PHP | Versión corregida |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1, 8.0 y 7.4 | Sin versión oficial. PHP ha publicado parches de código fuente («backports») por la gravedad del caso |
| 7.3 y anteriores | Sin corrección del proyecto PHP |
Ojo con lo de «sin versión oficial». Que PHP no saque versión nueva para la 8.1 no significa que tu hosting no pueda protegerte. Ahora lo vemos.
Cómo comprobar tu versión de PHP (y por qué el número puede engañar)
Primero, mira qué tienes:
- Entra en WordPress y ve a Herramientas > Salud del sitio > Información > Servidor. Ahí aparece la «Versión de PHP».
- O abre el panel de tu hosting, normalmente en una sección llamada PHP.
- Desde fuera, con nuestra herramienta gratuita Revisar mi hosting: si tu servidor anuncia su versión de PHP, te la muestra y te dice si es anterior a las corregidas. Ojo: la mayoría de hostings la ocultan, que es lo recomendable, y ningún detector online puede ver la versión si el servidor no la anuncia. En ese caso, usa los pasos 1 o 2.
Ahora viene la trampa. Muchos hostings y distribuciones de Linux aplican el parche sin cambiar el número de versión. Es lo que se llama backport. Una web que muestra 8.5.11, o incluso 8.1.x, puede estar perfectamente corregida. Y al revés: ver un número «moderno» no demuestra nada si el servidor no se ha actualizado ni reiniciado.
Por eso, el número solo no sirve. Tienes dos formas de salir de dudas:
- Mirar la fecha de compilación. GoDaddy y Hostinger explican que, si tu panel enseña la «Build Date» (por ejemplo en PHP Info), debe ser del 21 de octubre de 2026 o posterior. Si es anterior, no está parcheado.
- Preguntárselo al hosting por escrito. Es lo más fiable si no eres técnico. Wordfence propone esta pregunta, traducida casi literal:
¿El PHP que sirve mi web está parcheado frente a CVE-2026-109618 y CVE-2026-109619, y se ha reiniciado PHP?
Lo del reinicio importa: un parche instalado pero con los procesos viejos todavía en marcha no protege.
Si tienes acceso al servidor: el php -v de la terminal puede no coincidir con el PHP que atiende a la web (lo advierten Sucuri y Wordfence).
Qué hacer según tu tipo de hosting
Aquí está la diferencia que más importa y la que menos se explica.
Hosting compartido o gestionado
El proveedor parchea el servidor por ti. Esto es lo que dicen ellos mismos, a 25 de octubre:
- SiteGround: parches aplicados en todos los servidores el 21 de octubre. Dicen que no tienes que hacer nada.
- Hostinger: parche completado el 22 de octubre en todo salvo VPS. Tampoco pide acción, salvo en VPS.
- GoDaddy: WordPress gestionado parcheado el 21 de octubre; hosting web y Windows, el 22. Sin acción, salvo en VPS.
- IONOS: dice que ya instaló las actualizaciones oficiales, sin dar fecha. En versiones gestionadas desde la cuenta no pide acción. En VPS y servidores dedicados, sí, de inmediato.
Si tu proveedor no está en la lista, no lo des por parcheado: no he encontrado un comunicado de todos. Pregúntale con la frase de arriba y guarda la respuesta.
En este caso, cambiar de rama de PHP no es necesario para recibir el parche. El proveedor arregla la que tengas. Otra cosa es que estés en una versión sin soporte; de eso hablamos más abajo.
VPS, servidor dedicado, o Plesk/cPanel propio
Aquí el parche no llega solo. Si tienes un VPS (con IONOS, OVH o quien sea), la responsabilidad es tuya o de quien te lo administre.
Lo que dicen las fuentes:
- Plesk: hay versiones de PHP 8.2 a 8.5 corregidas. Los backports para 7.4 a 8.1 estaban «en pruebas» según su foro, y puede haber cambiado. Actualiza desde Herramientas y configuración > Actualizaciones (la ruta exacta depende de tu versión de Plesk; no la he contrastado con la documentación oficial).
- cPanel/WHM: según Patchstack hay paquetes ea-php corregidos de la 5.2 a la 8.5. El administrador los instala desde EasyApache 4. No he localizado el anuncio oficial de cPanel.
- Después de actualizar: reinicia todos los procesos de PHP.
Si no puedes actualizar hoy, PHP detalla medidas parciales, pero insiste en que solo actualizar es una solución completa. Es terreno de administrador: si no sabes qué es un pool de FPM, que lo haga quien lo sepa.
Y una advertencia: un firewall como Cloudflare o Wordfence ayuda, pero no sustituye al parche. Parte del ataque ocurre antes de que arranque WordPress, y si alguien llega directo al servidor de origen, el WAF no pinta nada.
Cómo actualizar PHP sin romper la web
Hay dos decisiones distintas, y conviene no mezclarlas:
- Parchear ya. Es urgente, y en hosting gestionado lo hace el proveedor.
- Cambiar de rama de PHP (por ejemplo, de 8.1 a 8.4). Es una decisión planificada, con copia y pruebas.
Si necesitas hacer lo segundo, sigue los pasos de WordPress.org:
- Haz una copia de seguridad completa (archivos y base de datos).
- Actualiza WordPress, el tema y los plugins, y comprueba que todo funciona.
- Revisa la compatibilidad con el plugin PHP Compatibility Checker. Ojo: ellos mismos avisan de que no es perfecto y puede pasar cosas por alto.
- Si algún plugin es incompatible, contacta con su desarrollador o busca alternativa.
- Cambia la versión en el panel del hosting.
- Si algo se rompe, vuelve a la versión anterior o restaura la copia.
Si puedes, haz el paso 5 primero en una copia de la web (entorno de pruebas o staging). WordPress.org no lo menciona en esa página, pero es lo que haría yo con una tienda que cobra.
WordPress 7.0 y 7.1 son compatibles con PHP de la 7.4 a la 8.5. El problema casi nunca es el núcleo: son los plugins y temas viejos.
Qué probar después (sobre todo en WooCommerce)
Un error 500 o una página en blanco justo tras el cambio suele indicar un plugin incompatible. Vuelve a la versión anterior y busca cuál es. Si todo carga, revisa:
- Acceso al panel de administración.
- Un pedido de prueba completo: añadir al carrito, checkout y pago con tu pasarela.
- Los emails de pedido y de contacto.
- Formularios y subida de archivos.
- Las tareas programadas (cron) y cualquier conexión con otros servicios (APIs).
- El registro de errores del servidor.
Esta lista sale de las recomendaciones de Sucuri y NEUBOX. El pedido de prueba es la prueba que no te puedes saltar.
El tercer fallo: CVE-2026-115560
El 23 de octubre, PHP publicó un tercer aviso de menor riesgo.
Solo afecta a una combinación poco habitual: una aplicación que configura session.serialize_handler como php_binary o php_serialize, lo cambia a php con ini_set() antes de session_start(), y tiene activo el upload progress. Es improbable que sea tu caso.
La medida temporal que recomienda PHP es poner session.upload_progress.enabled=0 hasta la próxima versión de mantenimiento. A 25 de octubre no existe versión que lo corrija ni ficha en NVD. Si tu hosting es gestionado, es cosa suya; pregúntale si lo ha tenido en cuenta.
Calendario de PHP y qué versión elegir
Esto es lo que dice php.net a 25 de octubre de 2026:
| Rama | Soporte activo hasta | Parches de seguridad hasta | Estado hoy |
|---|---|---|---|
| 8.5 | 31-12-2027 | 31-12-2029 | Soporte activo |
| 8.4 | 31-12-2026 | 31-12-2028 | Soporte activo |
| 8.3 | 31-12-2025 | 31-12-2027 | Solo seguridad |
| 8.2 | 31-12-2024 | 31-12-2026 | Solo seguridad; fin de vida en dos meses |
| 8.1 y anteriores | — | — | Fin de vida |
Mi recomendación, coherente con las fuentes: 8.3 como mínimo (lo que aconseja WordPress.org) y, si tu web lo soporta, 8.4 u 8.5 (lo que aconseja Patchstack). Si estás en 8.2, tienes hasta final de año. Si estás en 8.1 o menos, estás en una rama que ya no recibe parches del proyecto: te está protegiendo solo tu hosting, y conviene salir de ahí con calma, pero pronto. La 8.6 está en fase de candidata (RC) y no es para producción.
Preguntas frecuentes
Tengo todo actualizado. ¿No me basta? No. WordPress, plugins y tema pueden estar al día y la web seguir expuesta si el PHP del servidor no lo está.
¿Tengo que cerrar la web o la tienda? No hace falta con carácter general. Sansec dice expresamente que no es necesario cerrar una tienda. WordPress.org apunta una excepción: si gestionas tu propio servidor con PHP anterior a 8.2 y no puedes parchear, valora desconectarlo mientras preparas la actualización.
¿Me protege mi plugin de seguridad o Cloudflare? Ayudan, pero no sustituyen al parche. Wordfence reconoce que parte del ataque sucede antes de que arranque WordPress. Y desconfía de plugins o snippets «de arreglo» no oficiales: Patchstack los desaconseja.
Estoy en PHP 7.4, 8.0 u 8.1. ¿Estoy desprotegido? Estás en versiones afectadas y sin parche oficial del proyecto. Lo que importa es si tu hosting ha aplicado los backports (SiteGround e Hostinger dicen haberlos aplicado en sus servidores). Pregunta, confirma por escrito y planifica el salto a 8.3 o superior.
¿Cómo sé si ya me han hackeado?
Si tu servidor estuvo sin parchear, revisa: usuarios administradores que no reconozcas, archivos .php dentro de wp-content/uploads, archivos modificados recientemente y avisos de seguridad en Search Console. Wordfence vio ataques que intentaban subir un archivo llamado wp2s.php y leer wp-config.php y .env. Si encuentras algo raro, restaura una copia anterior a los ataques, cambia contraseñas y claves de API, y conserva los registros: Wordfence recomienda guardar copias y logs desde 48 horas antes del 21 de octubre.
Y ahora, qué
Tres cosas, en este orden: averigua si tu hosting es gestionado o si el servidor es tuyo; pregunta por escrito si el PHP está parcheado y reiniciado; y apunta en el calendario que PHP 8.2 caduca el 31 de diciembre.
Si prefieres no ocuparte, en AGENCIA RSE esto entra en el mantenimiento WordPress: revisar qué PHP corre tu web, probar los cambios en una copia y comprobar el checkout después. Pero no hace falta contratar nada para seguir esta guía. Con la frase de Wordfence y el calendario de arriba, puedes resolverlo tú.
Si ves un dato desactualizado, escríbenos y lo corregimos.