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 material9 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 uses a standard GitHub-provided action for setting up Node.js, but does not lock it to a specific version hash. Best practice is to pin to an exact hash, though the risk is low because this is an official GitHub action.
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 only. This is an official first-party GitHub action used to install Node.js in a CI test matrix. Pinning to a commit SHA is recommended but the use of a major-version tag for an official action is a low-risk practice.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/setup-node to a full commit SHA for reproducibility and supply-chain hardening.
The workflow uses a standard GitHub-provided action for uploading test results, but does not lock it to a specific version hash. Best practice is to pin to an exact hash, though the risk is low because this is an official GitHub action.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/upload-artifact by major version tag only. This is an official first-party GitHub action used to upload test report JSON files. Pinning to a commit SHA is recommended but the use of a major-version tag for an official action is a low-risk practice.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/upload-artifact to a full commit SHA for reproducibility and supply-chain hardening.
The workflow uses a standard GitHub-provided action for checking out code, but does not lock it to a specific version hash. Best practice is to pin to an exact hash, though the risk is low because this is an official GitHub action.
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 only. This is an official first-party GitHub action used for repository checkout in a CI test workflow with contents:read permissions. While pinning to a full commit SHA is the recommended best practice to prevent tag-repointing attacks, using a major-version tag of an official action is common practice and presents a low risk in this context.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/checkout to a full commit SHA for reproducibility and supply-chain hardening.
The scanner warns that uploaded artifacts might contain credentials. In this case, only test result files are uploaded, and there is no evidence that credentials are written into those files, so the actual risk is low.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The scanner flags potential credential persistence in artifacts. The workflow uses actions/checkout with the default GITHUB_TOKEN scoped to contents:read, then uploads only test-results JSON files generated by the project's own test runner. There is no indication that runner credentials or the GITHUB_TOKEN are written into these test report files. The artifact scope is narrowly limited to test result JSON, reducing the likelihood of credential leakage. The underlying concern is valid in principle but does not appear to be realized in this workflow's data flow.
Impact: low · Exploitability: unlikely
Developer action: Verify that the test runner does not write tokens or secrets into the test report JSON files. Consider explicitly setting a minimal GITHUB_TOKEN permission for the checkout step if further hardening is desired.
This extension includes a feature that lets users write their own small scripts to run during group chats. The flagged line is simply the part that runs those user-written scripts. Since the user is the one who creates and enables these scripts, this is the feature working as intended rather than a security problem.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched call constructs a function from entry.code, where entry is a script registered in the extension's script-executor system. The project explicitly provides a Director Script and custom Agent extension interface, so executing user-authored scripts during chat turns is the stated purpose. The executed code originates from the user's own extension configuration, not from external or attacker-controlled input. Execution is wrapped in a 5-second timeout and results are validated before merging into shared turn state. No network exfiltration, credential access, or concealed execution is present in the surrounding flow.
This is a script-running feature that the extension openly provides. The scripts come from the user's own configuration in the extension settings, and the feature is described in the project documentation. The code includes safety measures like timeouts and error handling. There is no sign of hidden or malicious behavior.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched call constructs a function from entry.code, where entry is drawn from a user-managed list of scripts filtered by enabled state and trigger type. The project explicitly advertises a Director Script feature and a custom Agent extension interface, so executing user-authored scripts is the stated purpose of this module. The surrounding code shows defensive design: per-script cloning of decision state, a 10-second timeout wrapper, turn-id guards against cross-turn contamination, and structured error handling that logs failures and continues. The code source is the extension's own user-configured script list, not remote or hidden input. No network calls, credential access, or obfuscation are present in the supplied context.
Credential access and network transmission in one file
Expected behavior · high confidence
The extension sends data only to the local SillyTavern server to create a character card from an NPC. A security token is fetched from the same local server and attached to that request. Nothing is sent to any outside service.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged fetch call targets a relative path on the same SillyTavern server, which is the standard local API for creating character cards. The CSRF token is obtained from another relative local endpoint and is used solely as a header for that same-origin request. No credentials are sent to any external destination, and the token is cached locally with a TTL. This matches the stated project purpose of importing NPCs as character cards via the ST API.
Credential access and network transmission in one file
Expected behavior · high confidence
This file contains a safety checker that looks for risky code patterns in user-added plugins. The flagged text is just the name of a warning rule, not actual code that steals or sends data anywhere.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged line is a regex pattern definition inside a DANGEROUS_PATTERNS array used by scanSource() to detect risky constructs in user-imported modules. The string 'fetch() — network exfiltration' is a label for a detection rule, not an actual call to fetch or any network sink. No credentials are accessed or transmitted by this code; it is a defensive scanner that warns users about potentially dangerous patterns in third-party modules they choose to import.
User-authored script execution is sandboxed by timeout and turn guards
low risk · high confidence
The script runner has built-in safety rails: scripts cannot run longer than 5 seconds, and their results are checked before being applied. This is consistent with a well-behaved user-script feature.
Technical assessment
The executor wraps each script invocation in a 5-second timeout via withTimeout and guards shared-state mutation with a turn-id check to prevent cross-turn async contamination. Returned values are type-checked with assertSnapshotValue before being merged. These controls align with a legitimate script-execution feature and reduce the risk of runaway or stale-state side effects.