Commvault CVFS Needs Its Own Update Receipt
A platform job can finish before the person responsible for storage has accepted the result. That handover deserves a clear acceptance condition. The useful question is not simply whether someone ran an update, but what evidence lets the next owner close the change.
Disclosed 13 October, CVE-2026-77099 affects Linux CVFS: critical command injection, CVSS 4.0 9.3. Its low-complexity network path needs no privileges, user interaction or additional conditions; confidentiality, integrity and availability impacts are high.
A change needs an owner
| Linux product | Affected, inclusive | Fixed from |
|---|---|---|
| Commvault Cloud | 11.46.0 to 11.46.29 | 11.46.30 |
| 11.44.0 to 11.44.24 | 11.44.25 | |
| 11.40.0 to 11.40.77 | 11.40.78 | |
| 11.36.0 to 11.36.126 | 11.36.127 | |
| Grid (HSX) CVFS | 5.0.1.0 to 5.0.14.4 | 5.0.14.5 |
Unlisted supported versions are unaffected; unsupported releases need upgrading. On 11.36 and 11.40, update the platform, then CVFS. From 11.44, the resolved HyperScale X release includes CVFS.
That distinction changes the handover between teams. Before the maintenance window, agree who receives the completed job and what result they must check. A closed task in one queue should not silently become an acceptance decision in another.
Make the handover usable
Platform builds: Command Center > Manage > Servers. For CVFS (11.44+), use Manage > Storage > HyperScale X > pool > Nodes > each node. For 11.40 or earlier, use /usr/local/hedvig/scripts/whichCommit.sh in the HSX shell. All nodes must show matching resolved CVFS versions.
This command checks a version; it is not the update itself. Keep expected and observed values together, with a named reviewer for differences. Checking one machine can reveal a problem, but cannot establish the state of an unchecked machine. Give exceptions an owner and a review time rather than hiding them inside an overall green status.
Do not confuse patch closure with an incident verdict
The canonical record’s CISA enrichment assessed exploitation as none on 13 October. Neither primary source supplies victims, incident indicators or an exploit chain. Those are evidence limits, not a guarantee against abuse.
Keep a completed change and an investigation into suspected misuse as separate decisions. Their owners, inputs and closure conditions differ. If an alert later raises a new incident question, the maintenance record should help reconstruct events, not supply a reason to dismiss it.
