TavernKeeper Scan Report

Noineri/vibe_tavern

Commit dbd319a Reviewed

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 126 low

What this review found

No material or immediate-danger item was identified.

Minor cautions

JavaScript analysis reported javascript.xray.unsafe-regex

Minor caution · medium confidence

A dice-rolling script uses a complex-looking pattern to recognize commands like /roll d20. While the pattern might be slightly inefficient, it's not dangerous and won't crash things in practice.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.

Contextual assessment: The regex pattern used for parsing dice commands is flagged by JS-X-Ray as potentially unsafe, likely due to the use of the 'g' flag and multiple optional capture groups. However, the regex is structurally simple and operates on short user chat messages. It does not contain nested quantifiers or overlapping alternatives that would cause catastrophic backtracking. The practical risk of ReDoS is negligible, and any denial of service would be limited to the client's own browser tab.

Impact: low · Exploitability: unlikely

Developer action: Consider simplifying the regex or adding input length limits for defense-in-depth, though this is not a priority.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.unsafe-regex
File role
generated
Source
apps/web/src/components/build/editors/script-templates/dice.js:17
Deterministic technical evidence (75)
  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:328

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:270

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:57

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:267

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:74

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:119

  • Dependency advisory GHSA-67mh-4wv8-2f99:pkg:100a52fb5850b2ff8a7f76c7 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:219

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:86

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:207

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:316

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:287

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:337

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:96

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-latest.yml:52

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:250

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:219

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:270

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:193

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:292

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:132

  • zizmor reported template-injection · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:286

  • Dependency advisory GHSA-67mh-4wv8-2f99:pkg:0ad9c1081b9e42257b771395 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • Dependency advisory GHSA-rgw5-rvv9-x895:pkg:c15eeb4b6498ad284f4ce31d applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:132

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:99

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:205

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-npm.yml:132

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:144

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:108

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:218

  • zizmor reported template-injection · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:284

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:188

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:109

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:359

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-npm.yml:128

  • Dependency advisory GHSA-395f-4hp3-45gv:pkg:f8812e56262cb0bece83a469 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-npm.yml:79

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:187

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:319

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:62

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:75

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-npm.yml:132

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:132

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:247

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:219

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:129

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:63

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-latest.yml:51

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:375

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:205

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:97

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:298

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:208

  • Dependency advisory GHSA-gpj5-g38j-94v9:pkg:21ad97366e3942078eb532b3 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:110

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:215

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:99

  • Dependency advisory GHSA-mh99-v99m-4gvg:pkg:17a4bca76c8dccd42bb43bfa applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: bun.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:123

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:87

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:363

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:161

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:113

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:141

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:98

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:172

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:157

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:221

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:345

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release-npm.yml:128

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:133

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/ci.yml:158

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:113

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:322

Contextual expected matches (50)

zizmor reported artipacked

Expected behavior · high confidence

This is a routine CI step that downloads the source code before building the Android app. The scanner warning about credentials in artifacts does not apply here because the uploaded app files do not contain any secret keys or passwords.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The zizmor 'artipacked' rule flagged a step in the build-android job at lines 161–163 (actions/checkout@v5). This rule generally warns when a workflow with access to secrets later uploads artifacts, but the provided evidence shows no credential data is included in the uploaded artifacts. The secrets (ANDROID_KEYSTORE_BASE64, passwords, alias) are used only during the build process—they are decoded to a temporary keystore, used to sign the APK, and the keystore is not packaged into the output. The artifacts uploaded (APK, tarball, installer) are standard release builds. No credential exfiltration, persistence, or unauthorized data flow is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported adhoc-packages

Expected behavior · high confidence

The workflow installs the latest version of npm to handle publishing the software. This is a normal part of the release process and does not pose a security risk.

Technical evidence

Scanner reason: zizmor matched workflow-security rule adhoc-packages. The match applies to this repository.

Contextual assessment: The step 'npm install -g npm@latest' upgrades the npm CLI to support OIDC trusted publishing, which is a standard and necessary part of this workflow. The installation uses the latest tag without pinning, but the workflow runs on a GitHub-hosted ephemeral runner with minimal permissions (contents: read, id-token: write). There is no secret exposure or malicious intent; this is routine CI/CD behavior.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

The workflow checks out the code from GitHub, which is a standard first step. No passwords or keys are saved into any file that gets uploaded, so there is no risk.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The scanner flagged an actions/checkout step as potentially persisting credentials via artifacts. However, this checkout step retrieves the repository source code without any credential handling. The workflow uses OIDC-based trusted publishing and does not store secrets in artifacts. The artifact upload steps later upload only build outputs, not credentials. The rule 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/release-npm.yml:79-83

