A crafted input might briefly slow or freeze the local client, without showing broader security harm.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.
Contextual assessment: The expression may permit a local CPU slowdown, but this evidence shows no credential, persistence, code-execution, or cross-user impact.
Impact: low · Exploitability: plausible
Developer action: Bound the input length or replace the expression when practical.
The project's automated release script uses an official GitHub helper that GitHub has retired and no longer updates. It still works, and nothing here shows misuse or any danger to people who install the extension. The only downside is that this piece of the build pipeline will never receive fixes, so replacing it with a maintained way to create releases is routine housekeeping rather than an urgent fix.
Technical evidence
Scanner reason: zizmor matched workflow-security rule archived-uses. The match applies to this repository.
Contextual assessment: The release job in this maintainer-side automation workflow invokes the official GitHub release-creation action, whose upstream repository has been archived and no longer receives maintenance, which the scanner correctly identifies. Examining actual data flow: the job runs only when a pull request is merged into the release branch, passes only the repository-scoped ephemeral automation token, and feeds the action values the workflow itself computes (a version number derived from git tags and pull request metadata read via the GitHub CLI), so no attacker-controlled input path or concrete harm is demonstrated. Because the action's source repository is archived and read-only, its major-version reference is effectively frozen, which limits the usual mutable-tag supply-chain concern. The net issue is reliance on unmaintained tooling in the build pipeline, not a demonstrated vulnerability, and it does not affect the extension code shipped to SillyTavern users.
Impact: none · Exploitability: unlikely
Developer action: Replace the retired release-creation action with a maintained alternative, such as creating releases through the GitHub CLI already configured in this workflow, and pin any actions to full commit hashes for auditability. No user-facing change is required.
Release workflow writes the automation token to an unused plaintext file
low risk · high confidence
The script saves its temporary GitHub access token into a file that nothing ever uses. The token expires quickly and the machine running the script is thrown away afterward, so there is no shown way for anyone to abuse it, but writing credentials to files for no reason is untidy and easy to remove.
Technical assessment
One setup step echoes the repository automation token into a plaintext file in the workspace, while the same token is simultaneously provided to that step through its environment variable, and no later step references the file. The runner is ephemeral, the token is short-lived and repository-scoped, and no supplied step uploads the workspace, so no concrete exposure path is demonstrated. This is credential hygiene in maintainer automation, not a demonstrated vulnerability, and it does not touch the shipped extension.
Impact: none · Exploitability: unlikely
Developer action: Delete the step that writes the token to a file and rely on the environment variable already set for the token.