# Security Policy

## Supported Versions

We ship security fixes in the latest release. Please reproduce on the current released version before reporting — we do not backport fixes to older releases.

## Reporting a Vulnerability

Report privately — **do not open a public issue or PR for a suspected vulnerability.**

- **Preferred:** GitHub private vulnerability reporting — the **"Report a vulnerability"** button under this repo's **Security** tab. This routes to the maintainers, keeps the report private until a fix is ready, and lets us issue a CVE through GitHub if warranted.
- **Email:** security@huggingface.co

We acknowledge valid, in-scope reports and will keep you updated on remediation. Please give us a reasonable window to fix before any public disclosure.

## Recognition

We do not offer a monetary bounty. For a valid, in-scope report we credit you on the published GitHub Security Advisory and name you as the reporter in the associated CVE. Let us know how you'd like to be credited (name or handle).

## What your report must include

We receive a high volume of reports. To be triaged, a report **must** follow the structure below. Copy this block into your submission and fill in every field. Reports missing the version, the proof of concept, or the impact are returned as incomplete and are not investigated until provided.

```markdown
### Summary
One sentence: what the vulnerability is and where.

### Affected version / commit
Exact released version or commit SHA you reproduced on (e.g. v4.57.0 / a1b2c3d).
Not "latest" or "main".

### Affected component
The public API, module, or entry point involved (e.g. `AutoModel.from_pretrained`).

### Vulnerability class
Type and CWE if known (e.g. deserialization / CWE-502, path traversal / CWE-22).

### Attack vector & preconditions
- How is the vulnerable code reached? (which API call / input / config)
- Who is the attacker and what do they control?
- What must be true for the attack to work? (auth, a user action, a non-default
  setting, a malicious file being loaded, etc.)

### Proof of concept
A minimal, self-contained script or step sequence that runs on a clean install
of the version above. Include:
- the exact commands / code to run,
- any input files needed (attach them, or give a script that generates them),
- the **expected** behavior vs. the **actual** behavior you observed.
A snippet showing that a function *exists* or *could* be misused is not a PoC.

### Impact
What an attacker gains in a realistic deployment. "Could theoretically…"
without a working chain is not an impact.

### Scope
Which trust boundary (see below) does this cross? If your finding touches
anything in the "Out of scope" list, name which item and explain why it is
nonetheless a violation of a guarantee we make.

### Suggested severity (optional)
We assign the final severity. Include a CVSS v3.1 vector only if you have one.

### Suggested fix (optional)
```

> The bar is a **reproducible PoC against a supported version, with a concrete impact that crosses a trust boundary we actually defend** (see scope below). Reports that are theoretical, auto-generated by a scanner or LLM, or that restate documented behavior will be closed without detailed review.

## Threat model & trust boundaries

Understanding these saves everyone time — most of what we close as not-a-vulnerability falls inside one of them.

**Loading artifacts you did not create is a trust decision.** Models, datasets, tokenizers, and configuration files can carry code or instructions that run when loaded. That a maliciously crafted artifact can execute code, read local files, or otherwise act when you load it is the **documented risk of loading untrusted content** — not a vulnerability in this library. Protect yourself by:
- preferring the `safetensors` format over pickle-based formats,
- pinning a specific, reviewed revision,
- enabling remote-code execution (e.g. `trust_remote_code=True`) only for repositories you have inspected.

We *will* treat as a vulnerability anything that breaks one of these protections — e.g. code executing despite `safetensors`-only loading, or a pinned revision being bypassed.

**Conversion, CLI, and developer utilities are operator tools.** Scripts you run yourself against inputs you chose (format converters, training/utility CLIs, dev helpers) are not a library API attack surface. Behaviors such as a script deserializing a file you pointed it at are within the operator's trust.

**Sandboxed execution environments run model-produced actions; isolation is the backend's responsibility.** Some training features let the model under training execute actions inside a sandboxed execution environment you configure. Executing those actions is the purpose of the environment; keeping them isolated from your host and other workloads is the configured sandbox backend's responsibility. Running such a feature without a real sandbox backend, or via a local non-isolating path, is not a security boundary and is out of scope. A genuine escape from a properly configured sandbox backend is in scope.

## In scope

We treat as vulnerabilities issues in the **published package code** — the library's own API surface — that an attacker can trigger without the victim having opted into a documented risk. For example:

- code execution, memory corruption, or file access reachable through a normal API call on input that is **not** an untrusted model/artifact the user chose to load;
- a control we advertise being bypassed (e.g. code running despite `safetensors`-only loading, or a pinned revision being ignored);
- exposure or mishandling of credentials, tokens, or another user's data by the library;
- a real escape from a backend we **document as a sandbox** (see trust boundaries);
- CI/CD or supply-chain issues in this repository.

## Out of scope

The following are **not** treated as vulnerabilities. If your finding touches one of these, the report must explain why it is nonetheless a violation of a guarantee we make — otherwise it will be closed.

- Issues that require loading an untrusted artifact and amount to the documented load-time risk above (code execution / file access on load of a malicious model, dataset, config, or pickle).
- Findings in `examples/`, documentation, tests, or other non-packaged reference material. These are out of scope for private security advisories (GHSA/CVE), but valid security issues should still be reported through the normal issue/PR process.
- Local denial-of-service from feeding pathological input to a function on your own machine (high memory, slow parse, panic), absent a multi-tenant or remote-service impact.
- The generation / weight-sync server you run for online training (`trl vllm-serve`) is training-cluster infrastructure you deploy and network-isolate yourself, not a hardened public service. Its reachability or availability on a network you chose to expose is a deployment concern, not a library vulnerability — absent a genuine cross-tenant or isolation break.
- Model behavior: jailbreaks, alignment failures, prompt injection, or harmful generations. Model weights are authored by their uploaders; report these to the model owner.
- Vulnerabilities in third-party dependencies we do not vendor — report upstream (we'll bump once fixed).
- Theoretical issues without a working proof of concept, and reports auto-generated from scanners or LLMs without a verified, reproducible chain.
- Best-practice or hardening suggestions with no demonstrated impact — missing email-authentication or transport records (MTA-STS, TLS-RPT, DMARC/SPF tuning), missing HTTP security headers, TLS configuration preferences, and similar scanner or config-checker output presented without a working exploit chain.

## Safe harbor

Good-faith research that respects these guidelines, avoids privacy violations and service disruption, and gives us a reasonable disclosure window will not be pursued by us. Do not access data that isn't yours and do not run tests against Hugging Face production infrastructure.

