Every domain collects old DNS records. A campaign site that was shut down, a test server that was never removed, a hosting account that expired. The record stays, and it keeps pointing at a server that is no longer yours. That is how subdomain takeovers happen. I added a report for this to ShadowTrackr, and I extended the webhook options so you can get the alerts in the tools you already use.
The new report lists web addresses of yours that point to a server that is not set up for them. You can run it from the search bar with $subdomain_takeover_report. It also appears in the report library under the DNS category, where you can schedule it.
Each result is one of two things:
Addresses that point to another domain of your own organisation are left out, because those are not findings. Possible takeovers are listed first. The fix is usually simple: remove the DNS record, or point the name back to a server you control.
The weekly PDF report now has a "Subdomain takeover" section too. It sits in the urgent part of the report, so you will see these findings without having to go looking for them.
An alert can call a webhook instead of sending an email. Choose Call webhook as the action and pick a payload:
You can also add up to 10 custom headers to every call, for example an Authorization header to authenticate to the receiving tool. Header values are stored encrypted and shown masked after you save.
A good combination is an alert on $subdomain_takeover_report that posts to your security channel. The same applies to any other query.
One thing to know: ShadowTrackr verifies the TLS certificate of your endpoint, and there is no option to switch that off. A self-signed certificate is refused. This matters for self-managed Splunk, which ships with a self-signed certificate. The documentation has step-by-step instructions for each tool.
Two new PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are out. There are also referred to as php2shell
Run this in ShadowTrackr to find all your php servers:
$software_overview_report software=php* last_seen>-7dYou get every host where PHP was detected in the last 7 days, across all your domains, subdomains and IPs, with the detected version for each.
software=php* matches every PHP version string.last_seen>-7d drops decommissioned hosts, so you only see what's exposed now.Patch internet-facing hosts first
19 October 2026
In ShadowTrackr, anything you can write as a query can become an alert. That's powerful, but it has an obvious problem: a blank query box doesn't tell you what's worth alerting on. So there are now two things to help.
The alerts documentation has a set of example alerts. Under each query is a Run in ShadowTrackr link that shows what the query finds in your own data today. If the result looks right, paste the query in a new alert and set the trigger to is greater than 0.
A few examples:
index=events change=tcp_port_opened:3389 earliest=-1dindex=cves_assets cvss_score>=7 first_seen>-1dindex=events change=security_header_removed earliest=-1dAlways add earliest=-1d to event queries. Without it the query also counts old events, so it keeps matching, and an alert that fires once a day will fire again every day.
I also wrote up the change= syntax. A single scan can change several things at once, and you still get one event on your timeline ("3 ports opened on host X"). With change=<field>:<value> you can alert on one specific value inside such an event, like port 3389 or protocol_added:TLS 1.0. This works for ports, certificates, DNS records and websites. Only events from after this feature was introduced can be matched, so older events won't show up.
Examples are nice, but copy-pasting is still work. So in the app, under Alerts → Alert library, you'll now find ready-made templates for the things most people want to know about. Pick one, adapt it if you like, and create it as your own alert. Every template fires when its query returns more than 0 results, and is throttled to at most once a day.
What's in there, by category:
Vulnerabilities
Hosts and ports
Certificates
Domains and DNS
Websites
Assets and discovery
Data leaks
I picked these because they catch the stuff that goes wrong quietly. Nobody tells you that a deployment dropped your Content-Security-Policy header, or that the nameservers of a domain changed at the registry (which is how domains get hijacked). A certificate renewal that silently failed shows up as a browser warning for your visitors, unless you had an alert that told you two weeks earlier.
shadowtrackr.com in the query. Don't forget to change that to your own domain.If you have an alert you'd like to see in the library, let me know. The full documentation is in the alert library section of the docs.