Security advisories

This page is the public record of security vulnerabilities disclosed in OpaqueVault components. Every entry links to the canonical GitHub Security Advisory (GHSA) and includes commands you can run yourself to verify both the vulnerability and its resolution — trust the proof, not the prose.

To report a vulnerability, see the security policy of the affected repo (e.g. opaquev/ov-scan-action/SECURITY.md).

---

GHSA-59j2-rc8j-4q5w — ov-scan-action v1.0.0 auto-loads a forgeable in-repo baseline

Published: 2026-08-17 · Severity: High (CVSS 3.1 score 7.7) · Affected: ov-scan-action v1.0.0 only · Patched: v1.0.1 and later

Canonical advisory: GHSA-59j2-rc8j-4q5w

What the vulnerability was

ov-scan-action v1.0.0 defaulted the baseline-file input to .ovscan-baseline.txt and passed --baseline to ov scan unconditionally — auto-loading a baseline file from the repository checkout on every run.

The baseline’s HMAC key offers no protection here: ov scan reads it from a sibling .ovscan-baseline-key file in the same checkout. The key is a random per-repo value and gitignored by default — but nothing stops a pull request from committing one, and because the verification key travels with the data it is supposed to authenticate, baseline fingerprints are forgeable entirely offline. A malicious pull request could commit a leaked secret, a poisoned baseline whose forged fingerprint matched the planted finding, and the matching key file. The finding would then be excluded from the fail-on breach evaluation, and CI would go green over a live leaked secret. Neither the allow-ci-baseline gate nor fork-PR strict mode caught this in v1.0.0, because both key on the input flag being set — not on a baseline file appearing in the diff.

Timeline

When (UTC)	What
2026-05-06 22:01	v1.0.0 released with the vulnerable default.
2026-05-06 23:20	v1.0.1 released — 79 minutes later. The smoke suite failed on its very first run against v1.0.0 (repos without a baseline file errored), and the fix changed the default to empty: --baseline is passed only when the user explicitly sets it. This removed the vulnerable behavior, though at the time it was classified as a first-run UX bug, not a security issue.
2026-08-17	A security audit of the baseline design re-classified the v1.0.0 default as a vulnerability (forgeable auto-loaded baseline → findings suppression), confirmed v1.0.1 and v1.0.2 already ship the safe default, and published GHSA-59j2-rc8j-4q5w the same day.

Are you affected?

You are affected if your workflow pins opaquev/ov-scan-action at:

• the tag @v1.0.0, or
• the commit SHA c1b559d4310a140e27306ed2d73ec90621b0954d (v1.0.0’s commit).

Every other released version — v1.0.1, v1.0.2, v1.0.3 — defaults baseline-file to empty and is not affected by default. Remediation: bump your pin to the current release (v1.0.3, commit 20f4875e4641fcaa34fc2403d8dfaab13669fd8e). If you cannot bump immediately, set baseline-file: '' explicitly in your with: block to disable baseline loading on v1.0.0.

On any version

Explicitly configuring baseline-file re-opens the same trust question on every version, because the baseline’s verification key is read from the same checkout as the baseline itself. Treat an in-repo baseline (and its .ovscan-baseline-key sibling) as trusted input: do not honor baseline files added or modified by untrusted pull requests.

Proof — verify it yourself

The action repo is public; none of this requires trusting us.

1. The vulnerable default exists in v1.0.0 and is gone in v1.0.1. Diff the two tags:

git clone https://github.com/opaquev/ov-scan-action.git
cd ov-scan-action
git diff v1.0.0 v1.0.1 -- entrypoint.sh

The fix is this hunk (plus making the baseline validation/--baseline flag conditional):

INPUT_BASELINE_FILE="${INPUT_BASELINE_FILE:-.ovscan-baseline.txt}"
INPUT_BASELINE_FILE="${INPUT_BASELINE_FILE:-}"   # empty = skip --baseline (smoke caught the broken default 2026-05-06)

2. The tag↔SHA mapping. Confirm which commits the tags point at, straight from GitHub:

git ls-remote https://github.com/opaquev/ov-scan-action \
  'refs/tags/v1.0.0^{}' 'refs/tags/v1.0.1^{}' 'refs/tags/v1.0.3^{}'
# v1.0.0 → c1b559d4310a140e27306ed2d73ec90621b0954d  (vulnerable)
# v1.0.1 → e91af746370e5e4b6a53e3a9a3675243cf1cbcb4  (patched)
# v1.0.3 → 20f4875e4641fcaa34fc2403d8dfaab13669fd8e  (current)

3. The release timestamps (the 79-minute exposure window):

gh release view v1.0.0 --repo opaquev/ov-scan-action --json publishedAt
# 2026-05-06T22:01:17Z
gh release view v1.0.1 --repo opaquev/ov-scan-action --json publishedAt
# 2026-05-06T23:20:48Z

4. The canonical advisory record, machine-readable:

gh api repos/opaquev/ov-scan-action/security-advisories/GHSA-59j2-rc8j-4q5w \
  --jq '{severity, cvss: .cvss.vector_string, vulnerabilities}'

5. Current behavior is continuously tested. The smoke suite runs daily against both the floating @v1 tag and the current release’s SHA pin on clean and dirty fixture repos — the same suite whose first run flagged the v1.0.0 default within 79 minutes of release. Its live status badge is at the top of the action README.

Related reading

• ov scan in GitHub Actions — pinning guidance and the action’s security model
• CHANGELOG — per-version record, including the v1.0.1 fix entry
• Action threat model