Java no es el riesgo. Tu implementación y tu parche, sí.

Esta semana circuló una imagen que puso a Java en rojo: "riesgo ALTO", junto a Node.js, Go y Python. Para quien no está en el día a día, el mensaje es fácil de leer mal: "Java es inseguro".

Llevo 12 años construyendo sistemas en Java para la banca en México: créditos en Banjército, SPEI en Banco Azteca, el core de HSBC, y fui Security Champion en Santander. Mi conclusión es otra: el lenguaje rara vez es el problema. El problema es cómo lo implementamos y qué tan rápido lo parchamos.

Pero también hay que ser honestos: esta semana trae un caso que ninguna capa de login te resuelve. Vamos por partes.

Qué pasó esta semana con Java

1. El parche trimestral de octubre (20 de octubre de 2026)

55 vulnerabilidades en Java SE, 49 explotables a distancia sin autenticación.
Ninguna clasificada como crítica.
Versiones corregidas: 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 y 27.0.1.
Java 26 ya no recibe parches: hay que pasar a la 25 (LTS) o a la 27.

2. Una alerta fuera de calendario: CVE-2026-91403 (21 de octubre de 2026)

Componente: JSSE, la implementación de TLS de Java.
CVSS 9.1 (crítica). Explotable por red, sin autenticación y con baja complejidad.
Impacto: lectura, creación, modificación o borrado de datos críticos.
Afecta incluso a las versiones del parche de octubre (8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1) y a GraalVM.
Según el aviso de OpenJDK, el origen son ocho certificados de autoridades intermedias de eMudhra comprometidos, generados con claves privadas débiles. No es solo el Java de Oracle: afecta también a OpenJDK 8, 11, 17, 21, 25 y 27.

El mito: "Java es inseguro"

Los bancos no usan Java por moda. Lo usan porque tiene:

Un ecosistema de seguridad maduro: Spring Security, estándares como OAuth2 y OpenID Connect, y décadas de auditorías.
Parches con calendario: Oracle publica actualizaciones de seguridad el tercer martes de cada mes, más un parche trimestral grande. Fechas conocidas que puedes planear.
Tipado fuerte y una plataforma estable, que reducen errores comunes.

Un sistema bancario bien construido en Java combina varias capas:

Spring Security con reglas claras de autorización.
Segundo factor (2FA) para el acceso.
SSO con tokens opacos, que el servidor puede revocar al instante, a diferencia de un JWT que vive hasta que expira.
Cookies de sesión con HttpOnly, Secure y SameSite, y tiempos de expiración cortos.
Un WAF empresarial (como Imperva) en el borde, filtrando ataques antes de que lleguen a la aplicación.

Con eso, la mayoría de los ataques contra la aplicación se vuelven muy difíciles. La mayoría de las brechas que vi en proyectos reales no venían del lenguaje: venían de endpoints sin autorización, secretos en el código, dependencias abandonadas y servidores sin actualizar.

Lo que no te resuelve el login

Aquí está el punto que casi nadie explica.

CVE-2026-91403 no es un ataque contra tu login: es un problema de confianza en certificados. Java venía confiando en certificados intermedios comprometidos. Con ellos, un atacante que se coloque en medio de la conexión (man-in-the-middle) puede presentar un certificado falso para cualquier dominio, y Java lo aceptaría como válido.

¿Dónde pega? Sobre todo cuando Java actúa como cliente: cuando tu aplicación se conecta hacia afuera, a la API de un tercero, a un procesador de pagos o a otro servicio interno por TLS. Tu aplicación cree que habla con el servidor correcto, y en realidad le está entregando datos al atacante.

Por eso:

El 2FA no lo frena.
El SSO no lo frena.
Spring Security no lo frena.

Todo eso protege a quien entra a tu aplicación. Este problema está en a quién le cree tu aplicación cuando sale.

Lo que sí ayuda:

