ServiceNow Patches Three CVSS 10.0 Vulnerabilities Allowing Unauthenticated Code Execution and SQL Injection

ServiceNow has patched three critical vulnerabilities in its AI Platform, all rated CVSS 4.0 10.0, that could allow unauthenticated attackers to execute arbitrary code, manipulate instance data, escalate privileges, or execute SQL statements against the underlying database. A fourth vulnerability, rated 8.7, also enables code execution through a sandbox escape.

ServiceNow has disclosed and patched a particularly serious group of vulnerabilities affecting its AI Platform, including three flaws carrying the maximum CVSS 4.0 score of 10.0.

The vulnerabilities are notable not simply because of their severity scores, but because the three critical issues share an unusually dangerous attack profile: they are remotely reachable, require no authentication, require no user interaction, and are rated low complexity by ServiceNow.

The affected functionality includes the GraphQL Composite Data API, a system configuration image upload processor, and a dynamic-schema database query path. Depending on the vulnerability, successful exploitation could result in arbitrary code execution, unauthorized modification of ServiceNow instance data, privilege escalation, or arbitrary SQL execution against the underlying database.

ServiceNow says it has already deployed security updates to its hosted environments and provided fixes to partners and self-hosted customers. Organizations operating their own ServiceNow infrastructure, however, must make sure the relevant patches have actually been applied.

At the time of publication, ServiceNow said it was not aware of malicious exploitation of the newly disclosed vulnerabilities. No public exploit code for the three CVSS 10.0 vulnerabilities had been identified in the reporting reviewed for this article.

That distinction matters. These vulnerabilities should not be described as actively exploited simply because they are critical. However, their pre-authentication attack surface and potential impact make them high-priority patching candidates.

ServiceNow Vulnerability Overview

The August 27 advisory covers four vulnerabilities:

The three 10.0 vulnerabilities all received the same CVSS 4.0 vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

In practical terms, that means an attack can be launched over the network, is considered low complexity, requires no privileges and no user interaction, and can have high confidentiality, integrity and availability consequences both within the vulnerable system and on subsequent systems.

CVE-2026-18885: Unauthenticated Code Injection in GraphQL Composite Data API

The first and arguably most immediately alarming vulnerability is CVE-2026-18885, a code injection vulnerability affecting the ServiceNow AI Platform’s GraphQL Composite Data API.

ServiceNow describes the vulnerability as allowing an unauthenticated user, under certain circumstances, to execute arbitrary code within the platform. Successful exploitation could also give the attacker access to or allow modification of instance data outside the intended authorization boundaries.

The CVE has been classified as CWE-94, Improper Control of Generation of Code, which is consistent with the vulnerability’s code-injection nature.

Why GraphQL matters

GraphQL is an API technology that allows clients to request structured data through queries rather than relying exclusively on traditional REST-style endpoints.

That flexibility can be valuable for enterprise applications, but it also means that API parsing, schema handling, resolver logic and input validation become important security boundaries.

In this case, the vulnerable component is specifically the GraphQL Composite Data API. The critical security issue is not GraphQL itself. Rather, it is the way ServiceNow’s implementation processes attacker-controlled input and ultimately permits code injection.

For an attacker, the most important characteristic is that the vulnerability is described as pre-authentication. No valid ServiceNow account is required according to the vendor’s description.

If arbitrary code execution is achieved, the consequences can extend far beyond the original API request. Depending on the privileges and capabilities of the execution context, an attacker may potentially access sensitive records, manipulate business data, alter configuration, establish persistence or use the compromised ServiceNow environment as a stepping stone toward connected infrastructure.

The CVE record confirms a CVSS 4.0 score of 10.0 and identifies the vulnerability as remotely exploitable with no privileges and no user interaction.

CVE-2026-18886: Unauthenticated Privilege Escalation Through Image Upload Processing

CVE-2026-18886 takes a different route.

Instead of directly describing code injection or SQL injection, ServiceNow identifies this vulnerability as an improper access control issue in the system configuration image upload processor.

The security problem could allow an unauthenticated attacker, under certain circumstances, to create or modify ServiceNow instance data beyond what should normally be permitted. ServiceNow says this can result in privilege escalation.

This is a particularly important distinction for defenders.

Access control vulnerabilities can be dangerous even when they do not initially provide direct operating-system-level code execution. Enterprise platforms contain highly privileged workflows and data relationships. If an attacker can manipulate objects that should only be accessible to administrators or trusted services, they may be able to turn a relatively narrow authorization failure into a much larger compromise.

The critical CVSS rating reflects the fact that the vulnerability is remotely reachable and does not require authentication or user interaction.

The security boundary being crossed

At a conceptual level, the vulnerability demonstrates why an upload feature should never be treated simply as a file-handling function.

An image upload endpoint may interact with:

• System configuration
• Metadata
• Database records
• Application properties
• Object identifiers
• Access-control decisions
• Backend processing routines

If authorization is missing at one of those boundaries, an attacker may be able to make the application perform an operation on their behalf that should require elevated privileges.

The available public information does not provide enough technical detail to responsibly reconstruct the exact exploitation chain, so claims about a specific payload or exploitation sequence should be avoided until ServiceNow or the reporting researchers publish additional technical analysis.

CVE-2026-74820: Critical Unauthenticated SQL Injection

The third CVSS 10.0 vulnerability is CVE-2026-74820, an SQL injection flaw in the ServiceNow AI Platform.

ServiceNow’s CVE record describes it as an unauthenticated SQL injection vulnerability reached through a dynamic schema ORDER BY clause. Under certain circumstances, an attacker could execute arbitrary SQL statements against the underlying database and access or modify instance data beyond what was intended.

The vulnerability is classified as CWE-89, the standard weakness classification for improper neutralization of special elements used in an SQL command.

Why an ORDER BY clause can become dangerous

For non-security readers, ORDER BY simply determines how database results are sorted.

For example, an application might internally construct a query equivalent to:

SELECT ... FROM records
ORDER BY created_at;

The security problem occurs when an application treats attacker-controlled input as trustworthy SQL syntax instead of strictly validating it and separating data from executable query structure.

A vulnerable dynamic-schema mechanism can therefore become an injection point if the application does not correctly constrain which fields or expressions may appear in the ordering portion of a query.

The ServiceNow vulnerability is more serious than an ordinary application-level sorting bug because the vendor says an unauthenticated attacker could, in certain circumstances, execute arbitrary SQL against the underlying database.

The potential impact therefore includes unauthorized access to database information and unauthorized modification of data.

CVSS 10.0 confirmed

The published CVE record gives CVE-2026-74820 the following CVSS 4.0 vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

It therefore receives the maximum 10.0 Critical score.

Independent vulnerability databases also record the same maximum score.

CVE-2026-6876: Another ServiceNow Sandbox Escape Rated 8.7

The August disclosure also includes CVE-2026-6876, a separate sandbox escape affecting the Now Platform.

ServiceNow rates this vulnerability CVSS 4.0 8.7, placing it in the High severity category.

The flaw could allow an unauthenticated user to execute arbitrary code within the Now Platform. However, its CVSS vector differs materially from the three 10.0 vulnerabilities. In particular, the vector specifies low privileges required, rather than PR:N, and does not assign impact to subsequent systems.

That distinction is important.

It would be misleading to simply group CVE-2026-6876 together with the three 10.0 flaws as though they had identical exploitation requirements. They do not.

Nevertheless, the fact that another sandbox escape was disclosed in the same broader platform security context deserves attention, especially because ServiceNow had already addressed another pre-authentication sandbox escape, CVE-2026-6875, earlier in 2026.

The CVE-2026-6875 Connection

The latest disclosures arrive only weeks after a serious ServiceNow sandbox escape, CVE-2026-6875, received widespread attention.

ServiceNow published the CVE-2026-6875 advisory on July 13, 2026. The vulnerability was described as a remote code execution issue in the ServiceNow AI Platform that could allow an unauthenticated user to execute code within the platform. NVD’s record lists a CVSS 4.0 vector with high attack complexity and an overall score of 9.5.

Security researchers at Searchlight Cyber reported the vulnerability to ServiceNow on April 1, 2026. Their subsequent technical research described a sandbox escape capable of compromising the ServiceNow instance and potentially reaching connected proxy or MID infrastructure.

The research is significant because ServiceNow instances often interact with infrastructure outside the SaaS application itself.

Searchlight Cyber specifically noted that connected MID Servers can sit inside an organization’s internal network. In an appropriately compromised environment, code execution within ServiceNow could therefore have implications beyond the ServiceNow instance itself.

CVE-2026-6875 Was Reported in Exploitation Activity

The July vulnerability also demonstrated how quickly interest in ServiceNow vulnerabilities can turn into exploitation attempts.

After public disclosure and publication of technical exploitation material, threat intelligence reporting indicated exploitation activity involving CVE-2026-6875. The Canadian Centre for Cyber Security subsequently warned that open-source reporting indicated the vulnerability was being exploited in the wild.

However, the situation requires an important qualification.

Defused later corrected its initial reporting after determining that the captured payload matched Searchlight Cyber’s publicly released proof of concept. ServiceNow separately stated that it had not observed evidence that the reported activity was related to instances it hosts.

This history is relevant to the current vulnerabilities because it demonstrates why organizations should not wait for an exploit to appear before patching a critical, pre-authentication ServiceNow flaw.

Why These Three CVSS 10.0 Vulnerabilities Are So Serious

A CVSS score alone does not tell an organization exactly how likely exploitation is. But the individual metrics behind the 10.0 scores are unusually concerning.

The three vulnerabilities have:

• Network attack vector: An attacker can reach the vulnerable functionality over a network.
• Low attack complexity: ServiceNow considers exploitation technically straightforward once the necessary conditions are met.
• No privileges required: The attacker does not need an authenticated ServiceNow account.
• No user interaction: There is no requirement for a victim to click a link or open a malicious document.
• High confidentiality impact: Sensitive information may be exposed.
• High integrity impact: Data may be modified.
• High availability impact: The attacker may potentially disrupt functionality.
• High subsequent-system impact: The consequences can extend beyond the immediately vulnerable component.

This combination is what makes the vulnerabilities particularly attractive from an attacker’s perspective.

A remote, unauthenticated vulnerability with low complexity removes several traditional defensive barriers simultaneously.

What an Exploitation Chain Could Mean

The individual vulnerabilities have different primitives, so they should not be treated as one confirmed exploit chain.

However, from a defensive perspective, the potential outcomes are significant.

1. Initial unauthorized access

An attacker could begin with an exposed vulnerable ServiceNow endpoint without possessing valid credentials.

2. Code or database execution

Depending on the vulnerability, the attacker could potentially reach an arbitrary code execution primitive or execute SQL against the underlying database.

3. Data access

ServiceNow environments can contain highly sensitive enterprise information, including tickets, customer records, employee information, configuration data, credentials stored in integrations, and operational workflows.

4. Data manipulation

An attacker with sufficient privileges could potentially modify records, alter workflows or interfere with business processes.

5. Privilege escalation

CVE-2026-18886 specifically carries a privilege-escalation consequence, demonstrating that authorization boundaries are an important part of the affected attack surface.

6. Lateral movement

Where a compromised ServiceNow environment has privileged connections to internal infrastructure, the compromise could potentially become an entry point into connected systems.

Searchlight Cyber’s earlier CVE-2026-6875 research highlights why this last stage deserves particular attention. Connected MID Servers can provide bridges between ServiceNow and internal networks.

This does not mean exploitation of the newly disclosed vulnerabilities automatically results in an internal network compromise. The exact blast radius depends on the instance’s architecture, integrations, privileges and network configuration.

Affected ServiceNow Versions

ServiceNow’s August advisory lists the following affected release families and fixed versions. Organizations should compare their exact release, patch and hot-fix level against the vendor’s advisory rather than assuming that being on the correct family name is sufficient.

The underlying CVE records confirm these affected-version boundaries.

There is a specific caveat concerning CVE-2026-18886 and Australia Patch 5. The CVE record carries an unknown status for that version, unlike the affected status shown for the corresponding boundary on the other vulnerabilities. Administrators should therefore rely on ServiceNow’s official security advisory and their instance-specific patch information rather than extrapolating across the four CVEs.

Hosted vs. Self-Hosted ServiceNow Customers

The remediation process depends heavily on how the ServiceNow environment is operated.

ServiceNow-hosted instances

ServiceNow says it deployed the security updates to hosted instances.

That reduces the operational burden on customers, but organizations should still verify that their instance is running a remediated version and review their security monitoring for suspicious activity.

Self-hosted and partner-managed environments

Customers operating their own instances need to apply the relevant updates or upgrade to a fixed release.

This is the group that should be most concerned about patch verification.

Simply receiving a ServiceNow security notification does not mean the vulnerable instance has been remediated.

What Security Teams Should Do Now

1. Identify every ServiceNow instance

Inventory production, development, test and partner-managed environments.

Do not assume that the production instance is the only relevant target.

2. Determine the exact release and patch level

Record the ServiceNow family and complete patch/hot-fix level.

Compare it directly against the fixed releases listed above.

3. Patch self-hosted systems immediately

If the environment is running an affected version, apply the appropriate ServiceNow security update or move to a fixed release.

For externally accessible systems, this should be treated as a high-priority remediation.

4. Confirm the update actually took effect

Do not stop at the change ticket.

Verify the installed version and patch state from the affected instance.

5. Review external exposure

Determine which ServiceNow endpoints and APIs are reachable from the public Internet.

Pay particular attention to environments exposing functionality associated with the affected AI Platform components.

6. Review authentication and access controls

Although the three 10.0 vulnerabilities do not require authentication, reducing unnecessary public exposure remains useful as a defense-in-depth measure.

7. Monitor for suspicious activity

Security teams should review available ServiceNow logs, web access logs, WAF telemetry, API activity and database-related events for anomalous behavior around the affected systems.

Look for unusual unauthenticated requests, unexpected administrative changes, unexplained data modifications and abnormal API activity.

8. Investigate before patching if compromise is suspected

If telemetry indicates suspicious activity, preserve relevant logs and evidence before making changes that could destroy forensic information.

Patching closes the vulnerability. It does not automatically remove an attacker who may already have established persistence.

Should Organizations Assume They Were Compromised?

No.

There is currently no basis for saying that every vulnerable ServiceNow instance has been compromised.

ServiceNow explicitly states that it is not currently aware of malicious exploitation against the newly disclosed vulnerabilities.

At the same time, organizations should not interpret the absence of known exploitation as evidence that their environment is safe.

The correct security posture is:

Patch first, then verify.

For Internet-facing, self-hosted instances that remained vulnerable after disclosure, security teams should additionally examine logs and monitoring data for suspicious activity during the exposure window.

No Public PoC for the Three New Critical Bugs Yet

As of August 28, 2026, the available reporting reviewed for this article did not identify a public proof of concept for CVE-2026-18885, CVE-2026-18886 or CVE-2026-74820. The Hacker News likewise reported that it had found no public exploit code for the three maximum-severity vulnerabilities.

That situation can change quickly.

The CVE records were published on August 27, meaning the vulnerabilities are still extremely new. Security researchers, vulnerability brokers and threat actors will likely continue analyzing the affected APIs and processing paths.

The recent history of CVE-2026-6875 is an important reminder that the time between public technical disclosure and exploitation can be short.

CVSS 10.0 Does Not Mean “Guaranteed Exploitable Everywhere”

There is another important nuance for security professionals.

A CVSS 10.0 score does not mean that every ServiceNow installation can be compromised immediately with a single request.

CVSS measures the characteristics and potential impact of a vulnerability. It does not establish:

• Whether the vulnerable functionality is exposed in a particular deployment
• Whether a specific configuration is required
• Whether a working exploit is publicly available
• Whether exploitation has been observed
• How easily an attacker can discover the vulnerable endpoint
• Whether compensating controls block exploitation

