Vulnerabilidad crítica en PHP: qué hacer con tu sitio

El 21 de octubre de 2026, el equipo de PHP publicó actualizaciones de emergencia para dos vulnerabilidades críticas que permiten ejecutar código en el servidor sin necesidad de contraseña. Si tu página web, tu tienda en WordPress o WooCommerce o tu sistema interno corre en PHP, actualiza hoy a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según tu rama. Si usas PHP 8.1 o anterior, no habrá versión oficial corregida: la solución de fondo es migrar.

En este artículo te explicamos en lenguaje claro qué pasó, cómo saber si te afecta y qué hacer según tu caso.

¿Qué pasó con PHP?

PHP es el lenguaje con el que funciona buena parte de la web: WordPress, WooCommerce, Magento, Moodle, Laravel y miles de sistemas administrativos hechos a la medida en México. Corre en el servidor, así que una falla en PHP afecta a todo lo que está construido encima, sin importar qué tan bien estén hechos tu sitio o tus plugins.

Lo que confirmó el aviso oficial de PHP:

• Son dos fallas en el núcleo de PHP: CVE-2026-109618, relacionada con el manejo de errores por falta de memoria, y CVE-2026-109619, en la que datos de una petición anterior se reutilizan cuando ya no son válidos.
• Permiten ejecución remota de código (RCE) sin autenticación. Un atacante no necesita usuario ni contraseña: basta con enviar peticiones especialmente preparadas a tu sitio. Con eso podría robar tu base de datos, instalar malware, enviar spam o usar tu servidor para atacar a otros.
• Son de severidad crítica. Las dos tienen 9.2 de 10 en la escala CVSS v4.0. En redes sociales circuló un “10 de 10” antes del aviso, pero la calificación oficial es 9.2, y sigue siendo crítica.
• Ya existe un ataque demostrado. PHP confirma un exploit funcional contra servidores Apache con mod_php, en el que la falla se activa antes de que se ejecute el código de tu aplicación. Los detalles técnicos ya son públicos, así que los ataques automatizados suelen aparecer en días, no en meses.
• El aviso se adelantó. La información se filtró antes de la fecha de divulgación acordada, y PHP publicó los parches antes de lo previsto.

¿A qué versión de PHP tengo que actualizar?

Tu rama de PHP	Versión con el parche	Estado de la rama
PHP 8.5	8.5.12 o posterior	Con soporte
PHP 8.4	8.4.27 o posterior	Con soporte
PHP 8.3	8.3.36 o posterior	Solo parches de seguridad
PHP 8.2	8.2.35 o posterior	Solo parches de seguridad hasta el 31 de diciembre de 2026
PHP 8.1, 8.0, 7.x	Sin versión oficial corregida	Fuera de soporte
PHP 5.x	Sin versión oficial corregida (no se menciona en el aviso)	Fuera de soporte desde 2018

Puedes consultar el estado de cada rama en la tabla de versiones soportadas de PHP.

¿Mi sitio o sistema está en riesgo?

PHP indica que están en riesgo todas las instalaciones de PHP que atienden peticiones web, sin importar cómo se ejecuten: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto es para mod_php, una configuración muy común en hosting compartido y servidores antiguos.

Tu situación	¿Usa PHP?	Riesgo
Página o tienda en WordPress o WooCommerce	Sí	Alto, hasta que actualices PHP
Sistema interno o ERP web hecho en PHP (Laravel, CodeIgniter, PHP “puro”)	Sí	Alto, sobre todo si está expuesto a internet
Moodle, PrestaShop, Magento, Joomla, Drupal	Sí	Alto, hasta que actualices PHP
Sistema en PHP 8.1, 7 o 5	Sí	Crítico: no tendrá versión oficial corregida
Sitio estático (HTML generado, sin panel de administración en el servidor)	No	No te afecta esta falla
Tienda en Shopify, Wix o Squarespace	No lo administras tú	Lo resuelve la plataforma
Sistema en .NET, Node.js, Python o Java	No	No te afecta esta falla

