NewsCSO OnlineFinancePublic sectorSME

    ServiceNow patches three maximum severity flaws that could put enterprise data at risk

    Code injection and SQL injection attacks have been around for decades, and they are still tried-and-true ways for attackers to compromise systems. ServiceNow’s latest trio of maximum severity flaws shows that even AI-era platforms remain vulnerable to these techniques: The software provider has released patches for three bugs in its ServiceNow AI Platform that could be exploited via low-complexity code injection, SQL injection, and privilege escalation attacks, with no user interaction required. Although its cloud-based instances have already been updated, ServiceNow advises self-hosted customers to upgrade or patch immediately. “You never want to see a 10/10 critical,” said David Shipley of Beauceron Security. “And you really don’t want to see three drop in row unless it’s an Olympic judging panel.” Gives attackers the ability to access, modify and create data The ServiceNow AI Platform, formerly the Now Platform, combines AI and autonomous agents, data, and security and governance controls across enterprise IT, employee, and customer relationship management (CRM) workflows. That makes it a juicy target for attackers. The three critical vulnerabilities now being patched are tracked as CVE-2026-18885 , CVE-2026-18886 , and CVE-2026-74820 . CVE-2026-18885 would allow unauthenticated users to execute arbitrary code and access and/or modify instance data. CVE-2026-18886 could give malicious actors the ability to create or change instance data and escalate privileges, and the CVE-2026-74820 vulnerability could allow attackers to execute arbitrary SQL statements against an instance’s underlying database to alter data. Along with these, ServiceNow also patched the high-severity CVE-2026-6876 , a sandbox escape vulnerability impacting ServiceNow AI. This vulnerability could allow attackers with basic privileges to perform remote code execution (RCE). ServiceNow said in its advisory that it was “not currently aware of exploitation” of any of the flaws. The company has released patches for all four, for impacted Xanadu, Yokohama, and Zurich versions of the platform. Recently, ServiceNow has also issued patches for several other critical vulnerabilities, including June’s API issue and last month’s CVE-2026-6875 , a pre-authentication sandbox escape in its AI Platform. Like the vulnerabilities disclosed this week, it could allow unauthenticated users to execute code. And earlier this month, independent research also identified attacks exposing company data . Concerning severity and accessibility What makes the current vulnerabilities particularly serious is the combination of severity and accessibility, noted Ensar Seker , CISO at SOCRadar; exploitation can potentially occur without authentication. “That means an attacker may not need to steal credentials or compromise an employee before attempting to exploit the platform,” Seker said, noting that CVE-2026-18885 is especially concerning because it could support arbitrary code execution through the GraphQL Composite Data API. This means that, in a successful attack, “code injection can effectively turn a trusted enterprise application into an attacker-controlled execution environment,” he pointed out. CVE-2026-74820 presents a different, but equally serious risk, he said. With SQL injection, an attacker can interact with an underlying database in unintended ways, potentially reading, manipulating, or destroying data. In general, code injection and SQL injection attacks are dangerous because they break fundamental security boundaries between data supplied by a user and instructions executed by a system, Seker explained. Once attacker-controlled input is interpreted as code or a database command, application-level access controls may no longer be adequate. Then, he noted, there’s the role ServiceNow plays inside enterprises that use it across their operations, assets, approvals, and integrations. Successful attackers can not only gain access to sensitive operational data, but move laterally and abuse trusted customer and partner workflows and integrations. “Compromising that type of platform can therefore be much more significant than compromising a standalone application,” he said. Attackers targeting platforms with extensive integrations may be more interested in the credentials, tokens, and systems connected to them, rather than just the platform itself. Patch, but also verify external integrations The immediate priority for enterprises is to determine which ServiceNow instances and versions they operate, and confirm they have been patched, Seker advised. Security teams should also inventory ServiceNow integrations, APIs, and highly privileged service accounts. Further, he said, teams should review historical telemetry for indicators of attempted exploitation, like unusual requests involving affected APIs and upload functionality. They should also look for unexpected administrative or privilege changes, unexplained creation or modification of records, anomalous service-account behavior, and unusual access to sensitive ServiceNow data. If suspicious activity is flagged, look for downstream systems connected to ServiceNow rather than treating it as an isolated application. Overall, Seker noted, AI changes the economics of vulnerability exploitation more than it changes the underlying vulnerability. Attackers are using AI to analyze disclosures, generate and modify exploit attempts, enumerate exposed services, adapt payloads to different environments, and automate post-exploitation activity. Work to reduce time to remediation “The period between public disclosure and widespread exploitation can therefore become increasingly compressed,” Seker said. This means organizations should work to reduce time between disclosure, exposure assessment, and remediation. This requires strong API authentication and authorization, strict input validation, parameterized database queries, least-privilege access, integration segmentation, application and API-layer monitoring, and controls that detect anomalous behavior, he emphasized. Internet-facing interfaces should also be minimized. But injection vulnerabilities are not new, he observed. Established controls like secure coding and static and dynamic API and adversarial testing prior to production can help eliminate weaknesses. Also assume that AI will continue to automate threat actors’ vulnerability discovery and exploitation, he added. By that token, defenders should implement similar automation around asset discovery, exposure validation, and remediation. In addition, security teams should not evaluate SaaS and enterprise platforms solely on their traditional vulnerability-management processes. Risk should be assessed on their blast radius: The data they contain, the systems, credentials, and APIs they access, and what an attacker could do, Seker said. Accessibility, no interaction required Beauceron’s Shipley pointed out that, while these vulnerability disclosures are critical for builders, they present a conundrum: Attackers now know about them, too. Within 15 minutes of ServiceNow’s publication, if not sooner, they were likely exploiting the flaws. While there was no previous evidence of exploit attempts, “you can take it to the bank that these are getting worked now,” he said. Unauthenticated access and network accessibility can create a “sweet exploit chain,” and low complexity exploits with no interaction required “make security professionals’ blood run cold.” “SQL injection is part of the OG group of web vulnerabilities that just keep on delivering,” he pointed out. Billions of lines of code still contain basic failings like these, revealing a lack of incentive on the part of software makers to ship secure code. “Until we change that,” he said, “the so-called Vulnpocalypse is here to stay.”

    Linked advisories

    Affected vendors and products

    More on ServiceNow

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4215430/servicenow-patches-three-maximum-severity-flaws-that-could-put-enterprise-data-at-risk.html

    ID