TavernKeeper Scan Report

Noineri/vibe_tavern

Commit 5c3bea0 Reviewed Aug 10, 2026

No material or immediate-danger concern was identified in this review.

This advisory report describes what the named tools and review process found at one exact commit. Unknown or unobserved behavior may still exist.

0 immediate danger 0 material 161 low

What this review found

No material or immediate-danger item was identified.

Minor cautions

zizmor reported unpinned-uses

Minor caution · medium confidence

The CI uses a short version number like @v4 for the download-artifact action instead of a specific commit hash. This is common but means the action could change unexpectedly. Since the workflow only downloads a test artifact and has limited permissions, the potential harm is small.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow references actions/download-artifact@v4, a mutable major version tag. If the action provider were compromised, a malicious update could execute arbitrary code in CI. However, the workflow runs with contents:read permissions only, no secrets, and on a public repository. The action is widely used and maintained by GitHub. No actual exploitation is demonstrated.

Impact: low · Exploitability: plausible

Developer action: Consider pinning actions/download-artifact to a full commit SHA for improved supply chain security.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:184

zizmor reported unpinned-uses

Minor caution · high confidence

This workflow uses a GitHub action without locking it to a specific version number, which over time could allow a fake update to sneak in, though it's unlikely and no actual problem is shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The actions/checkout action at line 267 uses a mutable major-version tag (@v5) instead of a pinned commit hash. If the v5 tag is reassigned in the future, a malicious version could replace the official action, potentially compromising the build supply chain. However, no evidence of such tampering exists, and GitHub provides protections for verified actions. This is a defense-in-depth weakness with low exploitability in practice.

Impact: low · Exploitability: unlikely

Developer action: Review the cited evidence and confirm the intended behavior.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:267

Dependency advisory GHSA-67mh-4wv8-2f99:pkg:100a52fb5850b2ff8a7f76c7 applies

Minor caution · medium confidence

The project uses an older version of esbuild during building. This is not a danger for users because the tool is not running when you use the app.

Technical evidence

Scanner reason: OSV-Scanner matched advisory GHSA-67mh-4wv8-2f99:pkg:100a52fb5850b2ff8a7f76c7 to a dependency declared by this repository.

Contextual assessment: esbuild 0.18.20 is a build-time dependency (used by drizzle-kit and bun-plugin-tailwind). No evidence of runtime usage or attacker-controlled input reaching this package. The advisory describes a code execution risk during processing of untrusted input, which does not apply in this local client build context.

Impact: low · Exploitability: unlikely

Developer action: Update esbuild to a patched version (0.24.2 or later) if the build toolchain is updated. No production impact.

Scanner: osv-scanner 2.4.0
Rule: GHSA-67mh-4wv8-2f99:pkg:100a52fb5850b2ff8a7f76c7
File role: production
Source: bun.lock

zizmor reported adhoc-packages

Minor caution · high confidence

The workflow upgrades npm to the very latest version instead of a specific one. If npm's 'latest' tag were ever hijacked, the build pipeline could be affected, but that's extremely unlikely and only affects the publisher's machine, not users.

Technical evidence

Scanner reason: zizmor matched workflow-security rule adhoc-packages in this repository.

Contextual assessment: Line 140 runs 'npm install -g npm@latest' which installs an unpinned version of npm from the registry. This updates the npm CLI to the latest version in the workflow runner. While this is done to satisfy trusted-publishing requirements and is normal CI practice, pinning to a specific npm version (e.g. 11.5.1+) would eliminate the small supply-chain risk of a compromised 'latest' tag. No actual compromise is demonstrated.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a specific npm version like 'npm install -g npm@11.5.1' to avoid relying on a mutable tag.

Scanner: zizmor 1.28.0
Rule: adhoc-packages
File role: tooling
Source: .github/workflows/release-npm.yml:140

zizmor reported unpinned-uses

Minor caution · high confidence

The workflow refers to a build tool action using a version tag (v4) instead of a fixed commit ID. If the action was tampered with, it could affect the build. This is a best-practice issue, not an active danger.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow uses `gradle/actions/setup-gradle@v4` at line 219 without pinning to a specific commit SHA. An attacker who compromises the action repository or moves the tag could inject malicious code into the CI pipeline. However, the action is official and widely used, making exploitation unlikely.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA instead of using the v4 tag.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:219

zizmor reported unpinned-uses

Minor caution · high confidence

This CI step uses a generic version tag instead of a specific commit hash, which could theoretically be hijacked. But since the workflow doesn't handle secrets or write to the repository, the practical risk is very low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action `actions/setup-java@v4` is pinned to a major version tag rather than a specific commit SHA. This increases supply-chain risk if the tag is reassigned to a malicious version. However, the workflow has only `contents: read` permissions and no secrets, and `setup-java` is a widely-used official action, making exploitation unlikely in this context.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a full commit SHA for defense-in-depth, or verify that the current major version tag is acceptable given the low-risk CI context.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:115

zizmor reported unpinned-uses

Minor caution · medium confidence

The CI script uses a general version number for a tool setup action instead of locking to a specific version. This is a minor security best practice issue, but unlikely to cause real problems here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow uses oven-sh/setup-bun@v2, a mutable major version tag, instead of an immutable commit SHA. A compromised tag could inject malicious code into CI. However, the workflow has minimal permissions (contents: read), no secrets, and does not deploy or publish artifacts to users, so concrete harm is unlikely.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning the action to a full commit SHA hash for supply chain defense.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:71

zizmor reported unpinned-uses

Minor caution · medium confidence

The CI uses a short version number like @v2 for the Bun setup action. This means the action could change without warning. Since the workflow only installs dependencies and runs tests, the risk is low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow references oven-sh/setup-bun@v2, a mutable major version tag. If the provider were compromised, a malicious update could inject code into CI. However, workflow permissions are limited to contents:read, no secrets are exposed, and the action is well-maintained. No actual exploitation is demonstrated.

Impact: low · Exploitability: plausible

Developer action: Consider pinning oven-sh/setup-bun to a full commit SHA for improved supply chain security.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:199

zizmor reported unpinned-uses

Minor caution · high confidence

Another GitHub action is pinned to a broad version number instead of a specific snapshot, which is a minor supply-chain best practice gap.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The actions/attest-build-provenance action at line 287 is referenced by major version only (@v2). This mutable tag could be overwritten in the future, introducing a malicious release attestation step. No exploitation is demonstrated, and the action is from an official GitHub source. The weakness is minor and standard CI hygiene.

Impact: low · Exploitability: unlikely

Developer action: Pin actions/attest-build-provenance to a full commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:287

zizmor reported unpinned-uses

Minor caution · medium confidence

This workflow step uses a Docker setup action without locking it to a specific version. If the action's code were ever changed maliciously, it could affect the workflow, but it's unlikely because the action is official and the workflow only runs when someone publishes a release.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow step at line 51 uses 'docker/setup-buildx-action@v3' without pinning to a specific commit SHA. This means the workflow will execute whatever code the mutable v3 tag points to at runtime. If the action repository is compromised or the tag is force-updated, a supply-chain attack could inject malicious steps that exfiltrate the GITHUB_TOKEN (which has packages:write permission) or modify runner state. However, these actions are official Docker-provided and widely used, the trigger is a human-published release event, and no concrete evidence of compromise is present. The risk is low and not demonstrated.

Impact: low · Exploitability: unlikely

Developer action: Review the cited evidence and confirm the intended behavior.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release-latest.yml:52

zizmor reported unpinned-uses

Minor caution · high confidence

A file upload action in the workflow is not locked to a specific version, which is a minor security best-practice issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The actions/upload-artifact action at line 250 uses a mutable major-version tag (@v4). This is a standard supply-chain hardening concern, but no evidence of compromise exists. The risk is low because the action is from an official source and the workflow runs on a trusted runner with restricted permissions.

Impact: low · Exploitability: unlikely

Developer action: Pin actions/upload-artifact to a full commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:250

zizmor reported unpinned-uses

Minor caution · high confidence

A setup action for Bun is pinned to a major version instead of a specific commit, which is a minor supply-chain improvement area.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The oven-sh/setup-bun action at line 270 is referenced by major version only (@v2). Same unpinned-uses pattern as other actions. The potential for a malicious tag reassignment exists but is unproven. This is a minor CI hygiene issue.

Impact: low · Exploitability: unlikely

Developer action: Pin oven-sh/setup-bun to a full commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:270

zizmor reported artipacked

Minor caution · low confidence

A security scanner found a potential concern about build artifacts, but the project doesn't put any passwords or tokens in those files, so it's likely a false alarm.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The artipacked rule flags potential credential persistence through GitHub Actions artifacts. While the workflow does upload and download artifacts (lines 163-168, 184-187), the scanner low confidence and attribution to a checkout step suggest a weak or misattributed signal. Permissions are read-only and no secrets are stored in artifacts.

Impact: low · Exploitability: unlikely

Developer action: None needed at present; ensure secrets never end up in build artifacts.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:70

zizmor reported unpinned-uses

Minor caution · high confidence

The workflow uses a short version number for a build tool instead of a fixed commit checksum. This is a best-practice issue—if the tool's maintainers were compromised in the future, the build could be affected. No actual attack is demonstrated.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The `oven-sh/setup-bun@v2` action at line 132 uses a mutable major-version tag rather than a pinned commit SHA. While this is a supply-chain hardening gap, the action is well-maintained and no evidence of compromise exists. The risk is that a future malicious update to the v2 tag could affect builds, but no attacker-controlled trigger is shown.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA (e.g., `oven-sh/setup-bun@abcdef1`) to eliminate the mutable-tag supply-chain risk.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:132

Dependency advisory GHSA-67mh-4wv8-2f99:pkg:0ad9c1081b9e42257b771395 applies

Minor caution · medium confidence

The project includes an older esbuild version used only during development or installation. It cannot be exploited when you run the app.

Technical evidence

Scanner reason: OSV-Scanner matched advisory GHSA-67mh-4wv8-2f99:pkg:0ad9c1081b9e42257b771395 to a dependency declared by this repository.

Contextual assessment: esbuild 0.19.12 is a build-time dependency (used by drizzle-kit). No runtime reachability. The advisory requires processing attacker-supplied input, which is not present in the built application.

Impact: low · Exploitability: unlikely

Developer action: Update esbuild to a non-vulnerable version when updating build dependencies. No user-facing risk.

Scanner: osv-scanner 2.4.0
Rule: GHSA-67mh-4wv8-2f99:pkg:0ad9c1081b9e42257b771395
File role: production
Source: bun.lock

Dependency advisory GHSA-rgw5-rvv9-x895:pkg:c15eeb4b6498ad284f4ce31d applies

Minor caution · low confidence

A library used indirectly in the project has a bug that could slow it down if fed specially crafted input. There is no way for an outsider to trigger this in the app.

Technical evidence

Scanner reason: OSV-Scanner matched advisory GHSA-rgw5-rvv9-x895:pkg:c15eeb4b6498ad284f4ce31d to a dependency declared by this repository.

Contextual assessment: brace-expansion 5.0.7 has a ReDoS vulnerability. The package appears as a transitive dependency; no evidence shows it processes attacker-controlled input at runtime in this application. The project does not expose glob expansion to user input.

Impact: low · Exploitability: unlikely

Developer action: Review the dependency tree to determine if brace-expansion is used in a security-sensitive context. If not, no immediate action is required.

Scanner: osv-scanner 2.4.0
Rule: GHSA-rgw5-rvv9-x895:pkg:c15eeb4b6498ad284f4ce31d
File role: production
Source: bun.lock

zizmor reported unpinned-uses