Si no sabes en qué está hecho tu sitio, el indicio más común es que tenga un panel en /wp-admin (WordPress) o que tu hosting tenga cPanel o hPanel. En ese caso, casi seguro usa PHP.

Cómo saber qué versión de PHP tienes

Necesitas la versión completa, con los tres números (por ejemplo, 8.3.36), no solo “PHP 8”.

• En WordPress: entra a Herramientas > Salud del sitio > Información y abre la sección Servidor. Ahí aparece la versión de PHP.
• En cPanel: busca Select PHP Version o MultiPHP Manager.
• En Hostinger: en hPanel, entra a Avanzado > Configuración de PHP.
• En un servidor propio o VPS: tu equipo técnico puede ejecutar php -v en la terminal. Ojo: la versión de la terminal y la que usa el sitio web pueden ser distintas.
• Si no tienes acceso: pídele la versión exacta a tu proveedor de hosting o a quien te desarrolló el sistema. Si nadie sabe responderte, eso ya es un hallazgo importante.

Un consejo: no dejes un archivo phpinfo.php publicado para revisar la versión. Esa página le muestra a cualquiera la configuración de tu servidor. Si lo creaste, bórralo al terminar.

Qué hacer según tu versión de PHP

Si tienes PHP 8.2, 8.3, 8.4 u 8.5

Es el mejor escenario. Actualiza a la versión corregida de tu rama (ver la tabla de arriba).

1. Haz un respaldo completo de archivos y base de datos, y comprueba que se pueda restaurar.
2. Actualiza PHP dentro de la misma rama. Si estás en 8.3, pasa a 8.3.36; subir de rama al mismo tiempo agrega riesgo de incompatibilidades.
3. Confirma la versión después de actualizar, con cualquiera de los métodos de arriba.
4. Revisa que el sitio funcione: formularios, pagos, inicio de sesión y facturación.

En hosting compartido, normalmente el proveedor instala el parche y tú solo confirmas. En un VPS o servidor propio, la actualización la haces tú o tu equipo técnico: si instalas PHP con los paquetes de tu distribución (Ubuntu, Debian, Red Hat y similares), busca las actualizaciones de tu proveedor, que recibieron los parches por adelantado.

Ten presente que PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si estás en esa rama, aplica el parche hoy y programa el salto a 8.4 u 8.5 en los próximos dos meses.

Si tienes PHP 8.1 o 8.0

Estas versiones ya están fuera de soporte y el proyecto PHP no publicará versiones corregidas. Algunas distribuciones y proveedores de soporte extendido ofrecen sus propias correcciones; si contrataste uno, consúltalo. Si no, lo más probable es que tu sitio funcione en PHP 8.3 u 8.4 con pocos ajustes, porque los cambios entre versiones de PHP 8 son moderados.

1. Respalda todo.
2. Prueba el sitio en una copia con PHP 8.4 (muchos hostings permiten crear un entorno de pruebas).
3. Corrige los avisos de compatibilidad y actualiza plugins o librerías.
4. Cambia la versión en producción y verifica.

Si tienes PHP 7.x o PHP 5.x

Es el caso más delicado, y en México es más común de lo que parece: sistemas de inventario, portales de clientes o tiendas que se hicieron hace años y “siguen funcionando”.

No habrá versión oficial corregida para tu versión. Por la gravedad del caso, el equipo de PHP publicó parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1, pero solo sirven si tu equipo compila PHP por su cuenta; en un hosting compartido no tienes esa opción. PHP 5 ni siquiera se menciona en el aviso.

Cambiar la versión en el panel del hosting casi siempre rompe el sitio, porque PHP 8 eliminó funciones que los sistemas viejos usan. Mientras planeas la migración, reduce el riesgo:

