Security advisories
This page is the published record of security vulnerabilities that have been fixed in Hayami DTM. When a security update is released, an advisory is published here describing what was fixed, which versions were affected, and what you should do.
Current advisories
Section titled “Current advisories”Five advisories. HAY-2026-002 to HAY-2026-004 are fixed in 1.0.6, and HAY-2026-005 and HAY-2026-006 in 1.0.7. Upgrade to 1.0.7 to close all of them.
HAY-2026-002
Section titled “HAY-2026-002”Below-admin accounts could reach some admin-only API endpoints.
| Field | Value |
|---|---|
| Identifier | HAY-2026-002 |
| Affected versions | 1.0.1 to 1.0.5 |
| Fixed in | 1.0.6 |
| Severity | Medium |
| Impact | In rare cases, an account with the readonly or editor role could be treated as authorised on some admin-only endpoints. A readonly account could read administrator-only information, such as the user list, managed script contents and diagnostics. An editor account could also create health checks that are reserved for administrators, and run an Azure Private DNS import. No access was possible without a valid account. |
| Remediation | Upgrade to 1.0.6. |
| Workaround | Until you upgrade, give the readonly and editor roles only to trusted operators, and leave script health checks disabled (the default, allow_script_health_checks). |
HAY-2026-003
Section titled “HAY-2026-003”An editor could change an administrator’s script health check.
| Field | Value |
|---|---|
| Identifier | HAY-2026-003 |
| Affected versions | 1.0.1 to 1.0.5, only where script health checks are enabled (allow_script_health_checks, off by default) |
| Fixed in | 1.0.6 |
| Severity | Medium |
| Impact | An editor could change a script health check that an administrator created, for example by changing its target or by changing its protocol so that it no longer ran the script. If the script’s arguments held a credential that the script sends to its target, that credential could be sent to a host of the editor’s choosing. From 1.0.6 only an administrator can change or delete a script health check. |
| Remediation | Upgrade to 1.0.6. Where script checks were enabled, review your script health checks’ targets and protocols, and rotate any credential held in a script check’s arguments if you cannot confirm the target was never changed. The audit log records each change to a health check. |
| Workaround | Until you upgrade, leave script health checks disabled, or keep credentials out of script check arguments. |
HAY-2026-004
Section titled “HAY-2026-004”A wildcard record in a privatelink zone could redirect an Azure service’s names.
| Field | Value |
|---|---|
| Identifier | HAY-2026-004 |
| Affected versions | 1.0.5 |
| Fixed in | 1.0.6 |
| Severity | Medium |
| Impact | A wildcard record (such as *) in a Microsoft privatelink zone hosted in DTM could be used to answer for names of that Azure service that your organisation does not own, sending those clients to the address in the record. Creating the record needed write access to the zone, for example an editor account or a service account scoped to that zone. From 1.0.6 such a record is refused and is never answered from. |
| Remediation | Upgrade to 1.0.6. After upgrading, check the start-up log and GET /api/v1/diagnose (storage.api_refused_records, rule privatelink_wildcard) for any such record, and delete it. |
| Workaround | Until you upgrade, do not create wildcard records in privatelink.* zones, delete any that exist, and scope service accounts to privatelink zones only where a pipeline needs it. |
HAY-2026-005
Section titled “HAY-2026-005”An account with the editor role could cause an administrator’s health-probe credential to be sent to a host of its choosing.
| Field | Value |
|---|---|
| Identifier | HAY-2026-005 |
| Affected versions | 1.0.1 to 1.0.6 |
| Fixed in | 1.0.7 |
| Severity | Medium |
| Impact | Using this required an account that already held the editor role (or higher) in DTM. If such an account was misused or compromised, it could cause a probe credential that an administrator had added to a health check, a record’s probe template or an override’s probe template (for example an Authorization or API-key header) to be sent to a server of the account holder’s choosing. In 1.0.1 and 1.0.2 it could do this by changing the probe’s target. In every affected version it could also do this, for an https probe, by changing how the probe verifies the server’s certificate or which host name it presents, and, for ALIAS records and linked overrides, over http or https, by changing DNS forwarding so that the probe’s target name resolved to that server. The credential was never shown in the API or the web UI, and it could only be sent to a server that the DTM node could reach over the network. |
| Remediation | Upgrade to 1.0.7. From 1.0.7, a non-admin who changes a probe’s target, certificate or Host header settings must re-enter its credential. A probe that sends a credential header while skipping certificate verification with no CA certificate stops probing, unless the cluster’s health-probe TLS policy (allow_insecure_authenticated_probes) allows it. A credentialed probe on an ALIAS record or linked override that does not use https with a certificate verified for a name stops probing whatever that policy says. A probe that stops shows the status unknown with the reason. Before upgrading, move such probes to verified https. If editors could change your health checks or forwarders, review the audit log for changes to them, and rotate any probe credential whose destination you cannot confirm. |
| Workaround | Until you upgrade, give the editor role only to trusted operators. Keep static credentials out of health checks, record probe templates and override probe templates where you can. Where you cannot, use https with certificate verification and a CA you control, and do not attach credentials to probes on ALIAS records or linked overrides. Restrict the DTM nodes’ outbound traffic, with network security group rules or a firewall, to the destinations DTM needs: your probe targets, your DNS forwarders, the other DTM nodes, and the Azure and Microsoft services your deployment uses (such as Key Vault, Azure Resource Manager and Microsoft Entra); this limits where a credential could be sent. |
HAY-2026-006
Section titled “HAY-2026-006”A zone-transfer allow-list written with invalid entries could allow transfers from any address.
| Field | Value |
|---|---|
| Identifier | HAY-2026-006 |
| Affected versions | 1.0.1 to 1.0.6, only where zone transfers are enabled in the configuration file (axfr.enabled, off by default) with axfr.require_tsig off |
| Fixed in | 1.0.7 |
| Severity | Low |
| Impact | If every entry in axfr.allowed_cidrs in the configuration file was not a valid CIDR (for example 10.0.0.5 instead of 10.0.0.5/32), the list did not restrict transfers, and any host that could reach the node on TCP port 53 could transfer every hosted zone. A list saved through the API was not affected, because the API validates each entry. |
| Remediation | Before upgrading to 1.0.7, write every axfr.allowed_cidrs entry as a CIDR with its prefix length, even where zone transfers are not enabled: from 1.0.7 a node whose configuration file holds an invalid entry does not start, and the error names the entry. After upgrading, attempt a zone transfer from a host outside the list and confirm the server answers REFUSED. |
| Workaround | Until you upgrade, write each entry with its prefix length, or set the list through the API, or set axfr.require_tsig: true. Then test from a host outside the list as above. |
What each advisory contains
Section titled “What each advisory contains”| Field | What it tells you |
|---|---|
| Identifier | A stable reference, in the form HAY-2026-002 |
| Affected versions | Which released versions are vulnerable |
| Fixed in | The version containing the fix |
| Severity | How serious it is, on the scale below |
| Impact | What an attacker can achieve |
| Remediation | What to do, plus any workaround if you cannot upgrade yet |
Severity
Section titled “Severity”One scale, applied consistently:
- Critical. Exploitable without credentials, and leads to loss of control of the cluster or of the answers it serves.
- High. Leads to privilege escalation, disclosure of stored secrets, or forged DNS answers, but requires some existing access or a specific configuration.
- Medium. Limited impact, or requires an unusual configuration or an authenticated role that already carries significant privilege.
- Low. Minimal practical impact, published for completeness.
Identifiers
Section titled “Identifiers”Advisories carry Hayami identifiers in the form HAY-YYYY-NNN. CVE identifiers
are not currently requested. If that changes, existing advisories will be updated
to show the CVE alongside the Hayami identifier rather than being renumbered, so
any reference you have recorded stays valid.
How you hear about a security release
Section titled “How you hear about a security release”DTM tells you inside the product. The cluster checks for published versions and the web UI shows Update available, or Critical update available where the release addresses a security issue, on its lifecycle page. That check needs no outbound internet access beyond DNS, so it works in a VNet with no route to the internet.
Updates are applied by you rather than automatically, using the upgrade mechanism for the way you deployed, which Rolling upgrades sets out. DTM does not reach out to fetch and install software by itself. That is deliberate: an appliance that could pull and run new binaries would need an outbound path to an artifact store, and keeping that path closed is worth more than the convenience of unattended updates.
Confirming what you are running
Section titled “Confirming what you are running”You deploy DTM as an Azure Marketplace image, so what you verify is the image rather than a file you downloaded.
Azure records the publisher, offer, plan and image version against the virtual
machine and reports them independently of DTM. Check the VM’s plan and image
reference in the Azure portal, or with az vm show. Those values come from the
Marketplace purchase itself, and they identify the image Microsoft certified.
The web UI lists every node with the software version it is running, so you can confirm that each node matches the image version you deployed and that an upgrade has actually taken effect across the cluster.
Reporting a vulnerability
Section titled “Reporting a vulnerability”Email [email protected]. Please do not open a public issue for a suspected vulnerability.
Include what you found, how to reproduce it, and your assessment of the impact. Security sets out what is in scope and what response to expect, and links the disclosure policy with its safe-harbour terms for good-faith research.
When publication is delayed
Section titled “When publication is delayed”Occasionally the risk of publishing outweighs the benefit, because an advisory describing an easily weaponised issue can put clusters that have not yet been updated at more risk than silence does. In those cases the detail is held back until customers have had a reasonable opportunity to apply the update. The advisory is still published, and it records that publication was delayed.