OpenSRE: instructions planted in alerts or Slack messages make the AI SRE agent run shell commands on its host, because the approval check in headless mode always allows execution; CVE published 20 October 2026

Changes to what this case says, with the reason. Every earlier version is kept.

• 2026-10-22: Fields: outcome. Follows the editor's call h1 of 21 october 2026 (outcome 'pending' where no fix has shipped): the field's state label had not been updated with the outcome; the rest of the field is unchanged.
  Show the change

  Before: State: averted by disclosure. No exploitation in the wild is reported in the sources; Lasso Security lists no known exploit. The reporters demonstrated the flaw in their own test setup: with a stubbed model, and with local models run through Ollama reading a forwarded Grafana alert carrying planted instructions, shell_run commands ran with no approval prompt (qwen3:8b emitted the injected command in 2 of 3 runs; llama3.1:8b did not use the tool channel). Lasso Security reports that the injected command was persisted to the agent's cross-session memory, with automatic re-execution seen once and not reproduced, so unconfirmed. The CISA (Cybersecurity and Infrastructure Security Agency) enrichment of the CVE record marks exploitation as 'poc', a proof of concept. As of 21 October 2026

  After: State: pending (no fix has shipped). No exploitation in the wild is reported in the sources; Lasso Security lists no known exploit. The reporters demonstrated the flaw in their own test setup: with a stubbed model, and with local models run through Ollama reading a forwarded Grafana alert carrying planted instructions, shell_run commands ran with no approval prompt (qwen3:8b emitted the injected command in 2 of 3 runs; llama3.1:8b did not use the tool channel). Lasso Security reports that the injected command was persisted to the agent's cross-session memory, with automatic re-execution seen once and not reproduced, so unconfirmed. The CISA (Cybersecurity and Infrastructure Security Agency) enrichment of the CVE record marks exploitation as 'poc', a proof of concept. As of 21 October 2026
