The vulnerability lies in the insecure handling of the QMetry Automation API Key within the QMetry Test Management Plugin. The analysis of the 'QTMReportPublisher.java' file reveals that the plugin fails to use Jenkins' standard mechanism for managing credentials, which is the 'hudson.util.Secret' class. Instead, the API key is treated as a regular 'String'.
The root cause is in the 'QTMReportPublisher' class. Its constructor, marked with '@DataBoundConstructor', directly accepts the API key as a 'String' from the job configuration. This key is then stored in a 'String' field. The corresponding getter, 'getQtmAutomationApiKey', exposes this key as a plaintext 'String'.
This design has two security implications:
- Plaintext Storage: When a Jenkins job is saved, its configuration is serialized to an XML file ('config.xml'). Because the 'qtmAutomationApiKey' field is a 'String', its value is written directly into this file without any encryption. Any user with 'Item/ExtendedRead' permission or filesystem access to the Jenkins controller can view this key.
- UI Exposure: The job configuration UI does not mask the API key field. This is a direct consequence of the getter returning a 'String'. If it returned a 'Secret', Jenkins would render a password input field. This increases the risk of shoulder-surfing or other methods of capturing the key visually.
Therefore, the identified vulnerable functions are the constructor that accepts and stores the plaintext secret and the getter that exposes it for persistence and UI rendering.