Apache Roller Hit by Severe Flaw Allowing Persistent Unauthorized Access
A serious vulnerability has been discovered in Apache Roller, the popular Java-based blogging platform, potentially letting attackers maintain access to accounts even after users change their passwords. The flaw carries the highest severity rating, highlighting the urgent need for administrators to patch their systems.

Apache Roller users! A serious security hole has been discovered in the popular open-source blogging software. This one's a doozy: it could let attackers keep access to your account even after you change your password.
The vulnerability, tracked as CVE-2025-24859, has been given a CVSS score of 10.0. That's as bad as it gets, indicating a critical severity. The issue affects all versions of Roller up to and including 6.1.4.
According to the official advisory, "A session management vulnerability exists in Apache Roller before version 6.1.5 where active user sessions are not properly invalidated after password changes."
In plain English, this means that if someone gets ahold of your password and you change it, their existing session might still be active. Yikes!
Think about the implications: someone could maintain access to your Roller account even after you've taken steps to secure it. If your credentials were ever compromised, this flaw could give attackers free rein.
The good news? A fix is available! Version 6.1.5 addresses the problem by implementing centralized session management. This ensures that all active sessions are invalidated when passwords are changed or users are disabled. So, upgrade ASAP!
Kudos to security researcher Haining Meng for finding and reporting this critical vulnerability.
This news comes on the heels of another critical flaw discovered in Apache Parquet's Java Library (CVE-2025-30065, CVSS score: 10.0). That one could let attackers remotely execute code on vulnerable systems. The hits just keep on coming!
And let's not forget the critical security flaw in Apache Tomcat (CVE-2025-24813, CVSS score: 9.8) that was actively exploited not long after it was revealed.