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 release automation uses an outdated, no-longer-maintained GitHub action to create releases. This is a maintenance concern for the project's build pipeline but does not affect people who install and use the extension.
Technical evidence
Scanner reason: zizmor matched workflow-security rule archived-uses. The match applies to this repository.
Contextual assessment: The workflow uses actions/create-release@v1, a GitHub-provided action that has been archived and is no longer maintained. This is CI tooling hygiene, not shipped extension behavior. The workflow runs only on merged pull requests to the release branch and uses the repository's own GITHUB_TOKEN with standard release-creation permissions. No attacker-controlled input reaches the archived action's inputs in a way that would harm extension users; the tag name and release body are derived from internal git tags and PR metadata. Using an unmaintained action means future vulnerabilities would not receive fixes, but no concrete exploitation path is demonstrated in the supplied evidence.
Impact: low · Exploitability: unlikely
Developer action: Replace the archived action with a maintained alternative such as softprops/action-gh-release or the GitHub CLI release command already available in the workflow.
The workflow briefly saves the GitHub access token to a file on the build machine. The machine is temporary and destroyed after the job, so the practical risk is low, but it is an unnecessary step that could be avoided.
Technical assessment
The step writes the GITHUB_TOKEN to a file named gh_token on the runner. The token is already available via the GH_TOKEN environment variable in subsequent steps, so the file write is unnecessary. The file persists on the ephemeral runner filesystem for the job duration. Since the runner is temporary and scoped to this workflow, exposure is limited, but writing secrets to disk is poor hygiene.
Impact: low · Exploitability: unlikely
Developer action: Remove the file-writing step and rely on the GH_TOKEN environment variable already configured for subsequent steps.