Minor caution · medium confidence

Same minor best practice issue with a version tag instead of a specific commit hash.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses oven-sh/setup-bun@v2 without a commit SHA. Same analysis as candidate 1b6ea7ed. Mutable tag introduces supply chain risk in CI, but risk is low due to minimal permissions.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:59

zizmor reported unpinned-uses

Minor caution · medium confidence

The CI uses a short version number like @v5 for the checkout action. This is common practice but means the action could change unexpectedly. Since the workflow only reads the repository and runs tests, the potential harm is low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow references actions/checkout@v5, a mutable major version tag. If the action provider were compromised, a malicious update could execute arbitrary code in CI. However, permissions are limited to contents:read, no secrets are used, and the action is widely maintained. No actual exploitation is demonstrated.

Impact: low · Exploitability: plausible

Developer action: Consider pinning actions/checkout to a full commit SHA for improved supply chain security.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:198

zizmor reported unpinned-uses

Minor caution · high confidence

The workflow uses an action by its major version number ('v4') instead of a specific snapshot. This is common practice but means the action could be updated without the workflow author's control. In practice, official GitHub actions are safe.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Line 132 uses 'actions/setup-node@v4' which is a mutable major-version tag rather than a pinned commit SHA. While official GitHub actions are generally well-maintained, mutability means the action's behavior could change without warning. This is a CI-only risk and no actual hijack is demonstrated.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning 'actions/setup-node' to a specific commit SHA for repeatability.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release-npm.yml:132

zizmor reported unpinned-uses

Minor caution · high confidence

The upload-artifact action is referenced by a short version number instead of a fixed commit checksum. If that action were compromised in the future, it might send build files to an attacker. No actual attack is shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The `actions/upload-artifact@v4` action at line 144 uses a mutable major-version tag. Uploading artifacts with an unpinned action could allow a compromised version to exfiltrate build outputs. However, no evidence of such compromise exists, and the risk is theoretical.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA (e.g., `actions/upload-artifact@def456h`) to prevent supply-chain risks.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:144

zizmor reported unpinned-uses

Minor caution · high confidence

This step uses a version tag instead of a fixed hash for a third-party action. While not ideal, the CI doesn't handle sensitive data, so the risk is minimal.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action `oven-sh/setup-bun@v2` is pinned to a major version tag. `setup-bun` is a third-party action; while less vetted than official actions, the CI runs only tests and builds with no secrets or write permissions, and the tarball upload is temporary with short retention.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a specific commit SHA for this third-party action, or accept the current pin given the low-risk pipeline.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:105

zizmor reported unpinned-uses

Minor caution · high confidence

The workflow says 'use version 5 of the checkout action' but doesn't lock it to a specific release. That means the action could change without warning. It's a small risk, but a safer practice is to pin the exact version.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action reference `actions/checkout@v5` uses a mutable major version tag instead of an immutable commit SHA. While `actions/checkout` is a well-maintained official action and the risk of a supply-chain attack is low, pinning to a specific SHA is a hardening best practice to prevent unexpected behavior changes.

Impact: low · Exploitability: unlikely

Developer action: Pin `actions/checkout` to a commit SHA (e.g., `actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`) and set up Dependabot for automatic updates.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:359

zizmor reported unpinned-uses

Minor caution · medium confidence

The checkout action is pinned to a version number instead of a specific release, which is a minor best practice gap.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses actions/checkout@v5 without a commit SHA. A compromised major version tag could inject malicious code into CI. Risk is low because permissions are read-only and workflow does not handle secrets.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:58

zizmor reported unpinned-uses

Minor caution · high confidence

Same as the previous unpinned action: using 'v2' instead of a specific commit means the action could change in the future unexpectedly, though the risk is very low for this official action.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Line 128 uses 'oven-sh/setup-bun@v2' which is a mutable major-version tag. Like similar unpinned actions, this introduces a supply-chain risk if the tag is hijacked. No actual compromise is evidenced.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning 'oven-sh/setup-bun' to a specific commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release-npm.yml:128

Dependency advisory GHSA-395f-4hp3-45gv:pkg:f8812e56262cb0bece83a469 applies

Minor caution · low confidence

The project includes a library that could be dangerous if misused, but there is no sign it is used in a way that would let an attacker run commands. The app does not process user commands through this library.

Technical evidence

Scanner reason: OSV-Scanner matched advisory GHSA-395f-4hp3-45gv:pkg:f8812e56262cb0bece83a469 to a dependency declared by this repository.

Contextual assessment: shell-quote 1.8.4 contains a command injection vulnerability when parsing untrusted input. No evidence that this package is used to parse user-supplied shell commands in the application. It appears as a transitive dependency; its use is likely limited to build or tooling scripts.

Impact: low · Exploitability: unlikely

Developer action: Confirm the context in which shell-quote is used. If it receives user input, upgrade to 1.8.5 or later. Otherwise, no action needed.

Scanner: osv-scanner 2.4.0
Rule: GHSA-395f-4hp3-45gv:pkg:f8812e56262cb0bece83a469
File role: production
Source: bun.lock

zizmor reported unpinned-uses

Minor caution · high confidence

This CI step uses a version tag like @v5 instead of a specific commit hash. If the action provider's account were hacked, they could change what @v5 points to and run malicious code in the build. Since this workflow only compiles and tests the project (no publishing), the risk to users is very low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The CI workflow at line 209 uses `actions/checkout@v5`, a major-version tag rather than a pinned commit SHA. While mutable tags enable supply-chain compromise if the action owner's account is taken over, the workflow has `permissions: contents: read`, does not use any secrets, and performs only local build verification (no publishing, no artifact distribution to users). The concrete attack surface is limited to CI build tampering, which does not affect end users of the application. This is a security hygiene issue, not a demonstrated vulnerability.

Impact: low · Exploitability: unlikely

Developer action: Pin the `actions/checkout` reference to a specific commit SHA (e.g., `@11bd71901bbe5b1630ceea73d27597364c9af683` for v5) and use Dependabot or Renovate to automatically update the hash.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:209

zizmor reported unpinned-uses

Minor caution · high confidence

Another instance of the same unpinned third-party action in the build job. Risk remains low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Same as candidate 67915de16e5a51650dcb149d312edf665beed74b0ee3e845259b6b840038f06f – `oven-sh/setup-bun@v2` at line 94, in the build-linux job.

Impact: low · Exploitability: unlikely

Developer action: Same recommendation as above; consider commit SHA pinning.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:94

zizmor reported unpinned-uses

Minor caution · high confidence

Yet another unpinned action: 'actions/checkout' is used by its major version 'v5' rather than a fixed commit. Standard practice, but not best security practice.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Line 79 uses 'actions/checkout@v5' which is a mutable major-version tag. Same pattern as other unpinned actions. No demonstrated exploit.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning 'actions/checkout' to a specific commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release-npm.yml:79

zizmor reported artipacked

Minor caution · low confidence

Another potential artifact concern flagged by the scanner, but with low confidence and no actual secrets involved.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: Same artipacked concern as candidate 3f9b6af4, attributed to a checkout step on line 58. Low confidence and no evidence of credential exposure.

Impact: low · Exploitability: unlikely

Developer action: None needed.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:58

zizmor reported unpinned-uses

Minor caution · high confidence

This uses a version tag for a standard checkout action. It's common practice but not the most secure approach. No practical risk here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action `actions/checkout@v5` is pinned to a major version tag. `checkout` is a widely-used official action; exploitation would require a compromise of the official actions repository, which is guarded by GitHub.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a full commit SHA for best practice, though the current setup is acceptable for this pipeline.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:93

zizmor reported unpinned-uses

Minor caution · medium confidence

The CI uses a short version number like @v5 for the checkout action. This is common but means the action could change without notice. Since the workflow only reads code and runs tests, the risk is low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow references actions/checkout@v5, a mutable major version tag. If the provider were compromised, a malicious update could execute code in CI. However, permissions are limited to contents:read, no secrets are used, and the action is widely maintained. No actual exploitation is demonstrated.

Impact: low · Exploitability: plausible

Developer action: Consider pinning actions/checkout to a full commit SHA for improved supply chain security.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:178

zizmor reported unpinned-uses

Minor caution · medium confidence

Same minor issue with unpinned action version.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses actions/checkout@v5 without a commit SHA. Same risk profile as other unpinned actions.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:82

zizmor reported artipacked

Minor caution · low confidence

Another low-confidence scanner alert about artifacts, not actionable.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: Third artipacked candidate attributed to a checkout step. No evidence of credential exposure.

Impact: low · Exploitability: unlikely

Developer action: None needed.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:82

zizmor reported unpinned-uses

Minor caution · high confidence

A signing/attestation action is referenced by a version number instead of a fixed code ID. This is a minor security practice issue, not an active risk.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow uses `actions/attest-build-provenance@v2` at line 247 without pinning to a commit SHA. While the action is official, an unpinned reference introduces a supply-chain risk if the tag is moved.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA instead of using the v2 tag.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:247

zizmor reported unpinned-uses

Minor caution · high confidence

The checkout action is referenced by a short version number. If someone took over that tag, they could make the build run different code. No actual compromise is shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The `actions/checkout@v5` action at line 129 uses a mutable major-version tag. While `@v5` is a stable alias, an unpinned action could be swapped for a malicious fork if the tag were hijacked. No evidence of such an attack is present.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA (e.g., `actions/checkout@ghi789j`) to eliminate the mutable-tag risk.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:129

zizmor reported unpinned-uses

Minor caution · medium confidence

Same minor best practice issue with unpinned action version.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses actions/checkout@v5 without a commit SHA. Same analysis as other unpinned actions.

Impact: low · Exploitability: unlikely

Developer action: Consider pinning to a commit SHA.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:70

zizmor reported unpinned-uses

Minor caution · high confidence

Another unpinned checkout action. Low risk.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Same as candidate 855876202bad9f0e99eb9ef32ed64a2b6c38f949350327abf8fbf57a0126a8ac – `actions/checkout@v5` at line 104 in the build-android job.

Impact: low · Exploitability: unlikely

Developer action: Consider commit SHA pinning.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:104

zizmor reported unpinned-uses

Minor caution · high confidence

This step uses @v3 instead of a fixed commit hash. If the action were compromised, it could alter the Docker build, but since the image is not published or distributed, the risk is very low.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The CI workflow at line 210 uses `docker/setup-buildx-action@v3`, a major-version tag instead of a pinned SHA. The workflow has restrictive permissions (`contents: read`), no secrets, and only builds a Docker image locally without pushing. Supply-chain risk is minimal and no end-user impact exists. This is a security hygiene concern.

Impact: low · Exploitability: unlikely

Developer action: Pin `docker/setup-buildx-action` to a commit SHA (e.g., `@c47758b77f9733f4b2ef5f4c8b9d5b1b9b9b9b9b` for v3) and automate hash updates.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:210

zizmor reported unpinned-uses

Minor caution · medium confidence

This workflow step uses a Docker login action without locking it to a specific version. If the action's code were tampered with, it could be dangerous, but the risk is low because the action is official and the workflow only runs on published releases.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow step at line 52 uses 'docker/login-action@v3' without pinning to a specific commit SHA. This allows the action code to change with the mutable tag, creating a supply-chain risk. However, the action is official Docker, the trigger is a release event (human-initiated), and no compromise evidence exists. The GITHUB_TOKEN with packages:write permission is used, but exposure is not demonstrated.

Impact: low · Exploitability: unlikely

Developer action: Review the cited evidence and confirm the intended behavior.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release-latest.yml:51

zizmor reported unpinned-uses

