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 material5 low
What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported artipacked
Minor caution · high confidence
The test workflow leaves a temporary GitHub login token saved in the runner after checking out code, but nothing in the workflow uses or exposes that token. It is a minor best-practice issue, not a real danger here.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The checkout action persists a GitHub token in local git config by default. This workflow only runs npm ci and npm test afterward and never uploads artifacts or exposes the token, so there is no concrete path to credential leakage. The concern is standard CI hygiene rather than an exploitable flaw in this context.
Impact: low · Exploitability: unlikely
Developer action: Set persist-credentials: false on the checkout step if no subsequent git operations require authentication.
The workflow uses a shorthand version label for a GitHub-provided helper instead of locking it to an exact version. This is a minor supply-chain hygiene issue with no immediate danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/checkout by major version tag rather than a full commit SHA. If the tag were ever moved to a compromised action version, untrusted code could run in CI. This is a supply-chain hardening concern; the action is a first-party GitHub action and the workflow performs only testing, limiting concrete impact.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a full commit SHA for reproducibility and supply-chain hardening.
The workflow does not explicitly limit what its built-in GitHub token can do, but it only runs tests and never uses any powerful capabilities. This is a minor best-practice gap.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow does not declare an explicit permissions block, so the default GITHUB_TOKEN permissions apply. The job only checks out code, installs dependencies, and runs tests; it does not write to the repository, create releases, or deploy. For pull_request events from forks, GitHub automatically restricts the token to read-only. No excessive permission is actually exercised.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block with contents: read to follow least-privilege practice.
Another GitHub helper is referenced by a shorthand version label instead of an exact locked version. This is a minor supply-chain hygiene issue with no immediate danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/setup-node by major version tag rather than a full commit SHA. This is the same supply-chain hardening concern as the checkout action. The action is first-party and the workflow context is limited to running tests, so concrete impact is low.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a full commit SHA for reproducibility and supply-chain hardening.
The flagged library is a testing tool used only by the developer on their own machine. It is not included in the extension that users install, so the vulnerability has no way to affect anyone using the extension.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-fxqj-rqcc-2cmp to a dependency declared by this repository.
Contextual assessment: The advisory targets a transitive dependency introduced solely through the project's only devDependency, vitest. The lockfile marks esbuild and its platform-specific binaries as dev and optional. The vulnerable surface in esbuild relates to its local development server, which is not part of the shipped SillyTavern extension runtime. No production code path in this extension imports or invokes esbuild; it exists only for running tests during local development. There is no runtime reachability from the extension's production execution, and no attacker-controlled input reaches the vulnerable code in a deployed context.