Parchar el runtime de Java en cuanto el parche de tu proveedor esté disponible.
Bloquear los certificados comprometidos reemplazando lib/security/blocked.certs por la versión que publica OpenJDK (en Java 8 el archivo se llama blacklisted.certs).
Activar la verificación de revocación en aplicaciones TLS: -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true.
Si usas el OpenJDK de tu sistema operativo (Debian, Ubuntu, Fedora, RHEL), normalmente basta con actualizar los certificados del sistema (ca-certificates).

¿Y terminar el TLS en un reverse proxy? Reduce la exposición del tráfico que entra, pero no protege las conexiones que salen desde Java. No sustituye al parche.

La lección: la seguridad de la aplicación y la seguridad de la plataforma son dos cosas distintas. Necesitas ambas.

Defensa en capas: dónde actúa cada control

Capa	Controles	¿Protege contra CVE-2026-91403?
Borde	WAF (Imperva), TLS terminado en el proxy, límites de tráfico	⚠️ Solo reduce exposición en tráfico entrante; no protege conexiones salientes de Java
Plataforma	JVM actualizada, `blocked.certs`, verificación de revocación, certificados del SO al día	✅ Sí
Aplicación	Spring Security, autorización por rol, validación de entradas	❌ No, el problema está en la confianza TLS
Identidad	2FA, SSO, tokens opacos, cookies de sesión seguras	❌ No, el problema está en la confianza TLS
Monitoreo	Logs, alertas, detección de anomalías	⚠️ Ayuda a detectar, no a prevenir

Qué hacer el lunes en tu equipo

Inventario de JVMs. No solo los servidores: también contenedores, herramientas y software de terceros que trae su propia JVM.
Actualiza al parche de octubre de tu versión (8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 o 27.0.1).
Vigila el parche de CVE-2026-91403 de tu proveedor (Oracle, Temurin, Azul, Red Hat, Amazon Corretto) e instálalo en cuanto salga.
Mientras tanto: reemplaza blocked.certs, activa la verificación de revocación y actualiza los certificados del sistema operativo.
Revisa tus conexiones salientes. Identifica qué servicios Java se conectan por TLS a terceros o a otros sistemas: son los más expuestos.
Reconstruye y redepliega las imágenes de contenedor. Actualizar el host no actualiza la JVM dentro del contenedor.
Reinicia los servicios. Una JVM corriendo sigue usando la versión anterior hasta que se reinicia.
Verifica con java -version en cada entorno. No confíes en que "ya se actualizó solo".
Si sigues en Java 26, planea la migración a 25 LTS o a 27.

Lo que aprendí en la banca

Como Security Champion, la mitad del trabajo no era corregir vulnerabilidades: era separar las reales de los falsos positivos. Una semana como esta trae decenas de CVEs, y un equipo chico no puede leerlos todos. La pregunta útil no es "¿cuántas vulnerabilidades hay?", sino "¿cuáles me afectan a mí, por dónde entran y qué capa las detiene?".

Por eso Java sigue siendo una gran opción para sistemas críticos. No porque sea invulnerable, sino porque te da las herramientas para defenderte en capas, si las usas bien y si parchas a tiempo.

Hoy trabajo en Fararoni App Sec, un proyecto que usa IA hospedada en México para hacer triage de vulnerabilidades y explicarlas en español, para que equipos pequeños, escuelas y pymes puedan responder a semanas como esta.

Fuentes

Eber Cruz Fararoni is a software architect specialized in distributed systems, event-driven architectures, and applied artificial intelligence. He builds Fararoni Flow, an open-source AI agent orchestrator, on Java 25, NATS, and hexagonal architecture. He writes at ebercruz.com about the intersection of software engineering and artificial intelligence.

If you found this article useful, share it with someone navigating the complex enterprise AI landscape in 2026. And if you want to try Fararoni Flow or exchange ideas about agent orchestration: contact me.