El 5 de agosto de 2026, investigadores de Novee dirigidos por Lidor Ben Shitrit presentaron en Black Hat USA un trabajo que reveló doce vulnerabilidades en cuatro plataformas Java empresariales, entre ellas dos cadenas críticas que permiten ejecutar código en el servidor sin ningún inicio de sesión, en la plataforma de flujos de trabajo Bonita BPM y en Apache OFBiz, el ERP de código abierto. La conclusión práctica para cualquier empresario: el sistema que das por protegido porque es interno puede alcanzarse con dos peticiones del navegador si está expuesto y sin parchear. La protección real empieza con un inventario de lo que ejecutas y una rutina de parches, no con la confianza en el perímetro de la red.

Qué encontraron realmente los investigadores

La investigación no se basó en un único fallo espectacular. Se construyó combinando pequeños errores habituales del middleware: diferencias en la forma de interpretar una URL, protección incompleta en la capa que gestiona las peticiones, claves criptográficas incrustadas en el código fuente y una evaluación de plantillas insegura. Por separado, ninguno parece peligroso, y precisamente por eso sobreviven a la revisión de código y se archivan como de baja prioridad. Encadenados, producen una ruta completa desde un visitante anónimo hasta la ejecución de comandos en el servidor. De las doce vulnerabilidades, cuatro funcionan antes de la autenticación y una rompe el aislamiento dentro del entorno aislado de ejecución.

La cadena BadBonita: tres puntos débiles forman un compromiso total

La primera cadena afecta a la versión 10.4.3 de Bonita BPM. Comienza con una evasión de autenticación construida a partir de tres debilidades enlazadas: un recorrido de rutas mediante la notación ..;, un filtro de seguridad que compara una subcadena en lugar de la ruta completa y la lógica interna de reenvío de peticiones. El resultado es que una petición llega a una API interna que nadie desde fuera debía ver jamás. Esa API acepta XML no confiable y lo pasa directamente a la biblioteca XStream, que lo deserializa, y a través de una conocida cadena de gadgets de Commons Collections el recorrido termina con comandos Groovy ejecutándose en el servidor.

Observa que ninguno de estos pasos requiere una contraseña filtrada, ingeniería social ni acceso previo. Lo único que necesita el atacante es que el sistema sea accesible a través de la red.

OFBiz: una clave de firma publicada en un repositorio abierto

El segundo problema, registrado como CVE-2026-31986 y calificado como crítico, afecta a la versión 24.09.05 de Apache OFBiz cuando el inicio de sesión único está activado. El problema es que las claves de firma predeterminadas están en el código fuente publicado abiertamente y, como muchas instalaciones no tocan los valores por defecto, un atacante puede falsificar un token SSO válido a nombre de una cuenta de administrador. A partir de ahí, la petición supera una lista de bloqueo que intentaba impedir palabras como java, process e import, pero la lista distinguía entre mayúsculas y minúsculas y comprobaba patrones concretos, así que basta con cambiar una letra a mayúscula o usar otro nombre de clase importada automáticamente para colarse. El resultado final: dos peticiones GET sin autenticar bastan para llegar a la ejecución de código en cualquier instalación que use SSO.

Por qué esto te importa a ti en concreto

Porque ninguna de las dos es una herramienta marginal. OFBiz es un ERP de código abierto que muchas empresas usan para gestionar inventario, compras y facturación, y Bonita es un motor de flujos de trabajo que impulsa aprobaciones y procedimientos internos. Quien llega a esos dos lugares no se limita a leer datos: se sitúa en medio de tu ciclo operativo, con órdenes de compra, precios de proveedores, expedientes de empleados e historial de clientes. Los investigadores informaron de que ambos proveedores publicaron versiones corregidas dentro del plazo habitual de divulgación de noventa días, lo que significa que la actualización existe y la responsabilidad recae ahora en quien opera el sistema, no en quien lo construyó.

La verdadera carencia del mercado no es la falta de parches, sino la falta de inventario. Muchas organizaciones no tienen una lista actualizada de lo que realmente ejecutan, en qué versión y en qué dominio. Así, una copia antigua de pruebas se queda colgada durante dos años en un subdominio olvidado y se convierte en la puerta en la que nadie pensó.

Qué hacer esta semana

  • Haz inventario de tus sistemas: una lista escrita de cada sistema que ejecutas, su versión, si está expuesto a internet y quién es su responsable, con nombre y apellidos.
  • Actualiza Bonita y OFBiz de inmediato a las versiones corregidas si usas alguno de ellos, y lee la página oficial de seguridad de Apache antes de actualizar.
  • Sustituye todas las claves de cifrado o de firma predeterminadas que venían con el producto. Ningún valor impreso en la documentación es secreto.
  • Cierra las pasarelas de administración al internet abierto y accede a ellas a través de una red privada o de una lista corta de direcciones permitidas.
  • Da de baja las copias antiguas de pruebas y los subdominios sin uso. Son el objetivo más fácil y el menos vigilado.
  • Activa el registro de accesos y consérvalo. Sin registros no podrás responder más adelante si alguien llegó a entrar.

La lección de ingeniería: la red interna no es una frontera de seguridad

La recomendación más importante que deja esta investigación es que el enrutamiento interno debe tratarse con controles del mismo nivel que internet. La vieja idea de que todo lo que está detrás del cortafuegos es seguro ha fracasado en la práctica: un solo fallo de evasión de autenticación convierte cada endpoint interno en uno público. De ahí se derivan tres reglas de ingeniería que deben formar parte de tus estándares de desarrollo:

Nunca confíes en una lista de bloqueo para proteger una operación peligrosa. Si la evaluación de expresiones no es necesaria en una ruta de código, elimínala por completo en lugar de intentar filtrarla.

La segunda regla es no condicionar nunca una operación sensible a un indicador de configuración o a una preferencia de usuario que pueda cambiarse desde dentro del sistema. La tercera es auditar la lógica de los filtros de autenticación en busca de cualquier comparación por subcadena, porque es el error más repetido y más fácil de explotar de esta categoría. Cuando construimos nuevos sistemas de negocio en Origami lo aplicamos por defecto: autorización explícita en cada endpoint y ninguna confianza derivada de la posición de una petición en la red.

La dimensión regulatoria en Arabia Saudí

Si el sistema comprometido contiene datos personales de personas dentro del Reino, deja de ser un asunto puramente técnico. La Ley de Protección de Datos Personales (PDPL) obliga al responsable del tratamiento a adoptar las medidas necesarias para proteger esos datos y a notificar los incidentes que afecten a su privacidad. La Autoridad Nacional de Ciberseguridad (NCA) publica controles esenciales que abarcan la gestión de vulnerabilidades, la aplicación de parches y la gestión de activos, que son precisamente los controles que habrían detenido esta cadena. Ejecutar una versión antigua de un producto con una vulnerabilidad conocida y ya corregida es una posición difícil de defender en cualquier auditoría.

La regla sencilla: trata las actualizaciones de seguridad como un compromiso operativo mensual con un responsable y una fecha, no como una tarea de emergencia que se realiza después de un incidente.

Fuentes

  • Help Net Security — detalles de las cadenas de RCE previas a la autenticación y de CVE-2026-31986: helpnetsecurity.com
  • Página oficial de seguridad de Apache OFBiz: ofbiz.apache.org/security.html
  • Autoridad Nacional de Ciberseguridad (NCA) — controles y marcos regulatorios: nca.gov.sa
  • Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA) — Ley de Protección de Datos Personales: sdaia.gov.sa