Description

IO::Socket::SSL::SelfCertificate versions 1.00 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. The dropper script is in lib/Crypt/SelfCertificate/sample/cert.pem. This is similar to CVE-2026-95831 for the module Crypt::SelfCertificate. The SHA-256 digests of the files are ba24ee8ec3b7f47f65bed62e16fb413ace50653cf44bd8ea90914390922831e0 IO-Socket-SSL-SelfCertificate-1.00.tar.gz 821d38830e5eb8607738421c25ac25f59fff02a6ab67daa32fbd020429454dac IO-Socket-SSL-SelfCertificate-1.00/lib/IO/Socket/SSL/SelfCertificate/sample/cert.pem d483cb7b23b7271cb11cf242bff4a2e1c02df0b9525eb0429abeea8961c399d5 IO-Socket-SSL-SelfCertificate-1.00-upload.tar.gz

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-24T23:19:22.960Z",
  "pubdate": "2026-09-24T23:19:22.960Z",
  "executiveSummary": "IO::Socket::SSL::SelfCertificate version 1.00 contains a supply chain compromise involving a malicious payload designed for arbitrary code execution (ACE).\nThe vulnerability is characterized by an obfuscated remote code execution (RCE) mechanism embedded within a sample certificate file, specifically lib/IO/Socket/SSL/SelfCertificate/sample/cert.pem.\nWhen the generate_certificate function is executed, it invokes an embedded Python script that fetches and executes remote content, effectively operating as a dropper for secondary malicious payloads.\nThis vulnerability allows an attacker to execute arbitrary code with the privileges of the user running the Perl module, without requiring the presence of a persistent script on the host file system.\nThe risk is critical, as it enables full system compromise upon execution of the affected function. Given the absence of test scripts or build hooks, this appears to be a targeted distribution of malicious code within the Perl ecosystem, similar to the pattern observed in CVE-2026-95831 for the module Crypt::SelfCertificate.",
  "technicalDetails": "The root cause of this vulnerability is the inclusion of malicious, obfuscated code within the file lib/IO/Socket/SSL/SelfCertificate/sample/cert.pem, which is packaged as part of the IO::Socket::SSL::SelfCertificate version 1.00 distribution.\nThe exploitation process begins when the generate_certificate function is called by a developer or automated process. The function treats the contents of the malicious cert.pem file as a Python script and executes it.\nUpon execution, the Python script initiates an external request to an attacker-controlled, hardcoded URL. To evade static analysis, the URL is obfuscated using base64 encoding.\nThe payload mechanism retrieves the response body from the remote URL and passes it directly to the system's execution environment. This 'fileless' execution pattern ensures that malicious instructions are evaluated in memory, significantly complicating detection by traditional file-based signature scanners.\nThe attack flow follows a discrete path: 1) Distribution of the compromised package via standard repository channels; 2) Integration of the module into a target project; 3) Execution of the generate_certificate function; 4) Triggering of the Python-based dropper; 5) Fetching and immediate execution of secondary payloads from an external source.\nBecause the execution happens within the context of the user running the Perl interpreter, the attacker inherits those specific user-level permissions. This allows for data exfiltration, local privilege escalation if environmental vulnerabilities exist, or the installation of persistent rootkits.\nThe lack of integrity checks in the distribution process facilitated this compromise, as there are no build hooks or test suites associated with this version to catch or impede the execution of arbitrary embedded code. The vulnerability requires no authentication and is triggered by the natural usage of the vulnerable function, making it an effective vector for supply chain attacks against developers and production environments relying on this specific library."
}