Vulnerability Disclosure Policy

Last updated: 2026-05-17 · Governed by the laws of the Republic of Ghana

LTX MoMo Insurance welcomes security research. This policy explains how to report a vulnerability and the protections we extend to good-faith researchers who follow it.

1. Our commitment

Customer money sits on the other side of every API we ship. We take vulnerability reports seriously and aim to fix critical issues fast. We commit to:

• Acknowledge your report within 2 business days.
• Triage and confirm severity within 5 business days.
• Provide a fix or compensating control timeline within 10 business days.
• Not pursue legal action against researchers who act in good faith under this policy.

2. Scope

The following assets are in scope:

• The customer portal at the production domain and its subdomains.
• Public API endpoints under /api/v1/*.
• The enrolment, verification, USSD, and webhook surfaces.
• First-party mobile clients (when published).

Particularly welcome classes of finding:

• Authentication or authorisation bypass — cross-customer data access, role escalation.
• Anything that lets a third party trigger MoMo debits or claim payouts.
• Injection (SQL, command, template), SSRF, RCE, deserialisation flaws.
• Sensitive-data exposure: Ghana Card numbers, biometric artefacts, raw audit logs.
• Authentication-token leaks (CSRF/CSP misconfig, IDOR on signed URLs, JWT verification flaws).
• Logic bugs in premium ceding, claim adjudication, or sanctions screening.

3. Out of scope

• Findings on third-party services (MTN MoMo APIs, public WHOIS data, registrar configuration).
• Social-engineering attacks against staff, customers, or agents.
• Physical attacks on offices or data-centre infrastructure.
• Volumetric DDoS, brute-force at scale, or any action that disrupts the live service.
• Reports generated solely by automated scanners with no demonstrable impact.
• Best-practice missing headers / TLS-ciphersuite reports without an exploit chain.
• Self-XSS and email-spoofing reports without a working PoC.
• Outdated browser / EOL-OS issues.

4. Rules of engagement

To stay within safe harbor you must:

• Test only on accounts you own or have explicit written permission to test.
• Stop and report immediately if you encounter PII, payment data, or biometric artefacts that aren't yours — do not download, copy, or share.
• Avoid degrading the service (no fuzzing in production, no destructive proof-of-concepts).
• Keep findings confidential for at least 90 days from acknowledgement, or until we publish a fix — whichever is sooner.
• Comply with all applicable laws of Ghana.

5. Safe-harbor promise

If you act in good faith and follow this policy, we will:

• Not pursue or support legal action against you arising from your research.
• Treat your report as authorised conduct under the Electronic Transactions Act, 2008 (Act 772), and any analogous statute.
• Work with you to understand and resolve the issue quickly.

This safe harbor does not apply to activity that violates the rules in §4, exceeds the scope in §2, or causes harm to customers or service availability.

6. How to report

Email security{{ parse_url(url('/'), PHP_URL_HOST) }}. We strongly prefer PGP-encrypted reports. The fingerprint of our security PGP key can be obtained on request from that address.

A good report contains:

• A short summary (one line).
• Affected endpoint or URL.
• Reproduction steps with the minimum-viable proof-of-concept.
• Impact: what an attacker can do, in plain English.
• Suggested fix or compensating control, if you have one.
• Your handle for credit (or "anonymous").

You'll also find the machine-readable version of this policy at /.well-known/security.txt (RFC 9116).

7. What happens next

1. We acknowledge by email within 2 business days.
2. We triage and propose a severity rating; you have 3 days to push back.
3. We engineer a fix on a timeline appropriate to the severity (critical: hours; high: days; medium: weeks).
4. We notify you when the fix is live and invite you to retest.
5. With your consent, we credit you in the next release notes.

8. Recognition

We do not currently run a paid bug-bounty programme. We do publish a quarterly Security thank-you list with researchers' handles (with consent) and provide a signed letter of acknowledgement on request.

Thank you for helping keep customer money safe.