Hall of fame

At Greenhost, we consider the security of our systems a top priority. But no matter how much effort we put into system security, there can still be vulnerabilities present. This is why we have a Responsible disclosure policy, allowing independent researchers to find and report vulnerabilities to us that may exist in our systems, in exchange for a reward.

As an additional thank-you gift, this page lists –with their permission– the security researchers that reported serious vulnerabilities. We also included an explaination of the vulnerability, and how it was fixed by our team.

Security researchers

Rajdip Dey Sarkar

We have an application that allows our customers to manage their services, which is also used by our employees to help customers and manage internal services. One text field that could be controlled by customers was not properly sanitized at every place before being displayed. A potential attacker could have theoretically written code that would be executed on an employee's browser, giving them the same level of access for this application. In practice, other security measures (Content Security Policy, limited amount of user-controlled data) would have made such an attack difficult if not impossible. We fixed by ensuring all text fields were properly sanitized before displaying.

  • Rewarded: € 500
  • Reported on: 19 Apr 2024

Mayank Mukhi

We run a small website helping customers onboard on some of our projects / products. This website exposed the its source code through version control system folder available publicly on the website. A potential attacker could have learned about the internals of this website. This was fixed by removing public access to this system folder.

  • Rewarded: € 50
  • Reported on: 24 Jan 2023

Manohar Kommalapati

We run a contact form, allowing customers and potential customer to reach us. It implements a rate limit on the messages, to prevent abuse. However, this rate limit could be bypassed by forging the message so they seem to be coming from an internal system. A potential attacker could have flooded our system with messages, delaying the handling of messages from legitimate customers. This was fixed by improving the detection of the origin of the message.

  • Rewarded: € 100
  • Reported on: 4 Nov 2022

Nicolás Armua

We run a status page, to allow our customer to see the health of our infrastructure and receive mail alerts about it. The open-source software running this page was left unmaintained, and security issues were discovered but not fixed. One security issue in particular would have allowed a potential attacker to have total control over the software, most importantly allowing them to collect email address of subscribed customers. This was fixed by changing the software to a better maintained fork.

  • Rewarded: € 100
  • Reported on: 26 Apr 2022

Vladimir adsec2s Vlasov

We used a script to migrate some of our open source projects to a separate GitLab instance. That script was open-sourced too, however working access token were left public. This would enable a potential attacker with write access to our Stackspin repositories, and read access to some of our internal repositories. This was fixed by revoking the tokens.

  • Rewarded: € 100
  • Reported on: 6 Jun 2021

0xdln

Our open-source work suite Stackspin comes with the Rocket.Chat application for communication. An issue was discovered in the application, allowing potential attackers to see usernames and potentially some messages of the application. We missed the announcement of this issue, and thus deployed the fix later than we expect of our security standards.

  • Rewarded: € 50
  • Reported on: 4 Jun 2021

Himanshu

Our customers have an access to our service center, with a username and a password. If a customer has suspicion that someone is illegitimately accessing it, they might want to have a way to disconnect other sessions, or may assume that changing their password would do that. This used to not be the case, which would have let illegitimate users access the account for a few hours after the password change.

  • Rewarded: € 50
  • Reported on: 6 Nov 2020

Sandip Dhanwai

During an order, the browser sends an order id and a authentication token. Before the payment, the authentication token was not checked against the order id. This would allow a potential attacker to access the name, phone number, mail address of current and past customers having made an order by guessing their id, by doctoring a PayPal link. This was fixed by also checking the authentication token during this step.

  • Rewarded: € 1000
  • Reported on: 1 Sep 2020

Shrestha Anand

During an order, the browser sends the order id via the URL to a webpage. It was possible for a potential attacker to inject JavaScript code by appending it to the order id. This was fixed by using the order object id instead of the provided value.

  • Rewarded: € 800
  • Reported on: 27 Jun 2020

Sander Wind, Stan Faas and Hans Gillis

Our customers have the ability to register domain names and manage their DNS records. Previously, it was possible to register and handle the DNS of some Greenhost-owned domain names. This could have potentially allowed an attacker to run a man in the middle attack, if the suspicious activity went unoticed by our manual processes. We have addressed this issue by improving the logic of domain registrations.

  • Rewarded: € 1500
  • Reported on: 16 Apr 2020

Rahul Kumar Rai

We have a web form on our website that can be used to send feedback. It used to send a reply to the mail address that was provided. It is open to the public and we can not verify the address. In a recent update of the website this message was then delivered to our ticket system that auto-replied to the address provided. As such, this would have allowed an attacker to send spam or malicious links to random addresses. This was fixed by reverting to the old behaviour of not sending automatic replies for the web form.

  • Rewarded: € 150
  • Reported on: 29 Jan 2020