3CX

Who we are

3CX is a global leader in business communications, being used by more than 350,000 companies around the world. Taking advantage of the SIP open-standard and WebRTC technology, 3CX has evolved from its roots as a PBX phone system to a complete communications platform, offering customers a simple, flexible, and affordable solution to call, video and live chat. With 3CX businesses can increase productivity, enhance customer experiences, while dramatically cutting costs and management headaches.

The 3CX Bug Bounty program is part of its commitment to providing a secure, best in class, product to its customers and partners. 3CX looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.

Response Targets

3CX will make a best effort to meet the following SLAs for hackers participating in our program:

We’ll try to keep you informed about our progress throughout the process.

Disclosure Policy

• Please do not discuss or disclose vulnerabilities in this program (even resolved ones) outside of the HackerOne platform.
• Follow HackerOne's disclosure guidelines.

Program Rules

Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• Even though reports must be detailed in order to understand and reproduce an issue, they should be kept as short as possible.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Provide a working POC along with your report. (Theoretical vulnerabilities may not be accepted)
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. (If an issue affects multiple endpoints but stems from the same function, open only one report and include all endpoints)
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

Test Plan

1. Register on www.3cx.com using your hackerone email address. Confirm your email and follow the wizard to select a deployment type. (Please refer to our documentation for more information about each deployment type https://www.3cx.com/docs/manual/install/)

2. There might be new builds in the repository after you have installed it. If you find a vulnerability, before submitting it, make sure you update to the latest available version (both 3CX PBX and 3CX SBC) and ensure it is still valid. This includes Alpha/Beta/RC versions.

3. For any additional technical documentation you can refer to our website.

Hackers who want to test features that are only available in the ENTERPRISE license should use the "Credentials for testing" feature of H1 to request their license to be upgraded.

Scope of program

The scope of our program focuses on exploiting any of the components included/used in the 3CX software. This includes:

• 3CX Phone System V20 (Windows and Linux) -- On Premise -- SMB -- Hosted by 3CX

• 3CX SBC V20 (Windows & Linux)

• 3CX Windows app V20

• 3CX Mobile clients (iOS/Android)

• 3CX Live chat & WordPress plugin

• 3CX Customer portal

Bounties

• The 3CX Bug Bounty program recognizes the contributions of security researchers who invest their time and effort in helping us make 3CX more secure.
• The reward level is based on the vulnerability impact and increases for higher quality reports that include reproduction code, test cases, and patches. Rewards are not additive and are subject to change as we see fit. 3CX will determine the impact for a given security vulnerability based on existing and compensating controls. Prior bounty amounts awarded are not precedent for future payments. Our program's scope and policy is subject to change at any time and individuals are encouraged to refer to this policy often.
• Multiple reports by the same user for an issue that stems from the same root cause will be treated as one.
• Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of 3CX. While exceptional reports may qualify for higher bounties, there should be no expectation of a payout above the range baselines.

* ** Vulnerabilities found/reported related to the VoIP/RTC features of the product can be awarded with extra bonus (depending on severity).**

AI-assisted research and duplicate reports

The increasing availability of AI-assisted security tools has made vulnerability discovery more accessible. We are receiving an increased volume of overlapping findings, and researchers should expect a high likelihood that an issue identified through these tools has already been reported, even if it has not been publicly disclosed.

AI-assisted research is welcome, subject to our program rules. However, a valid finding may still be closed as a duplicate if it describes a previously reported vulnerability. Independent discovery, a different tool, or a differently written report does not make the same vulnerability a new finding.

Mandatory human verification and end-to-end proof of concept

Every reported vulnerability must be manually verified by the submitting researcher before submission, regardless of whether it was discovered using AI, automated scanning, source-code review, binary analysis, or manual testing.

Each report must include:

• The affected asset and relevant version, configuration, and environment.
• All prerequisites, including required access, privileges, and configuration changes.
• A complete, executable proof of concept, with step-by-step instructions covering the path from initial setup to the demonstrated security impact.
• Actual results and supporting evidence sufficient for our team to reproduce the same outcome.
• Confirmation that the researcher personally executed the proof of concept and verified the reported result.

AI-generated explanations, scanner output, suspicious code paths, and theoretical exploitation scenarios are insufficient on their own. Reviewing an AI-generated report or accepting a tool’s conclusion does not constitute manual verification. Reports without a human-verified, reproducible proof of concept may be returned for additional information or closed if the required evidence is not provided.

All verification must comply with the program’s scope and testing restrictions.

Severity, misconfiguration, and prerequisite access

Severity is assessed using demonstrated impact and realistic exploitation conditions. Findings that depend on deployment misconfiguration, weakened security controls, or pre-existing privileged access or compromise will receive a lower severity than otherwise equivalent findings exploitable without those prerequisites.

Examples include exploitation that requires:

• A malicious insider with existing privileged access.
• An already compromised system or workstation.
• An SBC or tunnel exposed contrary to documented deployment requirements.
• Two-factor authentication being disabled where required by the documented security configuration.
• Security controls being disabled, weakened, or bypassed through administrative configuration.

Reports must clearly distinguish prerequisites from consequences of the reported vulnerability and demonstrate what additional access or impact the vulnerability enables beyond the attacker’s existing capabilities.

These conditions do not automatically make a finding invalid. The final severity will reflect the actual security boundary crossed and additional impact demonstrated. Insecure product defaults, failures to enforce documented controls, and vulnerabilities that themselves create or bypass these prerequisites will be assessed on their own merits.

##Duplicates Duplicates aren’t always identical on the surface. Two reports may describe different entry points, payloads, or attack scenarios, but if they stem from the same underlying root cause, they’re treated as the same issue, since a single fix would resolve both. Similarly, fixing one vulnerability can sometimes resolve others as a byproduct, which is another reason related reports are grouped together rather than assessed in isolation. In some cases, an issue may appear unresolved from the outside when a fix has already been made internally. Vendors often bundle fixes into scheduled releases, so a patch may be complete and going through testing or waiting for the next release cycle, even though the vulnerability is still reproducible in the current public version.

Out of scope vulnerabilities

• Any activity that could lead to the disruption of our infrastructure or cloud services (DoS, DDoS).
• Lack of rate limit on cloud endpoints.
• Issues that require an attacker to have access to a user's system or email.
• Creating unlimited objects in the 3CX Phone System is not considered an issue by itself, unless there is a severe impact that can be demonstrated.
• Being able to see own credentials in the xAPI responses or of other users when in elevated roles
• SSRF in the Admin console on Self-hosted systems. On 3CX hosted systems actual impact must be demonstrated for a report to be accepted/eligible and not just the mere presence of it.
• Command execution/injection using the Call Flow Designer (CFD). The app has functionality to execute system commands by design.
• Any action that can be taken as a result of a misconfigured system or firewall. For example exposing port 5015 which is used for setting up the system and allows to upload a backup.
• Social engineering of our employees or contractors.
• Attacks against our physical facilities.
• Attacks requiring physical access to a user's device, unless the device is in-scope and explicitly hardened against physical access.
• Attacks requiring disabling Man In The Middle (MITM) protections.
• Attacks only affecting obsolete browsers or operating systems.
• Missing best practices (SSL/TLS configuration, Content Security Policies, cookie flags, tabnabbing, autocomplete attribute, DNSSEC, SPF/DKIM/DMARC records), unless a significant impact can be demonstrated.
• Information disclosure in log files in the product.
• Information disclosure in publicly accessible files/endpoints, unless a significant/real impact can be demonstrated.
• Clickjacking or Cross-Site Request Forgery (CSRF) on unauthenticated pages / forms with no sensitive actions.
• X-frame "bypasses" using proxies.
• Open redirects, unless a significant impact can be demonstrated.
• Self-exploitation (e.g XSS), unless a method to attack a different user can be demonstrated.
• Content spoofing, text injection and CSV injection, unless a significant impact can be demonstrated.
• Software version disclosure / Banner identification issues / Descriptive error messages or stack traces.
• Theoretical vulnerabilities that require unlikely user interaction or circumstances.
• Outdated dependencies.
• Subdomain takeover of any of the domains that are freely available in the 3CX Phone System.
• Reports generated by AI or automated tools that have not been manually verified by the submitting researcher and do not include a reproducible, end-to-end proof of concept demonstrating the claimed security impact.
• Leaked credentials from infostealers (Reports are welcome but are not eligible for a bounty)

Safe Harbor

Gold Standard Safe Harbor Applies to this program.

Thank you for helping keep 3CX and our users safe!