Update - We are keeping this maintenance window open in a monitoring state to ensure maximum visibility and to address the most frequent questions our support team is currently receiving.

Please note: The active maintenance work and all host reboots were successfully completed well ahead of schedule and with only a few minutes of downtime per VM. There is no ongoing downtime caused by our infrastructure.

- Why this status post is still open: Leaving this maintenance open does not mean that active work is still in progress. We are keeping it visible solely to ensure that customers checking the status page later are fully informed about this critical security update. If your server is currently unavailable, it is not due to ongoing host maintenance. Please check your VM's internal status (e.g., failed autostart services), as the host-level work has been concluded.

- Nested Virtualization is permanently disabled: This feature has been disabled across all dataforest virtualization environments and is explicitly not planned to be reactivated. We anticipate similar security vulnerabilities to emerge in the near future, making this a permanent security policy. Our urgent recommendation remains unchanged: migrate your individual services to the dataforest cloud, or choose a dedicated server if you intend to continue hosting your own virtual machines. Our support team is ready to assist you.

- Software Emulation as a temporary workaround: In some cases, you might still be able to run virtual machines inside of your VM without Nested Virtualization by relying entirely on software emulation (e.g., using QEMU only, without KVM). Please test individually if your services function this way. Be aware that without hardware acceleration (KVM), performance will be severely compromised due to high CPU overhead. However, it may serve as a temporary bridge until you can properly migrate.

- Mandatory external contact emails: If you run your own mail server with us, it is mandatory to register an external contact email address in your customer panel. If your registered email address is hosted on the exact server that is currently experiencing an outage, you simply cannot receive our support replies or critical updates.

Jul 09, 2026 - 21:31 CEST
Verifying - All VMs on vnode22 have successfully booted and are back online after the applied fix proved effective. We apologize for the extended downtime.
Jul 09, 2026 - 15:33 CEST
Update - vnode22 is currently not starting its VMs. Please bear with us while we are working on this issue.
Jul 09, 2026 - 15:17 CEST
In progress - vnode22 is rebooting right now.
Jul 09, 2026 - 14:52 CEST
Verifying - The "ernie" migration has completed 5 minutes ago.
vnode22 will be rebooted in the next minutes.

Jul 09, 2026 - 14:44 CEST
Update - In light of recent events, we would like to point out the following to our customers:

- Customers who have previously used nested virtualization are advised to migrate their currently self-virtualized VMs to the dataforest cloud or switch to a dedicated server running Proxmox. Our support team is happy to advise you on this and will actively assist with the migration. Please keep in mind that nested virtualization is also not available in the dataforest cloud.

- We would also like to remind you of an important basic rule: If you run your own mail server with us, it is mandatory to register an external contact email address in the customer panel. If your registered email address is hosted on the exact server that is currently experiencing an outage, we simply cannot reach you in case of emergencies or support inquiries. Please check your settings and provide an independent address so that we can support you quickly and smoothly should the need arise.

Jul 09, 2026 - 13:01 CEST
Update - We have started the migration of "ernie" and will keep you updated on the progress.
The vnode22 reboot is planned to take place in about 3 hours.

Jul 09, 2026 - 11:17 CEST
In progress - We are currently preparing another required reboot of vnode22 (PHP-Friends G3 products) within the next few hours. A specific time will be announced as soon as possible.
This will also affect our Plesk web hosting system "ernie", which must be migrated to another node in this context, resulting in an extended downtime for this specific system. We apologize for the additional inconvenience.

Jul 09, 2026 - 09:46 CEST
Verifying - We have successfully completed the emergency maintenance well ahead of schedule. For the vast majority of VMs, the downtime was less than 5 minutes. We will keep this maintenance open in a monitoring state to ensure overall stability and carefully observe any incoming support tickets. Furthermore, due to the critical importance of this security update, leaving this post active ensures that customers checking the status page later will still be fully informed.
Jul 09, 2026 - 02:27 CEST
Update - Avoro VPS nodes vps-001 and vps-005 have successfully recovered and are back online. The host systems are currently starting all VMs. Please allow up to 10 minutes for your individual server to fully boot up and become reachable.
Jul 08, 2026 - 21:48 CEST
Update - We are currently experiencing unexpected issues with the Avoro VPS nodes vps-001 and vps-005 after applying the security update. Consequently, VMs on these hosts will remain offline for longer than 15 minutes. We are working on a fix with the highest priority.
Since this is a known issue that is being actively handled, please refrain from contacting support regarding these nodes. Keep an eye on this status page for the latest information.

