Summary
The CAS overlay is vulnerable to CVE-2026-29000 - a critical authentication bypass vulnerability in pac4j-jwt (CVSS 9.1).
Current version: pac4j 1.7.1
Fixed in: pac4j 4.5.9+
Vulnerability: JWT signature validation bypass allowing attackers to forge valid tokens
Impact
This vulnerability affects:
- OSF Username and Password Login
- OSF Authentication Delegation (ORCiD Login with OAuth)
- Institution Login with CAS
- Institution Login with SAML
- OSF OAuth Provider
All authentication flows using pac4j are potentially vulnerable to token forgery attacks.
Why Simple Upgrade Is Not Possible
Unfortunately, upgrading pac4j from 1.7.1 to 4.5.9 is not a simple dependency bump. This is a major version upgrade (1.x → 4.x) that requires:
1. CAS Version Incompatibility
- Current: CAS 4.1.x (based on Apereo CAS 4.1.x from ~2015-2016)
- CAS 4.1.x is tightly coupled to pac4j 1.x APIs
- pac4j 4.x requires CAS 5.x or 6.x minimum
2. Breaking API Changes
The custom pac4j integration code in this overlay uses pac4j 1.x APIs extensively:
Files requiring updates:
cas-server-support-osf/src/main/java/org/jasig/cas/support/pac4j/web/flow/ClientAction.java (336 lines)
cas-server-support-osf/src/main/java/org/jasig/cas/support/pac4j/authentication/handler/support/ClientAuthenticationHandler.java
cas-server-support-osf/src/main/java/org/jasig/cas/support/pac4j/authentication/handler/support/AbstractClientAuthenticationHandler.java
- Additional files using pac4j OAuth clients
Key API changes (pac4j 1.x → 4.x):
J2EContext → JEEContext (renamed)
BaseClient<Credentials, CommonProfile> → new generic structure
RequiresHttpAction exception → different exception handling
getCredentials(webContext) → API signature changed
ProfileHelper.setKeepRawData() → removed/changed
Mechanism enum → modified/replaced
3. Testing Requirements
Given this is the centralized authentication system for OSF, Preprints, Registries, and SHARE:
- Extensive integration testing required
- All OAuth flows need verification
- Institution SSO (CAS/SAML) must be tested
- Two-factor authentication validation needed
Recommended Approach
Option 1: Upgrade CAS (Recommended for Long-term)
- Upgrade to CAS 5.x or 6.x (supports pac4j 4.x+)
- Update all custom pac4j integration code
- Update configuration files
- Comprehensive testing of all authentication flows
- Migration guide: https://apereo.github.io/cas/6.6.x/installation/Upgrading-Guide.html
Pros:
- Fixes CVE-2026-29000
- Modernizes infrastructure
- Gets latest security patches
- Better long-term support
Cons:
- Significant development effort (weeks/months)
- Requires extensive testing
- May need infrastructure changes
Option 2: Backport Security Patch (Short-term Workaround)
- Extract the JWT signature validation fix from pac4j 4.5.9
- Patch the pac4j 1.7.1 source directly
- Build custom pac4j 1.7.1-security1 jar
- Replace in overlay
Pros:
- Minimal code changes
- Faster to implement
- Lower risk
Cons:
- Technical debt increases
- Still on unsupported CAS 4.1.x
- Future vulnerabilities require more patches
Option 3: Web Application Firewall (Immediate Mitigation)
- Add WAF rules to detect/block JWT forgery attempts
- Implement additional token validation at API gateway
- Enhanced monitoring for suspicious auth patterns
Pros:
- Can be deployed immediately
- Defense in depth
Cons:
- Not a real fix
- May have false positives
- Attackers may find bypasses
Immediate Actions
-
Assess current exposure:
- Are JWT tokens used in production?
- What is the attack surface?
- Are there compensating controls?
-
Consider interim mitigations:
- WAF rules
- Enhanced monitoring
- Token validation checks
-
Plan CAS upgrade:
- Resource allocation
- Testing strategy
- Deployment timeline
References
Labels: security, critical, authentication, dependencies
Priority: High
Severity: Critical (CVSS 9.1)
Summary
The CAS overlay is vulnerable to CVE-2026-29000 - a critical authentication bypass vulnerability in pac4j-jwt (CVSS 9.1).
Current version: pac4j 1.7.1
Fixed in: pac4j 4.5.9+
Vulnerability: JWT signature validation bypass allowing attackers to forge valid tokens
Impact
This vulnerability affects:
All authentication flows using pac4j are potentially vulnerable to token forgery attacks.
Why Simple Upgrade Is Not Possible
Unfortunately, upgrading pac4j from 1.7.1 to 4.5.9 is not a simple dependency bump. This is a major version upgrade (1.x → 4.x) that requires:
1. CAS Version Incompatibility
2. Breaking API Changes
The custom pac4j integration code in this overlay uses pac4j 1.x APIs extensively:
Files requiring updates:
cas-server-support-osf/src/main/java/org/jasig/cas/support/pac4j/web/flow/ClientAction.java(336 lines)cas-server-support-osf/src/main/java/org/jasig/cas/support/pac4j/authentication/handler/support/ClientAuthenticationHandler.javacas-server-support-osf/src/main/java/org/jasig/cas/support/pac4j/authentication/handler/support/AbstractClientAuthenticationHandler.javaKey API changes (pac4j 1.x → 4.x):
J2EContext→JEEContext(renamed)BaseClient<Credentials, CommonProfile>→ new generic structureRequiresHttpActionexception → different exception handlinggetCredentials(webContext)→ API signature changedProfileHelper.setKeepRawData()→ removed/changedMechanismenum → modified/replaced3. Testing Requirements
Given this is the centralized authentication system for OSF, Preprints, Registries, and SHARE:
Recommended Approach
Option 1: Upgrade CAS (Recommended for Long-term)
Pros:
Cons:
Option 2: Backport Security Patch (Short-term Workaround)
Pros:
Cons:
Option 3: Web Application Firewall (Immediate Mitigation)
Pros:
Cons:
Immediate Actions
Assess current exposure:
Consider interim mitigations:
Plan CAS upgrade:
References
pom.xmlline 710)Labels: security, critical, authentication, dependencies
Priority: High
Severity: Critical (CVSS 9.1)