¿WordPress en PHP 7.4, 8.0 u 8.1? La corrección de PHP2Shell no incluyó tu versión.
El 21 de octubre de 2026 el proyecto PHP publicó las correcciones de PHP2Shell, pero solo para PHP 8.2 a 8.5. Las ramas anteriores ya no tienen soporte: no reciben versión oficial, ni ahora ni en el próximo aviso. Eso todavía incluye a una parte grande de los sitios WordPress. Aquí están tus opciones reales, cómo actualizar sin romper nada y cómo revisar si alguien entró antes.
"Solo actualiza PHP" no sirve cuando tu versión ya no tiene actualizaciones
Para los sitios en PHP 8.2 o superior, PHP2Shell (CVE-2026-109618 y CVE-2026-109619) fue una actualización de rutina. Para los sitios en PHP 7.4, 8.0 u 8.1, el proyecto PHP solo publicó parches a nivel de código fuente. Que tu sitio haya recibido la corrección depende de tu hosting o de tu proveedor de Linux.
No es un caso raro. Un análisis de las estadísticas públicas de WordPress.org del 22 de octubre de 2026 encontró que cerca del 36 % de los sitios WordPress que reportan a WordPress.org seguían en PHP 8.1 o anterior. La cifra solo cuenta los sitios que se conectan a WordPress.org, así que tómala como una estimación, no como un censo.
Y PHP2Shell no será el último aviso: cada futura versión de seguridad de PHP también dejará por fuera estas ramas.
- En WordPress: Herramientas → Salud del sitio → Información → Servidor muestra la versión de PHP.
- En el panel de tu hosting (cPanel, hPanel, Plesk): busca "Versión de PHP" o "Configuración de PHP".
- Algunos hostings instalan versiones corregidas sin cambiar el número de versión. Si ves 7.4, 8.0 u 8.1, pregúntale a tu hosting si tu PHP incluye las correcciones del 21 de octubre.
Tres salidas, y solo una dura
Estado de las correcciones de los proveedores según lo reportado el 25 de octubre de 2026. Cambia rápido, así que confírmalo con tu hosting o proveedor.
| Opción | Qué es | El problema |
|---|---|---|
| Parche del hosting o de la distribución | Tu hosting o tu proveedor de Linux recompiló el PHP viejo con la corrección. Se reportó para algunos casos: cPanel EasyApache 4, alt-php de CloudLinux, Red Hat y PHP 8.1 de Ubuntu 22.04. | La cobertura varía según la versión y el proveedor. Es una solución temporal: sigues en una rama que PHP ya no mantiene. |
| Soporte extendido pagado | Parches comerciales de largo plazo para PHP viejo, como Ubuntu Pro, Freexian ELTS o TuxCare. | Un costo anual por seguir en código viejo. Sirve sobre todo cuando la actualización está realmente bloqueada por un tiempo. |
| Actualizar a PHP 8.3 u 8.4 | Pasar el sitio a una rama con soporte, que recibe todas las correcciones futuras del propio PHP. | Temas y plugins viejos pueden necesitar actualizaciones o reemplazos. Ese es el trabajo, y por eso se hace primero en una copia. |
No elijas PHP 8.2 como destino. Solo recibe correcciones de seguridad hasta el 31 de diciembre de 2026, así que tendrías que repetir todo en dos meses. WordPress 7.1 funciona con todas las versiones de PHP de la 7.4 a la 8.5 y recomienda 8.3 o superior.
Un problema relacionado, publicado el 23 de octubre (CVE-2026-115560), todavía no tiene corrección, y no habrá una para las ramas sin soporte. La recomendación temporal de PHP aplica a todos los servidores:
session.upload_progress.enabled = 0Configúralo en php.ini o en el pool de PHP-FPM y reinicia PHP. En hosting compartido, pídeselo a tu proveedor.
Cómo pasar a PHP 8.3 u 8.4 sin romper el sitio
Es el mismo proceso que seguimos nosotros. Puedes hacerlo tú; el orden es lo que lo hace seguro.
- Haz un respaldo completo y prueba la restauraciónArchivos y base de datos, guardados fuera del servidor. Un respaldo que nunca restauraste es una esperanza, no un plan.
- Crea una copia de pruebas (staging)La mayoría de los hostings la ofrece con un clic. Todos los cambios siguientes se hacen ahí primero, nunca en el sitio en vivo.
- Actualiza WordPress, el tema y los plugins en stagingLas versiones viejas son la causa habitual de que una actualización de PHP rompa el sitio. WordPress 7.1 necesita al menos PHP 7.4, así que el núcleo casi nunca es el problema.
- Identifica las piezas abandonadasPlugins o temas sin actualizaciones en años, o retirados del directorio, son el riesgo real. Planea su reemplazo antes de cambiar PHP.
- Pasa staging a PHP 8.3 u 8.4 y activa el registroActiva el registro de depuración de WordPress (sin mostrar errores en pantalla) y vigila errores fatales y avisos de funciones obsoletas.
- Prueba lo que te da ingresosFormularios de contacto, carrito y pagos, inicios de sesión, búsqueda, reservas o áreas de miembros, y el envío de correos. Recórrelos como lo haría un cliente.
- Cambia producción en una hora tranquilaRepite el cambio en el sitio en vivo con un respaldo nuevo y un paso de reversión claro, y vuelve a probar lo mismo.
- Vigílalo durante 48 horasRevisa el registro de errores y que formularios y pedidos sigan llegando con normalidad. Después agenda la próxima revisión en vez de esperar el próximo aviso.
El parche cierra la puerta. No revisa si alguien ya entró.
Amazon reportó intentos de explotación desde el 17 de octubre, cuatro días antes de que la corrección fuera pública. Las empresas de seguridad registraron millones de intentos y, al 23 de octubre, no se había confirmado públicamente ninguna intrusión exitosa. Si un sitio tuvo PHP sin corregir después del 17 de octubre, una revisión corta es un seguro barato:
- Cuentas de administrador nuevasRevisa Usuarios → Administradores y busca a alguien que no reconozcas.
- Archivos PHP donde no deberían estarCualquier archivo .php dentro de wp-content/uploads es una señal de alerta. Busca también archivos modificados hace poco que tú no tocaste.
- Tareas programadas que no creasteCron jobs desconocidos en el panel del hosting o eventos programados de WordPress que no reconoces.
- Errores extraños en los registrosRáfagas de errores "Allowed memory size" o procesos de PHP que fallan y se reinician sin causa clara.
Un resultado limpio no prueba que el servidor esté limpio. Si encuentras algo, saca el sitio de línea sin borrarlo, guarda los registros, cambia todas las contraseñas y claves que usa el sitio (base de datos, salts de WordPress, claves de API) y restaura un respaldo anterior al 17 de octubre. Si pudieron quedar expuestos datos personales, revisa tus obligaciones de notificación.
Todo el plan en dos páginas
Un PDF para imprimir con todas las revisiones de esta guía: qué PHP usas, las tres opciones, los pasos de actualización y la revisión de intrusión. Marca las casillas a medida que avanzas, o pásaselo a quien administra tu sitio.
Aquí está tu checklist.
Descargar el PDF (2 páginas) →
¿Quieres una segunda opinión? Pide una revisión de exposición gratis y te decimos qué PHP usa tu sitio y qué implicaría actualizarlo.
No pudimos enviarlo.
Revisa tu correo e inténtalo de nuevo, o escríbenos a hola@wordprex.com.
¿Prefieres no hacerlo tú?
Actualizamos sitios WordPress que siguen en PHP sin soporte con exactamente el plan de arriba: respaldo primero, todo probado en una copia de staging, reversión lista y un reporte escrito de lo que cambió.
Cada sitio es distinto, así que no adivinamos. Primero viene la revisión de exposición gratis y luego recibes una cotización fija antes de empezar cualquier trabajo. Después, Managed Protection mantiene al día PHP, WordPress y los plugins para que el próximo aviso no te afecte.
- Un respaldo antes de cada cambio
- Trabajo en staging, no en tu sitio en vivo
- Cotización fija antes de empezar
- Un reporte claro al terminar
- Conservas todos tus accesos y archivos. Sin ataduras
Respuestas rápidas
¿Tengo que actualizar WordPress para corregir PHP2Shell?
No. PHP2Shell es una falla del propio PHP, no de WordPress. La corrección es una versión de PHP corregida. Mantener WordPress, el tema y los plugins al día sigue siendo importante, porque es lo que permite pasar a una versión de PHP con soporte.
Mi hosting dice que corrigió PHP2Shell. ¿Mi sitio en PHP 7.4 ya está seguro?
Seguro frente a PHP2Shell, muy probablemente, si tu hosting instaló una versión corregida. Pero PHP 7.4, 8.0 y 8.1 ya no reciben correcciones oficiales, así que con el próximo aviso de seguridad de PHP vuelve la misma carrera. El parche del hosting da tiempo; no reemplaza la actualización.
¿A qué versión de PHP debo actualizar?
A PHP 8.3 u 8.4 para la mayoría de los sitios WordPress. WordPress recomienda PHP 8.3 o superior, y PHP 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026.
¿Afecta a los sitios en WordPress.com o en un hosting administrado?
Automattic informó que los sitios en WordPress.com, WordPress VIP, WP Cloud y Pressable ya estaban protegidos, y varios hostings administrados grandes aplicaron mitigaciones en menos de un día. Si estás en otro hosting, no lo des por hecho: pregunta, o pide una revisión gratis.