Security Disclosure Policy

How to report a vulnerability, what to expect from us, and our safe-harbor commitment.

Reporting

If you believe you have found a security vulnerability in Melia or its associated services, please report it to:

What to Include

  • A description of the vulnerability and where it lives (binary version, URL, endpoint, file).
  • Steps to reproduce, or a proof-of-concept.
  • Your assessment of impact (data exposed, privilege gained, accounts affected).
  • Any suggested remediation, if you have one.
  • How you would like to be credited if a fix is published, or whether you prefer to remain anonymous.

Our Commitment

  • Acknowledgement: we will confirm receipt of your report within five business days.
  • Initial assessment: we will share our triage and severity assessment within fourteen days.
  • Coordinated disclosure: we aim to coordinate public disclosure within ninety days of a fix being available, or sooner if you and we agree.
  • Credit: if you wish to be credited, we will name you in release notes and on this page (when an acknowledgments section is added). If you prefer to remain anonymous, we will respect that.

Scope

Reports about the following are in scope and welcomed:

  • The Melia desktop application binary (any supported release version).
  • melia.buxjr.com — this website.
  • locksmith.buxjr.com — the licensing service.

Out of Scope

The following are out of scope; please do not test against them:

  • Social engineering of Melia staff, partners, or customers.
  • Physical attacks against Melia personnel or facilities.
  • Denial-of-service or volumetric load testing.
  • Findings in software Melia depends on but does not author (Electron, Chromium, Node.js, native modules) — please report those upstream to their respective projects.
  • Findings that require physical access to an unlocked, logged-in user device (these are end-user OS security issues, not Melia vulnerabilities).
  • Reports generated solely by automated scanners with no manual validation and no demonstrated impact.
  • Best-practice or hardening suggestions that do not describe a specific vulnerability (e.g., “you should add header X” without a concrete exploitation path).

Safe Harbor

If you make a good-faith effort to comply with this policy during your research, we will consider that research authorized. We will not pursue legal action against you, and will work to make any necessary legal authorizations clear, provided you:

  • Stay within the scope defined above.
  • Access only systems and data necessary to demonstrate the vulnerability.
  • Do not exfiltrate, modify, or destroy user data beyond what is needed to prove the finding.
  • Do not perform attacks that degrade service for other users (denial of service, resource exhaustion, mass account creation).
  • Give us a reasonable opportunity to remediate before disclosing publicly.
  • Do not request bug bounty payment as a condition of disclosure (we do not currently offer a paid bounty program).

If at any point you are uncertain whether your intended testing falls within this policy, contact us first at security@buxjr.com for clarification.

Bug Bounty

Melia does not currently offer monetary bug bounty payments. We are a small commercial project and prefer to invest in responsiveness, fixes, and public credit rather than pay-per-finding economics. If you'd like to be credited for a valid finding, we will name you in release notes and in any future security acknowledgments page.

This Policy May Change

We may revise this policy as the project grows. The current version is always available at melia.buxjr.com/security-policy. Material changes will be reflected in our security.txt file.

Related: Trust & Transparency · security.txt · Privacy Policy