• Quita el sistema de internet si no necesita estar ahí. Un sistema interno puede quedar accesible solo desde la oficina o mediante VPN.
• Ponlo detrás de un firewall de aplicaciones (WAF), como el de Cloudflare o el de tu proveedor, y limita el tamaño de las peticiones.
• Limita y cambia contraseñas de los paneles de administración y de la base de datos.
• Separa la base de datos para que no comparta servidor con otros sitios.
• Ten respaldos fuera del servidor, diarios y probados.
• Vigila los registros (logs) en busca de procesos o archivos nuevos que nadie creó.

Ninguna de estas medidas corrige la falla; solo te dan tiempo. La solución es migrar el sistema a PHP 8 o reescribir los módulos críticos. Lo explicamos paso a paso en cómo modernizar un sistema legado sin detener tu operación.

Si no puedes actualizar hoy: medidas temporales

Para servidores propios o VPS, el aviso de PHP incluye medidas que reducen la exposición, pero no hacen seguro el servidor. Solo la actualización corrige el problema. Pásale esta lista a tu equipo técnico:

• Desactivar el progreso de subida de sesión con session.upload_progress.enabled = 0 y reiniciar todos los procesos de PHP. Debe configurarse en php.ini, en el pool de PHP-FPM o en el servidor web; no sirve hacerlo con ini_set() ni con .user.ini.
• En PHP 8.5, poner fatal_error_backtraces = 0 y reiniciar los procesos.
• Quitar el límite de memoria de PHP con memory_limit = -1, configurado de forma que la aplicación no pueda cambiarlo (por ejemplo, con php_admin_value), y poner un límite de memoria por contenedor o cgroup para que un proceso no tumbe el servidor.
• Reducir el tamaño máximo de las peticiones: post_max_size = 8M si el sitio no recibe archivos, o 32M si sí, con upload_max_filesize por debajo de ese valor. Conviene aplicar también límites en el servidor web o el proxy.

Los detalles técnicos completos están en los avisos de seguridad GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp.

Checklist para esta semana

• Hacer la lista de todos tus sitios y sistemas: página principal, tienda, landing pages, portal de clientes, sistemas internos.
• Anotar la versión exacta de PHP de cada uno.
• Respaldar archivos y base de datos, y probar que se puedan restaurar.
• Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 los que estén en PHP 8.2 a 8.5.
• Planear la migración de los que estén en PHP 8.1 o anterior, y mientras tanto aislarlos.
• Confirmar con tu hosting o tu proveedor que la actualización quedó aplicada.
• Cambiar contraseñas de administración si el sitio estuvo expuesto sin parche.

¿Cómo saber si ya me atacaron?

Algunas señales de que un servidor PHP fue comprometido:

• Archivos .php nuevos o modificados que nadie subió, sobre todo en carpetas de imágenes o uploads.
• Usuarios administradores que no reconoces.
• Redirecciones a sitios de apuestas, farmacias o descargas.
• El hosting te avisa de envío masivo de correos o de uso anormal de CPU.
• Google muestra la advertencia “Este sitio puede haber sido hackeado” en los resultados.

Si ves alguna de estas señales, no te limites a actualizar PHP: el atacante puede haber dejado accesos ocultos. Restaura desde un respaldo limpio anterior al incidente, cambia todas las contraseñas y revisa la base de datos.

El problema de fondo: software que nadie mantiene

Esta vulnerabilidad se arregla en minutos en un sitio bien mantenido y se vuelve un proyecto de semanas en uno abandonado. La diferencia no es la falla, sino cómo se construyó y se cuida el software:

• Versiones fuera de soporte. PHP 7.4 dejó de recibir parches en noviembre de 2022. Esta falla es solo la más visible.
• Nadie es responsable. El programador que lo hizo ya no está, el hosting “solo da el servidor” y la empresa asume que alguien más se encarga.
• Demasiados plugins. En WordPress y WooCommerce, cada plugin abandonado puede impedir que actualices PHP. Lo vemos seguido en tiendas que crecieron a base de extensiones; hablamos de ello en cuándo dar el salto de WooCommerce a desarrollo a la medida.
• Sin entorno de pruebas. Si no puedes probar una actualización antes de aplicarla, cada parche se vuelve una apuesta y terminas posponiéndolo.

