SAP GUI history flaws expose sensitive data on local clients

At a glance

What this is: Pathlock’s research identifies two SAP GUI input history flaws that expose locally stored sensitive entries on Windows and Java clients.

Why it matters: IAM and security teams need to treat client-side history as a governance problem because exposed local data can aid reconnaissance, phishing, and unauthorized access workflows across human and enterprise identity programmes.

👉 Read Pathlock's research on SAP GUI history exposure and client-side data risk

Context

SAP GUI input history is a local convenience feature, but in this case it becomes a data retention risk. The feature stores previously entered values on endpoint machines, including usernames, identifiers, and other sensitive fields that can be recovered if the storage layer is weak or absent. For identity and access teams, this is a reminder that endpoint-held identity artefacts fall inside the governance perimeter even when they are not stored centrally.

The governance gap is straightforward: organisations often focus on authentication and transport security while overlooking what the client keeps after a session ends. When business applications cache sensitive inputs locally, those artefacts can be used for phishing, reconnaissance, and abuse of authorisation workflows. That makes SAP GUI history a control issue for IAM, compliance, and endpoint hardening teams alike.

Key questions

Q: What breaks when SAP GUI history is left enabled on shared or regulated endpoints?

A: Client-side history becomes a recoverable source of sensitive identity and business data. On shared or regulated endpoints, that data can support phishing, reconnaissance, and authorisation abuse even when passwords are not stored. The control failure is persistence: the application keeps useful context after the session, outside normal IAM review and retention processes.

Q: Why do locally stored application inputs create IAM risk beyond privacy concerns?

A: Because stored inputs often contain identity context that attackers can reuse operationally. Usernames, account numbers, internal field names, and similar values help attackers target the right person, imitate legitimate workflows, and move from information exposure to access abuse. IAM teams should treat that context as security-relevant, not only as personal data.

Q: How do security teams know whether SAP GUI history controls are working?

A: They should verify that history is disabled, that endpoint files no longer exist, and that roaming or profile rebuilds do not recreate the cache. The useful signal is absence of the artefact on endpoints that process sensitive records, not reliance on patch status alone.

Q: Who is accountable when client-side input history exposes regulated data?

A: Accountability sits across application ownership, endpoint administration, and identity governance. If the client retains sensitive values locally, then patching alone is not sufficient because the exposure also reflects configuration, retention, and control-design choices. Teams should assign clear ownership for disabling, verifying, and auditing those client features.

Technical breakdown

Weak XOR encryption in SAP GUI for Windows

SAP GUI for Windows stores input history in a local SQLite database and protects it with a weak XOR-based scheme. XOR is not encryption on its own; security depends on a secret key that is random, unique, and protected. In this case, the same static key is reused for all entries for a given user, which means one known plaintext value can reveal the key pattern and expose other stored values. That turns local history into recoverable identity and business data rather than protected cache material.

Practical implication: treat locally stored SAP GUI history as readable data unless the feature is disabled and the cache is removed.

Unencrypted serialized storage in SAP GUI for Java

The Java version stores history as serialized objects with no effective encryption, so anyone with access to the workstation or its profile data can inspect the file contents. Because the storage location varies by operating system, the exposure follows the user profile rather than the application server. That matters because endpoint compromise, shared workstations, or simple file access can expose values that should never persist after a transaction is complete.

Practical implication: inventory every client platform using SAP GUI for Java and remove the history artefact from endpoint retention policies.

How stored history becomes an access-enablement layer

The value of the exposed data is not limited to disclosure. Stored usernames, national IDs, bank details, internal table names, and similar fields give an attacker structured context for phishing, social engineering, and workflow abuse. In an enterprise application environment, that context can help an attacker sound credible, target the right user, and move from information theft to authorisation abuse. The issue is therefore not only confidentiality but also downstream identity and access manipulation.

Practical implication: classify client-side history as a source of privileged context and remove it from environments where users handle sensitive records.

Threat narrative

Attacker objective: The attacker wants usable identity context and sensitive business data that can support follow-on access abuse, fraud, or targeted social engineering.

1. Entry occurs when an attacker gains access through a compromised workstation, HID injection, or phishing against a user who has SAP GUI history enabled.
2. Credential and context harvesting follow as the attacker extracts locally stored inputs, including usernames, identifiers, and application-specific values from the history files.
3. Impact comes when the recovered context is used to support phishing, reconnaissance, or authorisation workflow abuse against SAP users and processes.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Client-side history retention is a governance failure, not a usability detail. When a business application stores prior inputs on the endpoint, it moves sensitive identity context outside the normal control plane. That creates a retention problem for IAM, not just a software issue, because the data outlives the session and can be harvested outside the application boundary. The practical conclusion is that endpoint-held identity artefacts need the same governance discipline as centrally managed credentials.

