Your Service Desk Was Answering Strangers and Your Backups Take One Login to Own: ServiceNow's Zero-Auth API and Veeam's 9.4 Landed the Same Week.
- Patrick Duggan
- 6 minutes ago
- 4 min read
Two vulnerabilities surfaced this week that do not look related and are. One is a ServiceNow API endpoint that was answering requests from people who never logged in. The other is a Veeam Backup and Replication flaw rated 9.4 that hands remote code execution to any authenticated domain user. They sit at opposite ends of an enterprise — the service desk where work is tracked and the backup server where recovery lives — and they are the same story told twice, because those two systems are the nerve centers an attacker most wants and the two an organization can least afford to lose. Here is what each one is, and why the pairing is the point.
ServiceNow: A Door Marked "No Login Required"
ServiceNow disclosed that attackers exploited an unauthenticated-access flaw in an API endpoint to query data out of customer instances. The technical shape of it, per administrators discussing the incident and the company's own guidance, is almost insultingly simple: a REST endpoint at /api/now/related_list_edit/create was configured so that authentication was not required, which means a request did not need a valid account to reach instance data behind it. Confirmed suspicious activity traces to June 2nd and 3rd; ServiceNow applied a fix to hosted customer instances on June 5th and warned affected customers — and this is the part that should bother you — quietly, through support bulletins and direct cases rather than a loud public advisory, leaving a lot of customers unaware that a zero-authentication API on their tenant had been exploited in the wild.
The detection guidance is concrete, so act on it: review your ServiceNow logs for requests to /api/now/related_list_edit, with particular attention to the IP address 51.159.98.241, which is the address called out in the activity. The exposure concentrated on the Australia platform release and on older releases where certain configuration changes had been made, and a subset of instances were queried successfully. ServiceNow's position is that the activity was likely security researchers or bug-bounty-adjacent testing rather than a malicious actor, which may well be true — but an unauthenticated endpoint that returns instance data does not care about the intent of whoever finds it, and a gated advisory means the customers who most needed to check their logs were the last to know to look.
Veeam: One Login Away From Owning The Recovery
Veeam patched a critical flaw in Backup and Replication, tracked as CVE-2026-44963 and rated CVSS 9.4, that allows an authenticated domain user to execute code remotely on the backup server. "Authenticated domain user" sounds like a meaningful barrier and is not much of one: in a real network, an attacker who has phished a single ordinary employee or cracked one reused password is an authenticated domain user, and this flaw turns that low bar into remote code execution on the single most important box in the building for surviving a ransomware attack. The backup server is the thing that decides whether an encryption event is a bad week or a company-ending one. It is also, for exactly that reason, the first thing a competent ransomware crew goes after — you cannot refuse to pay if you cannot restore — and it is why backup infrastructure attracts critical vulnerabilities and active exploitation with grim regularity.
That regularity is worth making explicit, because Veeam Backup and Replication is a repeat name on the exploited-vulnerabilities list, not a one-time unlucky vendor. The Known Exploited Vulnerabilities catalog already carries a Veeam deserialization bug that gave unauthenticated remote code execution, two more Distribution Service flaws that let unauthenticated users reach internal API functions and upload code, and a Cloud Connect flaw that exposed stored credentials to anyone inside the backup network. CVE-2026-44963 is the newest entry in a years-long pattern, and the pattern says the same thing the ServiceNow incident says: the systems at the center of how an enterprise runs and recovers are under sustained, structural pressure, and they reward attention out of all proportion to their share of your patch queue.
Why The Two Together Are The Lesson
A service desk and a backup server do not look like front-line security infrastructure. They are plumbing — the systems that track the work and hold the safety net — and that is precisely why they are dangerous when they fail. The ServiceNow endpoint leaked instance data to people who never authenticated; the Veeam flaw hands the recovery system to anyone with a single stolen credential. Neither is a flashy nation-state zero-day; both are the kind of central, trusted, under-watched system that an attacker treats as a master key. The defender takeaway is to weight your attention toward the nerve centers rather than the perimeter alone: inventory the trusted-but-boring systems that everything else depends on, and ask of each one the two questions these bugs answer the wrong way — can someone reach it without authenticating, and does one ordinary credential turn into control of it? Patch the Veeam 9.4 now, because a backup server is the last thing you want owned the day the ransomware fires. Hunt the ServiceNow endpoint and that IP in your logs today, because a quiet advisory does not make a public, exploited, unauthenticated API any less public, exploited, or unauthenticated. The two front doors most worth checking are the ones nobody thinks of as doors.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.