This project is in early development. Only the latest main branch receives security fixes. Once a 1.0 release is cut, we'll publish a support table here.
| Version | Supported |
|---|---|
| main | ✅ |
| tagged releases | ✅ (latest two minor versions) |
| older | ❌ |
Do NOT file a public GitHub issue for security vulnerabilities.
Instead, email reza.ebrahimi.dev@gmail.com with:
- A description of the vulnerability and its impact.
- Steps to reproduce (a minimal reproducer is ideal).
- Affected component (
quark-server,quark-runtime,quark-cli,quark-catalog, orquark-nodes) and version. - Any suggested fixes or mitigations.
You should receive an acknowledgment within 48 hours. If you don't, please follow up to confirm we received the original report — email can get filtered.
We will coordinate disclosure with you and credit your report in the release notes unless you prefer to remain anonymous.
- Day 0: We receive the report and confirm receipt within 48 hours.
- Day 0–7: We reproduce the issue and assess severity.
- Day 7–30: A fix is developed on a private branch.
- Day 30: The fix is released and the vulnerability is disclosed publicly with credit to the reporter (unless anonymity is requested).
Critical vulnerabilities may be fixed and disclosed faster. Lower-severity issues may sit longer if a fix would require a breaking change.
This security policy applies to all five components of the Quark platform: quark-server, quark-runtime, quark-cli, quark-catalog, and quark-nodes.
- Authentication or authorization bypass in the control plane REST API.
- Authentication or authorization bypass in NATS subject routing (cross-tenant data leakage).
- Remote code execution via the data plane (e.g. via GraalJS sandbox escape, native node execution, or malicious
.quark.tssource). - Deserialization vulnerabilities in any component.
- Memory safety issues in the Java runtime or Go binaries.
- SQL injection in the Catalog's SQLite layer.
- Supply-chain risks (compromised dependencies, malicious publish artifacts).
- Vulnerabilities in NATS server itself — report to nats-io/nats-server.
- Vulnerabilities in GraalVM, Quarkus, or other upstream Java libraries — report upstream.
- Vulnerabilities in the Go standard library or Fiber / nats.go / zap — report upstream.
- Social engineering attacks against maintainers or users.
- Theoretical timing attacks without a demonstrated exploit.
- Denial of service via resource exhaustion on the NATS broker (mitigate at the broker level).
When deploying Quark in production:
- Secure the NATS broker. Use TLS for NATS connections (
tls://orwss://). Configure NATS account credentials so each tenant has isolated subject namespaces. The platform's multi-tenant model relies on NATS subject isolation; do not run with anonymous NATS access in production. - Restrict the control plane REST API. Bind
quark-serverto a private network or put it behind an authenticated reverse proxy. The REST API has no built-in auth — it assumes a trusted network. - Validate
.quark.tssource before deploy. The data plane evaluates TypeScript via GraalJS with ESM. While GraalJS is sandboxed by default, do not deploy untrusted.quark.tsfiles without code review. - Restrict Catalog SQLite access. The Catalog uses
modernc.org/sqlite(pure Go, no CGO). The database file should be on a filesystem with appropriate permissions; the Catalog process should run as a non-root user. - Pin container images by digest. When deploying via Docker, pin to a specific image digest, not just a tag.
- Monitor NATS subjects. Set up NATS streaming / JetStream observability so you can detect unusual subject activity (e.g. a tenant trying to subscribe to another tenant's subjects).
┌─────────────────────────────────────────────┐
│ Trusted zone (your deployment) │
Operator ────┤ │
│ quark-server (no built-in auth) │
│ quark-runtime (GraalJS sandbox) │
│ quark-catalog (SQLite, no remote access) │
│ NATS broker (must be TLS + auth) │
└─────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ Untrusted zone │
│ .quark.ts source files (review before │
│ deploy — GraalJS sandbox contains them but │
│ defense in depth is still recommended) │
│ Untrusted tenant workloads (rely on NATS │
│ subject isolation) │
└─────────────────────────────────────────────┘