While last week’s AppSec was dominated by the first-of-its-kind Shai-Hulud attack on NPM, that certainly wasn’t the only event of note. Here are some news items our team found interesting over the past week, which you might have missed.
- Jenkins Core, the open-source core that underpins both the community and commercial editions of the popular Jenkins CI system, was impacted by an underlying vulnerability in the Eclipse Jetty library (CVE-2025-5115, CVSSv4 7.7) which can be exploited to create a DoS (Denial of Service). The issue is confined to HTTP/2 support for Jetty’s embedded web server, which Jenkins bundles in versions prior to Jenkins 2.524 and LTS 2.516.3. Deployments using external appservers like Tomcat are not effected. Disable HTTP/2 and/or discontinue use of the embedded Jetty server, especially if unable to upgrade.
- The Kubernetes C# client was discovered not properly validating CA certificates (CVE-2025-9708, CVSSv3 6.8), leading to a risk of a “man in the middle” (MitM) attack if an adversary is able to supply a forged certificate. While difficult to exploit, the impact could be extremely high for some organizations. Kubernetes’ advisory indicates that this issue is present in “all versions of the Kubernetes C# client prior to the next release <=17.0.13”; read below for more information on mitigations.
Zero Research Updates. Subscribe today!
Jenkins Core bundling of Jetty with DoS vulnerability
Jenkins Core, the open-source core that underpins both the community and commercial editions of the popular Jenkins CI system, was impacted by an underlying vulnerability in the Eclipse Jetty library (CVE-2025-5115, CVSSv4 7.7) which can be exploited to create a DoS (Denial of Service). The issue is confined to HTTP/2 support for Jetty’s embedded web server, which Jenkins bundles in versions prior to Jenkins 2.524 and LTS 2.516.3. Deployments using external appservers like Tomcat are not effected. Disable HTTP/2 and/or discontinue use of the embedded Jetty server, especially if unable to upgrade.
The issue occurs in the way that the Jetty server handles malformed HTTP/2 requests; the server takes certain invalid requests and spends resources processing them to determine they’re invalid, responding with RST_STREAM frames while not incrementing the count of concurrent streams. Since those streams are not counted toward the cap, this allows an attacker to open a large number of streams. Since the server works much harder for each open stream than the client does, this enables an attacker to mount a Denial of Service (DoS) with minimal resources.
The Jenkins updates that address this issue also address other medium-severity issues, so upgrading is strongly recommended. Note that the non-LTS recommended is at least 2.528, newer than the version that only contains the Jetty fixes.
Fortunately, HTTP/2 isn’t the default configuration (you need to start Jenkins with --http2Port or the equivalent configuration file directive). And larger organizations typically don’t use the embedded Jetty server — despite this being the default mode in most installation guides for Jenkins — opting for using something like Tomcat instead. That means your first action is to verify whether you’re running a vulnerable configuration, and then plan your response accordingly.
Kubernetes C# client vulnerable to forged certificates
The Kubernetes C# client was discovered not properly validating CA certificates (CVE-2025-9708, CVSSv3 6.8), leading to a risk of a “man in the middle” (MitM) attack if an adversary is able to supply a forged certificate. While difficult to exploit, the impact could be extremely high for some organizations. Kubernetes’ advisory indicates that this issue is present in “all versions of the Kubernetes C# client prior to the next release <=17.0.13”.
Installations that keep the CA certificates for clients in the system trust store (rather than in the configuration file) are significantly harder to exploit, since it would require the attacker to alter the system certificate trust – an operation that generally requires local administrative rights. If you are unable to update promptly, enforcing this configuration can significantly increase the difficulty for an attacker.