PraisonAI EUVD-2026-108897

Exploitation requires three concrete conditions, all drawn from the advisory: (1) the host must have the optional 'sandlock' Python module importable while the kernel reports Landlock unavailable (e.g., an unsupported/missing Landlock ABI) - this is the exact branch that logs 'Sandlock not available, falling back to subprocess' and fails open; (2) the application must execute untrusted code via SandlockSandbox using SandboxConfig.native() (the code-execution path, not the read_file/write_file/list_files helpers, which still apply safe_sandbox_path checks); and (3) the attacker must be able to supply code to that sandbox. Limiting factors: where Landlock is present and enforced, or where sandlock is not installed at all, this specific fail-open does not occur; the attacker needs the ability to run code in the sandbox (PR:L), but no user interaction is required. The documented native policy (allowed filesystem paths, network=False) is silently not enforced during code execution.

The authoritative CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 8.8) correctly models this as a local sandbox escape with scope change: untrusted code that was supposed to be confined breaks the security authority (the Landlock-backed sandbox) and reaches host/other-tenant resources. Two signals are absent from the input: no EPSS probability is provided (so exploitation likelihood cannot be quantified) and there is no CISA KEV entry, so this is not confirmed as actively exploited. However, a detailed, demonstrated proof-of-concept is published inside the GHSA advisory with observed 'vulnerable: true' results on v4.6.58, so this is not a theoretical issue. The vuln.today decision label is 'this_week' (elevated, but not act_now/emergency). The key nuance that tempers raw severity: exploitation is gated by a specific environmental state - the optional 'sandlock' Python module must import successfully yet report Landlock unavailable (e.g., a kernel without the required Landlock ABI, which is common in many container/managed-runtime environments) - AND the application must actually rely on SandlockSandbox / SandboxConfig.native() to run untrusted code. Where those conditions hold this is a complete confinement bypass and a genuine priority for multi-tenant code-execution deployments; where Landlock is present and enforced, this specific fail-open path does not trigger. No conflict exists between the CVSS vector and the description - both describe local execution of attacker-supplied code crossing the sandbox boundary.

A multi-agent or multi-tenant platform built on PraisonAI runs untrusted or LLM-generated code through SandboxConfig.native(writable_paths=[...], network=False), trusting the documented kernel-enforced filesystem allowlist and network denial. On a host where the sandlock module is installed but Landlock is unavailable, SandlockSandbox silently falls back to plain SubprocessSandbox, so a crafted payload reads files outside the allowed path (e.g., other tenants' data, /etc/passwd, SSH keys, cloud credentials) and opens outbound network connections despite network=False. A working proof-of-concept demonstrating both boundary crossings is published in the GHSA advisory.