PJSIP corrige CVE-2026-25994 en ICE y exige parcheo urgente
Bajada: Canonical publicó USN-8122-1 para corregir CVE-2026-25994 en PJSIP, una falla de desbordamiento en el manejo de credenciales ICE que puede terminar en caída del servicio o corrupción de memoria en aplicaciones de voz y tiempo real.
Introducción
PJSIP es una librería base en múltiples stacks de VoIP, videollamadas, gateways SIP, PBX embebidas y herramientas de colaboración que usan negociación de medios sobre ICE/STUN/TURN. Cuando aparece una vulnerabilidad en esta capa, el impacto no se queda en “un paquete de Linux”: se traslada a softphones, SBCs, servidores de señalización y servicios internos de comunicaciones en tiempo real.
En este contexto, Ubuntu publicó el aviso USN-8122-1 con correcciones para varias vulnerabilidades históricas y, en especial, para CVE-2026-25994, una falla de buffer overflow en la sesión ICE de PJNATH. El problema afecta a versiones 2.16 o anteriores y ya cuenta con parche upstream y estados de remediación documentados.
Qué ocurrió
La vulnerabilidad se activa al procesar credenciales con username excesivamente largo durante la creación de checklist ICE. Según la descripción de Ubuntu y NVD, un actor remoto podría forzar condiciones que deriven en denegación de servicio, corrupción de memoria e incluso escenarios de ejecución de código en aplicaciones vulnerables, dependiendo de la compilación y protecciones del binario.
El advisory oficial de pjproject (GHSA-j29p-pvh2-pvqp) confirma que el componente afectado es pjnath, que las versiones vulnerables son 2.16 o inferiores y que la versión parcheada es 2.17. Ubuntu, además, publicó fixes en ramas mantenidas bajo ESM para releases antiguas donde el paquete está presente.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma, este tipo de CVE es relevante por tres motivos. Primero, porque PJSIP suele estar “escondido” como dependencia transitoria en productos de telefonía, contact center y comunicaciones unificadas. Segundo, porque muchos despliegues exponen servicios SIP/RTC hacia internet o redes de terceros. Tercero, porque la falla está en una ruta de procesamiento de entrada remota, justo donde se concentran los riesgos operativos.
En términos prácticos, el impacto incluye:
- interrupción de servicios de voz y señalización por crash de procesos;
- riesgo de degradación en clústeres de comunicación cuando un nodo vulnerable entra en bucle de reinicio;
- superficie para abuso en entornos multi-tenant o proveedores de comunicaciones que aceptan tráfico no totalmente confiable.
Para SRE y seguridad defensiva, la señal es clara: no alcanza con parchar el sistema operativo base; hay que mapear qué workloads realmente cargan pjproject/pjnath y cómo se propagan las actualizaciones en imágenes y artefactos.
Detalles técnicos
El commit de corrección (063b3a1) muestra dos cambios clave en la ruta vulnerable:
- se reemplaza un buffer fijo de 128 bytes por una constante de 512 bytes;
- se agregan validaciones explícitas de longitud para evitar combinaciones de ufrag y credenciales que excedan el límite permitido.
Además, se incorpora lógica de rechazo temprano cuando los tamaños no cumplen mínimos/máximos esperados, devolviendo errores controlados en lugar de continuar hacia una copia insegura de datos. Esto reduce riesgo de overflow clásico (CWE-120) en una ruta sensible del handshake ICE.
Un punto operativo importante: Ubuntu marca el CVE con prioridad alta y aclara que en 24.04 y 22.04 el paquete no está en release por defecto. Eso no elimina el riesgo para toda la infraestructura: si una aplicación empaqueta su propio pjproject, usa repositorios externos o mantiene builds estáticos, puede seguir expuesta aunque el host esté al día.
Qué deberían hacer los administradores o equipos técnicos
- Inventario de exposición real: identificar servicios que usen PJSIP/PJNATH (softphones, gateways SIP, servicios WebRTC, appliances de terceros).
- Validar versión efectiva: confirmar si están en 2.16 o menor; priorizar upgrade a 2.17+ o backport equivalente del proveedor.
- Aplicar parche en cadena: actualizar paquete del sistema, reconstruir imágenes de contenedor y redeployar workloads para evitar “parche fantasma”.
- Endurecer borde: limitar exposición de puertos SIP/STUN/TURN, aplicar ACL por origen y rate-limiting donde sea posible.
- Monitoreo y detección: crear alertas por crash loops, reinicios anómalos y picos de error en servicios de señalización.
- Gestión de terceros: pedir SBOM/estado de parche a vendors que integren PJSIP en appliances o plataformas administradas.
Si tu operación depende de comunicaciones en tiempo real (contact centers, soporte por voz, UCaaS interno, edge SIP), este CVE debería entrar en ventana de parcheo prioritaria, no en backlog normal.
Conclusión
CVE-2026-25994 no es un bug cosmético: toca una ruta remota de ICE en una librería ampliamente reutilizada. La combinación de exposición de red, dependencia transitiva y facilidad para pasar inadvertido en inventarios hace que el riesgo operativo sea mayor al que sugiere una lectura superficial del aviso.
La buena noticia es que hay parche claro, advisory público y evidencia técnica concreta del fix. El trabajo para los equipos de DevOps/SRE es ejecutar rápido y con método: descubrir dónde está PJSIP, actualizar sin romper flujos críticos de voz y cerrar observabilidad para detectar intentos de abuso o regresiones.