No material or immediate-danger concern was identified in this review.
This advisory report describes what the named tools and contextual reviewer found at one exact commit. Unknown or unobserved behavior may still exist.
0 immediate danger0 material6 low
What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow references a standard GitHub action by its major version tag instead of a fixed commit hash. If the action's tag were ever moved to a compromised version, the workflow could run untrusted code. This is a common practice but pinning to a specific hash would be safer.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: actions/checkout@v4 is pinned to a major-version floating tag rather than a full SHA. While this is the dominant convention in the ecosystem and GitHub maintains these tags, a tag-repointing or compromise scenario could introduce unexpected behavior. The workflow only runs tests, so the blast radius is limited to CI.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning the checkout action to a full commit SHA for stronger supply-chain integrity, though using the v4 major-version tag is widely accepted standard practice.
The flagged library is a development-only testing tool that is not included in the extension that users actually install. The security issue only matters if someone is actively developing and running tests on their own machine, not for people using the extension in SillyTavern. No real danger reaches end users.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-fxqj-rqcc-2cmp to a dependency declared by this repository.
Contextual assessment: The advisory GHSA-fxqj-rqcc-2cmp targets esbuild, which appears in the lockfile at version 0.28.1 as a transitive dependency of vitest. Vitest is declared as the sole devDependency, and every esbuild platform package entry is marked dev true and optional. This is a SillyTavern extension whose shipped artifact is browser-loaded JavaScript; esbuild and vitest are build/test-time tools that are not bundled into the extension and are never executed by end users. The vulnerable esbuild code path (development server behavior) has no runtime reachability in the production extension, and no attacker-controlled input can reach it in a deployed context. The advisory is valid for a developer running local tests, but it has no concrete user-harm path for extension consumers.
Impact: none · Exploitability: unlikely
Developer action: Update vitest to a version that pulls in a patched esbuild when convenient, but no urgent action is required for the safety of extension users.
The workflow references the Node setup action by its major version tag instead of a fixed commit hash. If the tag were ever moved to a compromised version, untrusted code could run in CI. This is common practice but pinning to a hash would be safer.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: actions/setup-node@v4 is pinned to a major-version floating tag rather than a full SHA. This is standard ecosystem convention, but a tag-repointing or supply-chain compromise could introduce unexpected behavior. The workflow only runs tests, limiting the blast radius to CI.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning the setup-node action to a full commit SHA for stronger supply-chain integrity, though using the v4 major-version tag is widely accepted standard practice.
The checkout action does persist a token in the local git config by default, but this workflow runs on a temporary GitHub-hosted runner that is destroyed immediately after the job. No artifacts are uploaded, and no step accesses or exfiltrates the persisted credential. There is no realistic path to harm.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule fires because actions/checkout defaults persist-credentials to true, leaving the GITHUB_TOKEN in .git/config. However, this workflow runs on ubuntu-latest (an ephemeral GitHub-hosted runner), performs only npm ci and npm test, uploads no artifacts, and makes no external network calls beyond package installation. The persisted credential is destroyed with the runner and is never exposed.
The workflow does not set an explicit permissions block, but it only runs tests and never uses the GitHub token for writes, uploads, or API calls. The default permissions are not exercised in any harmful way.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow lacks an explicit permissions block, which means the GITHUB_TOKEN receives default permissions. For pull_request triggers these are read-only; for push triggers they include write scopes, but no step in this workflow uses the token at all. There are no artifact uploads, deployment steps, or API calls. Adding an explicit permissions: contents: read block would be good hygiene but the absence causes no concrete harm here.
The workflow has no explicit permissions declaration. While no current step uses the GitHub token, adding a read-only permissions block is a simple best-practice safeguard.
Technical assessment
Adding an explicit permissions: contents: read block at the job or workflow level would enforce least-privilege even if future steps are added that inadvertently rely on the default token scope.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block with contents: read to follow least-privilege hygiene, even though no step currently uses the token.