Fedora 44 python-llm Arbitrary Code Execution (FEDORA-2026-4f3301f569): Patch to llm 0.33 and Hunt for Template/Plugin Abuse

Fedora has issued security advisory FEDORA-2026-4f3301f569 for Fedora 44, classifying an arbitrary code execution issue in the python-llm package — the distribution build of the open-source llm command-line toolkit used to interact with large language models. The fix is delivered by rebasing to the upstream llm 0.33 release.

No CVE identifier or CVSS score has been published with this advisory at the time of writing, and Fedora's notice is terse: "Update to latest upstream release python llm 0.33." That brevity should not lower your urgency. When a distribution security team ships a rebase labeled "arbitrary code execution," the correct posture is to treat it as a real execution-class flaw in a developer-facing tool that is increasingly present on build systems, AI/ML workstations, and automation pipelines.

llm is not a niche toy anymore. It is embedded in scripts, CI jobs, prompt pipelines, and local AI agent tooling. Its core features — templates, fragments, and a plugin architecture that dynamically loads third-party Python code — are exactly the kind of extensibility surface that turns a "CLI convenience tool" into a code-execution primitive.

Technical Analysis

Affected Products and Platforms

Systems running Fedora 44 with python3-llm installed at a version prior to the 0.33 rebase are exposed. Also treat as in-scope: any container images, CI runners, or developer workstations that install llm from PyPI (pip install llm) — those installations follow upstream versioning independently of DNF and may still be pinned below 0.33.

Attack Surface: Why llm Is an ACE-Prone Tool

From a defender's perspective, llm has three execution-relevant features that make any ACE classification credible:

1. Plugin architecture — llm install <plugin> loads arbitrary third-party Python packages into the tool's runtime and registers hooks at startup. A compromised or malicious plugin is code execution by design.
2. Templates and fragments — llm supports stored templates and fragments, including fragment loaders that can pull content from URLs and execute shell-derived fragments (e.g., command-substitution style loaders registered by plugins). Passing an attacker-controlled fragment reference (llm -f 'loader:argument') can transform a prompt-building step into an execution step.
3. Scripting integration — llm is routinely invoked from shell scripts, Makefiles, and CI pipelines with user-influenced arguments (ticket text, PR descriptions, customer input). If argument handling or fragment/template resolution is the vulnerable path, any pipeline that feeds untrusted text into llm becomes an injection surface.

The most likely exploitation chain, consistent with how this class of tool breaks, is: untrusted input → llm invocation with crafted template/fragment/plugin reference → unintended command or Python code execution in the context of the invoking user or service account. Exploitation requires the ability to influence arguments or configuration consumed by llm — which is precisely the case in automation.

Exploitation Status

• Public PoC: None confirmed at publication time.
• Active exploitation: Not reported. No CISA KEV listing.
• Assessment: Treat as a latent, weaponizable flaw. The combination of "arbitrary code execution" classification and llm's presence in automation means dwell time between public detail release and PoC is typically short. Patch before the technical write-up appears, not after.

Detection & Response

Because the precise vulnerable code path is undisclosed, detection should focus on behavioral indicators: the llm process spawning shells or interpreters, and llm invocations referencing remote fragment/template sources — both strong signals of abuse in environments where llm is used interactively rather than as a code executor.

Sigma Rules

---
title: LLM CLI Spawning Shell or Script Interpreter Child Process
id: 3f7a2c14-9b8e-4d61-a2c7-5e1f0b9d4c83
status: experimental
description: Detects the llm CLI (python-llm) spawning shells, interpreters, or network utilities as child processes — consistent with abuse of fragment/plugin code execution in FEDORA-2026-4f3301f569.
references:
  - https://linuxsecurity.com/advisories/fedora/fedora-44-python-llm-2026-4f3301f569
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/05/02
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/llm'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/ruby'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate use of llm fragment loaders that execute shell commands (plugins such as cmd fragments)
  - Developer workflows piping llm output into shells
level: high
---
title: LLM CLI Invoked With Remote Fragment or Template Source
id: 8c1d4e62-5a3f-4b79-9d02-7f6e1a3c5b94
status: experimental
description: Detects llm CLI executions that reference HTTP(S)-based fragments or templates, which can pull attacker-controlled content and trigger code execution paths.
references:
  - https://linuxsecurity.com/advisories/fedora/fedora-44-python-llm-2026-4f3301f569
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/05/02
tags:
  - attack.execution
  - attack.t1059
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_binary:
    Image|endswith:
      - '/llm'
  selection_url:
    CommandLine|contains:
      - 'http://'
      - 'https://'
  selection_flag:
    CommandLine|contains:
      - ' -f '
      - ' --fragment '
      - ' -t '
      - ' --template '
      - 'fragments:'
  condition: selection_binary and selection_url and selection_flag
falsepositives:
  - Documented use of remote fragments in legitimate prompt pipelines
level: medium

Tune the first rule against your known-good automation before broad deployment: any pipeline that intentionally uses command-executing fragment plugins will fire it. That tuning exercise is itself a worthwhile audit — you should know exactly where llm runs code on purpose.

KQL Hunt (Microsoft Sentinel / Defender for Endpoint on Linux)

This query hunts for llm spawning execution-capable children and for invocations carrying remote fragment references. If you ingest Linux auditd/Sysmon-for-Linux telemetry via Syslog or CEF, adapt the field names accordingly — the behavior logic holds.

