VDP · Active · No monetary reward · Hall of Fame recognition

Vulnerability Disclosure Program

Responsible Disclosure Policy

Help us keep MsgHub secure. No monetary reward at this stage — researchers earn public credit in our Hall of Fame, CVE assignment help, and Founding Researcher status. Median triage in 24 hours; we may add cash bounties later.

View Scope Submit Report

Want researcher credentials? Drop your email — we'll review and send a manual invite.

Researcher Hall of Fame

Recognition for security researchers

Every valid, impactful finding earns a permanent spot here, with your name (or handle), the finding category, and the date credited. We treat this wall as a public thank-you to the researchers keeping our customers safe.

Nisarg Vegadava

@0xsynix

Founding Researcher

Mass-assignment on the tenant settings API permitted post-creation tenant rename via an undocumented field, which retroactively rewrote historical audit-log entries through a JOIN-at-display denormalization. Reported responsibly with full reproduction.

Mass Assignment Audit Integrity

Credited 2026-04-26

@0xsynix LinkedIn

Deep Ghusani

Security Researcher

Founding Researcher

Identified that several input constraints were enforced only on the client. By submitting requests directly to the API with the client-side checks bypassed, out-of-policy values could reach server handlers — demonstrating the need for authoritative server-side validation on every accepting endpoint.

Client-Side Validation Bypass Input Validation

Credited 2026-04-26

LinkedIn

M K Rahul Rao

@Bugboy07

Founding Researcher

Reported a security vulnerability responsibly disclosed through our Vulnerability Disclosure Program. Submitted with a clear write-up and full reproduction steps, and fixed on the same day it was triaged.

Proof-of-Work Replay Anti-Automation Control

Credited 2026-09-03

LinkedIn

Roneil Bordallo

Security Researcher

Founding Researcher

Reported that our marketing origin returned pages without anti-framing response headers, allowing it to be embedded in a third-party iframe. Submitted with a clear write-up and a complete, working proof-of-concept, and prompted us to extend anti-framing headers beyond the application to every origin we serve.

Security Headers Defence in Depth

Credited 2026-09-22

LinkedIn

Researchers credited during the VDP phase are recognised as Founding Researchers — an irrevocable mark of early contribution as the program matures.

What you get

MsgHub currently runs a Vulnerability Disclosure Program (VDP) — no monetary reward at this stage. Valid, impactful findings earn public recognition and our genuine thanks. We may add cash bounties in the future as the program matures; researchers credited during the VDP phase will be recognised as Founding Researchers — an irrevocable mark of early contribution.

In-Scope Targets

*.msghub.info Tier 1

Web Application — Main dashboard, authentication, tenant management, all API routes

