Security reports
Email suspected vulnerabilities to hello@cex.app with the subject “CEX security report.” Do not open a public issue or post exploit details in a community channel before the problem has been reviewed.
This project cannot currently promise a reward, a formal safe-harbor program, or a fixed response deadline. Good-faith, non-destructive reporting is still appreciated.
What to include
- CEX version and operating system.
- A concise description of the impact and affected component.
- Reproduction steps or a minimal proof of concept.
- Relevant redacted logs, screenshots, or file names.
- Any temporary mitigation you found.
Do not include live credentials, access tokens, private user data, or destructive payloads.
The corrected Linux beta is pending
The former local installer candidates are not available through the public download route. Fresh x86_64 Linux artifacts must be rebuilt with the proprietary CEX terms and complete third-party notices, then pass the release-integrity gates before downloads reopen.
Reports against unreleased local development builds are still useful when they identify a problem in the same product path. Third-party model servers, providers, and connected services maintain their own security programs; a CEX integration or permission-boundary problem remains in scope even when the outside service itself does not.
What a public release must provide
A CEX download is not considered verified merely because it builds. The release page must publish the size and SHA-256 digest of each immutable artifact, a cryptographic signature with verification instructions, the applicable CEX terms and third-party notices, and the result of a malware scan performed on that same file.
Checksums detect a changed file but do not identify who produced it. The signature and its public verification path establish publisher provenance. CEX will not label an installer verified until both are available and reproducible.
The wrapper retains an explicit local diagnostic setting for an unsandboxed AppImage rendering workaround, but it is off by default. A public package must render and pass desktop regression tests with Chromium's operating-system sandbox intact, or the affected package format must remain unavailable.
Security-relevant boundaries
The desktop wrapper starts the local Python gateway and interface shell on loopback addresses. Model serving is separate in this beta. The wrapper isolates the interface from Node.js, rejects untrusted navigation and permissions, validates privileged IPC callers, and applies a restrictive browser content policy. Outward tools and connectors can require explicit approval based on the configured policy.
Those boundaries reduce accidental exposure; they do not make the beta suitable for unattended use with valuable credentials. Review permissions, keep dependencies updated, and use test accounts while evaluating high-impact connectors.
Updated August 13, 2026