zizmor reported superfluous-actions

Expected behavior · high confidence

The workflow uses a community-made action for creating releases instead of the built-in one. This isn't a security problem, just a style choice.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: The superfluous-actions finding flags that the softprops/action-gh-release action could be replaced by GitHub's built-in release functionality, but this is a code quality/style issue, not a security vulnerability. The action is pinned and widely used.

Impact: none · Exploitability: unlikely

Developer action: Consider using the built-in GitHub release creation to reduce third-party dependency, but not required for security.

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 fake key used only for testing, not a real secret. It's not used in the actual app.

Technical evidence

Scanner reason: Gitleaks matched secret-detection rule private-key. The match applies to this repository.

Contextual assessment: This file is a test fixture (provider-proxy-key.pem) located in the test/fixtures directory. The content is a dummy or test-only key used for testing provider proxy functionality. There is no evidence it is a real, usable credential or that it is shipped to users. Test fixture keys are standard practice and pose no risk.

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 artipacked

Expected behavior · high confidence

The scanner flagged a routine step that downloads the code onto the CI runner. This is normal and does not leak or store any login information.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The line flagged by the zizmor 'artipacked' rule is a standard `actions/checkout@v5` step that retrieves repository contents. No artifacts are uploaded at this point; the only artifact upload in the workflow is an npm tarball with a 7-day retention. No credential material is exposed or persisted through this step.

Impact: none · Exploitability: unlikely

Developer action: none

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

OpenGrep reported tavernkeeper.persistence.startup-modification

Expected behavior · high confidence

The test checks that the updater correctly reads release notes that mention 'Faster startup'. That's just sample text used in the test. Nothing is actually changing startup behavior.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification. The match applies to this repository.

Contextual assessment: The signal matches a TavernKeeper rule for 'startup-modification' at line 60, where the test asserts that parsed release notes equal a hardcoded string containing 'Faster startup'. This is a pure assertion on test data within a characterization test for the updater's parseRelease function. No actual persistence modification occurs; the string is part of a mocked GitHub release payload.

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

zizmor reported artipacked

Expected behavior · high confidence

The workflow checks out the code to build the Linux release. This is normal and does not expose any secrets.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The alert at lines 129-131 (build-linux job) flags actions/checkout@v5 with a ref from job outputs. This is the same pattern as other build jobs. The workflow does upload artifacts later (lines 144-149), but those artifacts are build outputs (tarball) attested with build provenance, not credentials. No secret or credential is written into the artifact. The low-confidence artipacked rule does not demonstrate actual credential persistence.

Impact: none · Exploitability: unlikely

Developer action: none

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

malcontent reported anti-static-xor-terms

Expected behavior · medium confidence

Another font file was flagged by the scanner for looking suspicious, but without seeing the actual data, this is not a confirmed risk. It is likely a normal font.

Technical evidence

Scanner reason: malcontent matched behavioral-analysis rule anti-static-xor-terms. The match applies to this repository.

Contextual assessment: Same as group e3c25489: the malcontent scanner flagged XOR-obfuscated terms in a font file, but metadata-only analysis precludes confirming any malicious behavior. Font files routinely include encoded data. No demonstrated exposure.

Impact: none · Exploitability: unlikely

Developer action: Optionally verify font integrity from official source.

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

zizmor reported artipacked

Expected behavior · high confidence

This is a normal code checkout for the self-update test job. It does not expose or store any credentials.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The flagged line is a standard `actions/checkout@v5` step in the selfupdate-npm job. It only retrieves repository code; no artifacts are uploaded at this point. The scanner rule produces 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:218

Credential access and network transmission in one file

Expected behavior · high confidence

The app uses a security token to stream chat messages from its own server.

Technical evidence

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

Contextual assessment: The file uses getMobileToken() to authenticate a fetch request to the project's own backend SSE streaming endpoints. This is normal for streaming AI chat responses from the local backend.

Impact: none · Exploitability: unlikely

Developer action: none

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

OpenGrep reported tavernkeeper.persistence.startup-modification

Expected behavior · high confidence

The test creates fake release notes that say 'Faster startup' to verify the parsing logic. It's just dummy data in a test, not an actual change to the program.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification. The match applies to this repository.

