Vulnerability disclosure

Pingram ("we", "us", or "our") welcomes good-faith security research. This Vulnerability Disclosure Policy explains how to report potential security vulnerabilities in Pingram products and infrastructure, what we ask of researchers, and how we will respond.

Researchers can discover this policy via our RFC 9116 security.txt. Reports should be sent to security@pingram.io.

1. Authorization and Safe Harbor

If you conduct security research in good faith, in accordance with this policy, we consider that research authorized. We will not pursue civil or criminal action, or refer the matter to law enforcement, against researchers who:

• Follow this policy and avoid privacy violations, destruction of data, and disruption of our services

• Do not access, modify, or destroy data that is not your own, beyond what is necessary to demonstrate a vulnerability

• Stop testing as soon as you confirm a vulnerability, and report it promptly

If legal action is initiated by a third party against you for research conducted in accordance with this policy, we will make it known that your actions were conducted in compliance with this policy.

This authorization does not extend to actions that violate applicable law, harm Pingram customers or employees, or fall outside the scope described below.

2. Scope

In-scope systems include:

• Pingram websites and dashboards, including www.pingram.io, app.pingram.io, and regional dashboard hosts (for example app.ca and app.eu)

• Pingram APIs and related endpoints we operate, including api.pingram.io and regional API hosts

• Official Pingram SDKs, CLI, MCP server, and other first-party developer tools we publish

• Notification delivery infrastructure that Pingram operates (email, SMS, voice, in-app, and related services)

Out of scope:

• Third-party products, subprocessors, or hosted portals we do not control (including vendor-operated trust or status pages)

• Customer applications, websites, or infrastructure that use Pingram

• Denial of service, volumetric flooding, or tests that degrade availability for other users

• Social engineering, phishing, or physical attacks against Pingram employees, customers, or offices

• Automated scanner output without a demonstrated security impact

• Missing security headers, SPF/DKIM/DMARC issues, or clickjacking without a practical exploit path

• Issues already known to us or already publicly disclosed

3. How to Report

Email security@pingram.io with as much of the following as you can provide:

• A clear description of the vulnerability and its potential impact

• The affected product, URL, API endpoint, SDK, or other asset

• Step-by-step reproduction instructions, including sample requests, payloads, or screenshots where helpful

• The date and time of your testing, and the account or identifiers you used

• Any proof-of-concept that stays within the limits of this policy

Do not include sensitive customer data in your report. If you encountered another party's data, stop, minimize what you retain, and tell us so we can contain the issue.

We do not currently operate a paid bug bounty program. We appreciate reports submitted in good faith and may recognize researchers at our discretion.

4. Rules of Engagement

When testing, you must:

• Use only accounts you own, or test data you are explicitly authorized to use

• Avoid accessing, copying, or modifying data that belongs to other customers

• Not exploit a vulnerability beyond what is needed to confirm it exists

• Not degrade service, send unsolicited messages, or use the platform to deliver spam, phishing, or malware

• Not attempt to pivot into other systems, maintain persistence, or exfiltrate data

5. Our Commitment

When you report a valid, in-scope issue, we will:

• Acknowledge receipt within five business days

• Work to validate the issue and keep you informed of our progress where practical

• Remediate confirmed vulnerabilities on a timeline appropriate to the severity and impact

• Notify you when the issue is resolved, unless doing so would create additional risk

We may not respond to reports that are out of scope, purely theoretical, or that do not include enough detail to reproduce.

6. Coordinated Disclosure

Please do not publicly disclose a vulnerability until we have confirmed it is resolved, or we have agreed in writing to a disclosure date. We aim to coordinate disclosure and typically ask for at least 90 days from our acknowledgment, or until a fix is available — whichever comes first — unless a shorter window is needed to protect users.

Public disclosure of an unpatched issue, or sharing exploit details that put customers at risk, is not covered by this policy.

7. Changes to This Policy

We may update this policy from time to time. The version posted on this page is the current policy. Our security.txt remains the machine-readable discovery file for this policy.

8. Contact