WaratekVRT Sign in

Pac4j CVEs

7 CVEs, 2 protected by Waratek

Reset
More filters (1)
Columns
Product pac4j✕
Overview 7 matches · 2 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
7matches 2protected28.6% 0exploited0.0% 0CISA KEV0.0% 1public PoC14.3% 0EPSS ≥ 0.50.0%
Protected by Waratek 2 28.6% Rule in development 0 0.0% Mitigation candidate 1 14.3% No exploit published 4 57.1%
Critical 2 28.6% High 3 42.9% Medium 2 28.6% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 2 28.6% partly blocked 0 0.0% not blocked 5 71.4% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 2 28.6% Forecast only 0 0.0% No public exploit 5 71.4%
split by peak 2 / year
No exploit published: 4Mitigation candidate: 1Protected by Waratek: 2 Medium: 2High: 3Critical: 2 not blocked: 5blocked by ARMR today: 2 No public exploit: 5Proof of concept only: 2
20191 No exploit published1 Medium1 not blocked1 No public exploit1 20200 20210 20221 No exploit published1 High1 not blocked1 No public exploit1 20230 20242 Protected by Waratek1 No exploit published1 Critical1 Medium1 blocked by ARMR today1 not blocked1 Proof of concept only1 No public exploit1 20251 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1 20262 Mitigation candidate1 No exploit published1 Critical1 High1 not blocked2 Proof of concept only1 No public exploit1
20192020202120222023202420252026
7 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
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-2026-29000 Critical 2026-03-04 Mitigation candidate Proof of concept only pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3 contain an authentication bypass vulnerability in JwtAuthenticator when processing encrypted JWTs that allows remote attackers to forge authentication tokens. Attackers who possess the server's RSA public key can create a JWE-wrapped PlainJWT with arbitrary subject and role claims, bypassing signature verification to authenticate as any user including administrators.
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-2023-25581 Critical 2024-10-10 Protected by Waratek Proof of concept only pac4j is a security framework for Java. `pac4j-core` prior to version 4.0.0 is affected by a Java deserialization vulnerability. The vulnerability affects systems that store externally controlled values in attributes of the `UserProfile` class from pac4j-core. It can be exploited by providing an attribute that contains a serialized Java object with a special prefix `{#sb64}` and Base64 encoding. This issue may lead to Remote Code Execution (RCE) in the worst case. Although a `RestrictedObjectInputStream` is in place, that puts some restriction on what classes can be deserialized, it still allows a broad range of java packages and potentially exploitable with different gadget chains. pac4j versions 4.0.0 and greater are not affected by this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability.
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.