As an SAP Security Analyst and Lead Researcher at Pathlock, I believe that responsible security research is the foundation for maintaining secure IT environments. Today, I am excited to disclose research on two vulnerabilities in the SAP Graphical User Interface (SAP GUI) input history feature, which we identified together with Julian Petersohn of Fortinet.

This disclosure follows coordinated reporting with SAP’s security response team, who have since issued relevant patches and mitigation steps in January 2025. The SAP team has been working closely with us throughout the entire process, for which we express our gratitude.

Download Whitepaper

Background

SAP, the ERP platform used by over 400,000 organizations worldwide – relies on SAP GUI as one of its primary interfaces for daily operations. SAP GUI facilitates the functionality of various SAP modules, including Financial Accounting (FI), Materials Management (MM), Human Resources (HR), and Sales and Distribution (SD).

The SAP GUI user history functionality is designed to enhance usability by storing frequently entered user inputs – such as usernames, field values, and other data – to reduce the need to repeatedly type commonly used entries. This data is stored locally on users’ machines. This data can include personally identifiable information (PII) depending on end users’ job function. Examples are addresses, user IDs, Social Security Numbers (SSNs), bank account or credit card numbers, and more.

Vulnerability: Weak Encryption Mechanism + Insecure Local Storage

The research discovered that SAP GUI input history is stored insecurely, both in the Java and Windows versions.

SAP GUI for Windows Vulnerability (Tracked as CVE-2025-0055)

At its core, SAP GUI for Windows stores previously entered input values in the user’s roaming profile directory under:

%APPDATA%\LocalLow\SAPGUI\Cache\History

These inputs are saved in a SQLite3 database file (SAPHistory<WINUSER>.db) using a weak XOR-based encryption scheme, which makes them trivial to reverse with minimal effort.

Why XOR Is Not Secure

XOR is a fundamental binary operation used extensively in computer science and cryptography. Although XOR is computationally efficient, its security depends entirely on the randomness and secrecy of the key. Reusing keys or applying predictable patterns makes XOR-based encryption vulnerable to attacks.

The research has shown:

• SAP’s XOR implementation reuses the same static key for all entries of a given user.
• The key is applied in a cascading pattern.
• One known input is enough to reverse-engineer the full key and decrypt other history values.

For a detailed technical breakdown of the XOR encryption foundation, limitations, as well as its weakness in SAP GUI, please go to the research paper, 3.2, Page 4.

SAP GUI for Java Vulnerability (Tracked as CVE-2025-0056)

For SAP GUI for Java, history entries are stored completely unencrypted as Java serialized objects. Their storage path varies by OS:

– Windows/Linux: %APPDATA%\LocalLow\SAPGUI\Cache\History or $HOME/.SAPGUI/Cache/History
– macOS: $HOME/Library/Preferences/SAP/Cache/History

Anyone with access to the computer can potentially access the history file and all sensitive information it stores.

Exploitation Potential

Because the data is stored locally and weakly (or not at all) encrypted, exfiltration through HID injection attacks (like USB Rubber Ducky) or phishing becomes a real threat. The paper demonstrates in clear detail how the XOR encryption can be reversed using a known plaintext attack, exposing a systemic design flaw rather than an implementation bug.

Even though password fields are not stored in user input history of SAP GUI, sensitive identifiers like usernames, national IDs, SSNs, bank account numbers, or internal SAP table names can be extracted from these history files. This data could provide an attacker with valuable contextual and structured information that can be weaponized to escalate access, perform reconnaissance, or bypass authorization workflows. Attackers can use it for speer phishing and further escalation scenarios or just misuse this information for malicious purposes.

Even though the vulnerabilities were assigned a Medium CVSS score of 6, they pose significant risks in terms of compliance. Storing sensitive information insecurely on local clients can lead to audit failures under regulations like GDPR, PCI DSS, or HIPAA.

Mitigation and Recommendations

To mitigate the risk:

– Disable the user input history:
– For Windows: Set DisableHistory = 1 under
HKEY_LOCAL_MACHINE\software\sap\SAPGUI Front\SAP Frontend Server\LocalData
or
HKEY_CURRENT_USER\software\sap\SAPGUI Front\SAP Frontend Server\LocalData
– For Java GUI: Disable the setting via Preferences.

– Delete the existing files:
– Remove .db or serialized object files from the above directories.

Although SAP has released updated versions that introduce stronger encryption – SAP GUI for Windows 8.00 Patch Level 9+ and SAP GUI for Java 7.80 PL9+ or 8.10 – the fallback mechanisms may still leave some clients vulnerable. Therefore, Pathlock recommends fully disabling the input history functionality, not just relying on patches.

One of the key takeaways of our research is that conducting regular, systematic audits of both legacy and modern systems is vital to uncover potential weaknesses in enterprise security posture. Unfortunately, weak encryption mechanisms like XOR are still common in legacy ERP software and custom enterprise apps, posing a real threat.

The vulnerabilities uncovered in this research provided the foundation for identifying a related flaw in SAP NetWeaver Application Server ABAP, documented as CVE-2025-0059. In this case, SAP GUI for HTML was found to have the same structural weakness. However, unlike CVE-2025-0055 and CVE-2025-0056, SAP does not offer a patch at this time. So far, the only effective mitigation is to disable the input history functionality.