--- title: "Actualización crítica de seguridad de PHP: revise su versión y pregunte a su proveedor de hosting" description: "Revise su versión de PHP en Herramientas > Salud del sitio > Información > Servidor y pregunte a su hosting si ya instaló la corrección del 21 de octubre de 2026." url: "https://webleveling.com/es/blog/actualizacion-critica-de-seguridad-php-que-hacer/" lang: "es" published: "2026-10-21" modified: "2026-10-21" author: "Cal Hewitt" tags: ["website-security","wordpress","website-maintenance"] image: "https://webleveling.com/og/blog-php-critical-security-update-what-to-do.jpg" alternates: en: "https://webleveling.com/blog/php-critical-security-update-what-to-do.md" --- # Actualización crítica de seguridad de PHP: revise su versión y pregunte a su proveedor de hosting Revise su versión de PHP en Herramientas > Salud del sitio > Información > Servidor y pregunte a su hosting si ya instaló la corrección del 21 de octubre de 2026. ![Una laptop cerrada, una libreta en blanco y un disco externo pequeño, ordenados sobre un estante de rack de servidores.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-security-update-featured.jpg) La actualización crítica de seguridad de PHP publicada el 21 de octubre de 2026 es una corrección de PHP en el servidor web, así que WordPress no necesita ninguna actualización para ella. Su trabajo de esta noche son dos pasos: leer la versión de PHP en Tools > Site Health > Info > Server (Herramientas > Salud del sitio > Información > Servidor) y luego preguntarle a su proveedor de hosting si la publicación del 21 de octubre está aplicada a su sitio. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Un sitio con un número más bajo en una de esas ramas es motivo para pedirle al proveedor la actualización. Las distribuciones de Linux numeran sus paquetes a su manera, así que la respuesta por escrito de su proveedor es la que define el caso. Los sitios con PHP 8.1 o una versión anterior necesitan un paso más grande, porque el proyecto de PHP ya no publica actualizaciones de seguridad para esas versiones. Si ese es el caso de su sitio, planifique una actualización a una versión con soporte, con una copia de seguridad a la mano y una copia de prueba antes. **Puntos clave** **La corrección vive en el servidor** PHP corrigió CVE-2026-109618 y CVE-2026-109619 el 21 de octubre de 2026, y [WordPress.org indica](https://es.wordpress.org/2026/10/21/actualizacion-critica-de-seguridad/) que no se requiere ni está prevista ninguna actualización de WordPress. **Versiones corregidas** PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 incluyen la corrección; PHP 8.1 y las anteriores no reciben actualizaciones de seguridad del proyecto de PHP. **Revisión de diez minutos** Tools > Site Health > Info > Server (Herramientas > Salud del sitio > Información > Servidor) muestra su versión de PHP, y una sola pregunta por escrito a su proveedor muestra si la corrección está instalada. **Los ajustes no son una corrección** Los ajustes provisionales del aviso reducen la exposición en ciertas rutas, y solo la actualización es completa. **Señales que conviene reportar** Errores por límite de memoria o errores HTTP 500 repetidos después de solicitudes extrañas, cookies PHPSESSID demasiado grandes y reinicios inexplicables de los workers de PHP justifican una revisión de posible compromiso. ## La solución es una actualización de PHP en el servidor, y WordPress no necesita ninguna El 21 de octubre de 2026, el proyecto de PHP publicó un [aviso de seguridad](https://www.php.net/archive/2026.php#2026-10-21-5) que corrige dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin iniciar sesión. La primera, [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), tiene que ver con la forma en que PHP maneja quedarse sin memoria mientras lee una solicitud. Puede dejar datos a medio construir que la limpieza posterior trata como válidos, lo que corrompe la memoria. La segunda, [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), tiene que ver con un estado de solicitud sobrante que sigue en uso después de liberar su memoria. Una solicitud posterior que atiende el mismo worker puede entonces usar ese estado obsoleto. Use los dos números CVE al escribir a su proveedor o a su desarrollador, porque nombran exactamente lo que cambió. PHP dice que las instalaciones que atienden solicitudes web están en riesgo, y nombra a PHP-FPM, Apache mod\_php, php-cgi, FrankenPHP y LiteSpeed. Califica a mod\_php como el de mayor riesgo, porque el exploit demostrado puede activarse antes de que se ejecute cualquiera de su código de aplicación. Un manejador (handler) es cualquiera de estos que ejecuta PHP para su sitio. Versiones corregidas de PHP y lo que significa cada rama | Su rama de PHP | Versión corregida | En qué situación está | | --- | --- | --- | | 8.5 | 8.5.12 | Con soporte del proyecto de PHP | | 8.4 | 8.4.27 | Con soporte del proyecto de PHP | | 8.3 | 8.3.36 | Con soporte del proyecto de PHP | | 8.2 | 8.2.35 | Con soporte; el soporte de seguridad termina el 31 de diciembre de 2026 | | 8.1 y anteriores | Ninguna del proyecto de PHP | Pregunte a su proveedor de hosting por un backport del proveedor del sistema, y luego planifique una actualización | La [página de versiones con soporte](https://www.php.net/supported-versions.php) enumera de la 8.2 a la 8.5 como versiones con soporte el 21 de octubre. Este es un problema de PHP, no de un plugin, así que una actualización de plugin no puede cambiarlo. Para las advertencias de plugins, [cómo revisar los plugins de WordPress en busca de actualizaciones de seguridad urgentes](https://webleveling.com/es/blog/revisar-plugins-de-wordpress-actualizaciones-de-seguridad/) cubre otra rutina. ![Una laptop cerrada junto a una libreta en blanco y un lápiz afilado sobre un escritorio de madera gastado.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-update-version-notepad.jpg) Un número de versión anotado en una libreta es lo primero que querrá ver su proveedor de hosting. ## La empresa de seguridad Wiz descubrió las fallas, y el riesgo es una toma de control sin iniciar sesión La empresa de seguridad Wiz descubrió las vulnerabilidades con ayuda de modelos de IA y las reportó al equipo de seguridad de PHP el 24 de agosto de 2026. El parche y la divulgación pública llegaron el 21 de octubre. En su [análisis](https://www.wiz.io/blog/php2shell-php-rce), Wiz llamó PHP2Shell a las fallas, y [NCSC-NL](https://github.com/NCSC-NL/php2shell) también usa esa etiqueta. El proyecto de PHP mismo las identifica por su número CVE. En palabras simples, el primer riesgo es una toma de control sin iniciar sesión. Wiz demostró ejecución remota de código en los contenedores más recientes de WordPress, Drupal y Joomla, y dice que la falla está en el propio PHP, así que incluso una aplicación sencilla en una versión afectada puede quedar expuesta. Wiz califica la gravedad hasta 9.2 en la escala CVSS. El segundo riesgo es más silencioso. Wiz dice que un atacante también podría leer memoria del proceso de PHP, y esa memoria puede contener contraseñas, tokens y claves de API. NCSC-NL dijo el 21 de octubre que no tenía indicios de explotación activa. Ese estado puede cambiar, por eso lo que debe guiar sus acciones es la actualización, no el titular. [BBC News informó](https://www.bbc.com/news/articles/cmly0lg3w5x2o) el 21 de octubre que había sitios fuera de línea en todo el mundo, y nombró al gobierno finlandés, al consejo municipal de Edimburgo y a la propia BBC como entidades que habían retirado páginas. Varias agencias de ciberseguridad instaron a las organizaciones que no pudieran parchear a tiempo a considerar bajar sus sitios. Ese consejo está dirigido a servidores que no se pueden actualizar con rapidez, y su primer paso sigue siendo la revisión de la versión. ## Dos minutos en su panel le dicen qué versión de PHP usa La versión y el manejador son los dos datos que necesita su proveedor. En WordPress, [Site Health (Salud del sitio)](https://wordpress.org/documentation/article/site-health-screen/) muestra ambos en la pestaña Info (Información), y WordPress.org apunta a la misma pantalla o a su panel de hosting. 1. Inicie sesión en el panel de WordPress. 2. Abra Tools > Site Health (Herramientas > Salud del sitio). 3. Seleccione la pestaña Info (Información) y despliegue Server (Servidor). 4. Anote la versión de PHP, la línea del servidor web y cualquier detalle del manejador o SAPI de PHP que aparezca. 5. Compare la versión con 8.5.12, 8.4.27, 8.3.36 u 8.2.35. En un hosting con cPanel, [MultiPHP Manager](https://docs.cpanel.net/cpanel/software/multiphp-manager-for-cpanel/) enumera la versión de PHP para cada dominio y muestra si PHP-FPM está habilitado. Un proveedor de hosting puede limitar qué versiones aparecen ahí. Si usa una página \`phpinfo()\` para obtener la misma respuesta, bórrela justo después, porque expone detalles del servidor a cualquiera que la encuentre. Un número por debajo de la versión corregida de su rama es motivo para pedir la actualización. Un número igual o superior no prueba que el paquete correcto esté corriendo para su dominio, porque un segundo pool de PHP o un manejador distinto puede seguir con una compilación antigua. Esa brecha es la que cierra la respuesta por escrito de su proveedor. ## Una respuesta por escrito de su proveedor define si la corrección está instalada Quién aplica la actualización depende de dónde esté el sitio. En hosting compartido o administrado, el proveedor normalmente se encarga del paquete del servidor. En un VPS, el dueño o el administrador aplica el paquete del sistema operativo, y el [aviso USN-8948-1 de Ubuntu](https://ubuntu.com/security/notices/USN-8948-1) dice que una actualización estándar del sistema instala la corrección en las versiones de Ubuntu con soporte. La documentación de los proveedores muestra cómo funcionan en general las actualizaciones de versión. [SiteGround dice](https://www.siteground.com/kb/what-is-managed-php) que Managed PHP actualiza periódicamente la versión predeterminada de PHP, y que los sitios con una versión administrada manualmente no se actualizan solos. [Kinsta dice](https://kinsta.com/docs/wordpress-hosting/php/wordpress-restart-update-php/) que las actualizaciones automáticas de PHP vienen activadas por defecto y ocurren cuando una versión llega al fin de su vida útil. Solo su proveedor puede responder si la publicación del 21 de octubre está hoy en su servidor, así que pregúntele. Envíele al proveedor esto, palabra por palabra: \> Por favor, confirme si la publicación de seguridad de PHP del 21 de octubre de 2026, que corrige CVE-2026-109618 y CVE-2026-109619, está instalada para mi dominio. Por favor, indíqueme la versión activa de PHP, el PHP handler (manejador de PHP), la package version (versión del paquete), si PHP-FPM o mod\_php está en uso, y si necesito tomar alguna medida. WordPress.org señala que su proveedor de hosting ya puede estar actualizando PHP y agregando reglas de firewall para aplicaciones web, y que debe consultar con el proveedor y actualizar lo antes posible si hace falta. Una respuesta que diga solo «nos tomamos la seguridad en serio» no contesta las preguntas. Si su proveedor no puede dar una respuesta específica, [elegir hosting web para una pequeña empresa](https://webleveling.com/es/blog/alojamiento-web-barato-para-un-pequeno-negocio/) explica qué buscar en un proveedor que sí pueda. ![Un sobre cerrado en blanco y un bolígrafo junto a una laptop cerrada sobre un escritorio de madera ordenado.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-host-question-envelope.jpg) Una pregunta corta y por escrito a su proveedor de hosting aclara más que una hora de búsqueda. ## PHP 8.1 o una versión anterior necesita una rama con soporte, probada antes de pasar a producción PHP 8.1 y las versiones anteriores ya no reciben actualizaciones de seguridad del proyecto de PHP. PHP dice que algunas distribuciones y proveedores de soporte a largo plazo pueden aplicar backports de las correcciones, y proporcionó backports mínimos del código fuente para 7.4, 8.0 y 8.1, para quienes compilan desde el código fuente o no tienen ese proveedor. Un backport no es lo mismo que pasar a una rama con soporte. Así que, la primera pregunta para un sitio antiguo es si el paquete instalado contiene las correcciones de ambos CVE, y la segunda es cuándo pasa el sitio a la 8.2 o a una versión más nueva. Como el soporte de seguridad de PHP 8.2 termina el 31 de diciembre de 2026, la 8.3 o la 8.4 dan un margen más largo. Esa fecha también es motivo para agendar el trabajo ahora y no en diciembre. La guía de WordPress sobre [versiones de PHP](https://developer.wordpress.org/advanced-administration/performance/php/) recomienda probar en una copia de prueba (staging), revisar plugins, temas y código personalizado, y mantener una copia de seguridad que pueda restaurar antes de cambiar el sitio en vivo. [El flujo de cambios seguros de Kinsta](https://kinsta.com/docs/wordpress-hosting/using-kinsta/kinsta-make-changes-safely/) sigue el mismo orden. Los formularios, los inicios de sesión, el pago y las reservas son las páginas que debe revisar después del cambio. Si usted administra su propio servidor con una versión anterior, WordPress.org cita al NCSC del Reino Unido y a otras agencias nacionales sobre una opción más: considerar dejar el servidor fuera de línea mientras prepara la actualización. Esa decisión le corresponde a quien administra el servidor. Un sitio en hosting compartido depende de lo que haga su proveedor. ![Un disco externo pequeño y un llavero de llaves de latón sobre un escritorio limpio, junto a una libreta cerrada.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-update-backup-before-upgrade.jpg) Una copia de seguridad que ya restauró una vez es la que vale la pena confiar antes de un cambio de PHP. ## Los ajustes provisionales reducen la exposición, pero no hacen seguro a un sitio El aviso enumera ajustes para quienes no pueden actualizar de inmediato, y PHP los etiqueta como reductores de exposición en rutas particulares, no como una corrección. Para CVE-2026-109618, recomienda configurar \`memory\_limit=-1\` de forma administrativa con \`php\_admin\_value\` en el pool de FPM o en la configuración de Apache, asegurándose de que ningún otro ajuste restaure un límite finito. También recomienda reducir \`post\_max\_size\` y limitar las cargas y la complejidad de las solicitudes. Para CVE-2026-109619, recomienda desactivar \`session.upload\_progress.enabled\` y reiniciar cada worker de PHP. En PHP 8.5 agrega \`fatal\_error\_backtraces=0\`, aplicado de la misma manera. Estos cambios afectan la configuración del servidor, así que los aplica el proveedor o un desarrollador, y el reinicio es parte del trabajo. Trátelos como una medida provisional. Un sitio con estos ajustes y sin actualización sigue sin parchear, y un ajuste aplicado a medias puede parecer terminado mientras deja una ruta abierta. Si está detrás de un CDN o de un proveedor de firewall, revise también su aviso. Wiz dice que Cloudflare, Akamai, AWS, Fastly, Google, Imperva, Microsoft, Vercel y Automattic prepararon guías y mitigaciones para clientes que no pueden parchear de inmediato. Una mitigación del proveedor tampoco sustituye la actualización. ## Tres señales piden una revisión de posible compromiso hasta que el sitio esté parcheado Wiz enumera señales que conviene plantear a su proveedor o desarrollador mientras un sitio siga sin parchear. Son motivo para mirar con más atención, y ninguna prueba por sí sola una intrusión. - Solicitudes multiparte inusuales seguidas de errores de límite de memoria o errores HTTP 500 repetidos - Cookies PHPSESSID inesperadamente grandes o malformadas - Reinicios inexplicables de los workers de PHP Pida al proveedor que busque estas señales en los registros del servidor. Si su sitio no estaba parchado y muestra alguna de ellas, tratar las contraseñas, tokens y claves de API guardados como posiblemente expuestos es una precaución razonable, y pedirle al proveedor o al desarrollador que los rote es un paso sensato. Es una precaución, y no es algo que se exija a todos los dueños. Que un sitio esté en línea no prueba que esté seguro, y que un sitio esté fuera de línea no prueba que hubo un ataque. Si una revisión encuentra algo real, [qué hacer en las primeras 24 horas tras un hackeo](https://webleveling.com/es/blog/hackearon-mi-sitio-web-que-hacer/) explica el orden: conservar la evidencia, aislar el sitio y luego limpiarlo o restaurarlo. Una [auditoría de seguridad de sitios web](https://webleveling.com/es/servicios/auditoria-de-seguridad-web/) es la revisión más larga, para después de la corrección inmediata. ![Un portapapeles con una hoja de lista de verificación en blanco y un bolígrafo sujeto, sobre un estante metálico de rack de servidores.](https://webleveling.com/blog/php-critical-security-update-what-to-do/php-update-patch-checklist.jpg) Una lista de verificación por escrito mantiene al proveedor, al desarrollador y a usted trabajando con la misma lista. ## La ayuda pagada tiene sentido en algunos casos concretos Usted puede hacer la primera revisión por su cuenta, y no necesita un proveedor para ello. La versión, el manejador, un correo y una respuesta por escrito están al alcance de cualquier dueño. La ayuda empieza a valer lo que cobra cuando la respuesta no es simplemente un número de versión. - El proveedor no puede dar una respuesta específica sobre su dominio - El sitio usa PHP 8.1 o una versión anterior - Hay código personalizado o plugins antiguos de por medio - No hay una copia de prueba (staging) para probar - No se puede restaurar una copia de seguridad Si ninguno de estos casos aplica, una respuesta clara del proveedor y una revisión rápida de sus formularios y del proceso de pago pueden ser todo lo que haga falta. Si alguno aplica, un proveedor de mantenimiento puede encontrar cada pool y manejador de PHP, confirmar el origen del paquete, armar una copia de prueba, probar la actualización, reiniciar los workers correctos y dejar por escrito el resultado. Esa es la diferencia entre un parche y un parche documentado, y es lo que debería dejarle un plan de [hosting web](https://webleveling.com/es/servicios/alojamiento-web/) o de mantenimiento. **Cuestionario: Repaso rápido: la actualización de PHP del 21 de octubre** 1. ¿Qué corrige las dos vulnerabilidades críticas de PHP anunciadas el 21 de octubre de 2026? - Una actualización del núcleo de WordPress - Una actualización de seguridad de un plugin - Una versión corregida de PHP instalada en el servidor **(respuesta correcta)** - Un certificado SSL nuevo 2. ¿Dónde se lee la versión de PHP en WordPress? - Settings > General (Ajustes > Generales) - Tools > Site Health > Info > Server (Herramientas > Salud del sitio > Información > Servidor) **(respuesta correcta)** - Appearance > Themes (Apariencia > Temas) - Plugins > Add New (Plugins > Añadir nuevo) 3. Su sitio usa PHP 8.1. ¿Qué dice el proyecto de PHP sobre sus actualizaciones de seguridad? - Sigue recibiéndolas hasta 2027 - Solo las recibe a través de plugins - Ya no las recibe, así que pregunte por un backport del proveedor y planifique una actualización **(respuesta correcta)** - No las necesita ## Preguntas frecuentes sobre la actualización crítica de seguridad de PHP **¿Cuál es la vulnerabilidad más reciente de PHP?** El 21 de octubre de 2026, el proyecto de PHP corrigió dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que pueden permitir la ejecución remota de código sin iniciar sesión. Las correcciones están en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. **¿Quién encontró la vulnerabilidad de PHP?** La empresa de seguridad Wiz la descubrió con ayuda de modelos de IA, la reportó al equipo de seguridad de PHP el 24 de agosto de 2026 y publicó sus hallazgos el 21 de octubre con el nombre PHP2Shell. **¿Cómo actualizo PHP en WordPress?** WordPress no actualiza PHP por sí mismo. En hosting con cPanel, MultiPHP Manager cambia la versión de un dominio, y el panel de su proveedor de hosting normalmente tiene una opción parecida. Para una corrección de seguridad dentro de su rama, pida al proveedor que instale la versión corregida, y pruebe en una copia de prueba antes de cambiar de rama. **¿Cuál es la última versión de PHP?** La rama más nueva que PHP enumera como con soporte es la 8.5, y su versión corregida es la 8.5.12. Las otras versiones corregidas son la 8.4.27, la 8.3.36 y la 8.2.35. **¿Se ha explotado la falla?** NCSC-NL dijo el 21 de octubre que no tenía indicios de explotación activa. Eso puede cambiar, así que parchee ahora en lugar de esperar una confirmación. **Mi proveedor dice que mi hosting es administrado. ¿Estoy cubierto?** Pida una respuesta por escrito que nombre los dos números CVE, su versión de PHP y su manejador. Una descripción general del servicio que hace el proveedor no le dice si esta publicación está instalada para su dominio. ## Qué significa esto para usted La actualización crítica de seguridad de PHP es una corrección del servidor, así que su trabajo es revisar la versión y hacer una pregunta. Lea su versión de PHP en Site Health (Salud del sitio), compárela con las cuatro versiones corregidas y envíe a su proveedor el correo con los dos números CVE. Hasta que el proveedor responda por escrito, esté atento a las tres señales, y pregunte si los ajustes provisionales están aplicados como medida provisional. Una vez confirmada la versión corregida, puede volver a su semana con una respuesta clara archivada, y con alguien a cargo de aplicar las actualizaciones de PHP. Si su sitio usa PHP 8.1 o una versión anterior, el mismo correo sirve para planear la actualización, y pasar a una rama con soporte, probada, es un proyecto que se hace una sola vez. Un sitio que no tiene un servidor PHP que parchear es otra opción; nuestros sitios hechos a mano con Next.js, parte de nuestro trabajo de [diseño web](https://webleveling.com/es/servicios/diseno-web/), se construyen así. Si su proveedor no puede responder, o si prefiere entregar la actualización a alguien que la pruebe y la documente, [Web Leveling](https://webleveling.com/es/) puede encargarse a través de nuestro servicio de [mantenimiento de sitios web](https://webleveling.com/es/servicios/mantenimiento-de-sitios-web/). Trabajamos con pequeñas y medianas empresas en todo el país y en el extranjero. [Envíenos su versión de PHP y los datos de su proveedor de hosting](https://webleveling.com/es/contacto/) y le diremos cómo se ve el siguiente paso. ## Términos Términos de la actualización de PHP en esta publicación Toque un término para ver qué significa. **CVE.** Un identificador público de una falla de seguridad específica, como CVE-2026-109618, que sirve para que los proveedores y los desarrolladores hablen del mismo problema. **Manejador de PHP (PHP handler).** La parte del servidor que ejecuta PHP para su sitio, como PHP-FPM o Apache mod\_php. **mod\_php.** Una forma de ejecutar PHP dentro de Apache; PHP califica este modo como el de mayor riesgo para esta actualización. **Backport.** Una corrección que un proveedor copia a una versión anterior de PHP, lo cual no es lo mismo que actualizar a una versión con soporte. **Copia de prueba (staging).** Una copia privada de su sitio que sirve para probar cambios antes de que salgan en vivo. **Firewall de aplicaciones web (WAF).** Un filtro frente a un sitio que puede bloquear patrones de ataque conocidos mientras se aplica la actualización. **Worker de PHP.** Un proceso que atiende las solicitudes del sitio; los ajustes provisionales piden reiniciar cada uno. - [Vulnerabilidad de Ghostscript y subidas de PDF: revise hoy](https://webleveling.com/es/blog/vulnerabilidad-ghostscript-subidas-pdf-wordpress/): Una vulnerabilidad de Ghostscript puede llegar a los sitios de WordPress por medio de las subidas de PDF. Liste sus formularios de subida, haga una pregunta a su host y actualice WordPress hoy. - [Vulnerabilidades de All in One SEO y Bricksforge: qué actualizar primero](https://webleveling.com/es/blog/vulnerabilidades-de-bricksforge-y-all-in-one-seo/): Bricksforge necesita la 4.0.1 o posterior y All in One SEO la 5.0.2.1 o posterior. Actualice Bricksforge primero y luego revise usuarios, archivos y redirecciones en busca de daños. - [Vulnerabilidad de Ninja Forms: revise su versión y actualice hoy](https://webleveling.com/es/blog/vulnerabilidad-ninja-forms-wordpress/): Vulnerabilidad de Ninja Forms: abra Plugins, lea su versión, saque una copia de seguridad y actualice. Vea qué versión corrige cada fallo y el complemento File Uploads.