Commvault CVE-2025-34028: upgrading to 11.38.20 is not the whole fix
CVE-2025-34028 gives pre-auth RCE on Commvault Command Center. The patch landed in April and the federal deadline passed in May, but the fix requires supplemental update packages beyond the base version, and most shops check the version number and stop there.
Commvault Command Center shipped a patch on April 10 for CVE-2025-34028, a pre-authentication remote code execution vulnerability with a CVSS 10.0 score. CISA added it to the Known Exploited Vulnerabilities catalog on May 2, set the federal deadline for May 23, and confirmed active exploitation. The watchTowr Labs proof-of-concept went public April 24.
If you upgraded to 11.38.20 and considered it done, there’s a step that’s easy to miss.
Who’s in scope
This CVE only affects the Innovation Release track, versions 11.38.0 through 11.38.19. If you’re on an LTS branch (11.20, 11.28, 11.32, or 11.36), CVE-2025-34028 doesn’t apply to you. Commvault Metallic SaaS customers were patched automatically.
LTS users are not entirely clear, though. CVE-2025-3928 is a separate webshell vulnerability affecting those branches. It was exploited by a nation-state actor in a breach of Commvault’s own Azure environment in February 2025, and it’s also in the KEV catalog. Different CVE, different branch, different attack surface, but if you haven’t addressed it, the picture isn’t clean.
For the rest of this post, the concern is Innovation Release 11.38.x.
What the exploit does
The vulnerable endpoint is /commandcenter/deployWebpackage.do, and it doesn’t require authentication. Commvault’s own authSkipRules.xml explicitly lists it as an endpoint the authentication filter skips.
An attacker sends an unauthenticated POST with a commcellName parameter pointing to a server they control. Commvault’s Command Center fetches a ZIP from that server. A second parameter, servicePack, controls where the ZIP is decompressed, and there’s no input validation, so a traversal sequence pushes the contents into a Tomcat-mapped web directory. A malicious JSP file in the ZIP lands there and executes with the privileges of the Commvault service account. No credentials required. One request to trigger the fetch, one request to run the shell.
Commvault confirmed that in the observed exploitation cases, attackers deployed credential scraping tools after gaining access. That’s the relevant consequence: Command Center stores service account credentials for every system it backs up: hypervisors, databases, domain accounts, cloud provider tokens. RCE on the backup server translates directly into credentials across the environment.
The patch has a second step
Commvault updated the advisory on May 7 to clarify something not in the initial release: reaching version 11.38.20 or 11.38.25 is required but not sufficient. Specific supplemental packages must also be installed.
For 11.38.20: SP38-CU20-433 AND SP38-CU20-436.
For 11.38.25: SP38-CU25-434 AND SP38-CU25-438.
Both packages are required for each fixed version. Arctic Wolf’s follow-up documented this after the initial advisory left it out.
To verify: open Command Center, go to the Server listing page, select each CommServe installation, and check the Additional Updates section. Both package names need to be listed. If they’re not, the endpoint is still open.
Checking whether you were hit
Exploitation leaves tracks. Check your Apache Tomcat access logs, on a default install at <ContentStore>\Apache\logs\access_log on Windows or the equivalent on Linux, for:
- POST requests to
/commandcenter/deployWebpackage.dofrom unexpected external IPs - GET requests to paths under
/reports/MetricsUpload/shell/or any path containing.tmp/dist-cc/
On the filesystem, no legitimate Commvault file under <ContentStore>\Reports\MetricsUpload\ should be a .jsp. If one exists, treat the host as compromised and assume every stored credential has been taken.
If your environment includes both Innovation Release and LTS instances, also check for ASPX webshell files named default.aspx or shell.aspx in unexpected locations, and look for connections to cloudsyncsvc[.]net or metabackup[.]org in your network logs. Those are the published IOCs from the CVE-2025-3928 Metallic incident. Separate vulnerability, but worth running if you’re already in the logs.
Why ransomware operators target backup infrastructure
Sophos’s 2024 ransomware survey across 2,974 affected organizations found that 94% of attacks attempted to compromise backup repositories, and 57% of those attempts succeeded. Organizations that lost their backups paid ransom at nearly double the rate of those whose backups stayed intact: 67% versus 36%.
Intact backups remove the attacker’s leverage. So they target the backup system before triggering the encryption payload. Command Center is the management plane for that system: it can delete backup jobs, disable retention, and redirect restores. An attacker who owns it doesn’t need to encrypt anything to strand you.
We’ve written about this same logic in the context of Veeam before. CVE-2025-34028 is the Commvault expression of the same targeting pattern, and the CISA KEV listing confirms it’s being used the same way.
What to do
On Innovation Release 11.38.x:
- Upgrade to 11.38.20 or 11.38.25
- Apply both supplemental packages for your version (SP38-CU20-433 and SP38-CU20-436 for 11.38.20; SP38-CU25-434 and SP38-CU25-438 for 11.38.25)
- Confirm both packages appear in the Additional Updates section of Command Center before closing the ticket
If you can’t patch immediately:
- Isolate Command Center from external network access. That’s Commvault’s documented interim mitigation
- Use Commvault’s IP allowlist feature to restrict Command Center access to known management IPs
Regardless of version:
- Treat the Commvault server as Tier-0 infrastructure: segment it, monitor it closely, and manage its service accounts under a PAM solution
- Maintain at least one backup copy that Command Center itself cannot modify: object lock, immutable storage, or an air-gapped copy. If an attacker compromises the management plane, that copy is what saves you
Sources
- Commvault Security Advisory CV_2025_04_1 — 2025-04
- NVD CVE-2025-34028
- watchTowr Labs: Fire In The Hole, We’re Breaching The Vault — 2025-04
- Arctic Wolf: CVE-2025-34028 Follow-Up — Fixed Versions — 2025-05
- CISA Known Exploited Vulnerabilities Catalog
- Censys Advisory: CVE-2025-34028 — 2025-05
- Sophos State of Ransomware 2024 — 2024
Share
Related field notes
-
Why ransomware crews love a backup server twice over
CVE-2022-36537 is a ZK Framework bug that handed attackers ConnectWise R1Soft backup servers. A backup server is the perfect ransomware target for two reasons at once: it can push code to everything it protects, and destroying it removes the one thing that lets a victim refuse to pay.
-
Ransomware crews keep hitting Veeam for the same two reasons
Four Veeam Backup & Replication CVEs feed the same playbook. Attackers target the backup server because it can destroy your recovery option and because it holds the credentials to everything it backs up. CVE-2024-40711 took Akira and Fog from access to ransomware fast.
-
The backup agent on every server was ALPHV's way in
Veritas Backup Exec's agent listens on every machine it backs up. Three 2021 CVEs in it, CVE-2021-27876, 27877, and 27878, let ALPHV/BlackCat affiliates get in. Backup infrastructure isn't just a destruction target; its agents are an attack surface on every host.
-
Your attack surface isn't just port 443
CVE-2023-46604 is a perfect-10 RCE in Apache ActiveMQ. The exploit isn't a web request; it's a single message to the broker on port 61616, a port most web-focused scanning and firewalling never considers. The broker then fetches a remote XML file and runs whatever's in it.
Get the free CVE triage cheat sheet
Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.
Subscribe