CVE-2017-1000093 in Jenkins
Summary
by MITRE
Poll SCM Plugin was not requiring requests to its API be sent via POST, thereby opening itself to Cross-Site Request Forgery attacks. This allowed attackers to initiate polling of projects with a known name. While Jenkins in general does not consider polling to be a protection-worthy action as it's similar to cache invalidation, the plugin specifically adds a permission to be able to use this functionality, and this issue undermines that permission.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/22/2019
The Poll SCM Plugin vulnerability identified as CVE-2017-1000093 represents a critical cross-site request forgery weakness that fundamentally compromises the security controls of Jenkins continuous integration systems. This vulnerability specifically affects the plugin's API endpoint implementation which fails to enforce proper HTTP method validation, allowing malicious actors to exploit the system through unauthorized requests. The flaw exists in the plugin's handling of API calls where it accepts requests regardless of whether they are sent via POST or GET methods, creating an exploitable vector that bypasses intended security measures.
The technical implementation of this vulnerability stems from the plugin's failure to validate the HTTP request method used when interacting with its polling functionality. According to CWE-352 Cross-Site Request Forgery, this weakness allows attackers to perform actions on behalf of authenticated users without their knowledge or consent. The vulnerability specifically targets the plugin's permission model where administrators can grant specific users the ability to trigger project polling through the API. When the plugin accepts GET requests for what should be POST-only operations, it enables attackers to craft malicious requests that can trigger polling actions against projects that are accessible to the victim user.
The operational impact of this vulnerability extends beyond simple polling functionality as it undermines the fundamental permission architecture that Jenkins relies upon for security control. While the Jenkins platform generally treats polling as a benign operation similar to cache invalidation, the specific implementation of this plugin introduces a security boundary that can be exploited when combined with the CSRF weakness. Attackers can leverage this vulnerability to perform unauthorized polling of projects that they might not otherwise have access to, potentially enabling them to gather information about project configurations or trigger unintended system behaviors. The risk is particularly elevated when users with polling permissions are authenticated in their browsers, as the CSRF attack can be executed automatically without user interaction.
The exploitation of this vulnerability aligns with ATT&CK technique T1566.002 for credential access through web application attacks, where attackers can manipulate API endpoints to perform unauthorized operations. The issue demonstrates how seemingly innocuous functionality can create security holes when proper input validation and method enforcement are not implemented. Organizations running Jenkins with this plugin version face potential exposure to attackers who can use the vulnerability to perform unauthorized polling operations, potentially leading to information disclosure or service disruption. The vulnerability specifically impacts systems where the plugin has been configured with granular permissions, as it directly undermines the access control mechanisms that should prevent unauthorized polling actions. The recommended mitigation involves updating to a patched version of the plugin that enforces proper HTTP method validation and ensures that API endpoints only accept POST requests for sensitive operations.