CVE-2026-11820: Ansible Nexmo Module Info Disclosure Bug

CVE-2026-11820 Overview

CVE-2026-11820 affects the plugins/modules/nexmo.py module in the Ansible community.general collection. The module sends SMS messages through the Vonage/Nexmo API but transmits api_key and api_secret as URL query parameters in a GET request. Although both parameters are declared with no_log=True at the input level, that protection is bypassed once the credentials are URL-encoded into the request URL. The credentials then appear in verbose Ansible output, Nexmo server access logs, HTTP proxies, SIEM collectors, and Automation Controller debug logs. The issue is classified under CWE-532: Insertion of Sensitive Information into Log File.

Critical Impact
Authenticated Ansible operators and any system handling HTTP request metadata can recover Nexmo API credentials in cleartext, enabling SMS account takeover and message-spoofing abuse.

Affected Products

Ansible community.general collection — plugins/modules/nexmo.py
Red Hat Ansible Automation Platform deployments using the affected module
AWX / Automation Controller environments executing the nexmo module

Discovery Timeline

2026-06-23 - CVE-2026-11820 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-11820

Vulnerability Analysis

The nexmo module constructs an SMS request by placing the API key and secret directly into the query string of a GET request to https://rest.nexmo.com/sms/json. Ansible's no_log=True attribute redacts parameters from task output but does not control how the module subsequently transmits or logs those parameters at the HTTP layer. Once urlencode() serializes the credentials into the URL, every downstream component that records request URLs captures the secrets verbatim.

Exposure surfaces include verbose playbook output produced by -vvv, the Nexmo HTTP access logs, transparent and explicit HTTP proxies, network inspection appliances, SIEM pipelines ingesting proxy logs, and AWX network debug traces. An attacker with read access to any of those sources can recover working credentials for the Vonage SMS account.

Root Cause

The root cause is improper transport selection for sensitive parameters. The module trusts the no_log flag to protect credentials end-to-end, but no_log only governs Ansible's own task display. Embedding secrets in a GET URL violates the principle that authentication material must travel in request bodies or authorization headers, not in URI components that are routinely logged by intermediaries.

Attack Vector

Exploitation requires read access to any log or telemetry source that records outbound HTTP request URLs from the Ansible control node. This includes operator-accessible job output, SIEM indexes, proxy access logs, or the upstream Nexmo account logs. The attacker does not need to compromise the Ansible control node itself — recovery of the credentials from log data is sufficient to authenticate to the Nexmo API as the victim.

The leaked URL pattern observed in vulnerable deployments takes the form https://rest.nexmo.com/sms/json?api_key=<KEY>&api_secret=<SECRET>&from=...&to=...&text=..., with both credentials fully visible in the query string.

Detection Methods for CVE-2026-11820

Indicators of Compromise

Presence of rest.nexmo.com/sms/json?api_key= strings in Ansible job output, AWX logs, or Automation Controller activity streams.
Proxy or web gateway log entries containing api_secret= query parameters bound to outbound traffic from automation hosts.
SIEM events ingested from network sensors that include full URL fields referencing the Nexmo SMS endpoint.

Detection Strategies

Search archived playbook logs, AWX job artifacts, and SIEM data for the regex pattern api_key=[^&]+&api_secret=[^&]+ against Nexmo hostnames.
Audit any Ansible inventory or playbook invoking the community.general.nexmo module and confirm whether verbose logging (-vvv) was used in past runs.
Review Vonage/Nexmo account access logs for unfamiliar source IPs or message patterns that may indicate credential reuse by a third party.

Monitoring Recommendations

Add data loss prevention rules that flag URL query parameters named api_secret, api_key, token, or password traversing egress proxies.
Continuously rotate Nexmo API credentials and monitor for usage from IP ranges that do not match the automation control plane.
Forward Ansible job output and AWX system logs into a centralized log store with restricted analyst access to limit credential exposure radius.

How to Mitigate CVE-2026-11820

Immediate Actions Required

Rotate all Nexmo api_key and api_secret values that were ever passed to the affected module, especially in environments that ran playbooks with verbose logging.
Purge or restrict access to historical Ansible job output, AWX logs, and proxy logs that may contain the leaked credentials.
Restrict the Nexmo account's allowed source IP addresses where the provider supports IP allowlisting.

Patch Information

The upstream fix replaces the GET request with a POST request that carries credentials in the request body using application/x-www-form-urlencoded content. The corrected call passes data=urlencode({...}) and method="POST" to fetch_url, removing credentials from the URL entirely. Track remediation status through the Red Hat CVE-2026-11820 advisory and Red Hat Bug Report #2488970.

Workarounds

Until a patched community.general release is deployed, avoid using the nexmo module in automation flows and substitute a maintained Vonage SDK-based custom module that sends credentials via POST.
Disable verbose logging (-vvv) on any playbook run that invokes the module, and ensure callback plugins do not persist task URLs.
Configure egress proxies to strip or mask query parameters matching credential names before logs are written.

bash

# Pin community.general to a fixed version once available, and audit existing usage
ansible-galaxy collection list community.general
grep -RIn "community.general.nexmo\|nexmo:" /etc/ansible /var/lib/awx/projects 2>/dev/null
# Rotate the Nexmo credentials referenced by any matching playbook