PHP 8.1 sin soporte significa que, desde el 31 de diciembre de 2025, ningún fallo de seguridad que se descubra en ese motor se corrige ya. Muchas webs con WordPress, PrestaShop o desarrollos a medida siguen ejecutándose sobre esa versión sin que nadie del equipo lo haya notado, porque por fuera la web sigue funcionando igual. El problema no se ve en el navegador: se ve cuando alguien explota una vulnerabilidad que ya nadie va a parchear. Si gestionas la web de una empresa, conviene saber qué versión corre tu hosting antes de que lo averigüe otra persona.
El fin de soporte de PHP 8.1 en cifras
PHP publica una versión nueva cada año y sostiene cada una con un ciclo de dos fases: dos años de soporte activo, con correcciones de errores y de seguridad, y otros dos de soporte de seguridad, solo para fallos críticos. PHP 8.1 salió en noviembre de 2021, entró en la fase de seguridad en noviembre de 2023 y agotó ese plazo el 31 de diciembre de 2025. En la tabla oficial de versiones soportadas de PHP.net ya no aparece: solo quedan 8.2, 8.3, 8.4 y 8.5.
Fin de soporte (EOL): el momento en que el equipo que mantiene un software deja de publicar parches, incluidos los de seguridad. A partir de ahí, cualquier fallo que se descubra queda sin corregir de forma permanente para esa versión.
Eso no significa que el sitio deje de cargar. PHP 8.1 sigue ejecutando código con normalidad, y ahí está el riesgo: nada avisa de que una versión se ha quedado sin soporte salvo que alguien lo compruebe a propósito. Los paneles de hosting compartido, en particular, tardan meses en forzar el salto de versión a sus clientes.
Calendario de soporte de cada versión de PHP
Antes de decidir a qué versión migrar conviene ver cuánto margen da cada una. Esta es la tabla oficial que publica PHP.net:
| Versión | Soporte activo hasta | Soporte de seguridad hasta |
|---|---|---|
| PHP 8.2 | 31 dic 2024 | 31 dic 2026 |
| PHP 8.3 | 31 dic 2025 | 31 dic 2027 |
| PHP 8.4 | 31 dic 2026 | 31 dic 2028 |
| PHP 8.5 | 31 dic 2027 | 31 dic 2029 |
PHP 8.2 ya solo recibe parches críticos: si el hosting ofrece 8.3 o 8.4 como salto, es la opción con más recorrido antes de repetir esta migración. WordPress recomienda en sus propios requisitos mínimos subir directamente a 8.3, y la mayoría de plugins de pago con soporte activo, como WooCommerce, Elementor Pro o Yoast, ya lo certifican como versión de referencia.
Riesgos de seguridad de una web con PHP desactualizado
Una versión sin soporte no es un problema teórico: es la puerta que buscan los ataques automatizados. Sin parches, cualquier vulnerabilidad que se descubra en el propio PHP, o en las extensiones que dependen de él, queda abierta de forma indefinida. No hace falta que el ataque sea dirigido: los escáneres recorren millones de dominios buscando exactamente esa combinación, y conviene programar una auditoría web técnica que revise qué componentes siguen sin parchear.
Ataques automatizados que explotan versiones sin parches
El informe State of WordPress Security 2026, de Patchstack, mide el tiempo real entre que se publica una vulnerabilidad y el primer intento de explotación: la mediana está en cinco horas, y una de cada cinco vulnerabilidades graves se explota en menos de seis. El 45% se ataca dentro de las primeras 24 horas. Eso deja fuera de juego cualquier plan de “ya lo actualizaré la semana que viene”: en una web con PHP 8.1, cada componente sin parchear lleva meses expuesto, no horas. El dato relevante para una empresa no es solo si le va a tocar, sino cuánto tiempo lleva ya expuesta antes de que le toque.
Cómo comprobar la versión de PHP de tu web
La forma más rápida, sin tocar el servidor, es desde el propio WordPress: en Herramientas → Salud del sitio → Información aparece la versión de PHP activa junto al resto de datos del servidor. En PrestaShop está en Parámetros avanzados → Información. Si el proyecto es a medida, basta con revisar el panel del hosting o pedir al proveedor la versión configurada por defecto para el dominio.
- Comprobar que la versión que aparece coincide con la que el hosting anuncia como «recomendada»: muchos paneles dejan la antigua activa aunque ofrezcan una nueva por defecto para los dominios recién creados.
- Anotar también la versión de las extensiones críticas (OPcache, GD, intl): un salto de versión de PHP puede desactivarlas si el hosting no las recompila.
- Guardar una copia de seguridad completa antes de tocar nada, con opción de revertir en un clic si algo falla.
Compatibilidad de plugins y temas al actualizar
El salto de versión no rompe WordPress en sí: rompe el código de terceros que asumía funciones ya retiradas de PHP. Antes de forzar la actualización en producción conviene probarla en un entorno de pruebas con los mismos plugins activos; quien prefiera delegarlo, el servicio de mantenimiento de WordPress incluye justamente esa prueba de compatibilidad en staging antes de tocar producción.
Qué falla con Elementor y WooCommerce al saltar de versión
Los constructores visuales y los plugins de pago son los que más incidencias generan porque acumulan dependencias de librerías externas. Elementor exige PHP 7.4 como mínimo, pero para 2026 recomienda 8.2 o superior como base de producción; pese a eso, algunos de sus addons de terceros siguen llamando a funciones marcadas como obsoletas desde PHP 8.1 y lanzan avisos visibles en pantalla si el hosting los muestra. WooCommerce recomienda 8.1 o superior, pero algunas pasarelas de pago antiguas dejan de responder si detectan una versión que no reconocen todavía. La recomendación práctica es actualizar plugins y tema a su última versión antes de tocar PHP, no al revés: así el propio autor ya ha corregido lo que rompía con la versión nueva.
Preguntas frecuentes sobre PHP 8.1 sin soporte
¿Qué pasa si no actualizo PHP en mi web?
La web sigue funcionando con normalidad, pero cualquier vulnerabilidad que se descubra en PHP 8.1 a partir de ahora no se corrige nunca. Con el tiempo aumenta la probabilidad de que un escáner automatizado la detecte, sobre todo si el hosting no añade por su cuenta una capa de protección adicional.
¿Cuánto cuesta actualizar PHP en una web ya en producción?
Depende de cuántos plugins o librerías de terceros use el proyecto, pero una migración de una web estándar de WordPress con revisión de compatibilidad y pruebas en staging suele resolverse en pocas horas de trabajo técnico, no en días; si prefieres delegarlo, un servicio de seguridad informática puede encargarse de la migración completa.
¿Puedo actualizar PHP sin perder el diseño de Elementor?
Sí: el salto de versión de PHP no toca la base de datos ni el HTML guardado, así que el diseño no se pierde. El riesgo está en los addons de terceros con funciones obsoletas; probarlos antes en un entorno de pruebas evita que un aviso de PHP se cuele en la portada.
Fuente: PHP.net – Supported Versions