Apereo Community Blog

CAS Vulnerability Disclosure

Sat, 06 Jun 2026 00:00:00 +0000

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

On behalf of the CAS Application Security working group,

Misagh Moayyed

CAS OpenID Connect Vulnerability Disclosure

Wed, 27 May 2026 00:00:00 +0000

Overview

This is an initial Apereo CAS project vulnerability disclosure, describing an issue in CAS acting and running as an OpenID Connect provider. 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.

Credits

This issue was originally reported to the team at Coop (Switzerland), namely Artur Stoecklin and David Roth, via the YesWeHack platform, which is a “global crowdsourced security and bug bounty platform that connects organizations with a vetted community of tens of thousands of ethical (white-hat) hackers to identify and report vulnerabilities in websites, mobile apps, and infrastructure”. Both the original reporter as well as the team at YesWeHack shared complete and thorough instructions on how this vulnerability can be observed and exercised. The team at Coop (Switzerland) further validated and tested the fix.

Thank you everyone!

Affected Deployments

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

- 7.3.x

Severity

You are affected by this security vulnerability IF AND ONLY IF your CAS deployment is acting and running as an OpenID Connect identity provider. Additional details will be made public once the security grace window has passed.

If your deployment does not pass the noted condition(s) above, there is nothing for you to do here. Keep calm and carry on.

Timeline

The issue was originally reported to the team at Coop (Switzerland) on May 5th, 2026 and was shared with the CAS project on May 22nd, 2026. Upon confirmation, CAS releases were patched and eventually published on May 27th, 2026.

Patching

Patch releases are available to address CAS deployments. Upgrades to the next patch version for each release should be a drop-in replacement.

Affected Versions

7.3.x

Modify your CAS overlay to point to the version 7.3.7.1.

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 approriate 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.

Support

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

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Java CAS Client JWT Vulnerability Disclosure

Wed, 20 May 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in the Java CAS Client while validating tickets issued as JWT.

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

Credits

This issue was reported to the project by a third-party researcher and was then further validated and tested by Mr. Jérôme Leleu, who is a project member and an active committer.

Thank you everyone!

Affected Deployments

If you have an application that uses the Java CAS client to intergrate with a CAS server and is configured to accept and validate JWTs from that server, you are affected and do need to upgrade. If this condition does not pass for your application deployments, there is nothing for you to do here. Keep calm and carry on.

If you 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.

Timeline

The issue was originally reported on May 2nd 2026, and upon confirmation, Java CAS client releases were patched and eventually published on May 20th, 2026.

Patching

Upgrade your applications to use Java CAS client’s version 4.1.1.

Support

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

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Apereo CAS - External Identity Providers

Sat, 25 Apr 2026 00:00:00 +0000

External identity providers registered with CAS, such as those that speak the OpenID Connect or SAML2 protocol largely remain static throughout the server lifecycle. Once built and available, their configuration remains in read-only mode and can only be modified with direct access to CAS configuration, server rebuilds and restarts.

Building on top of Dynamic Configuration Management features, newer CAS 8.x releases now allow one to register and modify external identity providers that can be used for delegated authentication attempts. The registration of external identity providers is now handled and supported by the Palantir admin dashbord.

This post provides an overview of external identity providers can be registered with the CAS server dynamically, without having to restart the server. Please note that this work is supported by and executed as part of the CAS proposal to NLnet.

Overview

As discussed, the main objective here is to allow the Palantir admin dashbord to support registering external identity providers. Doing so requires one to use Dynamic Configuration Management features of CAS to allow on-the-fly registration of external providers and gain the ability to edit their configuration without having to rebuild or restart.

Starting with most recent releases of CAS 8.x, Palantir admin dashbord now provides a humble view of all available external identity providers, regardless of their method of registration and configuration:

The most notable change here is the NEW button which allows one to register an identity provider. Available identity provider types are for now limited to the following set:

CAS

OpenID Connect

OAUTH

Keycloak

SAML2

Modifications

The registration process requires Dynamic Configuration Management features of CAS. Once an identity provider is registered, its configuration can be modified and edited exactly as any other CAS setting, since all configuration constructs are eventually translated to CAS properties and ultimately become available to the CAS application context.

