La regla que escribe finanzas se ejecuta como código

Una pregunta de negocio, no de boletín de seguridad

Imagine el cierre de mes. Alguien de finanzas ajusta una regla de validación para que una cuenta de gasto deje de rechazar cierto tipo de asiento. Nadie más lo revisa, porque es una configuración y "siempre se ha hecho así". Funciona.

Un mes después, el asiento contable no cuadra con el reporte de tesorería. Alguien pregunta quién cambió qué. La respuesta, en la mayoría de las empresas, es que nadie lo sabe con certeza: no hay versión, no hay aprobación registrada, no hay ambiente de prueba con evidencia, y probablemente la persona que lo hizo ya no recuerda la regla exacta.

Esa escena no requiere ninguna vulnerabilidad para ser un problema. Y esa es la puerta por la que conviene entrar a la noticia de esta semana.

Qué pasó el 13 de octubre

SAP publicó su Patch Day mensual el 13 de octubre de 2026 con 22 vulnerabilidades corregidas, entre ellas cuatro críticas. La más relevante para cualquier empresa que opera el ERP está en la funcionalidad con la que finanzas configura cómo se comporta el sistema.

Se trata de CVE-2026-89107, una inyección de código en SAP S/4HANA, específicamente en la función de administración de reglas de sustitución y validación. Afecta a las versiones S4CORE 105 a 109 y tiene un CVSS de 9.9, la calificación más alta para una falla que exige una cuenta autenticada. El detalle que importa: no requiere un administrador del sistema. Basta un usuario con un rol de negocio específico en las aplicaciones Fiori, es decir, exactamente el tipo de cuenta que tiene un analista funcional.

El vector de la falla incluye el componente de alcance cambiado, que en términos simples significa que el impacto se extiende más allá del componente afectado. No es un bug que rompe una pantalla: permite que texto introducido en un campo de regla sea interpretado por el motor como código ejecutable, con compromiso total del sistema.

Vale una precisión honesta: al 19 de octubre de 2026 no hay evidencia pública de explotación activa de esta vulnerabilidad. Lo que está documentado es el riesgo y la existencia de una cuenta de negocio capaz de alcanzarlo. Esa diferencia importa, y el artículo se sostiene en ella.

Por qué es un problema de integración y no solo de seguridad

Hay tres vulnerabilidades de este mismo ciclo de parches que cuentan la misma historia desde ángulos distintos, y las tres son problemas de costuras entre sistemas.

Visual Composer (CVE-2026-89110, CVSS 9.9). Permite que un usuario de portal con privilegios bajos invoque operaciones internas en un sistema remoto ya preconfigurado. El impacto no depende de la vulnerabilidad en sí: depende de qué conexiones remotas tiene configuradas la empresa. Una integración vieja y amplia multiplica el alcance; una conexión acotada lo limita.

SAP MII (CVE-2026-89108, CVSS 9.1). Un administrador de una aplicación de manufactura puede crear una cuenta administradora en el servidor de aplicaciones Java subyacente. La frontera entre dos sistemas se difumina, y con ella el modelo de permisos que la empresa creía tener.

SAP Cloud SDK for Python (CVE-2026-89111, CVSS 10.0). Una falla de redirección en el flujo OAuth2 permite desviar las solicitudes de token hacia un servidor controlado por el atacante y exfiltrar credenciales. Este SDK es el toolkit oficial para construir aplicaciones y agentes en la plataforma BTP, así que la credencial robada es exactamente la que una integración usa para hablar con SAP.

Leídos juntos, los tres apuntan al mismo lugar: el eslabón débil casi siempre es la costura entre dos sistemas que alguien configuró hace tres años y nadie volvió a revisar.

Las cuatro preguntas que un CTO debe poder responder hoy

Aquí está el valor práctico del artículo. Aplicar el parche es necesario, pero no es la decisión completa. Antes de tocar nada, un director de tecnología debería poder responder cuatro preguntas verificables:

1. ¿Tenemos inventario de las reglas de sustitución y validación, con dueño funcional y dueño técnico? No una lista de qué hace el sistema, sino de qué reglas existen, quién las puede editar y quién responde por su comportamiento.
2. ¿Están probadas en un ambiente con evidencia de que cambian lo que dicen cambiar? Una regla sin prueba es una suposición sobre el comportamiento de la contabilidad.
3. ¿Sabemos qué procesos downstream dependen de cada regla? El CRM, la pasarela de pagos, el reporte de consolidación y el tablero de tesorería consumen resultados de esas reglas. Si la regla cambia, algo aguas abajo cambia con ella.
4. ¿Sabemos qué se rompe si desactivamos la función como mitigación temporal? Porque desactivar el servicio de mantenimiento de reglas, que es la mitigación que se documentó para esta falla, bloquea también la edición de reglas en las aplicaciones relacionadas. El parche rápido del negocio rompe una función de negocio.

Y hay una quinta idea, que suele pasarse por alto: un parche aplicado no es un riesgo cerrado. Algunas correcciones de este ciclo requieren reiniciar la aplicación, y una importación exitosa no es lo mismo que un cambio de seguridad completado. En otros casos se requiere reconstruir y redesplegar. La tarea no termina cuando el sistema de gestión de parches dice que sí.

Qué hacer, sin vender humo

El plan no es complicado, pero tampoco cabe en un sprint. Cuatro pasos, en orden:

Inventariar. Saber cuántas reglas ejecutables tiene el ERP, quién las creó y qué tocan. Sin ese número, cualquier conversación sobre riesgo es una impresión.

Asignar dueño. Cada regla necesita un responsable funcional, que entiende el negocio, y un responsable técnico, que entiende qué ejecuta el motor. Cuando no hay ninguno de los dos, la regla es de nadie.

Poner la capa bajo control. Versión, revisión y prueba. Esto significa que un cambio en una regla que mueve asientos contables pase por el mismo cuidado que cualquier otro cambio que mueve dinero.

Decidir qué integraciones dependen de esa capa. Qué sistemas reciben sus resultados y qué pasa con ellos cuando la regla cambia o se desactiva. Ahí es donde la gobernanza de reglas se vuelve gobernanza de integraciones.

Ese trabajo de inventariar, dar dueño y dejar la capa de reglas e integraciones bajo control es el tipo de revisión de arquitectura que Byxel hace bajo su modelo de Ingeniería de Autor: alguien responde por cada decisión que el sistema ejecuta, incluida la que escribió el área de negocio.

Para seguir leyendo: el fin de soporte de SAP y las integraciones que destapa, las integraciones que nadie cotizó en el ERP y la deuda de integración como pasivo que crece.

La regla es código. Trátela como tal

Una regla de negocio configurada por finanzas no es un dato: es lógica que el sistema ejecuta, que mueve contabilidad y que se propaga hacia los sistemas conectados. Esa definición no cambia con la vulnerabilidad de este mes; la vulnerabilidad solo la hizo visible.

La pregunta que queda es si, después de aplicarlo, podría decir cuántas reglas ejecutables tiene su ERP, quién puede editarlas y qué sistemas dependen de ellas. La empresa que responde eso convierte un boletín de seguridad en una decisión de arquitectura. La que no, se entera del problema cuando el asiento no cuadra.

Si tu equipo no puede responder hoy cuántas reglas de negocio ejecutables tiene tu ERP, quién puede editarlas y qué sistemas dependen de ellas, empecemos por ese inventario. Escribinos por WhatsApp y agendemos una llamada de 30 minutos con nuestro equipo: llegamos con preguntas concretas, no con una presentación.