Sample security report

# Fix 25 security vulnerabilities

**19 CRITICAL** — exploitable now, fix these first · **6 HIGH** — fix before your next deploy

> 🔑 4 of these are **leaked credentials**. Those need manual steps from you (marked below) — an AI tool cannot rotate keys for you.

## 🔑 Rotate these leaked credentials first — steps only YOU can do

Every finding marked 🔑 below is a leaked credential. Changing the code is NOT enough: the value is already in your git history, so treat it as stolen. An AI tool cannot rotate credentials for you — do the steps for each type, then apply the code changes below.

**Third-party API keys** (`*****/*****/*****.js`, `*****/*****/*****.js`, `*****/*****/*****.js`, `*****/*****/*****.key`):
1. Log in to the service that issued it (Stripe, AWS, OpenAI, …) and **revoke the key**.
2. Generate a new one and store it in an environment variable (for example a `.env` file listed in `.gitignore`). Never paste it into source code.

Apply each fix below to the referenced file and line. The corrected code is included inline, so this works in any AI IDE or chat assistant without further context. The dependency upgrades at the end are shell commands, not code edits.

## 1. [CRITICAL] command-injection-js
- **File:** `*****/*****/*****.js` (lines 32, 33, 34)
- **Problem:** An attacker who controls `req.body.preTax`, `req.body.afterTax`, or `req.body.roth` can inject arbitrary JavaScript code that will execute on the server with full application privileges, allowing them to steal data, modify records, or compromise the entire application.
- **Fix:**

Replace `eval()` with `parseInt()` or `parseFloat()` (already shown in the commented-out fix on lines 38–40). The `eval()` calls treat user input as executable code; `parseInt()` safely converts strings to numbers and rejects anything that isn't numeric. Uncomment lines 38–40 and remove lines 32–34 to apply the fix that is already documented in the file itself.

## 2. [CRITICAL] hardcoded-api-key
- **File:** `*****/*****/*****.js` (lines 8, 9)
- **Problem:** An attacker who gains read access to this source code repository will obtain the session cookie secret and cryptographic key, allowing them to forge authenticated sessions and decrypt sensitive data without needing the legitimate server's secrets.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Move `cookieSecret` and `cryptoKey` into environment variables and load them without fallback defaults, so the application fails to start if they are not provided. Replace lines 8–9 with:
```javascript
cookieSecret: process.env.COOKIE_SECRET,
cryptoKey: process.env.CRYPTO_KEY,
```
Then ensure your deployment process (CI/CD, container orchestration, or hosting platform) injects these values at runtime. Never use `|| "default"` — a missing credential must crash loudly.

## 3. [CRITICAL] hardcoded-api-key
- **File:** `*****/*****/*****.js` (line 6)
- **Problem:** An attacker who gains access to this repository—or anyone reading the source code in version control, backups, or logs—can extract the hardcoded ZAP API key and use it to control the security testing tool or access its data without authorization.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Move the `zapApiKey` value into an environment variable and load it at runtime without a fallback default. Replace line 6 with `zapApiKey: process.env.ZAP_API_KEY,` then require the variable to be set before the application starts (e.g., by throwing an error in a startup check if it is undefined). Store the actual key only in your `.env` file or CI/CD secrets manager, never in version control.

## 4. [CRITICAL] hardcoded-api-key
- **File:** `*****/*****/*****.js` (line 6)
- **Problem:** An attacker who gains access to this source code repository (or any copy of it, including forks, backups, or CI logs) can extract the Zap API key on line 6 and use it to bypass security testing controls or manipulate the scanning tool.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Move the `zapApiKey` value into an environment variable and load it at runtime without a fallback default. Replace line 6 with `zapApiKey: process.env.ZAP_API_KEY,` — then the application will fail loudly at startup if the variable is not set, preventing accidental runs with a missing or stale credential. Store the actual key only in your test environment's secrets manager or `.env` file (which must not be committed to version control).

## 5. [HIGH] private-key
- **File:** `*****/*****/*****.key` (line 2)
- **Problem:** Artifact: *****/*****/*****.key Type: Secret Asymmetric Private Key Severity: HIGH Match: ****************************************************************.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first:

_No automated fix was generated for this finding. Ask the assistant to explain the issue at this exact file and line, propose a minimal fix, and apply it only after you approve._

## Dependency upgrades — 20 packages to update

