Skip to content

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.

None. No security advisories have been published for Hayami DTM.

The page exists so the channel is established and citable before it is needed, rather than being invented under pressure during an incident.

Field What it tells you
Identifier A stable reference, in the form HAY-2026-001
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

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.

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.

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.

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.

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, the safe-harbour statement for good-faith research, and what response to expect.

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.