Code Security
Mar 6, 2026
From Code Audit to Global CVE: The Story Behind the pac4j JWT Authentication Bypass
Sonali Sood
Founding GTM, CodeAnt AI
Security vulnerabilities rarely exist in isolation.
When a critical flaw is discovered in widely used software, it moves through an entire ecosystem:
research → disclosure → CVE assignment → vulnerability databases → security media → developer discussions.
This process is what turns a private finding into a global security signal.
Recently, our security research team at CodeAnt AI discovered a critical authentication vulnerability in the Java library pac4j-jwt. The issue allows attackers to forge encrypted JWT tokens using only a public key and authenticate as arbitrary users, including administrators.
The vulnerability has now been assigned CVE-2026-29000 with a CVSS score of 10.0 (Critical).
The full technical research and exploit analysis is available in our original disclosure:
👉 https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
But the story doesn’t stop there.
Within days of the disclosure, the vulnerability began appearing across dozens of vulnerability intelligence platforms, national CERT advisories, security news outlets, and developer discussion forums.
Understanding how this information propagates is important because security teams rely on these signals to identify and prioritize risk.
Before walking through how the vulnerability propagated across the global security ecosystem, it helps to understand the vulnerability itself at a glance.
CVE-2026-29000: Quick Vulnerability Overview
Field | Details |
|---|---|
CVE ID | CVE-2026-29000 |
Affected Component | pac4j-jwt |
Vulnerability Type | Authentication Bypass |
CWE Classification | CWE-347 Improper Verification of Cryptographic Signature |
CVSS Score | 10.0 (Critical) |
Attack Vector | Network |
Privileges Required | None |
User Interaction | None |
Impact | Attackers can authenticate as arbitrary users including administrators |
Root Cause | Signature verification skipped when payload contains PlainJWT |
Patched Versions | pac4j-jwt 4.5.9+, 5.7.9+, 6.3.3+ |
Once a vulnerability receives a CVE identifier, it begins moving through a structured security information pipeline.
The journey typically follows several stages, from initial research and disclosure to CVE assignment, intelligence platforms, national advisories, and developer discussions.
The sections below walk through how CVE-2026-29000 moved through each stage of this ecosystem.
Stage 1: Security Research and Responsible Disclosure
The first stage of any major vulnerability begins with security research and responsible disclosure.
The vulnerability was discovered during an internal research initiative at CodeAnt AI focused on auditing security patches in open-source ecosystems.
The project investigates a simple but important question:
When a vulnerability is patched in open source, does the patch truly eliminate the underlying issue?
During this analysis, our AI code reviewer flagged a suspicious condition in the pac4j authentication logic.
Specifically, it identified a null check guarding the JWT signature verification step.
A manual review by our security engineer confirmed the problem.
If a decrypted token contained an unsigned JWT, signature verification would never run. Yet the authentication process would still proceed and accept the token’s claims.
This allowed attackers to:
Create an unsigned JWT containing arbitrary claims.
Encrypt it using the server’s public RSA key.
Submit the token as an authentication credential.
Because the system trusted decrypted tokens before verifying signatures, the attacker could authenticate as any user.
Full technical details are documented in our research disclosure:
👉 https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
After validating the issue and building a proof-of-concept exploit, we privately disclosed the vulnerability to pac4j maintainer Jérôme Leleu.
The maintainer confirmed the issue and released patches across three major version lines within two business days.
Stage 2: CVE Assignment
Once the vulnerability was confirmed and patched, the next step was assigning a Common Vulnerabilities and Exposures (CVE) identifier.
The issue received the identifier:
CVE-2026-29000
Several vulnerability intelligence platforms now track the issue.
For example:
• https://vulnerability.circl.lu/vuln/cve-2026-29000
• https://vulners.com/cvelist/CVELIST:CVE-2026-29000
• https://app.opencve.io/cve/CVE-2026-29000
These databases aggregate vulnerability data used by security scanners, SIEM platforms, and threat intelligence systems.
Once a CVE appears in these feeds, it becomes visible to enterprise security tools worldwide.
This is the point where a vulnerability transitions from a research finding into a machine-readable security signal used by vulnerability management systems.
Stage 3: Security Intelligence Platforms
Threat intelligence platforms quickly began cataloging the vulnerability.
Examples include:
• https://euvd.enisa.europa.eu/enisa/EUVD-2026-9505
These platforms enrich CVE data with:
vulnerability classification
• attack context
• CWE mappings
• threat analysis
In this case, the vulnerability is categorized under CWE-347: Improper Verification of Cryptographic Signature.
That classification reflects the root cause: the authentication logic allowed claims to be trusted without verifying a cryptographic signature.
Threat intelligence feeds like these allow security teams to correlate vulnerabilities with broader attack patterns.
Stage 4: National CERT and Security Advisories
Government-backed cybersecurity organizations also track high-severity vulnerabilities.
For example, the Spanish national cybersecurity institute (INCIBE-CERT) published an advisory referencing the issue:
👉 https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2026-29000
Advisories like this serve an important purpose.
They notify organizations operating within national infrastructure sectors about newly discovered vulnerabilities that may affect enterprise systems.
When a vulnerability reaches this stage, it is typically incorporated into national vulnerability monitoring systems.
Stage 5: Security News Coverage
Security media outlets play a key role in translating technical disclosures into accessible information for the broader security community.
Several publications covered the vulnerability shortly after disclosure.
Examples include:
• https://www.thehackerwire.com/pac4j-jwt-authentication-bypass-via-forged-encrypted-jwts/
• https://dailyaiwire.news/article/ai-discovered-cvss-10-pac4j-jwt-authentication-bypass
These reports typically summarize:
the vulnerability impact
• affected software versions
• mitigation steps
• the underlying research
Media coverage helps security teams who may not regularly monitor CVE feeds stay informed about emerging risks.
Stage 6: Security Community Discussion
After the vulnerability appeared in vulnerability feeds and security news outlets, it began circulating in developer communities.
The discussion reached Hacker News, where developers debated the implications of the vulnerability and the broader security design patterns involved. Community discussions often provide valuable insights because engineers begin analyzing how the vulnerability might affect real production environments.
In parallel, vulnerability tracking accounts on decentralized social platforms also shared the CVE announcement:
👉 https://bsky.app/profile/cve.skyfleet.blue/post/3mgbkx4u4ue2v
These discussions help amplify awareness across developer communities that might otherwise miss formal advisories.
Stage 7: Vulnerability Feeds and Security Dashboards
Many security teams rely on automated dashboards to monitor vulnerability feeds.
For example, platforms like Feedly aggregate vulnerability signals from multiple sources:
These feeds allow security teams to track new vulnerabilities affecting their software stack in near real-time.
Once a CVE appears in these feeds, organizations can automatically cross-reference the issue against their dependency inventories.
Why This Process Matters
The journey from research discovery to global CVE coverage is critical for modern software security.
Each stage plays a role:
Research teams discover vulnerabilities.
Maintainers patch them.
CVE systems assign identifiers.
Threat intelligence platforms categorize them.
Media outlets report them.
Developer communities discuss them.
Security tools integrate them into vulnerability management workflows.
Without this ecosystem, organizations would struggle to identify newly discovered risks in their software supply chains.
Lessons From CVE-2026-29000
Beyond the vulnerability itself, this case highlights an important pattern in modern security.
The most dangerous vulnerabilities often arise not from broken cryptographic primitives but from incorrect assumptions about how those primitives are used.
In this case:
Encryption worked correctly.
JWT libraries behaved correctly.
But the authentication logic assumed that encrypted tokens would always contain signed payloads.
That assumption was never enforced.
And that small gap allowed attackers to bypass authentication entirely.
Why CVE Signals Matter
Modern security research does not end when a vulnerability is discovered.
It only becomes impactful when the discovery propagates across the security ecosystem and reaches the engineers responsible for maintaining production systems.
CVE-2026-29000 illustrates how quickly this process can unfold.
A vulnerability discovered during a code audit moved through disclosure, patching, CVE assignment, vulnerability databases, national CERT advisories, and developer communities within days.
This ecosystem ensures that security signals reach organizations worldwide.
But it also highlights a deeper lesson.
The most severe vulnerabilities rarely come from broken cryptography or obscure memory corruption bugs.
They arise from assumptions embedded in authentication logic.
And when those assumptions fail, the impact can ripple across the entire software supply chain.
Final Thoughts
Modern security research does not end when a vulnerability is discovered.
It only becomes impactful when the finding propagates through the vulnerability ecosystem and reaches the engineers responsible for maintaining production systems.
The journey of CVE-2026-29000, from research discovery to global vulnerability feeds, illustrates how that process works.
And it demonstrates how a single vulnerability can quickly become visible across security intelligence platforms worldwide.
For the full technical analysis and proof-of-concept exploit, see the original research disclosure by the CodeAnt AI Security Research team:
👉 https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
Security vulnerabilities rarely exist in isolation.
When a critical flaw is discovered in widely used software, it moves through an entire ecosystem:
research → disclosure → CVE assignment → vulnerability databases → security media → developer discussions.
This process is what turns a private finding into a global security signal.
Recently, our security research team at CodeAnt AI discovered a critical authentication vulnerability in the Java library pac4j-jwt. The issue allows attackers to forge encrypted JWT tokens using only a public key and authenticate as arbitrary users, including administrators.
The vulnerability has now been assigned CVE-2026-29000 with a CVSS score of 10.0 (Critical).
The full technical research and exploit analysis is available in our original disclosure:
👉 https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
But the story doesn’t stop there.
Within days of the disclosure, the vulnerability began appearing across dozens of vulnerability intelligence platforms, national CERT advisories, security news outlets, and developer discussion forums.
Understanding how this information propagates is important because security teams rely on these signals to identify and prioritize risk.
Before walking through how the vulnerability propagated across the global security ecosystem, it helps to understand the vulnerability itself at a glance.
CVE-2026-29000: Quick Vulnerability Overview
Field | Details |
|---|---|
CVE ID | CVE-2026-29000 |
Affected Component | pac4j-jwt |
Vulnerability Type | Authentication Bypass |
CWE Classification | CWE-347 Improper Verification of Cryptographic Signature |
CVSS Score | 10.0 (Critical) |
Attack Vector | Network |
Privileges Required | None |
User Interaction | None |
Impact | Attackers can authenticate as arbitrary users including administrators |
Root Cause | Signature verification skipped when payload contains PlainJWT |
Patched Versions | pac4j-jwt 4.5.9+, 5.7.9+, 6.3.3+ |
Once a vulnerability receives a CVE identifier, it begins moving through a structured security information pipeline.
The journey typically follows several stages, from initial research and disclosure to CVE assignment, intelligence platforms, national advisories, and developer discussions.
The sections below walk through how CVE-2026-29000 moved through each stage of this ecosystem.
Stage 1: Security Research and Responsible Disclosure
The first stage of any major vulnerability begins with security research and responsible disclosure.
The vulnerability was discovered during an internal research initiative at CodeAnt AI focused on auditing security patches in open-source ecosystems.
The project investigates a simple but important question:
When a vulnerability is patched in open source, does the patch truly eliminate the underlying issue?
During this analysis, our AI code reviewer flagged a suspicious condition in the pac4j authentication logic.
Specifically, it identified a null check guarding the JWT signature verification step.
A manual review by our security engineer confirmed the problem.
If a decrypted token contained an unsigned JWT, signature verification would never run. Yet the authentication process would still proceed and accept the token’s claims.
This allowed attackers to:
Create an unsigned JWT containing arbitrary claims.
Encrypt it using the server’s public RSA key.
Submit the token as an authentication credential.
Because the system trusted decrypted tokens before verifying signatures, the attacker could authenticate as any user.
Full technical details are documented in our research disclosure:
👉 https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
After validating the issue and building a proof-of-concept exploit, we privately disclosed the vulnerability to pac4j maintainer Jérôme Leleu.
The maintainer confirmed the issue and released patches across three major version lines within two business days.
Stage 2: CVE Assignment
Once the vulnerability was confirmed and patched, the next step was assigning a Common Vulnerabilities and Exposures (CVE) identifier.
The issue received the identifier:
CVE-2026-29000
Several vulnerability intelligence platforms now track the issue.
For example:
• https://vulnerability.circl.lu/vuln/cve-2026-29000
• https://vulners.com/cvelist/CVELIST:CVE-2026-29000
• https://app.opencve.io/cve/CVE-2026-29000
These databases aggregate vulnerability data used by security scanners, SIEM platforms, and threat intelligence systems.
Once a CVE appears in these feeds, it becomes visible to enterprise security tools worldwide.
This is the point where a vulnerability transitions from a research finding into a machine-readable security signal used by vulnerability management systems.
Stage 3: Security Intelligence Platforms
Threat intelligence platforms quickly began cataloging the vulnerability.
Examples include:
• https://euvd.enisa.europa.eu/enisa/EUVD-2026-9505
These platforms enrich CVE data with:
vulnerability classification
• attack context
• CWE mappings
• threat analysis
In this case, the vulnerability is categorized under CWE-347: Improper Verification of Cryptographic Signature.
That classification reflects the root cause: the authentication logic allowed claims to be trusted without verifying a cryptographic signature.
Threat intelligence feeds like these allow security teams to correlate vulnerabilities with broader attack patterns.
Stage 4: National CERT and Security Advisories
Government-backed cybersecurity organizations also track high-severity vulnerabilities.
For example, the Spanish national cybersecurity institute (INCIBE-CERT) published an advisory referencing the issue:
👉 https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2026-29000
Advisories like this serve an important purpose.
They notify organizations operating within national infrastructure sectors about newly discovered vulnerabilities that may affect enterprise systems.
When a vulnerability reaches this stage, it is typically incorporated into national vulnerability monitoring systems.
Stage 5: Security News Coverage
Security media outlets play a key role in translating technical disclosures into accessible information for the broader security community.
Several publications covered the vulnerability shortly after disclosure.
Examples include:
• https://www.thehackerwire.com/pac4j-jwt-authentication-bypass-via-forged-encrypted-jwts/
• https://dailyaiwire.news/article/ai-discovered-cvss-10-pac4j-jwt-authentication-bypass
These reports typically summarize:
the vulnerability impact
• affected software versions
• mitigation steps
• the underlying research
Media coverage helps security teams who may not regularly monitor CVE feeds stay informed about emerging risks.
Stage 6: Security Community Discussion
After the vulnerability appeared in vulnerability feeds and security news outlets, it began circulating in developer communities.
The discussion reached Hacker News, where developers debated the implications of the vulnerability and the broader security design patterns involved. Community discussions often provide valuable insights because engineers begin analyzing how the vulnerability might affect real production environments.
In parallel, vulnerability tracking accounts on decentralized social platforms also shared the CVE announcement:
👉 https://bsky.app/profile/cve.skyfleet.blue/post/3mgbkx4u4ue2v
These discussions help amplify awareness across developer communities that might otherwise miss formal advisories.
Stage 7: Vulnerability Feeds and Security Dashboards
Many security teams rely on automated dashboards to monitor vulnerability feeds.
For example, platforms like Feedly aggregate vulnerability signals from multiple sources:
These feeds allow security teams to track new vulnerabilities affecting their software stack in near real-time.
Once a CVE appears in these feeds, organizations can automatically cross-reference the issue against their dependency inventories.
Why This Process Matters
The journey from research discovery to global CVE coverage is critical for modern software security.
Each stage plays a role:
Research teams discover vulnerabilities.
Maintainers patch them.
CVE systems assign identifiers.
Threat intelligence platforms categorize them.
Media outlets report them.
Developer communities discuss them.
Security tools integrate them into vulnerability management workflows.
Without this ecosystem, organizations would struggle to identify newly discovered risks in their software supply chains.
Lessons From CVE-2026-29000
Beyond the vulnerability itself, this case highlights an important pattern in modern security.
The most dangerous vulnerabilities often arise not from broken cryptographic primitives but from incorrect assumptions about how those primitives are used.
In this case:
Encryption worked correctly.
JWT libraries behaved correctly.
But the authentication logic assumed that encrypted tokens would always contain signed payloads.
That assumption was never enforced.
And that small gap allowed attackers to bypass authentication entirely.
Why CVE Signals Matter
Modern security research does not end when a vulnerability is discovered.
It only becomes impactful when the discovery propagates across the security ecosystem and reaches the engineers responsible for maintaining production systems.
CVE-2026-29000 illustrates how quickly this process can unfold.
A vulnerability discovered during a code audit moved through disclosure, patching, CVE assignment, vulnerability databases, national CERT advisories, and developer communities within days.
This ecosystem ensures that security signals reach organizations worldwide.
But it also highlights a deeper lesson.
The most severe vulnerabilities rarely come from broken cryptography or obscure memory corruption bugs.
They arise from assumptions embedded in authentication logic.
And when those assumptions fail, the impact can ripple across the entire software supply chain.
Final Thoughts
Modern security research does not end when a vulnerability is discovered.
It only becomes impactful when the finding propagates through the vulnerability ecosystem and reaches the engineers responsible for maintaining production systems.
The journey of CVE-2026-29000, from research discovery to global vulnerability feeds, illustrates how that process works.
And it demonstrates how a single vulnerability can quickly become visible across security intelligence platforms worldwide.
For the full technical analysis and proof-of-concept exploit, see the original research disclosure by the CodeAnt AI Security Research team:
👉 https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
FAQs
What is CVE-2026-29000?
How was CVE-2026-29000 discovered?
Why is CVE-2026-29000 rated CVSS 10?
How do vulnerabilities propagate through the security ecosystem?
Why are CVEs important for security teams?
Table of Contents
Start Your 14-Day Free Trial
AI code reviews, security, and quality trusted by modern engineering teams. No credit card required!
Share blog:
Made with Love in San Francisco
355 Bryant St. San Francisco, CA 94107, USA
Ask AI for summary of CodeAnt
Made with Love in San Francisco
355 Bryant St. San Francisco, CA 94107, USA
Ask AI for summary of CodeAnt
Made with Love in San Francisco
355 Bryant St. San Francisco, CA 94107, USA
Ask AI for summary of CodeAnt