CVE-2026-16566: 
Ansible vulnerability analysis and mitigation

CVE-2026-16566 is an information exposure vulnerability in the jenkins_credential module of the community.general Ansible collection. When credential_type is set to token, the module generates a Jenkins API token via the Jenkins API and returns it in plaintext within the Ansible task result dictionary, without any output suppression. This exposes the token through Ansible task output, AWX/Tower/AAP Controller job logs, CI/CD pipeline logs, callback plugins, and fact caching backends. The CVE was published on July 22, 2026, and is estimated to be of Medium severity (Red Hat CVE, Red Hat Bugzilla).

The root cause is improper output neutralization / insertion of sensitive information into log files (CWE-532). In plugins/modules/jenkins_credential.py, line 793 stores the Jenkins API token directly into the result dictionary (result["token"] = response_data["data"]["tokenValue"]), and line 794 returns the full result via module.exit_json(**result). While the module correctly applies no_log=True to the jenkins_password argument (line 527) to suppress the input credential, no equivalent suppression is applied to the generated token in the return value. This asymmetry means the token is emitted in plaintext to any consumer of Ansible task output (Red Hat Bugzilla).

An attacker with read access to any of the affected output channels — including terminal logs, AWX/Tower/AAP Controller job log databases, CI/CD pipeline build logs, syslog/Splunk callback outputs, or Ansible fact caching backends — can retrieve the plaintext Jenkins API token. The exposed token grants the attacker the same Jenkins privileges as the user who created it, potentially enabling unauthorized access to Jenkins jobs, build pipelines, source code, secrets, and connected infrastructure. This could facilitate lateral movement within CI/CD environments (Red Hat Bugzilla, Red Hat CVE).

The CVE status is currently "Reserved" and no public proof-of-concept exploit code has been identified. Exploitation does not require network-level access to the target system — it only requires read access to one of the many output channels where Ansible task results are stored or displayed. There is no evidence of in-the-wild exploitation, no CISA KEV listing, and no EPSS score is currently available. A Nessus detection plugin (ID 330129) has been published (Tenable, Red Hat CVE).

1. Identify target environment: Determine that the target organization uses Ansible with the community.general collection and runs playbooks that invoke the jenkins_credential module with credential_type: token.
2. Gain access to an output channel: Obtain read access to one of the following: Ansible terminal/log output, AWX/Tower/AAP Controller job logs (via the web UI or database), CI/CD pipeline build logs (e.g., Jenkins, GitLab CI, GitHub Actions), Ansible callback plugin outputs (syslog, Splunk, log_plays), or registered variable fact caches.
3. Locate the token in output: Search logs or job output for the token key in Ansible task results associated with the jenkins_credential module. The token value (tokenValue) will appear in plaintext.
4. Use the token: Authenticate to the Jenkins API using the extracted token (e.g., curl -u username:<token> https://jenkins.example.com/api/json) to gain the same privileges as the token owner, enabling access to jobs, credentials, pipelines, and connected systems (Red Hat Bugzilla).

• Logs: Ansible task output or AWX/Tower/AAP Controller job logs containing a token field with a Jenkins API token value (typically a long alphanumeric string) in the result of a community.general.jenkins_credential task with credential_type: token.
• Logs: Unexpected or unauthorized Jenkins API authentication events in Jenkins access logs using API tokens, particularly from IP addresses not associated with normal automation infrastructure.
• File System: Ansible fact cache files (e.g., JSON files in the configured fact cache directory) containing a token key with a Jenkins API token value registered from a jenkins_credential task result.
• Network: Unusual Jenkins REST API calls (e.g., to /me/api/json, /job/<name>/build) authenticated with API tokens from unexpected source IPs or at unusual times.

The recommended fix is to remove tokenValue from the module's result dictionary and return only tokenUuid, preventing the sensitive token from appearing in any output channel. As of the disclosure date, an upstream fix is pending for the community.general Ansible collection. Until a patched version is released, operators should: (1) avoid using credential_type: token in the jenkins_credential module in environments where log output is broadly accessible; (2) restrict access to AWX/Tower/AAP Controller job logs, CI/CD pipeline logs, and Ansible fact caches to authorized personnel only; (3) rotate any Jenkins API tokens that may have been generated using the affected module and review access logs for unauthorized use (Red Hat Bugzilla, Red Hat CVE).