What Is New in Jenkins 2.462.x
This LTS release primarily focuses on security hardening and removing deprecated, potentially vulnerable functionality. It's a maintenance release that prepares the codebase for future major upgrades.
| Category | Key Changes |
|---|---|
| Security | Removed Windows path traversal escape hatch, upgraded Commons FileUpload library |
| UI Changes | Removed "Disable project" link from project view |
| Infrastructure | Removed Winstone multi-WAR support, added authenticated resource URL escape hatch |
| Plugin Compatibility | Requires updates for SAML SSO and HP Application Automation Tools plugins |
What security improvements were made in Jenkins 2.462.x?
The most significant security change is the removal of the Windows path traversal vulnerability escape hatch. The system property hudson.model.DirectoryBrowserSupport.allowAbsolutePath has been completely removed without replacement.
This means any workflows that previously relied on this security bypass will need to be redesigned. The change forces proper security practices by eliminating the workaround for directory browsing vulnerabilities on Windows systems.
How does the Commons FileUpload upgrade affect plugin compatibility?
Jenkins upgraded Apache Commons FileUpload from version 1.5 to 2.0, which is a prerequisite for the upcoming Spring Security 6.x migration. This change breaks compatibility with certain plugins that haven't been updated for the new API.
Specifically, users of the SAML Single Sign On (miniorange-saml-sp) plugin must upgrade to a compatible version simultaneously with Jenkins core. Users of the OpenText Application Automation Tools (hp-application-automation-tools-plugin) should wait for a compatible plugin version before upgrading Jenkins.
Why was the "Disable project" link removed from the project view?
The "Disable project" link has been removed from the main project/job page to streamline the UI and reduce accidental disabling of projects. The functionality still exists but is now only accessible through the project's Configure page.
For teams that frequently need to disable projects, the disable job button plugin can restore this functionality to the main project view. This change reflects a broader effort to clean up the Jenkins interface and move secondary actions to more appropriate locations.
What infrastructure changes should administrators be aware of?
Jenkins 2.462.x removes support for running Winstone with multiple WAR files via the webappsDir argument. This feature has been eliminated without a direct replacement, so administrators using this deployment method need to alternative approaches.
Additionally, 2.462.3 reintroduces an escape hatch for authenticated users accessing Resource URLs through the system property jenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true. This can also be set dynamically via Groovy script: jenkins.security.ResourceDomainRootAction.ALLOW_AUTHENTICATED_USER = true.
FAQ
Can I still bypass Windows path traversal restrictions in 2.462.x?
No. The hudson.model.DirectoryBrowserSupport.allowAbsolutePath system property has been completely removed. You'll need to address the root cause of why you needed this bypass instead.
My SAML authentication broke after upgrade - what should I do?
Update your SAML Single Sign On plugin to a version compatible with Commons FileUpload 2.0. The plugin must be updated in lockstep with the Jenkins core upgrade.
Where did the "Disable project" button go?
It was moved to the Configure page for each project. If you need quick access to this function, install the disable job button plugin to restore it to the main project view.
How can I allow authenticated users to access Resource URLs?
Set the system property jenkins.security.ResourceDomainRootAction.allowAuthenticatedUser=true on startup or execute the Groovy script jenkins.security.ResourceDomainRootAction.ALLOW_AUTHENTICATED_USER = true.
Can I still run multiple WAR files with Winstone?
No. The webappsDir argument support has been removed without replacement. You'll need to use alternative deployment methods such as traditional web application servers.