Last checked and updated on 03 May 2026What Is New in Jenkins 2.375.x
This release focuses on security hardening, infrastructure modernization, and user interface refinements. The most significant change is the introduction of a request part count limit to mitigate a potential denial-of-service vector.
| Category | Key Changes |
|---|---|
| Security | Added a limit for multipart/form-data request parts to prevent DoS attacks. |
| Infrastructure | Major Winstone and Jetty updates, removing deprecated TLS flags and obsolete options. |
| UI/UX | Modernized various UI elements, forms, and pages for a more consistent experience. |
| Deprecations | Removed several long-deprecated Winstone command-line flags. |
What security improvements were made in this release?
The primary security enhancement is a new limit on the number of parts processed in multipart/form-data requests. This directly addresses a potential denial-of-service vulnerability where an attacker could submit a request with an excessive number of parts, consuming server resources.
By default, the system now rejects requests with more than 1000 parts. This limit applies to all form fields, not just file uploads. In practice, this means complex Jenkins forms with many configuration options might hit this limit and require adjustment.
How did the embedded server infrastructure change?
Jenkins 2.375.x includes significant updates to its embedded web container, upgrading Winstone from 6.1 to 6.6 and Jetty from 9.4.46.v20220331 to 10.0.12. These updates bring performance improvements, security patches, and modern protocol support.
The more impactful change is the removal of deprecated TLS configuration flags. The --httpsPrivateKey and --httpsCertificate options are now completely gone. You must migrate to the standard --httpsKeyStore option using PKCS12 keystores, which is the Java standard since JEP 229.
What deprecated features were removed?
Several obsolete Winstone command-line flags were removed in this release cycle. The --toolsJar and --useJasper flags are gone since they served no purpose with Java 11+. The --ajp13Port and --ajp13ListenAddress options were removed as they've been obsolete since Jetty 9.
Additionally, the handler count flags --handlerCountMax and --handlerCountMaxIdle were removed after being deprecated for four years without actually functioning. This cleanup reduces complexity and maintenance burden for the embedded container.
How do I handle the new multipart request limits?
If your Jenkins instance uses complex forms that legitimately need more than 1000 parts, you can adjust the limits using Java system properties. Set hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILES and org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILES to a higher value.
For extreme cases where you need to disable the limit entirely (not recommended for security reasons), you can set these properties to -1. Most installations won't need to adjust these values as the default limit accommodates typical Jenkins forms.
What should I do about the removed TLS flags?
If you were using the deprecated --httpsPrivateKey and --httpsCertificate flags, you need to convert your TLS configuration to use a PKCS12 keystore. The process involves creating a keystore file containing both your private key and certificate chain.
You can use the Java keytool utility or OpenSSL to create the keystore. Once created, use the --httpsKeyStore flag pointing to your keystore file, along with the --httpsKeyStorePassword flag if your keystore is password-protected.
FAQ
Why would I encounter the new multipart request limit?
You might hit this limit if you have extremely complex job configurations with hundreds of parameters, or forms with many repeatable sections that generate numerous fields. The limit counts all form fields, not just file uploads.
Are the Jetty and Winstone updates backward compatible?
Mostly yes, but the removed flags mean existing startup scripts using those flags will break. The HTTP/HTTPS functionality itself remains compatible, but the configuration method changed for TLS.
What happens if I don't migrate from the deprecated TLS flags?
Jenkins will fail to start with an error about unrecognized command-line options. You must update your startup configuration to use the keystore approach before upgrading.
Can I still use AJP connectors with Jenkins?
No, the AJP support was completely removed with the deprecated flags. You'll need to use HTTP/HTTPS directly or place Jenkins behind a reverse proxy that handles AJP to HTTP conversion.
Is Java 17 required for this release?
While not explicitly required for 2.375.x, the removal of certain flags was necessary due to changes in Java 17 APIs. This release continues to support Java 11, but prepares for future Java 17 requirements.