Responsible disclosure
Report a security concern with care.
Help us understand a suspected EzePanel vulnerability while protecting customers, credentials and running services.
How to reportA clear report.
A careful boundary.
Identify the affected component. Explain the observation. Keep private data private.
Reporting path
Start a private reporting conversation.
Use the existing EzePanel Contact form to request the appropriate private security-reporting channel. Choose “Other” and use “Security reporting channel” as the subject.
In the first message, include a short, non-sensitive summary, the affected product and release, and how the team can reply. Wait for an agreed handling method before sharing sensitive evidence.
Contact EzePanelUseful report contents
What helps us understand the concern.
- Affected component
- Identify the public website, commercial portal or installed panel, its version and the relevant feature. Remove private hostnames and account identifiers where unnecessary.
- Expected boundary
- Explain which role, account ownership, session or privilege restriction you expected to apply.
- Observed behavior
- Describe what actually happened, when you observed it and the smallest authorized reproduction. Separate confirmed behavior from possible impact.
- Relevant context
- Include the operating environment and configuration details needed to understand the result, with secrets and unrelated data removed.
- Impact and limits
- Explain the demonstrated effect and what you did not test. Do not access more data or disrupt a service to make the report appear more severe.
Keep research within permission.
Use only systems and accounts you are explicitly authorized to examine. Agree the scope before active testing and stop if an observation could expose another customer’s information or affect service availability.
This reporting guidance does not authorize scanning, account takeover, persistence, social engineering, destructive actions or denial-of-service testing. It creates no safe-harbor agreement or legal immunity.
Protect sensitive evidence.
Do not publish secrets, customer data or a working exploit against a live service in public issues, forums or social posts. Preserve only the minimum evidence needed within your authorization.
If you encounter a secret or private record, stop accessing it. Describe the category of exposure and request a suitable handling path. Do not attach a large database, log archive or unredacted screenshot to the initial contact.
Coordination
Agree the next step before expanding the work.
Keep follow-up observations connected to the original report. Confirm the intended recipient and handling method before sending further evidence, and request authorization for any additional testing.
Coordinate disclosure with the responsible parties while protecting affected users. Reporting a concern does not establish a bounty, fixed remediation deadline or permission to access EzePanel customers’ infrastructure.
Common questions
Reporting expectations.
Does this page authorize security testing?
No. Obtain explicit authorization for the systems, accounts and testing scope before testing. Public access to a service is not permission.
Is there a bug bounty?
No bounty or reward programme is announced here.
Should I include a credential or customer record as proof?
No. Describe the type of exposure without including the secret or private record. Ask for an appropriate handling method before sharing sensitive evidence.
Is there a guaranteed response time?
No guaranteed response deadline is established by this guidance.