A Fake cPGuard Update Ran as Root on About 2,950 Servers, and the Vendor’s Second Notice Replaces Its First on the Entry Point, the Count and the Cleanup

OPSSHIELD, the company behind the cPGuard server security suite, says an attacker pushed a fake update through its update channel on November 2 and that the script it carried ran as root on about 2,950 customer servers. In a second notice published on November 3, the company says the attacker registered as a customer, broke into its billing and licensing server, took the keys it uses to publish updates, and had agents install the fake update between 02:08 and 03:20 UTC. BleepingComputer reported the story on November 3 from the company’s first notice and figures a spokesperson gave it.

The two notices disagree on facts that decide what an administrator does next. The first described “compromised credentials” on the update CDN, 32 retrieved files and a fix in version 5.88.25 or later. The second describes a customer account used against the billing portal, about 2,950 servers, a clean update numbered 5.88.26, a follow-up update, and three leftover paths to check by hand. The banner now on the first notice says it “records our earlier findings.” We read both notices, the vendor’s changelog as archived on November 3 and the registry record for the one IP address the vendor lists, and we tested a read-only check script on dummy files. We did not download or run anything from the fake update.

At a glance

What OPSSHIELD says happened

All times below are UTC and come from the second notice, which the company titles a Security Incident Disclosure.

By our arithmetic the first probe came 10 hours 26 minutes before the first upload, and the install window lasted 72 minutes, which fits the company’s “about ten hours” and “about 70 minutes.”

On the way in, the second notice admits a gap: “Our logs do not record the exact request that gave them access.” The company patched “two possible entry points,” says it has ruled out SSH, the control panel, FTP and API tokens, and is rebuilding its billing, licensing and internal management servers from clean images. It names no application, component or bug class.

Two notices, two accounts

The first notice is dated November 3 in India Standard Time and was last updated at 3:19 AM IST, which is 21:49 UTC on November 2. The Internet Archive captured it at 23:21 UTC that night and again at 15:59 UTC on November 3, and the notice text is identical in the two captures. Neither carries the banner that points to the disclosure; that banner appears only on the live page. The archive’s one capture of the disclosure is from 21:19 UTC on November 3, and the live page matched it line for line when we read it on November 4.

The vendor’s changelog, as the archive captured it at 06:35 UTC on November 3, labels 5.88.25 a Security Patch dated November 2 with the note “Patched compromised update,” and 5.88.26 a Security Patch of the same date whose note reads “Revoked support access to servers if it is enabled.” So the vendor’s own documents describe the two releases differently: the first notice credits 5.88.25 with removing the backdoor, the second notice credits 5.88.26 with removing the root shell, and the changelog credits 5.88.26 with revoking support access. The changelog entry fits the first notice’s later step, in which the company said it was releasing an update to remove its support-access keys from servers where they were added. The changelog lists no version between 5.88.11 (October 22) and 5.88.25, but it is not an exhaustive list: it also skips 5.88.01, 5.88.02 and 5.88.04 through 5.88.10.

BleepingComputer’s report follows the first notice and adds the spokesperson’s figures: “We detected 2946 servers were affected and copied the information mentioned, and our billing system database was copied over as well.” It does not mention the customer account used to get in.

Who is exposed: two rules that do not match

The first notice defines exposure by installed version. An entry in /opt/cpguard/logs/install_log showing 5.88.12 through 5.88.19 means the server installed an affected update, and the server should be treated as potentially compromised “even if it now runs 5.88.25 or later.” The second notice defines it by time: a server with cPGuard “installed and online between 02:08 and 03:20 UTC on 2 November” should assume its root-level secrets are known, while one that was not online in that window “did not receive the fake update.”

The rules can give different answers. The first notice’s sample log lines show 5.88.12 installed at 02:46, 5.88.15 at 04:46, 5.88.17 at 08:46, 5.88.18 at 10:46 and 5.88.19 at 12:46, with the caveat “your timestamps may differ.” The notice does not say which clock those lines use. If they are UTC, four of the five fall between 1 and 9 hours after the second notice’s window closed, so a server could be exposed under one rule and clear under the other.

Our reading: until OPSSHIELD reconciles the two, treat a server as exposed if it meets either rule, and check the leftover paths whatever the log says. The first notice itself warns: “No matching entries, or a missing or incomplete log, do not by themselves establish that the server was unaffected.” Namecheap’s help page says cPGuard is available with its VPS and dedicated servers, as BleepingComputer notes. Neither that page, which says nothing about the incident, nor OPSSHIELD says whether resold or bundled installs are among the 2,950.

What to check on a server

Commands from the vendor

The first notice gives these commands for cPGuard on Linux. The first lists update history, the second updates, and the third prints the installed version, which that notice says must be 5.88.25 or later; the second notice says to update to the latest version.

