The project includes a version of the nanoid library that has a known security issue, but we don't have evidence that the vulnerable code is ever used in a way that an attacker could exploit—it may only be used during development or testing.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-2v37-7h3g-55p8:pkg:c301f7c72c558e741e2a83a0 to a dependency declared by this repository.
Contextual assessment: The file pins nanoid@3.3.16, which is flagged by advisory GHSA-2v37-7h3g-55p8. However, the supplied evidence includes no source code, no import, and no runtime data flow showing that nanoid is invoked with attacker-controlled input. The extension is a SillyTavern UI extension whose purpose (interleaving user responses into completed assistant messages) does not inherently require nanoid; it may be a transitive devDependency. Without demonstrated reachability from an untrusted source, the advisory alone does not indicate a material runtime risk.
Impact: low · Exploitability: unlikely
Developer action: Confirm whether nanoid is a runtime dependency or solely a transitive devDependency. If it is bundled for production, update to nanoid@3.3.18 or later. If it is only a devDependency, consider removing it if unused, or update anyway to reduce scanning noise.
The project includes a YAML library with a known vulnerability, but the library is probably only used during development or testing, not when you use the extension. There is no evidence that anyone could send the extension malicious YAML to exploit the issue.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-5p4m-2wfm-xmqj:pkg:d055453f026a4e70572d800d to a dependency declared by this repository.
Contextual assessment: The file includes js-yaml@4.3.0, which has advisory GHSA-5p4m-2wfm-xmqj. The root package declares only devDependencies (eslint, vitest, etc.), and js-yaml is likely a transitive dependency of these development tools. No evidence shows that js-yaml is loaded or used to parse untrusted YAML at runtime in the extension. The extension's purpose (a UI tool for message editing) does not suggest any YAML processing of user data. Without a demonstrated attacker-controlled input path, the advisory does not represent a material runtime risk.
Impact: low · Exploitability: unlikely
Developer action: Confirm whether js-yaml is a runtime dependency. If it is bundled in the extension, update to js-yaml@4.3.1 or later. If it is solely a transitive devDependency, consider removing unused dependencies or updating to eliminate the advisory.
The workflow has more permissions than it needs. By default, GitHub gives it write access to the repository, but the workflow only runs tests and doesn't need to write anything. It's a good idea to restrict permissions to read-only.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow does not specify a permissions block, so it inherits the default GITHUB_TOKEN permissions which include write access to repository contents. For a CI workflow that only runs npm ci and npm run check, write permissions are unnecessary. If an attacker were to compromise the workflow (e.g., via a malicious dependency), they could abuse the token to push unauthorized changes. However, there is no evidence that the token is currently used in a risky way or that an attacker has done so.
Impact: low · Exploitability: plausible
Developer action: Add a 'permissions: contents: read' block at the top level or job level to follow the principle of least privilege.
This is just a label used to store temporary data in your browser. It is not a password, API key, or secret of any kind. The scanner was confused by the word 'key' in the variable name.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: Line 11 contains a string literal 'intercede_journal_v1' used as a localStorage key for crash-recovery journal storage. Gitleaks flagged it as a generic API key pattern, but the value is a plain constant identifier with no similarity to secret material, tokens, or credentials. The extension never transmits this value to any external service nor uses it for authentication. No credential exposure exists.
The workflow uses an action by its major version number (v5) instead of a specific commit. This is normal but means the action could change on future runs.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/checkout@v5 using a major version tag instead of a pinned commit hash. This is common practice but the action's code could change if the maintainer updates the tag. For an official GitHub action performing a checkout step, the practical risk is very low; no sensitive data is exposed and the action does not persist credentials.
Impact: none · Exploitability: unlikely
Developer action: Consider pinning to a specific commit hash for full reproducibility, though the current approach is acceptable for this low-risk CI workflow.
The flagged regular expression is a safe way to find paragraph breaks in text. It might look suspicious to automated scanners, but it cannot be exploited to cause performance problems or harm.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex in this repository.
Contextual assessment: The regex `PARAGRAPH_SEPARATOR_REGEX` matches consecutive newlines separated by optional horizontal whitespace. Although JS-X-Ray flags it as an unsafe-regex due to nested quantifiers (`*` and `+`), the pattern is effectively linear: it requires literal newlines to match, and backtracking is limited because there are no overlapping alternatives. The V8 JavaScript engine handles this pattern efficiently without catastrophic backtracking under typical chat-message inputs. No attacker-controlled input path or concrete ReDoS demonstration was supplied.
A security scanner thought the workflow might store secrets in build artifacts, but this workflow doesn't create any artifacts, so there's nothing to worry about.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The zizmor artipacked rule warns about potential credential persistence through GitHub Actions artifacts. This workflow does not use actions/upload-artifact or any artifact-related actions, so there is no mechanism for credential persistence via artifacts. The warning is a false positive triggered by a heuristic that does not consider the absence of artifact steps.
The workflow uses an action by its major version number (v5) instead of a specific commit. This is normal but means the action could change on future runs.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/setup-node@v5 using a major version tag instead of a pinned commit hash. This is common practice but the action's code could change if the maintainer updates the tag. For an official GitHub action setting up Node.js, the practical risk is very low; no sensitive data is exposed and the action does not persist credentials.
Impact: none · Exploitability: unlikely
Developer action: Consider pinning to a specific commit hash for full reproducibility, though the current approach is acceptable for this low-risk CI workflow.