Description

In Stapler 2107.v8dfcb_e8ed317 and earlier, except 2088.2093.vd7c3e58008a_6, included in Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, Stapler does not restrict the types of objects that can be instantiated via form data binding to those compatible with the expected field type, allowing attackers with Overall/Read permission to instantiate types related to configuration for which that field type was not intended.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-02T16:17:29.437Z",
  "pubdate": "2026-09-02T16:17:29.437Z",
  "executiveSummary": "This vulnerability involves an improper restriction of object instantiation within the Stapler framework used by Jenkins. The flaw allows attackers with Overall/Read permission to influence the data binding process by injecting arbitrary object types into fields where they are not expected.\nBy manipulating form data binding, an attacker can instantiate classes related to Jenkins configuration, potentially leading to unauthorized state changes or escalation of privileges. The vulnerability affects Stapler versions 2107.v8dfcb_e8ed317 and earlier, excluding version 2088.2093.vd7c3e58008a_6. It impacts Jenkins core up to 2.579 and LTS up to 2.568.2.\nThe risk is significant as it bypasses intended type-safety constraints, permitting the instantiation of sensitive objects that can modify system configuration. Successful exploitation requires the attacker to possess Overall/Read access, which is a baseline permission in many Jenkins environments. This vulnerability essentially transforms a read-only capability into a vehicle for unauthorized configuration modification, posing a severe threat to the integrity of the Jenkins environment.",
  "technicalDetails": "The vulnerability resides in the Stapler framework's data binding mechanism, specifically within the logic that processes HTTP request parameters to populate Java object fields. The root cause is a failure to perform adequate type validation during the deserialization of user-provided input into object fields. Stapler, as the web framework powering Jenkins, is responsible for mapping form fields to backend Java objects; however, in the affected versions, the framework fails to enforce that the instantiated objects match the expected type defined by the target field.\nThe attack vector leverages the lack of class-type filtering during the binding process. An attacker with Overall/Read access can craft a malicious HTTP request that submits form data containing parameters intended for specific Jenkins configuration objects. Because the framework does not validate that the injected object type is compatible with the field's declared type, an attacker can supply a different class name that is present in the classpath. When the framework attempts to bind this data, it instantiates the attacker-specified class.\nThe attack flow proceeds as follows: First, the attacker identifies a form endpoint within Jenkins that utilizes Stapler for data binding. Second, the attacker inspects the target field's expected type in the source code or via API introspection. Third, the attacker crafts a POST request that includes parameters configured to exploit the relaxed binding logic. By providing a serialized object representation or specific type markers that Stapler accepts, the attacker forces the application to instantiate an unauthorized class. The application then proceeds to execute logic associated with that object, effectively allowing the attacker to influence the internal state of the Jenkins configuration.\nThe impact of this exploitation is contingent on the availability of gadgets—classes that can be instantiated and subsequently misused to perform actions like unauthorized system modifications or property overrides. Because the attacker can instantiate objects related to configuration, they may potentially reconfigure security settings, plugins, or build triggers that were meant to be restricted to administrative users. This effectively bypasses functional access controls, as the vulnerability resides at the framework level rather than the application logic level. The scope is limited by the set of classes available within the Jenkins classpath, but the ability to trigger these instantiations without formal authorization elevates the risk to the entire Jenkins instance."
}