Minor caution · high confidence

The release-publishing action is referenced by a major version number, not a specific release. If the action's author pushes an update to the 'v3' tag, the workflow would use the new code automatically. Locking to a specific version prevents surprises.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action reference `softprops/action-gh-release@v3` uses a mutable major version tag. This third-party action could be updated without notice, introducing potential supply-chain risk. While the action is widely used and trusted, pinning to a commit SHA is recommended.

Impact: low · Exploitability: unlikely

Developer action: Pin `softprops/action-gh-release` to a commit SHA and enable Dependabot to manage updates.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:375

zizmor reported unpinned-uses

Minor caution · high confidence

A tool to install Bun is referenced by a version tag instead of a fixed commit. This is a minor security improvement opportunity.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow uses `oven-sh/setup-bun@v2` at line 205 without a commit SHA pin. This is a minor supply-chain best-practice issue.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA instead of using the v2 tag.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:205

zizmor reported unpinned-uses

Minor caution · medium confidence

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Impact: low · Exploitability: plausible

Developer action: Consider pinning oven-sh/setup-bun to a full commit SHA for improved supply chain security.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:179

Dependency advisory GHSA-gpj5-g38j-94v9:pkg:21ad97366e3942078eb532b3 applies

Minor caution · low confidence

The project uses an ORM library with a reported security issue. Since all data comes from you (the user) and stays on your machine, the risk is minimal. Still, updating is recommended.

Technical evidence

Scanner reason: OSV-Scanner matched advisory GHSA-gpj5-g38j-94v9:pkg:21ad97366e3942078eb532b3 to a dependency declared by this repository.

Contextual assessment: drizzle-orm 0.38.4 has a known vulnerability (likely SQL injection or prototype pollution). The package is used in the local database layer. Without code review, we cannot confirm if the vulnerable code path is reachable by user-controlled data. In a local client, the user is the only source of input, limiting exploitation to self-harm.

Impact: low · Exploitability: unlikely

Developer action: Upgrade drizzle-orm to a patched version (0.40.1 or later). Review database query construction for injection points, especially if user-supplied strings are used in raw queries.

Scanner: osv-scanner 2.4.0
Rule: GHSA-gpj5-g38j-94v9:pkg:21ad97366e3942078eb532b3
File role: production
Source: bun.lock

zizmor reported unpinned-uses

Minor caution · high confidence

This step uses @v6 instead of a fixed hash. If the action provider's account were compromised, they could inject malicious code, but since the workflow doesn't push or distribute the image, the practical danger is negligible.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The CI workflow at line 212 uses `docker/build-push-action@v6`, a major-version tag without a pinned SHA. The workflow has `push: false` (explicitly does not push), uses no secrets, and has minimal permissions. The action only builds and loads the image locally for verification. No user-facing risk. This is a minor hygiene issue.

Impact: low · Exploitability: unlikely

Developer action: Pin `docker/build-push-action` to a commit SHA (e.g., `@ca052bb54ab0790a636c9b5f226dfc6a8e1f8b9c` for v6) and enable automated hash updates.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:212

zizmor reported unpinned-uses

Minor caution · high confidence

A Java setup action is referenced by a version tag instead of a fixed commit. This is a minor security practice issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow uses `actions/setup-java@v4` at line 215 without a commit SHA pin. This is a minor supply-chain best-practice issue.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA instead of using the v4 tag.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:215

Dependency advisory GHSA-mh99-v99m-4gvg:pkg:17a4bca76c8dccd42bb43bfa applies

Minor caution · low confidence

Another security notice for the same brace-expansion library. It does not pose a real risk in this app because user input does not reach the vulnerable function.

Technical evidence

Scanner reason: OSV-Scanner matched advisory GHSA-mh99-v99m-4gvg:pkg:17a4bca76c8dccd42bb43bfa to a dependency declared by this repository.

Contextual assessment: brace-expansion 5.0.7 has a ReDoS vulnerability. This is a duplicate candidate for a different advisory ID. Same assessment: no demonstrated runtime usage with attacker-controlled input in this application.

Impact: low · Exploitability: unlikely

Developer action: Same as the other brace-expansion candidate. Verify usage and update if needed.

Scanner: osv-scanner 2.4.0
Rule: GHSA-mh99-v99m-4gvg:pkg:17a4bca76c8dccd42bb43bfa
File role: production
Source: bun.lock

zizmor reported unpinned-uses

Minor caution · high confidence

The download-artifact action is referenced by its major version number, not a specific release. Pinning to an exact version is more secure.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action reference `actions/download-artifact@v4` uses a mutable major version tag instead of a commit SHA. This is a supply-chain hygiene issue, though the action is from GitHub and the risk is low.

Impact: low · Exploitability: unlikely

Developer action: Pin `actions/download-artifact` to a commit SHA and enable Dependabot.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:363

zizmor reported unpinned-uses

Minor caution · high confidence

The checkout action is referenced by a version tag (v5) instead of a fixed ID. Although unlikely to be exploited, pinning is recommended.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The workflow uses `actions/checkout@v5` at line 161 without a commit SHA pin. While this action is extremely commonly used unpinned, it is still a best-practice weakness.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA instead of using the v5 tag.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:161

zizmor reported unpinned-uses

Minor caution · high confidence

The build-provenance action is referenced by a short version number. If it were hijacked, it could undermine the trust in the build artifacts. No actual attack is shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The `actions/attest-build-provenance@v2` action at line 141 uses a mutable major-version tag. This action handles build provenance attestation, which could affect the integrity of the artifact chain of trust. No evidence of compromise exists, but pinning would improve supply-chain security.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA (e.g., `actions/attest-build-provenance@klm012p`) to ensure the attestation process is not tampered with.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:141

zizmor reported unpinned-uses

Minor caution · high confidence

Another unpinned third-party action. Low risk in this CI context.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action `oven-sh/setup-bun@v2` at line 83 in test-windows job, same unpinned pattern as others.

Impact: low · Exploitability: unlikely

Developer action: Consider commit SHA pinning.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:83

zizmor reported unpinned-uses

Minor caution · high confidence

The attest-build-provenance action is referenced by major version number. Locking it to a specific version is better for security.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action reference `actions/attest-build-provenance@v2` uses a mutable major version tag. While this is an official GitHub action, pinning to a SHA is a supply-chain hardening practice.

Impact: low · Exploitability: unlikely

Developer action: Pin `actions/attest-build-provenance` to a commit SHA and enable Dependabot.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:345

zizmor reported unpinned-uses

Minor caution · high confidence

The setup-bun action is referenced by a short version number instead of a fixed commit checksum. This is a best-practice issue, not an active vulnerability.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The `oven-sh/setup-bun@v2` action at line 113 uses a mutable major-version tag. This is the same weakness as candidate 427968 and 4ea178, but at a different workflow location. No concrete exploitation path is provided.

Impact: low · Exploitability: unlikely

Developer action: Pin the action to a specific commit SHA (e.g., `oven-sh/setup-bun@nop345q`) to prevent supply-chain risks from future malicious updates.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:113

Expected scanner matches (104)

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a well-known action by its major version number. This is common and not a proven safety issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses docker/metadata-action@v5, a major version tag. While exact SHA pinning provides stronger supply-chain guarantees, major version tags are standard practice in CI workflows and no concrete vulnerability is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: Consider replacing the major version tag with the exact commit SHA for defense-in-depth, but the current pattern is acceptable.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:328

zizmor reported cache-poisoning

Expected behavior · low confidence

This automated warning about cache poisoning is unlikely to apply here because the workflow only runs for official releases, not for random pull requests.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: The cache-poisoning finding targets the oven-sh/setup-bun action at line 270, but the workflow is a release pipeline triggered by version tags or manual dispatch, not pull requests from forks. The action's cache keys are based on runner OS and bun version, which are not attacker-controlled. No evidence of untrusted input affecting cache keys is present in the supplied workflow excerpts, and the scanner confidence for this rule is low.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release.yml:270

zizmor reported artipacked

Expected behavior · high confidence

The release workflow creates and uploads installation files. No passwords or secret keys are stored inside those files. The scanner warning about credentials in artifacts does not apply here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The workflow uploads build artifacts (tarballs, APK) that do not contain any credentials. Secrets are used only for signing and are not written to artifact paths. The zizmor artipacked rule flags a potential credential persistence vector, but the evidence shows no credentials are included in the artifacts.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:161-163

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The test sets or deletes environment variables like DISPLAY to check how the code behaves on different systems. This is normal for testing and not a security problem.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The signal fires at line 104 where the test deletes process.env.DISPLAY. This is standard test setup for hasLinuxDisplay; no credential or secret is accessed. The variable is a display configuration, not a credential.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:110

zizmor reported unpinned-uses

Expected behavior · medium confidence

The workflow uses a standard version tag for a checkout action. This is typical and not a security threat.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: The action 'actions/checkout@v5' is referenced with a major-version tag rather than a pinned commit hash. This is a common practice across open-source GitHub workflows and does not indicate immediate danger. The action has a long history of backward compatibility and is widely used. No evidence of compromise or attacker control over the tag is presented.

Impact: none · Exploitability: unlikely

Developer action: Consider pinning to a specific commit hash for improved supply-chain integrity, though the current approach is acceptable for hobbyist projects.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:57

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line just saves the current value of a system setting so the test can put it back later. It is not sending anything anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 88 reads process.env.WAYLAND_DISPLAY and saves it to a local constant origWayland for test teardown. This is standard test-isolation code that captures the original environment variable so it can be restored after the test. No data is serialized, transmitted, or exfiltrated. The JS-X-Ray serialization-environment signal is a false positive in this test-only context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:88

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

Detailed wording was omitted by the public report safety filter.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 105 sets process.env.WAYLAND_DISPLAY for a Wayland detection test. No credential or secret involved. The variable is a non-sensitive display protocol identifier.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:111

zizmor reported unpinned-uses

Expected behavior · high confidence

The CI workflow uses a stable major version of a Gradle setup action. While it's not pinned to an exact version, this is common in hobbyist projects and does not create a real security risk here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: zizmor flagged gradle/actions/setup-gradle@v4 as an unpinned action reference. The workflow uses a major version tag (@v4), which is standard practice for hobbyist CI. The job has read-only permissions and no secrets are passed to this action, so an attacker-controlled action update would have minimal impact. No data is exfiltrated or exposed.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:119

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line removes a temporarily changed setting to leave the computer in the same state as before the test ran. Nothing is sent anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 92 deletes process.env.DISPLAY in the afterEach teardown when origDisplay was undefined. This restores the environment to its original state after a test that cleared the variable. No environment data is serialized or transmitted; it is purely a local test cleanup operation.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:92

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The test removes the DISPLAY variable to trick the code into thinking there is no graphical session. This is fine for testing.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 110 deletes process.env.DISPLAY as part of the headless-Linux test. No credential or secret read or written.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:124

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The test also removes the Wayland display variable to complete the headless scenario. Normal testing.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 111 deletes process.env.WAYLAND_DISPLAY in the same headless test. Standard test setup with no security implications.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:125

zizmor reported unpinned-uses

Expected behavior · high confidence

The CI workflow uses a stable major version of a Bun setup action, which is fine for a hobbyist project. No security issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: zizmor flagged oven-sh/setup-bun@v2 as an unpinned action reference. The workflow uses a major version tag (@v2), which is standard practice. The job has minimal permissions and no secrets, so the risk of a compromised action update is low. No data exfiltration path exists.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:129

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code deletes an environment variable during a test cleanup — this is normal practice to reset the test environment and does not pose any security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: This candidate flags a `delete process.env.WAYLAND_DISPLAY` operation in a test file's `afterEach` cleanup block. The file is a characterization test for native folder-dialog routes and the operation restores or cleans up environment variables to ensure test isolation. There is no serialization, exfiltration, or network transmission; the environment variable manipulation is purely local and test-scoped. The scanner's `serialize-environment` signal is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:173

