Your ServiceNow Platform Is an Authority Map

A request arrives at a ServiceNow instance without a username or password. Under the conditions described in three disclosures published on 27 August 2026, that request could reach code execution, change instance data to gain more privilege, or send commands to the underlying database. Nobody needs to click a link. The caller does not need an existing account.

ServiceNow gave each of those flaws the maximum CVSS 4.0 score of 10.0. It says hosted instances received a security update, while partners and customers running their own instances received fixes they must apply. The company also says it was not aware of malicious exploitation of the four flaws in the August advisory when the records were published (ServiceNow’s August advisory).

Patch status is the urgent question. It is not the last one.

ServiceNow often sits between employees and the systems that make work happen. It can open accounts, route approvals, update asset records, start automation, assign incidents, expose knowledge, and call other services. The exact reach differs in every deployment. That makes the platform more than a web application with a vulnerable endpoint. It is an authority map written in workflows, service identities, connection aliases, integration accounts, and approval rules.

The practical response has two tracks. First, establish whether every instance is hosted or self-managed, compare it with the vendor’s fixed versions, reduce unnecessary public access, and collect evidence from the vulnerable period. Then map what each affected instance could cause elsewhere. A clean patch report answers what code will run next. It cannot answer what an intruder might have done yesterday.

What ServiceNow disclosed on 27 August

The August notice covers four vulnerabilities in the ServiceNow AI Platform and Now Platform. Three received maximum scores. The fourth received an 8.7 score. The labels matter less than the paths they describe, but separating them prevents the common mistake of treating one vendor bulletin as one technical fault.

CVE-2026-18885 is a code-injection flaw in the GraphQL Composite Data API. ServiceNow says an unauthenticated user could, in certain circumstances, execute arbitrary code and gain access to or modify instance data. CVE-2026-18886 is an access-control failure in the system-configuration image-upload processor. It could let an unauthenticated user create or change data beyond the intended boundary, leading to privilege escalation. CVE-2026-74820 is a SQL-injection flaw in a dynamic schema ordering path. It could let an unauthenticated user execute SQL statements against the instance database and read or change data outside the intended scope (ServiceNow’s August advisory).

The fourth issue, CVE-2026-6876, is a sandbox escape in the Now Platform. ServiceNow describes possible code execution under certain conditions and rates it high rather than critical. The public wording and scoring vector appear to disagree about whether a low-privilege account is required. The Hacker News called out that discrepancy on 28 August, so teams should use ServiceNow’s current record for operational decisions and avoid inventing certainty where the public data does not provide it (The Hacker News analysis).

For the three maximum-score issues, the vendor’s vector describes network access, low attack complexity, no privileges, no user action, and high impact across confidentiality, integrity, and availability. That is a statement about the vendor’s assessment of a successful attack, not proof that every internet-facing instance is already compromised. As of 28 August, The Hacker News found no public exploit code for the three new critical flaws, and ServiceNow’s records said the company knew of no malicious exploitation.

Both halves belong in the response. There is no public basis for telling every customer that attackers are inside. There is also no sensible basis for delaying a fix to a pre-authentication path because exploitation has not been publicly confirmed. Exposure plus consequence sets the priority. A public victim count is not a prerequisite for containment.

The affected-version table spans the Xanadu, Yokohama, Zurich, and Australia release families, with different patch and hot-fix floors. That detail defeats casual inventory. “We run Zurich” does not establish safety. One Zurich patch line can require a different hot fix from another, and a development clone can sit on a different family from production. ServiceNow’s table is the source to compare against because secondary summaries can lose the branch distinctions (ServiceNow’s affected-version table).

ServiceNow says it deployed the update to hosted instances and supplied it to partners and self-hosted customers. BleepingComputer independently reported the same division of responsibility and urged self-hosted customers to secure their instances (BleepingComputer’s report). “Hosted” still deserves verification through the customer’s support and change records. “Self-hosted” demands a deployment. Neither word should become a substitute for evidence tied to a named instance.

Why a workflow platform carries unusual consequences

A conventional application usually has a recognisable job. A shop takes orders. A document service stores files. A monitoring console collects events. ServiceNow can become the connective tissue among all three, plus identity, support, human resources, security operations, procurement, and custom applications.

That flexibility is the product. It is also why a flaw in the platform can have a wider blast radius than the database row mentioned in a vulnerability description.

Imagine an employee onboarding flow. A request enters the platform, an approval rule evaluates it, an automation creates an identity, a second integration adds group membership, and a third creates a laptop order. Each step looks like ordinary business logic. Together they describe a route from one input record to an account, permissions, and physical equipment.

The dangerous property is not “AI” in the product name. The same authority problem exists in any workflow engine. Data enters through forms, APIs, email, imports, or connected systems. Rules interpret that data. Service identities carry the result into systems that trust the platform. If an attacker can create or modify the right record, call the right API, or run code under the platform’s authority, the workflow can turn a small input into a consequential effect.

That effect may remain inside ServiceNow. A malicious change could alter an incident, reveal a record, create an administrator, or damage configuration. It may also cross outward. A connection can call a cloud API, a directory, a ticketing partner, a development tool, a messaging service, or a custom endpoint. The public advisory does not say that every customer has those connections or that the new flaws were used to reach them. Your configuration decides which possibilities are real.

This is why a generic “critical business application” label is not enough for incident planning. The response team needs an authority map. For each instance, it should show which identities the platform holds or invokes, which destinations it can reach, which records trigger effects, and which effects require a human decision. The map can start as a table. Perfection can wait; ownership cannot.

A useful first row might read: production instance, employee lifecycle application, directory provisioning connection, service account name, groups it can assign, outbound destination, approval owner, log location, credential rotation owner. A second row might cover security incident automation. A third might cover a custom integration built years ago and maintained by nobody obvious. Those forgotten rows are where platform incidents become organisational incidents.

The map also corrects an unhelpful question: “Does ServiceNow have access to Active Directory?” Access is rarely binary. One integration may read users. Another may create accounts but not assign privileged groups. A third may hold a credential whose directory permissions have grown over time. Name the action. A narrow verb such as read, create, disable, approve, deploy, or rotate gives the response team something it can test.

The three paths break different boundaries

Code injection, improper access control, and SQL injection can sound like three names for “bad input.” Their defensive meanings differ. Each breaks a boundary at a different layer, and each leaves different questions after the software is fixed.

The GraphQL issue concerns a programmable API used to request or combine data. In a safe design, user-controlled fields remain data and the server executes only intended operations. A code-injection fault means some part of that input can cross into instructions the server runs. ServiceNow’s public record says the result could include arbitrary code execution and access to or modification of instance data (Rapid7’s CVE-2026-18885 record).

Plain English helps here: the platform should read a request card, but under the vulnerable condition it could treat part of the card as a command. The patch must stop that conversion. The investigation must ask what identity executed the command, what files or platform APIs that identity could reach, and where execution evidence would appear.

The image-upload processor issue breaks an authorisation boundary. Upload handling should accept a file only within the caller’s allowed context, then store or process it under tightly defined rules. ServiceNow says the flaw could let somebody without an account create or modify instance data, resulting in privilege escalation (Rapid7’s CVE-2026-18886 record).

The word “image” can make that route sound cosmetic. It is not. The security question is what the processor could change, not what file extension appears at the front door. If the affected handler can influence system configuration or privileged records, a seemingly narrow upload route can cross into authority.

The SQL issue breaks the boundary between query data and query structure. Ordering results by a permitted column is normal. Allowing a caller’s value to alter the database instruction is not. ServiceNow says the vulnerable dynamic schema ORDER BY path could let an unauthenticated user run SQL statements against the instance’s underlying database (ServiceNow’s CVE-2026-74820 record in the August advisory).

The practical consequence is not limited to stolen rows. Database changes can alter workflow state, permissions, configuration, audit data, or the records that later trigger automation. A malicious record can be both an immediate integrity problem and an instruction waiting for another trusted component to read it.

The sandbox escape is a fourth boundary. A sandbox allows customers or platform features to run code while limiting what that code can touch. An escape means code can cross beyond the intended enclosure. Public reporting notes an inconsistency in the prerequisites, so do not build a detection rule around an assumed anonymous route until ServiceNow clarifies it. The safer response is to fix the listed version and review code-execution evidence across both authenticated and unauthenticated paths.

These mechanisms converge on one operating rule: treat the instance as a control plane. If code, configuration, and records can each cause work elsewhere, integrity is as important as confidentiality. A responder who searches only for exported data can miss a changed approval, a new privileged account, a modified connection, or a workflow designed to act later.

Hosted updates and self-hosted patches need different proof

ServiceNow’s notice draws a clear line. The vendor deployed updates to hosted instances. Partners and self-hosted customers received updates to apply. That line changes who performs the work, but it does not remove the customer’s need to know which instance is on which side.

Large organisations often have more ServiceNow estates than their central platform team expects. A production service may be vendor-hosted while an acquired company retains a self-managed environment. Development and demonstration systems can belong to a partner. A temporary clone can survive a migration. An integration test instance may use real credentials even when its data has been scrubbed.

Start with names, not assumptions. Enumerate production, non-production, disaster-recovery, partner-managed, training, and retired-but-reachable instances. Record the public hostname, release family, patch and hot-fix level, hosting model, business owner, technical owner, and support entitlement. Compare every row with the vendor’s August table.

For a hosted instance, collect the vendor change or support evidence that identifies the instance and confirms the relevant security update. Then verify the version shown by the platform through an approved administrative method. If the customer cannot see a definitive build, open a support case and keep the case number in the incident record. A corporate status page that says “ServiceNow is managed by the vendor” is too broad.

For a self-hosted or partner-managed instance, the team needs package, deployment, restart, and running-state evidence. Record the selected fix, where it came from, its integrity check where ServiceNow provides one, the maintenance time, the nodes changed, and the version each node reports after restart. A successful automation job is evidence that a command ran. It is not proof that every request-serving node now runs fixed code.

Distributed systems create ordinary failure modes. One node can remain outside the deployment group. A load balancer can return an old server to service. A golden image can still contain a vulnerable build. A restored backup can bring back old application files. A development clone can remain public because the production change ticket did not name it.

Reachability needs its own proof. These flaws are described as network-reachable, so reducing unnecessary exposure is a useful control while patch status is being established. Check public DNS, load balancers, web application firewalls, reverse proxies, alternate hostnames, and partner routes. Test from an untrusted network under your organisation’s rules. Do not rely on the instance list alone, because an old hostname may still point to a live listener.

Restricting access is a risk-reduction step, not a replacement for the patch. Internal users, partner networks, compromised endpoints, and allowed proxies can still reach an internal service. Keep the distinction explicit in the change record: network control limits who can try the path; fixed software removes the known path.

After the update, test ordinary workflows with benign inputs. Confirm users can sign in, approvals land with the right people, integrations connect, scheduled jobs run, outbound logging continues, and security monitoring still receives events. Emergency patching can break business functions. A team that never tests them may quietly disable the very approval or audit control it expected to contain the platform.

Patch first, then investigate the earlier window

ServiceNow said it was not aware of malicious exploitation of these four August flaws when it published the records. The three critical issues did not have public exploit code in The Hacker News’s review on 28 August. Those facts should keep the response proportionate. They should not turn a vulnerable period into a blank space.

The purpose of an exposure review is to answer a bounded question: did this instance receive suspicious requests or show unauthorised effects while it ran affected code? That is different from declaring a breach. It is also different from scanning one application log for a public indicator and calling the system clean.

Begin by defining the window. The end is the time each node received the fix and unnecessary public access was restricted. The start depends on the instance’s history, the vulnerable code’s installation date, available retention, and guidance from ServiceNow. Record why the team chose it. If a proxy retains fourteen days and an audit store retains ninety, say which part of the window each source covers.

Preserve records before routine work changes them. Application access logs, platform audit history, system logs, web application firewall events, reverse-proxy records, database audit events where available, identity-provider events, endpoint telemetry for self-hosted nodes, and outbound network records can each answer a different question. Export them through approved methods and note their time zones.

