Is pac4j Even Widely Used?

Whenever a new vulnerability appears in an open-source library, engineers usually ask the same question:

“How widely used is this package?”

It seems like the obvious way to measure risk.

If a vulnerable package is rarely deployed, the real-world impact might be limited.
If it powers thousands of systems, the consequences could be massive.

But modern software supply chains make this assumption misleading.

Recently, the CodeAnt AI Security Research team disclosed CVE-2026-29000, a critical authentication bypass in the Java library pac4j-jwt.

Almost immediately, a familiar question surfaced:

“How widely used is pac4j?”

The answer reveals something important about modern security.

Before looking at why package popularity can be misleading, it helps to briefly understand the vulnerability itself.

The issue discovered by the CodeAnt AI Security Research team was assigned CVE-2026-29000, a critical authentication bypass affecting the pac4j-jwt module.

The vulnerability allows attackers to craft encrypted tokens that bypass signature verification and authenticate as arbitrary users.

The key facts about the vulnerability are summarized below.

CVE-2026-29000 at a Glance

At first glance, this might appear to be just another library vulnerability.

But the real question engineers immediately asked after disclosure was:

“How widely used is pac4j?”

That question highlights a common misconception in software security. Risk is often evaluated using popularity metrics like download counts or GitHub stars. But for security-critical infrastructure libraries, those metrics can be deeply misleading.

To understand why, we need to look at how security components actually sit inside modern software architectures.

Measuring Library Impact Is Harder Than It Looks

Most engineers evaluate open-source adoption using simple metrics:

• GitHub stars

• download counts

• npm or Maven statistics

• repository popularity

Those metrics work reasonably well for developer tools or frameworks.

But they often fail for security infrastructure libraries.

Authentication frameworks, cryptographic helpers, and protocol adapters frequently have lower visibility but extremely high impact.

They sit in places where failure has disproportionate consequences.

pac4j is a perfect example of this category.

What pac4j Actually Is

pac4j is a Java security engine that provides authentication and authorization mechanisms across many identity providers.

It is commonly used as a middleware layer between web applications and identity systems.

Developers use pac4j to integrate authentication methods such as:

• OAuth

• OpenID Connect

• SAML

• LDAP

• JWT-based authentication

• CAS (Central Authentication Service)

Rather than implementing authentication logic themselves, developers plug pac4j into their application framework and configure authentication providers.

This architecture means pac4j frequently appears inside:

• enterprise web platforms

• SSO gateways

• identity proxies

• API authentication layers

In many deployments, pac4j sits directly in front of application access control.

Which means a vulnerability in pac4j is not just a library bug.

It becomes an authentication boundary failure.

The pac4j-jwt Component

Within the pac4j ecosystem, the pac4j-jwt module provides JWT-based authentication mechanisms.

It allows applications to validate encrypted and signed tokens issued by identity providers.

JWT authentication is widely used across modern distributed systems because it enables stateless identity verification.

When a token arrives, the server validates it and extracts claims such as:

• user identity

• permissions

• roles

• expiration timestamps

If the token passes verification, the server trusts those claims.

That trust boundary is exactly where our research uncovered the vulnerability.

The Vulnerability We Found

During a broader research effort auditing patched vulnerabilities across open-source ecosystems, our team analyzed the authentication flow inside pac4j-jwt.

Specifically, we examined how the JwtAuthenticator component processed encrypted tokens.

The intended flow is simple.

The two layers serve different purposes.

• Encryption ensures the token contents remain confidential.

• Signature verification ensures the token was issued by a trusted authority.

Both protections must succeed.

But during our analysis, our AI code reviewer flagged a suspicious condition surrounding signature verification.

That condition allowed authentication to proceed even when no signature had been validated.

The Core Bug

The vulnerability originated from how the library handled the inner JWT payload after decryption.

The pac4j code attempted to parse the decrypted payload as a signed JWT using a helper function provided by the Nimbus JOSE+JWT library.

