No material or high-risk 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 high0 material5 low
What this review found
No material or high-risk item was identified.
Minor cautions
zizmor reported artipacked
Minor caution · high confidence
The test workflow checks out code in a way that leaves a temporary GitHub token in the local git settings. Since the workflow only runs the project's own tests and never saves or sends that token anywhere, this is a minor best-practice issue rather than a real danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The checkout action defaults to persist-credentials true, leaving the GITHUB_TOKEN in the local git config. This workflow does not upload artifacts or expose the workspace to untrusted code beyond running the project's own test suite, so credential persistence does not create a practical exfiltration path here. The concern is a standard CI hygiene issue rather than an exploitable flaw in this context.
Impact: low · Exploitability: unlikely
Developer action: Set persist-credentials: false on the checkout step if no git push operations are needed in this workflow.
The workflow uses a version label for a standard GitHub action instead of locking it to an exact version. This is a common practice and a minor hardening opportunity, not a sign of anything malicious.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action is referenced at major-version tag v4 rather than a pinned commit SHA. A compromised tag could in theory substitute malicious code, but this is a widely used first-party GitHub action at a stable major version. The workflow runs only the project's own tests and handles no secrets beyond the default token, limiting impact.
Impact: low · Exploitability: unlikely
Developer action: Pin actions to a full commit SHA for reproducibility and supply-chain hardening.
The test workflow does not limit what its temporary GitHub token is allowed to do. Since it only needs to run tests, it should declare read-only permissions as a precaution.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow defines no explicit permissions block, so it inherits the repository default token permissions, which may include write scopes. This job only checks out code, installs dependencies, and runs tests, so broad permissions are unnecessary. Adding a least-privilege permissions declaration would reduce blast radius if a dependency or test step were compromised.
Impact: low · Exploitability: unlikely
Developer action: Add a top-level or job-level permissions block with contents: read to follow least-privilege practice.
A security scanner found a known bug in a helper tool used only by the developer for testing and building. This tool is not included in the extension that users install and run, so it does not affect the actual add-on or anyone using it.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-fxqj-rqcc-2cmp to a dependency declared by this repository.
Contextual assessment: The lockfile declares only a single direct devDependency (vitest) and its transitive tree includes build and test tooling such as esbuild platform packages, all marked dev:true. The matched advisory corresponds to a known vulnerability in a development-time dependency. These packages are used during local testing and building and are not part of the shipped extension runtime that end users load in SillyTavern. The vulnerable package does not appear in the production dependency set, so there is no data flow from the advisory into the extension's runtime behavior, prompt handling, or any external API calls.
Impact: low · Exploitability: unlikely
Developer action: Update the affected dev dependency to a patched version when convenient to keep the development toolchain current, but no urgent action is required for the safety of the extension or its users.
The workflow uses a version label for a standard GitHub action instead of locking it to an exact version. This is a common practice and a minor hardening opportunity, not a sign of anything malicious.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-node action is referenced at major-version tag v4 rather than a pinned commit SHA. This is a standard first-party GitHub action used only to configure the Node runtime. The risk is supply-chain tag substitution, which is low for this widely used action and limited by the workflow's test-only scope.
Impact: low · Exploitability: unlikely
Developer action: Pin actions to a full commit SHA for reproducibility and supply-chain hardening.