In this post I write briefly about the discovery of multiple security vulnerabilities in CyberPanel. Further details on each of the findings are provided separately in dedicated posts.

Background

Some time ago I was searching through open source web hosting control panels, and came across CyberPanel1. Setting it up was fairly simple, and the advertised functionality was more than enough for my personal use at the time. After becoming familiar with the available features, I started noticing some interesting behavior. This prompted me to take a closer look and search for potential security vulnerabilities.

At that point, I opened up Burp Suite and combined functional testing with source code review to determine how the different features were implemented. While this was clearly an opportunity for security research, I set specific goals that would keep me on track and allow me to:

  • read through the source code implementation and improve my code review skills in Python codebases
  • learn how the developer(s) implemented features and solved (or maybe introduced) problems in code
  • identify, analyze, and report potential security vulnerabilities

With the above goals in mind, priority was given to security-critical functionality that could be used to compromise CyberPanel instances.

Findings

This short adventure resulted in the discovery of significant vulnerabilities in CyberPanel’s functionality and security controls. While more time could be spent on this project, I concluded testing when the following vulnerabilities were identified:

Security Risk Title
Critical WebTerminal Authentication Bypass
Critical Authentication Bypass and Local File Inclusion (LFI) in CloudAPI
Critical Authentication Bypass in File Manager’s Upload Functionality
Critical Security Middleware Bypass
High Bypass of Security Controls in ‘commandInjectionCheck()’
Medium Insecure Generation and Storage of API Tokens
Medium Broken Authentication and Local File Inclusion (LFI) in ‘/api/FetchRemoteTransferStatus’ endpoint

This might look like a bit of a mess, and you could be right, to an extent. Before you arrive at that conclusion, however, take a look at the findings and see for yourself 😄.

Timeline

  • July 29, 2023: Sent an email to CyberPanel’s GitHub repository owner. No reply.
  • August 1, 2023: Sent a LinkedIn message to CyberPanel’s GitHub repository owner. No reply.
  • January 4, 2024: Tagged CyberPanel and its owner’s accounts on Twitter asking for security contact details. No reply.
  • January 13, 2024: Sent an email to CyberPanel support. No reply.
  • January, 22, 2024: Publication of findings.

As you can see, multiple attempts were made to responsibly disclose these vulnerabilities, however, in each one of them the vendor was unresponsive.

To add to this, there was no security contact or policy on CyberPanel’s website and the GitHub repository.

Timeline Update

  • January, 22, 2024: Vendor reached out, started patching and requested the issues to remain private until patches were tested and released.
  • January, 22, 2024: Blog was made private. Planned publication set for Friday, January 26th, 2024.
  • January, 25, 2024: Reached out to the vendor for a status update. Vendor was still testing the patches, preparing for the next release.
  • January, 26, 2024: CyberPanel v2.3.5 was released2.
  • January, 26, 2024: Blog was made public again.

Once these posts were published, Usman from CyberPanel reached out and we had a chat about some of the findings. He was very responsive in starting fixing the identified issues right away. Although I appreciate the quick action, this urgency could have been avoided entirely if we had established proper communication earlier in the process.

To avoid similar issues in the future, I suggested the introduction of dedicated security contact details (security.txt, security email address and public PGP key). This would hopefully motivate other researches to look at CyberPanel and improve its security posture.

In addition, GitHub’s private vulnerability reporting3 feature could be used. This would allow researchers to privately report security vulnerabilities directly to CyberPanel’s GitHub repository.

References

  1. https://github.com/usmannasir/cyberpanel ↩

  2. https://cyberpanel.net/blog/cyberpanel-v2-3-5 ↩

  3. https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories ↩