Tesla's attack-surface scanner is hurling exploits at random NTP volunteers

A hobbyist server operator running a volunteer node in the NTP Pool (pool.ntp.org) discovered his machine was absorbing a steady stream of exploit attempts—Log4Shell, SSRF, path traversal, webshell uploads, and CMS probes—all tagged with the hostname pool-ntp.tesla.com and Assetnote user agents. The traffic traced back to three AWS-hosted scanners belonging to Assetnote (now marketed as Searchlight Cyber), Tesla’s continuous attack-surface management vendor. Since August 21 his server alone logged over 50,000 requests, and at least one other pool operator reported the same behavior.

The root cause is a DNS misconfiguration. Tesla publishes pool-ntp.tesla.com as a CNAME pointing to pool.ntp.org, a round-robin of thousands of community-run NTP servers that Tesla does not own. Assetnote’s asset discovery apparently enumerated everything under tesla.com, followed that CNAME, and treated every IP the record could resolve to as in-scope—so it began actively scanning strangers’ infrastructure. The scanner also fired templated payloads referencing unrelated third-party domains and internal RFC 1918 addresses baked into its detection templates, and blindly spoke HTTP to non-web ports like SSH and mail.

The operator’s attempts to stop it went nowhere: an email to Tesla’s vulnerability reporting address drew no reply, and serving a custom HTTP 299 notice on every path (“This is not Tesla infrastructure”) did nothing to change the scanner’s behavior. The episode is a clean illustration of how automated attack-surface tooling can go badly out of bounds when it trusts DNS resolution for scope, and it underscores why organizations should point such subdomains at vendor-specific zones rather than CNAMEing straight into shared public infrastructure.