CVE-2025-10010: Cpsd Cryptopro Secure Disk RCE Flaw

CVE-2025-10010 Overview

A security vulnerability has been identified in CPSD CryptoPro Secure Disk, a pre-boot authentication solution that integrates with Microsoft BitLocker. The application boots a small Linux operating system to perform user authentication before using BitLocker to decrypt the Windows partition. This Linux system resides on a separate unencrypted partition accessible to anyone with physical access to the hard disk.

The vulnerability exists in the integrity validation mechanism of the pre-boot environment. While multiple checks are performed to validate the integrity of the Linux operating system and CryptoPro Secure Disk application files—including the Linux kernel's Integrity Measurement Architecture (IMA)—configuration files are not validated by IMA. This oversight allows an attacker with physical access to modify these configuration files, bypassing other integrity checks, and execute arbitrary code in the context of the root user.

Critical Impact

An attacker with physical access to the hard disk can bypass integrity checks to execute arbitrary code as root in the pre-boot environment, potentially planting backdoors and accessing encrypted data during system execution.

Affected Products

• CPSD CryptoPro Secure Disk (BitLocker integration)
• Systems using CryptoPro Secure Disk pre-boot authentication
• Environments relying on IMA for pre-boot integrity validation

Discovery Timeline

• 2026-02-24 - CVE-2025-10010 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2025-10010

Vulnerability Analysis

This vulnerability represents a Missing Support for Integrity Check (CWE-353) in the pre-boot authentication mechanism of CPSD CryptoPro Secure Disk. The application implements a defense-in-depth approach using the Linux kernel's Integrity Measurement Architecture (IMA) to validate system files before allowing the Windows partition to be decrypted via BitLocker.

However, the IMA configuration fails to include critical configuration files in its integrity measurement scope. Since the pre-boot Linux partition is unencrypted and accessible to anyone with physical access to the storage device, an attacker can directly modify these unprotected configuration files. When the system boots, these modified configurations are loaded without integrity verification, potentially altering the behavior of the pre-boot environment in ways that enable code execution with root privileges.

The physical attack vector requires direct access to the target system's storage, which could occur through stolen devices, temporary physical access to unattended systems, or malicious insider scenarios.

Root Cause

The root cause is an incomplete implementation of the Integrity Measurement Architecture (IMA) policy. While the IMA framework is designed to measure and verify the integrity of executable files, kernel modules, and critical system files, the configuration for CryptoPro Secure Disk fails to extend these protections to all security-relevant configuration files. This gap in the integrity verification chain allows configuration files to be modified without detection, effectively creating a bypass path around the intended security controls.

Attack Vector

The attack requires physical access to the target system's hard disk. An attacker could:

1. Remove or access the storage device containing the CryptoPro Secure Disk pre-boot partition
2. Mount the unencrypted Linux partition from another system
3. Identify and modify configuration files that are not validated by IMA
4. Inject malicious commands or alter execution paths in these configuration files
5. Return the storage device to the target system
6. Wait for the legitimate user to boot the system, triggering execution of the attacker's code with root privileges

The attacker could leverage this access to plant persistent backdoors, capture authentication credentials, or access decrypted data when the system is in use. The exploitation does not require authentication, making it particularly dangerous for scenarios involving lost or stolen devices.

Detection Methods for CVE-2025-10010

Indicators of Compromise

• Unexpected modifications to files on the CryptoPro Secure Disk pre-boot partition
• Changes to configuration files that are not covered by IMA policy
• Unusual processes or services running in the pre-boot Linux environment
• Evidence of the pre-boot partition being mounted or accessed from external systems

Detection Strategies

• Implement file integrity monitoring (FIM) on all pre-boot partition files, including configuration files not covered by IMA
• Monitor for boot sequence anomalies or unexpected delays during pre-boot authentication
• Deploy tamper-evident seals on physical hardware to detect unauthorized access
• Review system logs for evidence of the pre-boot environment being accessed from external operating systems

Monitoring Recommendations

• Enable comprehensive logging of all pre-boot authentication events
• Implement hardware attestation mechanisms such as TPM-based measurements for additional integrity verification
• Monitor for unauthorized physical access to systems in data centers or secure areas
• Establish baseline hashes for all pre-boot partition files and alert on any deviations

How to Mitigate CVE-2025-10010

Immediate Actions Required

• Assess exposure by identifying all systems using CPSD CryptoPro Secure Disk with BitLocker integration
• Implement physical security controls to restrict access to affected systems
• Monitor the SEC Consult Security Advisory for vendor patches and updates
• Consider additional encryption or integrity protection for the pre-boot partition as an interim measure

Patch Information

Refer to the SEC Consult Security Advisory for the latest information on available patches and remediation guidance from CPSD. Organizations should contact CPSD directly for updated software versions that address this IMA configuration gap.

Workarounds

• Extend IMA policy to include all configuration files in integrity measurements where possible through custom policy modifications
• Implement full disk encryption on the pre-boot partition using additional mechanisms independent of the vulnerable application
• Restrict physical access to affected systems through access controls, surveillance, and tamper-evident mechanisms
• Consider hardware security modules or TPM-based boot attestation as an additional layer of integrity verification
• Use secure boot chains with signed bootloaders where supported to establish trust before the vulnerable component loads