CVE
CVE-2024-21182
CWE
Sin clasificar
Sistemas afectados
- Oracle WebLogic Server 12.2.1.4.0
- Oracle WebLogic Server 14.1.1.0.0
- Despliegues de Oracle Fusion Middleware que exponen T3 o IIOP
- Aplicaciones Java alojadas en dominios de WebLogic afectados
CISA añadió CVE-2024-21182 al catálogo de vulnerabilidades explotadas conocidas el 1 de junio de 2026, convirtiendo un elemento de la actualización crítica de parches de Oracle de julio de 2024 en un problema de respuesta activa para los operadores de WebLogic.
La descripción de Oracle es deliberadamente escueta: el fallo está en Oracle WebLogic Server Core, afecta a las versiones compatibles de WebLogic Server 12.2.1.4.0 y 14.1.1.0.0, es alcanzable de forma remota sin autenticación a través de T3 e IIOP, y puede provocar acceso no autorizado a datos críticos o acceso completo a todos los datos accesibles por WebLogic Server. Oracle asignó CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, lo que significa que el impacto público es solo de confidencialidad, pero el acceso es de red, de baja complejidad y sin autenticación.
Proyectos afectados
Los proyectos de servidor de aplicaciones afectados son:
| Producto | Versiones afectadas | Protocolos expuestos |
|---|---|---|
| Oracle WebLogic Server | 12.2.1.4.0 | T3, IIOP |
| Oracle WebLogic Server | 14.1.1.0.0 | T3, IIOP |
La exposición práctica es más amplia que la versión del binario de WebLogic. Cualquier aplicación Java desplegada en un dominio de WebLogic afectado hereda la superficie de protocolo del lado del servidor, especialmente si balanceadores de carga, cortafuegos, servicios de Kubernetes o rutas VPN públicos o semipúblicos exponen los puertos de escucha de WebLogic.
Por qué importan T3 e IIOP
WebLogic no expone solo aplicaciones HTTP. Las rutas administrativas, de clustering, RMI, EJB, JMS y de cliente remoto pueden viajar sobre los protocolos nativos de WebLogic. El error común es proteger /console y las URLs de la aplicación mientras se deja la misma dirección de escucha alcanzable para clientes t3://, t3s://, iiop:// o iiops://.
Los clientes Java típicos hacen explícitas esas elecciones de protocolo:
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
Hashtable<String, String> env = new Hashtable<>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://weblogic.example.com:7001");
Context ctx = new InitialContext(env);
Object remote = ctx.lookup("jms/ConnectionFactory");Ese código es habitual en entornos empresariales antiguos. Desde el punto de vista de un defensor, cada ruta t3:// o iiop:// permitida hacia un servidor afectado es una ruta relevante para la vulnerabilidad, no solo un detalle de conectividad de la aplicación.
Condiciones previas de explotación
Según los datos de Oracle/NVD/CISA, las condiciones previas importantes son:
La versión de WebLogic Server es 12.2.1.4.0 o 14.1.1.0.0
Falta la CPU de julio de 2024 o una corrección posterior aplicable de WebLogic
Un atacante tiene alcance de red hacia T3 o IIOP en la dirección de escucha de WebLogic
No se requiere autenticación ni interacción del usuarioOracle no ha publicado un diff de causa raíz público, por lo que los equipos deben evitar construir detecciones basadas en un nombre de método o clase adivinado. Concéntrate en versión, inventario de parches, alcance de red y telemetría a nivel de protocolo.
Comprobaciones de inventario y exposición
En los hosts, verifica la versión de WebLogic y el inventario de parches desde el Oracle home usado por el dominio en ejecución:
$ORACLE_HOME/OPatch/opatch lsinventoryBusca direcciones de escucha de WebLogic y ajustes relacionados con protocolos en la configuración del dominio:
rg -n \
"<listen-port>|<listen-address>|t3|t3s|iiop|iiops|IIOP|T3" \
"$DOMAIN_HOME/config/config.xml" "$DOMAIN_HOME/config"A partir del inventario de red, marca las rutas de Internet, de socios y las rutas internas amplias hacia los puertos predeterminados y personalizados de escucha de WebLogic. WebLogic suele escuchar en 7001 para tráfico plano y 7002 para SSL en dominios simples, pero los dominios de producción a menudo usan puertos personalizados, balanceadores de carga y separación entre servidor de administración y servidores gestionados.
# Ejemplo de descubrimiento desde un host de escaneo autorizado a evaluar el segmento.
nmap -sT -p 7001,7002,8001,8002,9001,9002 --open <weblogic-subnet>Si usas Kubernetes, no te detengas en las imágenes de los pods. Comprueba si un Service, Ingress, Gateway o balanceador de carga en la nube expone los puertos de WebLogic:
kubectl get svc,ingress,gateway -A -o wide | rg "7001|7002|8001|8002|weblogic"Detección
Dado que el aviso público no describe la forma de una carga útil, la detección debe ser conservadora:
- Revisa los registros de acceso de WebLogic y la telemetría de red en busca de nuevos clientes externos que alcancen los puertos de escucha de WebLogic, especialmente tráfico no HTTP.
- Busca actividad fallida o inusual de cliente JNDI/RMI/EJB/JMS alrededor de la fecha de inclusión en el KEV de CISA y antes de aplicar el parche.
- Compara los cambios recientes en la configuración del dominio de WebLogic con la actividad de despliegue aprobada.
- Revisa los registros de la aplicación en busca de lecturas de datos inesperadas, búsquedas administrativas o llamadas de servicio desde IPs de origen inusuales.
Ejemplo de triaje de registros:
rg -n \
"T3|IIOP|RJVM|JNDI|InitialContext|weblogic\\.rmi|javax\\.management|BEA-" \
"$DOMAIN_HOME/servers" /var/logEsa búsqueda es deliberadamente amplia. Debe guiar la delimitación del alcance, no servir como prueba de explotación.
Remediación
Parchea primero. Oracle corrigió el problema en la actualización crítica de parches de julio de 2024, y CISA ahora exige a las agencias federales cubiertas remediar la entrada del KEV antes del 4 de junio de 2026. Para los equipos no federales, la inclusión en el KEV sigue siendo una señal fuerte de que esto debería salir del parcheo trimestral rutinario.
Si el parcheo inmediato no es posible, reduce la exposición mientras preparas un despliegue corregido:
Bloquea el acceso de red público y no confiable a T3 e IIOP de WebLogic.
Permite T3/IIOP remoto solo desde los hosts de aplicación explícitamente necesarios.
Separa el acceso al servidor de administración del tráfico de aplicaciones de los servidores gestionados.
Desactiva las funciones IIOP o de cliente remoto no utilizadas cuando la aplicación no las necesite.
Requiere rutas de VPN, bastión o red privada para los protocolos administrativos y de cliente remoto.La propia guía de la CPU de Oracle es clara en que el bloqueo de protocolos puede reducir el riesgo, pero no sustituye la aplicación del parche. Trata los estados de solo mitigación como temporales y da seguimiento hasta su cierre.
De la investigación a la remediación
Comprueba si este patrón existe en tu código
Convierte esta investigación en un flujo de remediación. Utiliza análisis estático con IA para encontrar problemas similares y generar correcciones listas para revisar.