SAP GUI history flaws expose sensitive data on local clients

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pathlock's research: SAP GUI input history can expose sensitive local client data because Windows storage is weakly encrypted and Java storage is unencrypted.

Why it matters: IAM and security teams should treat local history retention as a governance problem, because exposed client-side input history can leak identifiers, complicate compliance, and widen the blast radius of routine user actions.

Context

SAP GUI input history is a local cache of previously entered values, intended to reduce retyping. In this case, the control boundary is the workstation, not the application server, which means data governance decisions shift onto the client endpoint and its storage model.

The issue matters to identity and access teams because the stored values can include usernames, national IDs, SSNs, bank account numbers, internal table names, and other sensitive fields. When a user interface preserves those values on disk, access control assumptions about the visibility of entered data no longer hold cleanly across Windows and Java client variants.

Key questions

Q: What should teams do when a client application stores sensitive history on local devices?

A: Treat the feature as a data-retention control, not a convenience setting. If the history can contain usernames, IDs, financial values, or internal object names, either disable it or prove that the local storage is strongly protected and operationally necessary. Then remove any pre-existing cached values from endpoints so old data does not remain readable.

Q: Why does weak client-side history storage create an IAM risk?

A: Because the retained values often reveal who uses which systems, what data they handle, and which business workflows they touch. That context can assist phishing, reconnaissance, and authorization abuse even when passwords are not stored. IAM teams should treat this as identity-context leakage, not merely an endpoint hygiene issue.

Q: What are the signs that GUI input history controls are failing?

A: Look for local files that persist across logins, evidence that sensitive fields appear in user history, and inconsistent behavior between client variants. If Windows and Java clients store the same information with different protection levels, the control is already inconsistent and should be reconsidered at the policy level.

Q: Should organisations disable client history or rely on patching it?

A: If the history can contain sensitive data, disabling it is usually the safer governance choice. Patching reduces exposure in a specific release, but it does not remove the underlying design assumption that locally retained history is acceptable. When that assumption is wrong, the feature itself remains the risk.

Technical breakdown

Weak XOR encryption in SAP GUI for Windows

SAP GUI for Windows stores history in a local SQLite database and protects it with a weak XOR-based scheme. XOR is not encryption in the governance sense unless the key is secret, random, and unique per use. Here the same static key is reused for a given user and applied in a predictable cascading pattern, so one known input can reveal the key and unlock other stored values. That turns local history into recoverable plaintext rather than a bounded usability cache.

Practical implication: Treat locally stored client history as readable data unless the storage format and key handling are demonstrably strong.

Unencrypted history storage in SAP GUI for Java

SAP GUI for Java stores history as serialized objects without encryption, which means anyone with file access can inspect the retained values directly. The security failure is not subtle cryptography weakness but the absence of protection at rest on the client. Because the data follows the user profile, roaming profile, or home-directory paths, exposure can persist across environments and be collected by any process or actor that reaches the endpoint storage layer.

Practical implication: Review whether client-side history should exist at all when endpoint file access reveals the underlying values.

Why local input history becomes an identity risk

Input history can capture identity data, financial data, and internal system context even when passwords are excluded. That creates an information spill that supports reconnaissance, spear phishing, authorization workflow abuse, and compliance failures under regimes such as GDPR and PCI DSS. The security problem is therefore broader than confidentiality of a single field: the retained context can help an attacker understand roles, systems, and trusted business processes.

Practical implication: Classify UI history as governed sensitive data, not harmless usability residue.

Threat narrative

Attacker objective: The attacker seeks usable identity and business context from locally stored GUI history to support follow-on access, social engineering, or workflow abuse.

