# Security & vulnerability disclosure - Provael > Markdown twin of https://www.provael.com/security/ - derived mechanically from the page's own rendered content at > build time (it can state nothing the page does not). Curated, data-driven twins exist for the > key pages; this one is generated so the twin convention has no holes. SECURITY # How to report a vulnerability. Report security issues privately, never in a public issue. After the steps, this page covers how the tool handles your data and how its releases are built. ## Report it privately - Reproduce it on the latest release on PyPI (currently v0.46.0). Earlier releases are not supported. - Open a private advisory at [github.com/provael/provael/security/advisories](https://github.com/provael/provael/security/advisories/new), or email [hello@provael.com](mailto:hello@provael.com). Include the steps to reproduce, the affected version and the impact. - We aim to acknowledge reports within 3 business days, then confirm the issue, work a fix and coordinate public disclosure, with credit, within a 90-day coordinated-disclosure window (sooner if a fix ships earlier; longer only if more time is genuinely needed and agreed with you). The full policy is in the repository's [SECURITY.md](https://github.com/provael/provael/blob/main/SECURITY.md); the machine-readable policy is at [/.well-known/security.txt](https://www.provael.com/.well-known/security.txt) (RFC 9116). ## What to report here Vulnerabilities in Provael itself: the code, the package, and the CI and release pipeline. Test only systems you own or are explicitly permitted to assess. Safe harbour. If you make a good-faith effort to follow this policy - testing only against your own installation of Provael, avoiding privacy violations, data destruction, or disruption of others’ systems, and giving us reasonable time to remediate before any public disclosure - we consider your research authorized, and we will not pursue or support legal action against you for it. This safe harbour does not authorize testing systems you do not own, and it does not waive any third party’s rights. ## How the tool handles your data - Runs where your policy runs. Provael executes locally or in your CI. Policies, simulators, and traces do not leave your environment by default. - No telemetry. The tool does not phone home. There is no network egress by default. - You keep the data. Findings, traces, and reports are written to your filesystem. Assessment engagements run under a data-processing agreement. What crosses on each path, including this website's forms and a managed engagement, is on [/trust](https://www.provael.com/trust/#data-paths). ## Supply chain - Apache-2.0, public on GitHub, inspectable end to end. - A software bill of materials (SBOM) is published with each release. - Releases publish to PyPI via OIDC trusted publishing (no stored tokens); build provenance is generated in CI. ## Advisories in our dependencies These are advisories in optional dependencies, tracked for transparency - they are not vulnerabilities in Provael. For example, LeRobot’s unauthenticated pickle-deserialization RCE (CVE-2026-25874) affects its PolicyServer in lerobot 0.5.1. Provael pins that version behind an optional extra but never starts the PolicyServer or any network endpoint, so the vulnerable path is not reachable through Provael. ## Disclosures we have made upstream PVL-D-2026-001 — openpi policy server bound to all interfaces, with tracebacks returned to the client. Reported 5 September 2026, third-party fix proposed 11 September, open upstream. scripts/serve_policy.py in Physical-Intelligence’s openpi started the websocket policy server bound to0.0.0.0 with no flag to change it, and application exceptions were serialised back to the client as tracebacks. On a robot cell that means the inference host accepts policy queries from anything that can route to it, and returns internal file paths to whoever asks. We filed [openpi#1039](https://github.com/Physical-Intelligence/openpi/issues/1039) on 5 September. On 11 September a contributor we have never met opened [PR #1042](https://github.com/Physical-Intelligence/openpi/pull/1042) addressing it: four files, +140/-4, with tests. The fix is their work, not ours. We reviewed the diff and confirmed the compatibility claim holds, because the client already raises on a string frame rather than unpacking it, so returning a plain error string preserves the existing path. We disagreed with them about one thing and said so publicly: they offered to change the server constructor’s host default as well. We argued against it. The command line is where the unsafe default actually bit, library callers pass the host explicitly, and changing a public default is a breaking change that deserves its own change. Also observed and not yet filed: the same server disables the websockets frame cap, so an unauthenticated client can send an unbounded frame and the server buffers it. That is a different shape of problem and a disclosure decision rather than a code one, so it is recorded here rather than quietly folded into someone else’s pull request. Tracked on our side as [provael#229](https://github.com/provael/provael/issues/229), which proposes a serving-layer probe family and states it must stay out of the attack-success denominator. ## Publishing results about other people’s policies The right of reply. A result about a policy Provael did not train is sent to that policy’s authors 14 days before it is published, with the whole artifact rather than a heads-up: - the signed report and the board row derived from it; - the exact command, checkpoint revision, seeds, horizon and simulator versions; - the predicate (stated as uncalibrated where it is), the benign control and its rate on the same fixture; - the caveat paragraph in the wording we intend to publish. If they find an error we re-run and correct or withdraw before publication, with the correction recorded. If they disagree and we are not persuaded, both positions are published on the same page, theirs in their words. If they do not respond, we publish after the 14 days and the entry says notice was given and no response received; silence is not a veto. One reasoned extension is granted and noted; a second open-ended one is not. The 14 days start when the notice is sent. The rule is the product’s, in full at [docs.provael.com/latest/leaderboard-disclosure/](https://docs.provael.com/latest/leaderboard-disclosure/), and it binds this project more tightly than anyone submitting to the board. Measured language. Every number about someone else’s policy travels with the same things ours do: - the interval, including when it is embarrassingly wide; - the benign false-positive rate on the same fixture; - the one-policy-one-suite-one-predicate transfer caveat; - an explicit note where the keep-out predicate is uncalibrated. A null is published as a result at 0/n with the same prominence as a positive rate. The board carries no safety ranking, presents no result as a vulnerability (a genuine weakness in a deployed system goes through the disclosure path above instead), and prints nothing about another policy that would not survive being written about SmolVLA on our own /results. A published result that proves wrong is corrected in place with what was wrong and when it was found; nothing is silently edited, and a withdrawal leaves its notice behind. These are the rules the errata log and /results are already held to. ## What Provael tests Provael tests the policy - the model that turns instructions and perception into robot actions. Firmware and radio exploits - for example the UniPwn BLE attacks (CVE-2025-60250 / CVE-2025-60251) or the Unitree Go1 firmware vulnerability (CVE-2025-2894) - are out of scope; Provael does not claim to detect them. Report a vulnerability Open a private advisory on GitHub, or email [hello@provael.com](mailto:hello@provael.com). Reproduce on the latest release first. At a glance Version: v0.46.0 License: Apache-2.0 [Email security](mailto:hello@provael.com) [View the repo](https://github.com/provael/provael) --- Canonical: https://www.provael.com/security/