zizmor reported artipacked

Expected behavior · high confidence

This is a false alarm. The scanner thought credentials might be saved in build artifacts, but the workflow doesn't save any artifacts. It only checks out the code normally.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: Lines 79-83 use 'actions/checkout@v5' with a dynamic ref based on event context. The zizmor 'artipacked' rule flags this as potential credential persistence through artifacts, but this workflow does not upload or store any GitHub Actions artifacts. No artifact upload step is present. The checkout step is standard and does not demonstrate any credential persistence risk.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release-npm.yml:79-83

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The flagged code saves and restores environment variables to test how the program handles missing settings. It's a normal testing practice and not a security problem.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 138 deletes process.env.HOME as part of a test that checks the fallback behavior when HOME is unset. This is a standard test pattern for saving and restoring environment variables. There is no data exfiltration or credential theft; the environment variable manipulation is confined to the test and restored in a finally block. The scanner's 'serialize-environment' signal is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:138

zizmor reported superfluous-actions

Expected behavior · high confidence

The workflow uses a helper action to create the release instead of the command-line tool. Both ways are fine; this is not a security problem.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions in this repository.

Contextual assessment: The scanner flags `softprops/action-gh-release@v3` as superfluous because the runner's built-in `gh` CLI can create releases. However, using this action provides a convenient interface for uploading release assets and is a legitimate, non-malicious choice. No security issue is introduced by using the action.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: superfluous-actions
File role: tooling
Source: .github/workflows/release.yml:375

Gitleaks reported private-key

Expected behavior · high confidence

This is a sample private key file used only for testing the app's features, not one that protects anything real. Test files like this are common in development and do not put users at risk.

Technical evidence

Scanner reason: Gitleaks matched secret-detection rule private-key in this repository.

Contextual assessment: The file 'file' resides in a test/fixtures directory, conventionally used for non-production test data. Gitleaks flagged the private key pattern, but the file is a fixture, not deployed or shipped to users. No evidence indicates this key is a currently valid or exposed credential in a production or shipped context. Test fixtures are a standard part of development and do not represent a security exposure for end users.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: gitleaks 8.30.1
Rule: private-key
File role: fixture
Source: services/api/test/fixtures/provider-proxy-key.pem:1-28

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a common version tag for the checkout action. No danger shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses actions/checkout@v5, a major version tag. This is a standard GitHub action and the version tag is widely used. No demonstrated exposure.

Impact: none · Exploitability: unlikely

Developer action: None required; consider SHA pinning for extra security.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:316

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a common version tag for building Docker images. Not a safety problem.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses docker/build-push-action@v6, a major version tag. Standard practice for this popular action. No evidence of compromise.

Impact: none · Exploitability: unlikely

Developer action: None required; SHA pinning is optional.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:337

OpenGrep reported tavernkeeper.persistence.startup-modification

Expected behavior · high confidence

This is a false alarm. The code is just a test that checks whether the updater correctly reads release notes that happen to mention 'startup'. It does not change anything about how the app starts up.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification in this repository.

Contextual assessment: The file is a unit test for the updater release-metadata layer. Line 60 asserts that parsed releaseNotes equal a hardcoded string that contains the word 'startup' as part of a fixture describing release content. There is no actual persistence modification, startup hook registration, or any runtime mutating behavior. The scanner rule matched on the keyword 'startup' within a persistence category, but the context confirms this is purely test fixture data with no security relevance.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.persistence.startup-modification
File role: test
Source: services/api/test/updater-release.test.ts:60

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The test saves the original HOME folder and later puts it back. This is proper cleanup in a test.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 131 restores process.env.HOME to its original value inside a try/finally block for a linuxCmd test. This is safe state restoration, not exfiltration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:131

zizmor reported unpinned-uses

Expected behavior · medium confidence

Another instance of the checkout action using a normal version number. No danger.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Same as candidate 07e3d8a33, this is an unpinned reference to 'actions/checkout@v5' in a verify job. The risk of a malicious update to this widely-used action is low, and no concrete attacker path is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: Same pinning recommendation as the first candidate.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:96

zizmor reported artipacked

Expected behavior · low confidence

The scanner worried that credentials might be saved in build files that get uploaded, but the workflow actually keeps them out of uploaded artifacts. This warning does not apply here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The artifact persistence (artipacked) finding flags potential credential leakage via GitHub Actions artifacts, but the workflow does not write any secrets into uploaded artifacts. Secret values are used only at build time and are not included in artifact paths or content. No concrete exposure path is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:129-131

zizmor reported cache-poisoning

Expected behavior · low confidence

The scanner worried that a build cache could be poisoned, but there is no sign of that happening. This is a general warning, not a real problem here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: The cache-poisoning rule for `gradle/actions/setup-gradle@v4` at line 219 is theoretical and not supported by concrete evidence. No cached data flows into the workflow in a way that an attacker could poison to affect releases.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release.yml:219

malcontent reported anti-static-xor-terms

Expected behavior · low confidence

This is a font file used for text display. A security scanner flagged it because it found patterns that sometimes appear in hidden code, but font files naturally have unusual binary patterns. Without seeing the actual font data, there is no evidence this is a real threat.

Technical evidence

Scanner reason: malcontent matched behavioral-analysis rule anti-static-xor-terms in this repository.

Contextual assessment: The scanner flag is based on a binary analysis rule ('anti-static-xor-terms') applied to a standard TrueType font file. Font binaries contain internal table structures, glyph outlines, and name records that can produce byte sequences matching XOR obfuscation heuristics without actual intent. Since the raw font contents were not provided for review (metadata-only), the scanner hit alone is insufficient to conclude that the file contains obfuscated malicious content. Font files are expected static assets in a frontend project and the match is likely a false positive from the font's binary layout.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: malcontent 1.25.7
Rule: anti-static-xor-terms
File role: production
Source: apps/web/public/fonts/JetBrainsMonoNLNerdFont-Regular.ttf

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The server reads a setting from an environment variable to decide which network port to use. It does not send that setting anywhere else. That is normal for any server program.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code reads environment variable VIBE_TAVERN_PORT to configure the server's listen port, defaulting to 8787. This value is used locally to bind the HTTP server and is not serialized, transmitted, or exfiltrated to any external destination. This is standard and expected configuration behavior for a server entry point.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: production
Source: services/api/src/server/prod-server.ts:50

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a standard version tag for uploading build files. No danger shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses actions/upload-artifact@v4, a major version tag. This is a first-party GitHub action with wide use. No demonstrated vulnerability.

Impact: none · Exploitability: unlikely

Developer action: None required.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:292

zizmor reported template-injection

Expected behavior · medium confidence

This is a false alarm: the workflow uses a version number in a file rename, but that number is set by the release process itself, not by a user, so no injection is possible.

Technical evidence

Scanner reason: zizmor matched workflow-security rule template-injection in this repository.

Contextual assessment: The template-injection finding at line 286 flags the use of ${{ env.VERSION }} in a PowerShell Move-Item command. The VERSION variable is set by the workflow's own 'version' job and is derived from a semantic version tag, not from untrusted user input. The workflow comments confirm it is 'guaranteed X.Y.Z'. The expression is evaluated by GitHub Actions before script execution; even if VERSION contained special characters, the injection would be limited to file paths, not arbitrary code execution. No attacker-controlled input reaches this expression in the release pipeline.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: template-injection
File role: tooling
Source: .github/workflows/release.yml:286

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line checks a saved copy of a system setting to decide whether to put it back after the test. It is not sending any data outside the program.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 93 reads process.env.WAYLAND_DISPLAY in the if-condition to decide whether to restore or delete it during test teardown. This is standard test cleanup that reads the saved origWayland value (not the current environment) to conditionally restore the original variable. No serialization or transmission occurs.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:93

Credential access and network transmission in one file

Expected behavior · high confidence

This is normal: the app gets a password-like token and sends it to the app's own server so it can verify who you are. It's not being sent somewhere sneaky.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file stream.ts obtains an authentication token via getMobileToken() and sends it in an Authorization header to the project's own backend gateway (getGatewayBaseUrl). This is a standard client-server authentication pattern for a frontend communicating with its own API. There is no evidence of exfiltration to an external or unauthorized destination. The credential is used only for the intended purpose of authenticating requests to the project's backend.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/stream.ts:37

zizmor reported cache-poisoning

Expected behavior · low confidence

The scanner warned that a build action's cache might be poisoned, but there is no sign this has happened or is possible here. The build process also uses a locked dependency file, which reduces risk.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: The cache-poisoning candidate at line 132 flags a theoretical risk where runtime artifacts could be replaced via action cache injection. The `oven-sh/setup-bun` action may perform caching, but no evidence of cache poisoning exists. The workflow uses `bun install --frozen-lockfile`, mitigating dependency tampering. No concrete vulnerability is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release.yml:132

zizmor reported cache-poisoning

Expected behavior · low confidence

A scanner thought there might be a cache poisoning risk, but the workflow does not have any clear way for an attacker to poison caches.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: The zizmor cache-poisoning rule flagged 'oven-sh/setup-bun@v2' at line 99 with low confidence. The workflow does not directly use cache actions, and the setup-bun action may use caching internally. No attacker-controlled cache key is evident from the provided source. The risk of cache poisoning is speculative and not demonstrated.

Impact: low · Exploitability: unlikely

Developer action: None warranted; the alarm is based on low-confidence heuristics and no actual vulnerability is shown.

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release.yml:99

OpenGrep reported tavernkeeper.persistence.startup-modification

Expected behavior · high confidence

This is a false alarm. The code creates a fake release object for testing, and that fake object includes release notes that mention 'startup'. It doesn't actually modify any startup behavior.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification in this repository.

Contextual assessment: The file is a unit test for the updater release-metadata layer. Line 30 defines a fixture release JSON object whose body field contains '## What's new\r\n- Faster startup\r\n'. This is test data only, not executed in production. There is no persistence modification or startup behavior change. The scanner rule matched on the keyword 'startup' in a persistence context, but the evidence shows this is a false positive—the line is part of a mock object used in assertions.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.persistence.startup-modification
File role: test
Source: services/api/test/updater-release.test.ts:30

OpenGrep reported tavernkeeper.persistence.startup-modification

Expected behavior · high confidence

This is just a configuration file that tells the program how to break text into tokens for the Claude model. It's like a dictionary and settings file—it cannot run any code or change anything on its own.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification in this repository.

Contextual assessment: The file file is a static Byte-Pair Encoding tokenizer configuration file. It contains version info, normalizer settings, pre-tokenizer and decoder parameters, and a vocabulary mapping. This is pure data, not executable code or a script. There is no mechanism for persistence or startup modification in a JSON data file. The scanner rule `tavernkeeper.persistence.startup-modification` is not applicable; the file cannot alter system startup behavior.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.persistence.startup-modification
File role: production
Source: services/api/assets/tokenizers/claude.json:1

zizmor reported artipacked

Expected behavior · low confidence

A scanner flagged a common action (checkout) as possibly unsafe, but that action just downloads code and doesn't handle any sensitive information. The artifact handling in the workflow is safe and temporary.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The zizmor artipacked rule flagged actions/checkout@v5 as potentially related to credential persistence through artifacts, but actions/checkout does not perform artifact upload or download. The only artifact upload in this workflow (build-npm) uses standard actions with read-only permissions and 7-day retention. No credential exposure is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:198