- **[CRITICAL]** `*****.json` — **tar** 2.2.1 is vulnerable (CVE-2026-59873, CVE-2018-20834); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2026-59873
- **[CRITICAL]** `*****.json` — **handlebars** 4.0.5 is vulnerable (CVE-2026-33937, CVE-2021-23383, CVE-2021-23369, CVE-2019-19919, GHSA-2cf5-4w76-r9qv, CVE-2019-20920, CVE-2026-33938, CVE-2019-20922, CVE-2026-33939, GHSA-q42p-pg8m-cqh6, CVE-2026-33940, CVE-2026-33941, CVE-2026-33916, GHSA-f52g-6jhx-586p, GHSA-g9r4-xpmj-mj65, GHSA-q2c6-c6pm-g3gh); no patched version was resolved automatically — check the advisory for the fixed release: https://github.com/advisories/GHSA-2cf5-4w76-r9qv
- **[CRITICAL]** `*****.json` — **babel-traverse** 6.11.4 is vulnerable (CVE-2023-45133); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2023-45133
- **[CRITICAL]** `*****.json` — **json-schema** 0.2.3 is vulnerable (CVE-2021-3918); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2021-3918
- **[CRITICAL]** `*****.json` — **getobject** 0.1.0 is vulnerable (CVE-2020-28282); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2020-28282
- **[CRITICAL]** `*****.json` — **form-data** 0.1.4 is vulnerable (CVE-2025-7783, CVE-2026-12143); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2025-7783
- **[CRITICAL]** `*****.json` — **lodash** 2.4.2 is vulnerable (CVE-2019-10744, CVE-2021-23337, CVE-2018-16487, CVE-2025-13465, CVE-2018-3721); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2019-10744
- **[CRITICAL]** `*****.json` — **growl** 1.9.2 is vulnerable (CVE-2017-16042); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2017-16042
- **[CRITICAL]** `*****.json` — **websocket-driver** 0.7.0 is vulnerable (CVE-2026-54466, CVE-2026-54490); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2026-54466
- **[CRITICAL]** `*****.json` — **bson** 1.0.9 → 1.1.4 or later (fixes CVE-2020-7610, CVE-2019-2391)
- **[CRITICAL]** `*****.json` — **minimist** 1.2.0 → 1.2.6 or later (fixes CVE-2021-44906, CVE-2020-7598)
- **[CRITICAL]** `*****.json` — **fsevents** 1.2.9 → 1.2.11 or later (fixes CVE-2023-45311, MAL-2023-462)
- **[CRITICAL]** `*****.json` — **mixin-deep** 1.3.1 → 1.3.2 or later (fixes CVE-2019-10746)
- **[CRITICAL]** `*****.json` — **set-value** 2.0.0 → 2.0.1 or later (fixes CVE-2019-10747, CVE-2021-23440)
- **[CRITICAL]** `*****.json` — **underscore** 1.9.1 → 1.12.1 or later (fixes CVE-2021-23358). This lockfile also has other copies of underscore at different versions, so pin this range through `overrides` rather than installing it (see below).
- **[HIGH]** `*****.json` — **js-yaml** 3.5.5 is vulnerable (CVE-2026-84375, CVE-2026-59869, GHSA-5p4m-2wfm-xmqj, GHSA-2pr6-76vf-7546, GHSA-8j8c-7jfh-h6hx, CVE-2026-53550, CVE-2025-64718); no patched version was resolved automatically — check the advisory for the fixed release: https://github.com/advisories/GHSA-5p4m-2wfm-xmqj
- **[HIGH]** `*****.json` — **sshpk** 1.10.1 is vulnerable (CVE-2018-3737); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2018-3737
- **[HIGH]** `*****.json` — **brace-expansion** 1.1.11 → 1.1.18 or later (fixes CVE-2026-13149, CVE-2026-14257, CVE-2026-69152, CVE-2026-33750). This lockfile also has other copies of brace-expansion at different versions, so pin this range through `overrides` rather than installing it (see below).
- **[HIGH]** `*****.json` — **cross-spawn** 4.0.0 is vulnerable (CVE-2024-21538); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2024-21538
- **[HIGH]** `*****.json` — **npm** 3.10.10 is vulnerable (CVE-2019-16777, CVE-2019-16775, CVE-2018-7408, CVE-2019-16776, CVE-2020-15095); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2019-16777

Fix these by running the commands below in the project folder — **never edit a lockfile by hand** (it is a generated file with integrity hashes; hand edits corrupt it):

```bash
# in the repo root
npm install bson@^1.1.4 fsevents@^1.2.11 minimist@^1.2.6 mixin-deep@^1.3.2 set-value@^2.0.1
```