grep 'Successfully updated' /opt/cpguard/logs/install_log
cpgcli update --start
cpgcli --version

A read-only check for the leftovers

This script is ours. It changes nothing: it greps the install log for the affected range, tests the four paths the two notices name, and prints the SHA-256 of any file whose name matches the fake update script so you can compare it with the vendor’s table below. ROOT is empty on a real server; the test runs below point it at dummy folders.

#!/bin/bash
# cpg_check.sh: read-only check for the versions and paths named in OPSSHIELD's two cPGuard notices (November 2026).
# ROOT is empty on a real server. Point it at a dummy folder to try the script safely.
ROOT="${ROOT:-}"

echo "== 1. Install history (the first notice lists 5.88.12 through 5.88.19 as affected)"
LOG="$ROOT/opt/cpguard/logs/install_log"
if [ -r "$LOG" ]; then
  grep -E 'Successfully updated to 5\.88\.1[2-9]$' "$LOG" || echo "no affected version in the log (this does not prove the server was unaffected)"
else
  echo "install_log missing or unreadable: the log cannot answer the question"
fi

echo "== 2. Paths named in the two notices"
found=0
for p in /var/tmp/.cpg91511_sh /var/tmp/.cpg91511 /var/tmp/.i93677 /etc/cron.d/i93677; do
  if [ -e "$ROOT$p" ] || [ -L "$ROOT$p" ]; then
    printf 'FOUND  %s  %s\n' "$(stat -c '%A' "$ROOT$p")" "$p"
    found=1
  fi
done
[ "$found" = 0 ] && echo "none of the four paths exist (absence after cleanup does not show the script never ran)"

echo "== 3. Fake update script names (compare each SHA-256 with the notice)"
find "$ROOT/opt/cpguard" "$ROOT/var/tmp" "$ROOT/tmp" "$ROOT/root" -maxdepth 4 -type f \
  -name 'cpguard-v58812-i91511*.sh' -print0 2>/dev/null |
  while IFS= read -r -d '' f; do
    printf '%s  %s\n' "$(sha256sum < "$f" | cut -d' ' -f1)" "${f#"$ROOT"}"
  done
echo "== done (nothing was changed)"

We tested it in Git Bash on Windows 11 against two dummy folders. This builds the first, with an install log holding 5.88.12, 5.88.17 and 5.88.26 lines, three of the named paths (a directory and two empty files) and a two-line dummy script that has the fake update’s file name:

D=dummy_hit
mkdir -p $D/opt/cpguard/logs $D/var/tmp/.i93677 $D/etc/cron.d $D/tmp
printf '[02-11-2026 02:46:04]: Successfully updated to 5.88.12\n[02-11-2026 08:46:02]: Successfully updated to 5.88.17\n[03-11-2026 01:00:00]: Successfully updated to 5.88.26\n' > $D/opt/cpguard/logs/install_log
: > $D/etc/cron.d/i93677
: > $D/var/tmp/.cpg91511_sh
printf '#!/bin/sh\necho dummy\n' > $D/tmp/cpguard-v58812-i91511b.sh

Running the check against it printed this:

$ ROOT="$PWD/dummy_hit" bash cpg_check.sh
== 1. Install history (the first notice lists 5.88.12 through 5.88.19 as affected)
[02-11-2026 02:46:04]: Successfully updated to 5.88.12
[02-11-2026 08:46:02]: Successfully updated to 5.88.17
== 2. Paths named in the two notices
FOUND  -rw-r--r--  /var/tmp/.cpg91511_sh
FOUND  drwxr-xr-x  /var/tmp/.i93677
FOUND  -rw-r--r--  /etc/cron.d/i93677
== 3. Fake update script names (compare each SHA-256 with the notice)
4a9f88f79c48c4273103a825e8cf4f3917f259804ffdf9bf66822591e8563ff4  /tmp/cpguard-v58812-i91511b.sh
== done (nothing was changed)

A second folder built the same way but holding only the 5.88.26 log line printed “no affected version in the log” and “none of the four paths exist.” Windows file systems have no setuid bit, so our dummy .cpg91511_sh shows plain permissions; the vendor calls the real file a setuid-root shell, so on a real server the mode column would show an s. Any FOUND line means stop and follow the vendor’s steps or contact its support. A clean result is not proof: the vendor says absence after cleanup “does not establish whether the script previously ran,” and its own server carried an implant that hides from ps, netstat, ls and find, which is why it advises checking from a trusted boot environment or a known-good static binary. The vendor reports that implant on its own server, not on customer servers.

Indicators the vendor lists

