Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Regex audience matching without anchors is a security footgun

Open
#1,019 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
52/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript, node.js

Research direction

Start with the audience check in verify.js and the README audience section. Review how string and RegExp audiences are currently described, then confirm which proposed behavior maintainers want. Done should make the security implications of unanchored regex audiences explicit, with any related verification coverage updated if required.

Written by the indexing model from the issue text.

Description

Summary

When options.audience contains a RegExp, verify() calls audience.test(targetAudience) without enforcing that the regex is anchored. This means a developer who writes:

jwt.verify(token, secret, { audience: /api\.myapp\.com/ });

will inadvertently accept tokens with audiences like evil-api.myapp.com.attacker.com — the . matches any character and there are no ^/$ anchors.

The string comparison path (audience === targetAudience) is strict. The regex path silently shifts the security burden to the caller.

Reproduction

const jwt = require('jsonwebtoken');

const secret = 'test-secret';
const token = jwt.sign({ aud: 'evil-api.myapp.com.attacker.com' }, secret);

// Developer intends to only accept "api.myapp.com"
jwt.verify(token, secret, { audience: /api\.myapp\.com/ }, (err, decoded) => {
  console.log(err);     // null — no error!
  console.log(decoded); // token accepted despite malicious audience
});

Impact

This is not a vulnerability in the library itself — the regex works as designed. But it's a footgun: developers who mix string and regex audience checks may not realize the security model differs between the two paths. The string path is exact-match. The regex path accepts partial matches unless the developer manually adds ^ and $.

Given that audience validation is a security-critical check, the gap between "looks like it works" and "actually secure" is a concern.

Suggestions (pick any)

  1. Document it prominently — Add a note to the README's audience section warning that regex audiences must be anchored to avoid partial matches.
  2. Warn on unanchored regexes — If the regex source doesn't start with ^ or end with $, emit a console warning or throw.
  3. Auto-anchor — Wrap unanchored regexes in ^(?:...)$ before testing. This would be a breaking change for anyone relying on partial matches intentionally.

Option 1 is the lowest-friction fix. Option 2 provides defense-in-depth without breaking existing behavior.

Relevant code

verify.js audience check:

return audiences.some(function (audience) {
  return audience instanceof RegExp ? audience.test(targetAudience) : audience === targetAudience;
});
Dominant language
JavaScript
Stars
18.2k
Forks
1.3k
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from auth0/node-jsonwebtoken

All issues in auth0/node-jsonwebtoken

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.