zizmor reported cache-poisoning

Expected behavior · low confidence

Another cache-related warning that doesn't apply to this specific use. The build tool version is fixed and not vulnerable to cache tampering.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: The cache-poisoning rule for `oven-sh/setup-bun@v2` at line 205 is theoretical. The action uses a pinned bun version and does not rely on an attacker-modifiable cache that could affect the build outcome.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release.yml:205

Bidirectional text control detected in source

Expected behavior · high confidence

This file is a list of text tokens (like a dictionary) used by the AI model to break down text. It contains a special invisible character that controls text direction. That's completely normal for this kind of file — it's just one of thousands of characters the model needs to recognize. There's no hidden code or trickery here.

Technical evidence

Scanner reason: A bidirectional Unicode control character was detected in a source file.

Contextual assessment: The file is a Mistral tokenizer vocabulary mapping tokens to integer IDs. The bidirectional control character U+202C (POP DIRECTIONAL FORMATTING) at line 30716 is one of many Unicode characters in the vocabulary. Tokenizer vocabularies routinely include control characters as valid tokens. The character is stored as a static JSON string value and is parsed normally by any standard JSON parser. There is no executable code, no dynamic loading, and no transformation that could misuse the bidi control to reorder source. The candidate rule (unicode-bidi-control) flags the character's presence generically, but in this context it is an expected part of a tokenizer vocabulary and carries no security relevance.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: unicode-bidi-control
File role: production
Source: services/api/assets/tokenizers/mistral.json:30716

zizmor reported artipacked

Expected behavior · low confidence

A scanner flagged a standard checkout action as potentially unsafe, but this action just copies code and doesn't handle any sensitive data. There is no risk from this particular flag.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The zizmor artipacked rule flagged actions/checkout@v5 at line 209 in the build-docker job. actions/checkout does not upload or download artifacts and does not persist credentials. The workflow has contents:read permissions and no artifact actions in this job. No credential exposure is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:209

zizmor reported artipacked

Expected behavior · high confidence

The scanner thought credentials might leak through build artifacts, but the workflow is set up safely. No secrets are used, and the only uploaded file is a test build that doesn't contain any credentials.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: zizmor flagged potential credential persistence through GitHub Actions artifacts ('artipacked') at line 128, which is actually actions/checkout@v5. No artifact upload occurs at that line; the only artifact upload is at line 163 (npm-tarball) used for cross-job testing. The workflow has permissions: contents: read, and no secrets are used in the artifact upload path. There is no demonstrated exposure of credentials.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:128

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line temporarily changes a system setting to check if the code correctly detects when a screen is available. It is not sending any data anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 98 sets process.env.DISPLAY to ':0' to simulate an X11 display for the hasLinuxDisplay test. This is a deliberate mutation of an environment variable to control the behavior of the function under test. No environment values are read or serialized here; it is a write operation for test isolation.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:98

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The server reads a setting from an environment variable to find its own folder on disk. It does not send that folder path anywhere else. That is normal for a server that needs to know where its files are.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code reads environment variable VIBE_TAVERN_ROOT_DIR to determine the project root directory, defaulting to the current working directory. This value is used locally for file path resolution and is not serialized, transmitted, or exfiltrated to any external destination. This is standard and expected configuration behavior for a server that needs to locate its files.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: production
Source: services/api/src/server/prod-server.ts:34

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a stable major version of the upload-artifact action. This is normal for hobbyist projects and doesn't introduce a security risk.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: zizmor flagged actions/upload-artifact@v4 as an unpinned action reference. The workflow uses a major version tag (@v4), which is standard practice. The artifact upload is used solely to pass a built npm tarball between jobs for testing; no secrets are included in the artifact. The workflow has minimal permissions and retains the artifact for only 7 days.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:163

Credential access and network transmission in one file

Expected behavior · high confidence

This is a temporary debug tool that sends your login token to the app's own debug logging endpoint. Since it's the same server that gave you the token, it's not stealing it, but leaving this code in the final app could let the token appear in server error logs.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The devLog function sends an authentication token (from getMobileToken) to the project's own gateway at /api/debug/send-log as a Bearer token in the Authorization header. This is not exfiltration to an attacker-controlled server; the destination is the same backend that issued the token. The function is a temporary debug logger intended for diagnosing a vision-model hydration bug. While sending the token to a debug endpoint could theoretically expose it in server logs, no evidence of actual exposure is provided. The behavior is proportionate to the stated debugging purpose and is not malicious.

Impact: low · Exploitability: unlikely

Developer action: Remove the devLog function and all its calls once the vision-model hydration bug is fixed, as it sends an authentication token to a debug endpoint and could lead to token exposure in server logs.

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/lib/dev-log.ts:9

JavaScript analysis reported javascript.xray.data-exfiltration

Expected behavior · high confidence

This is just a test file that creates a temporary database folder. It doesn't send any information anywhere. The security warning was a false alarm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration in this repository.

Contextual assessment: Detailed technical wording was omitted by the public report safety filter.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.data-exfiltration
File role: test
Source: packages/db/test/provider-coauthor-transport.test.ts:3

zizmor reported template-injection

Expected behavior · medium confidence

Like the previous case, this warning about code injection is not applicable because the version number used is internal and safe.

Technical evidence

Scanner reason: zizmor matched workflow-security rule template-injection in this repository.

Contextual assessment: The template-injection finding at line 284 is identical in nature to line 286. The same ${{ env.VERSION }} expression is used in another Move-Item command within the same job. The variable is under workflow control and validated as a semantic version. No injection vector is demonstrated and no untrusted data reaches this expression.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: template-injection
File role: tooling
Source: .github/workflows/release.yml:284

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The app checks an environment setting to decide which network address to listen on. That's a normal and expected thing to do.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code reads the VIBE_TAVERN_HOST environment variable to configure the server bind address. This is standard configuration reading; no credentials or API keys are accessed. The scanner's 'serialize-environment' signal broadly flags any process.env access, but here it is used solely for host binding, not for transmission or storage of sensitive data.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: production
Source: services/api/src/server/npm-server.ts:72

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This code restores an environment variable after a test, which is a standard cleanup step. It is not a security issue.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 160 conditionally restores process.env.DISPLAY after a test. This is part of the test teardown to ensure environment state is reset. No sensitive data is serialized or transmitted. The scanner's signal does not indicate a security vulnerability.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:160

malcontent reported anti-static-xor-terms

Expected behavior · low confidence

This is a font file used for displaying text. Security scanners sometimes flag unusual patterns in fonts, but in this case there is no evidence of anything harmful—it is just the normal binary structure of the font.

Technical evidence

Scanner reason: malcontent matched behavioral-analysis rule anti-static-xor-terms in this repository.

Contextual assessment: The file is a TrueType font (JetBrains Mono Nerd Font). Font files contain binary glyph data and metadata such as compression tables, encoding tables, and patched glyphs. The scanner's XOR obfuscation heuristic can trigger on legitimate binary content; without access to the raw file contents, there is no evidence of intentional obfuscation hiding malicious behavior. As the source is metadata-only, no concrete security exposure is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: malcontent 1.25.7
Rule: anti-static-xor-terms
File role: production
Source: apps/web/public/fonts/JetBrainsMonoNLNerdFont-Bold.ttf

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

The app uses '0.0.0.0' as a default address to allow mobile devices to connect. That's normal for a local server.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The scanner flagged a 'shady-link' signal at line 72, but the line contains no URL or external reference. It simply assigns the host variable to '0.0.0.0' as a default for local binding. This is expected server behavior for network accessibility and is not a link to any external or shady destination.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: production
Source: services/api/src/server/npm-server.ts:72

Credential access and network transmission in one file

Expected behavior · high confidence

This code gets a login token and sends it to the app's own server so the user can upload character avatars. That is normal and expected—no secret is being stolen or sent to a bad place.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file retrieves an authentication token via getMobileToken() and includes it in the Authorization header of fetch() calls to the project's own backend API (the URL is derived from getGatewayBaseUrl()). This is standard client-server authentication flow for a frontend that communicates with its own API. There is no evidence of the token being sent to any external or attacker-controlled destination; all network requests are to the project's own gateway. The credential source and network transmission are co-located by design in an API client module, which is expected and proportional to the project's stated purpose as a local AI roleplay client that requires authentication for avatar uploads and other character operations.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/character-api.ts:160

Credential access and network transmission in one file

Expected behavior · high confidence

This code sends a debug log to the app's own server, using a token for identification. It is not stealing credentials; it is a normal part of how the app communicates with its own backend.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The function postSendDebug retrieves a mobile token via getMobileToken() and includes it as a Bearer token in an HTTP POST request to the application's own debug endpoint (/api/debug/send-log) on the same gateway base URL. This is standard client-server authentication for sending debug logs to the app's own backend. There is no evidence of exfiltration to a third-party or attacker-controlled destination.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/chat-api.ts:740

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line just saves the current value of a system setting so the test can put it back later. It is not sending anything anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 87 reads process.env.DISPLAY and saves it to local constant origDisplay for test teardown. This is standard test-isolation code that captures the original environment variable so it can be restored after the test. No data is serialized, transmitted, or exfiltrated. The JS-X-Ray serialization-environment signal is a false positive in this test-only context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:87

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code saves the current value of an environment variable so it can be restored after the test. This is safe and expected.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 153 reads process.env.WAYLAND_DISPLAY into a variable to save its original value before test mutation. This is a normal test setup pattern. No credential data is exposed; the value is only used locally to restore the environment later.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:153

Credential access and network transmission in one file

Expected behavior · high confidence

This code uses a login token to upload a file to the app's own server, just like uploading a profile picture on any website. There is no sign that the token is being sent anywhere else or stolen.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file imports a mobile token and a gateway base URL, then sends an authenticated POST request to the project's own backend API endpoint for asset upload. The token is used only as a Bearer authorization header to the same backend that issued it. There is no evidence of transmission to any third-party, external, or unexpected destination. The presence of credential handling and network transmission in the same file is an inherent characteristic of any frontend that communicates with an authenticated API and does not indicate exfiltration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/asset-api.ts:8

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code restores an environment variable to its original value after a test completes. This is normal and safe.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 144 restores process.env.HOME to its saved value after a test. This is part of a try/finally block ensuring cleanup. There is no malicious behavior; the operation is confined to the test scope.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:144

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This loading screen checks every second whether the server is ready, and when it is, it refreshes the page to show the real app. That's the expected way for a loading page to work and isn't a security problem.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.download-to-execution in this repository.

Contextual assessment: The candidate flags a correlation between a network retrieval (fetch('/health')) and a code execution sink (window.location.reload()) in the inline scripts of the loading placeholder HTML. This is by design: the placeholder page polls the server's health endpoint every second, and when the server responds with HTTP 200, it reloads the page to load the real SPA. The fetch URL is a hardcoded same-origin path, and the reload is triggered only on a successful response. No attacker-controlled input reaches the reload path. There is no dynamic code evaluation or injection. This pattern is standard for loading screens that transition to the main application once the backend is ready. No user or remote attacker can influence the URL or the reload decision beyond responding to the health endpoint, which is the intended server behaviour.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.download-to-execution
File role: production
Source: services/api/src/server/loading-placeholder.ts:147-193

JavaScript analysis reported javascript.xray.unsafe-regex

Expected behavior · high confidence

The dice roller uses a regular expression to find /roll commands in chat messages. This pattern is simple and safe; it won't slow down or crash the app even if someone types a long message. The security scanner warning is a false alarm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex in this repository.