If the payload was a signed token, the library returned the parsed object.

If the payload was not signed, the function returned null.

The pac4j logic then used a conditional check:

If the token was unsigned, the verification step never ran.

Yet the authentication process continued.

Eventually the system constructed an authenticated user profile from the token’s claims.

In other words:

an unsigned token could still authenticate a user.

Turning the Bug Into an Exploit

Once our security engineers understood this execution path, the exploit became surprisingly simple.

Instead of generating a signed token, an attacker could generate a PlainJWT.

PlainJWT is a token format defined by the JWT specification.

It contains claims but no signature.

The attacker could then wrap that token inside a JWE envelope encrypted with the server’s public key.

Because the outer token was encrypted correctly, the server would decrypt it successfully.

But because the inner token was unsigned, the signature verification block would never run.

The authentication flow would continue normally.

The server would trust whatever claims the attacker placed inside the token.

Why the Public Key Was Enough

Many JWT deployments use RSA-based encryption.

In these setups, the public key is intentionally distributed to clients so they can encrypt tokens.

Public keys commonly appear in:

• JWKS endpoints

• configuration files

• documentation

• TLS certificates

Because the authentication logic trusted decrypted tokens without verifying signatures, anyone possessing the public key could construct a token the server would accept.

Our proof-of-concept exploit authenticated successfully using nothing more than the server’s public key.

The attacker was able to authenticate as an administrator with elevated privileges.

The Patch

After validating the vulnerability, we privately disclosed the issue to pac4j maintainer Jérôme Leleu.

The report included:

• detailed technical analysis

• a working proof-of-concept exploit

• recommended remediation steps

The maintainer confirmed the vulnerability and released patched versions across three major release lines within two days.

The patched versions enforce signature verification before claims are accepted.

Users should upgrade to:

Why Package Popularity Is the Wrong Metric

Returning to the original question:

How widely used is pac4j?

The answer is less important than another question:

Where does pac4j sit in the system architecture?

Security infrastructure libraries often have lower visibility but higher impact because they sit at trust boundaries.

Examples include:

• authentication frameworks

• encryption libraries

• serialization frameworks

• request routing middleware

A vulnerability in any of these components can affect the entire application stack.

In the case of pac4j, the vulnerability appeared in authentication logic itself.

That makes the impact far more significant than raw adoption metrics might suggest.

A Pattern in Modern Security Bugs

The pac4j vulnerability also illustrates a broader pattern.

None of the individual components involved were broken.

The JWT specification correctly allows unsigned tokens.

The Nimbus library correctly returns null for non-signed payloads.

The pac4j code correctly checked whether the parsed token existed.

Yet when these components interacted, a security guarantee disappeared.

These types of vulnerabilities are known as composition flaws.

They arise when multiple components behave correctly in isolation but interact in unexpected ways.

As software ecosystems grow increasingly complex, these flaws are becoming more common.

What This Research Is About

The pac4j vulnerability was discovered during a broader research initiative at CodeAnt AI.

Our goal is to audit whether security patches in widely used open-source packages truly eliminate the root causes of vulnerabilities.

This work involves analyzing:

• patch diffs

• surrounding execution paths

• assumptions embedded in authentication and security logic

The pac4j finding is one example of what this approach can uncover.

Additional findings from this research will be published as coordinated disclosure timelines allow.

The Bigger Lesson

Security discussions often focus on package popularity.

But popularity is not always the right measure of risk.

The real question is:

Does this software sit on a critical trust boundary?

Authentication frameworks do.

Encryption libraries do.

Serialization layers do.

When vulnerabilities appear in these components, their impact can extend far beyond the size of the package’s user base.

The pac4j vulnerability demonstrates how a single assumption in authentication logic can allow attackers to bypass identity verification entirely.

And it reminds us that the most dangerous vulnerabilities often appear not in obscure code, but at the very boundaries where systems decide who is allowed in.