macadmin.fraserhess.com

Yesterday, Ivanti disclosed CVE-2025-22460, a use of default passwords in their Cloud Services Application. The CSA is a pseudo-reverse proxy for Ivanti’s on-premise Endpoint Manager. The fix requires a fresh install of CSA 5.0.5 or running mitigation steps (login required) after upgrading from 5.0.0-5.0.4.

This disclosure began for me last month due to a finding in Google Cloud Platform’s Security Command Center that identified that the “gsbuser” had a hash of a weak password in the CSA’s PostgreSQL database. Our security team asked me to investigate and hopefully mitigate this finding. My first approach was simply to attempt to change the password, but Ivanti had no documentation on this user except that the username should not be used by the underlying Linux OS and was reserved to the CSA. After fumbling about with psql commands, I was able to guess the gsbuser’s password on the first attempt—not a good sign. (Later, I was able to confirm with another customer in Germany that they had the same username and password in their CSA database.)

Further exploration found that the user had rights to do almost anything in the CSA’s database, from changing configuration to reading users and their encrypted passwords, to truncating (dropping all rows) every table.

Put together, a local, authenticated, unprivileged user could guess this default password and compromise the CSA. The CVSS 3.1 score of 7.8/10.0 reflects these circumstances.

Through Ivanti’s vulnerability disclosure program I submitted a report, which was promptly handled. At all stages, the Ivanti representative that handled my case was professional and responsive. After my initial report, it was reviewed internally and determined that it had been resolved in CSA 5.0.5. However, my 5.0.5 instance clearly still had use of a default password, so I proposed that perhaps this had not been mitigated in upgrades to 5.0.5. While Ivanti investigated that possibility, I was asked to confirm that the vulnerability was resolved in a fresh install of CSA 5.0.5.

Working on the test system, I was able to confirm that a fresh install did not have the default password. In fact, it didn’t even have the gsbuser account in the database. Again on the test system, I was able to confirm that installations of 5.0.0 and 5.0.4 did create the gsbuser account with a default password. Upgrading those installations to 5.0.5 left the account intact.

Ivanti confirmed all the findings and said that an advisory with mitigation steps would be forthcoming. The disclosure occurred on May 2025’s Patch Tuesday. We followed the mitigation steps without incident and encourage all CSA customers to do likewise.

I thank my colleagues Matthew Dulong, Douglas Shaw, and Todd Seidenberg for technical review and helping me reproduce the vulnerability. Thanks are also due to Robin Peters for his assistance in testing at another Ivanti customer.