CVE-2026-71465

Executive Summary

CVE-2026-71465 is an argument injection flaw (CWE-88) in the ansible-core ad-hoc CLI execution path. RunAdHocCommand.build_args() appends the user-supplied limit value as a bare positional argument (args.append(limit)) instead of the two-element form used elsewhere (args.extend(['-l', limit]) as in RunJob). Because the value is passed without an option separator, a limit string beginning with - is interpreted by the ansible CLI argument parser as an option flag rather than as a host-limit pattern. The impact is bounded — the CVSS vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) and base score of 3.1 reflect low integrity impact only, high attack complexity, and a required low-privileged authenticated position. No public PoC, Nuclei template, or exploit code exists, and there is no evidence of exploitation in the wild.

Technical Analysis

The vulnerability class is OS command/argument injection (CWE-88) occurring entirely inside the ansible-core process argument parser — not a shell-level injection, since the injected string is reinterpreted as an ansible CLI option. The defect is architectural in nature: two code paths that build an ansible invocation treat the same logical parameter differently.

In RunAdHocCommand.build_args(), the limit value is appended directly:

args.append(limit)

This yields a bare positional operand on the resulting argument vector. Any string starting with - is therefore consumed by the option parser as a flag. By contrast, RunJob builds the equivalent argument safely:

args.extend(['-l', limit])

which binds the value to the -l limit option and terminates option parsing for that value.

Because the injected element occupies the position where the required pattern positional argument is expected, the injected token displaces the mandatory pattern. The practical consequence at time of writing is narrow: only flags that short-circuit execution before pattern validation are reachable — explicitly cited as --version and --help. These cause the process to emit its version or help text and exit, producing information disclosure (version fingerprinting) but no command execution and no state change to managed hosts.

The NVD description states explicitly that this "would escalate if ansible-core ever defaults pattern." In other words, the constraint that currently limits the bug to short-circuit flags is a side effect of the required pattern positional being non-defaulted. Should a future ansible-core release make pattern optional/defaulted, the displaced-positional barrier disappears and a much wider set of ansible CLI options — potentially including ones that alter connection handling, playbook sourcing, or plugin loading — becomes reachable via the same limit input path. This makes CVE-2026-71465 a latent escalation primitive rather than a fully-realized one.

Attack surface: any interface that lets a low-privileged user influence the limit parameter of an ad-hoc ansible invocation. That includes ansible-tower/AWX-style job wrappers, CI/CD pipeline steps invoking ad-hoc commands with externally supplied limits, custom automation built on ansible-core's API, and CLI wrappers. The vulnerability is remotely triggerable (AV:N) only where such a wrapper is network-exposed; in pure local CLI usage the prerequisite is local access to the ansible binary with a controllable limit argument.

Preconditions for the current, bounded form of the bug:

1. Attacker can supply a limit value beginning with -.
2. The invocation reaches RunAdHocCommand.build_args().
3. The injected flag is one honored before the required pattern positional is validated (--version, --help).

All three conditions must hold, hence AC:H. The attacker needs some pre-existing low-privileged position (PR:L) and no user interaction (UI:N). Confidentiality and availability impacts are None; only integrity is Low, consistent with argument-vector manipulation of a process invocation rather than data/host compromise.

Exploitation Scenarios

No public PoC exists; the attack chain below is inferred strictly from the vulnerability class (CWE-88) and the behavior documented in the NVD description. No function names, endpoints, or parameters beyond those in the description are asserted.

1. Reconnaissance / target identification. The attacker identifies an environment where ansible-core ad-hoc commands are executed with a limit value that the attacker can influence. Candidate surfaces: a job-runner web UI or API where the operator selects a host limit, a CI/CD pipeline parameter, or a wrapper script whose limit argument is derived from external input. Because no version range is confirmed, the attacker cannot rely on banner/fingerprint gating; instead the target is characterized by its use of the vulnerable ad-hoc code path. Direct CLI use, where the attacker already has shell access, is the lowest-friction variant.

2. Triggering the specific flaw class. The attacker supplies a limit string whose first character is -. Instead of being treated as a host pattern, the string is appended as a bare positional argument and parsed by the ansible option parser as an option. This is the essence of the argument-injection defect: the value crosses from the data channel into the control channel of the argument vector.

3. Payload / execution method (vulnerability-class level). In the currently demonstrated, non-escalated form, the injected token is a short-circuit flag — --version or --help. The result is that the ansible CLI emits version or usage information and exits. This is an information-disclosure primitive: it leaks the exact ansible-core version, enabling the attacker to correlate with known CVEs and to determine whether the environment later ships a release where pattern defaults (removing the current positional-displacement guard). No command execution is achieved today because the injected element displaces the required pattern positional, which must be present for normal playbook/command execution.

4. Post-exploitation impact. Assessed integrity impact is Low, confidentiality and availability None. The realized effect is manipulation of the ansible invocation's option parsing and disclosure of version/usage output. The strategic value is intelligence: version fingerprinting to plan follow-on attacks. If ansible-core later defaults pattern, the same input path may permit injecting additional ansible options, at which point the attacker's objective would shift from fingerprinting to influencing execution behavior of ad-hoc runs (for example, redirecting what is executed against which inventory) — a materially higher impact than what is achievable today. That escalation is speculative and contingent on a future upstream change, not on the current code.

