The team and I have recently discovered a new privilege escalation vulnerability, CVE-2026-1995, affecting IDrive Windows Backup.

Because this is a fresh discovery, it’s our responsibility to share details on our findings and recommendations based on what we’ve encountered in the wild.

If you’re using IDrive Windows Backup, the rest of this post explains what to look for and what you can do now to remediate.

If you’re unsure whether it’s in your environment, or are wondering what this tool is and does, I’ll briefly expand on it first.

Let’s dive in.

Important Note to Set the Stage

Before diving into the details, it is important to note that this vulnerability remains unpatched.

While CVE-2026-1995 is being made public, we would like to minimize active exploitation as much as possible.

Therefore, a working proof-of-concept will not be provided, and specific details as to the inner workings of this vulnerability will be omitted until a later date.

What is IDrive Windows Backup?

Simply, IDrive is a privately owned, cloud-based file backup tool company.

Their software can be used for personal devices or for businesses, but is primarily geared towards smaller and medium-sized businesses.

They have applications for Windows, macOS, and Linux, but for this vulnerability, I’ll specifically discuss their Windows backup client.

You may have heard of tools like Veeam or Backblaze—this is similar software.

About CVE-2026-1995

This is not the first privilege escalation in this software. A previous vulnerability was identified as CVE-2020-15351.

The origin of this specific vulnerability lies in weak permissions on the directory “C:\Program Files (x86)\IDriveWindows”, which allow authenticated users to overwrite program files associated with the backup client.

The simplest example of how this could be exploited is overwriting the executable used by the “IDriveService” Windows service, which runs with elevated system permissions.

This piqued our interest after encountering an out-of-date version of the software in the wild.

While not a complex exploit, it does require some user interaction if the user doesn’t already have permission to restart the service or reboot the system after replacing the service binary.

A fully non-interactive exploit is much more desirable, and in the process of identifying avenues for non-interactive exploitation, a separate vulnerability was identified.

Technical Details

Dynamic analysis of the associated elevated service binary, “id_service.exe” indicated that it would regularly attempt to open several text files located in the “C:\ProgramData\IDrive” directory.

Notably, this directory has the same permissions identified in the previous CVE, with authenticated users having read-write access.

Typically, ProgramData is used for scenarios where a program needs to store configuration data that the whole system needs to read, but not necessarily write to.

The best practice for storing user configuration data is to store it in the user’s AppData directory.

When modifying data stored in sensitive locations such as ProgramData, an API in the elevated process should be exposed to allow safe modification of data in the ProgramData directory.

From here, we can identify that this directory is being used as a form of inter-process communication between the user-mode backup client’s interface and the elevated Windows service.

Essentially, the user-mode program will write files to this directory, and the elevated Windows service will trigger a backup job or, under the correct circumstances, run arbitrary commands.

With this knowledge, it is possible to craft a file that triggers the elevated service to run any application or command without user interaction.

CVE-2026-1995 Impact

This vulnerability enables an authenticated user with low-level restricted access to run executables with full system privileges on a Windows machine.

An internal attacker could exploit the escalated permissions provided by this vulnerability to gain full administrative control of the target machine.

Ultimately, this would enable them to steal sensitive data, modify system configurations, or execute additional malicious code.

Remediation

At the time of publication (IDrive version 7.0.0.63), the vendor has not patched this vulnerability, and it affects all versions of the application.

A patch is reportedly in development.

Once additional information is identified regarding a patch, this post will be updated to include a link to a fixed version and additional technical details.

Unfortunately, modifying the permissions on the “IDrive” folder in the “ProgramData” directory breaks the application’s functionality.

Potential defenses in the meantime include restricting write permissions for the affected directory, though this may impact application functionality. It is also recommended to employ additional controls, such as EDR monitoring and Group Policy, to detect and prevent unauthorized file modifications and suspicious child processes from the backup service.

IDrive (Vendor) Interaction Timeline

2025-08-22 – FRSecure reaches out to the vendor’s technical support email to request info on how to proceed with responsible disclosure.
2025-08-24 – Vendor replies, stating to reply to the email with the technical details of the vulnerability.
2025-08-25 – FRSecure replies to the vendor with a technical write-up of the vulnerability and steps to reproduce the vulnerability.
2025-08-25 – Vendor replies, stating they are investigating.
2025-10-03 – FRSecure follows up with vendor due to no updates.
2025-10-05 – Vendor states they are still investigating.
2025-11-18 – FRSecure follows up with the vendor again, asking for confirmation of whether the vulnerability exists.
2025-12-03 – FRSecure reaches out to CERT to assist with coordination after not hearing back from the vendor.
2025-12-03 – CERT reaches out to the vendor, embargo on details being published is set for 2026-01-19.
2025-12-24 – Vendor states they are investigating.
2026-01-12 – CERT follows up requesting an update from the vendor as embargo date is approaching.
2026-01-20 – CERT follows up requesting an update from the vendor as embargo date has been reached.
2026-01-30 – CERT escalates the issue to CISA to reestablish communication with the vendor.
2026-02-02 – Vendor states they are addressing internal priorities to respond to the issue.
2026-02-02 – CERT requests a timeline from the vendor for when we can expect a patch.
2026-02-05 – CVE ID reserved.
2026-02-27 – CERT follows up requesting an update from the vendor.
2026-03-10 – No updates from vendor, public disclosure date set for 2026-03-23.
2026-03-23 – Vulnerability disclosed.