Search by behaviour as well as by indicator. Look for unusual unauthenticated requests to the affected API and upload paths, unexpected code or script execution, new or modified privileged users, changes to system properties, unfamiliar connection definitions, disabled logging, database activity outside normal application patterns, and workflow edits without a matching change. Exact fields and table names belong in ServiceNow’s customer guidance and your environment’s detection content. Do not guess a universal signature from a short public advisory.

Custom applications complicate the baseline. A service account may update hundreds of records during a normal import. A release team may legitimately change workflows at night. Compare suspicious events with deployment records, integration schedules, administrator activity, and known automation. The goal is to explain each unusual event with independent evidence, not to treat every anomaly as guilty.

Integrity checks should extend beyond the instance. If ServiceNow can create users, compare directory events with approved requests. If it can open cloud resources, compare cloud audit logs. If it can update development systems, review those destination logs. The connected service may preserve the effect even when the originating platform record changed later.

Credential review follows the authority map. Identify passwords, tokens, certificates, connection aliases, and delegated identities available to the instance. Determine their actual permissions and whether a successful platform compromise could read or invoke them. Rotate credentials when evidence, vendor guidance, or your incident process warrants it. Avoid a blind rotation wave that breaks recovery and hides which identity was used.

A patch changes future execution. It does not revoke a copied secret, remove an unauthorised account, reverse a database change, or restore a modified workflow. That is why patching and incident clearance require separate owners and separate completion criteria.

Build the authority map while the facts are fresh

Most teams will not have a complete diagram of every ServiceNow effect on Saturday afternoon. They can still build a useful map in hours by following the platform’s places of authority rather than documenting every screen.

Start with identities. List local administrators, delegated administrative groups, service accounts, OAuth clients, certificates, connection credentials, and integration users. For each one, capture the owner, purpose, permissions, expiry or rotation date, and where its activity is logged. Unknown ownership is a finding, not a reason to omit the row.

Next, list outward connections. Include integration hubs, custom REST or SOAP calls, directory services, cloud providers, email, messaging, development platforms, security tools, human-resources systems, procurement, and databases. Record the destination and allowed action in plain verbs. “Cloud integration” tells a responder very little. “Can create and disable user accounts in tenant X” sets a boundary.

Then identify triggers. Which forms, imported records, API calls, email messages, scheduled jobs, or approvals can start each effect? A strong control requires more than a trusted destination. It needs a trusted route from input to action. A workflow that accepts public input and later calls a privileged connector deserves more scrutiny than a read-only dashboard.

Human approval also needs precise meaning. Does the approver see the final target and action, or only a friendly request title? Can a record change after approval but before execution? Can one administrator both edit the workflow and approve its run? Does an emergency route bypass normal separation? Approval is useful only when the decision covers what the system will actually do.

Logging completes the first version of the map. For every consequential action, name the record that proves who or what requested it, which rule approved it, which identity executed it, what destination received it, and whether it succeeded. Prefer a copy outside the same administrative boundary. If platform administrators can rewrite the only record of platform administration, the audit story has a single point of failure.

This exercise tends to find dormant authority. A retired integration still has a valid token. A development instance can call production. A custom application uses a broad administrator account because narrowing it once broke a demonstration. A certificate has no owner. These conditions would make any future platform failure more expensive, regardless of whether attackers used the August flaws.

Reduce them in a controlled order. Remove unused connections. Narrow permissions to the verbs the workflow needs. Separate development from production destinations. Put expiry dates on temporary access. Require fresh approval for high-impact actions. Send administrative and integration events to an external log store. Test revocation before the next incident.

The Secure Harness describes this pattern for coding agents: autonomy becomes usable when its inputs, permissions, tools, destinations, and records sit inside enforced boundaries. A workflow platform deserves the same treatment. It accepts instructions, chooses actions, and operates through trusted identities. A prompt is not required for the authority problem to exist.

What to do now

The immediate response should be short enough to run and specific enough to audit. Assign one owner to the platform, one to investigation, and one to connected identities if your organisation has the staff. Smaller teams can combine roles, but they should keep the outcomes separate.

