Activity Feed

CVE-2024-5217 is an unauthenticated vulnerability in the input validation checks for GlideExpression scripts that results in remote code execution. It is unclear, but I expect that the vulnerability allows an unauthenticated user to provide a GlideExpression script that contains malicious commands that bypass available sanitization and result in code execution on the server.
ServiceNow’s release versioning is non-canonical, so determining if your release is vulnerable is non-trivial. Patched Versions are
Utah
Patch 10 Hot Fix 3
Patch 10a Hot Fix 2
Patch 10b Hot Fix 1
Vancouver
Patch 6 Hot Fix 2
Patch 7 Hot Fix 3b
Patch 8 Hot Fix 4
Patch 9 Hot Fix 1
Patch 10
Washington
Patch 1 Hot Fix 3b
Patch 2 Hot Fix 2
Patch 3 Hot Fix 2
Patch 4
Patch 5

These releases are similar, but not the same as CVE-2024-4879, another input validation vulnerability resulting in unauthenticated RCE. Several other less critical vulnerabilities with similar number have been released. CVE-2024-4879 and CVE-2024-5217 are the most critical in the batch release, and both have been reported as being exploited in the wild with low technical expertise required.

CVE-2024-4879 is a Jelly Template injection vulnerability in ServiceNow resulting from incomplete input validation. ServiceNow’s release cycle is not numbered, but named after states and with non-canonical minor version, so determining vulnerability is somewhat more difficult.
Utah versions that are patched:
Patch 10 and hot Fix 3
Patch 10a and Hot Fix 2
Vancouver versions that are patched are:
Patch 6 Hotfix 2
Patch 7 Hotfix 3b
Patch 8 Hotfix 4
Patch 9
Patch 10
Washington releases that are patched:
Patch 1Hotfix 2b
Patch 2 Hotfix 2
Patch 3 Hotfix 1
Patch 4

Jelly templates are configuration files used by the ServiceNow system; input validation for data into the file is insufficient, allowing an unauthenticated attacker to alter the Jelly Template file to gain code execution. This vulnerability was patched July 10, but as of this week, there are still reports of numerous internet-facing hosts vulnerable to this exploit with other outlets claiming that the vulnerability is being actively exploited in the wild. It is additionally complicated by the near simultaneous release of CVE-2024-5217, which has a similar vulnerability landscape, but a different vulnerability path.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1645154
https://www.imperva.com/blog/imperva-customers-protected-against-critical-servicenow-vulnerability/
https://www.linhttps://www.darkreading.com/cloud-security/patchnow-servicenow-critical-rce-bugs-active-exploitkedin.com/pulse/cve-2024-4879-cve-2024-5217-exposed-risks-rce-servicenow-nfmtc

This vulnerability is highly technical in that it is closer to a jailbreak than a traditional exploit. The Cisco Nexus switches affected by this exploit:
MDS 9000 Series Multilayer Switches, Nexus 3000, 6000, 7000, 9000 series Switches, and the Nexus 5500 and 5600 Series Platform switches all run a modified version of the Linux Kernel that is abstracted to prevent a user from accessing underlying OS commands not required for switching operation.
CVE-2024-20399 allows an attacker to break through this abstraction layer to issue OS commands directly to the Linux Kernel, allowing the attacker full control of the switch’s underlying operating system.
Through this access, attackers can install implants, routes, or other malicious configuration settings to the switch beyond the standard Cisco command interface, possibly bypassing some logging.
Although possession of such access to a critical and wide-ranging device like a Nexus switch is a powerful tool to an attacker, the advantage this gains is marginal as it required administrative-level credentials to implement the exploit.
Standard controls are recommended to mitigate this attack- certainly, patching is important, but relatively few individuals in an organization require administrative access to Nexus-type switches, and their size and criticality to business uptime preclude them from frequent changes. Limiting the number of individuals with access and logging/alerting to login events on them would not create an undue burden in most cases.