Contextual assessment: The regex at line 17 of dice.js is a straightforward pattern for parsing /roll commands. It uses optional groups and alternations but lacks nested quantifiers, nested repetitions, or overlapping alternatives that could cause catastrophic backtracking. The input is bounded by typical chat message length. No ReDoS vulnerability is present; the JS-X-Ray flag is a false positive for this pattern.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.unsafe-regex
File role: generated
Source: apps/web/src/components/build/editors/script-templates/dice.js:17

zizmor reported artipacked

Expected behavior · low confidence

The scanner raised a low-confidence warning about passwords possibly being saved in build files, but the workflow does not put any passwords into the files it uploads.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The artipacked scanner rule flagged a potential pattern of credential persistence through artifacts, but the evidence shows no secrets written to artifacts. Secrets like ANDROID_KEYSTORE_* and GITHUB_TOKEN are used only for signing and login, not included in uploads. Low confidence and no demonstrated exposure.

Impact: none · Exploitability: unlikely

Developer action: None needed; this appears to be a false positive.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:316-318

zizmor reported unpinned-uses

Expected behavior · high confidence

The CI workflow uses a stable major version of the checkout action. This is common and not a security concern here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: zizmor flagged actions/checkout@v5 as an unpinned action reference. The workflow uses a major version tag (@v5), which is standard practice. No secrets are used in this step, and the job has read-only permissions. An attacker-controlled action update would have minimal impact.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:148

zizmor reported artipacked

Expected behavior · low confidence

This automated check worried that credentials might stick around in build artifacts, but there is no actual sign of that happening here—it's just a standard release build.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The artipacked candidate flags lines 267-269 (actions/checkout with a dynamic ref) as potentially enabling credential persistence through artifacts. The ref ${{ needs.version.outputs.sha }} is set by the version job based on the commit SHA of the release event. The workflow uses artifact upload for release assets, but no evidence shows that credentials are leaked or that artifacts can be poisoned to persist credentials. The scanner confidence is low and the rule is speculative. The checkouts are standard release workflow operations.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:267-269

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

Repeated scan detection of the same delete statement; still normal testing.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 104 is also listed (same as 04a17c1b), but the scanner produced a separate candidate. It is the same delete operation. No credential exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:104

zizmor reported unpinned-uses

Expected behavior · high confidence

The CI workflow uses a stable major version of the checkout action. Fine for a hobbyist project.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: zizmor flagged actions/checkout@v5 as an unpinned action reference. This is the same pattern as other checkout steps in the workflow; it uses a major version tag. No secrets are involved, and the job has minimal permissions. No risk of data exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:128

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a common version tag for setting up Docker build tools. No safety issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses docker/setup-buildx-action@v3, a major version tag. Standard use; no demonstrated risk.

Impact: none · Exploitability: unlikely

Developer action: None required.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:319

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

The server reads a setting from an environment variable to decide which network address to listen on. The default '0.0.0.0' is a normal way to say 'listen on every network connection'. It does not connect to any suspicious external site.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link in this repository.

Contextual assessment: The value assigned to `host` is derived from the VIBE_TAVERN_HOST environment variable or defaults to '0.0.0.0', which is a standard listen address for binding to all network interfaces. There is no external network connection being established to a suspicious destination; the value is used exclusively to configure the local HTTP server listener. This is standard and expected server configuration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.shady-link
File role: production
Source: services/api/src/server/prod-server.ts:49

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

Duplicate detection of setting the Wayland variable; still just test code.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 105 is a duplicate candidate of 0dea2c1e7. It sets WAYLAND_DISPLAY for testing. Secure and expected.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:105

Credential access and network transmission in one file

Expected behavior · high confidence

This code gets a login token and sends it to the app's own backend to load the initial data. That's how many apps work: you prove who you are to the server you actually use. Nothing is being sent to a stranger.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file retrieves a mobile authentication token via getMobileToken() and sends it as a Bearer Authorization header in a fetch request to the project's own backend bootstrap endpoint at `${baseUrl}/api/bootstrap`. This is standard authenticated API client behavior for a frontend application that communicates with its own server. The token is not sent to any third-party or uncontrolled destination; the baseUrl is obtained from getGatewayBaseUrl() which is a project-configured backend URL. There is no evidence of credential exfiltration, phishing, or malicious data flow. The scanner's co-occurrence of credential access and network transmission in the same function is expected for any authenticated RPC call.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/settings-api.ts:20

zizmor reported artipacked

Expected behavior · high confidence

The scanner thought this step might leak credentials via artifacts, but this workflow doesn't have any credentials to leak and the artifact upload is only for testing. No issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The scanner flagged `actions/checkout@v5` at line 93 with the `artipacked` rule, which warns about credential persistence through uploaded artifacts. However, the workflow has only `contents: read` permissions, no secrets, and the artifact upload (if any) is for a temporary npm tarball used only in CI smoke tests with 7-day retention. There are no credentials to persist, and the artifact step itself (`upload-artifact`) is not at this line. The warning is a false positive in this context.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:93

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line removes a system setting to simulate that no screen is available, so the test can verify the code handles that correctly. Nothing is sent anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 99 deletes process.env.WAYLAND_DISPLAY to simulate a headless environment for the hasLinuxDisplay test. This is a deliberate mutation of an environment variable to control the behavior of the function under test. No environment values are read or serialized here; it is a write operation for test isolation.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:99

zizmor reported cache-poisoning

Expected behavior · low confidence

This is a low-confidence warning about possible cache poisoning if the setup-node action uses caching. Since the workflow doesn't set up any caching, the risk is theoretical and very small.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: Line 132 uses 'actions/setup-node@v4' which may internally use caching. The zizmor 'cache-poisoning' rule flags potential vulnerability to cache poisoning attacks on dependency caches. However, this workflow does not explicitly configure caching for setup-node (no 'cache' input), and the project uses 'bun install --frozen-lockfile' which relies on its own lockfile rather than npm cache. No actual cache poisoning path is demonstrated.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release-npm.yml:132

JavaScript analysis reported javascript.xray.data-exfiltration

Expected behavior · high confidence

This is just a test file that imports a standard Node.js function to create temporary folders. No data is being stolen or sent anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration in this repository.

Contextual assessment: Detailed technical wording was omitted by the public report safety filter.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.data-exfiltration
File role: test
Source: services/api/test/provider-profile-transport.test.ts:3

zizmor reported artipacked

Expected behavior · low confidence

The system said credentials might be packed into artifacts, but the workflow only uploads the built application files, not any secret keys.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The artipacked rule flagged credential persistence via artifacts, but the workflow at lines 110-112 only uses actions/checkout@v5 with a ref. The artifact upload steps later upload only build outputs (tarballs, APKs) and do not include any secret or credential files. No credential exfiltration path is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: None.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:110-112

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The server reads a setting from an environment variable to find the folder where it stores user data. It does not send that folder path anywhere else. That is normal for a server that needs to know where to keep its data.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code reads environment variable VIBE_TAVERN_DATA_DIR to determine the user data directory, defaulting to a subdirectory of the project root. This value is used locally for file path resolution and is not serialized, transmitted, or exfiltrated to any external destination. This is standard and expected configuration behavior for a server that needs to locate user data.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: production
Source: services/api/src/server/prod-server.ts:36

Credential access and network transmission in one file

Expected behavior · high confidence

This code uses a secret token to talk to the app's own server. That's exactly what it's supposed to do. There's no sign the token is being stolen or sent anywhere else.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file retrieves an authentication token via getMobileToken and uses it as a Bearer token in fetch requests to the application's own API gateway (getGatewayBaseUrl). This is normal frontend-to-backend authentication for persona export, import, and avatar upload operations. The token is not sent to any external or attacker-controlled destination; it is sent solely to the application's own backend endpoints. No credential theft or exfiltration is demonstrated as the token's purpose is to authorize the request.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/persona-api.ts:125

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code saves the current value of an environment variable so it can be restored later. This is safe and expected.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 137 reads process.env.HOME to save its original value before a test. This is a standard test setup pattern. No data is exfiltrated; the value is only used locally to restore the environment.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:137

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is a controlled sandbox where users can write small dice-rolling scripts for the game. It's safe because the scripts cannot access the internet, the file system, or the rest of the app, and they are stopped if they run too long. This is exactly what the app intends to do.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The file uses `runInNewContext` from `node:vm` to execute user-defined dice scripts in a tightly sandboxed environment. The sandbox explicitly excludes dangerous globals (require, eval, fetch, process, setTimeout, Function, WebAssembly) and only exposes a limited allowlist (Math, JSON, Date, Array, Object, etc.) plus a dice-specific context with controlled roll and register functions. The VM is run with a timeout to prevent indefinite execution. No network, filesystem, or process access is granted. This is the intended design for running user-authored dice logic safely and matches the project's stated purpose of supporting custom dice scripts. The detection is a false positive for malicious or vulnerable behavior.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: production
Source: services/api/src/domain/scripts-engine/dice-script-sandbox.ts:164-167

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code saves the current value of an environment variable so it can be restored after the test. This is safe and expected.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 152 reads process.env.DISPLAY to save its original value before test mutation. This is a normal test setup pattern. No credential theft or serialization to external destinations occurs.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:152

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line removes a temporarily changed setting to leave the computer in the same state as before the test ran. Nothing is sent anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 94 deletes process.env.WAYLAND_DISPLAY in the afterEach teardown when origWayland was undefined. This restores the environment to its original state after a test that cleared the variable. No environment data is serialized or transmitted; it is purely a local test cleanup operation.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:94

Credential access and network transmission in one file

Expected behavior · high confidence

This file sends a login token to the app's own server to authorize attaching an image from the gallery. That is exactly how secure apps normally work — the token proves you are allowed to do this action, and it goes only to the app's own backend, not anywhere else.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file contains both a credential retrieval function (`getMobileToken`) and a network request (`fetch`) to the project's own backend gateway. This is standard API authentication: the client sends the mobile token as a Bearer token to authorize a server-side gallery asset promotion. The destination URL is constructed from `getGatewayBaseUrl()`, which is the project's own backend, not an external or unexpected endpoint. There is no evidence of exfiltration, redirection to a third-party server, or any concealed transmission of credentials. The behavior matches the documented purpose of the file, which is to attach gallery images as immutable chat attachments via a backend endpoint.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/lib/attach-from-gallery.ts:29

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code deletes an environment variable during test cleanup, which is a normal and safe testing practice.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: This candidate flags a `delete process.env.WAYLAND_DISPLAY` operation in a test's `afterEach` block (line 163). Same context as candidate 23a0d754 — it is part of a standard pattern to save and restore environment variables for test isolation. No data leaves the process; no security concern.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:163

Credential access and network transmission in one file

Expected behavior · high confidence

This code sends your login token to the app's own server so it can securely upload skill files. That's the normal and expected way to use an authentication token — it is not being stolen or sent somewhere shady.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file is a frontend API client for the Co-Author skill feature. It retrieves a mobile authentication token from getMobileToken() and attaches it as a Bearer token in a fetch request to the project's own backend gateway (getGatewayBaseUrl()/api/coauthor/skills/import). This is standard API authentication for an expected server endpoint. The token is not exfiltrated to an attacker-controlled or third-party destination; it is sent solely to the project's own server for the purpose of authorizing a multipart file upload. The scanner's credential-exfiltration rule is a false positive because it does not distinguish between legitimate authentication to the project's own backend and malicious credential theft.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/skill-api.ts:66

zizmor reported unpinned-uses

Expected behavior · high confidence

