Security at MantelMarketing — disclosure done right.

Email security@mantelmarketing.com with the details of what you found. A complete report makes triage faster and cuts down on the back-and-forth — please include:

• A description — what the vulnerability is and why it matters.
• Steps to reproduce — the minimal recipe a developer can run to see the issue.
• Impact assessment — what an attacker could do if they exploited this.
• Optional: a proof of concept — please don’t run destructive PoCs against live customer data.

You can encrypt your report with our PGP key — fingerprint and key body live at /.well-known/security.txt and /.well-known/pgp-key.txt. If email isn’t an option, file a private security advisory through GitHub on our public repository.

We commit to the following timeline on every report we receive under this policy:

• Acknowledgement within 1 business day.
• Triage within 3 business days, with a severity classification you can challenge.
• Status updates at minimum every 7 days until the issue is resolved.
• Public credit — opt-in. We’ll list you in our hall of fame below with whatever name and link you prefer.

Fix-time service levels

Good-faith research is welcome. We will not pursue legal action against researchers who:

• Make a reasonable effort to avoid privacy violations and degradation of service.
• Only access accounts they own or have explicit permission to test.
• Do not intentionally exploit vulnerabilities beyond what’s needed to demonstrate the issue.
• Give us a reasonable window to remediate before public disclosure — 90 days is the default.

We consider research conducted under this policy authorised under the US Computer Fraud and Abuse Act and equivalent statutes — and we’ll say so publicly if a third party suggests otherwise.

The categories below are excluded — either because they aren’t security issues, because they require attacking someone other than us, or because they’re already monitored:

• Social engineering of MantelMarketing employees or contractors.
• Physical attacks on our offices or our staff.
• Denial of service — volumetric, NTP amplification, or anything that aims to take the site down rather than test a flaw.
• Brute-force attacks on rate-limited endpoints.
• Automated scanner output without manual verification.
• Self-XSS that requires the victim to paste malicious code into their own browser.
• Missing security headers without a demonstrated exploit path.

We follow a 90-day default disclosure window. Where a fix requires coordination with a vendor, customer, or upstream library, we may extend the window by mutual agreement. We’d rather extend a deadline than ship a half-cooked patch.

When the fix is live, we’ll publish a short post in the changelog describing what changed, credit the reporter (with permission), and reference any CVE we filed. If the issue affected customer data, we email affected customers directly per our breach-notification commitment in the privacy policy.

We don’t currently run a paid bug bounty program. Notable reports receive public acknowledgement and a thank-you note. We will revisit this policy if report volume warrants the operational overhead of a formal program — and we’ll announce it here first.

Researchers who’ve helped us improve will be listed here, with their permission. No reports have been credited publicly yet — you could be the first.

— awaiting first credited report —

Disclosure policy is one half of security; the architecture is the other. A short summary of the controls behind the platform:

Live state of every dependency is on the status page. Full data-handling commitments are in the privacy policy.

For security reports, write to security@mantelmarketing.com. For privacy questions, use privacy@mantelmarketing.com. For everything else, our contact page has the rest.

The machine-readable companion to this page lives at /.well-known/security.txt and follows RFC 9116.