Las vulnerabilidades críticas en PHP anunciadas este 21 de octubre de 2026 merecen una revisión concreta: saber qué sitios de tu empresa usan este lenguaje y quién confirma que recibieron el parche. Si tu web toma reservas, recibe solicitudes o procesa compras, esa respuesta forma parte de la continuidad del negocio.
El equipo de PHP publicó una actualización de emergencia para CVE-2026-109618 y CVE-2026-109619. Ambas pueden permitir ejecución remota de código sin autenticación. Eso significa que, en una instalación vulnerable y bajo las condiciones necesarias, un atacante podría ejecutar instrucciones sin entrar al panel de administración.
Información revisada el 21 de octubre de 2026. Las versiones y el alcance que describimos corresponden a los avisos oficiales disponibles en esa fecha. Al aplicar esta guía después, conviene comprobar también los avisos posteriores del proveedor.
La puntuación mide gravedad técnica; no es el porcentaje de sitios comprometidos ni la probabilidad de que tu empresa haya sufrido un ataque.
La puntuación aparece en las fichas de seguridad de los mantenedores de PHP. Nuestra recomendación es actuar con esa evidencia: identificar exposición, actualizar y comprobar el resultado.
Qué se confirmó y qué significa para tu sitio
La primera falla, CVE-2026-109618, afecta al manejo de errores cuando se agota la memoria. Determinadas solicitudes pueden dejar datos internos en un estado inválido y conducir a ejecución de código. Los investigadores validaron un ataque completo sobre Apache con mod_php, incluso antes de que comience el código de la aplicación.
La segunda, CVE-2026-109619, permite que un proceso conserve referencias a memoria que ya fue liberada. Otra solicitud atendida por ese proceso puede usar ese estado antiguo. La posibilidad de aprovecharlo depende de la configuración y de las operaciones que ejecute la aplicación.
Estos detalles explican por qué cambiar la contraseña del administrador no corrige el problema. También impiden sacar conclusiones mirando solo la apariencia del sitio: una portada que carga normalmente no acredita que el servidor esté actualizado.
La existencia de estas vulnerabilidades exige revisar los sistemas expuestos. Para afirmar que un sitio fue comprometido hace falta evidencia del incidente. Un aviso del proveedor, un error del sitio y una intrusión confirmada son situaciones distintas.
Si recibes una noticia alarmante, guárdala como aviso inicial y pide el boletín técnico correspondiente. El diagnóstico debe identificar el servicio afectado, su versión y el estado de corrección. Compartir un titular en el grupo del equipo no reemplaza esa verificación.
Qué versiones contienen la corrección
El aviso oficial de PHP identifica estas versiones corregidas dentro de las ramas con soporte:
| Rama instalada | Versión corregida publicada el 21-OCT-2026 | Qué confirmar |
|---|---|---|
| PHP 8.2 | 8.2.35 | Que el sitio usa esta corrección o una posterior que la incluya. |
| PHP 8.3 | 8.3.36 | Que el servicio web recibió el paquete corregido. |
| PHP 8.4 | 8.4.27 | Que todos los procesos del sitio usan el código actualizado. |
| PHP 8.5 | 8.5.12 | Que la actualización se aplicó al entorno que atiende las visitas. |
Desliza o usa las flechas ← → para ver todas las columnas.
PHP advierte que las ramas 8.1 y anteriores ya no reciben sus actualizaciones regulares. Algunos proveedores distribuyen correcciones adaptadas a paquetes anteriores, conocidas como backports. Si ese es tu caso, pide el boletín del proveedor que confirme la cobertura de ambas CVE; el número de versión por sí solo puede ser insuficiente para evaluar ese paquete.
Para nosotros, la pregunta útil al hosting es: «¿Qué paquete corregido está atendiendo las solicitudes de este dominio y qué evidencia confirma que cubre ambas vulnerabilidades?». Una respuesta que solo diga «tenemos seguridad avanzada» deja el trabajo pendiente.
Qué pedir al hosting o al responsable técnico
En una empresa pequeña, distintas personas pueden administrar el dominio, la web y el servidor. Durante una alerta, esa distribución se vuelve un problema si todos creen que la actualización le corresponde a otro.
Recomendamos asignar un responsable de cierre y entregarle una pauta breve:
Inventariar los servicios
Revisar el dominio principal, subdominios, tiendas, formularios y aplicaciones antiguas. Identificar cuáles ejecutan PHP.
Confirmar la exposición
Registrar la versión que usa cada servicio web y contrastarla con el aviso del proveedor para ambas CVE.
Aplicar la corrección
Coordinar respaldo, actualización y recarga o reinicio de los procesos según el procedimiento del proveedor.
Probar el negocio
Comprobar navegación y funciones críticas con pruebas controladas: contacto, reservas o compra, según corresponda.
Dejar constancia
Guardar fecha, servicios cubiertos, paquete instalado y resultado de las pruebas. Anotar cualquier excepción con responsable y plazo.
La evidencia puede ser un ticket de soporte o un registro de mantenimiento. Debe relacionar la corrección con tus servicios. Un comunicado general del proveedor es útil, pero conviene confirmar que incluye tu cuenta y los entornos que realmente están operando.
En un hosting compartido, evita cambiar parámetros avanzados copiando instrucciones de redes sociales. Entrega los avisos al soporte y solicita una intervención compatible con las aplicaciones de tu cuenta. Una modificación sin contexto puede interrumpir funciones que el negocio necesita.
Por qué es más complejo de lo que parece
Una empresa puede haber renovado su sitio principal y mantener un sistema anterior en un subdominio. También puede tener una tienda administrada por un proveedor distinto. Revisar únicamente la portada deja esas dependencias fuera del diagnóstico.
Otro error es confundir la versión disponible con la versión en uso. Que el panel ofrezca una actualización no acredita que el dominio la tenga aplicada. Pide verificar el servicio que recibe las visitas, incluidas las configuraciones particulares de cada sitio.
Los avisos técnicos de PHP distinguen condiciones de explotación entre entornos. Por eso, una explicación sobre un servidor diferente al tuyo no sirve como certificado de protección. La evaluación debe considerar tu configuración y las instrucciones del proveedor.
Identificar, actualizar y verificar
Identifica los servicios que usan PHP. Confirma que recibieron la actualización y prueba las funciones del negocio. Cierra la revisión con evidencia del entorno y del resultado.
Los controles temporales también tienen límites. Los mantenedores indican que aplicar una actualización con el parche es la única mitigación completa para estas fallas. Las medidas de configuración reducen determinadas vías de ataque, pero no equivalen a corregir el código vulnerable. Detalle técnico y límites de las mitigaciones.
Si el proveedor necesita tiempo para actualizar, pide un plan escrito: servicios pendientes, medida temporal, limitaciones y hora de la próxima revisión. Esa información permite decidir cómo operar mientras se completa el trabajo.
Cómo revisar el resultado sin perder continuidad
Antes de intervenir, identifica qué acción del visitante genera valor para tu empresa. En una clínica puede ser solicitar una hora. En una tienda, completar una compra. Esa acción tiene que formar parte de la prueba posterior, junto con la revisión técnica.
Coordina las pruebas para evitar cobros reales o notificaciones innecesarias a clientes. Si existe un entorno de pruebas, úsalo para comprobar compatibilidad; después valida también el funcionamiento del entorno publicado. Registra quién hizo la revisión y qué recorrido completó.
Si aparecen señales de acceso no autorizado, recomendamos abrir una investigación separada de la actualización. Actualizar resuelve la vulnerabilidad conocida, pero no demuestra por sí mismo que no haya cambios anteriores. Conserva los registros disponibles y coordina su revisión con el equipo responsable.
Al comunicarte con clientes, informa hechos comprobados: una interrupción, su alcance y los canales alternativos. Evita declarar una filtración o prometer que no ocurrió ninguna sin contar con antecedentes suficientes. El equipo comercial necesita una respuesta consistente con la investigación técnica.
Qué conviene dejar resuelto después de esta alerta
Una vez cerrado el parche, recomendamos conservar un inventario sencillo con cada servicio, su responsable, el proveedor y la fecha de revisión. Incluye los sistemas antiguos aunque tengan pocas visitas. Si ya no cumplen una función, evalúa retirarlos con sus respaldos y dependencias identificados.
La alerta también permite revisar el acuerdo de mantenimiento: quién recibe los avisos, quién aplica correcciones urgentes y cómo se informa el cierre. Si ninguna de esas tareas tiene dueño, la próxima noticia volverá a depender de quién la vea primero.
Para ordenar esa conversación, puedes revisar nuestros criterios de desarrollo web y mantenimiento de la presencia digital. Primero necesitamos entender qué sostiene la operación y qué evidencia falta para decidir la intervención.
Referencias y alcance de la información
Consultamos estas fuentes primarias el 21 de octubre de 2026. Los enlaces dentro del artículo permiten relacionar las afirmaciones técnicas con su respaldo:
- PHP: aviso oficial de seguridad y versiones corregidas. Publicado el 21 de octubre de 2026.
- Mantenedores de PHP: CVE-2026-109618, RCE via OOM corruption. Alcance, severidad y limitaciones de las medidas temporales.
- Mantenedores de PHP: CVE-2026-109619, RCE via stale global state. Condiciones de explotación y diferencias entre configuraciones.
La pauta de coordinación y validación es nuestra recomendación de gestión para empresas. No constituye una auditoría de una cuenta de hosting ni acredita el estado de un sitio particular.
Si en tu empresa nadie puede confirmar qué servicios usan PHP o quién verifica sus actualizaciones, agenda una llamada de diagnóstico. Podemos ayudarte a ordenar las dependencias, definir responsables y convertir esta alerta en un plan de trabajo verificable.