Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN609 _____________________________________________________________________ DATE : 09/06/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Apereo CAS server versions 7.3.x prior to 7.3.7.2. ===================================================================== https://apereo.github.io/2026/06/06/vuln/ _____________________________________________________________________ CAS Vulnerability Disclosure Saturday, Jun 6, 2026 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: Your CAS server is using Google Authenticator for multifactor authentication and storing user device records in Redis. Your CAS server is using Redis to store tickets, complemented with a local cache. 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. THIS IS SERIOUS! Our initial analysis of issue #3, where CAS acts as an OpenID Connect identity provider in a vulnerable state, indicates that the impact may extend beyond OpenID Connect provider functionality. The issue may affect broader CAS server behavior and could potentially lead to remote code execution. Even if you do not believe you are affected by any of the above conditions, we VERY STRONGLY recommend that you upgrade anyway. 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! CVEs The Citadelo team has reserved CVEs for this issue. We'll notify them to publish the records and make CVEs public, once the security grace period has passed. Patching Patch releases were published on June 5th, 2026. Upgrades to the next patch version for each release should be a drop-in replacement. Drop-in Replacement? For the most part, a drop-in replacement release (as is the case for almost all security patch releases) does not require you to change platform requirements, Java versions, application registration records, user interface, CAS configuration, logging semantics, etc. For most deployments, this should be closer to “upgrade and verify” than “cancel your weekend.”, unless explicitly (and uncommonly) noted otherwise. The only serious exception to this rule would be in scenarios where you have modified Java code and CAS server internal components and your changes directly overwrite upstream's fixes. While we do our best to ensure fixes are non-intrusive with a low footprint as much as possible, we cannot guarantee that your custom Java components that entirely overwrite and overlay on top of CAS remain fully functional or compatible with CAS APIs and implementations. The risk with owning code is that you own the code. Review and assess carefully. 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. Forward Ports Any CAS version that is still in development and considered a work-in-progress automatically receives any and all fixes. All changes are expected to be carried forward and released in due time. 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 ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================