Greenhost Blog

VPS vulnerabilities and responsibilities

2026-06-08T10:40:00+00:00

Over the past weeks multiple vulnerabilities were published that can affect VPS users on our platform. These recent vulnerabilities (Copy Fail, Dirty Frag and Fragnesia) were all so-called privilege escalation bugs, where people who already had some type of access could expand that beyond their intended rights. All of these vulnerabilities are now patched in the newest kernels.

We are writing this blogpost to provide a bit of background on such vulnerabilities, and the responsibilities involved.

The current fix

The vulnerability existed in the kernel of Linux. We patched these kernels as soon as we were aware of the vulnerabilities. The vulnerabilities have all been fixed. If you are using kernel version 6.12.90 or higher, you are safe from these vulnerabilities.

For the majority of our VPS users, restarting your VPS(es) is sufficient. This can be done either from the Service Centre, or by issuing the reboot command from inside the VPS itself.

If your VPS is covered under an SLA (Service Level Agreement, or maintenance contract), we have already upgraded the kernel of your VPS for you, no action is required in that case.

When is restarting not sufficient

By default our VPS's, load the kernel outside of the VPS. This allows us to update the kernel for you, so that only a reboot is required to load the latest kernel. It is however also possible to create a VPS where you manage the kernel yourself. If during creation you instead selected an Linux image with "(stock kernel)" behind it, the kernel is managed (by you) on the VPS instead, and you will have to take different steps to patch these vulnerabilties.

If you do not recall the installation process, you can check who manages the kernel for your VPS by any of these methods:

You can see what kernel is in use in our Service Centre. This can be seen under "VPS Cloud" > "VPSs" > "Manage VPS" > "Details". When this shows "Kernel: latest" the kernel is managed by Greenhost.
Logged in on the VPS you can see what kernel is currently in use. If you just restarted, and we manage the kernel for you, that kernel should be version 6.12.90 or higher.

How to patch when using stock kernel

If you manage the kernel yourself, and the current version is lower than 6.12.90, it needs to be updated manually. For this you can issue the following commands on the VPS:

apt-get update apt-get dist-upgrade rebootVPS vulnerabilities and responsibilities

If you previously ran one (or both) of the patches we suggested, you can undo these with the following commands:

rm /etc/modprobe.d/dirtyfrag.conf rm /etc/modprobe.d/disable-algif.conf

General Responsibilities

As host, we try to stay aware of any vulnerabilities. If we learn of any that are serious, we also try to inform our customers about them.

To this end, we have posted messages through our Service Centre, via Fediverse and for one of the vulnerabilities also via e-mail. However, we cannot guarantee to be always able to send warnings like this.

When a vulnerability is made public, there are several things we need to do:

Firstly we need to assess the impact the bug may have on our own systems, and address that. Then we need to assess the impact the bug may have on customer systems under our control and address that.

Only after that can we start to assess what impact a bug may have on customer systems that are not under under our control. The variety of machines this concerns is big, and we have only limited knowledge of what the VPSes are used for. Therefore it is very hard to assess what the impact would be, and which VPSes could be affected.

That is a judgement call we can not reliably make, not to mention the fact that we will not always be able to find time for this and that we do not want to overload our customers with emails. Especially with the unexpected rate these vulnerabilities are currently published.

Therefore, we want to make it clear that, even as we try to inform our customers in case of relevant vulnerabilities or events, we will not always be able to do so in a complete and timely manner.

When you choose to run a VPS, keeping up with updates and following news about these kinds of vulnerabilities, remains your own responsibility.

To partially automate keeping your system up-to-date you might want to consider installing unattended-upgrades (on Debian or Ubuntu) and configure this to also reboot after updates.

Please let us know if you have any further questions about this. We are of course happy to provide further advice when needed. You can use our contact form or send us an e-mail at support@greenhost.net.

Customer Data Breach

2026-05-22T10:30:00+00:00

On 27 April 2026, Greenhost identified and resolved a security vulnerability that exposed limited customer data to unauthorized access. 59 customers in total were affected. This post is the public record of what happened, what was exposed, and what comes next.

