Until now, an API key in ShadowTrackr could do everything your account could do. That is convenient, but it is not how you want to hand out access to a script, a SIEM or a colleague's dashboard. We added two things to fix that: API keys with a limited scope, and HMAC signatures on webhooks. Both help with the security measures that EU regulation asks of you.
When you create an API key, you now choose what it is allowed to do. A key for your reporting dashboard only needs to read. A key for a ticketing integration might only need to read findings. A key that can change settings or delete things is something very few integrations need.
Some examples of how this works in practice:
Existing keys keep working as before. You can replace them with scoped keys when it suits you. The API documentation lists the available scopes.
An alert can call a webhook, but until now the receiving side had no way to know that the call really came from ShadowTrackr. Anyone who found your endpoint URL could send it fake alerts.
You can now turn on HMAC signing for a webhook. ShadowTrackr calculates a signature over the payload with a secret that only you and ShadowTrackr know, and sends it in a header with every call. Your endpoint calculates the same signature and compares. If it does not match, you throw the request away.
This gives you two things:
The secret is stored encrypted and shown only once, like the custom header values. It works with all payload types, so it also covers JSON results, Splunk HEC and the rest. The documentation has a short verification example you can paste into your own code.
Regulation like NIS2, DORA and the GDPR does not tell you which header to use. It does expect you to show that you control who can access what, and that you protect your data in transit and know where it came from. These two options map onto that quite directly:
To be clear, no feature makes you compliant on its own. What these two do is give you controls you can point to, instead of a shared key and an unauthenticated endpoint. ShadowTrackr is hosted in Germany and run by an EU company, so your data stays inside the EU while you do this.
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