Mantener actualizado el lenguaje, el framework y el servidor es parte del costo real de tener software, igual que el mantenimiento de un vehículo. Elegir bien la tecnología desde el inicio también ayuda; lo explicamos en cómo elegir el stack tecnológico para tu software.

Cómo te ayuda Tecsolt

En Tecsolt desarrollamos y mantenemos sitios web, tiendas en línea y sistemas a la medida desde 2017. Si no sabes qué versión de PHP tienen tus sistemas o no tienes claro quién debe actualizarlos, te ayudamos a:

• Revisar tus sitios y sistemas, identificar versiones y priorizar los riesgos.
• Actualizar PHP, plugins y librerías con respaldo previo y pruebas.
• Migrar sistemas en PHP 5 o 7 a PHP 8, o modernizarlos por módulos sin detener tu operación.
• Administrar la infraestructura con parches, respaldos automáticos y monitoreo en nube e infraestructura.

Conoce nuestros servicios de diseño y desarrollo web y de software y ERP a la medida, o agenda una reunión para revisar tu caso.

Preguntas frecuentes

¿Qué es la vulnerabilidad crítica de PHP de octubre de 2026?

Son dos fallas en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, que permiten a un atacante ejecutar código en el servidor sin iniciar sesión. El equipo de PHP las calificó con 9.2 de 10 en la escala CVSS v4.0 y las corrigió el 21 de octubre de 2026 en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

¿A qué versión de PHP tengo que actualizar?

Depende de tu rama: PHP 8.5 a la 8.5.12, PHP 8.4 a la 8.4.27, PHP 8.3 a la 8.3.36 y PHP 8.2 a la 8.2.35, o cualquier versión posterior de la misma rama. Si usas PHP 8.1 o anterior, el proyecto PHP ya no publica actualizaciones y lo recomendable es migrar a una rama soportada.

¿Mi página en WordPress está en riesgo?

Sí, si tu servidor ejecuta una versión de PHP anterior a las corregidas. WordPress, WooCommerce y la mayoría de los CMS funcionan sobre PHP, y la falla se puede activar antes de que se ejecute el código de tu sitio, así que tener WordPress y plugins al día no te protege. Revisa la versión en Herramientas > Salud del sitio > Información > Servidor.

¿Cómo sé qué versión de PHP usa mi sitio?

En WordPress, entra a Herramientas > Salud del sitio > Información y abre la sección Servidor. En cPanel busca Select PHP Version o MultiPHP Manager; en Hostinger, Configuración de PHP en hPanel. Si no tienes acceso, pídele a tu proveedor de hosting o a tu programador la versión exacta, incluido el último número.

¿Qué pasa si mi sistema usa PHP 7 o PHP 5?

El proyecto PHP no publicará versiones corregidas para PHP 8.1 ni anteriores. Para 7.4, 8.0 y 8.1 publicó parches mínimos en código fuente, útiles solo si tu equipo compila PHP, y algunos proveedores de soporte extendido ofrecen sus propias correcciones. PHP 5 no se menciona en el aviso. La salida real es migrar a PHP 8.2 o superior y, mientras tanto, aislar el sistema.

¿Mi hosting actualiza PHP automáticamente?

Depende. En hosting compartido el proveedor suele instalar los parches de cada rama, pero tú eliges la rama: si tu sitio está fijado en PHP 7.4, seguirá ahí. En un VPS o servidor propio la actualización es responsabilidad tuya o de tu equipo técnico. Confirma con tu proveedor qué versión exacta quedó instalada.

• #seguridad web
• #PHP
• #WordPress
• #vulnerabilidades
• #sistemas legados