On the surface, CVE-2026-109444 looks like a simple logic flaw: a function that should ask "is this action allowed?" always answers "yes." In practice, it is one of the most dangerous vulnerability classes we are seeing in 2026 — a complete collapse of the human-in-the-loop safety control in an autonomous AI agent with shell access to production hosts.
NVD has published CVE-2026-109444 with a CVSS score of 9.8 (CRITICAL), network-exploitable, affecting OpenSRE through version 0.1.2026.10.19. OpenSRE is an AI-powered site reliability engineering agent that triages alerts, investigates incidents, and — critically — can execute shell commands on the host it runs on. The vulnerability lives in the headless presenter's execution_allowed() function, which unconditionally returns True. That means the approval gate designed to require human confirmation before running shell_run commands is dead code in headless deployments.
The attack surface is what makes this severe: OpenSRE ingests untrusted content — alert payloads, Slack messages, incident descriptions — as part of its normal operation. An attacker who can influence any of those inputs can inject instructions that the agent will execute with no confirmation, on the host, with whatever credentials the agent holds. Per the vulnerability description, that includes LLM API keys, Slack tokens, and cloud credentials — the exact material needed for lateral movement and full environment compromise.
If your organization runs OpenSRE (or any LLM agent with tool-use capability) in headless or unattended mode, treat this as an emergency change.
Technical Analysis
Affected Products and Versions
| Attribute | Detail |
|---|---|
| CVE | CVE-2026-109444 |
| CVSS | 9.8 (CRITICAL) — vector pathway: NETWORK |
| Affected product | OpenSRE |
| Affected versions | Through 0.1.2026.10.19 (all versions at or prior to this release) |
| Component | Headless presenter — execution_allowed() approval check |
| Attack prerequisite | Ability to influence content triaged by the agent (alerts, Slack messages, incident text) |
How the Vulnerability Works
OpenSRE's safety model assumes a human operator confirms any shell_run tool invocation before execution. The presenter layer is responsible for rendering that confirmation prompt and gating execution. In headless mode — the mode used when OpenSRE runs as an unattended service consuming alerts from a monitoring pipeline or Slack workspace — the headless presenter's execution_allowed() was implemented as a stub that always returns True.
The resulting attack chain, from a defender's perspective:
- Injection vector. The attacker plants malicious instructions anywhere the agent will read them: an alert description in the monitoring platform, a message in a Slack channel the agent monitors, a webhook payload, a ticket body. No authentication to the OpenSRE host is required — the attacker only needs write access to a data source the agent consumes. This is a textbook indirect prompt injection (MITRE ATT&CK-adjacent technique; OWASP LLM01).
- Approval bypass. The agent parses the injected content, decides a
shell_runaction is warranted (because the injected instructions tell it to), and calls the tool. The confirmation gate — the only thing standing between untrusted text and arbitrary shell execution — silently approves it becauseexecution_allowed()is hardcodedTrue. - Execution and exfiltration. The command runs with the OpenSRE service account's privileges. Documented objectives include reading environment variables and config files holding LLM API keys, Slack bot tokens, and cloud provider credentials (AWS/GCP/Azure metadata endpoints or mounted credential files), then exfiltrating them over the network.
Why This Is a 9.8 and Not a 7.x
Three factors push this to critical: network reachability of the injection vector (Slack and alert pipelines are, by design, externally influenced), no user interaction required (the entire point of the bug is that no human confirms anything), and scope change — compromising the agent hands the attacker credentials that unlock systems well beyond the OpenSRE host itself. This is the agentic-AI equivalent of an unauthenticated RCE.
Exploitation Status
At the time of writing, CVE-2026-109444 has been published by NVD with full technical detail on the vulnerable code path. Given that the flaw is a trivially verifiable logic stub (execution_allowed() returning True), exploitation requires no exploit development skill — only prompt-crafting. Defenders should assume rapid weaponization and treat any OpenSRE deployment exposed to attacker-influenceable input channels as already targeted. Monitor the CISA KEV catalog and the project's GitHub security advisories for confirmation of in-the-wild activity.
Detection & Response
The detection strategy rests on one principle: OpenSRE should never be the parent of a shell executing attacker-influenced commands without a logged human approval. Hunt the agent's process tree, its credential-file reads, and its outbound connections.
SIGMA Rules
---
title: OpenSRE Agent Spawning Shell or Command Interpreter
description: Detects the OpenSRE process spawning shell interpreters or command execution utilities, consistent with CVE-2026-109444 approval gate bypass leading to unauthorized shell_run execution.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-109444
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
status: experimental
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentCommandLine|contains:
- 'opensre'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/python'
- '/python3'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
condition: selection_parent and selection_child
falsepositives:
- Documented OpenSRE remediation playbooks that legitimately invoke shells; baseline approved tool invocations and alert on deviations
level: high
---
title: Credential or Secret File Access Following Agent Shell Execution
description: Detects shell commands spawned under OpenSRE that reference cloud credential files, environment dumps, or Slack/LLM token locations, indicating exfiltration after CVE-2026-109444 exploitation.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-109444
- https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
status: experimental
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentCommandLine|contains:
- 'opensre'
selection_creds:
CommandLine|contains:
- '.aws/credentials'
- '.config/gcloud'
- 'metadata.google.internal'
- '169.254.169.254'
- '/proc/self/environ'
- '/proc/1/environ'
- 'printenv'
- ' SLACK_'
- 'OPENAI_API_KEY'
- 'ANTHROPIC_API_KEY'
- 'AWS_SECRET'
- '.env'
condition: selection_parent and selection_creds
falsepositives:
- Agent health checks reading its own configuration; restrict to the exact config path the agent legitimately reads and alert on everything else
level: critical
---
title: OpenSRE Process Initiating Outbound Connection to Non-LLM Destination
description: Detects network connections from shells spawned by OpenSRE to external hosts, a strong exfiltration indicator when the destination is not an approved LLM API or Slack endpoint.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-109444
- https://attack.mitre.org/techniques/T1041/
author: Security Arsenal
status: experimental
logsource:
category: network_connection
product: linux
detection:
selection_parent:
ParentImage|contains: 'opensre'
selection_net:
Image|endswith:
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/python3'
filter_approved:
DestinationHostname|contains:
- 'api.openai.com'
- 'api.anthropic.com'
- 'slack.com'
- 'amazonaws.com'
condition: selection_parent and selection_net and not filter_approved
falsepositives:
- New SaaS integrations added to the agent; maintain the approved-destination allowlist as a living document
level: high
KQL — Microsoft Sentinel / Defender
This query hunts for OpenSRE-spawned command execution and credential-access patterns via Syslog ingestion. Tune ApprovedDestinations to your environment's LLM/Slack endpoints.
// Hunt: OpenSRE shell_run abuse — CVE-2026-109444
// Looks for (1) shells spawned by opensre, (2) credential/token access, (3) suspect outbound connections
let credArtifacts = dynamic([".aws/credentials", ".config/gcloud", "169.254.169.254",
"metadata.google.internal", "/proc/self/environ", "/proc/1/environ",
"printenv", "OPENAI_API_KEY", "ANTHROPIC_API_KEY", "AWS_SECRET", "SLACK_BOT_TOKEN", ".env"]);
let shellBinaries = dynamic(["/bin/sh", "/bin/bash", "/usr/bin/curl", "/usr/bin/wget", "/usr/bin/nc", "python3"]);
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName has "opensre" or ProcessName in~ ("sh", "bash", "curl", "wget", "nc", "python3")
| extend Raw = tostring(SyslogMessage)
| extend ShellSpawn = Raw has_any (shellBinaries)
| extend CredAccess = Raw has_any (credArtifacts)
| where ShellSpawn or CredAccess
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
SampleCommands = make_set(strcat("[", ProcessName, "] ", substring(Raw, 0, 300)), 20)
by Computer, SeverityLevel = iif(CredAccess, "CRITICAL", "HIGH")
| order by LastSeen desc
;
// Companion query: network exfil from agent hosts via CEF/syslog firewall feeds
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceAction !in~ ("deny", "drop")
| where SourceHostName has "opensre" or SourceUserName has "opensre"
| where DestinationHostName !has_any ("api.openai.com", "api.anthropic.com", "slack.com")
| summarize BytesOut = sum(tolong(SentBytes)), Connections = count()
by SourceIP, DestinationIP, DestinationHostName, DestinationPort
| where BytesOut > 100000 or Connections > 50
| order by BytesOut desc
Velociraptor VQL
Deploy this artifact to any host running OpenSRE. It enumerates the agent process tree for shell children and flags any child process whose command line touches credential artifacts or network utilities.
-- Artifact: Custom.Hunt.OpenSRE.ApprovalBypass
-- Purpose: Detect shell_run abuse on hosts running OpenSRE (CVE-2026-109444)
-- Looks for opensre processes with shell/utility children touching credentials or network tools
LET agent_procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'opensre' OR Name =~ 'opensre'
LET suspicious_children = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(sh|bash|dash|zsh|curl|wget|nc|ncat|python3?)$'
AND (
CommandLine =~ '(?i)(\.aws/credentials|\.config/gcloud|169\.254\.169\.254|metadata\.google|/proc/(self|1)/environ|printenv|API_KEY|SLACK.*TOKEN|AWS_SECRET|\.env)'
)
-- Also capture current outbound connections from the host for triage context
LET net_conns = SELECT Pid, Name, LocalIP, LocalPort, RemoteIP, RemotePort, State
FROM netstat()
WHERE State =~ 'ESTABLISHED' AND NOT RemoteIP =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)'
SELECT * FROM agent_procs
UNION ALL
SELECT * FROM suspicious_children
Remediation / Verification Script
Run this on every host where OpenSRE is deployed to identify the installed version, confirm whether the vulnerable code path exists, and apply compensating controls until patched.
#!/usr/bin/env bash
# CVE-2026-109444 — OpenSRE approval gate bypass: verify and harden
# Run as root or with sudo on each host running OpenSRE.
set -euo pipefail
AFFECTED_CEILING="0.1.2026.10.19"
echo "=== CVE-2026-109444 OpenSRE Verification ==="
# 1. Locate the installed version
if command -v opensre >/dev/null 2>&1; then
INSTALLED=$(opensre --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]{4}\.[0-9]{2}\.[0-9]{2}' | head -1 || true)
echo "[+] Installed OpenSRE version: ${INSTALLED:-unknown}"
else
echo "[-] opensre binary not in PATH; checking pip installs..."
INSTALLED=$(pip3 show opensre 2>/dev/null | awk '/^Version/{print $2}' || true)
echo "[+] pip-reported version: ${INSTALLED:-not found}"
fi
# 2. Check for the vulnerable code path directly
VULN_FILES=$(grep -rl "def execution_allowed" \
/usr/lib/python3*/site-packages/opensre* \
/usr/local/lib/python3*/site-packages/opensre* \
~/.local/lib/python3*/site-packages/opensre* 2>/dev/null || true)
for f in $VULN_FILES; do
if grep -A2 "def execution_allowed" "$f" | grep -q "return True"; then
echo "[!] VULNERABLE CODE PATH CONFIRMED in: $f"
echo " execution_allowed() unconditionally returns True — approval gate is bypassed."
fi
done
# 3. Compensating control: run the agent with a dedicated low-privilege user
if id opensre-svc >/dev/null 2>&1; then
echo "[+] Service account opensre-svc already exists"
else
useradd --system --no-create-home --shell /usr/sbin/nologin opensre-svc
echo "[+] Created low-privilege service account: opensre-svc"
fi
# 4. Remove cloud/LLM/Slack credentials from the agent's environment scope
SVC_USER="opensre-svc"
echo "[*] Auditing credential exposure for ${SVC_USER}..."
sudo -u "$SVC_USER" bash -c '
for p in ~/.aws/credentials ~/.config/gcloud ~/.env; do
[ -e "$p" ] && echo "[!] EXPOSED: $p readable by agent account — relocate or remove"
done
env | grep -iE "(API_KEY|TOKEN|SECRET|AWS_)" | sed "s/=.*/=<REDACTED>/" \
&& echo "[!] Secrets present in agent environment — move to a secrets manager"
' || true
# 5. Network egress restriction: allow only approved LLM/Slack endpoints
# Adjust the allowlist to your providers. Requires iptables and a dedicated egress group.
echo "[*] Apply egress filtering so ${SVC_USER} can only reach approved endpoints."
echo " Example (DNS-allowlist via your egress proxy/firewall is preferred over IP rules):"
echo " - api.openai.com / api.anthropic.com"
echo " - *.slack.com"
echo " - your cloud provider control plane endpoints only"
# 6. Upgrade instruction
echo ""
echo "=== ACTION REQUIRED ==="
echo "If version <= ${AFFECTED_CEILING} or vulnerable code path confirmed:"
echo " 1. Upgrade OpenSRE to the fixed release immediately: pip3 install --upgrade opensre"
echo " 2. If no fix is available, DISABLE headless/autonomous mode and require"
" interactive presenter approval for all shell_run invocations."
echo " 3. Rotate ALL credentials the agent could access: LLM API keys, Slack tokens,"
" cloud IAM keys/roles. Assume compromise until proven otherwise."
Remediation
1. Patch immediately. Upgrade OpenSRE to the first release after 0.1.2026.10.19 that corrects the headless presenter. Verify the fix at the code level: after upgrading, confirm execution_allowed() in the headless presenter no longer returns an unconditional True and that unattended shell_run invocations are denied by default. Track the advisory via NVD CVE-2026-109444 and the OpenSRE project's GitHub security advisories.
2. If no patch is available in your environment yet, disable autonomous execution. Take the agent out of headless triage mode, or wrap shell_run behind an external approval mechanism (e.g., a signed approval webhook or a policy engine like OPA) that the agent's own process cannot influence. Do not rely on prompt-level instructions ("ask before running commands") — that is exactly the control this vulnerability proves insufficient.
3. Rotate credentials — assume exposure. Any LLM API key, Slack bot token, or cloud credential readable by the OpenSRE process or its service account must be considered compromised if the agent has processed untrusted input since deployment. Rotate them all, then audit cloud IAM logs (CloudTrail, GCP Audit Logs, Azure Activity Log) and Slack audit logs for use of the old tokens.
4. Enforce least privilege on the agent. Run OpenSRE as a dedicated unprivileged service account with no sudo, no mounted cloud credentials, and no access to instance metadata endpoints (block 169.254.169.254 and metadata.google.internal for the agent's UID). Move required secrets to a secrets manager with short-lived, narrowly-scoped tokens.
5. Segment and filter egress. The agent only needs outbound access to its LLM provider API, Slack, and the alert sources it triages. Enforce an allowlist egress policy for the agent's service account and alert on any connection outside it — this single control neutralizes most exfiltration paths even if the agent is fully compromised.
6. Sanitize the intake channels. Treat every alert payload, Slack message, and ticket the agent consumes as untrusted input. Restrict who can post to agent-monitored Slack channels, validate alert sources at the webhook layer, and consider a content filter that strips instruction-like patterns from alert text before the agent sees it.
7. Adopt this as an architecture pattern, not a one-off fix. CVE-2026-109444 is a leading indicator for the entire agentic-AI category. Any LLM agent with tool-use capability needs: an approval gate that cannot be bypassed by the agent itself, least-privilege execution context, egress allowlisting, and prompt-injection-aware input handling. Audit every agent in your environment — not just OpenSRE — against those four controls this quarter.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.