Because no exploit code, Nuclei template, or public PoC is available, defenders should treat this as a hardening and latent-risk issue rather than an actively exploited one.

Impact Assessment

CVSS 3.1 base score 3.1 (Low). Subscores:

• AV:N (Network). Exploitable remotely where an ad-hoc-invoking wrapper is network-reachable and accepts an attacker-influenced limit.
• AC:H (High). Successful exploitation of the current form requires specific, narrow conditions: a --prefixed limit, the ad-hoc code path, and a short-circuit flag honored before the required pattern positional validates.
• PR:L (Low). The attacker needs a low-privileged position capable of influencing the limit parameter.
• UI:N (None). No user interaction required once conditions are met.
• Scope: Unchanged. The vulnerable component and impacted component are the same ansible-core process invocation.
• Confidentiality: None. Integrity: Low. Availability: None.

Business impact (current state): Limited. The practical effect is disclosure of ansible-core version/usage output during ad-hoc runs. Version disclosure assists an attacker in later, targeted exploitation of other vulnerabilities affecting that ansible-core version. No host compromise, no credential exposure, no data modification on managed nodes, and no denial of service are demonstrated.

Blast radius / affected systems: Any system, CI/CD pipeline, or automation wrapper invoking ansible-core ad-hoc commands (ansible) with a caller-influenceable limit. Concentration is highest in centralized automation platforms (job runners, AWX/Tower-style controllers, orchestration APIs) where a single exposed interface fronts large numbers of managed hosts. Even where the current payload is benign, a successful parse manipulation can alter which hosts an operator intended to target in adjacent invocation paths.

Latent escalation risk: The NVD description explicitly flags that the bug "would escalate if ansible-core ever defaults pattern." This is the dominant strategic consideration. A future change removing the required-positional guard converts a Low, integrity-only information-disclosure issue into a potentially broader option-injection primitive. Defenders should assume the risk score understates future exposure and remediate the code path proactively.

Exploitation status: CISA KEV: NO. EPSS: Not yet scored by FIRST.org. Public PoC/exploit: None. Nuclei template: NO.

Detection Guidance

Because this is an argument-parsing defect with no network protocol signature in the description, detection focuses on anomalous ansible process arguments, anomalous version/usage output during ad-hoc runs, and unusual limit values in command lines.

Sigma Rule

title: Ansible Ad-Hoc Limit Argument Injection (CVE-2026-71465)
id: 5f9c2e7a-7146-4a2f-9c3b-8e1d0f4b6a21
status: experimental
description: Detects ansible ad-hoc invocations where a limit value is passed as a bare positional beginning with a dash, or where short-circuit flags appear in the limit position, consistent with CVE-2026-71465.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-71465
author: valtersit.com
date: 2026/01/01
logsource:
  category: process_creation
  product: linux
detection:
  selection_binary:
    Image|endswith:
      - '/ansible'
      - '/ansible-playbook'
  selection_injected_flag:
    CommandLine|contains:
      - '--version'
      - '--help'
  selection_limit_position:
    CommandLine|re: '\s-l\s+--(version|help)|\s--(version|help)\s'
  condition: selection_binary and (selection_injected_flag or selection_limit_position)
fields:
  - CommandLine
  - User
  - ParentCommandLine
falsepositives:
  - Legitimate interactive use of `ansible --version` or `ansible --help` by administrators
  - Wrapper scripts that place --version/--help after other operands
level: low
tags:
  - attack.t1190
  - cve.2026.71465

YARA Rule

rule CVE_2026_71465_Ansible_Limit_ArgInjection
{
    meta:
        description = "Detects ansible-core RunAdHocCommand limit handling that appends limit as a bare positional (args.append(limit)) instead of args.extend(['-l', limit])"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-71465"
        cve = "CVE-2026-71465"
        date = "2026-01-01"

    strings:
        $cls_adhoc = "RunAdHocCommand" ascii
        $method    = "build_args" ascii
        $bad_append = "args.append(limit)" ascii
        $good_extend = "args.extend(['-l', limit])" ascii
        $good_extend_dq = "args.extend([\"-l\", limit])" ascii

    condition:
        $cls_adhoc and $method and $bad_append and not ($good_extend or $good_extend_dq)
}

Suricata IDS Rule

Network traffic for this CVE is not a distinct protocol exchange; the vulnerable input is a CLI argument. The rule below targets the observable side channel of short-circuit behavior (version/usage output) returned by an ad-hoc job wrapper after an injected flag, as well as command-injection-style parameters in job-runner HTTP traffic.

