Major incident

SiteHost: Targeted DDoS

Affected: IMAP, API, Name Server 1, NZ – AKL01, NZ – AKL01, NZ – AKL01, NZ – AKL01, NZ – AKL01, NZ – AKL01, Control Panel, Name Server 2, POP3, NZ – AKL02, NZ – AKL02, NZ – AKL02, NZ – AKL02, NZ – AKL02, NZ – AKL02, Name Server 3, Webmail, NZ – AKL03, NZ – AKL03, NZ – AKL03, NZ – AKL03, NZ – AKL03, NZ – AKL03, AU – SYD01, AU – SYD01, AU – SYD01, US – CAL01, AU – SYD01, AU – SYD01, UK – LDN01, US - CAL01, SG – SGP01, DE - FRA01, AU – SYD01, DE - FRA01, Website, Domains

Current status of SiteHost: Operational — live SiteHost status

Timeline

1. May 25, 2026, 00:02 UTC
   investigating
   We are currently experiencing a Distributed Denial of Service (DDoS) attack affecting parts of our infrastructure. Our team is actively investigating the situation and implementing mitigation measures to minimise any impact on services. Some customers may experience intermittent connectivity issues, increased latency, or temporary service disruptions while mitigation efforts are underway. We will continue to provide updates as more information becomes available.
2. May 25, 2026, 00:31 UTC
   investigating
   We are continuing to investigate this issue.
3. May 25, 2026, 01:13 UTC
   investigating
   We are working with our upstream provider to adjust DDoS protection settings and optimise mitigation measures. During this time, some customers may experience intermittent interruptions or degraded performance. We will continue to monitor the situation and provide updates as progress is made.
4. May 25, 2026, 01:48 UTC
   investigating
   Services are currently operating normally for traffic routed within New Zealand. However, international traffic continues to experience degraded performance. Websites utilising CDNs or services hosted outside New Zealand may be intermittently affected, and external monitoring systems may incorrectly report affected services as unavailable. We continue to work with our upstream provider on mitigation efforts.
5. May 25, 2026, 02:40 UTC
   identified
   We have applied a mitigation on the network in Sydney to address the current issue and services should now be stabilising. If you continue to experience any issues with services or applications hosted with us, or if you are aware of any UDP traffic to or from your server, please contact our support team at [email protected].
6. May 25, 2026, 03:27 UTC
   identified
   We are still observing degraded performance across some services in all regions. We are actively working with our upstream providers to investigate and resolve the issue. We will continue to monitor the situation closely and provide further updates as more information becomes available.
7. May 25, 2026, 05:05 UTC
   identified
   We have applied a mitigation and websites/services that are not routed through Cloudflare should now be stabilising. We are still seeing degraded performance for some websites and services behind Cloudflare on certain networks and are continuing to investigate. We will provide further updates as more information becomes available. If you are still facing issues, please contact us at [email protected]
8. May 25, 2026, 07:59 UTC
   investigating
   We are continuing to experience service disruption related to ongoing issues between Cloudflare and SiteHost. Our team is actively working with our upstream providers to mitigate the impact and restore normal service as quickly as possible. For customers who use Cloudflare, we strongly encourage you to log a support ticket directly with Cloudflare and raise this issue with them. This will help bring the issue to Cloudflare’s attention and allow them to provide further technical details, which will assist us in working toward a faster resolution. You may also provide Cloudflare with our contact email address [email protected] so their team can reach out to us directly for coordination. Additionally, if you encounter network issues to our servers, please provide us with your IP address and traceroute to and from the server to your local network and forward to [email protected]. We apologise for the inconvenience and appreciate your patience while we continue working toward a resolution.
9. May 25, 2026, 10:18 UTC
   identified
   Our upstream providers have implemented additional mitigation measures to help address the ongoing issue. While these changes have improved overall service stability, some legitimate traffic may be impacted as a result. If you are experiencing issues with your websites, applications, or servers, please contact our support team. We can work directly with you to identify any affected traffic patterns and make any necessary adjustments to restore normal operation. We appreciate your patience and will continue to provide updates as the situation evolves.
10. May 25, 2026, 16:16 UTC
    identified
    Service in New Zealand remains stable, however we are still noticing impact due to the DDoS attack upstream internationally. We are still working with our upstream providers to implement mitigations. We have additional engineers working 24/7. If you need assistance, please drop us an e-mail and we will do our best: [email protected]
11. May 25, 2026, 21:34 UTC
    identified
    While general service levels continue to gradually improve we are still seeing ongoing impact from the DDoS attack, and we are working closely with our upstream providers to improve stability and connectivity. If you are experiencing issues please email support with your IP address and a traceroute to and from the server to your local network to assist is in troubleshooting. Thank you for your patience and support during this incident.
12. May 25, 2026, 23:16 UTC
    monitoring
    While we continue to monitor the situation closely, customer websites and servers appear to be stable at the moment. If you're still experiencing issues, please get in touch and include your IP address, a traceroute to the affected server, and steps to reproduce the issue.
13. May 26, 2026, 05:49 UTC
    monitoring
    All infrastructure has continued to be stable since our prior update, but engineers will continue monitoring closely overnight.
14. May 27, 2026, 22:06 UTC
    resolved
    All infrastructure has remained stable and we're now marking this incident as resolved. We're working on a full incident report that will be posted here in the coming days.
15. May 29, 2026, 03:52 UTC
    postmortem
    # DDoS Attack Incident Report On Monday 25 May, SiteHost received a ransom demand. This came from an actor using the name "BlackMatter" who had taken the time to sign up for an account with us. They demanded a nominal amount of Monero cryptocurrency, threatening a massive DDoS attack if we didn't pay. We had 15 minutes. We declined. Just before midday, the attack began. What follows is the detailed account of what happened, what we did about it and what we’ve learned. Some details may be a bit vague where we have opted to protect sensitive information, for ourselves or our upstream providers. ## Why didn't we pay the ransom demand? We refused for three primary reasons: 1. Paying provides no guarantee the attack will stop, or that a new demand won't follow. 2. Capitulating to extortion helps fund further attacks against us and others. 3. The New Zealand government [strongly discourages cyber-ransom payments](https://www.dpmc.govt.nz/our-programmes/national-security/cyber-security-strategy/cyber-ransom-advice). We would make the same decision again. ## What actually happened? Typically a DDoS attack will originate from a large number \(typically millions\) of compromised devices targeting a single or perhaps a small number of targets. We have blogged previously about how we would work with you if [you are targeted by a DDoS attack](https://sitehost.nz/blog/how-we-deal-with-ddos-attacks). In this instance, the specific target was us, SiteHost. We saw a sudden surge in traffic to effectively every single network address on our network. Individually the volume of traffic was not insurmountable, but combined it overwhelmed a number of our, and our upstream providers’, safeguards. ## Timeline \(NZST\) ### Monday 25 May * **11:52** — A DDoS attack was detected via monitoring alerts. Our network team opened an incident meeting within minutes and began working to identify which specific IPs were being targeted. Traffic volumes were substantial across our entire IP address space. * **12:05** — Our network engineers struggled to identify any clear patterns in the traffic when compared to a traditional DDoS attack. * **12:09** — First calls to upstream transit providers to coordinate mitigation. * **12:30** — We confirmed that the source of the traffic was widely distributed, across our entire network and coming in via a large number of remote IPs and networks. This ruled out simple edge blocking as a solution. * **13:00** — Mitigation applied to our network. We attempted to block traffic for unused IP space to reduce the attack surface. This was ineffective due to the sheer volume of traffic. * **13:15** — We began working with our upstream providers to adjust DDoS protection settings and engage scrubbing services. While our providers had DDoS scrubbing capability, the nature of the attack made it difficult for their systems to effectively distinguish attack traffic from legitimate traffic. * **13:30** — To get additional upstream support we engaged our secondary provider to assist. They immediately sprung into action creating their own incident response meeting with over 25 engineers, which we joined. * **13:50** — We dropped peering sessions that were contributing to large volumes of international \+ unfiltered traffic being routed to our network via local Internet Exchanges \(IXPs\). Services routed within New Zealand stabilised. * **14:15** — We called the National Cyber Security Centre \(NCSC\) for coordination and assistance. They committed to following up via email and a return call, though immediate solutions were limited. * **~14:30** — We further refined our traffic filtering, blocking non-essential UDP traffic. Some services began stabilising, however our upstream networks were still under load and experiencing high packet loss across their networks. * **~15:00** — We rerouted all Sydney transit traffic through Auckland and isolated our network to our secondary provider to utilise enhanced scrubbing capabilities. *

Updates as published by SiteHost (original).