Participation Guidelines

Huntr is a vulnerability disclosure program for the AI/ML supply chain. We provide a platform to simplify the vulnerability disclosure process for security researchers and maintainers. We provide bounties to reward security researchers who find impactful and practical vulnerabilities in the AI ecosystem and to maintainers who fix them. We offer two distinct bug bounty programs:

  1. Model File Vulnerabilities (MFV): Focused on machine learning model file formats and their unique attack surfaces.
  2. Open Source Vulnerabilities (OSV): Targeting security flaws in ope-source AI/ML apps and libraries .

Each program has tailored guidelines and scope to maximize their respective impact.

Scope

We accept reports for all targets listed on our Bounties page.

Model File Vulnerabilities (MFV) Bug Bounty Guidelines

We are seeking novel vulnerabilities and exploits in machine learning model file formats and loading processes. Our focus is on attacks that occur at model load time or during inference, including backdoor manipulations and other malicious behaviors hidden within model files. Check out our Beginner's Guide for MFV for examples of previously discovered attacks!

The key value we want participants to hunt for is malicious attacks that bypass the ProtectAI safety scan on huggingface.com

Scope & Prioritization:

High-Value Targets:

  • File Formats: .safetensors, .gguf, .keras, .joblib
  • Vulnerability Types:
    • Arbitrary Code Execution (ACE) through a file format vulnerability
    • Backdoors or output manipulation triggered by malicious model files
    • Unique methods to bypass our existing model scanning tools

Medium to Low Value Targets:

  • File Formats: .pkl, other small or less-common formats
  • Vulnerability Types:
    • Zip/Tar-based directory traversal (Zip/TarSlip)
    • Library-specific code execution not coming directly from the model file load or inference
    • Denial of Service (DoS) attacks through malformed model files

What We’re Looking For:

  • Attacks that cause code execution at model load time by manipulating headers, metadata, or custom operators.
  • Embedded backdoors within model architectures that alter inference outputs under specific conditions.
  • Techniques that trick or evade our automated scanners, allowing malicious model files to go undetected.
  • Vulnerabilities in model file parsing leading to memory corruption (heap overflows, integer overflows, etc.).
  • Exploits via custom layers, operators, or code embedded in model formats that execute during model loading.

Submission Requirements:

  • Provide a proof-of-concept (PoC) model file uploaded to a public HuggingFace repository and reproduction steps.
  • Clearly explain the vulnerability, how you’ve created the PoC model file, affected file format, and conditions required to trigger it.
  • Demonstrate the security impact (e.g., code execution, silent output manipulation, scanner bypass).

Out of Scope:

  • Attacks requiring unrealistic prerequisites (e.g., already having full host access).
  • Non-actionable crashes or benign parser errors without security impact.
  • Model file formats that are executables such as raw Python or .llama files.

Responsible Disclosure:

  • Submit findings through our official reporting channel.
  • Do not publish full exploitation details until we have confirmed and addressed the issue.
  • Follow standard responsible disclosure timelines.

Open Source Vulnerability (OSV) Program

While we are shifting our incentives to guide researchers towards the model file vulnerability program, we are still committed to increasing the security of the AI ecosystem as a whole with the open source vulnerability program. Check out our Beginner's Guide for OSV.

Focus: Open source AI libraries

What We Look For:

  • Vulnerabilities with clear, real-world impact (directly exploitable & affects users)
  • Clear proof of concept (code, scripts)
  • Concise reports (focus on impact)

Out of Scope:

  • Non-code vulnerabilities (network, physical)
  • Test/demo code issues
  • Live, 3rd party-hosted systems (websites you don’t own for example)
  • Secrets/private keys
  • Protect AI services/products

Vulnerabilities Likely to be Marked Informational

The Huntr team will likely mark the issues below as informational unless maintainers specifically request validation.

  • Any security issues related to CI/CD
    • Example: GitHub Actions command injection
  • Any issues related to bad TLS certificates
  • Any issues related to payment bypasses or pricing plan bypasses that don't have security implications
  • Any security issues that first require paying to access to specific features in order to exploit
  • Local Re-DOSes that are not remotely exploitable
  • Blind or otherwise limited Server-Side Request Forgeries (SSRF)
  • Command injection in a locally-installed library which is not remotely exploitable
    • Exception: If the library is known to be commonly used as part of remotely accessible applications
  • HTML/Markdown injection in text fields
    • Exception: Cross-Site Scripting (XSS) attacks which trigger immediately
  • Lack of Rate Limiting
  • Session token expiry issues
  • Missing HTTP security headers
    • Examples: clickjacking, missing HttpOnly cookie flags, missing HSTS headers
  • Exceptions triggered in local libraries without networking components
  • Metadata not stripped from uploaded images
  • CSV injection
  • Self-XSS or XSS attacks which do not automatically trigger
  • Local libraries that allow Pickle files to be loaded
    • Exception: libraries with builtin networking components such as HTTP/API servers that allow remote users to upload Pickle files to achieve remote code execution

