PHP2Shell: las vulnerabilidades de PHP que deberían quitarte el sueño si tienes un FreePBX expuesto

Esta semana ha sido movida para los que tenemos servidores con PHP (es decir, casi todos). El pasado 21 de octubre, el equipo de PHP publicó actualizaciones de seguridad para corregir dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que ya se conocen popularmente como PHP2Shell. Y el nombre no es casualidad: ambas tienen una puntuación CVSS v4 de 9.2 y permiten ejecución remota de código sin autenticación.

Resumiendo mucho: la primera es una corrupción de memoria cuando PHP se queda sin memoria a mitad de preparar una petición; la segunda, un use-after-free en el que un worker reutiliza datos que quedaron «colgando» de una petición anterior. Afecta a cualquier PHP que sirva peticiones web (PHP-FPM, php-cgi, LiteSpeed…) y el caso más delicado es Apache con mod_php, porque el ataque puede funcionar antes incluso de que se ejecute una sola línea de la aplicación. Ya hay pruebas de concepto circulando, así que esto no es para dejarlo para el lunes.

Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Para 7.4, 8.0 y 8.1 hay parches mínimos en código fuente y paquetes de las distribuciones. ¿Y para PHP 7.3 o anteriores, incluido el querido PHP 5? Pues nada. No hay parche, ni lo va a haber.

¿Y esto qué tiene que ver con Asterisk?

Mucho más de lo que parece. Si echamos la vista atrás, me atrevería a decir que el 95% de los interfaces web para gestionar Asterisk se desarrollaron entre 2005 y 2020, y prácticamente todos en PHP: FreePBX, trixbox, Elastix, Issabel, PBX in a Flash… y un montón de paneles hechos a medida que todos conocemos (y que muchos hemos programado, no nos engañemos).

Hubo excepciones, claro. Asterisk-GUI fue bastante innovador en su día: HTML y JavaScript con Ajax hablando directamente con el servidor HTTP del propio Asterisk, sin PHP de por medio. Pero fueron los menos.

El problema es que muchas de esas centralitas siguen funcionando años después con la versión de PHP con la que se instalaron. Distribuciones abandonadas, CentOS sin soporte, PHP 5.x o 7.x… y el interfaz web abierto a Internet «para poder entrar desde casa». Con PHP2Shell, eso es una invitación en toda regla.

¿Qué hacemos?

Básicamente hay dos caminos, y lo ideal es hacer los dos:

1. Bloquear el acceso web. El interfaz de administración de una centralita no tiene por qué estar abierto al mundo. Firewall con lista blanca de IPs, VPN, o como mínimo el Responsive Firewall de FreePBX bien configurado. Si no puedes actualizar hoy, esto es lo primero que tienes que hacer hoy.
2. Actualizar. Comprueba qué versión tienes con php -v. Si tu distribución ya ha publicado el paquete parcheado, actualiza y reinicia Apache/PHP-FPM (sin reiniciar los workers, el parche no sirve de nada). Si estás en PHP 7.3 o anterior, no hay atajo: toca migrar.

Cómo actualizar FreePBX

Aquí viene la parte menos divertida: no existe una actualización directa de FreePBX 16 (o anteriores) a FreePBX 17. FreePBX 17 funciona sobre Debian 12 con PHP 8.2, así que el procedimiento es, a grandes rasgos:

1. Hacer una copia de seguridad completa con el módulo Backup & Restore de tu FreePBX actual.
2. Instalar un servidor nuevo con Debian 12 y FreePBX 17 usando el script oficial.
3. Restaurar la copia en el nuevo servidor (por línea de comandos si es grande).
4. Revisar lo que haya cambiado: FreePBX 17 viene con Asterisk 22, que ya no tiene chan_sip ni la aplicación Macro, así que tus troncales SIP pasarán a PJSIP y el dialplan personalizado con macros habrá que pasarlo a GoSub.

Sangoma lo explica paso a paso en su documentación: Upgrading to FreePBX 17 y How to Install FreePBX 17 on Debian 12. Y si queréis más detalle sobre las vulnerabilidades, el FAQ de watchTowr y el análisis de Rapid7 están muy bien.

Sé que migrar una centralita en producción da pereza, y más si «funciona perfectamente desde hace diez años». Pero precisamente por eso: si lleva diez años sin tocarse, lleva diez años acumulando vulnerabilidades. Mejor dedicarle una tarde ahora que una semana de facturas de tráfico fraudulento después.

¿Tenéis todavía algún Elastix o FreePBX antiguo por ahí dando guerra? Contadlo en los comentarios o en nuestro canal de Telegram.