Weak local encryption creates an identity blast radius that reaches beyond the workstation. The exposed values are not only personal data. They are also contextual inputs that can strengthen phishing, accelerate reconnaissance, and make authorisation abuse more effective. That means storage weakness in a client application can become an IAM problem across users, systems, and downstream workflows. Practitioners should treat client caches as attack-enabling identity infrastructure, not harmless convenience data.

Access reviews cannot compensate for data that should never have persisted. Governance processes usually assume that retention is intentional and reviewable, but cached history breaks that premise. Once sensitive entries are written to local storage, the organisation has already lost part of the control story, because the risky artefact exists outside the normal entitlement lifecycle. The implication is that programme owners must reconsider which user-facing application features are allowed to generate durable identity context.

Input history offboarding is a lifecycle control, not a patching decision. SAP’s mitigations reduce exposure, but the underlying governance question is whether the feature should exist in regulated or high-risk environments at all. Lifecycle thinking matters here because the right control may be removal, not preservation with stronger encryption. Practitioners should align client application settings with data minimisation and identity governance requirements, not only with vulnerability management schedules.

Known-plaintext weaknesses in legacy enterprise software remain an active identity risk. Legacy systems often keep convenience features that were never designed for modern threat models or compliance expectations. This research shows that static local secrets, weak obfuscation, and retained input history can combine into an exploitable chain even in mainstream enterprise software. The practitioner conclusion is that legacy client review must be part of NHI and IAM governance, not left to ad hoc application teams.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For a broader breach lens, The 52 NHI breaches Report shows how exposed identity artefacts turn into repeatable attack patterns across environments.

What this signals

Client-side retention is becoming part of the identity attack surface. When application inputs persist on endpoints, the control question shifts from authentication success to data survival after use. That matters because identity programmes built only around centrally managed entitlements miss a growing class of locally stored identity context, especially in regulated workflows.

Input history offboarding should sit beside secrets and session controls in operational reviews. If a client feature keeps sensitive values after the task is done, the issue is not patch cadence alone but whether the feature belongs in the environment at all. Organisations that handle financial, HR, or master-data workflows should treat local cache review as part of their access governance cycle.

The pattern reinforces a broader governance signal: convenience features in enterprise clients often age into security liabilities when workloads become more sensitive. Teams that already map data flows, endpoint retention, and access lifecycle together will spot these issues earlier and remove them before they become audit findings or phishing fuel.

For practitioners

• Disable SAP GUI input history where sensitive data is entered Turn off history in Windows and Java clients for users handling identifiers, account numbers, or internal table names, then verify the setting through configuration review.
• Remove existing history files from endpoints Delete the SQLite database and serialized history files from user profiles after disabling the feature, and confirm the files do not return through profile roaming or rebuilds.
• Review client-side data retention in regulated workflows Map where SAP GUI and similar enterprise clients retain user inputs locally, then classify those caches as controlled data stores in your retention and audit model.
• Align endpoint hardening with IAM governance Require endpoint teams, SAP administrators, and IAM owners to share responsibility for client settings that can expose identity context outside the application boundary.

Key takeaways

• SAP GUI history creates a local exposure path because sensitive values are retained on endpoints instead of being discarded after use.
• The research shows that weak or absent encryption on client history turns ordinary usability data into material for reconnaissance, phishing, and workflow abuse.
• Disabling the history feature and removing existing cache files is the control that most directly limits the risk in regulated environments.

Key terms

• Client-Side History Retention: The practice of storing previous user inputs on an endpoint so the application can reuse them later. In security terms, it is durable data storage that can outlive the session and expose identity context, regulated information, or workflow clues if the local files are accessible.
• Known-Plaintext Attack: A technique where an attacker uses one known piece of stored content to reveal how a weak protection scheme works. In this case, if the same value or pattern is reused, the attacker can recover the wider data set rather than just one field.
• Identity Context: The user-related information that helps prove, target, or imitate legitimate business activity, such as usernames, account references, and internal field values. It is not a credential by itself, but it can materially strengthen phishing, reconnaissance, and access abuse when exposed.
• Endpoint Data Retention: The persistence of application or user data on laptops, desktops, or shared workstations after a task is complete. For identity teams, this matters because retained local artefacts can become part of the attack surface and should be governed like any other sensitive store.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pathlock: SAP GUI input history vulnerabilities and the risk of local data exposure. Read the original.