# Parche de PHP: ¿quién actualiza tu sitio?

Source: https://somosgentedigital.com/es-co/blog/parche-php-quien-actualiza

Date: 2026-10-21

El 21 de octubre de 2026 PHP corrigió dos fallas críticas. Tres preguntas de dueño: quién vigila, quién actualiza y qué hacer con versiones viejas.

![Tripulación Aura de Somos Gente Digital: un zorro y un gato astronautas junto a una estrella](https://images.prismic.io/somosgentedigital-alfa/oQ3wRW6-MD6PhX8q_sgd-cover-canonico-aura-16x9.png?auto=format,compress)

Si tu sitio, tu tienda o el portal donde entran tus clientes funciona con WordPress, Magento, Drupal o un desarrollo propio en PHP, esta semana hay una pregunta que vale más que cualquier detalle técnico: ¿quién en tu empresa, o en tu proveedor, se enteró del aviso y actualizó el sitio ese mismo día?

Si la respuesta honesta es «supongo que el hosting», no tienes un problema técnico. Tienes un riesgo sin dueño. Y eso sí se puede resolver.

## Qué pasó, al 21 de octubre de 2026

PHP es el lenguaje con el que funcionan muchísimos sitios web, tiendas en línea y portales. El 21 de octubre de 2026 el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos fallas críticas (CVE-2026-109618 y CVE-2026-109619), calificadas con 9.2 en la escala CVSS v4.0. En palabras simples: permiten que alguien, sin usuario ni contraseña, ejecute sus propias instrucciones en el servidor donde vive tu sitio. [El propio proyecto PHP lo dice sin rodeos](https://www.php.net/archive/2026.php): no hay mitigaciones completas y actualizar es la única opción segura.

Los detalles se filtraron el 20 de octubre y PHP adelantó la publicación: salió hacia las 8:30 a. m., hora de Colombia, del 21 de octubre, antes de lo programado, [según el CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018). Las dos fallas ya se conocen como «PHP2Shell», el nombre que usan Cloudflare y Sansec.

La reacción fue rápida. [Cloudflare reportó intentos de ataque tempranos](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) y activó reglas en su firewall como protección provisional, que no reemplaza la actualización. En Países Bajos, el gobierno [apagó temporalmente por precaución varios sitios oficiales](https://www.rijksoverheid.nl/actueel/nieuws/2026/10/21/aantal-websites-rijksoverheid-preventief-offline-na-kwetsbaarheden-php), entre ellos Overheid.nl, MijnOverheid y DigiD. Y, [según Sansec](https://sansec.io/research/php2shell), los investigadores de Calif demostraron que alguien sin usuario ni contraseña puede ejecutar código en Magento, WordPress y Drupal.

No te lo contamos para asustarte. Te lo contamos porque un gobierno decidió que valía la pena saber exactamente qué tenía expuesto y actuar el mismo día. Esa es la pregunta que vale la pena hacerse en cualquier empresa.

## Actualizar WordPress, Magento o Drupal no lo arregla

Aquí está la confusión más común. Tu sitio tiene dos capas: la plataforma que ves (WordPress, Magento, Drupal) y el motor que la hace funcionar por debajo, que es PHP. La falla está en el motor. Por eso actualizar la plataforma o sus plugins, aunque sea buena práctica, no cierra este hueco.

El equipo de seguridad de Drupal lo dejó claro [en su aviso](https://www.drupal.org/psa-2026-10-20): actualizar PHP es la única mitigación completa, y la seguridad del hosting es responsabilidad del dueño del sitio. Es decir, tuya, aunque la delegues.

## Quién actualiza depende de dónde está alojado tu sitio

- Hosting administrado o compartido: normalmente lo hace el proveedor. Pero ese día la respuesta fue desigual: algunos publicaron paquetes corregidos ese mismo día (por ejemplo, cPanel, Debian y Ubuntu, porque las distribuciones recibieron los parches por adelantado), y de algunos proveedores no encontramos comunicados públicos.
- Servidor propio, VPS o nube contratada directamente: nadie lo actualiza si no lo pides. El servidor no se cuida solo, y el proveedor de la máquina normalmente no toca lo que corre adentro.

Si no sabes en cuál de los dos casos estás, ese ya es el primer hallazgo.

## Tres preguntas para hacerle a tu equipo o a tu proveedor

### 1. ¿Quién vigila los avisos de seguridad?

No basta con «el que sabe de sistemas». Necesitas un nombre, sea de tu equipo o de tu proveedor, que se entere el mismo día que sale un aviso como este y sepa si te afecta: que tu sitio corre en PHP y en qué versión.

### 2. ¿Quién actualiza y te confirma por escrito que quedó hecho?

Un «ya está» por teléfono no alcanza. Pide una confirmación escrita con la versión exacta de PHP instalada (por ejemplo, 8.3.36 o superior en la rama 8.3), la fecha y la constancia de que PHP se reinició para que la versión nueva quede activa. Si alguien aplicó solo una medida provisional, también debe decírtelo con esas palabras.

### 3. ¿Qué haces si tu sitio corre en una versión que ya no recibe parches?

Si tu sitio está en PHP 8.1 o anterior, esas versiones ya no reciben actualizaciones del proyecto PHP. Por la gravedad del caso, el equipo de seguridad de PHP publicó parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta o no tiene un proveedor de soporte extendido (LTS); además, algunas distribuciones y proveedores LTS ofrecen sus propias correcciones. Eso es un salvavidas, no un plan. El plan real es migrar a una rama con soporte (hoy, 8.2, 8.3, 8.4 y 8.5), y eso hay que presupuestarlo y probarlo con calma. Si estás en 7.3 o antes, no hay ni ese parche mínimo.

Y si estás en 8.2, esta vez sí hay parche (8.2.35), pero esa rama se queda sin soporte el 31 de diciembre de 2026. Es buen momento para poner la migración en el calendario.

## Si la respuesta fue «supongo»

No hace falta entrar en pánico ni volverse experto en servidores. Hace falta ponerle dueño al riesgo: saber dónde está alojado tu sitio, en qué versión corre, quién lo vigila y quién te avisa. Es la misma lógica de [quién responde por lo que entra a producción](/es-co/blog/codigo-con-ia-quien-responde), incluso cuando el código lo escribe una IA.

Un sitio caído o intervenido no es un problema de servidores: son pedidos que no entran, clientes que no pueden ingresar a su portal y una conversación incómoda sobre la reputación de tu marca.

## Preguntas frecuentes

### ¿Qué es PHP2Shell?

Es el apodo de dos fallas críticas de PHP (CVE-2026-109618 y CVE-2026-109619) corregidas el 21 de octubre de 2026 en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Permiten ejecutar código en el servidor sin autenticarse.

### ¿Si actualizo WordPress, Magento o Drupal ya estoy protegido?

No. La falla está en PHP, el motor sobre el que corren esas plataformas. Lo que protege es actualizar PHP a una versión corregida y reiniciarlo.

### ¿Mi hosting ya lo arregló?

Depende. En hosting administrado suele hacerlo el proveedor, pero no todos respondieron igual el día del aviso. En un servidor propio o VPS nadie lo hace si no lo pides. Pide confirmación escrita con la versión instalada.

### ¿Qué hago si mi sitio está en PHP 8.1 o anterior?

Esas versiones ya no reciben actualizaciones del proyecto PHP. Por la gravedad del caso, PHP publicó parches mínimos para 7.4, 8.0 y 8.1, y algunas distribuciones y proveedores LTS ofrecen los suyos: sirven para salir del paso, pero el plan real es migrar a una rama con soporte (hoy, 8.2 a 8.5). PHP 8.2 queda sin soporte el 31 de diciembre de 2026.

En Somos Gente Digital escuchamos, construimos y acompañamos hasta que el negocio crece. En mantenimiento eso significa vigilar los avisos, actualizar y contarte qué quedó hecho, con versión y fecha. No te vamos a prometer que nada va a fallar nunca; sí que hay gente cercana mirando y un método claro para responder cuando algo pasa.

Si no tienes claro quién responde por tu sitio, mira [cómo trabajamos el mantenimiento de software](/es-co/mantenimiento-y-soporte-de-software) o escríbenos en [Contacto](/es-co/contacto).