To view our Protect AI's vulnerability disclosure policies, please visit https://protectai.com/vulnerability-disclosure-policy

General Submission Guidelines

To maximize your impact and streamline validation:

  1. Proof-of-Concept (PoC): Include a concise and clear demonstration of the issue:
    • Reproducible scripts or commands (e.g., cURL, Metasploit modules, Python scripts).
  2. Details Matter: Specify deployment methods (e.g., arguments used) and contextual details.
  3. Concise Reports: Focus on exploitability and user impact rather than verbose descriptions.

Life of a Report

1. Disclose

  • All vulnerability disclosures must go through our forms. To be eligible for a bounty, your disclosure must go through our process, unless explicitly stated by one of the site admins.

  • When the security researcher submits their vulnerability report, we will acknowledge receipt of this disclosure by sending them an e-mail. The e-mail will be sent to the address linked to their registered account. This report is private by default, and only the reporter, contacted maintainers (for OSV) and site admins can view it.

2. Validate

  • OSVs: Once a disclosure is submitted, the maintainer of the vulnerable codebase will be invited to validate or invalidate the vulnerability with the security researcher. If validated, the disclosing researcher will be rewarded a bounty and a CVE will be assigned to the vulnerability (if applicable).
  • MFVs: Validation focuses on exploit severity and scanner evasion, with no CVE or publication timeline.

In all cases we aim for a 45 day time to review.

3. Patch

  • OSVs: Encouraged by maintainers, but researchers may also submit patches.
  • MFVs: N/A

4. Publish

  • OSVs: Reports are published after 90 days by default, with extensions available upon request.
  • MFVs: N/A for the moment.

You can find a list of our published vulnerabilities on our hacktivity page.

Payments

We pay bounties each month, typically on the 25th, via Stripe Connect. For the first month that you are due a payment, you will receive an email requesting you to create a Stripe Connect account. There you will need to provide your identity and payment information so that your account can be verified. Once your account is verified, you will receive an email confirming the details of your payout. In subsequent months, you will only receive an email confirming the details of your payout.

Stripe Connect supports payouts to most countries. You can see the full list of supported countries here. If your country is not in this list, we will not be able to process a payout to you, but instead can offer to donate your payout to charity.

Participation

By accessing and using our Website, you acknowledge and agree that you are subject to the following conditions:

Eligibility: By participating in our Bug Bounty Platform, you confirm that you are not a citizen or resident of any country where such participation is prohibited by applicable laws, decrees, regulations, treaties, or administrative acts.

Sanctions and Embargoes: You further confirm that you are not a citizen or resident of, or located in, a country or region that is subject to U.S. or other sovereign country sanctions or embargoes.

Restricted Entities: Additionally, you acknowledge that you are not an individual employed by or associated with an entity identified on the U.S. Department of Commerce's Denied Persons or Entity List, the U.S. Department of Treasury's Specially Designated Nationals or Blocked Persons Lists, or the Department of State's Debarred Parties List. You must also be eligible to receive items subject to U.S. export control laws and regulations or comply with other economic sanction rules of any sovereign nation.

Age Requirement: Our Website is not intended for use by children under the age of 13. If you have not reached the age of majority in your jurisdiction of primary residence and citizenship, you must obtain your parents' permission to use this Website.

Relevant Laws: You must abide by all relevant laws and respect a project's policies (e.g. Terms & Conditions, Security Policy), as defined on their GitHub/Website.

By accessing and using our Bug Bounty Platform, you agree to abide by these eligibility requirements. Failure to meet any of the specified criteria may result in disqualification from participation in the program. We appreciate your commitment to ensuring compliance with all relevant laws and regulations to promote a safe and responsible bug hunting environment.

We appreciate your understanding and compliance with these additional terms.

Contact

We do not accept vulnerability disclosures over e-mail, but we encourage security researchers to contact us if they require any support or help in the process. Our team can be contacted at support@huntr.com. We look to respond to support queries as soon as possible.