1. Entry occurs through local access to a workstation, roaming profile, or user home directory where SAP GUI history files are stored.
2. Credential or context harvesting follows when the attacker reads weakly protected or unencrypted history files and extracts usernames, identifiers, and other sensitive values.
3. Impact arises when the recovered context is used for reconnaissance, phishing, authorization abuse, or compliance exposure against the SAP environment.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Client-side history retention is a data governance decision, not a UI convenience: When an application stores prior inputs locally, it creates a second data estate outside the core application control plane. That estate must be governed as sensitive data because it can include identity and financial fields that users never intended to persist. The practitioner takeaway is to decide whether the history feature should exist at all, rather than assuming retention is harmless.

Weak local protection collapses the assumption that workstation storage is low risk: Client-side caches were designed for convenience in trusted endpoint contexts. That assumption fails when the cache contains business identifiers and authorization-relevant context, because local file access becomes equivalent to data access. The implication is that endpoint storage boundaries must be treated as part of the identity and data governance model, not as an implementation detail.

Sensitive field history creates an identity blast radius beyond passwords: Even without password storage, usernames, SSNs, bank data, internal table names, and other retained values can help attackers map roles and workflows. That makes the exposure operationally relevant to IAM, compliance, and fraud detection teams. The practitioner conclusion is that retained context should be evaluated by the downstream decisions it enables, not only by the presence of secrets.

Patch-only thinking is too narrow when the failure mode is structural: The article points to stronger versions and mitigation steps, but the deeper issue is that the feature itself persists data that users and teams may wrongly assume disappears. That is a structural governance problem, not merely a vulnerability management problem. The practitioner response is to treat persistence as the risk signal, then decide whether disabling history is the only defensible control.

Named concept: local input history exposure: This is a useful label for a recurring class of failures where UI convenience features retain sensitive user input on endpoints longer than their governance model anticipates. It matters because these stores are often outside central monitoring and access review. Practitioners should map any client-side retention feature to the same exposure analysis before accepting it in production.

What this signals

Local input history exposure: Client-side convenience features often outlive the governance assumptions that justified them. Once a workstation cache can contain identity, finance, or internal-system context, the retention model becomes part of the attack surface and should be reviewed like any other sensitive data store.

SAP GUI-like history features show why endpoint data handling belongs in IAM and compliance discussions, not just application support. The practical question is whether preserving prior inputs helps the business enough to justify the risk of exposing those values on a user device.

For practitioners

• Disable client-side input history where it captures sensitive fields Turn off SAP GUI history for Windows and Java wherever business processes can tolerate it, and do not rely on patching alone when local retention is the exposure mechanism.
• Remove existing history files from affected endpoints Delete cached .db files and serialized history objects from the documented local storage paths after disabling the feature so older values do not remain recoverable.
• Review endpoint storage for identity and finance data Inventory whether local workstation caches contain usernames, national IDs, bank details, internal table names, or similar high-value fields that should never be retained in user history.
• Treat GUI history as governed sensitive data Update data handling rules so client-side history is classified, reviewed, and audited like other sensitive records rather than being exempt because it sits on a user device.

Key takeaways

• Client-side input history can become a hidden sensitive-data store when applications retain usernames, identifiers, and other entered values on local devices.
• The exposure matters because weak local protection and unencrypted storage make routine workstation access enough to reveal business context that attackers can reuse.
• The strongest control is often to disable the history feature entirely and remove any cached values that already exist on endpoints.

Key terms

• Client-Side History Exposure: A condition where an application keeps previously entered values on the user device in a form that is easier to read or recover than the user expects. In identity programmes, this matters because the retained data can include sensitive business and identity context even when authentication secrets are not stored.
• Data Retention: Data retention is the practice of keeping records for a defined period to satisfy legal, regulatory, audit, or business requirements. In security programmes, retention should be tied to data class and purpose, because keeping information longer than necessary increases storage cost, discovery burden, and exposure if the data is later compromised.
• Identity-context leakage: Identity-context leakage is the loss of control that happens when a user’s authenticated identity looks legitimate but the data they send is handled outside enterprise policy. In browser-based AI use, the account may be known, yet the prompt, upload, or model relationship escapes governance.

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 building or maturing an IAM programme, it is worth exploring.