Looking for how Infisical is built rather than how to report a problem with it? The product security architecture is documented at infisical.com/docs/internals/security.

Our commitment

Infisical builds secrets management, PKI and privileged access infrastructure. Our customers trust us with the credentials that run their systems, and most of our code is open source, so anyone can read it. We would rather hear about a security problem from you than from an incident.

If you have found a vulnerability in an Infisical product or service, we want to know. This policy explains how to tell us, what we will do about it, and what protections you have when you act in good faith.

Safe harbor

If you make a good-faith effort to comply with this policy during your research, we will consider your research authorized, we will work with you to understand and resolve the issue quickly, and Infisical, Inc. and its affiliates will not pursue or support legal action against you in connection with it. This includes claims under the Computer Fraud and Abuse Act and equivalent computer-misuse or anti-hacking statutes, claims under section 1201 of the Digital Millennium Copyright Act for circumventing a technical protection measure, and the terms of our own agreements that would otherwise prohibit security testing.

If a third party brings legal action against you for activity conducted in accordance with this policy, we will make it known that your actions were authorized.

You are expected to comply with all applicable laws. This policy does not authorize action against any system or organization other than Infisical, and it does not give us the ability to waive rights held by third parties.

If you are unsure whether a specific action is authorized, stop and ask us first at [email protected].

Scope

In scope

Asset	Notes
`app.infisical.com`	Infisical Cloud, US region.
`eu.infisical.com`	Infisical Cloud, EU region.
`infisical.com`, `www.infisical.com`	Marketing and documentation.
`github.com/Infisical/infisical`	Core platform: API and frontend.
`github.com/Infisical/cli`	CLI, agent, gateway and secret scanner.
`github.com/Infisical/agent-vault`	Credential broker for AI agents. Beta, and a novel attack surface, so we are particularly interested in findings here.
Anything else we publish under `github.com/Infisical` that ships in a product	Our official SDKs and integrations, our Kubernetes, Terraform, key-management and PKI components, and the libraries and patched forks our products depend on. The Out of scope list below bounds this.
Self-hosted Infisical	On a default or recommended configuration.

Out of scope

Any Infisical instance you do not own or operate. This includes self-hosted deployments run by our customers and any dedicated or single-tenant environment. These are other people's systems and testing them is not authorized by this policy.
Hostnames not listed above. Please do not enumerate or scan subdomains of infisical.com. Doing so reaches customer and internal infrastructure. If you believe an unlisted host is genuinely misconfigured, tell us the hostname and stop there.
Infisical's internal infrastructure and cloud control plane.
Third-party services and platforms we use, which have their own disclosure programs.
Archived and superseded repositories, including infisical-node, infisical-python, infisical-go-client and python-sdk-old. Please report against the current SDKs instead.
Upstream forks we do not ship. Our GitHub organization mirrors a number of third-party projects. A fork is in scope only where we patch it and ship it in a product; otherwise please report to the upstream project.
Repositories that are not part of the product, such as guides, samples, demos, hiring exercises and the organization profile.

What we care about most

Issues affecting the confidentiality, integrity or access control of secrets and customer data:

Remote code execution
Authentication bypass, including SSO (SAML, OIDC, LDAP) and machine-identity authentication
Authorization bypass and privilege escalation across organization, project, environment or role boundaries
Cross-tenant data exposure
IDOR or BOLA on secrets, certificates, private keys or credentials
Server-side request forgery reaching an internal service, cloud metadata, or a key-management endpoint
Any path that yields raw key material, decrypted credentials or certificate private keys

What we will not action

Denial of service, resource exhaustion and rate-limiting weaknesses. Describe one if you find it, but see Rules of engagement: do not test these.
Self-XSS, and issues requiring a victim to paste attacker-supplied content
Missing security headers or cookie flags with no demonstrated impact
Clickjacking on pages with no sensitive state-changing action
Automated scanner output with no validated, reproducible impact
Best-practice or hardening suggestions with no exploit
Third-party dependency vulnerabilities without a working exploit in Infisical's context. We run automated dependency scanning and maintain our own remediation queue.
Social engineering, phishing and physical attacks
Reports based solely on outdated software versions
Findings that require an insecure non-default configuration of a self-hosted instance. An insecure default is in scope and we take it seriously.

