The VTX SDK processes binary .vtx replay files that are frequently user-supplied and untrusted — generated by third-party tooling, transmitted over the network, or loaded from local caches that could be tampered with. The reader and differ are therefore security boundaries, and we take vulnerabilities in them seriously.

VTX is pre-1.0. Security fixes land on main and are tagged in the next release. There are no backport branches.

Please do not open a public GitHub issue for anything that could be security-sensitive. Public issues tip off attackers before a fix is out.

Use one of:

1. GitHub Security Advisory (preferred): open a private report. Keeps the discussion, CVE assignment, and patch coordination in one place.
2. Email: vtx@zenosinteractive.com. PGP not required; if you want encryption, ask in your first message and we'll send a key out-of-band.

Please include, to the extent you're able:

• VTX version / commit SHA where you reproduced the issue.
• A minimal .vtx file, code snippet, or reproduction command. If the trigger is a malformed file, a hex dump or the shortest-possible crafted binary is ideal.
• What you observed (crash, hang, memory corruption, info disclosure, UB warning from a sanitizer) and, if you know, what you think the root cause is.
• Your platform: OS, compiler, CPU arch, build type (Release / Debug), whether sanitizers were on.

If you'd like attribution in the fix announcement, say so and give us the name / handle you want credited. We default to "reported by a third party" otherwise.

These are commitments, not aspirations. If we miss one, escalate via email to vtx@zenosinteractive.com with a subject prefix of [ESCALATION].

If a vulnerability is being actively exploited against VTX users, we'll compress the timeline and coordinate disclosure accordingly.

In scope (please report):

• Memory-safety bugs in the reader / differ: out-of-bounds reads/writes, use-after-free, double-free, stack overflow via recursion on adversarial input, integer overflow in size calculations, misaligned accesses crashing on strict-alignment architectures.
• Denial-of-service: pathological .vtx files that cause the reader to allocate unbounded memory, hang indefinitely, or consume CPU disproportionate to file size ("zip bomb"-class inputs).
• Data races / TOCTOU in the reader's async chunk prefetcher (vtx_reader.h's threading path) that could be triggered by a caller following the documented API.
• Logic bugs in the schema registry or property address cache that could be exploited to read or mutate memory the caller shouldn't be able to touch.
• Supply-chain: unexpected network access, writes outside the configured output path, or shell execution in any SDK, tool, or sample code path.
• Vulnerabilities introduced by how we ship or build third-party components (thirdparty/*, CMake FetchContent pins).

Out of scope (not a vulnerability):

• Crashes on files the SDK has explicitly rejected (e.g. the reader returns an error, then the caller uses a null pointer without checking — that's a caller bug).
• Known upstream issues in third-party libraries we ship at their advertised versions. If the upstream has a fix and we haven't picked it up, that's a dependency-update request rather than a VTX vulnerability — but tell us anyway, especially if the upstream fix is tagged with a CVE.
• Theoretical weaknesses in the on-disk format design (e.g. "the checksum isn't cryptographic") without a concrete exploitation path that breaks a documented security property. Documentation updates welcome; not treated as a vulnerability.
• Findings that only reproduce with modifications to the SDK source, non-default CMake options intended for development (e.g. VTX_SANITIZE), or caller code that violates the documented API contract.
• Social engineering, physical access, or compromise of a user's machine.

If you're unsure whether something is in scope, report it privately anyway — we'll tell you honestly, and "better safe than sorry" is the right call.

• Don't access, modify, or exfiltrate data belonging to others.
• Don't run denial-of-service tests against infrastructure we operate.
• Give us a reasonable window to fix before public disclosure. "Reasonable" here means the timeline above; if a fix is blocked on something you can see us actively working on, we can agree on an extension.

• We won't pursue legal action against good-faith security research that follows this policy.
• We'll keep you in the loop on fix progress and won't release the advisory without giving you a chance to review the write-up.
• Credit in the advisory is yours to take or decline.