CVE-2026-18175 y CVE-2026-18221: el boletín de DDM/DRDA que IBM publicó sin ofrecer ningún workaround

El 2 de septiembre de 2026, IBM publicó un boletín de seguridad para IBM i titulado "IBM i is Affected By Improper Authorization and Authentication Vulnerabilities in DDM / DRDA", con dos CVEs nuevos: CVE-2026-18175 y CVE-2026-18221. No es la misma tanda de boletines de DRDA/DDM del 11 y 12 de agosto que ya repasamos en este blog (aquella cubría CVE-2026-16860, la RCE con CVSS 9.9, y un grupo de cinco fallas distintas en el mismo protocolo). Esta es una ronda posterior, con identificadores propios, y con un detalle que la distingue del resto: en la sección "Workarounds and Mitigations" del boletín, IBM escribió una sola palabra: "None". No hay una configuración alternativa, ni un parámetro que se pueda ajustar mientras se prueba el PTF en un entorno de desarrollo. La única salida es aplicar el parche o restringir el acceso de red al servicio.

Qué es lo que queda expuesto

DDM (Distributed Data Management) y DRDA (Distributed Relational Database Architecture) son los protocolos que IBM i usa para que un sistema remoto —otra partición IBM i, un cliente ODBC/JDBC, una herramienta de integración o replicación— acceda a archivos y bases de datos Db2 for i sin pasar por una API intermedia. Son mecanismos antiguos, anteriores a la ola actual de modernización vía REST, pero siguen activos en una enorme cantidad de shops porque son la base de integraciones que se configuraron hace años y que nadie revisó desde entonces: replicación entre particiones, ETLs de terceros, conexiones de BI que leen directamente contra Db2 for i. Es justamente ese perfil —tráfico de red expuesto, configurado una vez y olvidado— el que convierte cualquier falla de autenticación en DDM/DRDA en algo más serio que una vulnerabilidad de laboratorio.

Las dos fallas, explicadas

CVE-2026-18175 (CWE-285, Improper Authorization) describe una falla en el "DDM target dispatcher": el componente que recibe una solicitud DDM y decide si el que la envía tiene permiso para ejecutar la operación que pide. IBM la describe así: "IBM i could allow a remote attacker to manipulate database transactions due to improper authorization in the DDM target dispatcher". El vector CVSS es AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L, con un puntaje base de 8.1: explotable por red, sin privilegios previos (PR:N), sin interacción de usuario, con cambio de alcance (S:C, el ataque afecta recursos más allá del propio componente vulnerable) y con impacto alto en integridad. En criollo: un atacante que llega a esa parte del protocolo puede alterar transacciones de base de datos que no debería poder tocar.

CVE-2026-18221 (CWE-287, Improper Authentication) es, en cierto sentido, la falla más incómoda de las dos: "IBM i could allow a remote attacker to gain unauthorized access due to improper validation of client-supplied authentication parameters". Es decir, el servidor no valida correctamente los parámetros de autenticación que el propio cliente le envía, lo que abre la puerta a que esos parámetros se manipulen para obtener acceso. Su vector CVSS es AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, también con puntaje 8.1, pero con impacto alto simultáneo en confidencialidad, integridad y disponibilidad: el peor de los tres combinados.

Ambas fallas comparten algo relevante: AC:H (complejidad de ataque alta). Esto no significa que sean difíciles de explotar en el sentido de requerir herramientas sofisticadas, sino que dependen de condiciones que el atacante no controla directamente —por ejemplo, el estado específico de la sesión DDM en el momento del intento—. Es la diferencia entre "cualquiera con acceso de red lo explota en el primer intento" y "un atacante con acceso de red y algo de persistencia eventualmente lo logra". Para un servicio que muchos shops dejan escuchando en el mismo segmento de red que el resto de la infraestructura, esa distinción no cambia demasiado la urgencia.

Los parches, versión por versión

El boletín afecta a las cuatro versiones soportadas de IBM i —7.6, 7.5, 7.4 y 7.3— bajo el producto con licencia 5770-SS1, y trae PTFs específicos para cada una: SJ11231 y SJ11230 para 7.6, SJ11232 y SJ11233 para 7.5, SJ11262 y SJ11261 para 7.4, y SJ11234 y SJ11235 para 7.3. Como cada versión requiere dos PTFs (uno por cada CVE, aparentemente), conviene confirmar que ambos números quedaron aplicados y no solo uno de los dos, algo fácil de pasar por alto si el proceso de aplicación de PTFs en tu shop no está automatizado.

Qué hacer mientras el PTF entra en el ciclo de pruebas

Como el boletín no ofrece mitigación alternativa, lo primero es entender cuánto expone tu sistema estos dos protocolos. DRDA y DDM escuchan tradicionalmente en los puertos TCP 446 y 447; un NETSTAT *CNN te muestra si hay conexiones activas contra esos puertos y desde qué direcciones IP, lo cual es un primer indicio de qué tan expuesto está el servicio hacia afuera del perímetro de confianza. Si tu shop no usa DDM ni DRDA para nada —porque toda la integración externa ya pasa por API REST o por un intermediario— vale la pena confirmar si el servidor *DDM realmente necesita estar activo, y si no, terminarlo con ENDTCPSVR SERVER(*DDM) mientras se aplica el parche, en lugar de dejarlo escuchando por inercia.

Si en cambio sí lo usás —para replicación entre particiones, conexiones ODBC/JDBC de terceros o BI— el camino no es apagarlo, sino acotar quién puede llegar a él: restringir por firewall las IPs de origen a las que realmente lo necesitan, y revisar si tenés puntos de salida (exit points) registrados sobre los servidores de acceso remoto que te permitan filtrar o auditar esas conexiones en lugar de confiar únicamente en la autenticación del protocolo, que es precisamente lo que estas dos fallas ponen en duda. Ninguna de estas dos acciones reemplaza el PTF —siguen siendo mitigaciones de exposición, no una corrección de la causa raíz—, pero son la diferencia entre tener una ventana de riesgo acotada y tener el servicio abierto sin control mientras el parche pasa por el ciclo normal de pruebas antes de producción.

La lección de fondo, otra vez, es la misma que dejó la ronda de agosto: DDM y DRDA son protocolos que rara vez aparecen en la conversación de seguridad de un shop IBM i, precisamente porque llevan tanto tiempo funcionando sin incidentes que terminan tratados como parte del paisaje. Este boletín es un recordatorio de que "lleva años funcionando así" no es lo mismo que "está configurado de forma segura", y de que vale la pena que ambos protocolos entren en el mismo inventario de superficie de red expuesta que cualquier API moderna que tu shop haya publicado este año.