---
title: "Las fallas de PHP ya se explotan: qué deben revisar las empresas con su hosting"
description: CISA confirma la explotación de dos fallas críticas de PHP. Qué deben verificar las empresas con su hosting y cuáles son las versiones corregidas.
---

[En clave inbound | Goat blog de Titular](https://www.titular.com/blog)

# [Las fallas de PHP ya se explotan: qué deben revisar las empresas con su hosting](https://www.titular.com/blog/las-fallas-de-php-ya-se-explotan-qué-deben-revisar-las-empresas-con-su-hosting)

 Escrito por [titular.com](https://www.titular.com/blog/author/titular-com) | 28/10/26, 11:00

## Claves del artículo

- CISA incorporó el 26 de octubre dos vulnerabilidades críticas de PHP a su catálogo de fallas con explotación conocida.
- Identificadas como **CVE-2026-109618** y **CVE-2026-109619**, pueden permitir la ejecución remota de código sin autenticación en sistemas vulnerables.
- El equipo de PHP publicó correcciones el 21 de octubre para las ramas 8.2, 8.3, 8.4 y 8.5. Las empresas deben confirmar que su proveedor aplicó el parche al entorno que atiende su sitio.
- La actualización de PHP no reemplaza la revisión de posibles indicios de compromiso previos a la instalación del parche.

Dos vulnerabilidades críticas de **PHP**, el lenguaje que utilizan numerosos sitios web y aplicaciones, ya figuran en el catálogo de fallas explotadas de la Agencia de Ciberseguridad y Seguridad de la Infraestructura de Estados Unidos, CISA. La incorporación, realizada el **26 de octubre**, cambia el contexto de la alerta: las correcciones existen desde la semana pasada, pero la explotación ya fue observada fuera de un entorno de prueba.

La novedad afecta a empresas que dependen de sitios comerciales, tiendas en línea o blogs que ejecutan versiones vulnerables de PHP. La prioridad es confirmar con el equipo técnico o el proveedor de hosting si el intérprete está corregido y revisar si hubo actividad sospechosa durante el período de exposición.

## De una alerta crítica a la explotación conocida

Las fallas, conocidas en conjunto como **PHP2Shell**, están identificadas como **CVE-2026-109618** y **CVE-2026-109619**. Ambas pueden permitir que un atacante ejecute código de forma remota sin iniciar sesión, aunque la posibilidad de explotación depende de las condiciones del sistema.

El [Centro Canadiense de Ciberseguridad](https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619) confirmó que CISA incorporó las dos fallas a su catálogo el 26 de octubre y señaló que existen informes públicos de explotación activa. La inclusión no significa que todos los sitios con PHP hayan sido comprometidos ni identifica por sí sola a las víctimas.

La primera vulnerabilidad involucra un error en el manejo de memoria cuando PHP procesa una solicitud. La segunda afecta a información interna que puede permanecer disponible después de que la memoria correspondiente dejó de ser válida. En ambos casos, el problema se encuentra en el funcionamiento de PHP y no necesariamente en el código de una aplicación concreta.

El [equipo de seguridad de PHP](https://www.php.net/archive/2026.php#2026-10-21-5) advirtió que están expuestas las instalaciones que atienden solicitudes web, incluidas las que usan PHP-FPM, Apache con mod\_php, php-cgi, FrankenPHP y LiteSpeed. Identificó el mayor riesgo en **mod\_php**, donde existe una explotación demostrada que puede activarse antes de que se ejecute el código de la aplicación.

## Qué versiones corrigen las fallas

El 21 de octubre, PHP publicó las siguientes versiones con correcciones para las dos vulnerabilidades:

- **PHP 8.5.12**
- **PHP 8.4.27**
- **PHP 8.3.36**
- **PHP 8.2.35**

El equipo oficial recomendó actualizar de inmediato. Para instalaciones administradas mediante distribuciones de Linux u otros proveedores, también puede existir un paquete con la corrección incorporada por el fabricante, aun cuando la numeración visible no coincida exactamente con la versión publicada por PHP. En esos casos, la confirmación debe provenir del proveedor.

Las ramas **PHP 8.1 y anteriores** ya no reciben actualizaciones del proyecto PHP. Algunos proveedores ofrecen parches adaptados para versiones antiguas; si no existe una corrección verificable, será necesario migrar a una versión compatible.

La distinción es relevante para empresas que utilizan gestores de contenido. **Actualizar WordPress, sus temas o sus plugins no equivale a actualizar PHP**: el gestor y el intérprete son componentes distintos, aunque trabajen juntos. Como explicamos en nuestra [nota anterior sobre las fallas críticas de PHP](https://www.titular.com/blog/fallas-cr%C3%ADticas-en-php-qu%C3%A9-ocurre-y-por-qu%C3%A9-hubspot-queda-fuera-del-riesgo), los sitios alojados nativamente en HubSpot utilizan una arquitectura diferente y no presentan la misma vía de exposición, pero una web externa conectada a HubSpot puede necesitar igualmente una revisión de PHP.

## Qué conviene confirmar con el proveedor de hosting

Para una empresa que no administra directamente su servidor, el primer dato útil es saber **quién se ocupa de PHP** y qué versión atiende efectivamente las solicitudes del sitio. Una respuesta que solo indique que el gestor de contenidos está actualizado no alcanza para confirmar que estas fallas están corregidas.

La consulta al proveedor o al equipo responsable puede centrarse en cuatro puntos:

- Si el sitio o sus aplicaciones utilizan PHP y qué versión ejecutan.
- Si se aplicó una versión corregida o un parche equivalente del fabricante para ambas vulnerabilidades.
- Si la corrección está activa en todos los servidores o entornos públicos afectados.
- Si se revisaron registros y otros indicios de actividad sospechosa durante el período en que el sistema estuvo expuesto.

Si no es posible instalar una corrección de inmediato, [CISA recomienda retirar de servicio los sistemas vulnerables](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/42ff5ac) hasta que puedan actualizarse. Las medidas temporales pueden reducir ciertas vías de ataque, pero no sustituyen el parche.

La actualización tampoco borra una intrusión anterior. Por eso, la conversación con el hosting no termina cuando aparece una nueva versión en el panel: también debe establecer qué evidencia conserva el proveedor y quién puede investigar una eventual actividad sospechosa.

[Ver post completo](https://www.titular.com/blog/las-fallas-de-php-ya-se-explotan-qué-deben-revisar-las-empresas-con-su-hosting)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "titular.com"
  },
  "dateModified" : "2026-10-28T11:00:02.052Z",
  "datePublished" : "2026-10-28T11:00:02Z",
  "headline" : "Las fallas de PHP ya se explotan: qué deben revisar las empresas con su hosting",
  "image" : {
    "@type" : "ImageObject",
    "height" : 941,
    "url" : "https://www.titular.com/hubfs/exec-64681269-71b3-4d1d-b443-7564ecb12e92.png",
    "width" : 1672
  },
  "mainEntityOfPage" : "https://www.titular.com/blog/las-fallas-de-php-ya-se-explotan-qué-deben-revisar-las-empresas-con-su-hosting",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "En clave inbound"
  }
}
```