Overview

This is an initial Apereo CAS project vulnerability disclosure, which describes a series of security vulnerabilities that affect different features and aspects of the CAS server. Additional details will be made public once the security grace window has passed.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.3.x

If your CAS version is not listed above AND is still part of an active maintenance cycle per the CAS maintenance policy, then best effort (analysis or confirmation from reporters/testers) indicates that the version is not affected by this issue. That said, please note that per the project’s Apache2 license, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. For additional information, please see the project license.

If you are (or your institution is) a member of the Apereo foundation with an active support subscription supporting the CAS project, please contact the CAS subs working group to learn more about this security vulnerability report.

Exposure

You are affected by this security vulnerability IF ANY of the following separate conditions apply to your CAS deployment:

1. Your CAS server is using Google Authenticator for multifactor authentication and storing user device records in Redis.
2. Your CAS server is using Redis to store tickets, complemented with a local cache.
3. Your CAS server is acting as an OpenID Connect identity provider.

These conditions are separate from one another and operate independently. Again, your CAS deployment is considered vulnerable IF ANY of the above conditions are true for your CAS deployment.

Timeline & Credits

Issue: Google Authenticator with Redis

The issue was originally reported to the CAS project on May 28th, 2026 and fixed on June 1st, 2026. The reporter declined to be listed in this advisory. Thank you anyway!

Issue: Redis Ticket Registry

This issue was originally reported to the CAS project on May 30th, 2026 by Georgia Tech’s Enterprise Application and Identity teams and a candidate fix was offered on June 1st, 2026. While final reporter confirmation is still pending, our analysis gives us reasonable confidence that the issue has been addressed. We may iterate further if additional testing identifies gaps. As ever, we appreciate Georgia Tech’s cooperation and willingness to report and verify the fixes.

Issue: OpenID Connect

This issue was originally reported to the CAS project on June 2nd, 2026 by Richard Gašparík, an ethical hacker at Citadelo and was fixed on June 3rd, 2026. Citadelo is a European cybersecurity company that focuses primarily on penetration testing and offensive security, helping organizations across Europe find and fix vulnerabilities before attackers do. We also wish to credit Richard’s colleague, Josef Korbel, who worked on the penetration test with Richard and helped to find the vulnerabilities.

We appreciate Richard’s and Josef’s time and effort who shared complete and thorough instructions on how this vulnerability can be observed and exercised and were able to ultimately verify the fix. Thank you both very much!

Patching

Patch releases were published on June 5th, 2026. Upgrades to the next patch version for each release should be a drop-in replacement.

Versions

Given the timeline and severity of the reported issues, we decided to publish one security patch release for affected versions per the CAS maintenance policy, rather than individual releases for every fix and issue. This was a rather unusual event where we received multiple security reports all around the same timeframe and one release to rule them all helps us reduce maintenance burden and release churn, as the fixes are quite targeted and surgical.

7.3.x

Modify your CAS overlay to point to the version 7.3.7.2.

How to upgrade

• Locate your gradle.properties file in your CAS overlay, found at the root of the project.
• Modify your CAS version to point to the appropriate release version noted above by updating the cas.version property.
• Follow the instructions in the README.md file to build the server, i.e. ./gradlew[.bat] clean build.

Security In The AI Era

We are beginning to see a clear trend in how security issues are researched and reported: AI is playing a much larger role in analyzing, documenting, explaining, and submitting potential vulnerability reports. This is not unique to CAS. It is happening across open source. The same productivity gains that AI gives developers and maintainers are also changing how code is reviewed, assessed, challenged, and patched. As this article puts it:

It’s one thing for a development team of 4-10 engineers to use generative AI to build new features faster. It’s a whole other situation when, for each engineer on the team, there are dozens in our community using generative AI to create issues, pull requests, and security reports.

AI did not just learn to write code. It also learned to open security reports, explain them confidently, attach a proof of concept, and then politely ask why nobody has fixed it yet! This trend is likely to accelerate. With that in mind, we would like to highlight two practical points:

• Maintainer capacity is a real constraint. Human resources and available maintainer time matter a great deal here. It is very likely that time-to-fix expectations will need to stretch, not just for CAS but for many open source projects. If the volume of security reports becomes difficult to manage, our response may be slower than usual. There are only a few of us, and many of you, them, and possibly a small army of extremely confident, polite autocomplete machines. Please set expectations accordingly, and review the vulnerability response process to understand how reports are handled and what commitments, if any, can realistically be made.

• Automated verification and deployment are no longer optional luxuries. It is becoming increasingly important for adopters of open source projects, especially CAS, to invest in tooling and processes that support automated release verification, automated integration testing, reliable CI/CD pipelines, and fast production deployment. If your current deployment process depends on manual steps, delayed approvals, synchronous coordination, or one heroic person remembering the exact production checklist from 2019, you may start to feel the pain. As security fixes and patches appear more frequently, teams with slow or manual deployment practices will have a harder time consuming updates quickly and safely.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

If you or your institution is a member of the Apereo foundation with an active CAS subscription supporting the CAS project, please contact the CAS subs working group to learn more about this security vulnerability.

Resources

• CAS Security Vulnerability Response Model
• CAS Maintenance Policy
• CAS Mailing Lists

On behalf of the CAS Application Security working group,

Misagh Moayyed