CVE-2025-64145: Jenkins ByteGuard Build Actions Plugin does not mask API tokens displayed on the job configuration form

The vulnerability lies in the io.jenkins.plugins.BytegaurdActionBuilder class, which handles the configuration for the build step. The core of the issue is the handling of the token field, which is used for authentication with the ByteGuard API.

1. Unencrypted Storage: The token is declared as a private final String. When a user configures a job using this build step, Jenkins uses the @DataBoundConstructor to instantiate the BytegaurdActionBuilder. The provided token is stored in the token field. Because the field is a standard String and not a hudson.util.Secret, Jenkins serializes it directly into the job's config.xml file in plain text. Anyone with access to the Jenkins controller's file system or with Item/ExtendedRead permission can view this sensitive credential.

2. Unmasked Credential in UI: The getToken() getter method returns the token as a plain String. This getter is used by the associated config.jelly view file to render the configuration form. A standard <f:textbox> field bound to this getter will display the token in cleartext. This allows any user who can access the job's configuration page to see the API token, increasing the risk of accidental exposure or malicious capture.

The fix for this type of vulnerability typically involves changing the token field type from String to hudson.util.Secret and updating the constructor and getter accordingly. The corresponding Jelly file would also be updated to use an <f:password/> field, which automatically handles masking in the UI and encryption on the backend. As no fix is available, the identified functions represent the current vulnerable implementation.