Overview

This is an initial Apereo CAS project vulnerability disclosure, which describes a security vulnerability that affects how the CAS server manages state for authentication flows. 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 your CAS deployment manages its state for authentication webflows using the client browser. This is the default setup and configuration for almost all deployments.

Timeline & Credits

The issue was originally reported to the CAS project on June 16th, 2026 and fixed on June 17th, 2026. The reporter decided to remain anonymous. Thank you anyway!

Patching

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

Versions

7.3.x

Modify your CAS overlay to point to the version 7.3.7.3.

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