GenClass (@genclass/runtime and the model package @genclass/runtime-model) runs inside your web app: it wraps the page's network and timer APIs, reads application state and, when you opt in, changes how requests, responses and state writes proceed. We take reports about it seriously.

Please report security issues privately, not in public GitHub issues, discussions or pull requests.

• Email: mehar@daybot.ca
• GitHub: a private vulnerability report on the GenClass repository (Security → Report a vulnerability).

Include what you can of: the affected package and version (GenClass.runtime.status, or the version in package.json), how GenClass was installed (@genclass/runtime/auto, GenClass.init, the script tag), the mode (observe, guard, heal), a minimal page or steps that reproduce it, and the impact you see. Please do not test against sites you do not own, do not access other people's data, and give us a reasonable time to fix the issue before you disclose it.

What to expect:

There is no bug bounty programme at this time.

GenClass is pre-1.0. Security fixes go into the newest published version only; upgrade to receive them.

• the runtime library (packages/runtime/src), its zero-code entries (/auto, the script-tag build), the devtools overlay;
• the CLI (packages/runtime/bin: init, remove, login, connect, whoami, logout, fetch-model, info), including the session credentials login stores in ~/.config/genclass/credentials.json ($XDG_CONFIG_HOME/genclass/ when that is set to an absolute path; %APPDATA%\genclass\ on Windows; on macOS and Linux, file mode 600 in a directory with mode 700), and the app token and private dashboard link init saves in .genclass.local in the project (it makes sure git ignores that file, adding it to .gitignore when needed; the link is a secret: whoever holds it sees the app's dashboard);
• the model loader and host (integrity checks, Cache Storage, the worker);
• the telemetry client and the collector (telemetry-worker/), including anything that sends more than TELEMETRY.md says;
• a way to make GenClass act where its documentation says it never does (see INTERCEPTION.md, "What it never does"): for example changing a request's body, retrying a non-idempotent request without an idempotency key, acting on a requests.protect endpoint, acting in observe mode, or writing discovered React or Zustand state.

Out of scope: the model choosing a wrong action within what the documentation allows (that is a quality issue: please open a normal issue with the situation from rt.explain(id)), attacks that need script execution in the page (any page script already has the same access GenClass has; see the threat model), and denial of service against infrastructure we do not operate.

• docs/runtime/THREAT-MODEL.md: who could attack an app through GenClass, how, the mitigations in the code and the risks that remain.
• packages/runtime/INTERCEPTION.md: every API GenClass wraps or listens to, what each mode may change, the preconditions and undo of every action, and how disable() and ?genclass=off restore the page. A unit test keeps it in sync with the code.
• packages/runtime/TELEMETRY.md and PRIVACY.md: what leaves the page.
• Verifying a published tarball (below): how to check that a published tarball was built from this repository.
• Advisories: docs/security/. Latest: 2026-10, a link could raise the mode, fixed in 0.3.0-beta.2 and 0.2.3; the four further findings from the review of that fix (route look-alikes, an invalid mode, a stale sample bucket, aggressiveness level names) are fixed in 0.2.3 (npm's latest since 2026-10-28) and 0.3.0-beta.5 (beta, 2026-11-03).

Recommended for production: keep the default observe mode until you have looked at what GenClass reports for your app; set mode explicitly (a URL parameter can then only lower it); keep payment, checkout and sign-in endpoints observe-only with requests: { protect: protectPreset("payments", "auth") }; self-host the model and onnxruntime-web behind a Content-Security-Policy (README, "Content-Security-Policy and self-hosting"); review rt.audit().

Anyone can check a published version against this repository. For a version published by the release workflow (.github/workflows/release.yml, from a v* tag, with npm provenance):

# 1. registry signatures and the provenance attestation (in any project that installed it)
npm install @genclass/runtime@<version>
npm audit signatures                    # counts packages with verified registry signatures and verified attestations
npm view @genclass/runtime@<version> dist.attestations   # the provenance bundle URL
# npmjs.com shows "Built and signed on GitHub Actions" with links to the workflow run, the commit and release.yml

The provenance names the repository, the workflow file, the tag and the commit SHA the tarball was built from. To compare the contents with that commit yourself (any published version, also the hand-published ones):

V=<version>
mkdir -p /tmp/gc-verify && cd /tmp/gc-verify
npm pack @genclass/runtime@$V                       # the published tarball, byte for byte
npm view @genclass/runtime@$V dist.shasum dist.integrity gitHead
shasum -a 1 genclass-runtime-$V.tgz                 # equals dist.shasum
mkdir published && tar -xzf genclass-runtime-$V.tgz -C published
git clone https://github.com/genclass-dev/GenClass.git src && cd src
git checkout v$V                                    # or the commit in the provenance / gitHead
ONNXRUNTIME_NODE_INSTALL=skip npm ci --no-audit --no-fund
npm run build -w @genclass/runtime
cd packages/runtime && npm pack && mkdir ../../../rebuilt && tar -xzf genclass-runtime-$V.tgz -C ../../../rebuilt
cd /tmp/gc-verify && diff -r published/package rebuilt/package && echo "same files, same contents"