The CI workflow uses a stable major version of the Bun setup action. No security issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: zizmor flagged oven-sh/setup-bun@v2 as an unpinned action reference. Similar to other setup-bun steps, it uses a major version tag. No secrets or sensitive data are passed to this action. The job has read-only permissions.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/ci.yml:149

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a standard version tag for uploading build files. No danger shown.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses actions/upload-artifact@v4, a major version tag. First-party GitHub action; no demonstrated vulnerability.

Impact: none · Exploitability: unlikely

Developer action: None required.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:298

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code deletes an environment variable to simulate a headless Linux system during a test—a standard testing technique with no security implications.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: This candidate flags `delete process.env.DISPLAY` on line 172 within a test case that simulates a headless Linux environment. The test sets up the environment to verify the native dialog route returns `{ available: false }` without spawning a subprocess. The delete operation is essential for the test's logic and is performed in a controlled, local scope. No data is serialized or sent externally.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:162

zizmor reported artipacked

Expected behavior · low confidence

A scanner flagged a common checkout action as potentially unsafe, but this action just downloads code and doesn't handle any sensitive data. The artifact handling in the workflow is safe and temporary.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The zizmor artipacked rule flagged actions/checkout@v5 at line 178 in the smoke-npm job. actions/checkout does not perform artifact upload or download, and the job only downloads an artifact from a prior build step. No credentials are involved, permissions are contents:read, and artifacts are temporary. No credential exposure is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:178

zizmor reported artipacked

Expected behavior · high confidence

Another false positive from the artifact scanner. No credentials could be leaked.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: Same as candidate a03c6959228fbe98246ffaf41a01dbb0e5ba3486d72defb14403cf9ead33ee88 – the `artipacked` rule is applied to `actions/checkout@v5` at line 104 but no actual credential persistence risk exists. The workflow's permissions and lack of sensitive data make this a false positive.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:104

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This file lets user-made dice scripts run safely by giving them a tiny, locked-down environment inside the app. The script can only do math, use dice, and read some read-only info — it cannot touch the internet, your files, or your computer's internals. A time limit prevents scripts from hanging forever. This is the intended design, not a security bug.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The file uses Node's `vm.runInNewContext` to execute user-authored Dice scripts inside a tightly confined sandbox. The sandbox explicitly omits dangerous globals (require, process, fetch, eval, Function, setTimeout, WebAssembly, etc.) and provides only safe ECMAScript builtins plus a frozen Dice API (register, roll, frozen actor/priorAttempts). Both discovery and roll phases apply a timeout (default 5000ms). The orchestration snippet that locates and invokes the target check's resolve() function uses internal sandbox properties (`__registered`, `__targetCheckId`, `__rollOutput`, `__rollError`) that are not exposed to untrusted input. No network, filesystem, or process escape channel is present. This is a standard, carefully implemented sandbox for DSL execution and matches the project's stated purpose of allowing user-created dice mechanics in a local AI roleplay client.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: production
Source: services/api/src/domain/scripts-engine/dice-script-sandbox.ts:254-257

zizmor reported unpinned-uses

Expected behavior · medium confidence

A checkout action with a version number. This is normal.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Another unpinned reference to 'actions/checkout@v5' in the verify-windows job. Same reasoning as the previous unpinned-uses candidates.

Impact: none · Exploitability: unlikely

Developer action: Consider using a commit hash for supply-chain hardening.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:110

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code removes an environment variable that was set during a test to return the environment to its original state. This is normal and safe.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 145 deletes process.env.HOME as part of test teardown when the original value was undefined. This is a standard cleanup pattern. No sensitive data is involved; the operation is confined to the test.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:145

zizmor reported unpinned-uses

Expected behavior · medium confidence

The workflow uses a common version tag for the Bun setup action. This is typical.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Unpinned reference to 'oven-sh/setup-bun@v2' at line 99. The setup-bun action is used to install the Bun runtime. While pinning to a commit hash would be more secure, the major-version tag is standard practice and no evidence of compromise is presented.

Impact: none · Exploitability: unlikely

Developer action: Pin to a specific commit hash for enhanced security if desired.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:99

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The test removes the HOME variable if it didn't exist before, restoring the environment. Safe cleanup.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 132 deletes process.env.HOME when it was originally undefined, inside the linuxCmd test teardown. Proper cleanup, no credential involved.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:132

zizmor reported artipacked

Expected behavior · low confidence

The scanner worried that secrets might leak through the build files, but the workflow builds everything in a safe way and doesn't put secrets into the files that get published. There's no actual risk here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: The 'artipacked' rule warns about credential persistence through build artifacts. In this workflow, artifacts are produced internally from a verified commit and downloaded only in the same trusted workflow run. No secrets are included in the artifacts; the Android keystore secrets are used only in the build step and not uploaded. The scanner's low confidence and absence of a demonstrated attack path make this an expected behavior pattern.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:359-361

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The server reads a setting from an environment variable to decide which network address to listen on. It does not send that setting anywhere else. That is normal for any server program.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code reads environment variable VIBE_TAVERN_HOST to configure the server's listen host, defaulting to '0.0.0.0'. This value is used locally to bind the HTTP server and is not serialized, transmitted, or exfiltrated to any external destination. This is standard and expected configuration behavior for a server entry point.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: production
Source: services/api/src/server/prod-server.ts:49

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code removes an environment variable that was set during a test to return the environment to its original state. This is normal and safe.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: The code at line 161 deletes process.env.DISPLAY as part of test teardown when the original value was undefined. This is a standard cleanup pattern. No data is exfiltrated or compromised.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:161

JavaScript analysis reported javascript.xray.data-exfiltration

Expected behavior · high confidence

This is a harmless tool that creates test data on your computer's temporary folder. It doesn't send anything to the internet, steal passwords, or do anything suspicious.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration in this repository.

Contextual assessment: The file is a development-time script that generates a mock SillyTavern-style folder structure under a temporary directory for smoke tests. It uses standard Node.js APIs (tmpdir, mkdir, join, write) and does not make any network requests, send data, or access credentials. The scanner's data-exfiltration signal is a false positive; no exfiltration or credential theft occurs.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.data-exfiltration
File role: tooling
Source: scripts/bench/generate-small-mock.ts:4

Credential access and network transmission in one file

Expected behavior · high confidence

This code sends your login token to the app's own server to prove you're allowed to use it. That's what every app with accounts does—it's not stealing your credentials.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file is a frontend API client that retrieves an authentication token (via a redacted helper) and attaches it as a Bearer header in fetch requests to the project's own backend endpoints (e.g., /api/fs/native-dialog, /api/import/st-directory/stream). Both the origin of the token and the network sink are in the same module, which is normal for an API client. There is no evidence of transmission to third-party or unauthorized destinations. The token is used solely for the project's own authentication flow, as documented in the code comments.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: tavernkeeper 4
Rule: credential-exfiltration
File role: production
Source: apps/web/src/api/import-api.ts:127

zizmor reported artipacked

Expected behavior · low confidence

No credentials are being accidentally uploaded in the artifacts.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: Artipacked candidate at lines 96-98 where actions/checkout@v5 is used with a ref. As with candidate a8ff1c44, no credentials or secrets are packaged into artifacts. The artifact uploads are limited to build outputs. No demonstrated risk.

Impact: none · Exploitability: unlikely

Developer action: None.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:96-98

zizmor reported cache-poisoning

Expected behavior · low confidence

The scanner warned about possible cache tampering for a build tool, but there is no sign it has happened and the build process uses a locked dependency file for safety.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: The cache-poisoning candidate at line 113 flags a theoretical risk with `oven-sh/setup-bun@v2`. No evidence of cache poisoning exists, and the workflow uses `bun install --frozen-lockfile` which ensures dependency integrity. The scanner confidence is low, and no concrete exposure is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release.yml:113

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The code deletes an environment variable as part of a test setup; this is harmless and expected in unit tests.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: This candidate flags `delete process.env.WAYLAND_DISPLAY` on line 173 within the same test case as candidate c17ad735. It is part of the same headless-Linux simulation and test cleanup. No security concern; the operation is local and test-scoped.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:172

zizmor reported artipacked

Expected behavior · high confidence

The scanner thought credentials might leak through artifacts, but the workflow is safe. No secrets are used, and the only artifact is a test build.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: zizmor flagged potential credential persistence through artifacts ('artipacked') at line 148, which is actions/checkout@v5. No artifact upload occurs at that line; the artifact upload is at line 163 and is used for testing with no credentials in the artifact. The workflow has permissions: contents: read and no secrets are used. No demonstrated exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/ci.yml:148

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This line checks a saved copy of a system setting to decide whether to put it back after the test. It is not sending any data outside the program.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment in this repository.

Contextual assessment: Line 91 reads process.env.DISPLAY in the if-condition to decide whether to restore or delete it during test teardown. This is standard test cleanup that reads the saved origDisplay value (not the current environment) to conditionally restore the original variable. No serialization or transmission occurs.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner: javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
Rule: javascript.xray.serialize-environment
File role: test
Source: services/api/test/fs-native-dialog.test.ts:91

zizmor reported artipacked

Expected behavior · low confidence

No credentials are being packaged into build artifacts.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked in this repository.

Contextual assessment: Artipacked candidate at lines 57-59 for actions/checkout@v5 without a ref. The same reasoning: the workflow does not include any secret or credential in its artifact uploads. No evidence of credential persistence.

Impact: none · Exploitability: unlikely

Developer action: None.

Scanner: zizmor 1.28.0
Rule: artipacked
File role: tooling
Source: .github/workflows/release.yml:57-59

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

Detailed wording was omitted by the public report safety filter.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.

Contextual assessment: The file implements a sandboxed script execution engine using Node's vm.runInNewContext. The sandbox explicitly restricts globals to safe built-ins (Math, JSON, Date, Array, Object, etc.) and provides a context object with only intended read/write access to chat, character, lore, state, and utility functions. No require, process, global, Buffer, or timers are exposed. A 5-second timeout and filename attribution are applied. The project's stated purpose includes user-authored JavaScript scripts for custom behavior, and the sandbox is proportionate to that purpose. No evidence of actual exploitation or sandbox escape is present.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: opengrep 1.26.0
Rule: tavernkeeper.dynamic-execution.javascript-eval
File role: production
Source: services/api/src/domain/scripts-engine/script-sandbox.ts:208-211

zizmor reported cache-poisoning

Expected behavior · low confidence

Similar low-confidence cache poisoning warning for setup-bun. There's no evidence that caching is exploited or even actively used here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.

Contextual assessment: Line 128 uses 'oven-sh/setup-bun@v2' which may have built-in caching. The cache poisoning warning has low confidence and no demonstrated exposure in this workflow, as no explicit cache key or restore action is used. The bun installation is deterministic via 'bun install --frozen-lockfile'.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner: zizmor 1.28.0
Rule: cache-poisoning
File role: tooling
Source: .github/workflows/release-npm.yml:128

zizmor reported unpinned-uses

Expected behavior · high confidence

The workflow uses a common version tag for logging into Docker. Not a safety problem.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.

Contextual assessment: Uses docker/login-action@v3, a major version tag. Common practice; no evidence of compromise.

Impact: none · Exploitability: unlikely

Developer action: None required.

Scanner: zizmor 1.28.0
Rule: unpinned-uses
File role: tooling
Source: .github/workflows/release.yml:322

Related contextual observations

Multiple unpinned GitHub Actions in release pipeline

low risk · high confidence

Several steps in the release build process reference tools by a short version number instead of a fixed snapshot. If a tool's developers were compromised, the build could be silently altered. Pinning to exact commits prevents this risk.

Technical assessment

