---
service: "Publicasta"
schema_version: "1.0"
article_id: 577
title: "Las fallas del kernel de SAP de septiembre de 2026 exigen inventariar y aplicar parches"
language: "es"
default_language: "en"
canonical_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=es"
json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=es"
api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=es"
channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity"
channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-09-10T13:50:47+00:00"
updated_at: "2026-09-10T13:50:47+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ar"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ar"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=de"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=de"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=en"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=es"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=es"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=fr"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=fr"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=pl"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=pl"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ru"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ru"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=zh"
    markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=zh"
    json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=zh"
---

# Las fallas del kernel de SAP de septiembre de 2026 exigen inventariar y aplicar parches

> OVERPASS y S4GET afectan rutas de comunicación esenciales de SAP y pueden poner en riesgo un paisaje ERP completo. La prioridad es comprobar qué componentes están expuestos, corregirlos y verificar que los procesos activos usan las versiones reparadas.

El Security Patch Day de SAP de septiembre de 2026 contiene dos vulnerabilidades críticas que merecen atención inmediata en las organizaciones que operan paisajes SAP. Una es una falla de máxima gravedad en SAP Kernel, relacionada con el procesamiento de Extended Passport, registrada como CVE-2026-44756 y apodada OVERPASS por Onapsis Research Labs. La otra, CVE-2026-58240, afecta a SAP NetWeaver Message Server y ha sido denominada S4GET. En los sistemas afectados, ambas pueden alcanzarse remotamente sin autenticación.

 ![Sala de servidores empresariales con un mapa de red abstracto e indicadores de parches de seguridad](https://publicasta.com/storage/projects/9/pages/577/2026/09/0eecf113-0be8-4e9f-9929-205dcb47ba8d.webp)

 La cuestión importante no es afirmar que todas las instalaciones de SAP ya estén comprometidas. El problema es que estas fallas se encuentran en infraestructura compartida por varias rutas de comunicación, incluidas algunas que los administradores pueden considerar protegidas solo porque la aplicación empresarial principal no está expuesta directamente a internet. Por eso, la primera tarea no consiste en esperar un informe espectacular de intrusión. Consiste en determinar qué componentes del kernel y de Message Server existen, si pueden alcanzarse desde redes hostiles y si las correcciones del proveedor se instalaron y se activaron mediante un reinicio efectivo.

 Este artículo se centra en la pregunta defensiva: ¿cómo puede el responsable de un entorno SAP convertir un aviso de alta gravedad en pruebas concretas sobre su propia infraestructura?

 ## Qué divulgó SAP el 8 de septiembre

 SAP publica un Security Patch Day periódico el segundo martes de cada mes. Su boletín de septiembre de 2026 enumera las notas de seguridad pertinentes, las versiones de producto afectadas y las correcciones para las versiones con soporte. Los dos problemas tratados aquí no son errores ordinarios de una aplicación confinados a una función empresarial opcional. Afectan a SAP Kernel y NetWeaver Message Server, componentes que pueden situarse por debajo de varios productos y protocolos.

 CVE-2026-44756 se corrige mediante la SAP Security Note 3747649. El problema subyacente se describe como una validación insuficiente de límites mientras SAP Kernel procesa datos de Extended Passport. Extended Passport es una estructura de trazabilidad que acompaña a las solicitudes. En una implementación vulnerable, los datos malformados pueden provocar corrupción de memoria u otro comportamiento indefinido. El registro de la CVE describe una condición alcanzable por red, con gran impacto potencial sobre la confidencialidad, la integridad y la disponibilidad. Onapsis evalúa la consecuencia práctica como una posible ejecución de comandos del sistema operativo en el host SAP.

 CVE-2026-58240 se corrige mediante la SAP Security Note 3759472. Se trata de una comprobación de autenticación ausente en SAP NetWeaver Message Server, concretamente en el componente identificado como BC-CST-MS. Message Server coordina el registro y la comunicación de los servidores de aplicaciones dentro de un entorno SAP. Un sistema que acepta como confiable a un componente no autorizado puede convertir una frontera pensada para miembros internos del clúster en una ruta hacia un compromiso más amplio.

 ¿La Agencia de la Unión Europea para la Ciberseguridad? No. El resumen técnico relevante procede de CERT-EU, el equipo de respuesta ante emergencias informáticas de las instituciones, organismos, oficinas y agencias de la Unión Europea. CERT-EU considera grave la preocupación operativa porque ambas vulnerabilidades pueden explotarse remotamente sin autenticación y recomienda aplicar cuanto antes las dos notas de seguridad de SAP.

 ## Por qué el problema del kernel supera a un único endpoint web

 El nombre OVERPASS puede hacer que el problema parezca una falla limitada de una función concreta. No es así. El procesamiento de Extended Passport es una capacidad compartida del kernel. Onapsis afirma que el procesamiento vulnerable puede alcanzarse mediante más de un protocolo y más de una capa orientada a SAP. Entre las rutas señaladas están la capa web expuesta a internet, las comunicaciones relacionadas con SAP GUI y las conexiones RFC entre sistemas SAP.

 Eso no significa que todos los protocolos estén expuestos en todas las implementaciones. Sí significa que la frase «nuestra interfaz web de SAP está detrás de una VPN» no basta para cerrar la investigación. El mismo código del kernel puede estar presente en un sistema accesible mediante un proxy inverso, un diseño de acceso remoto, una conexión de socios, un segmento interno de integración u otro sistema SAP. La pregunta correcta es: ¿qué binarios afectados del kernel están instalados, qué interfaces los cargan y qué entidades de red pueden alcanzar esas interfaces?

 La distinción importa durante la clasificación inicial. Una vulnerabilidad puede ser no autenticada sin estar publicada en internet. Un atacante interno, una estación de trabajo comprometida, una red de un socio vulnerada o una zona de administración mal segmentada pueden bastar si el servicio relevante es accesible. A la inversa, un servicio realmente aislado sigue necesitando el parche, porque las suposiciones de aislamiento cambian y porque el componente vulnerable puede reutilizarse después de una modificación arquitectónica.

 Onapsis ha decidido no publicar detalles de explotación en su aviso público. Para los defensores, esto resulta útil: hay información suficiente para priorizar la corrección sin convertir un artículo informativo en una guía de explotación. También significa que los equipos de seguridad no deben usar la ausencia de una prueba de concepto pública como motivo para aplazar la respuesta.

 ## Por qué S4GET cambia el análisis de la frontera de confianza

 La segunda vulnerabilidad funciona de otra manera, pero puede tener una consecuencia parecida. NetWeaver Message Server está diseñado para coordinar componentes de un clúster SAP. Ese diseño depende de distinguir los servidores de aplicaciones legítimos de los sistemas no autorizados. CVE-2026-58240 indica que la comprobación de autenticación correspondiente es insuficiente en las versiones afectadas.

 Según el resumen de CERT-EU sobre los hallazgos del investigador, un actor no autenticado con acceso de red puede registrar un componente no autorizado. Onapsis describe el riesgo como la posibilidad de que un atacante se presente como un nodo confiable y propague esa confianza por el clúster. Si tiene éxito, el resultado puede incluir la ejecución de comandos del sistema operativo usando la cuenta que ejecuta SAP.

 Por eso importa la ubicación de red. Message Server no es simplemente otro puerto que se pueda cerrar después de instalar el parche de la aplicación. Forma parte del plano de control de un paisaje SAP. Si es accesible desde una red de usuarios, un segmento amplio de servidores, una red de socios o internet, la población que puede alcanzarlo entra en el cálculo del riesgo. Sin embargo, el filtrado de red es un control compensatorio, no un sustituto de la corrección del proveedor. Puede reducir la exposición mientras se prepara un cambio; no puede reparar una comprobación de confianza defectuosa.

 Onapsis también señala una limitación operativa difícil: la ruta vulnerable puede estar asociada al mismo puerto público que utilizan los clientes SAP GUI. Bloquearlo indiscriminadamente podría interrumpir los inicios de sesión legítimos. Es una advertencia útil contra los cambios urgentes de firewall realizados sin el responsable de la aplicación. La respuesta debe combinar el parche, un mapa de exposición verificado y restricciones específicas que mantengan el tráfico empresarial necesario.

 ## Qué está afectado

 Las listas de versiones afectadas son técnicas y deben contrastarse con el inventario exacto de componentes SAP, no con el nombre de un producto introducido en un escáner. CERT-EU informa de las siguientes familias generales para CVE-2026-44756: KRNL64NUC 7.22 y 7.22EXT; KRNL64UC 7.22, 7.22EXT, 7.53 y 8.04; KERNEL 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19 y 9.20; y WEBDISP 9.16, 9.18, 9.19 y 9.20. La compilación vulnerable exacta y la compilación corregida dependen de la nota de seguridad de SAP y de la combinación de plataformas.

 Para CVE-2026-58240, las familias afectadas comunicadas por CERT-EU son KERNEL 9.16, 9.18, 9.19 y 9.20. El problema está asociado al componente NetWeaver Message Server BC-CST-MS, de modo que una comprobación genérica de «servidores SAP» producirá falsos positivos y falsos negativos si no se vincula con los datos de componentes instalados y niveles de parche.

 Estas listas no deben interpretarse como permiso para deducir seguridad a partir de una cadena de versión diferente. Los paisajes SAP suelen contener varios sistemas, binarios antiguos del kernel conservados por compatibilidad, servidores de aplicaciones con niveles de parche distintos, web dispatchers, entornos de desarrollo y calidad, y conexiones entre sistemas que no aparecen en el mismo inventario utilizado para los activos expuestos a internet. Una respuesta completa debe incluirlos a todos.

 ## Estado de explotación: urgencia no equivale a una intrusión confirmada

 La evidencia pública disponible el 9 de septiembre no demuestra que ninguna de las dos vulnerabilidades se esté explotando a gran escala en la naturaleza. Onapsis afirma que no había observado explotación activa de OVERPASS en el momento de publicar su aviso. CERT-EU recomienda una corrección inmediata porque el impacto técnico y el alcance remoto sin autenticación convierten las vulnerabilidades en un riesgo elevado, no porque informe de una campaña confirmada contra todos los clientes de SAP.

 Conviene conservar esa distinción. «Crítica» es una señal de gravedad y de prioridad. «Explotada activamente» es una observación sobre el comportamiento de los atacantes. No son expresiones intercambiables. Un proceso responsable de respuesta ante incidentes no debe declarar una intrusión basándose solo en la puntuación de una CVE, ni descartar la CVE porque todavía no se haya documentado una campaña pública.

 Los equipos de seguridad deben vigilar las actualizaciones del proveedor, los avisos de CERT-EU o de los CERT nacionales y su propia telemetría. La evidencia local vale más que el ruido general de internet: registros inesperados de Message Server, procesos nuevos bajo la cuenta del sistema operativo de SAP, actividad administrativa inusual, cambios inexplicados en perfiles o archivos del kernel, conexiones RFC anómalas y tráfico saliente desde hosts SAP hacia destinos que la empresa no utiliza son motivos para escalar la revisión. Estos indicios no prueban por sí solos una intrusión, pero pueden ayudar a decidir si basta con aplicar el parche o si también hace falta una respuesta ante incidentes.

 ## Una secuencia práctica de respuesta

 ### 1. Asignar un responsable y congelar las suposiciones

 Designe a una persona o equipo para coordinar la administración de SAP Basis, las operaciones de seguridad, la ingeniería de red y al responsable empresarial del sistema afectado. El coordinador debe registrar decisiones y marcas de tiempo. Así se evita un fallo habitual del parcheado empresarial: el equipo Basis cree que el firewall es responsable de la exposición, el equipo de firewall cree que la aplicación ya fue corregida y nadie tiene pruebas de que haya cambiado el proceso en ejecución.

 No empiece únicamente con un escaneo genérico de vulnerabilidades. Comience con el inventario autorizado de sistemas SAP y confirme cuáles están realmente activos. Incluya producción, recuperación ante desastres, aseguramiento de calidad, desarrollo, sandboxes, concentradores de integración, web dispatchers y sistemas temporales usados para migraciones o pruebas.

 ### 2. Mapear los binarios afectados y las rutas de red activas

 Para cada sistema, registre la familia del kernel instalada, el nivel exacto de parche, el sistema operativo, la presencia de Message Server, la presencia de web dispatcher, la exposición de SAP GUI o RFC y las zonas de red que pueden alcanzar los servicios relevantes. Compare la versión instalada con la versión corregida especificada en las SAP Security Notes 3747649 y 3759472.

 El mapa debe responder preguntas concretas: ¿algún servicio relevante está vinculado a una dirección enrutable externamente? ¿Puede una estación de trabajo de usuario alcanzarlo directamente? ¿Puede acceder una red de socios o de integración? ¿Existen rutas alternativas mediante un balanceador, proxy inverso, concentrador VPN, bastion host o grupo de seguridad en la nube? ¿Se han probado recientemente la segmentación entre producción y no producción y sus reglas reales?

 Registre las pruebas, no solo la conclusión. Un ticket que diga «no expuesto» es débil. Un ticket que identifique la interfaz, la política de firewall, la fecha de la última validación y al responsable que la aprobó puede revisarse cuando cambie la arquitectura.

 ### 3. Aplicar las correcciones del proveedor, reiniciar y verificar

 Siga las notas de seguridad publicadas por SAP y el proceso de cambios de la organización. Las actualizaciones del kernel suelen requerir coordinación entre instancias, sistemas operativos, configuraciones de alta disponibilidad y ventanas de mantenimiento. Copiar un archivo en un servidor no equivale a que un proceso activo esté utilizando la compilación corregida.

 Después del cambio, verifique la versión en ejecución de cada instancia relevante. Compruebe que todos los servidores de aplicaciones del clúster utilizan el nivel de kernel previsto. Revise por separado los web dispatchers y los demás componentes. Confirme que no se ha dejado atrás un nodo de conmutación por error, un entorno de recuperación ante desastres o una instancia que parecía inactiva. Si el entorno utiliza automatización, conserve el resultado del despliegue y compárelo con pruebas independientes del estado en ejecución.

 El criterio de éxito no es «el trabajo de parcheado terminó». Es «cada servicio afectado dentro del alcance ejecuta la versión corregida, el cambio quedó registrado y la evaluación de accesibilidad sigue coincidiendo con la arquitectura desplegada».

 ### 4. Utilizar controles temporales mientras se prepara el parche

 Si una actualización inmediata es imposible, reduzca la exposición sin suponer que la medida temporal resuelve el defecto. Limite el acceso a los servicios SAP al conjunto mínimo de redes autorizadas. Elimine la exposición innecesaria a internet. Restrinja las interfaces administrativas y las rutas de Message Server desde redes de usuarios y socios cuando el diseño empresarial lo permita. Revise las reglas del proxy inverso y del balanceador, no solo el firewall del servidor.

 Para S4GET, tenga especial cuidado con el bloqueo generalizado de puertos. Una regla que rompa SAP GUI o la comunicación del clúster puede crear un incidente de disponibilidad sin eliminar todas las rutas hacia el componente vulnerable. Realice los cambios junto con el responsable de SAP Basis, pruébelos contra el tráfico necesario y conserve un plan de reversión.

 Si un sistema no puede parchearse pronto, documente el motivo, los controles compensatorios, la persona que acepta el riesgo y la fecha de reevaluación. «Lo parchearemos más adelante» no es un plan de mitigación.

 ### 5. Buscar indicios de compromiso

 El parche sigue siendo necesario aunque no haya indicadores sospechosos. Tampoco es suficiente si existe la posibilidad de que el sistema ya haya sido accedido. Revise la creación de procesos del sistema operativo, la integridad de archivos, las tareas programadas, las definiciones de servicios, los registros de auditoría de seguridad de SAP, los registros de Message Server y de las aplicaciones, los eventos de autenticación, los cambios administrativos y las conexiones de red alrededor del periodo anterior al parche. Preserve los registros relevantes antes de que las ventanas de retención los eliminen.

 La revisión debe incluir las cuentas del sistema operativo de SAP y los usuarios SAP privilegiados, pero no debe detenerse ahí. Un atacante que alcance el host puede manipular el sistema operativo sin crear un inicio de sesión de diálogo SAP evidente. Busque binarios inexplicables, scripts de arranque modificados, cuentas locales nuevas, conexiones salientes inusuales y cambios en la ubicación o propiedad de los archivos del kernel.

 Si las pruebas sugieren un compromiso, aísle el sistema con cuidado junto con el equipo de respuesta ante incidentes y el responsable de SAP. No borre la máquina ni rote todas las credenciales a ciegas antes de recopilar las pruebas necesarias para comprender el alcance. La rotación de credenciales, la decisión de reconstruir el sistema y las medidas de continuidad empresarial deben seguir el procedimiento de incidentes de la organización.

 ## Qué significa el aviso para cada equipo

 Los administradores de SAP Basis deben tratar las dos notas de seguridad como una tarea de inventario y parcheado de todo el paisaje. El riesgo principal consiste en dejar atrás una instancia, un dispatcher o un entorno de recuperación. Basis también debe comprobar que el kernel corregido está en ejecución, en lugar de confiar únicamente en el estado que informa el sistema de despliegue.

 Los equipos de red deben validar las rutas reales hacia los servicios SAP, incluidas las que no aparecen como una exposición ordinaria a internet. Deben revisar grupos de seguridad, balanceadores, políticas VPN, conexiones de socios y la segmentación entre redes de usuarios, servidores, desarrollo y administración. No deberían aplicar un cambio de firewall de una sola línea sin comprender la comunicación del clúster y de los clientes SAP.

 Los equipos de operaciones de seguridad deben enriquecer la monitorización de actividad sospechosa alrededor de los hosts SAP y las cuentas del sistema operativo. Deben comparar el momento de divulgación del aviso con la telemetría local y preservar las pruebas mientras los registros sigan disponibles. Un ticket de vulnerabilidad y un ticket de incidente son objetos distintos; uno no sustituye al otro.

 Los equipos de identidad y acceso deben revisar las cuentas privilegiadas de SAP y del sistema operativo si existe cualquier indicio de explotación. Corregir el software no deshace comandos que ya pudieron ejecutarse, credenciales que pudieron leerse ni relaciones de confianza que pudieron modificarse.

 Los responsables empresariales deben ayudar a decidir qué sistemas requieren mantenimiento de emergencia y qué tráfico es realmente necesario. SAP suele formar parte de las operaciones financieras, manufactureras, logísticas, de nómina, compras o atención al cliente. La respuesta debe ser rápida, pero una interrupción precipitada puede crear su propio riesgo grave.

 ## Preguntas que deben responderse antes de cerrar el ticket

 Un registro de cierre defendible debería poder responder a todas estas preguntas:

 - ¿Qué sistemas SAP y familias de kernel se revisaron?
- ¿Qué instancias, web dispatchers y Message Servers quedaron dentro del alcance?
- ¿Qué versiones exactas en ejecución se observaron antes y después de la actualización?
- ¿Qué sistemas podían alcanzarse desde internet, redes de usuarios, redes de socios u otros sistemas SAP?
- ¿Se aplicaron las Security Notes 3747649 y 3759472 donde correspondía?
- ¿Se verificaron todos los miembros del clúster, sistemas en espera y sistemas de recuperación ante desastres?
- ¿Qué controles de red temporales se utilizaron y quién los aprobó?
- ¿Qué registros y datos de telemetría se revisaron para detectar una posible explotación?
- ¿La revisión encontró procesos, registros, acciones administrativas o conexiones salientes sin explicación?
- ¿Quién aceptó cualquier riesgo residual y cuándo volverá a revisarse?

 Si la respuesta a una de estas preguntas es «no lo sabemos», el trabajo no está terminado. Puede ser razonable pasar al siguiente paso operativo, pero la incertidumbre debe quedar explícita.

 ## Una conclusión serena

 OVERPASS y S4GET son graves porque combinan un impacto elevado con accesibilidad remota y sin autenticación en infraestructura SAP compartida. No son motivo para suponer que todos los clientes de SAP han sido comprometidos, y la información pública disponible el 9 de septiembre no demuestra una explotación generalizada en la naturaleza. Sí son motivo para dejar de tratar el parcheado del kernel SAP como una tarea de mantenimiento limitada.

 La respuesta útil es disciplinada: inventariar el paisaje real, mapear las rutas reales, aplicar las correcciones de SAP, reiniciar y verificar cada componente afectado, utilizar restricciones de red cuidadosamente delimitadas durante el cambio y revisar la telemetría en busca de señales de acceso previo. Esa secuencia produce algo más valioso que el pánico o la tranquilidad infundada: una respuesta documentada sobre qué está expuesto, qué se ha corregido y qué sigue necesitando atención.

 ### Fuentes y alcance

 Los datos técnicos de este artículo se basan en los materiales del Security Patch Day de SAP de septiembre de 2026, el aviso de CERT-EU sobre las dos vulnerabilidades, los informes de divulgación responsable de Onapsis Research Labs y los registros públicos de las CVE citados por CERT-EU. La corrección específica de cada producto debe seguir las notas de seguridad actuales de SAP disponibles para la cuenta de SAP Support del cliente.
