It can really depend on the nature of the vulnerability and who discovered it. Based on the timeline at the bottom of this article it seems like this was way too slow. Based on the cve information this was ranked as 9.8. The last time I dealt with a bug that bad it was log4j. It was found on a Tuesday, patched on a Thursday, announced on a Friday, and I redeployed all of our servers over the weekend.

The most egregious part in my eyes is the slow response to the initial contact. In shows that Service Now does not monitor it's reporting and that they don't care about security. If I were using a product of theirs to handle proprietary or privileged information I would no longer trust them.

I suspect the CVSS score has been over-estimated. For the "scope" metric, the "vulnerable component" and the "affected component" are both ServiceNow itself, so that should be "unchanged": https://security.stackexchange.com/a/129205

That drops you down to an 8.8. Also, log4shell was a 10.0, which got that extra .2 points from not requiring any privs, whereas this ServiceNow vuln requires "low" privs.

Hi, ServiceNow dev here. I'd agree that the CVSS might be a little overinflated, but I don't think by much.

I would argue that ServiceNow as a singular component is flawed. It could be several applications on a single instance: Vulnerability Response, Security Incident Response, IT Service Management, IT Operations management, Vendor Risk Management, CMDB, etc.

I actually think in some instances, this vulnerability is considerably worse due the information it provides. User contact information, an inventory of the security vulnerabilities across the organization, applications & versions, Server information, etc. The social engineering issues are massive since they can spoof from essentially your service desk.

Often times ServiceNow has access to other subsystems. Midservers, provisioning tools, monitoring systems, desktop orchestration tools. These systems are often used to handle the response & monitoring. The ServiceNow teams are often understaffed and underskilled.

I've only been thinking about this for the last hour, but compromise 1 account (and I can think of at least 5 different ways that could happen) and a hacker could have:

- a complete topology of your infrastructure

- your active security vulnerabilities

- contact information for your entire company

- a very convincing spoofing method

- the ability to remotely install software on customer desktops

- the ability to monitor your response to security issues

- access to your provisioning tools

This kind of attack could go undetected for years. God forbid ServiceNow's internal instance got compromised. They can remote in to ANY instance.

No, judging from the Disclosure Timeline at the very bottom, it appears the lengthy remediation is due to ServiceNow dragging their feet. Took them over a month, plus a followup email, just to get them to respond to the initial report.

In any other software I would say no, but it's ServiceNow, so yes.

My experience with this sort of enterprise software is that if you are a user, there is usually someone higher up the org chart than you that is worried such a disclosure will damage his relationship with his mate. My point being, much like Oracle, the usual timeline is that you never go public.

Yes - I worked at a place which had that experience with them. Massive outage: down for weeks, data lost, etc. We paid millions for “support” and had very little to show for it. Things escalated, and their regional VP took our senior VP out to the corporate box to discuss it over football. Monday morning, word came out to stop talking about the problem where possible. A bunch of people worked nights & weekends to get it patched up but didn’t even get thanked by anyone above their immediate supervisor.

That story makes me incredibly angry, and quite sad, actually.

ServiceNow ships major upgrades twice a year and patches every month. It means that they could genuinely not figure out how to remediate this quickly and quietly without disrupting ongoing contract negotiations. It means that even with that, they couldn't fix it for a whole year.

They negotiate multiyear contracts. they're investing into government and healthcare services.

I have to correct myself. Apparently the vulnerability was patched in San Diego patch 7 which was release on September 1st 2022. It wasn't disclosed until June 2023.

I am still mad they didn't release it as a hotfix, but that meant they couldn't sneak it under the radar.