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

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

• Email: security@huggingface.co, and cc gradio-team@huggingface.co.

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

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 would like to be credited (name or handle).

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, proof of concept, or impact are returned as incomplete and are not investigated until provided.

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

### Affected version / commit
Exact released version or commit SHA you reproduced on (for example,
`trackio==X.Y.Z` / `a1b2c3d`). Not "latest" or "main".

### Affected component
The public API, module, dashboard route, or CLI entry point involved (for
example, `trackio.init`, `trackio.show`, `Artifact.download`, or `trackio sync`).

### Vulnerability class
Type and CWE if known (for example, path traversal / CWE-22 or cross-site
scripting / CWE-79).

### Attack vector & preconditions
- How is the vulnerable code reached? Which API call, dashboard route, input,
  command, or configuration is involved?
- Who is the attacker, and what do they control?
- What must be true for the attack to work? Consider authentication, network
  exposure, user interaction, non-default settings, remote Spaces or servers,
  artifacts, references, and custom frontends.

### Proof of concept
A minimal, self-contained script, dashboard setup, or step sequence that runs
on a clean install of the version above. Include:
- the exact commands and code to run,
- any input files needed (attach them or provide a script that generates them),
- the expected behavior and 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 below does this cross? If your finding touches anything in
the "Out of scope" list, name the item and explain why the behavior nonetheless
violates a guarantee Trackio makes.

### 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. Reports that are theoretical, auto-generated by a scanner or LLM, or that restate documented behavior will be closed without detailed review.

Understanding these boundaries saves everyone time — most reports we close as not vulnerabilities fall inside one of them.

Training and application code is trusted. Trackio runs inside code supplied by the user and records the values that code passes to it. It does not sandbox training scripts, callbacks, integrations, custom media processing, or other application logic. Code that reads local files, makes network requests, runs commands, or logs sensitive information is application behavior, not a vulnerability in Trackio. A Trackio protection being bypassed by untrusted input is in scope.

Experiment data may be sensitive. Metrics, configuration, traces, media, alerts, artifacts, commands, and captured logbook output can contain source code, paths, prompts, credentials, or other private information. The user is responsible for deciding what to record and where to publish it. Trackio must not disclose data outside the local project, Space, bucket, dataset, server, or webhook destination the user selected.

Publishing or exposing a dashboard is a deployment decision. A Space is public unless it or its organization is configured private. Static Trackio Spaces contain public snapshot data and do not support private=True. Likewise, trackio.show(host="0.0.0.0"), a share link, or another publicly reachable deployment lets other people view the data the deployment exposes. This is not an authentication boundary unless Trackio documents one for that mode.

Write tokens are secrets. A self-hosted dashboard's write-access URL and TRACKIO_WRITE_TOKEN authorize ingestion, uploads, and supported write operations. Anyone who obtains a valid token may perform those operations. Leaking a token in application logs, shell history, a public Space, or a URL shared by the user is outside Trackio's control. Trackio exposing, accepting, or mixing up tokens contrary to its documented behavior is in scope.

Artifacts and references are trust decisions. Files added to an artifact are intentionally read and stored. Calling Artifact.download() intentionally writes artifact contents to disk and fetches external URIs recorded through add_reference. Custom reference handlers are trusted code. A malicious remote artifact escaping the selected download directory, writing undeclared files, or executing code without an explicit user action is in scope.

Operator and customization tools are trusted. trackio logbook run executes the command supplied by the operator; it is not a sandbox. A custom frontend can execute its own browser code, and a configured webhook receives the alert data Trackio sends it. Command execution, custom frontend behavior, and delivery to an explicitly configured webhook are expected.

Remote Trackio deployments are separate trust domains. When a client, sync command, or CLI query connects to a remote Space or self-hosted Trackio server, treat that deployment and the content it returns as untrusted. Incorrect or malicious experiment data from that deployment is not a Trackio vulnerability. A remote response that causes Trackio to execute code, escape an intended local directory, or disclose unrelated local data without an explicit user decision is in scope.

We treat as vulnerabilities issues in the published Trackio package and bundled dashboard code that an attacker can trigger without the user opting into a documented risk. Examples include:

• code execution, path traversal, unauthorized file access, or server-side request forgery reachable through normal Trackio APIs, dashboard routes, or remote responses;
• cross-site scripting or cross-user browser access caused by untrusted logged values in the bundled dashboard;
• bypasses of write-token validation, read-only SQL enforcement, project or run isolation, artifact path validation, or other protections Trackio documents;
• exposure or mishandling of Hugging Face tokens, Trackio write tokens, webhook credentials, artifact contents, or another user's experiment data;
• unintended local file writes, local data disclosure, or code execution caused by a malicious remote Space, server, artifact manifest, or logbook;
• remotely triggerable denial of service with concrete impact on a realistic shared or multi-tenant deployment; and
• CI/CD or supply-chain issues in this repository.

The following are not treated as vulnerabilities in Trackio. If your finding touches one of these, the report must explain why it nonetheless violates a guarantee Trackio makes; otherwise, it will be closed.

• Unsafe or malicious behavior implemented by the user's own training code, callbacks, integrations, media tools, custom reference handlers, or custom frontend.
• Execution of a command the operator explicitly passed to trackio logbook run.
• Access to an intentionally public Space, static snapshot, share link, or self-hosted dashboard, absent a bypass of a documented Trackio control.
• Data or files the user explicitly logged, published, synchronized, uploaded, downloaded, or sent to a configured webhook destination.
• Network access and file writes explicitly requested by downloading artifact references or using a custom reference handler.
• Incorrect, unsafe, or malicious model output, including jailbreaks, prompt injection, harmful generations, and behavior controlled by a model or remote training application rather than Trackio.
• Findings in examples, documentation, tests, or other non-packaged reference material.
• Local denial of service from pathological input on your own machine, absent a shared, multi-tenant, or remotely reachable impact.
• Vulnerabilities in third-party dependencies we do not vendor. Report these upstream; we will upgrade once a fix is available.
• Theoretical issues without a working proof of concept, and reports generated by scanners or LLMs without a verified, reproducible chain.
• Best-practice or hardening suggestions without demonstrated impact, including missing email-authentication records, missing HTTP security headers, TLS preferences, and similar scanner or configuration-checker output.
• Issues that reproduce only on an unsupported older release and do not reproduce on the current release.

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 is not yours, and do not run tests against Hugging Face production infrastructure.