StrongDM Vulnerability Let Attackers Reuse Local Session Files for Authenticated Access

A StrongDM authentication vulnerability could let attackers reuse locally stored session material to gain access to infrastructure resources as another user. The flaw, tracked as CVE-2026-4387, affected StrongDM’s Windows desktop application before version 23.74.0 and Desktop Client before version 53.77.0.

SpecterOps discovered the issue during a security assessment and publicly detailed it on June 1, 2026. The researchers found that StrongDM wrote authentication material to a local state file that could be copied and reused on another host.

The official StrongDM Trust Center describes the issue as unencrypted storage of authentication state in the StrongDM Desktop Application state.kv file. StrongDM fixed the vulnerability in Desktop Application 23.74.0 and Desktop Client 53.77.0.

What CVE-2026-4387 exposed

CVE-2026-4387 involved a per-user file stored at C:\Users\<username>\.sdm\state.kv. After a user logged in, the file contained authentication state, including a JSON Web Token and asymmetric key material.

The GitHub Advisory Database says the file was protected only by default user-level NTFS permissions. That means an attacker who already gained local read access to the affected user’s profile could copy the material.

The NVD entry also confirms that exploitation requires local read access to the affected user’s profile directory and additional deployment and execution conditions on the target host. This was not a remote, unauthenticated internet-facing vulnerability.

Detail	Information
CVE ID	CVE-2026-4387
Affected platform	StrongDM Desktop Application and Desktop Client on Windows
Affected versions	Desktop Application before 23.74.0, Desktop Client before 53.77.0
Weakness	Cleartext storage of authentication state
Required access	Local read access to the affected user profile
Official CVSS v4.0 score	2.0, low severity
Fix	Update to StrongDM Desktop Application 23.74.0 or Desktop Client 53.77.0 or later

Why the state file reuse mattered

StrongDM is used to broker access to infrastructure such as databases, servers, Kubernetes clusters, and cloud resources. If an attacker could reuse a victim’s authenticated session, they could potentially reach resources available to that user.

SpecterOps showed that copying the state file to another machine could make the StrongDM client load the victim’s session and display the victim’s resources. The attack worked more reliably when the copied state file replaced the local state file after the StrongDM application had already launched.

This made the issue especially relevant in post-compromise scenarios. An attacker did not need the victim’s password if they could steal the local StrongDM authentication state from a compromised Windows profile.

• The attacker first needs local read access to the affected user’s profile.
• The attacker copies the StrongDM state.kv file.
• The copied file can be placed on another host running StrongDM.
• The StrongDM client may load the victim’s authenticated session.
• The attacker can then attempt to access resources assigned to that victim.

Sensitive data also appeared in cache and local endpoints

During the investigation, SpecterOps found more than one place where session material appeared. The researchers identified a cached data_1 file under the StrongDM application cache that contained what looked like a JSON response with a JWT.

They also found a local endpoint at http://127.0.0.1:65220/v2/authentication that returned the authenticated user’s JWT when queried with a minimal header while the StrongDM desktop application was running.

Those findings reinforced the larger problem. Session material had not been sufficiently protected from local reuse, so a compromise of a user profile could become a path to authenticated StrongDM access.

StrongDM fixed the storage model

StrongDM remediated the issue by moving sensitive authentication material away from plaintext storage in state.kv. The company’s advisory says users should update to the fixed versions or later.

The updated client uses platform-native credential storage. On Windows, StrongDM moved sensitive material into DPAPI-protected storage, and Microsoft’s DPAPI documentation explains that DPAPI lets applications encrypt data using information from the current user account or computer.

SpecterOps retested the fix in May 2026 and confirmed that authentication material was no longer stored in plaintext. The state.kv file still existed, but it no longer contained the JWT required to reuse the authenticated session.

Before the fix	After the fix
JWT stored in state.kv	JWT removed from state.kv
Key material stored in plaintext	Sensitive material moved to platform-native secure storage
State file could be reused across hosts	Cross-host reuse no longer produced authenticated access in retesting
Cache file exposed JWT material	Retesting found JWT material removed from the cache file

The vulnerability is low severity on paper, but still important

The official severity rating may appear low because the attack requires local access and other conditions. The StrongDM advisory lists CVE-2026-4387 with a CVSS v4.0 score of 2.0 and CWE-312, Cleartext Storage.

That rating does not mean security teams should ignore it. StrongDM often sits in front of sensitive infrastructure, so session reuse can raise the impact after malware, phishing, insider access, or another endpoint compromise.

The GitHub advisory also notes that exploitation requires local read access and additional deployment conditions. For defenders, the main takeaway is clear: endpoint compromise and credential storage weaknesses can combine into broader infrastructure exposure.

Who should update and what to check

Organizations using StrongDM on Windows should confirm that all desktop clients run version 23.74.0, Desktop Client 53.77.0, or later. Teams should prioritize users with broad infrastructure access, privileged roles, or access to production resources.

The NVD record identifies the affected product versions and confirms the local attack requirement. Asset teams can use that information to find vulnerable installations across managed endpoints.

Security teams should also review endpoint telemetry for unusual access to StrongDM state files, suspicious copying of the .sdm directory, or unexpected StrongDM sessions from unfamiliar hosts.

1. Update StrongDM Desktop Application to 23.74.0 or later.
2. Update StrongDM Desktop Client to 53.77.0 or later.
3. Prioritize users with privileged infrastructure access.
4. Review suspicious file access under C:\Users\<username>\.sdm\.
5. Check for StrongDM logins or resource access from unexpected hosts.
6. Rotate or revoke sessions for users whose endpoints may have been compromised.

How security teams can reduce similar risks

This incident shows why local credential storage still matters, even when an application uses modern authentication flows. If session tokens or signing keys remain reusable outside their original device context, attackers may not need a password to move forward.

Developers should avoid storing bearer-style tokens and private key material in plaintext files. When local storage is necessary, platform tools such as DPAPI can help bind protected data to a user or device context.

Security teams should also treat access brokers as high-value applications. Their local files, caches, logs, helper services, and loopback endpoints can become targets during post-compromise activity.

• Monitor access to local files that store authentication state.
• Use endpoint detection rules for token theft and credential file collection.
• Limit infrastructure access by role and device posture.
• Enforce MFA and session policies for administrative access tools.
• Review vendor advisories for access brokers and identity infrastructure.
• Remove stale local cache files during incident response.

Disclosure timeline

SpecterOps began investigating the StrongDM desktop application during an assessment in May 2025. The issue went through coordinated disclosure, with StrongDM implementing remediation in March 2026.

SpecterOps’ disclosure says the CVE was reserved on May 19, 2026, publicly published on May 29, and broadly disclosed on June 1. StrongDM is now part of Delinea, according to the researcher’s disclosure note.

The fix was validated before public disclosure. That gives customers a clear path: update clients, review logs, and check whether any affected endpoints may have exposed session state before the patched versions were deployed.

FAQ