Greenhost has written openly when things go wrong, like when we had major outages in 2018 and 2021. We are writing this post because transparency is nice at comfortable times, but especially important in the uncomfortable moments.

Here is what happened

A hidden API endpoint, intended only for Greenhost staff, was deployed in 2023 with incorrect access controls. For roughly two years, the endpoint was technically reachable but not referenced anywhere in publicly visible code, making accidental discovery very unlikely. In September 2025, a reference to it was added to the front-end. From that point onwards, anyone analyzing the code could find it.

On 25 April 2026, a security researcher noticed the endpoint and accessed a small set of records to confirm the scope of the issue. They reported it through our Responsible Disclosure Program over the weekend. On the next working day, 27 April, Greenhost confirmed the report and patched the vulnerability. On 29 April, the incident was reported to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens).

What was exposed

For affected accounts, the following data was visible:

Company name, or personal name, where the customer is a private person
Billing e-mail address
IBAN data stored directly with Greenhost
List of active domain registrations
Internal Greenhost comments on the account

What was not exposed

Login names and passwords (including hashed passwords)
Customer addresses and phone numbers
Payment information stored with the external payment provider
Cloud customer data and contract data
Contact persons or their details
Support system data

Who was affected

Log analysis identified 20 customers whose data was accessed by automated bot traffic, a pattern consistent with broad security scanning rather than targeted activity. A further 39 customers had their data viewed by the security researcher in good faith while confirming the scope of the issue.

There is no current evidence of misuse. The 59 customers who’s data was accessed have been contacted about this via separate, individual e-mail.

Why this happened

The vulnerability resulted from inconsistencies in access control between two different mechanisms used in different parts of the platform. The risk of operating two methods in parallel was already known internally, and refactoring to consolidate them was already underway. This incident sharpens that priority. Finalizing a single, consistent access control mechanism is now at the top of the engineering queue.

Reflection

The honest assessment is that this should not have happened. The operational gap that allowed the endpoint to be exposed in the first place is the kind of issue Greenhost holds itself to a higher standard on. As such, we are embarrassed this happened. Privacy and security are not just commitments printed on a website; they are operational responsibilities, and on this occasion, the operations fell short.

There are two things worth saying beyond the apology.

The first is about data minimization. The most reliable way to protect customer data is to store less of it. Predating this incident, Greenhost has been simplifying onboarding and reducing the amount of information collected. We have also been working on removing previously obtained information, and we will continue doing this with renewed focus. Less data on the books means less data exposed when something goes wrong. This is privacy by design in its most practical form: Daily decisions about what data to ask for, what to keep, and for how long.

The second is about responsible disclosure. The reason this incident is being written about now, rather than discovered later through misuse, is that a researcher chose to report it through the proper channel. Greenhost's Responsible Disclosure Program exists precisely to make that the easier choice, and in this case, it worked. Programs like this are a quiet infrastructure for the open Internet. They depend on trust between researchers and operators, and they deserve more recognition than they usually get.

The researcher in this case is Shubham Bothra, who identified the exposed endpoint, retrieved only the minimum data needed to confirm the scope of the issue, reported it clearly and quickly through the proper channel, and offered to walk the Greenhost team through the steps to help resolve it. The work was carried out exactly in the spirit the Responsible Disclosure Program is built around. Greenhost has awarded Shubham a reward of €2,000 for the disclosure (the maximum possible payout under our program), and the team is grateful for the care and professionalism he brought to the process. He has been listed in the Hall-of-fame, where you can also see other researchers who were rewarded.

What comes next

Beyond the immediate fix and the notification to the regulator, Greenhost is:

Prioritizing completion of the access control refactoring already underway
Continuing the work to reduce the volume of customer data stored at all times
Reviewing internal processes for how new endpoints are reviewed before deployment, with particular attention to features that exist for staff use only
Reviewing what log retention is needed to investigate incidents like this thoroughly, while staying within the principle of storing only what is necessary

Trust, once shaken, is not restored by a blog post. It is restored by the work that follows, by the next year of decisions, and by being honest the next time something goes wrong too. That is the focus from here.

For any questions or concerns, the team can be reached at support@greenhost.net or through our contact form.

— On behalf of everyone at Greenhost