Roadmap

The admin dashboard today supports a limited set of external identity provider types and a narrowed populist view of what can be configured for each provider. Going forward, the intention is to customize and enhance the registration process to add more identity provider types and support additional settings as necessary.

On behalf of the CAS project,

Misagh Moayyed

CAS JWT Authentication Vulnerability Disclosure

Fri, 06 Mar 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in CAS while using a token-based JWT Authentication feature.

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

Credits

This issue was originally reported, researched and tested by Mr. Jérôme Leleu, who is a project member and an active committer. Jérôme was kind enough to thoroughly investigate the issue, discuss the problem in detail, provide steps to reproduce the problem and offer insight to diagnose the root cause.

Thank you Jérôme!

Affected Deployments

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

- 7.2.x
- 7.3.x

Severity

You are effected by this security vulnerability if your CAS deployment has specifically enabled a feature called JWT Authentication, sometimes also referred to as token-based non-interactive authN and accepts credentials as JWTs for non-interactive authentication attempts. Note that this has nothing to do with any other CAS functionality that deals with JWTs.

For better details, see:

When JwtAuthenticator decrypts a JWE, it attempts to parse the inner token as a SignedJWT. If the inner token is a PlainJWT (alg=none), the SignedJWT object is null and the signature verification path is skipped due to a logic error. The code then builds a user profile from unverified claims, enabling full impersonation. Impacted deployments are those using RSA-based JWE together with JwtAuthenticator configured with both EncryptionConfiguration and SignatureConfiguration.

If your deployment does not pass the noted condition(s) above, there is nothing for you to do here. Keep calm and carry on.

Timeline

The issue was originally reported on March 2nd 2026, and upon confirmation, CAS releases were patched and eventually published on March 6th, 2026.

Patching

Patch releases are available to address CAS deployments. Upgrades to the next patch version for each release should be a drop-in replacement.

Affected Versions

7.2.x

Modify your CAS overlay to point to the version 7.2.7.1.

7.3.x

Modify your CAS overlay to point to the version 7.3.5.

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 approriate release by updating the cas.version property.
Follow the instructions in the README.md file to build the server.

Support

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

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Performance improvements on the service registry

Mon, 09 Feb 2026 00:00:00 +0000

This is a task planned through NLNet funding.

Context

When it comes to the CAS server, performance is generally not a concern. Going with the defaults should be enough in 99% of cases.

However, in some rare edge cases, the performance of the service registry can become a problem. The service registry is the storage used to define all the applications allowed to authenticate with the CAS server via the CAS, OAuth, SAML, or OpenID Connect protocols.

With a few hundred services, performance can drastically deteriorate. Therefore, we have worked on improving the performance of the service registry for all use cases.

Benchmarks and profiling have been conducted to understand the main hotspots of time consumption. Two features are particularly resource-consuming: sorting services and matching services.

Better sorting

Despite careful code reviews, there is always room to improve the source code. The first action we took was to turn the internal Comparator used in the BaseRegisteredService component into a singleton shared across all instances:

    private static final Comparator<RegisteredService> INTERNAL_COMPARATOR = Comparator
        .comparingInt(RegisteredService::getEvaluationPriority)
        .thenComparingInt(RegisteredService::getEvaluationOrder)
        .thenComparing(service -> StringUtils.defaultString(service.getName()), String.CASE_INSENSITIVE_ORDER)
        .thenComparing(RegisteredService::getServiceId)
        .thenComparingLong(RegisteredService::getId);

as well as improving string comparison by using String.CASE_INSENSITIVE_ORDER.

Better matching

In Java pattern matching, creating regex patterns is always very time-consuming, and a global cache was already available to improve performance.