// Hunt for llm CLI abuse: suspicious child processes and remote fragment/template references
let SuspiciousChildren = dynamic(["bash","sh","dash","zsh","python","python3","perl","ruby","curl","wget","nc","ncat","socat"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "llm" or InitiatingProcessCommandLine has "llm"
| where FileName in~ (SuspiciousChildren)
    or (ProcessCommandLine has_any ("http://","https://") and ProcessCommandLine has_any ("--fragment"," -f ","--template","fragments:"))
| project TimeGenerated, DeviceName, AccountName,
          ParentProcess = InitiatingProcessFileName,
          ParentCmd = InitiatingProcessCommandLine,
          ChildProcess = FileName,
          ChildCmd = ProcessCommandLine,
          SHA256, ReportId
| order by TimeGenerated desc;
// Alternative: Syslog-ingested Linux telemetry
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has "llm"
| where SyslogMessage has_any ("--fragment"," --template","fragments:") or SyslogMessage has_all ("llm","http")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL Hunt

This artifact enumerates running llm processes and audits per-user llm configuration directories (templates, fragments, installed plugins) for recently modified or unexpected artifacts — the persistence vector if an attacker lands code execution through this tool.

-- Hunt for active llm executions with suspicious command lines
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^llm$'
   OR CommandLine =~ '(?i)(--fragment|--template|fragments:).*http'

-- Audit llm configuration directories across user homes for unexpected
-- templates, fragments, or recently installed plugins (persistence surface)
SELECT FullPath, Mtime, Size, Mode
FROM glob(globs='/home/*/.config/io.datasette.llm/**')
WHERE NOT IsDir
ORDER BY Mtime DESC

Investigate any plugin directory entries or templates.yaml modifications that post-date your last authorized change, and any llm process owned by a service account that does not normally run AI tooling.

Remediation & Verification Script

Run this on Fedora 44 hosts (adapt for configuration management at scale). It reports the installed version, applies the specific advisory update, verifies the fix, and audits user-level llm configurations for unexpected plugins or remote template references.

#!/bin/bash
# Remediation and verification for FEDORA-2026-4f3301f569 (python-llm ACE -> llm 0.33)
set -euo pipefail

# 1. Report current state
rpm -q python3-llm 2>/dev/null || echo "python3-llm not installed via RPM"
command -v llm >/dev/null && llm --version || echo "llm binary not found on PATH"

# 2. Apply the specific advisory update
sudo dnf upgrade -y --advisory=FEDORA-2026-4f3301f569

# 3. Verify patched version (must be >= 0.33)
INSTALLED=$(llm --version | grep -oE '[0-9]+\.[0-9]+' | head -1)
MAJOR=${INSTALLED%%.*}; MINOR=${INSTALLED##*.}
if [ "$MAJOR" -eq 0 ] && [ "$MINOR" -lt 33 ]; then
  echo "[FAIL] llm $INSTALLED still vulnerable — check for pip-installed shadow copies:"
  pip show llm 2>/dev/null; pipx list 2>/dev/null | grep -i llm
  exit 1
else
  echo "[OK] llm $INSTALLED is patched"
fi

# 4. Audit pip/pipx/venv installations that bypass DNF
pip list 2>/dev/null | grep -i '^llm' && echo "[WARN] pip-managed llm found — upgrade with: pip install -U 'llm>=0.33'"

# 5. Audit user configs for unexpected plugins and remote template/fragment references
for d in /home/*/.config/io.datasette.llm /root/.config/io.datasette.llm; do
  [ -d "$d" ] || continue
  echo "--- Auditing $d ---"
  ls -la "$d/plugins" 2>/dev/null
  grep -rnE 'https?://' "$d/templates.yaml" 2>/dev/null && echo "[WARN] remote references in templates.yaml"
done

# 6. List installed llm plugins for review
llm plugins list 2>/dev/null

Remediation Steps

1. Patch Fedora 44 systems immediately: sudo dnf upgrade --advisory=FEDORA-2026-4f3301f569 (or dnf upgrade python3-llm). Verify llm --version reports 0.33 or later. Rebuild any container images that layer python3-llm from Fedora 44 base images.
2. Cover non-RPM installs. Any llm installed via pip, pipx, uv, or virtualenvs bypasses DNF entirely. Inventory these (pip list | grep llm, check CI images and developer venvs) and upgrade to llm>=0.33.
3. Audit the extensibility surface. Run llm plugins list on every affected host and remove plugins that are not explicitly required. Review ~/.config/io.datasette.llm/templates.yaml and any fragment configurations for remote (http(s)://) sources you did not authorize — remote fragments are fetched and processed at runtime and are a prime injection vector.
4. Constrain automation input. Any pipeline that passes untrusted text (PR descriptions, issue bodies, support tickets, web content) into an llm invocation must treat those arguments as hostile: avoid passing attacker-influenced strings into fragment (-f) or template (-t) flags, and run llm under a least-privilege service account with no shell-spawning requirement where feasible.
5. Deploy the detections above to catch post-exploitation behavior while you finish patching, and keep them running — the behavior (llm spawning shells, llm pulling remote fragments) is a durable abuse indicator regardless of the specific bug fixed in 0.33.
6. Track the upstream fix. Monitor the upstream llm project release notes for 0.33 and the Fedora advisory for a CVE assignment; if one is published with in-the-wild exploitation, re-prioritize accordingly.

The pattern here is broader than one Fedora package: LLM CLI tooling is landing in production automation faster than security teams are inventorying it. Treat llm and its peers as what they are — interpreters with network access and plugin loaders — and govern them accordingly.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub