CVE-2025-12420: Critical ServiceNow AI Platform Flaw Enables Unauthenticated User Impersonation

CVE-2025-12420 — ServiceNow AI Platform Impersonation

Severity: Critical
CVSS: 10.0 (Highest severity)
Impact: Full impersonation of any user without authentication
Exploitability: High – can be triggered remotely via HTTP requests
Public exploit status: No confirmed public exploit code at time of writing

What this vulnerability really is

CVE-2025-12420 is a security flaw in the ServiceNow AI Platform where the system fails to properly verify that a request actually came from a legitimate authenticated user. In simple terms:

The AI Platform allowed requests to be processed as if they were from another user — including high-privilege users — even when the attacker had not logged in at all.
This means an attacker could trick the platform into thinking “this request is from User X” without ever providing valid authentication.
Because ServiceNow uses roles and permissions tied to user accounts, once the attacker impersonates a real user, they automatically inherit that account’s privileges.
If the targeted user has admin rights or broad access to data, the attacker suddenly has that level of access too.

This is not just a data leak – it is unauthenticated impersonation, which is one of the most serious classes of vulnerabilities.

How an attacker might exploit it

An attacker would interact with the ServiceNow AI Platform’s public HTTP APIs. These APIs accept requests over the network. Because of the flaw, the server does not check or enforce authentication properly for some operations. An attacker could:

Send carefully crafted HTTP requests to endpoints used by the AI Platform.
Include payloads or headers that instruct the system to treat the request as if it came from a specific user.
The platform processes those requests as if that user performed them — even without a valid session.
The attacker can then read, modify, delete records, run workflows, or invoke actions that the impersonated user is allowed to do.

The key issue is authorization and identity verification broken at the API layer. The platform mistakenly identifies the attacker as a valid user.

What could be done with a successful exploit

Depending on the privileges of the impersonated account, the attacker could:

Read sensitive corporate or personal data stored in the instance.
Modify records (change fields, remove audit trails, alter workflow logic).
Trigger workflows, business rules, integrations, exports.
Create or delete users and roles.
Potentially disable security controls or cover tracks.
Use the instance as a bridgehead to pivot into other systems connected via integrations.

If a privileged account is targeted (such as admin or service account), the impact could be complete control over the ServiceNow tenant.

Is a PoC or exploit publicly available?

At this time there is no widely circulated public PoC exploit script. That does not mean the flaw is not severe — vulnerabilities of this class are high risk even without published exploits. Threat actors often reverse engineer patches or behavioural changes to create exploits once a patch is released.

How to detect exploitation or attempted exploitation

Because the core issue is unauthenticated requests acting with authenticated privileges, detection focuses on identifying requests that perform actions normally requiring authentication but lack valid authentication signals.

Key detection signals

1. Actions from high-privilege accounts with no corresponding login

If logs show a “User Admin” performing changes, but there is no authenticated session activity from that user preceding those actions, that is suspicious.

Example patterns:

User X updated or deleted records
No successful login event recorded for User X around that time
No valid authentication token was used

2. HTTP requests with missing or malformed authentication headers

Typical HTTP traffic to ServiceNow should include valid session IDs, tokens, or SSO assertions. Requests that successfully trigger actions without these should be flagged.

Look for:

Requests to /api/ or AI endpoints
Authorization headers that are empty, missing, or malformed
Requests returning 2xx success codes

3. Unusual request patterns from external IPs

Requests from public/external IPs to internal admin APIs where normally only authenticated internal users would be expected.

Logs to collect and monitor

Collect logs from the following sources:

ServiceNow system logs
- Audit logs
- User activity logs
- API request logs
- Authentication and session logs
Web server and API access logs
- Reverse proxy
- Load balancer
- WAF logs
SIEM logs
- Correlated events showing absence of authentication followed by privileged actions

Key fields to capture:

Timestamp
Client IP
User account (if present)
URI and HTTP method
Authorization header content
Session ID or absence of session
Response codes

Detection rule examples

You can adapt these to your monitoring stack:

SIEM-style logic

Trigger when an API request returns success but no prior login exists:

if (action_success AND user_role_high_privilege AND no_authentication_event_in_last_5_min)
then flag as possible exploit

Requests without Authorization header but successful privileged write:

if (http.response_code == 200
    AND (uri_path contains "/api/ai" OR uri_path contains "/ai")
    AND Authorization header is null or empty
    AND action is write/update/delete)
then alert

Multiple high-privilege actions from the same IP without login:

group by client_ip
where count(privileged_actions_without_auth) > 3 in 10 minutes
then alert

What a malicious payload might look like

There is no public exploit payload, but based on the vulnerability behavior, malicious requests might:

Target AI or API endpoints
Omit valid session cookies
Omit valid OAuth/SSO tokens
Include suspicious user identifiers in headers or body fields that attempt to force impersonation
Return success status while performing privileged actions

For example:

POST /api/ai/performAction
Host: servicenow.company.com
User-Agent: Mozilla/5.0
Content-Type: application/json

{
    "user": "[email protected]",
    "action": "updateRecord",
    "recordId": "INC123456",
    "fields": { "state": "closed" }
}

Such a request should normally be rejected if the attacker is not authenticated. If it succeeds without proper authentication, it indicates exploitation of this vulnerability.

How to respond and mitigate

Apply the official patch immediately.
- The single most important action is to update your ServiceNow instance using the advisory link:
  https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2587329
- Patching fixes the authentication/authorization logic so attacks can no longer impersonate users.
Block access to vulnerable endpoints until patched
- Use a web application firewall to block requests missing valid auth headers
- Restrict AI Platform endpoints to internal or trusted IP ranges
Rotate credentials and invalidate sessions
- After patching, force logout all sessions
- Rotate API keys/service account credentials
Review logs for suspicious activity
- Look back through logs from before and after the patch to identify any unusual accesses
- Hunt for actions performed without corresponding login
Harden your policies
- Enforce multi-factor authentication everywhere possible
- Implement least privilege roles
- Ensure audit logging is enabled and retained

Official patch/upgrade:
ServiceNow Security Advisory — apply updates via the ServiceNow Support Portal:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2587329

Final Takeaway

This vulnerability allowed someone on the internet to send crafted traffic to your ServiceNow AI APIs and convince the platform to act as if they were a real user — even without logging in. That means data reads, updates, deletes, workflow triggers — anything that user was allowed to do.

The fix is available now and should be applied immediately. After patching, you need to look through logs to make sure no unauthorized actions took place and tighten your logging and monitoring so that future anomalies are caught early.