Pac4j CVEs with no public exploit
5 CVEs, 1 protected by Waratek
Overview 5 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
1
20.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
4
80.0%
blocked by ARMR today
1
20.0%
partly blocked
0
0.0%
not blocked
4
80.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
5
100.0%
split by
peak 1 / year
20191
No exploit published1
Medium1
not blocked1
No public exploit1
20200
20210
20221
No exploit published1
High1
not blocked1
No public exploit1
20230
20241
No exploit published1
Medium1
not blocked1
No public exploit1
20251
Protected by Waratek1
High1
blocked by ARMR today1
No public exploit1
20261
No exploit published1
High1
not blocked1
No public exploit1
20192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-40458 | High | 2026-04-17 | No exploit published | No public exploit | PAC4J is vulnerable to Cross-Site Request Forgery (CSRF). A malicious attacker can craft a specially designed website which, when visited by a user, will automatically submit a forged cross-site request with a token whose hash collides with the victim's legitimate CSRF token. Importantly, the attacker does not need to know the victim’s CSRF token or its hash prior to the attack. Collisions in the deterministic String.hashCode() function can be computed directly, reducing the effective token's security space to 32 bits. This bypasses CSRF protection, allowing profile updates, password changes, account linking, and any other state-changing operations to be performed without the victim's consent. This issue was fixed in PAC4J versions 5.7.10 and 6.4.1 |
| CVE-2025-31129 | High | 2025-03-31 | Protected by Waratek | No public exploit | Jooby is a web framework for Java and Kotlin. The pac4j io.jooby.internal.pac4j.SessionStoreImpl#get module deserializes untrusted data. This vulnerability is fixed in 2.17.0 (2.x) and 3.7.0 (3.x). |
| CVE-2024-45384 | Medium | 2024-09-17 | No exploit published | No public exploit | Padding Oracle vulnerability in Apache Druid extension, druid-pac4j. This could allow an attacker to manipulate a pac4j session cookie. This issue affects Apache Druid versions 0.18.0 through 30.0.0. Since the druid-pac4j extension is optional and disabled by default, Druid installations not using the druid-pac4j extension are not affected by this vulnerability. While we are not aware of a way to meaningfully exploit this flaw, we nevertheless recommend upgrading to version 30.0.1 or higher which fixes the issue and ensuring you have a strong druid.auth.pac4j.cookiePassphrase as a precaution. |
| CVE-2021-44878 | High | 2022-01-06 | No exploit published | No public exploit | If an OpenID Connect provider supports the "none" algorithm (i.e., tokens with no signature), pac4j v5.3.0 (and prior) does not refuse it without an explicit configuration on its side or for the "idtoken" response type which is not secure and violates the OpenID Core Specification. The "none" algorithm does not require any signature verification when validating the ID tokens, which allows the attacker to bypass the token validation by injecting a malformed ID token using "none" as the value of "alg" key in the header with an empty signature value. |
| CVE-2019-10755 | Medium | 2019-09-23 | No exploit published | No public exploit | The SAML identifier generated within SAML2Utils.java was found to make use of the apache commons-lang3 RandomStringUtils class which makes them predictable due to RandomStringUtils PRNG's algorithm not being cryptographically strong. This issue only affects the 3.X release of pac4j-saml. |