← Todos los artículos

PHP2Shell y el CRA: qué hacer si tu producto lleva PHP

· 8 min de lectura

El 21 de octubre el proyecto PHP publicó parches para dos vulnerabilidades críticas que permiten ejecutar código en el equipo atacado sin autenticarse. Cinco días después, la agencia de ciberseguridad de Estados Unidos (CISA) las añadió a su catálogo de vulnerabilidades explotadas. Casi toda la cobertura habla de servidores web, pero PHP también va dentro de muchos productos: interfaces de administración, pasarelas, equipos de red. Si fabricas alguno, es probablemente el primer caso serio en el que tienes que pensar en las obligaciones de notificación del Reglamento de Ciberresiliencia (CRA).

Qué ha pasado

Las dos vulnerabilidades, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), tienen una puntuación CVSS v4.0 de 9,2. Las dos son fallos de memoria en la forma en que PHP gestiona internamente cada petición.

Afectan a cualquier instalación de PHP que sirva peticiones web, sea con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. Según el equipo de PHP, el caso de más riesgo es mod_php: hay un exploit demostrado en el que una sola petición sin autenticar lanza el ataque antes de que se ejecute código de la aplicación.

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores ya no reciben actualizaciones: para 7.4, 8.0 y 8.1 solo hay correcciones mínimas en código fuente, que hay que aplicar y compilar por cuenta propia.

Los ataques no han esperado. Según la prensa especializada, los intentos empezaron antes de que hubiera parches y llegaron a contarse por millones, y el fin de semana del 24 y 25 de octubre se confirmó la primera ejecución de código real en servidores trampa. El 26 de octubre CISA incluyó ambas vulnerabilidades en su catálogo de vulnerabilidades explotadas.

Por qué te afecta si fabricas electrónica

El aviso del CERT-EU incluye expresamente los productos de terceros que llevan PHP dentro y remite a la lista que mantiene el centro nacional de ciberseguridad neerlandés (NCSC-NL). A 28 de octubre esa lista seguía 757 productos, 218 de ellos confirmados como vulnerables y 354 todavía en investigación. Hay appliances, equipos de red, interfaces de administración e incluso software inalámbrico industrial.

Dos ejemplos conocidos lo muestran. pfSense, el software de cortafuegos y router de Netgate, tiene su interfaz de administración web hecha en PHP, y su portal cautivo también depende de él. Netgate publicó paquetes corregidos el mismo 21 de octubre. Y Palo Alto Networks ha confirmado que se está explotando la vulnerabilidad contra la interfaz web de gestión de sus cortafuegos. No es casualidad: la interfaz de administración es precisamente la parte del equipo pensada para ser accesible desde la red.

Por qué en un equipo se tarda más que en un servidor

En un servidor, corregir PHP es instalar un paquete. En un producto embebido, la versión de PHP va fijada en la imagen del firmware, y el cuello de botella casi nunca es compilar PHP: es toda la cadena de entrega y recuperación.

  • Generar la imagen correcta para cada placa, variante de producto y configuración.
  • Firmarla con las claves de producción y que el equipo verifique firma, integridad y versión antes de instalarla.
  • Que un corte de alimentación o una descarga interrumpida no deje el equipo inutilizable, con particiones A/B, recuperación y vuelta a la versión anterior.
  • Probar la compatibilidad con la configuración existente, los periféricos, las comunicaciones, el arranque y la actualización desde versiones antiguas, incluidas las extensiones y bibliotecas que cambian con PHP.
  • Distribuirla con conectividad intermitente, equipos detrás de redes privadas y ventanas de mantenimiento, de forma gradual y sabiendo qué equipos se han actualizado.
  • Coordinarlo con el cliente: aprobación, instrucciones de instalación y un plan para los equipos que no vuelven a conectarse.

Imagina una pasarela de contadores inteligentes con Linux. El parche de la interfaz web está listo, pero no puede desplegarse hasta comprobar que funciona en las dos revisiones de hardware, que la imagen está firmada con la clave de producción y que los equipos con mala cobertura se recuperan si la descarga se corta. Incluso en un producto maduro como pfSense, la corrección no se puede aplicar desde la propia interfaz web: hay que hacerlo por consola o SSH, reinstalar WireGuard y reiniciar servicios.

