OPSSHIELD, the maker of the cPGuard firewall and malware scanner for Linux hosting servers, said an attacker used stolen credentials to publish a malicious script through the product’s own update channel, installing a backdoor on servers that applied the update. Versions 5.88.12 through 5.88.19 are affected.
Stolen Credentials Opened OPSSHIELD’s Update Network
At 02:06 UTC on November 2, the attacker accessed OPSSHIELD’s CDN and update distribution network and published the script. OPSSHIELD said no software bug was exploited. The intrusion relied on valid credentials, which is a defining feature of a supply-chain compromise: customers trust the vendor’s update path, so a tampered release arrives looking legitimate.
OPSSHIELD said it caught the attack within 12 hours and halted it. It emailed customers, and warnings also appeared on the LowEndSpirit and Portal do Host forums.
What the Malicious Script Did on Customer Servers
The script staged files under /var/tmp and installed a backdoor shell at /var/tmp/.cpg91511_sh. It also collected sensitive data, such as password hashes and root SSH keys, and uploaded it to OPSSHIELD’s licensing server under a compromised account for the attacker to retrieve later.
32 Files, Each Tied to One Customer Server
OPSSHIELD estimates the attacker retrieved 32 files, each tied to a single customer server. The company cautioned that its 12-hour detection time “does not establish whether data was transferred” from servers where the script ran. In other words, the count of 32 is an estimate of retrieval, and servers that ran the script cannot be assumed safe on the basis of detection speed alone.
OPSSHIELD Says Update cPGuard to 5.88.25 and Rotate Credentials
Customers should update to version 5.88.25 or later, which removes the backdoor and the staged files. They should rotate all exposed credentials. OPSSHIELD also tells administrators to check the logs in /opt/cpguard/logs/install_l* for “Successfully updated” entries and to treat any such server as potentially compromised.
The company removed its own support-access keys from customer servers. It does not recommend a full rebuild for now, a position it ties to the early state of its analysis.
OPSSHIELD Finds No Other Malicious Activity but Calls It Preliminary
OPSSHIELD found no other malicious activity so far but described that conclusion as preliminary. Open questions include how the credentials were stolen, whether the attacker had access before November 2, and whether any retrieved root keys were used to log in to customer machines.
cPGuard Shows Security Tools Are Supply-Chain Targets
The incident targets a product whose job is to protect hosting servers, and the update mechanism that keeps such a product current is also a privileged channel into every installation. Security software typically runs with root-level access, so a malicious update inherits those rights immediately.
Hosting environments compound the risk. A server running cPGuard often hosts customer websites, and root SSH keys taken from one server can give an attacker access to adjacent systems that trust the same keys. The reported theft of password hashes adds a second route, since hashes can be cracked offline and the resulting passwords tried elsewhere.
The campaign echoes earlier supply-chain compromises in which attackers chose the vendor over its customers, an approach that scales: one set of stolen credentials reached every server configured to pull updates. OPSSHIELD’s account suggests the window was short, but the 32 retrieved files show the attacker did not need long.
Open Questions About OPSSHIELD’s Compromised Licensing Server Account
Using OPSSHIELD’s own licensing server as the drop point for stolen data also raises a question about how long a compromised account on that server remained usable. The company said it removed its support-access keys and halted the malicious update within 12 hours, but it has not said whether the licensing account credentials have been fully replaced. Customers who ran the update inside that window are left to rely on the vendor’s log-check instructions to learn whether their server executed the script.
