Notifications
Clear all
Topic starter
25/06/2026 1:17 am
TL;DR: SAP GUI input history is stored weakly encrypted on Windows and unencrypted on Java clients, creating local data exposure that can surface usernames, identifiers, and other sensitive fields; SAP issued patches and mitigations in January 2025, according to Pathlock research. The real issue is not just encryption strength but the governance assumption that client-side history is safe enough to retain.
NHIMG editorial — based on content published by Pathlock: SAP GUI input history vulnerabilities and the risk of local data exposure
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Pathlock's full research covers the technical detail this post intentionally leaves for the source:
- XOR reversal steps for the Windows SAP GUI cache and the known-plaintext weakness behind it
- File paths and storage locations for both Windows and Java client histories across operating systems
- Patch-level details and the fallback condition that still leaves some clients exposed
- ABAP-side follow-on analysis showing how the same structural weakness appeared in SAP NetWeaver Application Server
👉 Read Pathlock's research on SAP GUI history exposure and client-side data risk →
SAP GUI input history exposure: what IAM teams need to know?
Explore further
25/06/2026 10:35 am
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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: SAP GUI history flaws expose sensitive data on local clients
