CVE-2026-95831 in Crypt::SelfCertificate
Summary
by MITRE • 09/22/2026
Crypt::SelfCertificate versions from 1.01 through 1.05 for Perl contains malware which executes Python code from an obfuscated URL.
The generate_certificate runs a Python script saved as a certificate file. The pyhton script attempts to retrieve code from a hardcoded http URL that is obfuscated with base64 encoding and run the response body directly.
The impact is that arbitrary code can be invoked as the user, without a dropped script being saved on the affected host.
The releases have no test scripts nor build hooks. The intention may have been to trigger the payload after installation.
For version 1.01, the dropper script is in lib/Crypt/SelfCertificate/sample/validate.p12.
For version 1.05, the dropper script is in lib/Crypt/SelfCertificate/sample/cert7.pem.
The SHA-256 digests of the files are
fbff21f45ff748365062a5e36fb2d72558cad82a507a6f357f320b4fcdf07760 Crypt-SelfCertificate-1.01.tar.gz 27b2d2d3174ad771474fff2521f5084ec231e9218ea8c832515aef1cbd5897bc lib/Crypt/SelfCertificate/sample/validate.p12
9fdfa7d69b034b77d4510cda567e8da1e486ca81c7daaadc5732a45c41d71991 Crypt-SelfCertificate-1.05.tar.gz 27b2d2d3174ad771474fff2521f5084ec231e9218ea8c832515aef1cbd5897bc lib/Crypt/SelfCertificate/sample/cert7.pem
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Crypt::SelfCertificate versions 1.01 through 1.05 represents a severe compromise of software supply chain integrity, classified as malicious code injection within a legitimate Perl module distribution. This flaw is not merely a logic error or configuration mistake but constitutes the deliberate insertion of malware into open-source packages distributed via CPAN. The core technical mechanism involves the modification of certificate generation routines to execute arbitrary Python scripts embedded directly within PEM and P12 certificate files. When an application utilizes these compromised modules, specifically during the process of generating self-signed certificates, the underlying code triggers a system call that interprets the content of specific sample files as executable Python script rather than static cryptographic data. This behavior bypasses standard security expectations where certificate files are treated solely as passive configuration or identity artifacts.
The operational impact is significant because it allows for arbitrary code execution under the context of the user running the Perl application, without requiring any external network interaction at the time of exploitation if the payload were local, but in this specific instance, the malware acts as a dropper that fetches additional payloads from an obfuscated URL. The Python script contained within the compromised certificate files attempts to retrieve code from a hardcoded HTTP endpoint where the target binary or script is encoded using base64 encoding. Upon retrieval, the response body is executed directly in memory. This technique minimizes forensic artifacts because no persistent malicious file needs to be written to the disk beyond the initial module installation, making detection by traditional antivirus solutions more difficult as the execution chain relies on legitimate system interpreters like Python and standard network libraries.
From a classification perspective, this vulnerability aligns with CWE-1108, which describes the inclusion of malware or backdoors in software distributions, and falls under the ATT&CK technique T1587.001, specifically Development Compromise via supply chain attacks where threat actors compromise build systems or package repositories to inject malicious code. The absence of test scripts and build hooks in these releases further exacerbates the risk, as it prevents automated quality assurance processes from detecting anomalous behavior during installation or unit testing phases. This lack of verification infrastructure suggests that the malicious changes were introduced without standard community oversight mechanisms typically present in well-maintained Perl modules.
The specific vectors for exploitation are tied to sample files included within the distribution archives. For version 1.01, the dropper is located at lib/Crypt/SelfCertificate/sample/validate.p12, while for version 1.05, it resides at lib/Crypt/SelfCertificate/sample/cert7.pem. These files contain Python code disguised as certificate data, which triggers when the generate_certificate function processes them. The SHA-256 digests provided serve as critical indicators of compromise for security teams scanning their environments. Organizations using these versions must immediately assume that any system where this module was installed is potentially compromised and requires forensic analysis to identify lateral movement or persistent access established by the executed Python payload.
Mitigation strategies require immediate remediation through upgrading to a verified clean version of the Crypt::SelfCertificate module if available, or removing the package entirely from production environments until trust can be re-established with the upstream maintainers. Security teams should audit their systems for the presence of the specific sample files mentioned and check for outbound HTTP connections to suspicious domains that may have been contacted by the dropper script. Additionally, implementing strict allow-listing policies for Python execution contexts within Perl applications can help prevent similar supply chain attacks from succeeding in future iterations. Regular integrity checks using tools like CPAN::Audit or SHA-256 verification of installed modules against known good hashes are essential to detect such compromises early before they lead to broader system infiltration.