Contextual assessment: The signal matches a TavernKeeper rule for 'startup-modification' at line 30, where a helper function constructs a mock release body containing 'Faster startup'. This is test fixture data used to simulate a GitHub API response. No persistence modification happens; the string never reaches any runtime code that modifies startup behavior.

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 a data file that tells the app how to break text into tokens for AI models. It's just plain information—it can't run any code or change how the app starts up. The security warning was a mistaken alert.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification. The match applies to this repository.

Contextual assessment: The OpenGrep rule for startup persistence modification triggered on a static JSON tokenizer configuration file. The file contains a BPE tokenizer vocabulary (version, added_tokens, pre_tokenizer, model, etc.) and is read-only data. It is not executable and contains no code paths that modify startup behavior. The rule likely matched on structural patterns (e.g., 'added_tokens') unrelated to actual persistence. No harmful modification or execution is present.

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

Bidirectional text control detected in source

Expected behavior · high confidence

This is just a data file for the AI model's tokenizer. The unusual character is simply one of the many symbols the tokenizer recognizes, not a hidden code.

Technical evidence

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

Contextual assessment: The file is a JSON tokenizer vocabulary (Mistral model) mapping tokens to IDs. The bidirectional control character (U+202E) appears as a token for a Unicode character in the vocabulary, not as obfuscation or executable code. Static data files for tokenizers commonly include such Unicode tokens. No executable context or disguised logic.

Impact: none · Exploitability: unlikely

Developer action: none

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

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The server reads settings from environment variables to know where to find files and which port to use. This is standard and safe.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.

Contextual assessment: The production server entry point reads several environment variables (VIBE_TAVERN_ROOT_DIR, VIBE_TAVERN_DATA_DIR, VIBE_TAVERN_HOST, VIBE_TAVERN_PORT) to configure paths and listen options. This is normal runtime configuration, not credential serialization or exfiltration. The scanner signal is a static analysis false positive.

Impact: none · Exploitability: unlikely

Developer action: none

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

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 the same authentication token the app normally uses. It's not sending your login info to a third party; it's just logging for debugging purposes.

Technical evidence

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

Contextual assessment: The devLog function sends a POST request to the application's own backend gateway (/api/debug/send-log) using the mobile token for authentication. This is a legitimate internal debug logging endpoint, not external data exfiltration. The credential source and network transmission are co-located by design for authenticated client-to-server communication within the same application, which is standard for a local AI roleplay client that stores API keys and tokens locally and communicates with its own backend.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
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 a unit test that creates a temporary folder on your computer to test database features. It doesn't send any data anywhere or access your credentials.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration. The match applies to this repository.

Contextual assessment: This is a test file that uses Node.js standard library tmpdir to create temporary directories for isolated database testing. The static analysis signal is a false positive — tmpdir is a standard OS temp directory and is used here solely for test isolation. There is no network activity, credential handling, or data exfiltration in this test code.

Impact: none · Exploitability: unlikely

Developer action: none

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

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The server reads a setting from the environment to know which network address to use. This is normal.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.

Contextual assessment: The file reads the environment variable VIBE_TAVERN_HOST to configure the listen address. This is a standard server configuration pattern, not credential serialization. The scanner signal is a static analysis false positive.

Impact: none · Exploitability: unlikely

Developer action: none

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

malcontent reported anti-static-xor-terms

Expected behavior · medium confidence

A security scan found a suspicious pattern in a font file that could indicate hidden code. However, font files often look suspicious to scanners. Since we couldn't examine the actual file contents, we cannot confirm any issue. The font is likely a well-known font from the Nerd Font project.

Technical evidence

Scanner reason: malcontent matched behavioral-analysis rule anti-static-xor-terms. The match applies to this repository.

Contextual assessment: The malcontent scanner detected XOR-obfuscated terms in a binary font file (JetBrainsMonoNLNerdFont-Bold.ttf). However, the artifact is metadata-only; raw content was not inspected. Font files, especially Nerd Font variants, commonly contain compressed or encoded data that can trigger false positives in static analysis. No concrete threat path is demonstrated without artifact content review.

Impact: none · Exploitability: unlikely

Developer action: If desired, verify the font file origin from the official JetBrains Mono Nerd Font release to confirm integrity.

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

This is just setting up the server's host address, nothing shady.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.

Contextual assessment: The referenced line (72) assigns the host string from environment or default. There is no suspicious external link or network request. The scanner signal is a static analysis false positive.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-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

The app uses a login token to talk to its own backend when uploading character avatars. That token stays on your machine and is only sent to the backend server that runs alongside the app.

Technical evidence

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

