Security
QWED is a security boundary, so its own security is handled in the open. Here are the answers a security or procurement review asks for, the project’s track record, and how to report a vulnerability.
For security and procurement reviews
- Where it runs
- In your environment, as a Python library, a CLI, a self-hosted API or a Docker image. The exception is QWED Security: a GitHub App hosted on Google Cloud (Cloud Run), which processes the webhook and API traffic needed to scan a pull request.
- What leaves your systems
- Nothing is sent by QWED itself. Checks that start from natural language send a prompt to the model provider you configure; with a model you host, nothing leaves your infrastructure.
- What decides
- Deterministic engines such as SymPy, Z3, SQLGlot and AST analysis. The model never approves its own output: it only translates natural language, and that translation is not itself verified.
- Separation of duties
- The model proposes, QWED checks, and your system enforces the decision. QWED returns ADMIT or DENY; your integration acts on it, or a QWED product does, as QWED Security does by failing the pull request check.
- Evidence you keep
- Every result carries its status and admission decision. A VERIFIED result carries a proof_ref, a SHA-256 commitment to its evidence. Verification Context v1.0 is the open format for keeping a result as a record. The specification
- Versions and fixes
- Security fixes ship for the latest release only (qwed 7.3.x today). Every fixed vulnerability is published with its affected and fixed versions. Latest advisories
- Continuity
- QWED has a single maintainer, and no backup maintainer has been appointed yet. What exists for continuity
- Licence and limits
- Apache-2.0, for every package. What QWED does not check is written down, package by package. What QWED does not verify
QWED is designed for environments where human oversight and an audit trail are required. It does not, by itself, make a system compliant with any regulation.
Track record
Counted at every build from the published advisories on GitHub and the release history on PyPI.
- 22advisories published, across 6 packages
- 21 of 22fixed in a released version
- 6reported by outside researchers, 6 credited by name
- 22releases in the last 90 days, across all packages
No fixed version yet for @qwed-ai/legal = 1.0.0 (GHSA-mrv2-8596-cx34).
What went wrong
- 6A check returned VERIFIED for a claim that was false
- 5A guard let through something it should have stopped
- 5Untrusted input could run code
- 1Untrusted input could exhaust compute
- 5Not yet sorted
The first two are the failures that matter most for a verification project, so they are counted on their own rather than left inside the list. Each advisory explains the cause and the fix. The proof engines are also tested at every release on claims with a known answer: the latest results.
Latest advisories
Every fixed vulnerability is published as a GitHub security advisory on the affected repository, and listed here.
- 16 Oct 2026Stats and consensus sandbox static gates can be bypassed to reach blocked primitives (incomplete fix of #336 / GHSA-6rxr-gq43-694g)high
- 16 Oct 2026CodeVerifier certifies command-execution, file-access and exfiltration code as VERIFIED/ADMIT (incomplete fix of GHSA-6rxr-gq43-694g)high
- 16 Oct 2026SQLVerifier admits credential-dumping and tautology-injection queries (SELECT * bypasses the sensitive-column denylist; tautology check matches exact shapes only)medium
- 16 Oct 2026SQLVerifier certifies destructive and administrative SQL as VERIFIED/ADMIT (DML hidden in CTEs; incomplete statement-type denylist)high
- 16 Oct 2026DSLLogicVerifier NL->DSL bridge returns VERIFIED for contradictory or altered constraints (incomplete fix of GHSA-mfh5-3c8f-975p)medium
Report a vulnerability
Please don’t report vulnerabilities in public issues, pull requests or discussions. Use one of these private channels:
Include as much as you can:
- Steps to reproduce
- Affected versions
- Relevant code, configuration, logs or screenshots
- A proof of concept, if you have one
- The impact on confidentiality, integrity or availability
What happens next
- AcknowledgedWe aim to reply within 3 business days. QWED has a single maintainer, so it may occasionally take longer.
- TriagedThe report is reproduced and validated as quickly as possible.
- FixedYou are kept informed while it is investigated and fixed.
- PublishedDisclosure timing is agreed with you, then the advisory is published with the fix.
Coordinated disclosure
Please allow reasonable time to investigate and fix the issue before you disclose it. In particular:
- Don’t disclose publicly until a fix or mitigation is available.
- Make a good-faith effort to avoid privacy violations, data destruction and service disruption.
- Don’t access, change or take data beyond what you need to demonstrate the issue.
Supported versions
| qwed version | Security fixes |
|---|---|
| 7.3.x (latest release) | Supported |
| < 7.3 | Not supported. Please upgrade. |
Security fixes are released for the latest version only.
Security issue or bug?
Security issue
Compromises confidentiality, integrity or availability: code execution, injection, auth bypass, privilege escalation, sensitive data exposure, sandbox escape, or a check that fails open.
Report it privately.
Bug
A defect with no security impact, such as a wrong calculation, a documentation problem or a crash that can’t be exploited.
Report it on the issue tracker.
How releases are protected
- Every QWED package on PyPI is published through PyPI Trusted Publishing, with build provenance attestations.
- Two-factor authentication is enforced for the whole QWED-AI organisation on GitHub, and required for anyone with write access to PyPI or Docker Hub.
- QWED Security is installed across the QWED-AI organisation and checks pull requests before they merge.
Credit
Reporters who disclose responsibly are credited publicly in advisories and release notes, unless they ask to stay anonymous. Everyone credited so far is listed on the community page.