Repository navigation
Conversation
…ht the risk auth0#952 I have made the changes as per above mentioned in the above comment.
| <summary><em></em>Need to peek into a JWT without verifying it? (Click to expand)</summary> | ||
|
|
||
| ### jwt.decode(token [, options]) | ||
| ### jwt.unsafe_decode(token [, options]) |
There was a problem hiding this comment.
There was a problem hiding this comment.
Thanks for the suggestion! I'll update the name to unsafeDecode to align with JavaScript's camelCase convention. I'll also review the implementation and tests to ensure the change is consistent.
cc: @jonaskello
| @@ -0,0 +1,7268 @@ | |||
| { | |||
| "name": "jsonwebtoken", | |||
There was a problem hiding this comment.
It seems the package-lock wasn't committed before which is not the best practice.
It might be better to add it in a different commit for visibility
… into aalu-love-952
| "integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==", | ||
| "dev": true | ||
| }, | ||
| "node_modules/js-yaml": { |
There was a problem hiding this comment.
Medium severity vulnerability may affect your project—review required:
Line 1859 lists a dependency (js-yaml) with a known Medium severity vulnerability.
ℹ️ Why this matters
Affected versions of js-yaml are vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'). js-yaml is vulnerable to prototype pollution through its YAML merge key (<<) handling. When parsing untrusted YAML with load, loadAll, safeLoad, or safeLoadAll, a crafted document containing a __proto__ key inside a merged mapping can modify the prototype of the resulting object, leading to integrity violations in the application.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2025-175314, GHSA, CVE
To resolve this comment:
Check if you are using js-yaml on the CLI.
- If you're affected, upgrade this dependency to at least version 3.14.2 at package-lock.json.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==", | ||
| "dev": true | ||
| }, | ||
| "node_modules/js-yaml": { |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 1859 lists a dependency (js-yaml) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of js-yaml are vulnerable to Inefficient Algorithmic Complexity / Uncontrolled Resource Consumption. js-yaml is vulnerable to CPU exhaustion when parsing untrusted YAML: the maxTotalMergeKeys budget is only charged for keys that a merge (<<) source actually contributes, so empty mappings cost nothing against the limit. A small document that merges a long sequence of empty mappings repeatedly forces O(N*K) work while the counter stays flat, stalling the process. Merge keys are part of the default schema for every load entrypoint (load, loadAll, and the 3.x safeLoad/safeLoadAll), and lowering maxTotalMergeKeys does not mitigate it.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-69712, GHSA, CVE
To resolve this comment:
Check if you are using js-yaml on the CLI.
- If you're affected, upgrade this dependency to at least version 3.15.2 at package-lock.json.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==", | ||
| "dev": true | ||
| }, | ||
| "node_modules/js-yaml": { |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 1859 lists a dependency (js-yaml) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of js-yaml are vulnerable to Inefficient Algorithmic Complexity. An attacker can supply a YAML document containing a large !!omap sequence, which js-yaml resolves with a linear duplicate-key scan inside its per-element loop. Resolution is therefore quadratic in the number of entries, so a modestly sized document consumes disproportionate CPU inside the load call and blocks the event loop, resulting in a denial of service.
References: GHSA
To resolve this comment:
Check if you are using js-yaml on the CLI.
- If you're affected, upgrade this dependency to at least version 3.15.1 at package-lock.json.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==", | ||
| "dev": true | ||
| }, | ||
| "node_modules/js-yaml": { |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 1859 lists a dependency (js-yaml) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of js-yaml are vulnerable to Inefficient Algorithmic Complexity / Uncontrolled Resource Consumption. An attacker can supply a YAML document containing a chain of mappings that each merge the previous one via the merge key (<<), causing js-yaml to spend quadratic CPU time while parsing input whose size grows only linearly, resulting in a denial of service.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-42301, GHSA, CVE
To resolve this comment:
Check if you are using js-yaml on the CLI.
- If you're affected, upgrade this dependency to at least version 3.15.0 at package-lock.json.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "node": ">=4.x" | ||
| } | ||
| }, | ||
| "node_modules/handlebars": { |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 1518 lists a dependency (handlebars) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of handlebars are vulnerable to Improper Control of Generation of Code ('Code Injection') / Improper Encoding or Escaping of Output / Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). The Handlebars CLI precompiler allows arbitrary JavaScript injection by embedding unescaped template filenames and CLI option values such as --namespace, --commonjs, and --handlebarPath directly into generated output. An attacker who can control these inputs can cause malicious code to execute when the precompiled bundle is loaded in Node.js or a browser.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-16862, GHSA, CVE
To resolve this comment:
Check if you execute templates through the Handlebars CLI precompiler.
- If you're affected, upgrade this dependency to at least version 4.7.9 at package-lock.json.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "node": ">=0.4.0" | ||
| } | ||
| }, | ||
| "node_modules/nyc/node_modules/handlebars": { |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 3717 lists a dependency (handlebars) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of handlebars are vulnerable to Improper Control of Generation of Code ('Code Injection') / Improper Encoding or Escaping of Output / Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). The Handlebars CLI precompiler allows arbitrary JavaScript injection by embedding unescaped template filenames and CLI option values such as --namespace, --commonjs, and --handlebarPath directly into generated output. An attacker who can control these inputs can cause malicious code to execute when the precompiled bundle is loaded in Node.js or a browser.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-16862, GHSA, CVE
To resolve this comment:
Check if you execute templates through the Handlebars CLI precompiler.
- If you're affected, upgrade this dependency to at least version 4.7.9 at package-lock.json.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "lodash": "^4.17.4" | ||
| } | ||
| }, | ||
| "node_modules/nyc/node_modules/babel-traverse": { |
There was a problem hiding this comment.
Critical severity vulnerability may affect your project—review required:
Line 2833 lists a dependency (babel-traverse) with a known Critical severity vulnerability.
ℹ️ Why this matters
Affected versions of @babel/traverse and babel-traverse are vulnerable to Incomplete List of Disallowed Inputs / Incorrect Comparison. Compiling untrusted code with Babel using plugins that invoke the internal path.evaluate() or path.evaluateTruthy() methods (for example @babel/plugin-transform-runtime, @babel/preset-env with useBuiltIns, or any polyfill‐provider plugin) allows a maliciously crafted AST to execute arbitrary code on the build machine during compilation.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2023-2669, GHSA, CVE
To resolve this comment:
Check if you use Babel to compile untrusted JavaScript.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "inBundle": true, | ||
| "license": "ISC" | ||
| }, | ||
| "node_modules/nyc/node_modules/set-value": { |
There was a problem hiding this comment.
Critical severity vulnerability introduced by a package you're using:
Line 5037 lists a dependency (set-value) with a known Critical severity vulnerability. Fixing requires upgrading or replacing the dependency.
ℹ️ Why this matters
Affected versions of set-value and set-value are vulnerable to Improperly Controlled Modification Of Object Prototype Attributes ('Prototype Pollution'). The set function fails to validate which Object properties it updates. This allows attackers to modify the prototype of Object, causing the addition or modification of an existing property on all objects.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2019-0617, GHSA, CVE
To resolve this comment:
Upgrade this dependency to at least version 2.0.1 at package-lock.json.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| "node": ">=0.10.0" | ||
| } | ||
| }, | ||
| "node_modules/nyc/node_modules/union-value/node_modules/set-value": { |
There was a problem hiding this comment.
Critical severity vulnerability introduced by a package you're using:
Line 5912 lists a dependency (set-value) with a known Critical severity vulnerability. Fixing requires upgrading or replacing the dependency.
ℹ️ Why this matters
Affected versions of set-value and set-value are vulnerable to Improperly Controlled Modification Of Object Prototype Attributes ('Prototype Pollution'). The set function fails to validate which Object properties it updates. This allows attackers to modify the prototype of Object, causing the addition or modification of an existing property on all objects.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2019-0617, GHSA, CVE
To resolve this comment:
Upgrade this dependency to at least version 2.0.1 at package-lock.json.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
#952 I have made the changes as per the above mentioned in the above comment.
Description
Checklist