Skip to content

Issue #952 fixed rename decode function unsafe_decode - #953

Open
aalu-love wants to merge 3 commits into
auth0:masterfrom
aalu-love:aalu-love-952
Open

aalu-love wants to merge 3 commits into
auth0:masterfrom
aalu-love:aalu-love-952

Conversation

@aalu-love

Copy link
Copy Markdown

#952 I have made the changes as per the above mentioned in the above comment.

Description

Renamed decode function to unsafe_decode where ever it has define in the code.

Checklist

  • I have added documentation for new/changed functionality in this PR or in auth0.com/docs
  • All active GitHub checks for tests, formatting, and security are passing
  • The correct base branch is being used, if not the default branch

…ht the risk

auth0#952 I have made the changes as per above mentioned in the above comment.
Comment thread README.md
<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])

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aalu-love Could you make it camelCase? So it can match javascript default case

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread package-lock.json
@@ -0,0 +1,7268 @@
{
"name": "jsonwebtoken",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@aalu-love
aalu-love requested a review from a team as a code owner October 10, 2026 05:40
Comment thread package-lock.json
"integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==",
"dev": true
},
"node_modules/js-yaml": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==",
"dev": true
},
"node_modules/js-yaml": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==",
"dev": true
},
"node_modules/js-yaml": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"integrity": "sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==",
"dev": true
},
"node_modules/js-yaml": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"node": ">=4.x"
}
},
"node_modules/handlebars": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"node": ">=0.4.0"
}
},
"node_modules/nyc/node_modules/handlebars": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"lodash": "^4.17.4"
}
},
"node_modules/nyc/node_modules/babel-traverse": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"inBundle": true,
"license": "ISC"
},
"node_modules/nyc/node_modules/set-value": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread package-lock.json
"node": ">=0.10.0"
}
},
"node_modules/nyc/node_modules/union-value/node_modules/set-value": {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants