CVE WatchOct 16, 2026

CVE-2026-108161

FusionPBX through 5.6.5 contains an OS command injection vulnerability in call_recordings::download() that allows unauthenticated attackers

CVSS

7.5

High

EPSS

1.1%

p65

KEV

—

Exploit Today

0-100

Published: Oct 10, 2026 · Last modified: Oct 16, 2026 · CWE-78

EPSS · 30d

1.1%EPSS · 30 days1.1%

2026-10-112026-10-23

Technical description

FusionPBX through 5.6.5 contains an OS command injection vulnerability in call_recordings::download() that allows unauthenticated attackers to execute commands by placing calls with malicious caller ID values. When the record_name filename template is enabled, attackers can embed shell metacharacters like $(...) in the Caller-ID name or number, executing commands as the web server user once a privileged user downloads multiple recordings as a ZIP.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-399027.2 HIG

—

———Cacti is an open source performance and fault management framework. Prior to version 1.2.31, the prior blocklist ([;&| `$\\n\r]) omitted single-quote, double-quote, redirect operators, subshell parens and braces. An authenticated admin could save an input_string` containing single-quote, redirect operator, or subshell parens, and pass the check. This issue has been patched in version 1.2.31.8h CVE-2026-114355—

—

———OS command injection in the root-privileged 'hardware_monitor' helper in DJI CrystalSky ZS600C firmware v0.3.9.7 through v0.6.6.9 on Android allows a local unprivileged process to execute arbitrary commands as root by writing a crafted line to the Android log (logcat), which the helper reads and passes to a shell eval.7h CVE-2026-114354—

—

———Missing authorization in the native binder service 'android.dji.server' (transaction code 1018) in DJI CrystalSky ZS600C firmware v0.3.9.7 through v0.6.6.9 on Android allows a local application with no permissions to execute arbitrary OS commands as root, because the handler passes a caller-supplied string to system() in the root-privileged 'assistant' daemon without any caller-identity or permission check.7h CVE-2026-571427.8 HIG

—

———PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. This issue has been patched in version 4.6.61.10h CVE-2026-571178.8 HIG

—

———PraisonAI is a multi-agent teams system. From version 4.6.10 to before version 4.6.59, LocalManagedAgent / SandboxedAgent compute bridging wraps read_file, list_files, and write_file when a compute provider is attached. The bridge converts those file operations into shell command strings using raw path arguments, then sends those strings to shell-backed compute providers. An attacker who can influence a file-tool path argument can break out of the quoted path and execute arbitrary shell commands in the compute environment. With compute="local", commands execute through the local subprocess compute provider on the host. With Docker, commands execute in the container. This issue has been patched in version 4.6.59.10h CVE-2026-568387.8 HIG

—

———PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.59, PraisonAI recipe execution blocks default-denied dangerous tools unless the caller explicitly passes allow_dangerous_tools=True. The normal recipe.run() path enforces this with _check_tool_policy(). The streaming path, recipe.run_stream(), loads the same recipe, checks dependencies, and then calls _execute_recipe() without running the dangerous-tool policy check. As a result, a recipe that honestly declares execute_command in TEMPLATE.yaml requires.tools is denied by recipe.run(), but reaches the execution engine through recipe.run_stream() with allow_dangerous_tools=False. This issue has been patched in version 4.6.59.11h