We just released Jenkins 1.638 and 1.625.2 which contain important security fixes, including a fix for the zero-day vulnerability published on Friday. Please see the security advisory for more information.
Want to be kept up to date on Jenkins security releases, including advance notice on scheduled security updates? Subscribe to the jenkinsci-advisories mailing list!
Updated 2015-11-11 15:00 UTC: We have released Jenkins 1.638 and 1.625.2 which contain a fix for this vulnerability. See the security advisory for more information about these releases.
Updated 2015-11-06 03:55 UTC: Included a updated mitigation script which doesn't have a Jenkins boot race condition
Earlier today we received numerous reports about a previously undisclosed "zero day" critical remote code execution vulnerability and exploit in Jenkins core. Unfortunately the vulnerability was not disclosed to us ahead of its publication so we're still working on more thorough fix. In the meantime however, we wanted to inform you of the issue and provide a workaround which will help prevent this exploit from being used against public Jenkins installations, for future reference this issue is being tracked privately as
SECURITY-218 in our issue tracker.
It is great to see the pick up of local activities through hosted JAMs. In October, the Jenkins community hosted Atlanta JAM and Bay Area JAM. Many thanks to our sponsors: Ericsson, CloudBees, Blazemeter, NetRoadShow.
Here's a summary of what was discussed:
- Atlanta JAM - Jenkins workflow and Docker to reduce friction in DevOps efforts.
- Bay Area JAM- Performance testing strategies, incorporating performance tests into Jenkins workflows and the metrics that matter most for troubleshooting and diagnosing issues.
Preceding some of last week's Jenkins 2.0 discussions, there had been some threads on whether we should move Jenkins to require Java 8. The introduction of Java 8 last year brought performance improvements and highly desirable API changes, which make developing Java-based applications (arguably) much easier than before. The release was followed earlier this year by the end-of-life announcement for Java 7; the writing is on the wall: upgrade to Java 8.
I wanted to answer the question "does it even make sense to force an upgrade to Java 8?" There are plenty of technical discussions that we can have in the community on whether or not this is the right approach, but my goal was to try and measure the current Jenkins install base for Java 8 preparedness.