100% Green energy and still CO₂ emissions?

2025-07-22T08:00:00Z

Our servers consume a lot of electricity. For this we of course use 100% green energy. We don't buy this electricity directly, but this energy is supplied by our data centres. We do validate their energy sources, as well as request Green certificates/GvOs from them. This should mean we do not emit CO₂, right?

Well, even though we are using 'green' energy, the energy coming out of the wall socket is always a mix of green and grey energy. It only becomes 100% green through certificates (GvOs). We wrote a lengthy article about this: sjoemel stroom. So even if on paper it’s green, that doesn't mean it is actually green.

We believe that even if our emissions from electricity are zero on paper, we should do our best to make them zero in real life as well. To that end, we calculate our yearly (combined) real CO₂ emissions, and based on those calculations, we compensate through Trees for All. We also invest an equal amount into the energy transition through Meewind. Under the current circumstances, we believe this is the best we can do.

Understanding how Green the Grid is

The grid is a mix of wind, solar, gas, coal, nuclear, and other energy sources. If there is more wind or sunshine on a given day, the usage of gas and/or coal goes down, making the grid greener. At night, energy usage is lower, but there is also no solar energy. So depending on wind speed, the grid can be clean or dirty. This fluctuates throughout the day.

Luckily nowadays, there is much more precise information available on how green the grid is. European grid managers are required to make this data available and the website Electricity Maps sifons this information in a great visualisation. This is expressed in the term gCO₂eq/kWh — in other words, the number of grams of CO₂ equivalent emitted per kilowatt-hour used.

This is valuable information, as we can use this to improve our calculations.

How can we use this (grid) data?

Recently we added this grid data to our calculations. This allows us to create a better understanding of the impact our operations have. To see this in action, we'll explain how much electricity is used and how we combine this with the grid data.

Energy usage (per rack)

Servers are installed in a server rack. We operate multiple racks, usually each has a maximum capacity of ~5.5–6 kW. The below graph shows the energy consumption of a single rack, over a period of 48 hours.

Energy Consumption per Rack

As seen in the graph, during nighttime the platform is less busy and we consume less energy. However, the baseline for one rack is still about 5.35 kW, while the peak is at 5.90 kW (about 10% above baseline; note the Y-axis does not start at 0). So although there is variation, it is somewhat limited. We are experimenting with adjusting power settings of servers to improve energy savings. This can improve the saving a bit, but that effect will be limited as well.

The power grid

Now we add information about the grid. In this second graph, you see how efficient/green the grid is at specific times. For example, at nighttime on the 29th, the grid was not very clean with a value of 375 gCO₂eq/kWh, compared to daytime, when it was ~100 gCO₂eq/kWh. Of course, at night there is no production from solar panels. Apparently, during that night, wind speeds were also low, resulting in the need for more gas/unclean production of energy.

Power Grid Emissions

Combine both data.

In the final graph, we calculate how much CO₂ was emitted over this 48 hour period. (Note, this graph shows the cumulative CO₂ emissions. This means the line can only go up.) Now we see that when our electricity usage becomes lower during the night (see the first graph), our emissions actually started increasing at a higher rate.

Combined emissions

This makes sense, as we saw in the second graph, the grid power was less clean that night.

Conclusion

With this information combined, we have a much clearer picture of how much CO₂ we really emit. This helps us with our strategies to be more sustainable and decide where we should focus our efforts to make changes.

For the last years, we have used the average yearly data. Now we have the real-time data in hand, it is possible for us to revalidate our earlier estimations.

We are working on how to apply this information to improve our sustainability goals. For example by combining this data with the CO2-emissions during hardware manufacturing, this will have an effect on some policies. We will share more information about this in the near future.

Greenhost Is Leaving X and Facebook

2025-01-14T16:00:00+00:00

For many, many years, we have been ambivalent regarding our presence on social media in general, and Facebook and X/Twitter in particular.

Already back in 2010, we wrote a (Dutch) blogpost on whether or not to quit Facebook, and in 2015 we joined a large global initiative asking Mark Zuckerberg to stop his internet.org scheme. Since then, things only got worse.