If a package is still flagged after this, it is a transitive dependency: pin the patched version through your manifest (`"overrides"` in `*****.json` for npm, `"resolutions"` for yarn, or your package manager's equivalent), then re-run the install command so the lockfile is regenerated — never edit the lockfile itself.

**Do not install these yet:** `babel-traverse` 6.11.4 (in `*****.json`), `cross-spawn` 4.0.0 (in `*****.json`), `form-data` 0.1.4 (in `*****.json`), `getobject` 0.1.0 (in `*****.json`), `growl` 1.9.2 (in `*****.json`), `handlebars` 4.0.5 (in `*****.json`), `js-yaml` 3.5.5 (in `*****.json`), `json-schema` 0.2.3 (in `*****.json`), `lodash` 2.4.2 (in `*****.json`), `npm` 3.10.10 (in `*****.json`), `sshpk` 1.10.1 (in `*****.json`), `tar` 2.2.1 (in `*****.json`), `websocket-driver` 0.7.0 (in `*****.json`). No patched version was resolved for them, so installing without a version pin would either reinstall the vulnerable release or upgrade across a major version. Open the advisory link on each bullet above, find the fixed release, and tell me the version before changing anything.

**Several copies installed — use `overrides`, not `install`:** `brace-expansion` (versions 1.1.6, 1.1.11 in `*****.json`), `lodash` (versions 2.4.2, 4.13.1 in `*****.json`), `tar` (versions 2.2.1, 4.4.8 in `*****.json`), `underscore` (versions 1.8.3, 1.9.1 in `*****.json`). Your dependency tree contains more than one version of these packages, pulled in by different parents. A plain install writes a single range into `*****.json` and cannot upgrade one copy while leaving the other alone, so running it would either miss the vulnerable copy or drag an unrelated one across a major version. Pin the patched range per line in `overrides` (npm) or `resolutions` (yarn/pnpm), then reinstall so the lockfile is regenerated, and check afterwards that every copy moved.

Re-run the tests and confirm the app still builds, then re-run the security scan.

**What each of these costs, worst case.** The upgrades in the command block stay on the version line you are already on, so they are patch or minor bumps: low risk, but a package can still change behaviour in a minor release, which is why the tests come first. Pinning through `overrides`/`resolutions` forces a version onto a dependency that did not ask for it, so the worst case is a resolution conflict or a parent package running against a version it never tested with. A major upgrade can remove or rename APIs and break every caller, which is why those are listed as decisions rather than commands. Doing nothing is also a choice with a cost: the advisory stays exploitable in whatever way the finding describes. If any upgrade fails its tests, stop and report it rather than working around it.

If a fix needs a major-version upgrade, or no patched version exists (the vulnerable package belongs to an end-of-life toolchain, like Babel 6), do not force it — flag it as a decision for me, explained in plain language.

## Ground rules (do not skip)
- Change only the lines needed for each fix — do not refactor, rename, or restructure unrelated code.
- Preserve every function signature, import, error handler, log line, and existing test.
- Never weaken or remove an existing security measure (authentication, input validation, sanitisation, rate limiting) while applying a fix.
- If a finding points at a generated file (a schema dump, a lockfile, a build artifact, anything under dist/ or vendor/), do not edit that file — it is output and your edit will be overwritten. Fix the source that produces it (the migration, the manifest, the template) and say which file you changed.
- If a fix needs a new import or dependency, add only that — change nothing else. Do not add new third-party packages unless a fix explicitly requires one.
- Work through the fixes one at a time, most severe first: apply a fix, then check it (run the tests if you can) before moving to the next. Don't pause for my approval between routine fixes — but do stop and tell me if a fix fails its test, conflicts with another, or needs a decision only I can make. Put anything that needs my input in your final summary.
- Never claim you did something only I can do — you cannot reset a leaked key, change a provider or dashboard setting, or click through the running app. List those as steps for me; do not report them as done.
- If the code at a referenced line number does not match the finding, search that file for the code shown in the fix and apply the change there. If you cannot find it, say so in your final summary instead of guessing.
- If you cannot fully fix a finding — because it needs a change in an account or provider dashboard, a rotated key, or a decision only I can make — do not skip it silently. Tell me, and walk me through it in small numbered steps I can do myself. Assume I am not a developer: name exactly what to open and what to click, and say how I'll know it worked.

## Prevent these from coming back
Keep these rules in your project notes and include them in future prompts:
- Never write API keys, passwords, or tokens in source files — read them from environment variables.

## After every fix is applied
- [ ] Run the full test suite — everything that passed before must still pass.
- [ ] Start the app and click through your main user flows to confirm nothing broke.
- [ ] Confirm the old keys listed above are revoked at the provider and the new ones live only in environment variables.
- [ ] Re-run the security scan to verify these findings are gone and no new ones appeared.

> ⚠️ This prompt shows the **top 25 of 178** fix items, ranked most severe first — the remaining 153 are in your full report. Apply these, verify, then re-run the scan and grab the next batch.

---
Findings by Sentrint · https://sentrint.com