cca_checks — the deterministic verification layer behind the fp-check gate — executes code from the repository under audit. This is not an edge case; it is the mechanism the package exists to provide. Concretely:

• repro_runner.py and property_check.py both invoke pytest as a subprocess (python -m pytest) against paths inside the audited repo. pytest imports conftest.py at collection time, before any test selection happens. Pointing this tool at an untrusted repository executes that repository's conftest.py — and anything it imports — with your privileges and in your environment. There is no sandboxing at this layer; the subprocess inherits the calling user's filesystem access, environment variables, and network reachability.
• substrate.py runs the audited target three times — float64, a 50-digit mpmath reference, then float64 again to screen for output-changing state — and monkeypatches the target module's math bindings during the reference call. It also installs a temporary profile hook in the current thread to detect native conversion of an mpf. Complex arithmetic, cmath, worker threads, and side effects are not supported. The module is explicitly documented as not thread-safe.
• Hunt mode (/audit-fix hunt <paths>) is designed to be pointed at code you did not write — an OSS dependency, a repo you're evaluating, a legacy service. That is exactly the untrusted case above, by design, not by accident.
• pyright_check.py and semgrep_check.py shell out to external binaries resolved against the audited repo's working directory and can read the audited repo's own tool config (pyrightconfig.json, .semgrepignore, # nosemgrep). The DEEP self-audit (2026-07-22, fixed in the commits merged via PRs #18–#20) hardened several of these — explicit PATH resolution instead of bare-name lookup, a generated pyright config that ignores the audited repo's own typeCheckingMode/# type: ignore overrides, --disable-nosem/--no-git-ignore for semgrep — because the audited repo's own configuration is adversarial input, not trusted context.

The documented mitigation is a sandbox: run the pipeline against untrusted or third-party code inside a container, under seccomp, or in a scrubbed, offline, disposable environment — never directly on a machine holding credentials, SSH keys, or access to systems you care about. This is stated in the module docstrings of repro_runner.py, property_check.py, and substrate.py themselves; this file exists so it is stated somewhere a security reviewer looks first, too.

The current release and current master are supported. Older release lines do not receive guaranteed backports; upgrade before reporting a problem already fixed on master. The DEEP self-audit changes merged through PRs #18–#20 and #22 fixed security-relevant defects that were not backported to earlier releases.

Use GitHub Security Advisories on this repository to report privately. If you'd rather not use Advisories, open a regular GitHub issue and state that it's security-sensitive — this project does not yet have a dedicated inbox separate from GitHub, and I'd rather point you at the real channel than invent one.

Response time: best effort. This is a solo-maintained project, not a team with an on-call rotation. I will not promise an SLA I can't honor — I'll acknowledge and look at reports as soon as I reasonably can, but there is no guaranteed turnaround.

The tool executing the audited repository's code is documented, intended behavior — not a vulnerability. Please don't file "the auditor ran my conftest.py" or "the substrate checker imported my module and mutated its globals" as a security report; both are covered above and are the mechanism, not a bug in it. If you find a way the tool executes code it should refuse to run (e.g., a bypass of the target-viability pre-flight, or execution triggered without any of the documented pytest/subprocess paths above), that is in scope — please report it.

Also out of scope: vulnerabilities in third-party tools this project shells out to (pyright, semgrep, pytest, hypothesis, mpmath) — report those upstream. This project's own use of them (config injection, argv[0] resolution, etc.) is in scope.