What this review found
No material or immediate-danger item was identified.
Minor cautions
Dependency advisory GHSA-395f-4hp3-45gv applies
Minor caution · medium confidence
A known security issue was found in a tool used only during development (not in the actual app that users run). Since this tool is not part of the finished product, the risk to end users is very low. It would only matter if someone tricked a developer into processing a specially crafted file during development.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-395f-4hp3-45gv to a dependency declared by this repository.
Contextual assessment: This advisory targets a dependency declared in the root package-lock.json. The root package.json declares only devDependencies (concurrently, oxfmt, oxlint), and all visible entries in the lockfile are marked dev: true and optional: true. The production server and client code live in separate subdirectories with their own package.json files not covered by this lockfile. The vulnerable package is therefore a development-only tool or its transitive dependency, with no runtime reachability in the shipped application. Exploitation would require an attacker to craft malicious input that triggers the vulnerability during a development workflow such as linting or formatting, which is unlikely in normal use.
Impact: low · Exploitability: unlikely
Developer action: Update the affected devDependency to a patched version when available. No urgent action is required since this does not affect the production application.
- Scanner
- osv-scanner 2.4.0
- Rule
- GHSA-395f-4hp3-45gv
- File role
- production
- Source
- package-lock.json
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If the tag were ever moved to malicious code, it could run in the workflow, but major action tags are generally protected.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 105 references actions/github-script@v7 by major-version tag rather than a pinned SHA. Tag-based references can be moved by the action maintainer, introducing a supply-chain risk if the tag is reassigned to malicious code. The action runs in the test job and uses the GITHUB_TOKEN to comment on PRs. Impact is limited because the token scope is narrow and the script only creates comments.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/github-script to a full commit SHA for reproducibility and supply-chain hardening.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:105
zizmor reported excessive-permissions
Minor caution · high confidence
The lint job does not declare its own permissions, so it may inherit broader access than it needs. It only runs linting and does not use the GitHub token for anything sensitive.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The lint job has no explicit `permissions` block. It runs only checkout, setup-node, npm install, and npm run lint. No step uses the GITHUB_TOKEN for write operations. The risk is that default repository permissions could grant more access than necessary, but no step exercises write capabilities.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit `permissions: contents: read` block to the lint job to follow least-privilege conventions.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- test
- Source
- .github/workflows/test.yml:10-27
zizmor reported unpinned-uses
Minor caution · high confidence
The checkout action is referenced by version tag (@v4) instead of a fixed commit hash. If the action's repository were compromised, a new version could run in this workflow. This is a common practice and a low-risk supply-chain hygiene issue.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 15 uses `actions/checkout@v4` pinned to a floating major version tag rather than a SHA. This is a widely adopted convention but does not provide full supply-chain protection against tag re-pointing.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions to a commit SHA for stronger supply-chain integrity, though this is optional for a hobbyist project.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:15
Dependency advisory GHSA-w7jw-789q-3m8p applies
Minor caution · medium confidence
A serious security issue was found, but it is in a development-only tool that is not included in the app people actually use. Even though the issue is rated critical, it cannot affect users of the finished product. It would only be a concern if an attacker could manipulate files that a developer processes with these tools.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-w7jw-789q-3m8p to a dependency declared by this repository.
Contextual assessment: This critical-severity advisory targets a dependency in the root package-lock.json. The root project declares only devDependencies (concurrently, oxfmt, oxlint) with no production dependencies. All visible lockfile entries are marked dev: true. The production application code resides in server/ and vue_client/ subdirectories with their own separate dependency manifests. The vulnerable code therefore has no runtime reachability in the deployed application. While the advisory severity is critical, the dev-only context means attacker-controlled input would need to reach the vulnerable code path during a development task such as building, linting, or formatting, which is not a plausible attack vector for end users.
Impact: low · Exploitability: unlikely
Developer action: Update the affected devDependency to a patched version when convenient. The critical rating warrants attention but does not represent production risk for this project structure.
- Scanner
- osv-scanner 2.4.0
- Rule
- GHSA-w7jw-789q-3m8p
- File role
- production
- Source
- package-lock.json
zizmor reported unpinned-uses
Minor caution · high confidence
The setup-node action is referenced by version tag (@v4) instead of a fixed commit hash. Same low-risk supply-chain hygiene concern as the checkout action.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 18 uses `actions/setup-node@v4` pinned to a floating major version tag rather than a SHA.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions to a commit SHA for stronger supply-chain integrity, though this is optional for a hobbyist project.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:18
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If the tag were moved to malicious code, it could execute in CI, but this is unlikely for well-known actions.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 37 references actions/setup-node@v4 by major-version tag. This is a common pattern but does not provide immutability guarantees. The action installs Node.js and configures npm cache; it does not handle secrets directly in this job.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/setup-node to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:37
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a fixed commit hash for the Codecov upload action. If the tag were moved to malicious code, it could access the Codecov token, but this is unlikely for a widely used action.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 86 references codecov/codecov-action@v5 by major-version tag. This step receives the CODECOV_TOKEN secret and uploads coverage files. A tag reassignment could expose the token, but the action is widely used and the step is continue-on-error.
Impact: low · Exploitability: unlikely
Developer action: Pin codecov/codecov-action to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:86
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If the tag were moved to malicious code, it could execute in CI, but this is unlikely for well-known actions.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 61 references actions/setup-node@v4 by major-version tag in the test job matrix. Same supply-chain consideration as other unpinned references; the action configures Node.js and npm cache.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/setup-node to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:61
zizmor reported unpinned-uses
Minor caution · high confidence
The checkout action in the format job is referenced by version tag (@v4) instead of a fixed commit hash. Same low-risk supply-chain hygiene concern.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 34 uses `actions/checkout@v4` pinned to a floating major version tag rather than a SHA. This is the format job's checkout step.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions to a commit SHA for stronger supply-chain integrity, though this is optional for a hobbyist project.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:34
zizmor reported excessive-permissions
Minor caution · high confidence
The format job does not declare its own permissions, so it may inherit broader access than it needs. It only checks formatting and does not use the GitHub token for anything sensitive.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The format job has no explicit `permissions` block. It runs only checkout, setup-node, npm install, and npm run format:check. No step uses the GITHUB_TOKEN for write operations.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit `permissions: contents: read` block to the format job to follow least-privilege conventions.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- test
- Source
- .github/workflows/test.yml:29-46
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a fixed commit hash for the Codecov upload action. If the tag were moved to malicious code, it could access the Codecov token, but this is unlikely for a widely used action.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 95 references codecov/codecov-action@v5 by major-version tag for the client coverage upload. This step also receives the CODECOV_TOKEN secret. Same supply-chain consideration as the server coverage step.
Impact: low · Exploitability: unlikely
Developer action: Pin codecov/codecov-action to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:95
zizmor reported artipacked
Minor caution · low confidence
The checkout action saves a GitHub token in the local git config by default. If someone later uploaded the git folder as an artifact, the token could leak. In this workflow, only coverage JSON files are uploaded, so the token is not exposed.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule flags actions/checkout@v4 at lines 57-58 because persist-credentials defaults to true, leaving the GITHUB_TOKEN in .git/config. However, the only artifacts uploaded in this workflow are specific coverage JSON files via codecov-action, not the .git directory. There is no evidence of .git directory exfiltration, so the practical risk is low.
Impact: low · Exploitability: unlikely
Developer action: Set persist-credentials: false on checkout steps if credential persistence is not needed, or ensure no artifacts include the .git directory.
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- test
- Source
- .github/workflows/test.yml:57-58
zizmor reported excessive-permissions
Minor caution · medium confidence
The test job does not specify which permissions its GitHub token should have. Without explicit limits, the token may have broader access than necessary. The job only needs to read code and post a PR comment.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The test job (lines 48-127) has no explicit permissions block. The github-script step at line 105 calls github.rest.issues.createComment, which requires pull-requests: write. Without an explicit permissions declaration, the job relies on default token permissions, which may be broader than needed. For pull_request events from forks, the GITHUB_TOKEN is typically read-only, so the comment step would fail silently due to continue-on-error. Adding an explicit minimal permissions block would follow least-privilege principles.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block to the test job with only the scopes needed, such as contents: read and pull-requests: write for the comment step.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- test
- Source
- .github/workflows/test.yml:48-127
zizmor reported excessive-permissions
Minor caution · high confidence
The workflow does not declare explicit permissions at the top level. The test job needs write access to comment on pull requests, but without explicit permission declarations, all jobs may inherit broader access than necessary. This is a common CI hygiene gap.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: No workflow-level `permissions` block is present. The test job uses `actions/github-script@v7` to create a PR comment, which requires `pull-requests: write`. Without explicit per-job permissions, all jobs inherit the repository default token permissions, which may be broader than needed. The CODECOV_TOKEN secret is passed to the codecov action but that is a separate secret, not the GITHUB_TOKEN.
Impact: low · Exploitability: unlikely
Developer action: Add a workflow-level or per-job `permissions` block declaring only the access each job needs (e.g., `contents: read` for lint/format, `contents: read` and `pull-requests: write` for the test job's PR comment step).
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- test
- Source
- .github/workflows/test.yml:1-127
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a fixed commit hash for the checkout action. If the tag were moved to malicious code, it could execute in CI, but this is unlikely for a well-known action.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Line 58 references actions/checkout@v4 by major-version tag in the test job. Same supply-chain consideration as other unpinned references. The checkout action has access to the repository contents and, with persist-credentials defaulting to true, the GITHUB_TOKEN.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/checkout to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:58
Expected scanner matches (11)
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify the onboarding preset endpoint works correctly. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file (onboarding.test.js) as part of a supertest request body sent to the onboarding preset endpoint. The value is a placeholder test fixture used to exercise API key validation and preset creation logic. No real credential is present; the value has been redacted in the supplied evidence.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:254
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a test file using fake, redacted API keys to check that the app can create different AI provider connections. No real secret is exposed.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The flagged value is a placeholder API key used inside a unit test for a provider factory. The supplied source context shows the values are already redacted placeholders, and the test only verifies that provider objects are instantiated correctly. No real credential is present, and the test does not transmit credentials anywhere.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/services/__tests__/provider-factory.test.js:50
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify the skip-onboarding flow. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file as part of a supertest request body creating a preset before testing the skip endpoint. It is a placeholder test fixture, not a live credential.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:319
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify DeepSeek preset creation. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file as part of a supertest request body for the onboarding preset endpoint. It is a placeholder test fixture used to validate preset creation behavior.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:140
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify the default preset is set correctly. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file as part of a supertest request body creating a DeepSeek preset to verify default preset assignment. It is a placeholder test fixture.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:264
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a test file that needs fake API keys to test how the app creates different AI provider connections. The flagged value is just a dummy placeholder used in tests, not a real secret, and it never goes anywhere outside the tests.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The flagged line is inside a unit test file for a provider factory. The matched value is a placeholder API key assigned to a test preset object used only to exercise provider instantiation logic. The value has been redacted in the supplied evidence, and the surrounding test cases use similar placeholder credentials solely to satisfy the apiKey field shape. No real credential is present, and the value is not used for authentication or sent to any external destination.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/services/__tests__/provider-factory.test.js:50
zizmor reported artipacked
Expected behavior · high confidence
The checkout action stores GitHub credentials in the local git config by default, but this workflow never uploads any artifacts, so there is no path for those credentials to be leaked through artifacts.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule flags credential persistence via checkout's default persist-credentials behavior. However, this workflow contains no `upload-artifact` steps. The codecov action sends coverage data to an external service, not to GitHub artifacts. Without artifact upload, there is no exfiltration path for the persisted .git/config credentials.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- test
- Source
- .github/workflows/test.yml:33-34
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify AI Horde preset creation with an optional key. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file as part of a supertest request body for the AI Horde provider preset endpoint. It is a placeholder test fixture exercising optional API key handling.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:191
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify the full onboarding flow. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file as part of a supertest request body creating a DeepSeek preset during the full onboarding flow test. It is a placeholder test fixture.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:383
zizmor reported artipacked
Expected behavior · high confidence
The checkout action stores GitHub credentials in the local git config by default, but this workflow never uploads any artifacts, so there is no path for those credentials to be leaked through artifacts.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked rule flags credential persistence via checkout's default persist-credentials behavior in the lint job. However, the lint job contains no `upload-artifact` steps. Without artifact upload, there is no exfiltration path for the persisted .git/config credentials.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- test
- Source
- .github/workflows/test.yml:14-15
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key used as test data in a test file to verify Anthropic API key prefix validation. It is not a real credential.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value appears in a test file as part of a supertest request body testing that an invalid Anthropic API key prefix is rejected. It is a placeholder test fixture.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- server/src/routes/__tests__/onboarding.test.js:171