alert http any any -> any any (msg:"CVE-2026-71465 Ansible ad-hoc limit argument injection attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"limit"; nocase; pcre:"/limit=[^&]*-{1,2}(version|help)/i"; classtype:attempted-recon; sid:202671465; rev:1; reference:cve,2026-71465; metadata:service http;)

Elastic Detection

process where process.name in ("ansible", "ansible-playbook") and
  process.args != null and
  (
    (process.args : "--version" or process.args : "--help") and
    process.args : "-l"
  )

This EQL sequence variant captures the case where a limit option is followed by, or a bare positional resolves to, a short-circuit flag:

sequence by process.entity_id
  [process where process.name == "ansible" and process.args : "-l"]
  [process where process.name == "ansible" and (process.args : "--version" or process.args : "--help")]

Splunk SPL Query

index=main source=*Process* (Image="*ansible" OR Image="*ansible-playbook" OR process_name="ansible")
| eval cmd=coalesce(CommandLine, process, command_line)
| where match(cmd, "(?i)(-l\s+--(version|help)|--(version|help)\s)")
| stats count values(cmd) as command_lines by host user parent_process_name
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="ansible,cve-2026-71465,">
  <rule id="202671" level="3">
    <if_sid>80700</if_sid>
    <field name="audit.command">ansible</field>
    <description>CVE-2026-71465: ansible ad-hoc executed - possible limit argument injection (bare positional flag)</description>
    <regex>ansible.*(--version|--help).*</regex>
  </rule>

  <rule id="202672" level="8">
    <if_sid>202671</if_sid>
    <description>CVE-2026-71465: ansible limit parameter carried an option-like flag - suspected argument injection</description>
    <regex>-l\s+--(version|help)</regex>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED. A patch is reported by a single source via NVD and has NOT been independently confirmed. No vendor advisory, no fixed version string, and no commit reference are published in the supplied data. Treat the vulnerability as unpatched from a verified standpoint until an authoritative ansible-core advisory or changelog entry is available.

1) Immediate mitigations (apply now, independent of patch availability):

• Never pass an untrusted or caller-supplied value directly into the limit parameter of an ad-hoc ansible invocation. Validate/normalize the value at the wrapper layer: reject any limit string beginning with - and allow-list acceptable host patterns.
• Insert a -- argument terminator before position-dependent operands where the CLI supports it, so downstream tokens cannot be reinterpreted as options. This is the general guard the vulnerable code path omits.
• Constrain who can influence the limit field on job runners, AWX/Tower-style controllers, and CI/CD parameters. Limit the parameter to trusted roles (PR:L is the CVSS assumption; reducing who holds that position reduces exposure).
• Where the ad-hoc capability is not required, disable or restrict the ansible binary to privileged operators and require full playbooks instead of ad-hoc commands.
• Monitor for --version/--help appearing in ad-hoc invocation arguments (see Detection Guidance) and alert on anomalies.

2) Patch / upgrade steps:

• Monitor the ansible-core project's official release notes and security advisories for the fix reference for CVE-2026-71465. The correct upstream fix is expected to change RunAdHocCommand.build_args() to bind the limit as an option value — i.e., args.extend(['-l', limit]) — mirroring the existing safe pattern in RunJob, rather than appending it as a bare positional.
• Once an ansible-core version containing the fix is published, schedule upgrade of ansible-core across controllers, job runners, and CI images. Uppercase the upgrade to all execution environments, since the vulnerable code ships with the package.
• After upgrading, verify by confirming that a --prefixed limit no longer produces --version/--help short-circuit behavior on a controlled ad-hoc invocation.
• Because patch confidence is only 2/4, confirm the patch independently (checksum/signature, changelog entry) before declaring remediation complete.

3) Long-term hardening:

• Treat any ansible-core upgrade that changes pattern handling as security-relevant. The NVD description warns the bug escalates if pattern ever defaults; track upstream changes to required/optional positional handling and re-assess CVE-2026-71465 severity after each such release.
• Adopt argument-construction standards across automation code: always pass option values as separate ['-l', value] elements (or with an explicit -- terminator), never as bare positional append operations. Add unit tests that assert an option-like input is never interpreted as a flag.
• Enforce typed input validation at all automation boundaries (API schemas, CI parameter definitions) with deny-by-default for --prefixed values in positional fields.
• Maintain inventory and version tracking of ansible-core across all execution environments to enable rapid response to this and future advisories.
• Include argument-injection test cases (CWE-88) in security regression suites for internal wrappers around ansible and comparable CLIs.

References

• NVD — CVE-2026-71465: https://nvd.nist.gov/vuln/detail/CVE-2026-71465
• ansible-core (ansible/ansible) official repository and release notes — monitor for the fix reference binding limit via args.extend(['-l', limit]): https://github.com/ansible/ansible
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• CWE-88 — Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'): https://cwe.mitre.org/data/definitions/88.html
• FIRST EPSS — no score yet published for CVE-2026-71465 (confirm at time of reading): https://api.first.org/data/v1/epss?cve=CVE-2026-71465

Threat actor / in-the-wild status: No evidence of exploitation in the wild. CISA KEV: not listed. No public PoC, exploit code, or Nuclei template available. No known threat actor campaigns are associated with this CVE at the time of writing.