La respuesta breve. La mayoría de las webs pequeñas funcionan con un programa llamado PHP. Piense en él como el motor que va bajo el capó. El 21 de octubre de 2026 se descubrieron dos agujeros graves en ese motor. Esos agujeros permiten que una persona extraña engañe a una web para que ejecute su código, sin llegar a iniciar sesión. Las correcciones salieron el mismo día, pero solo para las versiones que siguen recibiendo atención. Si su web funciona con PHP 8.1 o anterior, los responsables han dejado de corregirlo, así que no hay corrección para su versión. Muchas webs de alojamientos están exactamente en ese punto: construidas hace años, funcionando sin problema y sin que nadie las haya vuelto a mirar desde entonces. Escriba la dirección de su web en la comprobación gratuita que encontrará justo a continuación y en unos segundos sabrá de qué lado de la línea está.
Para esta comprobación no necesita saber ningún número de versión. Escriba la dirección de su web, pulse el botón y en unos segundos tendrá una respuesta clara: si los agujeros de octubre de 2026 afectan a su web y qué hacer al respecto. La comprobación solo mira la información que su web ya muestra a cualquiera que la visita. No se instala nada en su web y no guardamos su dirección.
Su resultado aparecerá aquí.
Algunas webs mantienen oculto su número de versión. Si la suya es una de ellas, la herramienta se lo dirá, y la comprobación de dos minutos de arriba es el recurso alternativo.
Si ya ha encontrado su número de versión, selecciónelo aquí. Verá al momento si sigue recibiendo atención, si la corrección de octubre de 2026 le cubre y qué hacer a continuación.
Elija su versión arriba y su resultado aparecerá aquí.
PHP es el motor que hace funcionar WordPress y la mayoría de las webs de las pequeñas empresas. El 21 de octubre de 2026, el equipo que se ocupa de PHP anunció dos agujeros graves en él. Están registrados con los números de referencia CVE-2026-109618 y CVE-2026-109619, y juntos han recibido el apodo de php2shell. Cada uno tiene una gravedad de 9,2 sobre 10, casi el máximo de la escala. Dicho sin tecnicismos, cualquiera de los dos agujeros puede permitir que una persona extraña envíe un mensaje cuidadosamente preparado a su web y consiga que el ordenador que hay detrás ejecute su código. No necesita contraseña. En el peor caso que describe el propio equipo de PHP, puede ocurrir incluso antes de que el propio código de su web llegue a despertarse.
Las correcciones se publicaron el mismo día, en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El consejo del propio equipo de PHP es rotundo: no existe ninguna solución alternativa que le proteja por completo, y actualizar es la única opción segura.
Dos cosas importan si su web no es nueva. Primero, la corrección solo existe para las versiones que siguen recibiendo atención. El aviso dice sin rodeos que PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del equipo de PHP. Segundo, el equipo hizo algo poco habitual: para quienes construyen PHP ellos mismos desde su código en bruto, publicó también pequeños parches para PHP 7.4, 8.0 y 8.1. Eso da una idea de la gravedad del asunto. Una cuenta de alojamiento normal no recibirá esos parches por sí sola, y por eso importa comprobar qué versión tiene usted.
Cada versión de PHP recibe dos años de atención completa. Después recibe dos años más en los que solo se corrigen los agujeros de seguridad. A partir de ahí llega a lo que los técnicos llaman el fin de vida útil. Dicho de forma sencilla, los responsables han dejado de corregirlo, un poco como un teléfono que ya no recibe actualizaciones. La versión no deja de funcionar. Su web se ve exactamente igual al día siguiente. Simplemente, deja de volverse más segura.
| Versión de PHP | Cómo está en octubre de 2026 | Las correcciones de seguridad se acaban |
|---|---|---|
| 8.5 | Con soporte completo | 31 de diciembre de 2029 |
| 8.4 | Con soporte completo | 31 de diciembre de 2028 |
| 8.3 | Solo correcciones de seguridad | 31 de diciembre de 2027 |
| 8.2 | Solo correcciones de seguridad, y casi sin tiempo | 31 de diciembre de 2026 |
| 8.1 y anteriores, incluido todo PHP 7 | Fin de vida útil: ya nadie lo corrige | Ya se acabaron |
Muchas webs de alojamientos pequeños siguen en PHP 7.4, 8.0 u 8.1. Nadie hizo nada malo. La web se construyó, funcionaba, llegaban reservas y nunca hubo un motivo para volver a abrir el panel de control del alojamiento. Las empresas de alojamiento no siempre le pasan a una versión más reciente por su cuenta. Un salto de versión puede romper una web antigua, y prefieren dejar tranquila una web que funciona antes que romperla en silencio. El resultado es una web que parece estar bien y que lleva años, sin hacer ruido, desde su última corrección de seguridad.
Si su web usa WordPress (la mayoría de las webs de alojamientos lo usan), aquí es donde se esconde el número de versión:
Si su web no usa WordPress, o no puede iniciar sesión:
Ahora compare su número con la tabla de arriba. Con la 8.2, tiene la corrección por ahora, pero el reloj corre: las correcciones para la 8.2 se acaban el 31 de diciembre de 2026. Con la 8.1 o inferior, su versión ya ha pasado el final, y el resto de esta página trata de sus opciones.
Primero, mantengamos la proporción. Una versión antigua no significa que su web haya sido hackeada, y nadie está yendo a por su casa rural por su nombre. El riesgo funciona así. Cuando se anuncia un agujero, los detalles se publican para que cualquiera pueda leerlos. A partir de ahí, son ordenadores los que van buscando webs que todavía tengan ese agujero, automáticamente, día y noche. Una versión antigua significa que cada agujero que se descubra desde ahora quedará abierto en su web para siempre, incluida la pareja de este mes, en la que el atacante ni siquiera necesita contraseña.
Si alguien consigue entrar, los resultados suelen ser aburridos más que dramáticos: sus páginas cambiadas o desviadas a webs de spam, páginas basura escondidas bajo su dirección web, o su cuenta de alojamiento usada para enviar correo no deseado. Esto último puede hacer que su dirección acabe en listas negras, de modo que sus consultas de reserva empiecen a caer en las carpetas de spam de los huéspedes. Y la web de un alojamiento no es solo un folleto. Sus formularios de consulta guardan nombres, fechas y datos de contacto de los huéspedes. Si su sistema de reservas funciona como un complemento, un pequeño añadido dentro de su web, la propia vía de reserva queda detrás del mismo motor. Esa es la parte de su negocio a la que el número de versión está haciendo guardia en silencio.
1. Subir a una versión de PHP más reciente, donde está su web. Es la respuesta adecuada para la mayoría de las webs, y a menudo es gratuita: su proveedor acciona un interruptor y su web sigue funcionando. Le conviene si las piezas con las que está construida su web, su tema y sus complementos (plugins), siguen recibiendo la atención de quienes los hicieron. El único riesgo real es que un complemento escrito para PHP 7 deje de funcionar en PHP 8. Así que hágalo en el orden seguro: primero una copia de seguridad completa, después el cambio, y luego recorra sus páginas y su vía de reserva una a una. Pida a su proveedor que lo haga, o que lo pruebe antes en una copia de prácticas, y acuerde de antemano que le devolverá al punto anterior si algo se rompe. Una actualización cuidadosa que sale mal le cuesta una tarde. Quedarse en una versión sin corregir no cuesta nada hoy y conlleva el riesgo cada día a partir de ahora.
2. Conservar la web y poner las correcciones en el calendario de otra persona. Si la web cumple su función y usted sencillamente no quiere abrir nunca el área de administración, pagar a alguien para que se ocupe de ella es una respuesta justa: mantiene al día por usted WordPress, el tema, los complementos y la versión de PHP, y comprueba la web después. Le conviene a quien tiene una web en buen estado pero su atención está en otra parte. El problema de las versiones rara vez es una cuestión de conocimiento. Es que la tarea no es de nadie. Esta vía le da un responsable.
3. Empezar de nuevo con una web construida a mano. Si la revisión sale mal en todos los niveles, un motor que ya nadie corrige, complementos de los que sus autores se han desentendido, un diseño de antes de que la mayoría de los huéspedes reservara desde el móvil, arreglarlo pieza a pieza puede costar más que empezar de nuevo. Esa es la vía en la que trabajamos nosotros. Construimos a mano su web de reserva directa por un pago único de 1.999 £, con su motor de reservas actual integrado en ella. Como decimos en nuestra página sobre el gestor de canales: en WordPress, herramientas como un motor de reservas suelen llegar como un complemento, y un complemento es una cosa más que actualizar y mantener segura. Una web construida a mano no tiene plantillas ni constructores visuales, y toda la cadena de mantenimiento, WordPress, el tema, los complementos y la versión de PHP, deja sencillamente de ser suya. Consulte nuestra guía de costes de una web para alojamientos para ver cómo se compara la construcción de pago único con los costes continuos de plataformas y mantenimiento.
Si su web usa WordPress, entre en su área de administración y vaya a Herramientas, luego a Salud del sitio y abra la pestaña Información. Despliegue la sección Servidor y allí figura su versión de PHP. Si su web no usa WordPress, entre en el panel de control de su alojamiento y busque Seleccionar versión de PHP o MultiPHP Manager, que muestran la versión asignada a su web. Si ninguna de las dos vías funciona, haga a su proveedor una sola pregunta: ¿qué versión de PHP está usando mi web y sigue recibiendo atención? O use la comprobación gratuita de esta página: escriba la dirección de su web y le dirá si su versión se puede ver desde fuera.
En octubre de 2026, siguen recibiendo atención PHP 8.2, 8.3, 8.4 y 8.5. PHP 8.2 está en su tramo final, solo con correcciones de seguridad, y llega a su fin el 31 de diciembre de 2026. PHP 8.1 y todo lo anterior, incluido todo PHP 7, ya han pasado el final: el equipo de PHP ya no publica correcciones de seguridad para ellos.
No. Una versión antigua no significa que hayan entrado en su web. Significa que, cuando se anuncia un agujero nuevo, no se publica ninguna corrección para su versión por el canal habitual. Los agujeros corregidos el 21 de octubre de 2026 son un ejemplo real: las correcciones salieron para PHP 8.2 a 8.5, mientras que PHP 8.1 y las versiones anteriores no recibieron una publicación regular. Trátelo como una tarea que hay que reservar en la agenda, no como un incendio que deba causarle pánico, y resérvela pronto.
Puede ocurrir, si su tema o sus complementos son antiguos. Un complemento escrito para PHP 7 puede dejar de funcionar en PHP 8, y por eso las actualizaciones deben hacerse primero con una copia de seguridad completa y, si puede, probarse antes en una copia de prácticas. En la práctica, la mayoría de los proveedores accionarán el interruptor por usted y lo devolverán a su sitio si algo se rompe. El riesgo de una actualización cuidadosa es pequeño y de corta duración. El riesgo de quedarse en una versión sin corregir no desaparece.
No. Esas empresas funcionan en sus propios sistemas y las reservas que llegan por ellas siguen como siempre. Lo que funciona sobre su PHP es su propia web: sus páginas, sus formularios de consulta y, si su sistema de reservas es un complemento dentro de su web, su vía de reserva directa. Esa es la parte que merece la pena proteger, porque es la vía por la que los datos de los huéspedes le llegan directamente a usted.
Normalmente, no. Si su web de WordPress cumple por lo demás su función, actualizar PHP y mantener al día WordPress, el tema y los complementos resuelve el problema. Merece la pena pensar en una reconstrucción cuando la web es antigua en todos los niveles: una versión de PHP que ya nadie corrige, complementos que sus autores ya no mantienen y un diseño de antes de que la mayoría de los huéspedes reservara desde el móvil. En ese caso, la reconstrucción se lleva toda la cadena de mantenimiento en lugar de repararla eslabón a eslabón.
Si su comprobación da una versión que sigue recibiendo atención, bien: anote la fecha en la que se acaban sus correcciones, póngase un recordatorio y siga adelante con su alojamiento. Si da una versión antigua, ya conoce las tres rutas y, a grandes rasgos, lo que le cuesta cada una en dinero o en atención. Y si de todos modos a su web ya le tocaba una renovación, una web construida a mano le quita de encima, para siempre, toda la rueda de los parches.
Web construida a mano, 1.999 £ de pago único, 0 % de comisión. Vea primero su propio alojamiento con una demo de 9,90 £.
Probar una demo de 9,90 £¿Preguntas? Llame al +44 7727 811227 (IA 24/7) · WhatsApp (persona) · hello@directbook.uk
Última comprobación: 21 de octubre de 2026. Solo orientación general, no es asesoramiento de seguridad ni jurídico. Fuentes: aviso de seguridad de PHP, «Critical remote code execution vulnerabilities, update now» (php.net, 21 de octubre de 2026); Versiones con soporte de PHP (php.net, consultado el 21 de octubre de 2026); anuncios de publicación de PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12 (php.net, 21 de octubre de 2026); aviso previo de la publicación de seguridad de PHP (php.net, 20 de octubre de 2026).