However, thorough tests have shown that things could be improved further in this area by using a specific property to store the regex pattern in BaseRegisteredService:

    @JsonIgnore
    @Getter(AccessLevel.NONE)
    @Setter(AccessLevel.NONE)
    @Transient
    private transient Pattern patternServiceId;

    ...
    
    /**
     * Set the service identifier and pre-compute its regex pattern.
     *
     * @param serviceId the service id
     */
    @CanIgnoreReturnValue
    public BaseRegisteredService setServiceId(final String serviceId) {
        Assert.notNull(serviceId, "Service id cannot be null");
        this.serviceId = serviceId;
        this.patternServiceId = RegexUtils.createPattern(serviceId);
        return this;
    }
    
    @Override
    public Pattern compileServiceIdPattern() {
        if (this.patternServiceId == null) {
            setServiceId(this.serviceId);
        }
        return this.patternServiceId;
    }

And to use it for matching:

    @Override
    public boolean matches(final RegisteredService registeredService, final String serviceId) {
        return registeredService.compileServiceIdPattern().matcher(serviceId).matches();
    }

With these two improvements, the benchmark (on a CAS server with 1000 services) between version 8.0.0-RC1 and the latest version 8.0.0-SNAPSHOT shows that the reference time drops from 81 seconds to 51 seconds!

Going further

Despite these improvements, the benchmarks still show that a lot of time is spent in the “sorting phase”:

The slowdown is located in the getCandidateServicesToMatch method of the DefaultServicesManager component. Indeed, despite the cache of services, the sorted clause is still applied and consumes a lot of time.

So, in the case of a cache size set to 0:

cas.service-registry.cache.initial-capacity: 0
cas.service-registry.cache.cache-size: 0

we now keep a copy of the sorted list of services, which makes processing much faster.

With this change in place and enabled (size set to 0), the benchmark time drops again to 24 seconds!

This might be a new option to enable if you have clearly identified that the service registry does not perform well in your CAS deployment.

Availability

The performance improvements described in this document will ultimately be available in CAS 8.0.0, and you should be able to benefit from them as of 8.0.0-RC2.

On behalf of the CAS project,

Jerome LELEU

Apereo CAS Dynamic Configuration Management

Sat, 07 Feb 2026 00:00:00 +0000

Configuration sources that supply properties and settings to Apereo CAS server deployments generally tend to be static. Their main responsibility is to feed the server a collection of properties and settings, typically very early on during the bootstrapping phase, before the CAS application context has had a chance to be created. Once built and available, the application context remains largely in read-only mode and can only be observed until the next restart.

This post provides an overview of how configuration sources can provide dynamic updates to the CAS server and allow it to react and reload its configuration and components without having to restart the server. Please note that this work is commissioned as part of the CAS proposal to NLnet.

Overview

Configuration sources in Apereo CAS typically include static .properties or .yaml files. Once the server has had a chance to read and process the collection of settings in such files, they mainly stay out of the way and subsequent changes to these files usually requires a restart. While CAS can be configured to watch for updates to property files and react, our objective here is mainly focused on external configuration sources, particularly those that are based on SQL databases or MongoDb.

In addition to allowing CAS to use such external sources to support dynamic updates, we also intend to extend this functionality and make it available in the CAS admin interface, codenamed Palantir. Today, Palantir presents a read-only web view of active configuration settings and properties that control server behavior. The operator is only able to view all properties and settings, as well as their source, default values, etc. Thus, we intend to enhance Palantir functionality to allow the CAS operator to add, edit, and possibly remove configuration settings at runtime using a web-based editor. The operator should have the ability to update existing settings or add new ones, have them be stored in the appropriate persistent configuration store that survives restarts. All server functionality that depends on a given setting should be able to seamlessly refresh itself to work with the new copy of the setting.

MongoDb Configuration Source

It is already possible to use an external MongoDb instance as the configuration source for CAS properties. This capability is handled by the cas-server-support-configuration-cloud-mongo module, which automatically creates a collection called MongoDbProperty and stores properties using this structure:

{
    "id": "kfhf945jegnsd45sdg93452",
    "name": "the-setting-name",
    "value": "the-setting-value"
}

To teach CAS about the MongoDb instance, the connection information can be supplied via:

export CAS_SPRING_CLOUD_MONGO_URI="mongodb://..."

The underlying core component, MongoDbPropertySource, is one that is modified to implement operations requested by a MutablePropertySource. Mutability in this case means that the source can be updated, settings can be removed, etc. This is the mechanism required of all property sources in CAS (that is absent in Spring Cloud today), if they wish to participate in dynamic updates. Of course, when you just start out, the MongoDb collection is empty, and it can live next to your existing .properties and .yaml files, though it has a higher priority and can be asked to override settings elsewhere.

Also note that, as implied, while the focus here is mainly on MongoDb, you can run CAS with multiple configuration sources at the same time. On paper, it is possible to have CAS load properties from files, MongoDb, SQL databases, etc., all at the same time.

Now, when you build and launch the Palantir admin module, you may be presented with this interface:

You can start by creating configuration properties:

Or reload what is already there, delete and clear everything, or import from .properties or .yaml files. The import functionality might be especially useful if you wish to migrate from one static source, such as a .properties file to a dynamic source like MongoDb.

When creating new settings, you can also switch to the Environment tab and look at how the CAS application context and environment is formed.

You can look at the effective value for a property:

Or take something that is available, import it into your dynamic property source (i.e. MongoDb) and override its value:

Important: remember that just because a property exists in a configuration source, it does not mean that CAS will be able to immediately notice the change to start using it. The configuration source is mainly kept in isolation and separate from the active runtime context, and can be changed and updated as many times as necessary until you’re ready to put changes into effect. When the time is right, you can ask CAS to refresh itself:

Once refreshed, CAS settings that are put into your configuration source should be activated.

SQL Configuration Source

Note that the exact same concept is available to CAS when a SQL database is used to house configuration settings. The difference now is, this capability is handled by the cas-server-support-configuration-cloud-jdbc module. By default, settings are expected to be found under a CAS_SETTINGS_TABLE that contains the columns: id, name and value. Note that id is a unique identifier for each record and may be generated automatically.

And similar to MongoDb, the SQL connection information can be taught to CAS via:

export CAS_SPRING_CLOUD_JDBC_URL="jdbc:..."

Availability

The capabilities described in this document will ultimately be available in CAS 8.0.0, and you should be able to start playing with them as of 8.0.0-RC2. The configuration sources that can handle dynamic updates and are covered include:

Amazon S3
Amazon DynamoDb
Amazon Secret Manager
Amazon Systems Manager Parameter Store (SSM)
JDBC (As was covered here)
MongoDb (As was covered here)
REST

Subsequent improvements and fixes will also be included in future release candidates prior to the final release.

On behalf of the CAS project,

Misagh Moayyed

Apereo CAS Receives NLnet Grant to Advance CAS Development

Sun, 01 Feb 2026 00:00:00 +0000

We’re excited to share that the Apereo CAS project has been awarded funding from NLnet, through the NGI0 Commons Fund, to support the development of CAS — an initiative aimed at strengthening open, sovereign, and self-hosted identity infrastructure on the internet.

We also extend our sincere gratitude to the Apereo Foundation for their continued support and stewardship. Their assistance was instrumental in helping us secure the necessary funding, and their commitment to open source identity infrastructure remains a vital part of the CAS project’s ongoing success.

About Apereo

The Apereo Foundation is a global non-profit advancing open source software in service of higher education. Since its founding in 2012, Apereo has empowered colleges and universities to build, use, and sustain innovative software for teaching, learning, research, and campus operations. At the heart of Apereo is a vibrant, collaborative community—institutions, educators, developers, and technologists—working together to solve common challenges and shape the future of education technology. Through shared development, open governance, and a culture of transparency, members co-create solutions that are cost-effective, adaptable, and aligned with academic values.

About CAS

Apereo CAS (Central Authentication Service), released under an Apache 2.0 license, is an open source identity provider. Offering native clustering capabilities and a resilient architecture, Apereo CAS acts as an identity provider for all applications deployed by an organization at scale, supporting hundreds of thousands of users. Developed in the early 2000s, Apereo CAS has since expanded to play a critical role in providing security across various public interests: government agencies, NGOs, and the business sector.

About NLnet

NLnet, a foundation dedicated to promoting open technologies that benefit the public interest, has committed funding to support the CAS development effort. This is provided via the NGI0 Commons Fund, which focuses on improving the privacy, resilience, and trustworthiness of internet infrastructure.

NLnet’s role is intentionally non-operational: the foundation exists to enable impactful work, not to direct it. The success of the project is measured by the public benefit it delivers to the wider internet and identity community.

Proposal & Work Ahead

Our proposal focuses on expanding CAS in specific areas that include support for better management interfaces, from smaller enhancements and bug fixes that focus on security to larger development efforts to improve authentication protocol support with a targetted focus on OpenID Connect.

All work produced under this project — including source code, designs, and documentation — will be released publicly under the Apereo CAS project existing license, Apache v2. The results will not be proprietary and can be freely used, modified, and repurposed by anyone.

This work is undertaken voluntarily and in the public interest. It is not an employment contract or a commercial arrangement; the funding here is provided to support open-source development aligned with NLnet’s mission. We’re grateful not only for NLnet’s support, but also for the broader ecosystem of experts and organizations involved with the NGI0 Commons Fund who help ensure projects like this have lasting, wide-reaching impact.

Tasks & Work Items

As part of this project, the following work items will be worked out and developed.

External Identity Provider Management

The CAS admin interface, codenamed Palantir, will be enhanced to allow for registration and modifications of identity providers for external authentication using a web-based editor. CAS already has the ability to support identity providers that understand the CAS, OpenID Connect, OAuth, or SAML2 protocols. However, the registration process for such identity providers requires access to CAS configuration files, which further require the deployer to rebuild and redeploy the software. This task intends to provide a graphical interface, included in Palantir, that allows one to register and update such identity providers without having to rebuild and redeploy the system, with the assumption that CAS configuration is backed by a persistent storage such as a SQL database or MongoDb.

Configuration Management

The CAS admin interface, codenamed Palantir, presents a read-only web view of active configuration settings and properties that control server behavior. The operator is only able to view all properties and settings as well as their source, default values, etc. Real changes to settings require manual modifications and server restarts. This task is about enhancing Palantir to allow the CAS operator to add, edit, and possibly remove configuration settings at runtime using a web-based editor. The operator should have the ability to update existing settings or add new ones, have them be stored in the appropriate persistent configuration store that survives restarts. All server functionality that depends on a given setting should be able to seamlessly refresh itself to work with the new copy of the setting. Specifically,

Support SQL databases for configuration store updates
Support MongoDb for configuration store updates

Release Maintenance

CAS is currently pushing towards its next major iteration under version 8.0.0. This task is about supporting the development lifecycle and allowing for several release candidates to be published, typically one every 4-5 weeks, to allow the community to experiment and to deliver a steady stream of fixes and minor enhancements before the final release. Activities include upgrading libraries, build tools, documentation corrections, minor bug fixes, and finally getting the release published. Our estimated timeline for the final GA release is around May/June 2026.

Performance Improvements

CAS stores its authorized applications in the services registry. When many applications are defined (several hundreds), there are performance drawbacks related to sorts and patterns computation. Specifically,

Improve sorting
Improve regular expression pattern computation

Bug Fixes

Passwordless support for LDAP does not properly handle MFA via an attribute.
Secret validation in OAuth suffers from URL decoding.
SAML logout requests sent in SOAP binding don’t have the proper form (extra parameter) and the right content type.
Process results from security audit and accessibility scan provided by NLnet.

OpenID Federation

Today, OpenID Connect is the standard protocol for authentication. It has many specifications on top of OAuth to bring new features (like sessions management), but the last big feature is Federation which should be available in CAS, acting both as a server and as a client. Specifically,

Implement the CAS server as a Trust Anchor
Implement the CAS server as a Federation Operator
Add federation support to the CAS server as an OP (/.well-known/openid-federation)
Add federation support to the CAS server as a RP: /.well-known/openid-federation, consume TA/Operator, validate chains up to an OP.

Open Development, Open Governance

The project is led by Misagh Moayyed and Jérôme Leleu, both long-time CAS core developers with deep experience in open standards and free software. Misagh will serve as the primary point of contact for the project.

In the spirit of transparency and collaboration:

Progress updates will be shared with the community at least every two months
A public status page will track milestones and outcomes
The broader CAS user and developer community is encouraged to follow along, contribute, and provide feedback.

