Now more than ever, it’s important to protect your sensitive customer data from security weaknesses in your vendor’s AI software. SendSafely Halo for ServiceNow encrypts the sensitive files customers share with your Virtual Agent in the browser and keeps them outside ServiceNow, so they are not sitting in your instance when the next platform vulnerability lands.
On August 27th, ServiceNow disclosed and patched three maximum-severity vulnerabilities in the ServiceNow AI Platform. CVE-2026-18885 is a code injection flaw that lets an attacker run arbitrary code. CVE-2026-18886 lets an unauthenticated attacker create or modify instance data and escalate privileges. CVE-2026-74820 is SQL injection against the instance's underlying database, which means reading or modifying records directly. All three can be exploited by an unauthenticated attacker in a low-complexity attack with no user interaction, which is about as bad as a vulnerability description gets. ServiceNow also patched a sandbox escape, CVE-2026-6876, that allows arbitrary code execution within the platform and was upgraded from high to critical severity on September 1.
ServiceNow said it patched its cloud-based platform against the three critical security flaws and advised customers to secure their self-hosted instances. BleepingComputer has the full release table. ServiceNow says it isn't currently aware of malicious exploitation against customer instances, and there's no particular reason to doubt that.
So this is a good week. Patch and move on. But it's worth understanding what you're actually protecting against, because the last pre-auth flaw in this platform was reportedly being exploited within weeks of disclosure, and we wrote about it in July.
The Attack Paths Don't Depend on a CVE
MDSec published a write-up this month covering two years of ServiceNow red team engagements, and it's the clearest public picture available of what a compromised instance actually means. Almost none of what they did required a vulnerability at all.
Their team identified at least 24 distinct roles that can be escalated to full admin, several of which get handed out as a matter of routine. Across three engagements, more than 10,000 users held sn_cmdb_editor, spread across HR, finance, legal, IT and outside contractors, and that role by itself was a workable path to owning the instance. For persistence they modified an existing business rule so a backdoor admin account quietly rebuilds itself every day, with no audit trail linking the rule to the account it creates. Credentials came out in volume: Windows discovery credentials, SSH keys, GitLab API keys, and CyberArk safes reachable through the instance's own integrations. MID servers were used to run commands against on-premises systems and pivot into SCCM.
Then there's what was sitting in the attachment tables. The red team pulled two years of prior security assessment reports out of sys_attachment. The incident tables showed them which alerts the SOC had already dismissed as false positives.
MDSec's read on defensive coverage is worth quoting directly: detection and response inside ServiceNow is "basically non-existent" even at mature organizations, and in engagements where they deliberately triggered detections, responders still couldn't identify the persistence or contain it.
Patching these three CVEs closes three doors. It does nothing about any of the above.
What's Already in Your Instance
For most of the financial services, healthcare, legal and MSP teams we work with, this is where it gets uncomfortable. Your service desk collects account numbers to verify a caller's identity. Your onboarding flow collects bank statements and government IDs. Your HR case management holds medical documentation supporting a leave request. Your legal team attaches a privileged contract to an intake ticket because the ticket is where the request lives.
None of that was a security decision. It was a series of reasonable workflow choices made by people trying to resolve someone's problem efficiently, and it's been accumulating in sys_attachment for as long as the instance has been running. Nobody ever signed off on the aggregate, it just built up.
That's your blast radius, and it's the one number in this whole situation you can still change.
Keeping Customer Data Out of the Instance
SendSafely Halo works on exactly that variable. Files and structured data are encrypted in the browser, on the submitter's device, before anything is transmitted. What the ServiceNow instance receives and stores is a reference rather than the content, and the keys are never in ServiceNow. Agents retrieve what they need through the same interface they're already using, so the record in the platform stays a pointer instead of a payload.
The workflow doesn't change. The Virtual Agent conversation, the ticket, the queue and the routing all stay where they are. What changes is what your instance is worth to somebody who owns it. An attacker running the exact playbook MDSec documented against a Halo-protected intake flow can dump the attachment table and come away with encrypted references. That's still an incident you have to work, but it’s better than a letter notifying every customer who has ever attached a document to a ticket.
The Bottom Line
Three maximum-severity flaws with no known exploitation is a good outcome and a temporary one. Patch them, then spend some time on the harder question, which is how much regulated customer data is sitting in a platform whose compromise you have no realistic ability to detect, and how much of it needed to be in there at all.
Halo for ServiceNow is available now on Enterprise plans. If you want to see what your exposure looks like with an encrypted trust layer in front of intake, email sales@sendsafely.com.
SendSafely: Encrypted File Transfer for Modern Business
If your organization needs a secure way to transfer files with customers or business partners, our platform might be right for you. Contact us today.