What happened (in plain human-speak)

Okay, here’s the messy bit: on November 2 at 02:06 UTC, someone used stolen credentials to break into the cPGuard update channels and slip a malicious script into official updates. If your server checked for updates while the bad package was being served (about a 12-hour window), it might have run that script — essentially inviting a backdoor and a data-stealing gremlin into the machine. OpsShield discovered the incident and stopped the distribution, but not before some damage could be done.

The affected releases were 5.88.12 through 5.88.19. Because update checks happen on schedules, some servers may have escaped the hit by sheer timing luck, while others definitely pulled the nasty payload. The attacker used legitimate credentials to reach the update CDN — how they got those credentials hasn’t been confirmed.

The payload targeted several sensitive artifacts on infected hosts. The script looked for and exfiltrated things like:

  • Linux password hashes
  • Root database (MariaDB/MySQL) configuration files
  • Root shell history
  • Root SSH authorization and known_hosts files

The stolen files were uploaded through a compromised account to the vendor’s licensing server, and the attackers later retrieved the collected data. Investigators found evidence indicating the actor pulled about 32 files per affected customer. The vendor reported roughly 2,946 servers were impacted and said their billing database was copied as well.

What you should do right now (do it, like, now)

No one likes emergency patching parties, but this one’s mandatory if you run cPGuard. Quick, prioritized checklist:

  • Update every cPGuard instance to version 5.88.25 or later — the update removes the malicious backdoor and staged files.
  • Immediately reset passwords and rotate credentials everywhere that could be affected: database credentials, cloud secrets, service accounts.
  • Rotate or revoke SSH keys and replace any support-access keys that might have been installed — assume anything exposed is toast until proven otherwise.
  • Review access logs and file changes for unexpected uploads, new accounts, or odd outbound connections. If you find unexplained activity, consider rebuilding the server from a known-good backup.
  • Invalidate any credentials that could have been exfiltrated. Remember: updating removes the backdoor, but it does not undo stolen passwords or keys.
  • Block compromised accounts at the vendor side if you have that option and follow any vendor-provided remediation steps.

If you’re the kind of admin who likes proof, collect logs and indicators of compromise before rebuilding, but don’t leave compromised keys or passwords valid while you investigate. And if you haven’t already, contact your vendor support for specific guidance and any follow-up tools they release to clean support keys.

Bottom line: this was a supply-chain style hit that abused a trusted update path. Patch, rotate, audit — and maybe have a coffee while you wait for everyone to calm down.