Productos que ya están en el mercado:Revisión y rescate de diseños

Lo que exige el CRA desde el 11 de septiembre

Desde el 11 de septiembre de 2026, las obligaciones de notificación del CRA se aplican también a los productos que ya estaban a la venta. Cuando el fabricante tiene conocimiento de que una vulnerabilidad de su producto se está explotando activamente, debe enviar, a través de la plataforma única de ENISA:

  1. Una alerta temprana en 24 horas.
  2. La notificación en 72 horas, con la información disponible sobre el producto, la vulnerabilidad y las medidas correctoras.
  3. Un informe final a más tardar 14 días después de tener disponible una corrección o una medida de mitigación.

Además, tiene que informar a los usuarios afectados de la vulnerabilidad y de las medidas que deben tomar.

Un matiz importante: que PHP2Shell esté en el catálogo de CISA no obliga por sí solo a notificar. Según la guía que publicó la Comisión Europea en julio, el plazo empieza cuando el fabricante tiene un grado razonable de certeza de que se está explotando en su producto. Pero si tu equipo es vulnerable y su interfaz es accesible, esa certeza puede llegar en cualquier momento, y 24 horas no dan para empezar de cero. Lo explicamos con más detalle en nuestra guía del CRA para fabricantes.

Qué hacer ahora

  1. Averigua qué productos llevan PHP y qué versión. Si tienes una lista de componentes de software (SBOM), es una consulta. Si no, toca revisar la imagen de cada firmware.
  2. Comprueba cómo se ejecuta y quién puede llegar a él. El peor caso es una interfaz con mod_php accesible desde internet; limitarla a la red local reduce la exposición, pero no la elimina.
  3. Prepara la actualización de firmware con una versión corregida o con el backport en código fuente si vas en una rama antigua. Si usas PHP 8.2, ten en cuenta que deja de tener soporte el 31 de diciembre de 2026.
  4. Mientras tanto, aplica las mitigaciones de PHP y recomienda a tus clientes que la interfaz no quede expuesta a internet. El propio equipo de PHP advierte de que no bastan: solo actualizar lo resuelve.
  5. Decide y documenta si tienes que notificar, quién lo hace y cómo vas a informar a los usuarios. Si aparecen indicios de explotación en tus equipos, el plazo de 24 horas ya ha empezado.
  6. Si integras software de terceros (un sistema operativo de pasarela, un panel de gestión), búscalo en la lista del NCSC-NL y pide a tu proveedor su calendario de corrección.

Actualización de firmware y SBOM:Firmware embebido

La lección para el diseño

PHP2Shell no va de PHP. Cualquier componente de terceros de un producto conectado puede tener mañana una vulnerabilidad crítica, y el CRA convierte la respuesta en una obligación con plazos. Lo que decide si es una tarde de trabajo o un mes de crisis se resuelve en el diseño: saber qué lleva cada producto, poder actualizarlo en campo de forma segura y exponer a la red solo lo imprescindible.

Para un equipo nuevo no descartaríamos PHP por principio. Tiene sentido si la plataforma tiene recursos suficientes, el runtime tiene soporte y alguien se responsabiliza de actualizarlo durante todo el ciclo de vida del producto. En muchos dispositivos preferimos una interfaz pequeña con una API local, sobre el servidor web y el lenguaje que la plataforma ya soporta. Elijas lo que elijas:

  • Interfaz desactivada o limitada a la red local por defecto, y nunca expuesta a internet sin una necesidad clara.
  • Autenticación y permisos: que solo sea accesible en la red local no la hace segura.
  • Servicios, dependencias y extensiones reducidos a lo necesario, con versiones fijadas.

Si no tienes a nadie vigilando las dependencias de tus productos, es justo lo que cubre nuestro servicio de seguimiento de vulnerabilidades. Y si quieres saber cuánto tardarías en sacar una actualización como esta, cuéntanos tu producto y lo vemos.

Fuentes

Email Contactar