Although social media are undeniably a very powerful tool in community building, we now feel the abuse of power and the tone of voice on X/Twitter, and the endless list of privacy concerns with Facebook far outweigh any benefits, and the ethical divide between those platforms and us has become too large.

Therefore, as of today, we will stop any active interaction on and through X/Twitter and Facebook.

This does not mean we fully turn our backs on social media. In the future, we might join other, more aligned, Social Media platforms such as Mastodon, Bluesky or Diaspora, but we have not yet decided on this.

In the meantime we will post our updates through the blogpages on our website. You can also use our RSS feed to follow us. If we indeed decide to join another social media platform, we will also share this here.

Updates on system status and maintenance can, as usual, be found on https://status.greenhost.net.

PS: Metas decision to stop working with independent fact-checkers was published after our decision to leave the platform, but only strengthens our resolve that we no longer belong there.

Greenhost Joins Forces with The Sharing Group (TSG)

2024-12-11T00:00:00+00:00

For over 20 years, Greenhost has focused on what we believe truly matters: sustainability, digital civil rights, and security. These ideals are at the core of what we do, and we’ve pursued these ideals with great passion and conviction— and we remain as committed to them today as we were when we started.

To continue pushing our ideals and amplifying our impact, we have recently become part of The Sharing Group (TSG).

Greenhost’s small scale and independent position are a key reason for some of our customers to host with us. That’s why we’d like to explain the new partnership, why we made this decision, and what it means for the future.

Why this decision?

In recent years, the hosting industry has evolved significantly. Hosting has become increasingly complex, with ever-growing technical challenges, more advanced security threats, stricter legal requirements, and rising customer expectations. Our small scale made it harder for us to navigate these changes while staying true to our ideals.

At the same time, we believe that companies like Greenhost, -driven by principles, not just profits- are needed more than ever.

Over the past few years, we’ve explored various ways to secure our future by building a more robust business model, all while safeguarding our ideals. We explored the possibility of partnering with socially conscious investors and implementing a steward-ownership model. Ultimately, we found that joining forces with TSG enables us to stay true to our values while benefiting from the stability and resources of a larger organization.

TSG is a family of companies with values that we strongly identify with. TSG focuses on strengthening the sharing economy and aims to accelerate the energy transition — goals that align closely with our own green objectives. Since 2023, TSG has also been moving toward a steward-ownership model, prioritizing societal impact over financial profit.

Within TSG, Greenhost will remain largely autonomous. Our name, our team, and our products will stay the same and we will continue to prioritize sustainability, digital civil rights, security, and open-source software.

At the same time, this partnership opens up new opportunities. Greenhost will take a leading role in developing cloud services for the group, providing a meaningful alternative to Big Tech.

We are confident that this collaboration will strengthen our mission and help us make an even bigger impact. As always, if you have questions, we are happy to answer them.

New release cycle PHP

2024-05-21T19:30:00+00:00

As you might know, every year a new PHP-version is released. This year that was PHP 8.3. We try to offer this new version on our hosting platform as soon as a stable release is available.

Together with the adding of a new version, each year support for an older version was dropped. PHP developers no longer supported the older versions and, as a result, we could no longer securely offer these versions. This is why we removed these older PHP-versions for our customers at that point. This has resulted in problems, such as websites that were no longer functioning correctly, but in the trade-off between customer convenience and security, we opted for security.

Recently, the PHP developers decided to extend the period in which security updates were applied. From this year onward, every version gets two years of active support and two years of security support.

We are happy with this decision, and we are glad to follow that schedule. This means we will not phase out a PHP version this year. PHP 8.1 is the oldest supported version, and we will keep offering that until the end of 2025.

Evidently, for the security of your website it remains crucial that the used CMS (Content Management System, such as Wordpress), themes and plugins are up-to-date.

Next to the security involved, in most cases a newer PHP version and an up-to-date CMS will result in better website performance. That is why we still advise to upgrade to the newest PHP version at an early stage. If that causes issues, you can easily switch back or research if there are alternatives to outdated software you might be using.

You can switch between active PHP versions in our Service Centre. More information on how to change the version can be found on our Helpdesk pages.

If you have any questions on this, please contact us through support@greenhost.net.