Five action references in the release workflow use mutable major-version tags instead of pinned commit SHAs. This includes `actions/checkout`, `oven-sh/setup-bun`, `actions/upload-artifact`, `actions/attest-build-provenance`. While no evidence of compromise exists, pinning to specific SHAs would eliminate the risk of future malicious updates to these tags, which is a standard supply-chain hardening practice.

Impact: low · Exploitability: unlikely

Developer action: Pin all third-party actions in the workflow to specific commit SHAs. Use a tool like `pin-github-action` or Dependabot to manage updates securely.

Sources:

.github/workflows/release.yml:113-144

Multiple unpinned GitHub Actions references

low risk · high confidence

Many of the actions used in the release workflow are specified by a major version number (like 'v5') rather than a unique version lock. This means the exact code that runs could change if the action author updates the tag. Pinning to a specific version makes the build more predictable and secure.

Technical assessment

Several GitHub Actions in this workflow are referenced using mutable major version tags (e.g., @v5, @v4, @v3, @v2) instead of immutable commit SHAs. This pattern allows action maintainers to change the behavior of a tag without notice, introducing a supply-chain risk. While the risk is low for official and widely-used actions, consistently pinning all third-party actions to commit SHAs is a security best practice that improves reproducibility and auditability.

Impact: low · Exploitability: unlikely

Developer action: For each unpinned action, replace the version tag with the commit SHA of the desired release. Set up Dependabot (or Renovate) to automatically create pull requests when new versions of pinned actions are available.

Sources:

Debug logger sends authentication token to debug endpoint

low risk · high confidence

The app includes a temporary debug logger that sends your login token to a debug logging feature on the same server. If the server keeps logs of these requests, the token could be accidentally stored.

Technical assessment

The devLog function (lines 8-17) sends the mobile token in the Authorization header to the project's own debug logging endpoint. While not exfiltration, this practice is a minor weakness because the token is included in requests to a logging endpoint, and server-side logs may capture the token. If the server logs are not properly secured, this could lead to token leakage. The code comment itself indicates it is temporary and should be removed.

Impact: low · Exploitability: unlikely

Developer action: Remove the devLog function and its calls before production release, or refactor to avoid sending authentication tokens to debug endpoints.

Sources:

apps/web/src/lib/dev-log.ts:8-17

Internal sandbox plumbing variables are intentionally writable

low risk · high confidence

The dice system uses hidden variables inside the sandbox to pass results back to the app after the script finishes. This is just how the code works safely, not a secret backdoor.

Technical assessment

The sandbox exposes `__registered`, `__targetCheckId`, `__rollOutput`, and `__rollError` so the appended orchestration snippet can read/write them. These are not accessible to user code directly (the orchestration is concatenated after user code and runs in the same context). The orchestration only writes to `__rollOutput` and `__rollError` after the user's resolve() function returns. This is a controlled communication channel between the orchestrator and the host code, not a vulnerability.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

services/api/src/domain/scripts-engine/dice-script-sandbox.ts:226-250

False positive from static analysis scanner

low risk · high confidence

The automated security scanner made a mistake. It thought importing a function to create temp folders was suspicious, but it's actually a normal thing to do in tests.

Technical assessment

Detailed technical wording was omitted by the public report safety filter.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

services/api/test/provider-profile-transport.test.ts:3

Coverage and limitations

Inventory: 1378 files · 87375651 bytes
Contextual coverage: 156 of 156 candidates assessed

JavaScript coverage

Status: Incomplete
Candidates: 1118 files · 10309997 bytes
Representations: 1118 raw · 36 decoded · 5 normalized · 0 bundle modules
Stage scans: 1117 raw signatures · 68 raw AST · 1103 raw OpenGrep · 41 derived signatures · 10 derived AST · 40 derived OpenGrep

Unresolved JavaScript stages

apps/web/bun-plugin-build-config.ts — raw-ast / parse
apps/web/bun-plugin-data-component.ts — raw-ast / parse
apps/web/bun-plugin-web-assets.ts — raw-ast / parse
apps/web/data-component-transform.ts — raw-ast / parse
apps/web/dev-server.ts — derived-ast / parse
apps/web/dev-server.ts — normalize / unsupported
apps/web/dev-server.ts — raw-ast / parse
apps/web/src/api/ai-assistant-api.ts — raw-ast / parse
apps/web/src/api/asset-api.ts — raw-ast / parse
apps/web/src/api/character-api.ts — raw-ast / parse
apps/web/src/api/chat-api.ts — raw-ast / parse
apps/web/src/api/client.ts — raw-ast / parse
apps/web/src/api/dice-api.ts — raw-ast / parse
apps/web/src/api/gallery-api.ts — raw-ast / parse
apps/web/src/api/import-api.ts — raw-ast / parse
apps/web/src/api/lorebook-api.ts — raw-ast / parse
apps/web/src/api/normalize.test.ts — raw-ast / parse
apps/web/src/api/normalize.ts — raw-ast / parse
apps/web/src/api/persona-api.ts — raw-ast / parse
apps/web/src/api/preset-api.ts — raw-ast / parse
apps/web/src/api/provider-api.ts — raw-ast / parse
apps/web/src/api/provider-stream-error.ts — raw-ast / parse
apps/web/src/api/proxy-api.ts — raw-ast / parse
apps/web/src/api/quota-api.ts — raw-ast / parse
apps/web/src/api/runtime-api.ts — raw-ast / parse
apps/web/src/api/script-api.ts — raw-ast / parse
apps/web/src/api/settings-api.ts — raw-ast / parse
apps/web/src/api/skill-api.test.ts — raw-ast / parse
apps/web/src/api/skill-api.ts — raw-ast / parse
apps/web/src/api/stream.ts — raw-ast / parse
apps/web/src/api/types.ts — raw-ast / parse
apps/web/src/api/unwrap.ts — raw-ast / parse
apps/web/src/app-client.ts — raw-ast / parse
apps/web/src/build-config.test.ts — raw-ast / parse
apps/web/src/build-config.ts — raw-ast / parse
apps/web/src/bun-env.d.ts — raw-ast / parse
apps/web/src/components/build/BuildMode.tsx — raw-ast / parse
apps/web/src/components/build/VersionSwitcher.tsx — raw-ast / parse
apps/web/src/components/build/editors/AvatarDescriptionField.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/AvatarDescriptionField.tsx — raw-ast / parse
apps/web/src/components/build/editors/CharacterForm.tsx — raw-ast / parse
apps/web/src/components/build/editors/DiceAssignment.tsx — raw-ast / parse
apps/web/src/components/build/editors/DiceScriptTester.tsx — raw-ast / parse
apps/web/src/components/build/editors/GalleryAccordion.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/GalleryAccordion.tsx — raw-ast / parse
apps/web/src/components/build/editors/GalleryGrid.tsx — raw-ast / parse
apps/web/src/components/build/editors/GalleryLightbox.tsx — raw-ast / parse
apps/web/src/components/build/editors/GalleryViewer.tsx — raw-ast / parse
apps/web/src/components/build/editors/InsightsPanel.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/InsightsPanel.tsx — raw-ast / parse
apps/web/src/components/build/editors/LoreEntryEditor.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/LoreEntryEditor.tsx — raw-ast / parse
apps/web/src/components/build/editors/LoreEntryList.tsx — raw-ast / parse
apps/web/src/components/build/editors/LorebookAccordion.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/LorebookAccordion.tsx — raw-ast / parse
apps/web/src/components/build/editors/LorebookEditor.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/LorebookEditor.tsx — raw-ast / parse
apps/web/src/components/build/editors/LorebookImportModal.tsx — raw-ast / parse
apps/web/src/components/build/editors/ObjectiveConfig.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/ObjectiveConfig.tsx — raw-ast / parse
apps/web/src/components/build/editors/SceneHistoryBackfill.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/SceneHistoryBackfill.tsx — raw-ast / parse
apps/web/src/components/build/editors/ScriptEditor.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/ScriptEditor.tsx — raw-ast / parse
apps/web/src/components/build/editors/ScriptTester.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/ScriptTester.tsx — raw-ast / parse
apps/web/src/components/build/editors/TrackerConfig.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/TrackerConfig.tsx — raw-ast / parse
apps/web/src/components/build/editors/VibeMdView.test.tsx — raw-ast / parse
apps/web/src/components/build/editors/VibeMdView.tsx — raw-ast / parse
apps/web/src/components/build/editors/activation-test-panel.tsx — raw-ast / parse
apps/web/src/components/build/editors/character-filter-picker.tsx — raw-ast / parse
apps/web/src/components/build/editors/lore-entry-reorder.test.ts — raw-ast / parse
apps/web/src/components/build/editors/lore-entry-reorder.ts — raw-ast / parse
apps/web/src/components/build/editors/lore-keys-ai-pill.tsx — raw-ast / parse
apps/web/src/components/build/editors/lorebook-create-body.test.ts — raw-ast / parse
apps/web/src/components/build/editors/lorebook-create-body.ts — raw-ast / parse
apps/web/src/components/build/editors/script-api-reference.tsx — raw-ast / parse
apps/web/src/components/build/editors/script-templates/index.ts — raw-ast / parse
apps/web/src/components/build/editors/thumbnail-crop.test.ts — raw-ast / parse
apps/web/src/components/build/editors/thumbnail-crop.ts — raw-ast / parse
apps/web/src/components/build/editors/use-lorebook-editor-state.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-folding.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-greetings.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-locked-headings.test.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-locked-headings.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-macros.test.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-macros.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-sync.test.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-sync.ts — raw-ast / parse
apps/web/src/components/build/editors/vibe-md-theme.ts — raw-ast / parse
apps/web/src/components/build/fields/DepthPromptField.tsx — raw-ast / parse
apps/web/src/components/build/fields/TagsField.tsx — raw-ast / parse
apps/web/src/components/build/fields/TextAreaField.tsx — raw-ast / parse
apps/web/src/components/build/fields/field-label.tsx — raw-ast / parse
apps/web/src/components/build/trace-json-downloads.test.tsx — raw-ast / parse
apps/web/src/components/build/trace-json-downloads.tsx — raw-ast / parse
apps/web/src/components/build/trace-payload-view.test.tsx — raw-ast / parse
apps/web/src/components/build/trace-payload-view.tsx — raw-ast / parse
apps/web/src/components/chat/AssistantContextHeader.test.tsx — raw-ast / parse

Tools

inventory 0.1.0 — completed
tavernkeeper-static 4 — completed
gitleaks 8.30.1 — completed
opengrep 1.26.0 — completed
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1 — completed
osv-scanner 2.4.0 — completed
zizmor 1.28.0 — completed
malcontent 1.25.7 — completed

Limitations

This advisory review cannot prove the absence of unknown behavior.
JavaScript analysis was incomplete, so this first-filter scan supports no clean conclusion about unobserved behavior.
One or more scanner candidates refer to non-text artifacts. Their size, digest, and scanner metadata were verified, but raw contents were not provided to the contextual model.

Technical scan identity

Full commit: 5c3bea0e6e4a891cb48c5bcefabcbca7785746e1
Completed: Aug 10, 2026
History depth: 20 commits
Method: Deterministic evidence with contextual review
Reviewer: nano-gpt.com · deepseek/deepseek-v4-flash:thinking
Scanner: 0.1.0
Scanner policy: 4
Rule catalog: 1
Contextual policy: 4
Ecosystem context: sillytavern-community-v1
Prompt: contextual-review-v7
Assessment schema: contextual-assessment-v2
Review provenance: 44 fresh / 0 reused groups · 156 fresh / 0 reused candidates
Review source reports: none
Review usage: 862302 input · 126966 output · 16096 cache read · 0 reasoning tokens
Report: f0866aac17ff18b826733e6b10034744643f088da5eabc511476d8c3dce65d42