API — /api/* Tier 1

REST API — Auth, contacts, campaigns, templates, settings, invoices, integrations, SMPP management

Webhook Receiver — port 4001 Tier 1

Inbound API — WhatsApp, SMS, RCS inbound webhook handlers and carrier callback processing

SMPP Server — port 2775 Tier 2

Protocol — Enterprise SMPP interface, bind authentication, submit_sm / deliver_sm handling

Public SDK / Widget — /api/v1/* Tier 2

Public API — Public-facing endpoints authenticated by API key

SSRF Playground — /security-demo + /api/security/test-url/public + /api/security/challenge Tier 1

Public, unauthenticated SSRF guard playground — recommended starting point for webhook-security research. A bypass here applies platform-wide. See /security for valid-finding examples and hardening controls.

What We're Looking For

Authentication & Authorization

Critical
  • • Session hijacking / fixation
  • • Authentication bypass on any route
  • • Privilege escalation (member, admin, owner, superadmin)
  • • OAuth token leakage (Zoho, HubSpot integrations)
  • • MFA bypass

Multi-Tenant Isolation

Critical
  • • Cross-tenant data access (RLS bypass)
  • • IDOR — accessing another tenant's contacts, campaigns, templates, invoices
  • • Context switch abuse — accessing client tenants you don't own
  • • Tenant ID manipulation in webhook URLs

Injection & SSRF

High
  • • SQL injection (despite Drizzle ORM + Zod)
  • • Server-Side Request Forgery (SSRF guard bypass)
  • • Template injection in SMS / WhatsApp / RCS / email templates
  • • Command injection via campaign or chatbot flow parameters

Business Logic

High
  • • Rate limit bypass (X-Forwarded-For rotation, etc.)
  • • API key scope enforcement bypass (read-only key doing writes)
  • • Free messaging abuse — bypass billing / usage tracking
  • • Invoice amount manipulation
  • • Campaign sending without proper DLT registration

Information Disclosure

Medium
  • • Stack traces or debug info leaking in production
  • • Sensitive data in API responses (password hashes, internal IDs, secrets)
  • • Superadmin route path disclosure
  • • Exposed environment variables or config

Infrastructure

Medium
  • • Docker container escape or misconfiguration
  • • Redis / PostgreSQL / RabbitMQ exposed without auth
  • • Nginx misconfiguration allowing path traversal
  • • CORS misconfiguration allowing credential theft

Out of Scope

  • ✗ Denial of Service (DoS / DDoS) attacks
  • ✗ Social engineering, phishing, or physical attacks against MsgHub employees
  • ✗ Attacks on third-party services (Meta, MSG91, Gupshup, Kaleyra, Razorpay, Zoho, HubSpot)
  • ✗ Clickjacking on pages with no sensitive actions
  • ✗ Self-XSS (XSS that only affects the attacker's own session)
  • ✗ Missing security headers that don't lead to exploitable vulnerability
  • ✗ CSRF on unauthenticated forms (login, registration)
  • ✗ Email enumeration on login / forgot-password (known, accepted risk)
  • ✗ Rate limiting on non-sensitive endpoints
  • ✗ Vulnerabilities in outdated browsers or platforms
  • ✗ Content spoofing / text injection without demonstrable impact
  • ✗ Missing best practices without demonstrable security impact
  • ✗ Reports from automated scanners without manual validation and clear PoC
  • ✗ Open redirects unless chained with another vulnerability
  • ✗ Tabnabbing / reverse tabnabbing
  • ✗ SPF / DKIM / DMARC misconfiguration (report separately to [email protected])
  • ✗ Broken links or 404 pages
  • ✗ Attacks requiring MITM or physical access to user's device

Rules of Engagement

DO

  • ✓ Test only against your own accounts (create test tenants)
  • ✓ Provide clear, step-by-step reproduction in your report
  • ✓ Include impact assessment — what can an attacker actually do?
  • ✓ Report one vulnerability per submission
  • ✓ Give us reasonable time to fix before disclosure (90 days)
  • ✓ Use the lowest privileges necessary to demonstrate the bug
  • ✓ Stop testing and report immediately if you access another user's data
  • ✓ Encrypt sensitive details in reports using our PGP key
  • ✓ Include your CVSS 3.1 score estimate with justification
  • ✓ Chain low-severity bugs together if they produce higher impact
  • ✓ Test both cookie-auth (session) and API key auth paths
  • ✓ Check tenant isolation — this is our most critical boundary

DON'T

  • ✗ Access, modify, or delete data belonging to other real users
  • ✗ Perform any Denial of Service attacks
  • ✗ Spam users (real contacts, real phone numbers, real emails)
  • ✗ Use automated mass-scanning tools against production without permission
  • ✗ Publicly disclose vulnerabilities before they're fixed
  • ✗ Test against production infrastructure unless explicitly whitelisted
  • ✗ Exfiltrate data beyond minimum needed for PoC
  • ✗ Pivot from a vulnerability to attack internal infrastructure
  • ✗ Chain exploits that involve physical or social engineering
  • ✗ Submit reports generated purely by automated scanners
  • ✗ Submit duplicate reports — check our known issues list first
  • ✗ Attempt to brute-force credentials of real users

Submission Guidelines

Send your report to [email protected] with this structure:

Subject: [VDP] <Severity> — <Short Title>


1. Vulnerability Type: (e.g., IDOR, SQLi, Auth Bypass)

2. Affected Asset: (URL, endpoint, service)

3. Severity: Critical / High / Medium / Low

4. CVSS 3.1 Score: (with vector string)

5. Description: (what the vulnerability is)

6. Steps to Reproduce:

Step 1: ...

Step 2: ...

Step 3: ...

7. Proof of Concept: (curl commands, screenshots, video)

8. Impact: (what an attacker can achieve)

9. Suggested Fix: (optional but appreciated)

Response SLA. Acknowledge within 3 business days, triage + severity within 7 business days, fix or mitigation within 30 days for High / Critical. You will be kept informed at each stage.

Disclosure timeline. We coordinate publication with the reporter. Our target is public disclosure within 90 days of the initial report (sooner if a fix has shipped and the reporter agrees). We will request an extension, with reasoning, if a fix is in-flight at day-90.

Safe Harbor

We consider security research conducted consistent with this policy to be authorized and will not pursue legal action against researchers who:

  • Act in good faith and comply with this policy
  • Avoid privacy violations — do not access other users' data beyond minimum PoC
  • Report vulnerabilities promptly and don't exploit them beyond validation
  • Give us reasonable time to remediate before any disclosure
  • Do not degrade production services or access real user data

We will not file DMCA claims or pursue legal action under the Computer Fraud and Abuse Act (or equivalent Indian IT Act provisions) for security research conducted under these terms.

Ready to hunt?

Found something? Let us know.

[email protected]

security.txt