Our efforts span an initial 12-month period, with the possibility of extension by mutual agreement if the work remains relevant. As always, success will be defined by usefulness, adoption, and the value delivered to the community.

We’re excited to get started and even more excited to build this together.

Stay tuned for updates, and thank you to NLnet and the NGI0 Commons Fund for investing in open identity, open infrastructure, and the public good.

On behalf of the Apereo Foundation & CAS project,

Misagh Moayyed, Jérôme Leleu, Josh Baron, Patrick Masson

CAS OAuth/OpenID Connect Vulnerability Disclosure

Thu, 25 Sep 2025 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in CAS acting as an OAuth/OpenID Connect provider.

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

Credits

This issue was originally reported by Luca Famà and was later corroborated by the team at Coop (Switzerland), namely Artur Stoecklin and David Roth. The group was kind enough to thoroughly investigate the issue, discuss the problem in detail, provide steps to reproduce the problem and offer insight to diagnose the root cause.

Thank you everyone!

Affected Deployments

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

- 7.1.x
- 7.2.x

Severity

You are effected by this security vulnerability if your CAS deployment is acting as an OAuth/OpenID Connect identity provider.

The issue primarily presents itself when CAS receives an OAuth or OpenID Connect authorization request, and in the absense of an SSO session, attempts to route the request to the login endpoint, constructing a special callback URL that is passed as the service parameter to the login endpoint. This callback URL essentially points back to CAS itself and restarts the flow once the login attempt is completed. The attacker could somehow hijack this callback URL and modify it in such a way that would fool CAS into redirecting to an unauthorized URL. This is caused given the fact that the callback URL is registered with CAS as an internal service whose matching policy is based on regular expressions and pattern matching, and as a result, the attacker could manipulate the service parameter such that the pattern enforced is bypassed.

In summary, this is an “Open Redirect” security vulnerability. We believe this is fairly low risk, and does not allow one to cause any major material damage to the CAS server.

If your deployment does not pass the noted condition(s) above, there is nothing for you to do here. Keep calm and carry on.

Timeline

The issue was originally reported on September 17th, 2025 and upon confirmation, CAS releases were patched and eventually published on September 25th, 2025.

Patching

Patch releases are available to address CAS deployments. Upgrades to the next patch version for each release should be a drop-in replacement.

Affected Versions

7.1.x

Modify your CAS overlay to point to the version 7.1.6.2.

7.2.x

Modify your CAS overlay to point to the version 7.2.7.

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 approriate release by updating the cas.version property.
Follow the instructions in the README.md file to build the server.

Support

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

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

CAS Simple Multifactor Authentication Vulnerability Disclosure

Tue, 19 Aug 2025 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in CAS acting as a simple multifactor authentication provider.

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

Credits

Thank you Jérôme!

Affected Deployments

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

- 7.1.x
- 7.2.x

Severity

You are effected by this security vulnerability if your CAS deployment is acting as a multifactor authentication provider and is using the CAS Simple MFA module.

Simple MFA in CAS generates its own codes using a secure random strategy to ensure generated IDs cannot collide with previously generated codes. One controlling factor here is the code length (6 by default). In scenarios where the code length is lowered to smaller lengths and typically under high traffic and load, it’s quite possible for one to run into code collisions and duplicates. As a result, two separate different users might be sharing the same code and may be able to log in as one another.

Fixes in this area force CAS to never a generate a code that was already generated and remains valid. The generate function should take this rule into account and will attempt to re-generate the code if it runs into a collision.

If your deployment does not pass the noted condition(s) above, there is nothing for you to do here. Keep calm and carry on.

Timeline

The issue was originally reported on August 18th, 2025 and upon confirmation, CAS releases were patched and eventually published on August 19th, 2025.

Patching

Patch releases are available to address CAS deployments. Upgrades to the next patch version for each release should be a drop-in replacement.

Affected Versions

7.1.x

Modify your CAS overlay to point to the version 7.1.6.1.

7.2.x

Modify your CAS overlay to point to the version 7.2.6.

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 approriate release by updating the cas.version property.
Follow the instructions in the README.md file to build the server.

Support

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

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed