The vulnerability lies in the insecure handling of the Dead Man's Snitch API token within the plugin. The core issue is that the token is treated as a standard 'String' throughout the 'DeadMansSnitchNotifier' class, rather than a secure credential.
The investigation of the plugin's source code revealed the following:
-
Data Binding: The DeadMansSnitchNotifier constructor is annotated with @DataBoundConstructor, indicating that Jenkins uses it to instantiate the class with values from the configuration form. The constructor public DeadMansSnitchNotifier(String token, String message) accepts the token as a plain String.
-
Configuration Form (UI): The corresponding UI is defined in src/main/resources/org/jenkinsci/plugins/deadmanssnitch/DeadMansSnitchNotifier/config.jelly. The form input for the token is defined as <f:textbox />. This Jelly tag renders a standard HTML text input field, which does not mask the characters entered by the user. The fix for this type of vulnerability is typically to use <f:password />, which would render a password field and integrate with Jenkins' credential encryption.
-
Insecure Storage: Because the token field is a String, Jenkins serializes it as plain text in the job's config.xml file on the controller's file system. This allows anyone with file system access or Item/ExtendedRead permissions to view the token.
The combination of the plain String field in the Java class and the <f:textbox /> in the Jelly view results in the token being neither masked in the UI nor encrypted at rest, leading to the reported vulnerability.