The disclosure’s table also lists probe files and web shells, a URL path the attacker used to receive stolen data, a gsocket backdoor and a Go implant. It says its last three rows come from OPSSHIELD’s own internal server, “not from customer servers.” We left those rows out here and link the page below. The registry record for the attacker address does not identify an operator: RIPE’s RDAP service lists 94.183.188.0/24 as CloudBackbone with country code FR, registered on October 15, 2025, and carries a remark that Gold IP L.L.C-FZ administers the address resource only while the downstream customer operates the network. A registry record shows who holds an allocation, not who used an address that night.

What the second notice asks you to rotate

1. Update cPGuard to the latest version, then confirm /etc/cron.d/i93677, /var/tmp/.i93677/ and /var/tmp/.cpg91511_sh are gone, and delete them if not.
2. Change the root password and every local user password on the server.
3. Generate new root SSH keys, remove the old public keys from authorized_keys on every server that trusted them, and review authorized_keys for entries you do not recognize.
4. Change the MySQL root password and any database passwords stored in /root/.my.cnf.
5. Rotate any password, API key or token that appears in root’s shell history, plus any keys in /root/.s3cfg.
6. Treat other servers you reach from this one with SSH keys as exposed until their keys are replaced.
7. Reset your OPSSHIELD billing portal password and turn on two-factor login.
8. If OPSSHIELD told you the attacker logged in by hand, rebuild from a clean backup taken before November 1.

What the notices do not say

• Detection and the end of the window. The first notice says the attack was detected within 12 hours. The second gives no detection time, dates the key revocation only to November 2, and does not say what ended the install window at 03:20 UTC.
• The flaw. “Callback pages” on the billing portal and “related vendor components” are the only hints. No application, component, bug class or CVE is named.
• Signing. The company says it will “harden our own update and signing process” and has started re-issuing “all cPGuard license private/public keys, so the copies the attacker holds stop working.” It does not say whether agents verified a signature that the stolen storage key could not forge, what the re-issued keys sign, or whether re-issuing has finished.
• 32 against 2,950. The notices do not say how many of the 2,950 servers’ files the attacker actually retrieved, or how many servers the attacker entered by hand.
• Payment data. The second notice lists five billing fields and never uses the words card, payment or invoice, so it neither confirms nor rules out such data in the copied database.
• Versions 5.88.20 through 5.88.24. They sit between the affected range and the fix, and neither notice discusses them.
• Speed and AI. The disclosure says attackers “now use AI tools to scan for weak points, read unfamiliar code and write custom tools in hours instead of weeks,” and offers the ten-hour timeline as the result. It shows the speed and cites no tool output, model name or transcript for how the work was done.
• Bans. The timeline says cPGuard flagged and banned the attacker twice; the fix list includes “fixing cPGuard so temporary bans are enforced on nftables firewalls.” The page does not connect the two.

Our reading

The second notice supersedes the first on the points that matter for response, and the company says so on the first notice’s banner. For an administrator the safe course is to combine them: treat a server as exposed if its log shows an affected version or if cPGuard was online in the window, check the leftover paths whatever version it runs, and rotate every secret the notices list. A clean script result means little on a server the vendor has told you the attacker logged in to by hand; the second notice says to rebuild those.

The shape is familiar from the vendor-channel incidents we covered recently: Rank Math PRO downloads that carried malware for 11 hours, a poisoned LiteLLM release published by the project’s own pipeline, and Cursor’s marketplace notice that grew from one affected version to two. Here the first notice’s entry point, count and cleanup have been replaced within a day, which is the same kind of revision. What is unusual is the product. The vendor’s changelog shows 5.88.03, dated October 21, carrying “Primary patches against the php2shell PHP vulnerability” (we covered the PHP patch release), so hosts had reason to update promptly, and a script delivered through that update path ran as root. Whether the agent verified a signature is the question the notices leave open.

Sources and related coverage

• OPSSHIELD, cPGuard security advisory: Update channel compromise (archive captures of 23:21 UTC on November 2 and 15:59 UTC on November 3) and Security Incident Disclosure: manage.opsshield.com (archive capture of 21:19 UTC on November 3).
• OPSSHIELD, cPGuard changelog as archived at 06:35 UTC on November 3. The live changelog returned HTTP 503 when we tried it at 10:17 UTC on November 4.
• BleepingComputer, Hackers hijack cPGuard autoupdate to deploy backdoor, steal data, and Namecheap’s What Is cPGuard?.
• RIPE NCC RDAP record for the address the vendor lists, and the NVD keyword search for cpguard (no records on November 4).
• Method: we converted IST times at UTC+5:30, computed intervals ourselves, ran the check script on dummy folders only, and did not download, open or run any file from the fake update or contact the attacker address. BleepingComputer’s was the only report that turned up in our searches, and we found no independent technical analysis, so every account of what happened above comes from the vendor.
• On sxz.io: Rank Math PRO malware, the poisoned LiteLLM release, the tampered Cursor extension and the PHP2Shell patch release.