Most agent security findings are about an agent doing something foolish with the access it was given. CVE-2025-12420 is about the agent never being the problem at all. AppOmni found that ServiceNow shipped the same integration secret to every instance on the planet, and that the linking step behind it accepted an email address as proof of identity. What sat at the end of that was Now Assist, with the agentic workflows of whichever user you claimed to be.
TL;DR
- AppOmni disclosed BodySnatcher on 13 January 2026. Tracked as CVE-2025-12420, CVSS 4.0 base 9.3 critical per the ServiceNow CVE record.
- The Virtual Agent API used an integration token, servicenowexternalagent, that was the same value on every ServiceNow instance.
- The Basic account linking method bound an external caller to a ServiceNow user on an email address alone, with no MFA and no SSO in the way.
- With both, an unauthenticated caller could impersonate any user and drive privileged Now Assist agentic workflows as them. AppOmni’s proof of concept created administrator accounts.
- ServiceNow remediated hosted instances at the end of October 2025. Self-hosted customers had to patch.
#What AppOmni documented
The finding has two halves, and neither is interesting alone.
The first is an endpoint, /api/sn_va_as_service/bot/integration, that exists so external chatbots can talk to ServiceNow’s Virtual Agent. It is reachable over the network. It authenticates its caller with a shared secret. So far this is an ordinary integration design, the kind that sits in thousands of products.
The second is that the secret, per AppOmni, was configured with the exact same value across all ServiceNow instances. Not per customer. Not per instance. One value, shipped everywhere.
And behind it, the Basic account-linking method “required only the email address to link an external entity to a ServiceNow account”. No second factor, no SSO assertion, no verification that the caller had anything to do with that mailbox.
#The access path, step by step
# as published by AppOmni, 13 January 2026 Virtual Agent API # reachable over the network, no authentication needed first → shared secret # servicenowexternalagent, identical on every instance → email-only linking# an email address is enough to be that user, no MFA, no SSO → Now Assist agents # privileged agentic workflows, driven as the impersonated user → admin accounts # the published proof of concept created admins and assigned roles
Four steps, and the only input an attacker needs to supply is somebody’s work email address.
#A secret that is not a credential
The useful way to read this is to ask what the shared secret actually proved.
A credential is supposed to answer “who is this”. A value that ships identically to every customer answers a different question: “is this the integration”. And the answer is always yes, for everyone, forever, because nobody can change it. One customer rotating it would break the product.
| What it looked like | What it was |
|---|---|
| An authentication secret on the endpoint | A constant, the same for every tenant |
| Account linking | An email address, accepted as identity |
| MFA and SSO on the tenant | Configured, and not on this path |
| Now Assist permissions | Correct, and applied to the wrong person |
That last row is the one worth sitting with. Nothing about the agent misbehaved. Now Assist ran the workflows it was allowed to run, with the permissions of the user it believed it was serving. Every authorisation decision downstream was correct. The authentication upstream was a constant.
#Why agentic workflows raise the stakes
Impersonation bugs are not new, and a bug that lets you act as another user would be serious in any product. What Now Assist adds is that the thing you are now driving is built to do things rather than show them.
An impersonated session in a classic ticketing interface reads records and files tickets. An impersonated session in front of an agentic workflow engine executes the workflows that engine is allowed to execute, which per AppOmni’s proof of concept extended to creating administrator accounts and assigning privileged roles. The difference is not the authentication bug. It is the length of the lever on the other side of it.
This is the same shape as the agent-to-agent recruitment finding AppOmni published two months earlier: agents inherit the privileges of whoever triggered them, so the question for an attacker is never “what can the agent do” but “whose identity can I put in front of it”.
#What to check this week
- Inventory the integration secrets you did not generate. Any shared value that arrived with a product rather than being issued to you is a constant, not a credential. List them before you judge them.
- For each agent platform, write down what authenticates the caller and what authorises the action. If the answer to the first is weaker than the answer to the second, the second does not matter.
- Check every account-linking or just-in-time provisioning flow for what it accepts as proof. An email address is an identifier, not an assertion.
- Ask whether your MFA and SSO sit on the path an integration takes, or only on the path a browser takes. In this case they were configured and bypassed, not missing.
- If you self-host ServiceNow, confirm you are past Now Assist AI Agents 5.1.18 or 5.2.19 and Virtual Agent API 3.15.2 or 4.0.4, per AppOmni’s published ranges. Hosted instances were remediated in October 2025.
On Elmoz
#FAQ
What is BodySnatcher, CVE-2025-12420?
A vulnerability AppOmni disclosed on 13 January 2026 in ServiceNow’s Virtual Agent API and Now Assist AI Agents. A hardcoded integration secret identical across all ServiceNow instances, combined with account linking that required only an email address, let an unauthenticated attacker impersonate any user and run privileged agentic workflows as that user. The ServiceNow CVE record gives a CVSS 4.0 base score of 9.3.
Did MFA or SSO stop it?
No. Per AppOmni the Basic linking method required only the email address to link an external entity to a ServiceNow account, and MFA and SSO were not enforced on that path. Both can be correctly configured on a tenant and still not sit between the attacker and the impersonation.
Was it exploited?
No source we could open reports exploitation in the wild. AppOmni reported it to ServiceNow on 23 October 2025; ServiceNow remediated hosted instances and published a knowledge base article by 30 October 2025. The CVE record lists exploit maturity as proof of concept.
What should a security team take from it?
That an agent platform inherits whatever the authentication in front of it is worth. The Now Assist permission model behaved correctly throughout; it was applied to the wrong person. Reviewing what authenticates a caller to an agent platform is a different exercise from reviewing what the agent is allowed to do, and the first one bounds the second.
An agent platform is only as trustworthy as the identity in front of it. Elmoz inventories AI agents and the machine identities behind them, including the integration secrets nobody issued, and shows where a path ends.