Rules of engagement

Our production systems hold live customer secrets. These rules are conditions of the safe harbor above.

Test only within your own organization. Create your own account and confine testing to resources you created.
Never access another tenant's data. If you find a path that reaches it, stop immediately. Do not enumerate, repeat, download or screenshot the contents. Report the single request that demonstrated it. We treat that restraint as evidence of good faith, and it will not count against you.
Do not run denial-of-service or volumetric tests, and do not test rate limiting, lockout or brute-force protection.
Automated scanning requires prior approval. Ask first.
Do not exfiltrate, persist or pivot. Retrieve the minimum needed to demonstrate impact.
Use synthetic data. Do not upload real credentials or personal data of any kind.
Report privately rather than publicly, and hold the issue until we have shipped a fix and agreed a disclosure date with you. See Disclosure.

Working with our source code

Most of Infisical is open source and we encourage you to read it. Source review is a legitimate way to find issues here.

A report should demonstrate impact rather than describe a suspicious-looking line of code. Where the rules above prohibit demonstrating something, describe the exploitation path instead and we will validate it internally. You will not be disadvantaged for following the rules.

We also run continuous internal source-code analysis and third-party penetration testing, and we maintain a substantial set of known issues. If your finding matches one, we will tell you plainly, and where we can we will tell you roughly when we found it. That is not a judgement on your work.

How to report

File your report through our Bugcrowd program: bugcrowd.com/engagements/infisical-vdp-ess. Reports filed there reach our security team and our triage partner directly.

Please include: what you found, where, how to reproduce it, what an attacker could achieve, and how you would like to be credited.

For the open-source repositories you may also use GitHub private vulnerability reporting. Please do not open a public GitHub issue for a security problem.

If you cannot use Bugcrowd, email [email protected]. That address also handles general security correspondence, compliance documentation and questionnaires.

What happens next

Stage	What to expect
Acknowledgement	Within 3 business days
Initial assessment	Within 7 business days
Progress updates	At each significant change, and on request
Resolution	We will tell you when a fix ships

We will keep you informed rather than leaving you guessing. If something is taking longer than expected, we will say so and explain why.

Disclosure

Please hold the issue until we have shipped a fix and agreed a disclosure date with you.

This matters more for us than for a typical SaaS company. Infisical is open source and is run by self-hosted and air-gapped customers, so the fix commit itself can reveal a vulnerability to an attacker while our customers are still on an unpatched version.

So we coordinate the announcement around three things:

A fix has merged and a patched release has shipped
Affected self-hosted, air-gapped and enterprise customers have been notified and given an upgrade window
Any associated advisory or CVE has been published

How long that takes depends on the severity of the issue and on how much of our self-hosted and air-gapped install base has to move. We will propose a target date once we have assessed your report, we will keep you updated, and we will tell you if it moves. Where a customer upgrade path is slow we may ask to extend it, and if we do we will explain why rather than simply refusing.

We are happy to credit you publicly in the advisory and release notes, unless you would prefer we did not.

Rewards

This disclosure program does not offer monetary rewards. We offer acknowledgement, public credit in our advisories and release notes where you want it, and a straight answer about what we are doing with your report.

Infisical also runs a private, invitation-only bug bounty program on Bugcrowd covering app.infisical.com, which does pay. Researchers who submit high-quality reports through this policy are strong candidates for an invitation.

Submit a report

bugcrowd.com/engagements/infisical-vdp-ess, or the form below. Either route reaches our security team and our triage partner, acknowledged within 3 business days.

INFISICAL

Vulnerability Disclosure Policy