Una RCE con CVSS 9.9 en IBM i: por qué el boletín de agosto merece prioridad inmediata en tu ciclo de parches
Entre el 11 y el 12 de agosto, IBM publicó seis boletines de seguridad para IBM i 7.3 a 7.6: una ejecución remota de código con la puntuación más alta que suele verse en estos avisos, y un grupo de cinco fallas en DRDA/DDM que conviene mirar juntas, no una por una.
Los boletines de seguridad de IBM i rara vez hacen ruido fuera del círculo de quien administra la plataforma: son avisos técnicos, con jerga de CVSS y números de PTF, que se acumulan semana a semana en la cobertura que IT Jungle le dedica a su PTF Guide. Pero entre el 11 y el 12 de agosto de 2026, IBM publicó una serie de boletines que vale la pena mirar en conjunto, porque uno de ellos trae una puntuación que no es habitual ver en este tipo de avisos: 9.9 sobre 10 en CVSS v3.1, la franja más alta antes del máximo teórico. El resto de los seis boletines de esos dos días afecta al mismo componente —DRDA/DDM, el mecanismo que IBM i usa para el acceso remoto a bases de datos— y, tomados juntos, dibujan un patrón que importa más que cualquier CVE individual.
La vulnerabilidad que hay que priorizar: CVE-2026-16860
El boletín publicado el 11 de agosto describe una vulnerabilidad de ejecución remota de código causada por un elemento de ruta de búsqueda no controlado (CWE-427). En criollo: un atacante remoto ya autenticado en el sistema puede aprovechar que IBM i no fija correctamente dónde busca cierto binario o biblioteca, y lograr que el sistema ejecute código bajo su control en lugar del legítimo. El vector CVSS completo es AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L, que se traduce en: explotable por red, sin complejidad de ataque relevante, con privilegios bajos, sin necesidad de que un usuario interactúe, con cambio de alcance (afecta recursos más allá del componente vulnerable) y con impacto alto en confidencialidad e integridad. Esa combinación es la que empuja el puntaje a 9.9.
La vulnerabilidad afecta a IBM i 7.6, 7.5, 7.4 y 7.3, todas bajo el producto con licencia 5770-SS1. El boletín trae PTFs específicos para cada versión —SJ10879 para 7.6, SJ10880 para 7.5, SJ10881 para 7.4 y SJ10882 para 7.3— y el texto de IBM no deja margen de ambigüedad: "IBM strongly recommends addressing the vulnerability now" ("IBM recomienda encarecidamente abordar esta vulnerabilidad ahora"), una frase que no aparece en todos los boletines y que funciona, en la práctica, como la señal más clara de que esto no puede esperar al próximo ciclo trimestral de mantenimiento.
El grupo de fallas en DRDA/DDM que llegó el mismo día
Un día después, el 12 de agosto, IBM publicó dos boletines más centrados en DRDA (Distributed Relational Database Architecture) y DDM (Distributed Data Management), los protocolos que permiten a un sistema remoto acceder a bases de datos y archivos de IBM i. El primero cubre una única falla, CVE-2026-17078: denegación de servicio por agotamiento de recursos (CWE-400), con CVSS 5.3, también en las cuatro versiones soportadas, con PTFs propios (SJ10836 a SJ10839).
El segundo agrupa cuatro CVEs en un mismo boletín: CVE-2026-17216 (desbordamiento de enteros al procesar encabezados de objetos grandes en DRDA, DoS, CVSS 5.3), CVE-2026-17077 (uso de una variable sin inicializar, DoS, CVSS 5.3), CVE-2026-17076 (procesamiento indebido de solicitudes de resincronización DRDA/DDM que permite agotar recursos sin límite, CVSS 5.3) y CVE-2026-17074 (gestión indebida de privilegios que permite a un atacante remoto autenticado saltarse restricciones de seguridad, CVSS 3.1, la única de las cuatro que no es de denegación de servicio sino de integridad). Las cuatro comparten PTFs (SJ10848 a SJ10851 según versión) y el mismo día de publicación.
Ninguna de estas cinco fallas de DRDA/DDM alcanza por sí sola la gravedad de la RCE del día anterior. Pero la concentración —seis boletines distintos, dos componentes de red expuestos (DDM y el mecanismo de búsqueda de rutas), 48 horas de diferencia— es justamente el tipo de patrón que un boletín leído de forma aislada no deja ver. Si tu shop expone DDM/DRDA hacia afuera del perímetro de confianza —algo más común de lo que debería, sobre todo en integraciones heredadas que nunca se revisaron después de configurarse— esa semana de agosto concentró más superficie de ataque nueva contra ese protocolo que varios meses anteriores juntos.
Por qué esto no es solo "otro martes de parches"
Hay una razón estructural para prestarle atención a este tipo de agrupamiento, más allá del caso puntual de agosto. IBM i tiene fama, merecida en términos relativos, de ser una plataforma con una superficie de ataque más acotada que la de un servidor Linux o Windows expuesto de la misma forma. Esa reputación genera un efecto secundario poco discutido: en muchos shops, el ciclo de aplicación de PTFs de seguridad es más laxo que en el resto de la infraestructura, precisamente porque "total, esto no lo ataca nadie". Una RCE con CVSS 9.9 en un componente de red es la prueba de que esa suposición tiene un costo cuando falla, y falla justo en los sistemas donde vive la lógica de negocio más crítica y donde una intrusión exitosa suele pasar más tiempo sin ser detectada.
El otro punto que vale la pena señalar es que las cuatro versiones soportadas —7.3, 7.4, 7.5 y 7.6— están afectadas por igual en los seis boletines. Esto importa especialmente para los shops que siguen en 7.4, cuyo soporte estándar termina el 30 de septiembre de este año, como ya cubrimos en este blog. Estar a semanas del fin de soporte no es excusa para dejar sin aplicar un parche de una RCE crítica: todo lo contrario, es la ventana en la que conviene cerrar cualquier deuda de seguridad pendiente antes de que ese PTF eventualmente deje de estar garantizado en versiones fuera de soporte.
Qué hacer con esto en tu shop
El primer paso, obvio pero fácil de postergar, es verificar si tu partición ya tiene aplicados SJ10879/80/81/82 (según tu versión) para la RCE, y priorizarlo sobre cualquier otro trabajo de mantenimiento programado esta semana: la recomendación explícita de IBM de "abordarlo ahora" no es retórica de boletín, es una señal real de gravedad. Segundo, si tu sistema expone DDM o DRDA fuera de la red interna —para integraciones con partners, ETL de terceros o accesos remotos históricos— es un buen momento para auditar quién realmente necesita ese acceso y si puede restringirse por firewall o exit points en lugar de dejarlo abierto por costumbre. Tercero, si administrás varias particiones en distintas versiones, no asumas que aplicar el PTF en una cubre a las demás: cada versión tiene su propio número de PTF y su propio calendario de pruebas antes de producción, así que conviene trackear el estado de aplicación por partición, no por sistema operativo en general. Ninguna de estas acciones reemplaza un programa formal de gestión de vulnerabilidades, pero cierran la brecha más urgente que dejó abierta esta ronda de boletines de agosto.