Security & responsible disclosure.
An offensive-security tool has to earn trust before it earns adoption. Here is how Provael handles data, and how to report a vulnerability.
Data handling
- 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.
Software supply-chain posture
- Apache-2.0, public on GitHub, inspectable end to end.
- An SBOM is published with each release.
- Releases publish to PyPI via OIDC trusted publishing (no stored tokens); build provenance is generated in CI.
- A coordinated vulnerability-disclosure policy lives in the repository.
- Supported version: the latest release on PyPI (currently v0.41.2). Please reproduce on the current version before reporting.
Dependency advisories
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. We name it here because trust means disclosing the dependencies, not hiding them.
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.
The part worth recording is what happened next. We filed openpi#1039 on 5 September. On 11 September a contributor we have never met opened PR #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, which proposes a serving-layer probe family and states it must stay out of the attack-success denominator.
Reporting a vulnerability
Please report security issues privately. Do not open a public issue for a vulnerability.
- Email hello@provael.com.
- Or open a private advisory at github.com/provael/provael/security/advisories.
- Our machine-readable policy is at /.well-known/security.txt (RFC 9116).
We aim to acknowledge reports within 3 business days and follow a 90-day coordinated-disclosure window - we confirm the issue, work a fix, and coordinate public disclosure with credit within 90 days (sooner if a fix ships earlier). Provael is an offensive-security tool - please test only systems you own or are explicitly permitted to assess.
Scope
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.
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.