Netwrix Password Manager Vulnerability Allows Authenticated Remote Code Execution

A critical security vulnerability has been discovered in Netwrix Password Secure, an enterprise password management solution, allowing authenticated attackers to execute arbitrary code on victim machines.

The vulnerability, identified as CVE-2025-26817, affects all versions of Netwrix Password Secure up to version 9.2.2, exposing organizations that haven’t updated to the latest release.

The flaw resides in the document sharing functionality of the password manager, which is designed to securely share passwords, keys, and other sensitive information between users within an organization.

The vulnerability exploits a flaw in how the password manager validates file types when updating existing document links.

While the application implements protective measures during initial document uploads by restricting file types to a whitelist, these security checks can be bypassed when modifying existing document links.

An authenticated attacker can manipulate document properties to change the file path to point to an executable file while maintaining the original document type in the system.

8 COM security researchers identified this vulnerability during a comprehensive security analysis of the password management platform.

Their investigation revealed that the application fails to verify the complete document path when updating document properties, focusing only on the DocumentType attribute and neglecting to validate changes to the DocumentPath attribute.

“Password managers are considered one of the most secure ways to keep passwords safe,” noted the researchers in their technical report.

“However, this vulnerability demonstrates how even security-focused applications can contain critical flaws in their implementation.”

The vulnerability is particularly concerning as password managers are specifically designed to enhance organizational security, making this a case of security software potentially becoming an attack vector.

The exploit leverages a design oversight in the document sharing functionality. When a document link is initially created, the application properly validates the file extension against a whitelist.

However, when modifying an existing document link, only the DocumentType attribute is checked while changes to the DocumentPath attribute are applied without further validation.

Exploitation Details

The exploitation process begins with an attacker creating a legitimate document link using an allowed file type, such as a PDF.

After the document is saved to the database, the attacker modifies the DocumentPath attribute to point to PowerShell.exe while leaving the DocumentType unchanged as “pdf”.

The vulnerability lies in the VerifyCorrectDocumentType method:-

public void UpdateContainerFileHandle(MtoContainer container, Guid fileHandle)
{
    this.VerifyCorrectDocumentType(container);
    using (RightManager rm = new RightManager(base.CurrentConnection))
    {
        rm.VerifyObjectRight(container.Id, Rights.RightWrite, true);
    }
}

This method only checks the DocumentType attribute but fails to validate the DocumentPath. The DocumentParams attribute can also be manipulated to include PowerShell commands:

currendContainer.TimeStampUtc = container.TimeStampUtc;
currendContainer.DocumentPath = container.DocumentPath;
currendContainer.DocumentType = container.DocumentType;
currendContainer.DocumentSize = container.DocumentSize;
currendContainer.DocumentMeta = container.DocumentMeta;
currendContainer.DocumentParams = container.DocumentParams;
currendContainer.DocumentCacheDeleteTime = container.DocumentCacheDeleteTime;
currendContainer.EntityState = MtoEntityState.Modified;

When a victim user opens the shared document link, the system executes PowerShell with the attacker-controlled parameters rather than opening the expected PDF file.

Exploitation allows for remote code execution in the context of the victim’s user account. Netwrix has released fixes in versions above 9.2.2, and users are strongly advised to update immediately.

The vulnerability was responsibly disclosed following a coordinated timeline, with initial contact made on January 28, 2025, and public disclosure occurring on May 22, 2025, after remediation was available.

Equip your SOC team with deep threat analysis for faster response -> Get Extra 𝗦𝗮𝗻𝗱𝗯𝗼𝘅 𝗹𝗶𝗰𝗲𝗻𝘀𝗲𝘀 for Free