Contextual assessment: The file retrieves a local mobile auth token via getMobileToken() and sends it in an Authorization header to backend endpoints under the same local gateway (getGatewayBaseUrl()). The token never leaves the local process; the fetch targets are the project's own API routes for avatar upload and gallery operations. This is standard frontend-to-backend authentication for a single-host application, not credential exfiltration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
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

When the app logs debug info, it sends a small message to its own backend using the same login token. No data goes outside your computer.

Technical evidence

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

Contextual assessment: The postSendDebug function retrieves a mobile auth token via getMobileToken() and sends it in an Authorization header to the local backend endpoint /api/debug/send-log. This is a client-side debug logging mechanism that transmits only non-sensitive event names and timestamps to the same local server. The token is never sent to an external destination. Normal first-party authenticated request.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
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

The test file reads an environment variable to see if a Linux display is running. That's exactly what the real code does to decide whether to open a file picker window. No secrets are being stolen.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.

Contextual assessment: The signal flags access to process.env.DISPLAY inside a test file for the hasLinuxDisplay helper. This helper is designed to check whether a Linux graphical session is present, which is a legitimate and necessary capability for a native file dialog route that must decide whether to spawn a GUI picker. The test file saves and restores env variables in afterEach hooks; no credential or sensitive data is read or transmitted. The scanner signal is a false positive for 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_families-1
Rule
javascript.xray.serialize-environment
File role
test
Source
services/api/test/fs-native-dialog.test.ts:87

Credential access and network transmission in one file

Expected behavior · high confidence

The app gets a login token from its own server and sends it back to upload a file. This is normal and secure; the token never leaves your own computer.

Technical evidence

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

Contextual assessment: The tavernkeeper credential-exfiltration rule flagged that a mobile token is retrieved and then sent as a Bearer token in a fetch call within the same file. This is legitimate client-server authentication for asset uploads to the user's own local gateway server. There is no exfiltration to an external destination; the token is used to authenticate against the same server that issued it.

Impact: none · Exploitability: unlikely

Developer action: none

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

JavaScript analysis reported javascript.download-to-execution

Expected behavior · high confidence

This is a loading screen that checks if the server is ready and then reloads into the main app. It's not doing anything suspicious.

Technical evidence

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

Contextual assessment: The loading placeholder serves a static HTML page with inline scripts that poll the same-origin /health endpoint and reload the page when the server is ready. The fetch URL is not attacker-controlled and the reload is a standard pattern for waiting on server startup. The scanner correlation of network retrieval and page reload is benign.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

A security tool warned that credentials might be saved in build artifacts, but the workflow only saves the program files, not any passwords or API keys. This is a false alarm.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The zizmor artipacked finding flags credential persistence through GitHub Actions artifacts, but the workflow only uploads build binaries (APK, installer, zip) and never secrets. The GITHUB_TOKEN used in docker login is a short-lived token scoped to the job. No credentials are embedded in artifacts.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

This is a standard CI step that checks out the code before building the Windows version. The scanner warning about credentials in artifacts is not a real concern here because the uploaded installer and zip files do not include any private keys or passwords.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The zizmor 'artipacked' rule flagged a step in the build-windows job at lines 267–269 (actions/checkout@v5). The job has access to the repository secrets only through the GITHUB_TOKEN and builds Windows artifacts (installer and zip). No credential data is written into these artifacts; they are standard distribution files. The artifact uploads later in the job do not contain any secret material. There is no evidence of credential persistence, exfiltration, or malicious behavior.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

This is just the CI system downloading the project code to run tests. It does not expose or store any secrets.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This is another standard `actions/checkout@v5` step in the test-linux job. It only pulls the repository code and does not produce or upload any artifacts. No credential exposure occurs.

Impact: none · Exploitability: unlikely

Developer action: none

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

JavaScript analysis reported javascript.xray.shady-link

Expected behavior · high confidence

This is just setting the server's host address, nothing suspicious.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.

Contextual assessment: The referenced line (49) assigns the host string from environment or default. There is no suspicious external link or network request. The scanner signal is a static analysis false positive.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

The scanner mistakenly flagged a routine code checkout step in the Windows build job. It does not leak or persist any credentials.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The flagged line is a standard `actions/checkout@v5` step in the build-windows job. It only retrieves repository code; no artifacts are uploaded at this line. The scanner rule is producing a false positive on an ordinary checkout action.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

Another normal checkout used for the Docker build job. It does not leak or persist any login information.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This is a standard `actions/checkout@v5` step in the build-docker job. It only retrieves repository source code; no artifacts are uploaded. The scanner incorrectly flags this as credential persistence.

