Legal Agreements for CloudLinux Products

Vulnerability Reporting & Disclosure Policy

At Cloud Linux Software, Inc. (“CloudLinux”), DBA TuxCare, we take the security of our customers seriously and try to resolve any security issues as soon as they are reported.

If you found any security issues with CloudLinux products, services, or systems, we appreciate your prompt disclosure of such issues. Please provide full details about the suspected vulnerability so that the CloudLinux security team may verify and reproduce the issue. 

You can use CloudLinux’s Security PGP key to encrypt sensitive information you send via email.

Please submit the report to [email protected].

To help us validate and triage your finding as quickly as possible, please include:

• Type of vulnerability (e.g., XSS, SQL Injection, RCE).
• Asset or product affected.
• Detailed steps to reproduce the vulnerability (screenshots, code snippets, and scripts are helpful).
• Potential impact of the vulnerability.

Policy Scope

We encourage you to discover and report to us any vulnerabilities in the company’s products:

• CloudLinux OS software, including its components, such as kernel, Apache, LVE Manager, Cage FS, MySQL Governor, Selectors, Hardened PHP, mod_lsapi, SecureLinks, Slow Site analyzer, PHP X-Ray, Centralized Monitoring, Accelerate WP, etc.
• TuxCare Live Patching software or TuxCare ELS software
• ImunifyAV, ImunifyAV+ software, including its components, such as Firewall, IDS/IPS, Malware scanning, Proactive Defense, etc.
• Imunify Email software.

We also accept vulnerabilities in company services and systems if there is a proven security impact. Please always carefully check whose assets you are testing when conducting research.

Out of Scope Vulnerabilities

The list of out-of-scope vulnerabilities includes, but is not limited to:

• Clickjacking on pages with no sensitive actions
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Attacks requiring MITM or physical access to a user’s device
• Previously known vulnerable libraries without a working Proof of Concept
• Comma-Separated Values (CSV) injection without demonstrating a vulnerability
• Missing best practice, configuration, or policy suggestions, including SSL/TLS configurations that do not contain a fully functional proof-of-concept
• Missing/enabled HTTP header/methods that do not lead directly to a security vulnerability
• Any activity that could lead to the disruption of our service (DoS)
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Rate limiting or brute-force issues on non-authentication endpoints
• Missing best practices in Content Security Policy
• Missing HttpOnly or Secure flags on insensitive cookies
• Missing email best practices (Invalid, incomplete, or missing SPF/DKIM/DMARC records, etc.)
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g, stack traces, application or server errors)
• Tabnabbing
• Open redirect – unless an additional security impact can be demonstrated
• Issues that require unlikely user interaction

Coordinated Vulnerability Disclosure

We consider security research activities conducted under this policy to be “authorized” and will not pursue civil or criminal action against any party for good-faith research that adheres to this policy.

To be considered “good-faith” research, you must:

• Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
• Only use exploits to the extent necessary to confirm a vulnerability’s presence.
• Provide us with a reasonable amount of time to remediate the issue before public disclosure.

Our Commitment to Disclosure

1. Acknowledgment: We will make a best effort to provide a non-automated acknowledgment of your report’s receipt within 3 business days.
2. Triage: Our security team will validate the vulnerability. We will notify you once we have confirmed the finding and determined its severity.
3. Remediation: Our team will work to fix the vulnerability promptly, based on its severity and complexity. We will aim to keep you informed of our remediation progress.
4. Public Disclosure: We request that you do not publicly disclose the vulnerability until we have mutually agreed upon a disclosure timeline and the fix has been deployed. A standard embargo period is up to 90 days from the date of our confirmed triage. Depending on the severity of the vulnerability and the complexity of the fix, the embargo period may vary and is a result of agreement with you.
5. Recognition: While we do not operate a formal bug bounty program, we are happy to provide public recognition (with your permission) to researchers who contribute to the security of our platform.