1. Inventory every instance. Record production, non-production, partner-managed, self-hosted, vendor-hosted, training, recovery, and old migration environments. For each one, capture hostname, release family, exact patch and hot-fix level, hosting model, owner, and external reachability.

2. Compare exact versions with ServiceNow’s advisory. Use the vendor’s affected-version table for Xanadu, Yokohama, Zurich, and Australia. Do not infer safety from the family name alone. Save the table or support reference used for each decision because the advisory can change.

3. Confirm the fix on hosted instances. Obtain instance-specific vendor or support evidence, then verify the running version through an approved administrative method. Open a support case when the platform does not expose enough detail and retain the case number.

4. Patch self-hosted and partner-managed instances. Apply the relevant update to every node, restart as required, and verify the running build on each server. Update images, recovery packages, and automation that could recreate the old version.

5. Reduce unnecessary network reachability. Restrict public and partner access to the routes the business needs. Check DNS, proxies, load balancers, alternate hostnames, and test environments. Test the result from outside the trusted route. Keep patching as a separate requirement.

6. Preserve the vulnerable-period evidence. Export application, audit, proxy, firewall, identity, database, endpoint, and outbound-network records before retention or maintenance removes them. Write down each source’s time zone and coverage window.

7. Review high-impact changes and execution. Search for unusual unauthenticated requests, code execution, privileged-account changes, workflow edits, connection changes, disabled logging, unexpected database actions, and effects in connected systems. Reconcile findings with approved changes and normal automation.

8. Map the instance’s authority. List identities, permissions, integrations, triggers, approvals, destinations, and external logs. Use plain action verbs. Prioritise routes that can create accounts, grant access, alter security controls, move money, deploy code, or change production systems.

9. Respond to evidence, not anxiety. If the review finds credible signs of compromise, activate the incident process, isolate where appropriate, preserve evidence, involve ServiceNow, revoke exposed identities, and validate connected systems. If it finds no signs, document the searched sources and their limits rather than claiming certainty.

10. Test the repaired platform. Exercise sign-in, approvals, integrations, scheduled work, logging, and recovery with benign cases. Confirm security events still leave the platform. A fixed version with a broken audit route is an incomplete recovery.

The sequence deliberately joins software state with organisational authority. Stopping at step four can leave an old node, a stale recovery image, an unexplained workflow change, or a broadly privileged connector outside the response.

A patch closes the path, a boundary limits the consequence

Three maximum-score vulnerabilities in one advisory make an easy headline. The more useful fact is quieter: an enterprise workflow platform can turn records and API calls into actions across the organisation. Its security boundary includes every identity and destination that trusts it.

ServiceNow’s 27 August update deserves prompt attention. Hosted customers should verify the vendor-applied state for every instance. Self-hosted and partner-managed customers should apply the supplied fixes and prove every node is running them. Teams should also preserve enough evidence to examine the period before the fix, without telling employees or customers that exploitation occurred when the public record does not establish it.

The lasting control is an authority map kept close to the platform. It names what can enter, what can run, which identity carries the action, where that action can go, who approves it, and which independent record proves the result. When a new flaw appears, the response team can answer consequence with evidence instead of imagination.

That map will never be finished. New workflows arrive, old connections linger, permissions drift, and ownership changes. Review it with major releases and integration changes. Give temporary authority an expiry. Keep high-impact actions narrow. Put administrative evidence somewhere the same platform cannot quietly erase.

ServiceNow fixed the known paths. Your boundaries decide how much any future path can reach.

For one practical email each month on making security work in ordinary systems, join the newsletter on Cyber Security in Plain English.

Sources

• ServiceNow: August 2026 CVE Advisory Notification, accessed 2026-08-29.
• The Hacker News: Three CVSS 10.0 ServiceNow Flaws Could Let Unauthenticated Attackers Execute Code and SQL, accessed 2026-08-29.
• BleepingComputer: ServiceNow Warns of Three Max-Severity Security Vulnerabilities, accessed 2026-08-29.
• Rapid7: CVE-2026-18885, ServiceNow AI Platform Code Injection, accessed 2026-08-29.
• Rapid7: CVE-2026-18886, ServiceNow AI Platform Improper Access Control, accessed 2026-08-29.