Last Week in AppSec for 04. November 2025

Here are some news items our team found interesting over the past week, which you might have missed.

• The Jenkins SAML Plugin, the official way to add SAML-based Enterprise Authentication to Jenkins, has a flaw (CVE-2025-64131 [reserved and unscored at time of writing]) which allows an attacker to capture SAML messages and “replay” them to successfully authenticate as a legitimate user. The weakness exists in versions up to and including 4.583.vc68232f7018a. The implementation should have contained a replay cache that makes checks to make sure a SAML assertion can only be used one time; fixed versions implement this control. Network encryption like mandatory HTTPS significantly reduces risk of exploit.
  
• In a return of a previously-fixed issue, Apache Tomcat’s RewriteValve system once again (CVE-2025-55752, CVSSv3=7.5)got the decoding and normalization order wrong for rewritten URLs, allowing attackers manipulate encoded path components in a way that grants them access to file paths on the server that would normally be restricted (Path Traversal), including WEB-INF and META-INF directories. In the (fairly rare) configuration where PUT actions are permitted, this vulnerability could also allow attackers to replace content on the server, potentially even leading to RCE (Remote Command Execution) of whatever an attacker wants. This issue impacts versions 9.0.0.M11 through 9.0.108, 10.1.0-M1 through 10.1.44, and 11.0.0-M1 through 11.0.10.

Note: this article contains code templates to assist identification of issues; these have received only basic testing, and may require modification for use in your environment. As always, read and understand code before using it.

Get Last Week In AppSec in your Inbox

Subscribe to Checkmarx Zero

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.

SAML Replay attack in Jenkins allows adversaries to impersonate users

The Jenkins SAML Plugin, the official way to add SAML-based Enterprise Authentication to Jenkins, has a flaw (CVE-2025-64131 [reserved and unscored at time of writing]) which allows an attacker to capture SAML messages and “replay” them to successfully authenticate as a legitimate user. The weakness exists in versions up to and including 4.583.vc68232f7018a. The implementation should have contained a replay cache that makes checks to make sure a SAML assertion can only be used one time; fixed versions implement this control. Network encryption like mandatory HTTPS significantly reduces risk of exploit.

SAML auth works in part by an identity provider (like Microsoft’s Entra ID or similar) signing an XML document called an “assertion”, which a Service Provider (SP) like Jenkins consumes as a proof that the user has been authenticated. To avoid a situation where an attacker can capture that signed document and just re-present it to authenticate, there are two common controls.

1. the IdP (Identity Provider) includes fields NotBefore and/or NotOnOrAfter, limiting the time during which the assertion can be considered valid. The SP (Service Provider) must robustly check those, though, since the IdP has no way to enfoce them.
2. the SP keeps the assertions (or their SHA sums or similar) in a cache until the NotOnOrAfter time is passed. When checking an assertion, the SP looks at the cache: if the assertion has been used before, the SP should reject it.

The Jenkins SAML Plugin implementation did not do the second step, leaving the system open to these replay attacks within the validity window set by the IdP.

Fortunately, Jenkins deployments that used some kind of encryption in transit (like HTTPS or IPSec) are very hard to exploit with this vulnerability, as an attacker would have to “Man-in-the-Middle” attack the system or otherwise break the encryption in order to capture valid SAML assertions in the first place. IdP’s with short assertion validity windows also lower risk by keeping the window to exploit a captured credential small.

Configuring Jenkins to require local MFA (Multi-Factor Authentication) for privileged accounts is also a possible mitigation factor, though it can introduce additional management overhead.

You can query the version of the SAML plugin, to determine which Jenkins servers are affected in your organization, using the following command template (replace user:APITOKEN with user name and API token that have sufficient access, and JENKINS_URL with the base URL for the Jenkins API):

# detects installed SAML plugin version
curl -s -u "user:APITOKEN" "https://JENKINS_URL/pluginManager/api/json?depth=1" \
  | jq -r '.plugins[] | select(.shortName=="saml") | .version'

Apache Tomcat URL rewriting can expose sensitive information (regression)

In a return of a previously-fixed issue, Apache Tomcat’s RewriteValve system once again (CVE-2025-55752, CVSSv3=7.5)got the decoding and normalization order wrong for rewritten URLs, allowing attackers manipulate encoded path components in a way that grants them access to file paths on the server that would normally be restricted (Path Traversal), including WEB-INF and META-INF directories. In the (fairly rare) configuration where PUT actions are permitted, this vulnerability could also allow attackers to replace content on the server, potentially even leading to RCE (Remote Command Execution) of whatever an attacker wants. This issue impacts versions 9.0.0.M11 through 9.0.108, 10.1.0-M1 through 10.1.44, and 11.0.0-M1 through 11.0.10.

Fortunately, not all configurations are affected. Exploitation requires there be rewrite rules in place that rewrites a query parameter into a file system path.

You can determine whether you’re affected by running Tomcat’s version.sh or equivalent on the server, which should report the version. While on the server, you can check to see if RewriteValve is in place and whether there are any rewrite configurations by examining configuration files. On a Linux or similar system, a command like the following will help (replace the directories with the equivalents in your deployment if they are different):

# find RewriteValve usage and rewrite configs under a typical Tomcat base
grep -R --line-number "RewriteValve" /opt/tomcat/conf /opt/tomcat/webapps 2>/dev/null || true
grep -R --line-number "rewrite.config" /opt/tomcat/conf /opt/tomcat/webapps 2>/dev/null || true

Prioritize servers taht have potentially risky configurations for remediation, and upgrade Tomcat to the patched releases:

• Tomcat 9.x: upgrade to 9.0.109 or later.
• Tomcat 10.1.x: upgrade to 10.1.45 or later.
• Tomcat 11.x: upgrade to 11.0.11 or later.

Risk can be reduced where upgrades cannot be completed quickly, by ensuring there are restrictive file permissions outside of indended rewrite targets: if the Tomcat process can’t read something, then an attack trying to access it should fail. This is not a sufficient control to be considered a workaround, but rather a partial mitigation to reduce impact until an upgrade can be executed.