Jul 08, 2026 - 21:43 CEST
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jul 08, 2026 - 18:30 CEST
Scheduled - A critical security vulnerability known as "Januscape" has been discovered in KVM, the core virtualization technology powering our infrastructure. This flaw potentially affects all virtual servers across our network. Over the past 24 hours, our team has analyzed the threat and developed an immediate mitigation plan.

This is one of the most severe vulnerabilities reported in KVM to date. While there are currently no public exploits available to compromise host systems, we expect this to change imminently. To ensure the absolute safety of all customer data and our infrastructure, immediate action is mandatory.

What we are doing
Over the next 24 hours, our engineers will work in multiple shifts to apply a security patch to all host systems, which requires a reboot of all virtual servers. Due to the extreme urgency of the situation and the massive scale of the infrastructure, it is unfortunately impossible to schedule individual maintenance windows.

Expected impact
- We expect a brief downtime of 5 to 15 minutes per virtual server. If your server is unreachable for more than 15 minutes, please check this status page for updates regarding potential host-specific issues. If there are no known issues listed, please contact our support.
- For unmanaged server customers: Ensure your VM is reboot-safe. Configure critical software to autostart on boot and terminate cleanly upon a shutdown signal from the host. Please understand that we cannot take responsibility for the internal configuration of unmanaged servers.
- For managed, webhosting, and TeamSpeak 3 customers: You do not need to take any action. Our team manages the configuration and safe reboot of your services automatically.
- As part of the security mitigation, we must globally disable nested virtualization (the ability to run a virtual machine inside your virtual server). This is a highly specific feature, and if your workload relies on it, you are likely aware of it. If this affects you, please reach out to our support immediately to discuss a custom solution.

We understand that this situation is unpleasant and challenging, but we must ensure the safety of all customers.

Affected products
This maintenance applies to every type of virtual server in our infrastructure, including:
- Seeds in the dataforest cloud
- Virtualized Avoro products (VPS, Rootserver, Power Rootserver, NVMe vServer, Compute vServer, Cloud Server)
- Every PHP-Friends vServer; both managed and unmanaged
- Our Plesk web hosting systems and TeamSpeak 3 servers (as these are hosted on the same virtualization platform)

Jul 8, 2026 18:30 - Jul 9, 2026 18:30 CEST
[dataforest Backbone] Interxion FRA8 Operational
90 days ago
99.9 % uptime
Today
Edge Network (affects all locations) Operational
90 days ago
100.0 % uptime
Today
DDoS Protection (affects all locations) Operational
90 days ago
99.6 % uptime
Today
Dedicated Servers (40G / 100G / 400G) Operational
90 days ago
100.0 % uptime
Today
Facilites Operational
90 days ago
100.0 % uptime
Today
[Datacenter] maincubes FRA01 Operational
90 days ago
99.99 % uptime
Today
Datacenter Routing and Switching Infrastructure Operational
90 days ago
100.0 % uptime
Today
Ceph Cluster Operational
90 days ago
100.0 % uptime
Today
Virtual Servers Operational
90 days ago
99.99 % uptime
Today
Dedicated Servers Operational
90 days ago
100.0 % uptime
Today
Plesk Web Hosting Operational
90 days ago
99.99 % uptime
Today
TeamSpeak3 Servers Operational
90 days ago
100.0 % uptime
Today
Network Storage Operational
90 days ago
100.0 % uptime
Today
Colocation Racks Operational
90 days ago
100.0 % uptime
Today
Facilites Operational
90 days ago
100.0 % uptime
Today
[Datacenter] firstcolo FRA4 Operational
90 days ago
100.0 % uptime
Today
Datacenter Routing and Switching Infrastructure Operational
90 days ago
100.0 % uptime
Today
Dedicated Servers Operational
90 days ago
100.0 % uptime
Today
Colocation Racks Operational
90 days ago
100.0 % uptime
Today
Facilites Operational
90 days ago
100.0 % uptime
Today
General Services Operational
90 days ago
100.0 % uptime
Today
Avoro CP & Support Operational
90 days ago
100.0 % uptime
Today
PHP-Friends CRM & Support Operational
90 days ago
100.0 % uptime
Today
Hotline Operational
90 days ago
100.0 % uptime
Today
Dedicated Control Panel Operational
90 days ago
100.0 % uptime
Today
IPMI VPN Operational
90 days ago
100.0 % uptime
Today
DDoS Manager Operational
90 days ago
100.0 % uptime
Today
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.
Jul 12, 2026

