El miércoles, en la conferencia Hexacon de París, el investigador Quentin Kaiser presentó algo que me dejó con una mezcla de rabia y respeto: un bug en la implementación WiFi propietaria de Broadcom que lleva vivo desde al menos 2010. Parche incompleto publicado en silencio en 2018. Y a la fecha, routers de operadores de telecom reales, corriendo en producción, siguen sin el fix.
El bug, en corto
La falla es un desbordamiento en el reensamblado de paquetes EAP del WPS, dentro del SDK propietario de Broadcom. Lo feo no es el overflow en sí, sino las condiciones de explotación: se dispara por WiFi sin conocer la clave de la red y sin completar un enrolamiento WPS válido. La cadena termina en revelación de información y ejecución arbitraria de código. En las demos se ve root shell en un CPE de Orange, con el ataque funcionando a distancia — no hace falta estar pegado al router, y el shellcode de vuelta viaja por frames 802.11, sin C2 en la nube.
Afecta las plataformas eCos (BCM3380, BCM3383, BCM33834) y potencialmente las Linux (BCM3390, BCM65xx, BCM68xx). Docenas de fabricantes, cientos de productos, millones de access points con Broadcom en el mundo.
Lo que me tiene molesto: el CVE que no existe
Broadcom conocía el bug desde 2018. Su respuesta fue un parche parcial silencioso y la recomendación de que los OEM migraran a hostapd — es decir, «resuélvanlo ustedes». Y se negó a asignar un CVE. Sin CVE no hay aviso público, no hay escáneres de versión, no hay nota de prensa técnica. La notificación va por un portal privado a cada OEM y, si el OEM no mira, nadie parchea. Que es exactamente lo que pasó: Kaiser probó gateways de 3 de los 4 ISP de Bélgica — Proximus (BBOX 3V+), VOO (Netgear CG3100 y CG3700, Technicolor 7210, CGA4233) y Orange (ASKEY TCG3000) — y al 15 de octubre de 2026 ninguno de esos equipos estaba parcheado. Solo sus estimaciones hablan de unas 850.000 gateways afectadas de Proximus, más de medio millón de VOO y 210.000 de Orange Bélgica.
La IA aceleró el reloj
Kaiser lo dice sin rodeos: solo, esta investigación le habría tomado meses; con modelos frontera le tomó menos de una semana. Ese dato me incomoda, y no lo digo por dramático. Yo uso agentes de IA todos los días en mi pega y sé lo que vale en manos buenas. Lo que cambia con esto es el costo de mirar profundamente: capas del stack que antes requerían un especialista con un mes libre, ahora quedan al alcance de cualquiera con criterio y suscripción. La «seguridad por complejidad» está muerta, y el inventario de código viejo que nadie revisó recién empieza a cobrarse.
Y el vector no es teórico: ataques nearest-neighbour sobre WiFi cercanos (los documentó Volexity con un APT ruso) o el compromiso de redes de hoteles que reportó Microsoft este año. Objetivos puntuales, por aire, contra equipos en los que los defensores casi no tienen visibilidad.
Qué hacer al respecto
Primero, identificar: Kaiser publicó un script de fingerprinting y una regla YARA en su repo (github.com/qkaiser/broadcom-wps) para mapear el radio de la bomba. Segundo, presionar a tu ISP si tu CPE sale en la lista — la divulgación fue de 90 días, informados estuvieron, el parche no llegó. Tercero, lo de siempre que nadie hace: aislar tu red interna detrás de tu propio router (pfsense, OpenWrt, lo que sea) y dejar el CPE del operador como módem puro, con WPS apagado. Yo prefiero no depender del firmware de nadie que no puedo auditar, y esta historia es el argumento perfecto.
La deuda técnica se cobra siempre. La única pregunta es quién lo hace primero: nosotros o el weón al otro lado de la vereda.
Fuente de inspiración: One Parser, Two Bugs, Many Routers: Exploiting Broadcom WiFi Across eCos and Linux
