cve-2025-26817 netwrix rce

Introduction

Password managers are considered one of the most secure ways to keep passwords safe. We have analyzed the commercial password manager by Netwrix and discovered an authenticated Remote Code Execution vulnerability.

Netwrix Password Secure is an enterprise password manager, which covers a variety of functions that go beyond the normal password protection. One of these features allows to securely share passwords, keys and secrets with other users.This blog post describes how we found a way to use this functionality to execute code on other users’ systems.

Setup

The security check was performed for the following version:

Netwrix Password Secure (Client - PSC) 9.2.0.32454
Netwrix Password Secure (Server - PSS) 9.2.0.32454

Versions up to 9.2.2 are affected by the vulnerability.

Analysis

The password manager’s functionality to share passwords with other users or teams makes the application very interesting for potential vulnerabilities. During the analysis, we looked for classic process calls like ProcessFileInfo. One method stood out in particular.The class DocumentsHelper implements a method called OpenInDefaultProgram, which creates a new ProcessFileInfo objects. So it could be that documents, or better said files, are always executed with the default program based on the file extension.

The method is called by the DocumentDoubleClick method in the DocumentListViewModel class.

For example, if it was possible to upload executable binaries such as exe files, these should be executed via the Explorer.

So the first goal was to find out where documents could be uploaded. In the password manager, I noticed that there is also a Documents tab besides the Passwords tab.

There it was possible to upload PDF files and make them available to other users as a link via the share function. Unfortunately, when uploading exe files as a document link, a message appears that this type of file is not allowed. Upon further investigation, it was discovered that when a document is uploaded, the application checks the file extension to verify the file type.

Multiple file extensions are whitelisted by default:

this.InternalUpdateOption<MtoOptionString>("AllowedDocumentTypes", "OptionCategoryDocuments", MtoOptionGroup.OptionGroupSecurity5, "png|pdf|doc|docx|dot|dotm|dotx|xls|xlsx|xlr|wps|jpg|gif|rtf|txt|ppt|pptx|pps|ppm|vss|vssm|vstm|one|onepkg|pfx|htm|html|lic|ini|xml|pub|ppk", null);

This prevents the upload of exe files as new document shortcuts. After further analysis, it was discovered that there are differences between modifying an existing shortcut and the initial upload. The application stores the file path with the file extension in the DocumentPath attribute. In addition, the attribute DocumentType is used, which only contains the file extension.

When changing a document link that has already been uploaded, only the modified attributes are changed. Then the VerifyCorrectDocumentType method is called again to check the file extension against the whitelist. However, an important detail has been overlooked.

Only the DocumentType attribute is checked in the VerifyCorrectDocumentType method. After that, no further checks are performed on the file type and file path, and the change is simply applied.

So if only the file path is changed for an existing document link, only the DocumentPath attribute is affected. The DocumentType attribute remains unchanged. This allows changing the file path of an existing document link to an executable file without causing the DocumentType attribute check to fail.

Since no executables can be uploaded due to whitelisted restrictions, there are two possible attack scenarios:

Change the file path to a custom executable file located on a network share that is accessible to the user
Change the file path to one of the standard Windows executable files that are always present

Since the scenario without network sharing is a more realistic scenario, the path could be set to PowerShell.exe. However, the next issue would be that the PowerShell is executed, but no payload can be dropped to run its own code.

Those who have been paying attention will have noticed something. There is already one attribute that can help. There is an additional attribute DocumentParams.

Sounds like a way to pass parameters to the executing program. The attribute is also inherited by the container object without any further checks. When OpenInDefaultProgram is called, the DocumentParams attribute is always specified as well. It was also noticed that in the newly created ProcessFileInfo object, the DocumentType is not used as an extension, although it is stored separately. In fact, the extension is extracted from the current file path that we are trying to change and used for this purpose. This means that it is likely that the correct default program will be started. In our case, that would be Explorer, which should run the PowerShell.exe with our specified payload.

So it might be possible to inject a payload for the PowerShell.exe by configuring this parameter on the client side. Now it is time to move from theory to practice.

Exploitation

First, the Netwrix Password Secure Client application was started in a debugger and a new document link was created.

After that, a harmless PDF file such as the Edge browser manual (EdgeAnleitung.pdf) is uploaded.

In the debugger, a breakpoint is then set in the PsrClientLayer.Models.DocumentsAddModel class in the SaveDocumentToDatabase method (line 317) to modify the DocumentParams attribute later.

The document link will then be saved.

On saving, the breakpoint is triggered and in the MtoContainer the value of DocumentParams is set to null.

Before the client sends the object to the server, the payload calc is added to DocumentParams for demonstration purposes. If this works, the Windows Calculator should pop up when the vulnerability is successfully exploited.

When the debugger resumes, a message will pop up, that the entry has been saved.

After that, the properties of the document shortcut can be opened again by right-clicking on the entry.

Now it’s time to specify the local path to the PowerShell.exe.

The shortcut can then be saved with the changed path.

The change was successful. The entry now shows the new modified path to PowerShell.exe, because only the specified file type was checked, not the modified file path.

The document link has now been manipulated so that the file extension is pdf. However, when clicking on the entry, the default program for the specified file in the file path should be called (PowerShell.exe) and not the specified file extension in the MtoContainer object (pdf). In addition, the payload calc has been injected into the DocumentParams attribute to popup the calculator when the document link is opened with a double-click.Now the shortcut can be shared with other users.

When this user opens the shortcut, we can observe the following:

Boom! Clicking on it opens the PowerShell window, followed by the executed payload, which pops the calculator.

The path actually worked to execute custom code when a user opened the shared document link. Of course, this vulnerability is only authenticated and exploitable with user interaction. However, there is another scenario resulting from the vulnerability found. The same attack can be performed on documents that have been shared with the attacker user itself, if he has permission to modify the file path property of the shared document link.

Another feature even allows direct usage via a desktop shortcut that can be created for the entry. So the user can not even see the file path via the shortcut.