Tesla's Security Scanner Is Attacking a Volunteer's NTP Server

A misconfigured DNS record inside Tesla's own infrastructure has turned a security scanner Tesla pays to protect itself into an attacker in its own right, firing live exploit payloads at a stranger's home server for nearly a month. A systems administrator who runs a volunteer NTP Pool node published the writeup on their personal site, dreamstation.systems, and it surged onto Hacker News's front page in the past hour with well over a hundred points. The cause traces back to a single CNAME record Tesla never should have pointed where it did.

What is actually happening to this server?

The admin, who goes by Robin and runs NTP, web, and mail services out of dreamstation.systems, says their nginx logs show more than 50,000 requests since August 21 from three AWS-hosted IP addresses tied to Assetnote, the attack-surface-management scanner Searchlight Cyber acquired in 2025. Over a roughly two-day stretch the two most active hosts alone sent close to 8,000 requests. Among them: 989 attempts carrying Log4Shell callback strings and 114 carrying SSRF callback strings, plus a mix of path traversal probes, webshell upload attempts, and fingerprinting requests aimed at identifying whatever CMS or admin panel might be listening. None of it worked, by Robin's own account, but that was luck rather than defense.

RelatedPixel 11 Loses MTE Security Support, GrapheneOS Confirms

How does a DNS record turn into 50,000 exploit attempts?

Tesla publishes pool-ntp.tesla.com as a CNAME pointing at pool.ntp.org, the NTP Pool Project's public time-sync service. Pool.ntp.org isn't a fixed set of Tesla-owned machines. It's a round-robin DNS zone that hands out rotating IP addresses belonging to thousands of volunteers worldwide who donate spare bandwidth to keep the internet's clocks in sync, Robin's machine among them. Assetnote's asset-discovery crawler apparently resolved that hostname, saw a Tesla-owned subdomain pointing at it, and concluded every IP address it ever returns belongs to Tesla. From there its scanner did what attack-surface-management tools are built to do: probe every asset on the list for exploitable software, continuously, without a human checking whether the "asset" actually belongs to the company that hired it.

Why would a legitimate security vendor do this?

Assetnote's whole pitch, now sold under Searchlight Cyber's name, is continuous attack-surface discovery: point it at a company's domains and it maps every subdomain, every IP, every exposed service, then tests each one for known vulnerability classes around the clock. That model works when the discovery step is accurate. It breaks the moment a target company's own DNS points at shared, third-party infrastructure it doesn't control, because the scanner has no way to know the difference between "Tesla's server" and "some volunteer's server that Tesla's DNS happens to reference this hour." NTP Pool addresses rotate constantly by design, which means Assetnote wasn't just wrong once. It kept re-resolving the hostname and kept attacking whoever the pool handed it next, all under the honest belief it was defending Tesla.

Has Tesla actually responded?

Robin emailed Tesla's security team at VulnerabilityReporting@tesla.com, laying out the traffic pattern and noting, in their words, that Tesla was "throwing exploits at strangers' IPs." As of publication there had been no reply. That silence is arguably the more interesting failure here: the technical mistake is an understandable DNS oversight, but a vulnerability disclosure inbox that doesn't answer a report describing your own vendor's exploit traffic hitting an uninvolved third party is a process problem, not a configuration problem.

RelatedOpenAI's Cyber Model Answers 95% of Exploit Prompts

Is Robin's server an isolated case?

No. Another NTP Pool operator, Matt Nordhoff, confirmed on the Hacker News thread that he's seen the same pattern of Assetnote traffic since August 15, nearly a week before Robin's logs start. Commenters on the thread pointed to a near-identical 2003 incident where Netgear hardcoded a university's NTP server address into a run of consumer routers and buried that university's network in unwanted traffic for years. The specific vendor and decade change, but the underlying mistake, treating a shared public resource as if it were dedicated infrastructure, keeps recurring because DNS makes it easy to do by accident and hard to notice until someone downstream writes about it.

1. Aug 15Fellow NTP Pool operator Matt Nordhoff starts seeing Assetnote scanner traffic
2. Aug 21Robin's dreamstation.systems logs begin recording the same Assetnote IPs
3. Sept 8Robin starts answering the scanner's requests with HTTP 299 to flag the trafficno change in behavior
4. Sept 13Robin publishes the writeup and emails Tesla's security team
5. NowStory hits Hacker News's front page; Tesla has not publicly responded

Our take

This isn't a Tesla hack, and it isn't really a Tesla story at all once you look past the headline. It's a story about what happens when attack-surface-management tools, which exist specifically to reduce blind spots, get fooled by the same DNS trick that's tripped up vendors for over two decades. The fix on Tesla's side is trivial: stop pointing pool-ntp.tesla.com at a shared public pool, run dedicated NTP infrastructure or use a provider that doesn't rotate through volunteer machines, and the whole problem disappears. The fix on Assetnote's side is harder and matters more, because Tesla is not the only Searchlight Cyber customer whose DNS records might reference shared infrastructure, and every one of them is a candidate for the same mistake at a different volunteer's expense. An asset-discovery tool that can't tell a dedicated server from a round-robin pool entry is going to keep finding "Tesla assets" that were never Tesla's to begin with, and keep firing exploit payloads at whoever gets handed the short straw next.

Original analysis by GenZTech. Source: dreamstation.systems.