ServiceNow SN-INCIDENT-2026-06-KB3067321

A ServiceNow security incident with no CVE assigned. ServiceNow published a public TrustShare customer advisory and a more detailed login-gated bulletin (KB3067321, reachable only from the support portal), and applied a cloud-side fix to hosted instances on 2026-06-05 (publicly disclosed 2026-06-09). ServiceNow confirms the access was unauthenticated ("without requiring credentials") and scopes the advisory to the Australia release family; its investigation reports the observed activity began 2026-06-02. Community analysis (attributed by the press to "one commenter") adds the specific Scripted REST Resource at the related-list-edit endpoint and the requires_authentication=false root cause. Because the requests were unauthenticated, ServiceNow had no account to attribute them to, so the activity appears in syslog_transaction logged against the built-in Guest user — the single most useful and most misunderstood detection signal, and the centerpiece of the cross-linked guide (ATTACK-007).

Why this checker exists. ServiceNow notifies affected customers by opening a support case — and says that if you did not receive one, you are likely not affected. That is a "trust us, we'll contact you" model: the public advisory tells you the incident happened, the detailed KB is behind a support login, there is no CVE, and there is no self-service way to check your own instance. This checker lets a team verify independently, from its own logs, rather than rely on the absence of a support case.

Exposure window. ServiceNow's investigation reports activity beginning 2026-06-02, before the 2026-06-05 fix; one community report suggests possible earlier (~April 2026) activity. The signature's disclosed field is set to 2026-04-01 as a deliberately conservative window-open: an all-clear (DORMANT) then requires your logs to cover a wide window, and because most instances' transaction-log retention does not reach back that far, the common result is an honest INVESTIGATE (a retention gap that is itself reportable), never a false all-clear. The setting only ever narrows toward INVESTIGATE — it can never manufacture a false EXERCISED. Because the fix was applied cloud-side, there is no customer upgrade and no version to patch to — the action is to review your logs.

This signature carries detection signals only. It contains nothing about how the endpoint was called, and no request body, payload, or reproduction detail — the activity was unattributed at disclosure, and on 2026-06-12 ServiceNow attributed much of it, hedged, to security researchers and customers' own testing. A signal hit means the endpoint was reached/queried in the instance's logs; it does not, by itself, identify the actor or confirm a breach.