Impact: none · Exploitability: unlikely

Developer action: none

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

Credential access and network transmission in one file

Expected behavior · high confidence

The app uses a security token to talk to its own server, which is exactly what it should do. No suspicious external connections.

Technical evidence

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

Contextual assessment: The file obtains an authentication token via getMobileToken() and includes it as a Bearer header in a fetch request to the project's own backend endpoint /api/bootstrap. This is standard practice for a frontend communicating with its own authenticated API; there is no indication that credentials are sent to any third-party or unintended destination.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

The code checkout step on the Windows test runner is normal. It does not upload or leak any credentials.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This is a standard `actions/checkout@v5` step in the test-windows job. It only retrieves the repository code; no artifacts are uploaded at this line. The scanner rule is triggered by the action name itself, but no credential persistence is present.

Impact: none · Exploitability: unlikely

Developer action: none

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

JavaScript analysis reported javascript.xray.data-exfiltration

Expected behavior · high confidence

This test file uses a standard Node.js function to create a temporary folder for testing. It does not send any data anywhere, and the flagged line is just a normal import. The security warning is a false alarm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration. The match applies to 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_families-1
Rule
javascript.xray.data-exfiltration
File role
test
Source
services/api/test/provider-profile-transport.test.ts:3

zizmor reported artipacked

Expected behavior · high confidence

The scanning tool falsely labeled a common code download step as risky. No actual credential exposure happens here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The flagged line is a standard `actions/checkout@v5` step in the build-android job. It only clones the repository and does not upload any artifacts. The zizmor 'artipacked' rule incorrectly flags well-known checkout actions as credential persistence.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

The workflow gets a copy of the code to run tests on it. No passwords or secrets are stored in any file that gets saved or uploaded, so there is no danger.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The scanner flagged an actions/checkout step in the verify-windows job as potential credential persistence through artifacts. However, this step only checks out the repository source code. No secrets or credentials are involved, and no artifacts are created in this job. The later artifact upload steps in build jobs upload build outputs, not credentials. This is a false positive.

Impact: none · Exploitability: unlikely

Developer action: none

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

Credential access and network transmission in one file

Expected behavior · high confidence

This file works like a typical app login: it gets a security token and sends it to the app's own server to identify the user. The token goes only to the app's backend, not to any outside website, so this is normal behavior for a secure app.

Technical evidence

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

Contextual assessment: The file obtains a bearer token via getMobileToken() and sends it in Authorization headers to the application's own backend API endpoints (e.g., /api/personas/import). This is standard client-server authentication for a single-page application. The token is not sent to any third-party or unexpected destination. The base URL is derived from getGatewayBaseUrl(), which is controlled by the application configuration. There is no evidence of credential exfiltration or malicious data flow.

Impact: none · Exploitability: unlikely

Developer action: none

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

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This file runs dice game scripts in a locked-down virtual sandbox. It only lets the scripts do basic math, use dice rolling, and register checks. It blocks dangerous actions like accessing the internet, reading files, or changing the app's chat. This is exactly what you want for running user-made dice rules safely.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval. The match applies to this repository.

Contextual assessment: The file uses Node.js `runInNewContext` to execute user-defined dice scripts in an isolated sandbox. The sandbox explicitly excludes dangerous APIs (fetch, require, process, globalThis, eval, Function, setTimeout, etc.) and only exposes a curated set of standard globals (Math, JSON, Date, etc.) plus a Dice-only context with `register` and `roll` methods. Both discovery and roll functions are wrapped in try-catch with a configurable timeout. The orchestration snippet is appended but runs inside the same sandbox with no additional privileges. This is a well-documented, intentional design for executing user-authored dice logic without host access.

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

Credential access and network transmission in one file

Expected behavior · high confidence

The app uses a security token when attaching images from your gallery to a chat.

Technical evidence

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

Contextual assessment: The file uses getMobileToken() to authenticate a fetch request to the project's own backend endpoint /api/characters/:cid/assets/:rowId/promote-to-attachment. This is a legitimate backend operation to promote a gallery asset, and credentials are not exfiltrated.

Impact: none · Exploitability: unlikely

Developer action: none

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

Credential access and network transmission in one file

Expected behavior · high confidence

The app uses a security token when sending skill files to its own server.

Technical evidence

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

Contextual assessment: The file uses getMobileToken() to authenticate a fetch request to the project's own backend endpoint /api/coauthor/skills/import. This is a legitimate API call for importing skill files, and credentials are not exfiltrated.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