• 2026-10-21: Status text. Editor's call h2 of 21 october 2026 (accepted as amended, pull request #79): status wording follows the corroboration; every fact in it is already in the case.
  Show the change

  Before: Provisional (no fix shipped as of 21 October 2026; proof of concept run by the reporters; no exploitation in the wild reported)

  After: Confirmed (corroborated by the project's own code, which also disputes one point; no fix shipped as of 21 October 2026; proof of concept run by the reporters; no exploitation in the wild reported)
• 2026-10-21: Status. Editor's call h2 of 21 october 2026 (accepted as amended, pull request #79): the glossary defines 'provisional' as awaiting independent corroboration; with the maintainer's own records corroborating the mechanism, the case is confirmed.
  Show the change

  Before: provisional

  After: confirmed
• 2026-10-21: Provenance tier. Editor's call h2 of 21 october 2026 (accepted as amended, pull request #79): the maintainer's own records (advisory, documentation or code) confirm the mechanism.
  Show the change

  Before: disclosure_uncorroborated

  After: disclosure_corroborated
• 2026-10-21: Outcome: state. Editor's call h1 of 21 october 2026 (accepted as amended, pull request #79): no fix has shipped in a published release, so the outcome is not yet known; 'averted by disclosure' claimed an outcome that has not happened.
  Show the change

  Before: averted_by_disclosure

  After: pending
• 2026-10-21: Inference: value. Found in the editor's second, independent check of the interpretations, 21 october 2026: the reporters' proof of concept used a planted grafana alert only, not a slack message (lasso security, cve-2026-109444, proof-of-concept step 3).
  Show the change

  Before: The record shows an approval step that does not stop a command when no person is there to answer: on headless surfaces such as the gateway and scheduled runs, the presenter's execution_allowed() always returns True, allowing the command, so a shell command prompted by text planted in an alert or Slack message can run without anyone deciding it. The reporters demonstrated this in their own test setup, where whether the model acted on the planted text varied by model and run. The record does not show exploitation in the wild, does not confirm that a planted command stored in the agent's memory runs again later, and shows no fix as of 21 October 2026

  After: The record shows an approval step that does not stop a command when no person is there to answer: on headless surfaces such as the gateway and scheduled runs, the presenter's execution_allowed() always returns True, allowing the command, so a shell command prompted by text planted in an alert or Slack message can run without anyone deciding it. The reporters demonstrated this with a planted alert in their own test setup, where whether the model acted on the planted text varied by model and run. The record does not show exploitation in the wild, does not confirm that a planted command stored in the agent's memory runs again later, and shows no fix as of 21 October 2026
• 2026-10-21: Inference: value. Found in the editor's second, independent check of the interpretations, 21 october 2026: 'allowed' is not the function's value: the cve record says it 'always returns true', and the code at tag v0.1.2026.10.21 has 'return true'.
  Show the change

  Before: The record shows an approval step that does not stop a command when no person is there to answer: on headless surfaces such as the gateway and scheduled runs, the presenter's execution_allowed() returns 'allowed' every time, so a shell command prompted by text planted in an alert or Slack message can run without anyone deciding it. The reporters demonstrated this in their own test setup, where whether the model acted on the planted text varied by model and run. The record does not show exploitation in the wild, does not confirm that a planted command stored in the agent's memory runs again later, and shows no fix as of 21 October 2026

  After: The record shows an approval step that does not stop a command when no person is there to answer: on headless surfaces such as the gateway and scheduled runs, the presenter's execution_allowed() always returns True, allowing the command, so a shell command prompted by text planted in an alert or Slack message can run without anyone deciding it. The reporters demonstrated this in their own test setup, where whether the model acted on the planted text varied by model and run. The record does not show exploitation in the wild, does not confirm that a planted command stored in the agent's memory runs again later, and shows no fix as of 21 October 2026
• 2026-10-21: Controls: c-d2. Found in the editor's source check of 21 october 2026: the cve record and opensre's code describe a code path (the headless presenter's execution_allowed() returns true), not the agent choosing to proceed.
  Show the change

  Before: Mechanism: when no human approver is present (the headless presenter), the agent proceeds rather than stopping. Why it interrupts: stopping and handing off when the approval cannot be obtained would have blocked the command even with the injected instruction accepted. Source shows it failed: execution_allowed() always returns True in headless mode. The source does not show a fail-closed configuration being tried, so the counterfactual is not shown

  After: Mechanism: when no human approver is present (the headless presenter), the presenter's code allows the command rather than stopping. Why it interrupts: stopping and handing off when the approval cannot be obtained would have blocked the command even with the injected instruction accepted. Source shows it failed: execution_allowed() always returns True in headless mode. The source does not show a fail-closed configuration being tried, so the counterfactual is not shown
• 2026-10-21: Controls: c-e3. Found in the editor's source check of 21 october 2026: sources disagree on whether shell_run opts into the approval gate: opensre's code at commit 8eba8c9 sets requires_approval=true; lasso security says shell_run never opts in. both accounts now stated.
  Show the change

  Before: Mechanism: shell_run is meant to require confirmation, but in headless mode the presenter's execution_allowed() always returns True, so commands the agent derives from injected alert or Slack text run without confirmation. Why it interrupts: a confirmation step that is enforced on every surface would put a human decision between the injected instruction and the host command. Source shows it failed: the record calls this an approval gate bypass and states commands run without confirmation

  After: Mechanism: shell_run is meant to require confirmation (the project's code at the affected commit marks it requires_approval=True; Lasso Security's write-up says it never opted into the gate), but in headless mode the presenter's execution_allowed() always returns True, so commands the agent derives from injected alert or Slack text run without confirmation. Why it interrupts: a confirmation step that is enforced on every surface would put a human decision between the injected instruction and the host command. Source shows it failed: the record calls this an approval gate bypass and states commands run without confirmation
• 2026-10-21: Inference: value. Found in the editor's source check of 21 october 2026: 'the headless path decided the outcome' named a single cause, while lasso security's advisory also describes model behaviour that varied by run, a shell policy that allows every command and a child process that inherits the full environment; the interpretation also did not say what the record does not show (no exploitation in the wild, memory re-execution unconfirmed, no fix by version 0.1.2026.10.21). it was unsigned, so no signature was cleared.
  Show the change

  Before: An approval gate that returns 'allowed' when no person is there to ask is not a gate; the headless path decided the outcome

  After: The record shows an approval step that does not stop a command when no person is there to answer: on headless surfaces such as the gateway and scheduled runs, the presenter's execution_allowed() returns 'allowed' every time, so a shell command prompted by text planted in an alert or Slack message can run without anyone deciding it. The reporters demonstrated this in their own test setup, where whether the model acted on the planted text varied by model and run. The record does not show exploitation in the wild, does not confirm that a planted command stored in the agent's memory runs again later, and shows no fix as of 21 October 2026
• 2026-10-21: Fields: recovery technical. Found in the editor's source check of 21 october 2026: later development: versions 0.1.2026.10.20 and 0.1.2026.10.21 were tagged without changing the headless presenter (opensre repository, subprocess_presenter.py at tag v0.1.2026.10.21 still returns true).
  Show the change

  Before: {"value": "No fixed version is named in the sources. Lasso Security recommends requiring approval for shell_run and cli_exec, failing closed on headless surfaces when no approver is available, and treating observability content as untrusted data", "source_ids": ["LASSO-109444"]}

  After: {"value": "No fix had shipped as of 21 October 2026: the CVE record lists versions through 0.1.2026.10.19 as affected and names no fixed version, and in OpenSRE's code at version 0.1.2026.10.21, the latest tag on 21 October 2026, the headless presenter's execution_allowed() still returns True. Lasso Security recommends requiring approval for shell_run and cli_exec, failing closed on headless surfaces when no approver is available, and treating observability content as untrusted data", "source_ids": ["LASSO-109444", "NVD-109444", "REPO-PRESENTER-1021"]}
• 2026-10-21: Fields: evidence event. Found in the editor's source check of 21 october 2026: the cve record (cve.org) also references the lasso.security advisory, credits three finders, and gives datepublic 15 october 2026; the vulncheck advisory is dated 19 october 2026; the cisa adp enrichment (20 october 2026 16:04 utc) gives the exploitation, automatable and technical impact values.
  Show the change

  Before: {"value": "CVE-2026-109444 published 20 October 2026 by the VulnCheck CNA; CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H), CVSS 3.1 8.8; CWE-862; references OpenSRE source at commit 8eba8c9 (Slack dispatcher and subprocess_presenter.py) and a VulnCheck advisory", "source_ids": ["NVD-109444"]}

  After: {"value": "CVE-2026-109444 published 20 October 2026 by the VulnCheck CNA (CVE Numbering Authority); CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H), CVSS 3.1 8.8; CWE-862 (Common Weakness Enumeration: missing authorization); references OpenSRE source at commit 8eba8c9 (Slack dispatcher and subprocess_presenter.py), a VulnCheck advisory dated 19 October 2026 and Lasso Security's advisory; credits Noy Pearl, Michael Sromin and Ophir Dror as finders; gives 15 October 2026 as the date the flaw was made public. On 20 October 2026 CISA's enrichment of the record added Exploitation 'poc', Automatable 'yes', Technical Impact 'total'", "source_ids": ["NVD-109444", "VC-109444"]}
• 2026-10-21: Fields: outcome. Found in the editor's source check of 21 october 2026: lasso security's advisory describes a working proof of concept (stubbed model; local models through ollama; commands ran with no approval prompt); the cisa enrichment added to the cve record on 20 october 2026 gives exploitation 'poc'. the case did not say the flaw had been demonstrated.
  Show the change

  Before: {"value": "State: averted by disclosure. No exploitation reported in the sources; Lasso Security lists no known exploit and reports that the injected command was persisted to the agent's memory, with re-execution unconfirmed. As of Oct 2026."}

  After: {"value": "State: averted by disclosure. No exploitation in the wild is reported in the sources; Lasso Security lists no known exploit. The reporters demonstrated the flaw in their own test setup: with a stubbed model, and with local models run through Ollama reading a forwarded Grafana alert carrying planted instructions, shell_run commands ran with no approval prompt (qwen3:8b emitted the injected command in 2 of 3 runs; llama3.1:8b did not use the tool channel). Lasso Security reports that the injected command was persisted to the agent's cross-session memory, with automatic re-execution seen once and not reproduced, so unconfirmed. The CISA (Cybersecurity and Infrastructure Security Agency) enrichment of the CVE record marks exploitation as 'poc', a proof of concept. As of 21 October 2026."}
• 2026-10-21: Fields: envelope constraints. Found in the editor's source check of 21 october 2026: sources disagree. lasso security: 'opensre has a human approval gate, but shell_run never opts into it'. opensre's code at commit 8eba8c9, the commit the cve record cites, sets 'requires_approval=true' on shell_run, added by commit ae5d449 on 6 october 2026. both accounts are now stated and the field is marked disputed.
  Show the change

  Before: {"value": "An approval gate on shell_run, which the headless presenter does not enforce (CWE-862, missing authorization)", "source_ids": ["NVD-109444"], "disputed": false}

  After: {"value": "An approval gate on shell_run, which the headless presenter does not enforce (CWE-862, missing authorization). The accounts differ on whether shell_run opts into the gate: Lasso Security's write-up says shell_run never sets the approval flag (requires_approval), while the project's code at the affected commit 8eba8c9 (version 0.1.2026.10.19) marks shell_run requires_approval=True, a setting added on 6 October 2026 (commit ae5d449). Both accounts agree that on headless surfaces the presenter allows the command without asking", "source_ids": ["NVD-109444", "LASSO-109444", "REPO-SHELL-1019", "REPO-AE5D449"], "disputed": true}
• 2026-10-21: Fields: decision. Found in the editor's source check of 21 october 2026: the cve record says attackers 'can inject instructions' to run commands; lasso security's tests show it depends on the model and run (qwen3:8b emitted the injected command in 2 of 3 runs; llama3.1:8b did not use the tool channel), so 'acts on' overstated it.
  Show the change

  Before: The agent acts on the injected instructions and calls shell_run; in headless mode the presenter's execution_allowed() always returns True, so the approval gate is bypassed

  After: The agent can act on the injected instructions and call shell_run; in headless mode the presenter's execution_allowed() always returns True, so the approval gate is bypassed
• 2026-10-21: Fields: actor. Found in the editor's source check of 21 october 2026: the cve record names the vendor as 'tracer-cloud' and the repository as github.com/tracer-cloud/opensre; the case did not name the maintainer.
  Show the change

  Before: OpenSRE through 0.1.2026.10.19, an AI agent that triages alerts and Slack messages and has a shell_run tool

  After: OpenSRE through 0.1.2026.10.19, an open-source AI agent maintained by Tracer-Cloud (the vendor named in the CVE record) that triages alerts and Slack messages and has a shell_run tool
• 2026-10-21: Outcome: as of. Found in the editor's source check of 21 october 2026: later developments checked to 21 october 2026: cisa enrichment of the cve record (20 october), nvd status deferred, and versions 0.1.2026.10.20 and 0.1.2026.10.21 shipped without a fix (opensre repository).
  Show the change

  Before: Oct 2026

  After: 21 Oct 2026
• 2026-10-21: Outcome: severity. Found in the editor's source check of 21 october 2026: the cve record (cve.org and nvd) gives both scores with vulncheck as their source (nvd lists them as 'secondary'): cvss 4.0 8.7 high and cvss 3.1 8.8 high; lasso security's entry shows 'cvss score 9', 'critical', with no version named. the case gave one score without saying who assigned it.
  Show the change

  Before: none reported (CVSS 4.0 8.7)

  After: none reported (no harm reported; VulnCheck, the CVE Numbering Authority that assigned the identifier, rates the flaw 8.7, High, on CVSS 4.0 (the Common Vulnerability Scoring System, a 0 to 10 severity score) and 8.8, High, on CVSS 3.1; Lasso Security's entry shows a CVSS score of 9, Critical, without naming the version)
• 2026-10-21: Status text. Found in the editor's source check of 21 october 2026: the cna advisory has now been read (vulncheck); opensre's code at tag v0.1.2026.10.21 still has execution_allowed() returning true; lasso security's advisory describes a working proof of concept. the status value is left to the editor.
  Show the change

  Before: Provisional (CNA advisory not read in this run; no fix named in the sources; no exploitation reported)

  After: Provisional (no fix shipped as of 21 October 2026; proof of concept run by the reporters; no exploitation in the wild reported)
• 2026-10-21: Provenance tier text. Found in the editor's source check of 21 october 2026: the nvd record's status is now 'deferred' (nvd api, last modified 20 october 2026 20:11); the vulncheck advisory was opened in this check; the cve record links lasso security's entry as the 'lasso.security advisory' with the proof of concept, so it is not only a restatement. the tier value itself is left to the editor.
  Show the change

  Before: CVE record assigned by VulnCheck (CNA) and recorded in NVD (status Received); the VulnCheck advisory it references could not be opened in this run; a Lasso Security database entry restates the flaw and reports no known exploit

  After: CVE record assigned by VulnCheck (the CVE Numbering Authority) and recorded in NVD, the US National Vulnerability Database (status Deferred on 21 October 2026); VulnCheck's advisory read; the reporters' technical advisory with a proof of concept is published by Lasso Security; the project's code at the cited commit shows the headless presenter returning True
• 2026-10-21: Context: mandate context text. Found in the editor's source check of 21 october 2026: lasso security's advisory describes a proof of concept run at three levels (code checks, a stubbed model, and local models through ollama) in which commands ran with no approval prompt, and lists 'known exploit: no'; the cisa enrichment of the cve record marks exploitation as 'poc'.
  Show the change

  Before: Vulnerability disclosure; no exploitation reported

  After: Vulnerability disclosure with a proof of concept the reporters ran in their own test setup; no exploitation in the wild reported
• 2026-10-21: Sources: nvd-109444: checked; sources: lasso-109444: checked. Found in the editor's source check of 21 october 2026: both sources re-opened in this check (nvd record through the nvd api; lasso security page in full).
  Show the change

  Before: 2026-10-20

  After: 2026-10-21
• 2026-10-21: Sources: lasso-109444: interest. Found in the editor's source check of 21 october 2026: the lasso security page closes by offering its automated ai red-teaming product ('book a demo').
  Show the change

  Before: Security vendor that publishes the database entry

  After: Security vendor that publishes the entry and sells AI security products
• 2026-10-21: Sources: lasso-109444: primary. Found in the editor's source check of 21 october 2026: the cve record (cve.org) links this entry as the 'lasso.security advisory', tagged 'technical-description' and 'exploit'; it is the reporters' own technical record with their proof of concept, a researcher primary record.
  Show the change

  Before: false

  After: true
• 2026-10-21: Sources: lasso-109444: title. Found in the editor's source check of 21 october 2026: the entry's exact headline is 'cve-2026-109444: remote code execution via ungated shell_run tool driven by prompt injection' (lasso security page).
  Show the change

  Before: Lasso Security vulnerability database entry CVE-2026-109444 (OpenSRE): no known exploit; injected command persisted to memory; remediation recommendations

  After: Lasso Security vulnerability database, 'CVE-2026-109444: Remote Code Execution via Ungated shell_run Tool Driven by Prompt Injection'