Were you hit by the June 2026 ServiceNow incident?

Update (June 12, 2026): ServiceNow now attributes the observed activity — hedged — to security researchers or customers conducting their own security research, not malicious actors; the researchers told ServiceNow it was solely for a bug-bounty submission and that no data was used or retained. That attribution is platform-wide and hedged, not a per-instance all-clear — so whether your instance was reached, and by whom, is still worth confirming from your own logs. That is what this checker does.

The fix was applied cloud-side — there is no version to upgrade to. Hosted instances are already patched. The only remaining question is forensic: was your instance reached before the fix? Most teams cannot answer it from memory, because the activity hides in plain sight (see below).

Why the attacker shows up as “Guest”

Because the endpoint accepted requests with no session, ServiceNow had no authenticated account to attribute them to — so it logs them against the built-in Guest user in syslog_transaction. A Guest-attributed transaction to an authenticated-only API endpoint is the primary indicator that an unauthenticated actor reached it. Many teams misread this as benign internal traffic. It is not.

The catch: transaction-log retention is usually only days to weeks, so an empty result does not clear you if your logs do not reach back to ~April 2026. That gap is itself a finding — and the verdict below names it.

1 · Run the read-only check on your instance free · no login · no instance access

In ServiceNow: System Definition → Scripts - Background. The script only reads syslog_transaction and prints an envelope — it cannot call or exploit the endpoint.

2 · Paste the output verdict computed in your browser · logs never leave your tenant