ServiceNow’s own descriptions repeatedly use language such as “in certain circumstances.”

That qualification should remain in reporting about these vulnerabilities.

The important point is that ServiceNow has assessed the vulnerabilities as having the maximum severity under CVSS 4.0 and recommends prompt remediation.

Why ServiceNow Is Becoming an Increasingly Important Security Target

ServiceNow is not simply a ticketing application.

Large organizations frequently use the platform as an operational hub connecting IT service management, security operations, customer workflows, employee processes, automation and other enterprise systems.

That makes security flaws in its core platform potentially more consequential than vulnerabilities in an isolated business application.

The CVE-2026-6875 research provides a useful illustration. Searchlight Cyber reported that successful exploitation could allow access to ServiceNow data and potentially execution on connected proxy servers.

This means defenders should think about ServiceNow as part of an organization’s identity, automation and integration architecture, not merely as a web application.

A compromise could affect the confidentiality and integrity of information flowing through the platform, while integrations could potentially expand the attack surface further.

ServiceNow Vulnerability Timeline

April 1, 2026

Searchlight Cyber reports CVE-2026-6875 to ServiceNow. (Searchlight Cyber)

July 13, 2026

ServiceNow publicly discloses CVE-2026-6875 and releases remediation information. (NVD)

July 2026

Independent reporting identifies exploitation activity involving CVE-2026-6875, followed by clarification regarding the relationship between observed payloads and the published proof of concept.

August 27, 2026

ServiceNow publishes its latest advisory covering CVE-2026-18885, CVE-2026-18886, CVE-2026-74820 and CVE-2026-6876.

August 28, 2026

The three new maximum-severity vulnerabilities remain listed at CVSS 4.0 10.0, while CVE-2026-6876 is rated 8.7. ServiceNow says it is not currently aware of malicious exploitation against its instances.

The Bigger Security Picture

The most important takeaway from this disclosure is not simply that ServiceNow has three CVSS 10.0 vulnerabilities.

It is that all three vulnerabilities sit close to highly valuable trust boundaries.

CVE-2026-18885 concerns code injection through a GraphQL API.

CVE-2026-18886 concerns authorization around system configuration processing.

CVE-2026-74820 concerns SQL execution through a dynamic database query path.

Those are fundamentally different classes of vulnerability, but they converge on the same security consequence: an attacker who begins with no credentials may be able to cross boundaries that should separate an Internet request from highly privileged application or database operations.

That is why these vulnerabilities deserve immediate attention from organizations running affected ServiceNow releases.

Final Verdict

ServiceNow’s latest security disclosure represents a high-priority enterprise patching event.

Three vulnerabilities, CVE-2026-18885, CVE-2026-18886 and CVE-2026-74820, have received the maximum CVSS 4.0 score of 10.0 and are described as exploitable without authentication under certain circumstances. Their potential consequences span arbitrary code execution, unauthorized data manipulation, privilege escalation and arbitrary SQL execution.

A fourth vulnerability, CVE-2026-6876, carries a CVSS score of 8.7 and provides another sandbox-escape route to arbitrary code execution within the Now Platform.

There is currently no confirmed evidence that the three newly disclosed CVSS 10.0 vulnerabilities are being exploited in the wild, and no public exploit code was identified in the reporting reviewed for this article.

That should not reduce the urgency of remediation.

Organizations running self-hosted or partner-managed ServiceNow environments should identify affected instances, apply the relevant patches, verify remediation and review security telemetry for suspicious activity.

The lesson from the earlier CVE-2026-6875 episode is particularly relevant: once technical details surrounding a high-impact ServiceNow vulnerability become public, the window between disclosure and attacker interest can be extremely short. Searchlight Cyber’s research also demonstrates why ServiceNow compromises can have consequences beyond the platform itself when privileged integrations and MID Servers are involved.

For defenders, the safest approach is therefore straightforward: do not wait for a public exploit or an exploitation alert. Patch the vulnerable ServiceNow instance now.

This post first appeared at - The CyberSec Guru