Normal code checkout for the smoke test job. No credentials are at risk from this step.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This is a standard `actions/checkout@v5` step in the smoke-npm job. It downloads the repository code; the artifact consumed by this job (npm-tarball) is a short-lived build output with a 7-day retention and contains no credentials. The checkout step itself poses no risk.

Impact: none · Exploitability: unlikely

Developer action: none

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

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This is another part of the dice-rolling system that safely runs user scripts in a sandbox. It's designed to prevent any harmful behavior.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval. The match applies to this repository.

Contextual assessment: Same file as previous candidate, but this instance is in the 'executeDiceRoll' function (line 254). It also uses runInNewContext to execute the dice script code concatenated with an internal orchestration snippet. The sandbox configuration is identical to the discovery phase: limited globals, frozen context objects, timeout. The orchestration code safely finds and invokes the target check's resolve() function. This is expected behavior for the dice system and does not constitute a security vulnerability.

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 artipacked

Expected behavior · high confidence

Same false alarm as the first group: the tool worried about credentials in artifacts, but the workflow only handles program files.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: The artipacked finding flags credential persistence through artifacts at the checkout step, but this is a false positive. The publish job downloads build artifacts (binaries) and creates a draft release. No credentials are leaked or persisted.

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.data-exfiltration

Expected behavior · high confidence

This is a harmless test script that creates fake data in a temporary folder to check how progress bars look. It uses a standard Node.js feature to find the temporary folder location. There is no data theft or security risk.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration. The match applies to 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_families-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

The frontend uses a token to log in to its own backend server when performing imports. This is normal behavior for any app that needs to authenticate its requests. The token stays within the application and is not sent to any outside or malicious service.

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 bearer token via getMobileToken() from the client module and attaches it as an Authorization header in HTTP requests to the local backend API endpoints (e.g., /api/fs/native-dialog, /api/import/st-directory/stream). This is standard client-server authentication for a local application where the frontend authenticates to its own backend server. The destination URL is derived from getGatewayBaseUrl(), which resolves to the local server. No credentials are sent to external or unauthorized destinations. The scanner rule 'credential-exfiltration' flags co-location of credential access and network transmission, but here the transmission is to the application's own backend, not to an attacker-controlled host.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

Another normal code checkout that the scanner incorrectly flagged. It does not expose or store any secrets.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This is a standard `actions/checkout@v5` step in the build-linux job. It retrieves repository source code and does not produce or upload any artifacts. No credentials are at risk.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

The workflow retrieves the code to run checks on it. No sensitive information is leaked or saved in any artifact file, so it's safe.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This candidate flags the actions/checkout step in the verify-linux job. As with the other artipacked alerts, this checkout retrieves source code without credential handling. No secrets are written to artifacts. The alert 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/release.yml:96-98

zizmor reported artipacked

Expected behavior · high confidence

The workflow gets the code to verify the version. No secrets or credentials are exposed or saved in any artifact, so there is no security issue.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This candidate flags the actions/checkout step in the version job. Again, this is a standard checkout without credential handling or artifact creation. The alert is a false positive.

Impact: none · Exploitability: unlikely

Developer action: none

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

zizmor reported artipacked

Expected behavior · high confidence

Normal checkout step for the npm packaging pipeline. No secrets are exposed or stored by this action.

Technical evidence

Scanner reason: zizmor matched workflow-security rule artipacked. The match applies to this repository.

Contextual assessment: This is a standard `actions/checkout@v5` step in the build-npm job. It clones the repository and does not upload any artifacts at this point. The intentional artifact upload later (npm tarball with 7-day retention) is clearly documented and does not involve credential exposure.

Impact: none · Exploitability: unlikely

Developer action: none

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

OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval

Expected behavior · high confidence

This file runs user-written scripts in a restricted sandbox, which is a core feature of the app. The code is not hidden or malicious; it is the expected way scripts are executed.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval. The match applies to this repository.

Contextual assessment: The file uses node:vm's runInNewContext to execute user-authored JavaScript scripts within a carefully constructed sandbox that limits globals, provides specific context objects (chat, character, lore, state, shared, persona, utility), and enforces a 5-second timeout. This is the intended design of the scripting engine, not a hidden execution vector. No evidence of attacker-controlled code injection or malicious 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/script-sandbox.ts:208-211

Coverage and limitations

JavaScript coverage

Unresolved JavaScript stages

Tools

Limitations

Technical scan identity