No incidents reported today.

Jul 11, 2026

No incidents reported.

Jul 10, 2026

No incidents reported.

Jul 9, 2026
Completed - The maintenance has been postponed due to unresolved software issues with the partner switch in rack X13. To proactively mitigate the risk of any network disruptions, we have decided to deploy entirely new switches in both racks. These will be interconnected and tested prior to going live, followed by a migration of all server uplinks in racks X12 + X13 at the end of July. This revised strategy not only significantly reduces individual server downtime but, first and foremost, guarantees network stability by eliminating potential hardware or software failures. A new maintenance window will be announced in advance.
Jul 9, 20:51 CEST
Scheduled - We will be performing planned maintenance on the network connectivity of the dedicated server rack(s) mentioned below at firstcolo FRA4.

What we are doing
We will update the software of the top-of-rack switches to resolve known bugs and ensure stable operation of the service. After the update, a reboot is required.

Expected impact
During the maintenance window, there will be a network interruption during each switch reboot. The reboot is expected to take up to 20 minutes per switch.

- Servers with only one uplink will lose network connectivity during that reboot. Connectivity should recover automatically once the switch is back online.
- Servers with two uplinks are designed to remain reachable during this maintenance, as one physical uplink will remain available while the other switch is rebooting.
- For servers with two uplinks, correct LACP configuration on the customer side is always required. Two physical uplinks only provide redundancy if they are configured as one LACP channel. If LACP is missing or incorrectly configured on the customer side, the server will become unreachable during the maintenance, even though redundant uplinks are physically available.

dataforest does not verify customer-side LACP configuration for unmanaged dedicated servers. Customers are responsible for ensuring that both provided uplinks are correctly configured and operational.

Affected rack(s)
X12

How to check if you are affected
In our control panel at https://dedicated.dataforest.cloud, open the server and check "Statistics". If one of your ports shows a description containing one of the rack identifiers listed above, your server is part of the maintenance scope.

You can see whether your server has one or two uplinks in your contract or product details. If two uplinks are included, LACP must be configured and actively used on your side.

Additionally affected managed dedicated servers (without access to the control panel): root077

We will complete the work as quickly as possible and aim to keep the interruption to the minimum stated above. Thank you for your understanding.

Jul 3, 16:58 CEST
Postmortem - Read details
Jul 9, 20:53 CEST
Completed - The maintenance could not be completed successfully. Our analysis has shown that a software bug in the X13 switch leads to MLAG instability, which is why we have rolled back the configuration changes. No major impact was caused by this software issue; however, a few brief network interruptions occurred, each lasting ~15 seconds, which did not align with our initial plan (two interruptions, 60 seconds each). We will announce a new maintenance window for racks X12 and X13 once a decision has been made on how best to handle the situation.
Jul 9, 02:19 CEST
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jul 9, 00:00 CEST
Scheduled - We will be performing planned maintenance on the network connectivity of two dedicated server racks at firstcolo FRA4.

What we are doing
We will interconnect each rack pair via MLAG (Multi-Chassis Link Aggregation) between the respective top-of-rack switches. This is an improvement to further increase resilience and operational flexibility.

Expected impact
During the maintenance window, there will be at least two brief network interruptions, expected to be up to 60 seconds (link flap / LACP re-negotiation). Traffic will recover automatically; no customer action is required.

Affected rack pairs
X12 + X13

How to check if you are affected
In our control panel at https://dedicated.dataforest.cloud, open the server and check "Statistics". If one of your ports shows a description containing one of the rack identifiers listed above, your server is part of the maintenance scope.

Additionally affected managed dedicated servers (without access to the control panel): root077

We will complete the work as quickly as possible and aim to keep the interruption to the minimum stated above. Thank you for your understanding.

Jul 3, 16:06 CEST
Jul 8, 2026
Completed - The scheduled maintenance has been completed.
Jul 8, 01:17 CEST
Verifying - The maintenance has been completed with less impact than expected. Network connectivity was interrupted for approximately 10 seconds.
We are monitoring our ticket system for any unforeseen issues over the next few minutes.

Jul 8, 00:58 CEST
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jul 8, 00:00 CEST
Scheduled - We will be performing planned maintenance on the network connectivity of two dedicated server racks at maincubes FRA01.

What we are doing
We will interconnect each rack pair via MLAG (Multi-Chassis Link Aggregation) between the respective top-of-rack switches. This is an improvement to further increase resilience and operational flexibility.

Expected impact
During the maintenance window, there will be at least two brief network interruptions, expected to be up to 60 seconds (link flap / LACP re-negotiation). Traffic will recover automatically; no customer action is required.

Affected rack pairs
AZ17 + AZ18

How to check if you are affected
In our control panel at https://dedicated.dataforest.cloud, open the server and check "Statistics". If one of your ports shows a description containing one of the rack identifiers listed above, your server is part of the maintenance scope.

Additionally affected managed dedicated servers (without access to the control panel): root319, root498, root503

We will complete the work as quickly as possible and aim to keep the interruption to the minimum stated above. Thank you for your understanding.

Jul 3, 15:58 CEST
Jul 7, 2026

No incidents reported.

Jul 6, 2026

No incidents reported.

Jul 5, 2026

No incidents reported.

Jul 4, 2026

No incidents reported.

Jul 3, 2026
Resolved - All Seeds have been live migrated (without downtime) to another node. We keep investigating the root cause internally.
Jul 3, 06:44 CEST
Monitoring - A fix has been implemented and we are monitoring the results.
Jul 3, 06:03 CEST
Identified - The issue persists, thus we migrate all Seeds to another node.
Jul 3, 05:40 CEST
Monitoring - A fix has been implemented and we are monitoring the results.
Jul 3, 00:01 CEST
Update - The system is operational but we keep investigate the root cause
Jul 2, 23:58 CEST
Update - The emergency reboot is done and we start to boot every seed on this node.
Jul 2, 23:43 CEST
Update - We just performed a emergency reboot for this node and continue investigating the issue.
Jul 2, 23:28 CEST
Investigating - We are currently investigating this issue.
Jul 2, 23:24 CEST
Jul 2, 2026
Jul 1, 2026
Resolved - This incident has been resolved.
Jul 1, 12:15 CEST
Monitoring - A fix has been implemented and we are monitoring the results.
Jul 1, 11:54 CEST
Identified - The issue has been identified and a fix is being implemented.
Jul 1, 11:49 CEST
Investigating - We are currently investigating this issue.
Jul 1, 11:15 CEST
Jun 30, 2026

No incidents reported.

Jun 29, 2026
Completed - The scheduled maintenance has been completed.
Jun 29, 19:00 CEST
Verifying - The maintenance has been successfully completed. We are keeping the window open for a few more minutes to closely monitor the network and any support tickets.
Jun 29, 18:42 CEST
Update - The Anti-DDoS cluster at EQX-FR4 has been back in service for the past 15 minutes, re-enabling granular mitigation for all dataforest edge routing POPs. Maintenance at DRT-FRA8 is still in progress but should not lead to a complete loss of granular mitigation at this PoP. As planned, only a portion of the capacity is being taken offline at any given time.
Jun 29, 18:13 CEST
Update - We have to extend the maintenance window to fix an unforeseen issue with our Anti-DDoS cluster at EQX-FR4. Currently, granular DDoS mitigation is unavailable at this PoP. Granular mitigation at DRT-FRA8 and basic filtering at EQX-FR4 are in service.
Jun 29, 17:03 CEST
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jun 29, 15:00 CEST
Scheduled - We will carry out maintenance on our DDoS protection infrastructure.

What we are doing
We will deploy software updates to our redundant DDoS scrubbing cluster. Filter appliances will be taken out of production and updated one by one to ensure mitigation capacity is always sufficient. After each update, functionality will be verified before we move on to the next filter.

Expected impact
No customer impact is expected at any datacenter, but it cannot be ruled out entirely. Idle (inactive) connections/sessions may time out; active ones should not, as they are synchronized during the startup of a new software release. If you notice anything unusual, such as timeouts of active sessions or the inability to connect to your server, please contact our support.

Affected customers
All IP prefixes routed through our DDoS protection (which is the default) are affected by this maintenance. Only prefixes that have been explicitly configured to bypass our DDoS protection (which we do not recommend) are unaffected. In any case, no customer action is required.

Fallback plan
Should the update fail and cause issues, we will disconnect the filters within a few seconds and update this status post transparently. In that case, mitigation of sophisticated attacks will not be possible for 30-60 minutes.

Jun 24, 20:44 CEST
Jun 28, 2026

No incidents reported.