Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
50 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
SkillTools.runskillscript() accepts a scriptpath parameter and executes it via subprocess.run() without any path containment validation. While FileTools has validatepath() with traversal detection, SkillTools performs none. An LLM-directed call can execute arbitrary scripts from any filesystem location. The @requireapproval decorator can be bypassed via YAML approve: for high-risk tools. Details src/praisonai-agents/praisonaiagents/tools/skilltools.py (lines 69-119): By contrast, FileTools.validatepath() (src/praisonai-agents/praisonaiagents/tools/filetools.py, lines 42-78) properly validates that the resolved path stays within the working directory: SkillTools has no equivalent check. PoC Tested result: The script at /tmp/maliciousskill.sh executed successfully despite the working directory being set to a jail directory. The output confirms arbitrary script execution including whoami and hostname. No path containment check exists — the absolute path is accepted and executed…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unsafe dynamic module loading vulnerability allows an attacker who can control a workflow file and a sibling tools.py to execute arbitrary Python code when the workflow is executed. Details The vulnerability is located in the workflow structured output resolution logic. File: src/praisonai-agents/praisonaiagents/workflows/workflows.py Method: AgentFlow.resolvepydanticclass This code is reached during step execution when a step uses a string outputpydantic: filepath is set automatically by: - WorkflowManager.loadworkflow() (used by workspace discovery) - WorkflowManager.createworkflow() It can also be set manually after loadyaml(): The execmodule() call has no sandboxing and ignores the PRAISONAIALLOWTOOLS environment variables used elsewhere in the project. PoC Create the following two files in the same directory: /tmp/attack/attack.yaml /tmp/attack/tools.py Run the following Python code (adjust the path to your PraisonAI source): Impact Type: Execution of Untrusted Local…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FastContext path resolution permits absolute and traversal reads outside the workspace Summary PraisonAI's praisonaiagents.context.fast FastContext feature treats workspacepath as the root directory for code search, but its model-facing search tools and high-level readcontext() helper accept absolute paths and .. traversal paths without checking that the resolved path remains under that workspace. A lower-trust prompt or caller that can influence FastContext tool arguments can read, search, and enumerate files outside the intended project workspace; the resulting file content is then returned to the caller or injected into the model's tool-result context. Technical Details FastContextAgent documents workspacepath as the "Root directory for searches" and stores it as an absolute path: The same class exposes grepsearch, globsearch, readfile, and listdirectory as model function-call tools via gettools(). Those tools are intended to retrieve code context from the configured workspace.…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The plugin manager loads and executes arbitrary .py files from .praisonai/plugins/ directories (both project-level and user home) via importlib.util.specfromfilelocation() + execmodule() with zero code signing, integrity verification, or sandboxing. Any attacker who can write a file to the plugins directory (via path traversal, supply chain attack, or compromised dependency) achieves arbitrary code execution when the plugin system initializes. Details src/praisonai-agents/praisonaiagents/plugins/manager.py (lines 163-196): src/praisonai-agents/praisonaiagents/plugins/discovery.py (lines 38-39): No code signing, hash verification, or sandboxing is applied. The only validation is checking for a Plugin Name field in the file's docstring header. PoC Tested result: Plugin file was loaded via execmodule(), and the PROOF variable confirmed code execution at import time. Impact - Arbitrary code execution: Any .py file in the plugins directory is executed with full Python access - No…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CodeAgent.executepython() executes LLM-generated Python code in a subprocess with the complete parent-process environment (os.environ.copy()), zero AST validation, zero import restrictions, and no sandbox enforcement — even when CodeConfig(sandbox=True) is explicitly set. This allows an attacker who can influence LLM output (via prompt injection in agent input, tool results, or ingested content) to exfiltrate all environment secrets (API keys, database credentials, cloud tokens) and execute arbitrary code on the host. Details src/praisonai-agents/praisonaiagents/agent/codeagent.py (lines 253–308): Key issues: 1. Environment leak: os.environ.copy() passes every environment variable — OPENAIAPIKEY, DATABASEURL, AWS credentials, etc. to the subprocess. By contrast, the sandboxed executecode tool in pythontools.py uses env={} (empty environment). 2. No AST validation: The LLM-generated code string is written directly to a temp file and executed. No validatecodeast() call, no…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI gates dangerous tools (file writes, deletes, shell/code execution) behind an interactive approval prompt. The first approval of a tool is cached for the remainder of the run and silently reused for all later invocations of that tool with arbitrary, unreviewed arguments. Root cause ApprovalRegistry.isalreadyapproved (src/praisonai-agents/praisonaiagents/approval/registry.py, around line 181) returns True whenever the tool name is present in a per-run context set. The cache is keyed on tool name only — arguments are not part of the key. approvesync / approveasync (around lines 224-226 / 278-279) short-circuit on that cache before the approval backend is consulted. clearapproved (around lines 186-187) is the only routine that clears the cache, but it is never invoked in the shipped library (only in tests). The cache persists for the entire agent run and is inherited by child tasks via contextvars. Critical-tier tools (executecommand, executecode) are exempt from the…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's webcrawl agent tool performs a server-side HTTP fetch of an agent/attacker-influenced URL. SSRF is meant to be prevented by issafecrawlurl(), which resolves the hostname and rejects private/loopback/link-local IPs at validation time. The validated value is the URL string (not a pinned IP); the fetch backend then re-resolves the hostname at connection time. Because validation and connection perform two independent DNS resolutions, a DNS-rebinding domain that returns a public IP during validation and an internal IP during the fetch fully bypasses the guard, and the internal HTTP response body is returned to the caller. This is SSRF with internal response disclosure (read-back) — not blind SSRF. Runtime-confirmed against PraisonAI 4.6.63; the crawl response returned the controlled internal markers PRAISONAIINTERNALSECRETCANARY7f3a91 / FAKEINTERNALTOKENDONOTUSE7f3a91. Severity High. Reachable by any actor who can influence the URL an agent crawls (e.g. a…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Project config can auto-save agent output outside the project root Summary praisonaiagents automatically reads project-local .praisonai/config.toml defaults when constructing an Agent. A repository-controlled config can set defaults.output.outputfile to an absolute path or a .. traversal path. When the developer later calls agent.start(...), PraisonAI writes the agent response to that path with open(..., "w"), creating parent directories if needed. This lets an untrusted project overwrite files outside the project root with the privileges of the user running PraisonAI. Technical Details The source-to-sink path is Agent.init() project config loading to OutputConfig.outputfile to public agent.start() output auto-save. praisonaiagents/agent/agent.py applies config-driven defaults before parameter resolution; if the caller did not explicitly pass output, it calls applyconfigdefaults("output", output, OutputConfig). praisonaiagents/config/loader.py treats a config block with enabled =…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The DNS-rebinding / redirect SSRF bypass in PRAI-05 is not limited to the httpx/urllib backend. When crawl4ai (headless Chromium via Playwright) is installed, webcrawl auto-selects provider=crawl4ai, and the headless browser re-resolves DNS and follows redirects on its own — with no per-connection SSRF guard. Runtime-confirmed read-back of the internal canary via both DNS rebinding and redirect (provider: "crawl4ai"). Status: runtime-confirmed addendum to PRAI-05. Details Affected component - Package praisonaiagents 4.6.63. Backend selected when crawl4ai+Playwright are installed. - Files: src/praisonai-agents/praisonaiagents/tools/webcrawltools.py (crawlwithcrawl4ai) and src/praisonai-agents/praisonaiagents/tools/crawl4aitools.py (standalone crawl wrappers). Vulnerable code / root cause Path: src/praisonai-agents/praisonaiagents/tools/webcrawltools.py Function: crawlwithcrawl4ai Snippet: Path: src/praisonai-agents/praisonaiagents/tools/crawl4aitools.py Function:…
Recommended action: Upgrade to 1.6.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
praisonaiagents/memory/filememory.py::FileMemory.init() constructs all memory file paths by directly joining the userid parameter to a base path: No validation or normalization is applied to userid before the path join. An attacker who can supply a userid containing ../ sequences can write arbitrary JSON files (memory content) to any writable location on the filesystem. The vulnerability is confirmed live on the current main branch (praisonaiagents==1.6.52) and is distinct from GHSA-766v-q9x3-g744 (which covered MultiAgentMonitor in an example file, not FileMemory in the core library). Details Vulnerable code — praisonaiagents/memory/filememory.py lines 139-157: All five JSON files are written under userpath, which is directly derived from the attacker-controlled userid. The written content is valid JSON in the memory item format (configurable user content + metadata). Comparison with the patched reference — praisonaiagents/storage/backends.py (SQLiteBackend): The sibling…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Target: PraisonAI (MervinPraison/PraisonAI) Affected component: praisonaiagents/tools/astgreptool.py — astgreprewrite Affected versions: master at ce97667156a116c50b4a3d1aa21e09f048903fda; reproduced against the current praisonaiagents PyPI release (praisonaiagents <= 1.6.52). Summary Tools in praisonaiagents/tools/ that modify on-disk state or run code are uniformly wrapped with @requireapproval, which routes the call through an interactive approval flow before the body runs and fails closed — on denial (or with no approval backend configured) it raises PermissionError and the side effect does not occur. This is applied at every sibling mutation entry point: | File | Line | Symbol | Risk level | |---|---|---|---| | filetools.py | 212 | copyfile | high | | filetools.py | 239 | movefile | high | | filetools.py | 266 | deletefile | high | | edittools.py | 38 | EditTools.editfile | high | | edittools.py | 155 | editfile | high | | shelltools.py | 32 | executecommand | critical | |…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The webcrawl tool performs its SSRF check only on the initial URL: it resolves the hostname once with socket.gethostbyname and rejects private/loopback/link-local results. It then passes the URL to a fetcher that uses httpx.Client(followredirects=True) - or urllib.request.urlopen when httpx is absent, which also follows redirects - and re-resolves the hostname at connect time, with no further validation. This validate-here/fetch-there gap is bypassable two independent ways: HTTP redirects and DNS rebinding. Affected code: src/praisonai-agents/praisonaiagents/tools/webcrawltools.py - Single-shot validation (lines 229-238): if os.environ.get("ALLOWLOCALCRAWL") != "true": ipstr = socket.gethostbyname(hostname) resolved ONCE, at validation time ip = ipaddress.ipaddress(ipstr) if ip.isloopback or ip.isprivate or ip.islinklocal or ip.ismulticast or ip.isunspecified: continue rejected urllist.append(u) - Vulnerable fetch (crawlwithhttpx, lines 142 / 149): follows redirects, re-resolves…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
praisonaiagents/tools/spidertools.py contains an SSRF protection bypass. The function hostisblocked() validates URLs against a list of blocked IP literals and hostname aliases, but never performs DNS resolution. Any hostname that resolves to a private or loopback IP address — including public wildcard DNS services like 127.0.0.1.nip.io — bypasses the protection entirely. This has been confirmed with a live exploit: scrapepage("http://127.0.0.1.nip.io:PORT/secret") makes an HTTP request to 127.0.0.1:PORT and returns the internal service response. No attacker-controlled infrastructure is required. scrapepage, extractlinks, crawl, and extracttext are all registered as LLM-callable agent tools (see tools/init.py lines 51-55), so any agent instructed to fetch a user-supplied URL will trigger this path. This is a new bypass of prior fix commit 004dcfef (GHSA-q9pw-vmhh-384g), which only rejected IP literal encoding tricks (hex, octal, backslash). The fix was also applied to…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research Target: https://github.com/MervinPraison/PraisonAI --- Package: praisonaiagents on PyPI Affected version (empirically tested): 1.6.48 Component: praisonaiagents.server.AgentServer (the bundled HTTP / SSE server) --- TL;DR AgentServer.ServerConfig advertises an authtoken: Optional[str] = None field that operators set when they want to lock down the server. The GET /info endpoint even displays it back as "authtoken": "" — strongly implying the value is wired into request authentication. It isn't. AgentServer.createapp never reads authtoken, never adds an authentication middleware, and never decorates any route with a dependency that checks it. Every route — /info, /publish, /events, /health — accepts unauthenticated requests regardless of whether authtoken is configured. The same package contains a sibling server, praisonaiagents.ui.a2a.A2A, written by the same developer, which implements the…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
praisonaiagents.tools.webcrawltools.webcrawl() validates the initial URL and blocks direct loopback/private destinations by default, but the default httpx fallback still uses httpx.Client(followredirects=True) and does not revalidate redirect targets. An attacker-controlled public URL can pass the initial host check, redirect to loopback/private/cloud metadata infrastructure, and have the redirected response body returned by webcrawl(). This appears to be an incomplete fix / patch bypass for the published webcrawl SSRF class (GHSA-qq9r-63f6-v542 / CVE-2026-40160, and GHSA-8f4v-xfm9-3244). Affected Component Package: File: Functions: Affected Versions Validated affected: - praisonaiagents 1.5.128 via repository tag v4.5.128; - praisonaiagents 1.6.40 via repository tag v4.6.40; - praisonaiagents 1.6.56 via repository tag v4.6.56; - current origin/main commit 095653d78a01cc6c80ff5b2dd20a8e5619686ddc. Suggested affected range for maintainer confirmation: No patched version is…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset. This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution. The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs. This is distinct from the previously published toolresolver.py, api/call.py, templates/tooloverride.py, and agentsgenerator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature. Affected Components -…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
webcrawl (an exported, model-callable tool) validates only the INITIAL URL's resolved IP against a private/loopback blocklist, then fetches with httpx.Client(followredirects=True) and never re-validates redirect targets. An attacker who controls the agent's crawl target (a malicious task, or prompt injection inside any page the agent already crawls) supplies a public URL that HTTP 302-redirects to an internal address. httpx follows the redirect, fetches the internal resource (cloud metadata 169.254.169.254, localhost services, internal APIs), and returns its body into the agent context. This bypasses the SSRF protection added to fix the earlier webcrawl SSRF reports, so it is an incomplete fix for that class. httpx is the default crawl provider on a stock pip install praisonaiagents, so no provider configuration is required. Details 1. The agent is asked (or prompt-injected) to crawl https://attacker.example/r, which the source accepts because attacker.example resolves to a…
Recommended action: Upgrade to 1.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability in the SearxNG / searchweb search tools allows an attacker to make the server perform requests to arbitrary internal endpoints and read the responses back. The searxngurl argument is passed directly to requests.get() with no validation of scheme, host, or port. Because searxngurl is exposed to the LLM as a tool parameter and searchweb / searxngsearch are part of the default agent toolset, the vulnerability is reachable through prompt injection in any content an agent ingests (web pages, files, tool output). This enables reading internal services and APIs, internal host/port enumeration, and in cloud environments reachability of the instance metadata endpoint (169.254.169.254) with potential IAM/credential exposure. Details The SearxNG search provider performs no validation on the searxngurl argument before issuing the HTTP request. src/praisonai-agents/praisonaiagents/tools/searxngtools.py (lines 16–47): The same unvalidated…
Recommended action: Upgrade to 1.6.61 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The email search tool in src/praisonai-agents/praisonaiagents/tools/emailtools.py constructs IMAP SEARCH commands by interpolating LLM-controlled parameters (fromaddr, subject, query) directly into IMAP protocol strings using f-string formatting with double-quote delimiters. An attacker who can influence the arguments to the searchemails or replyemail tool (via crafted agent prompts) can inject arbitrary IMAP commands, potentially exfiltrating email data from other folders, deleting emails, or performing other unauthorized IMAP operations. Details Vulnerable code (lines 493–502): The fromaddr, subject, and query parameters originate from LLM tool call arguments (the searchemails public function at line 665). These values flow through without any sanitization or escaping. The double-quote (") characters in these parameters allow breaking out of the IMAP SEARCH quoted string context. Additional injection points: - Line 416: mail.search(None, f'HEADER Message-ID "{searchid}"') -…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI AgentTeam.launch() exposes unauthenticated remote agent invocation endpoints Summary PraisonAI's documented Python AgentTeam.launch() / Agents.launch() HTTP server starts externally reachable agent invocation endpoints without any authentication enforcement. The current implementation registers GET /{path}/list, POST /{path}, and POST /{path}/{agentid} routes. The POST routes directly call agent.chat(...). Requests with no Authorization header are accepted, and requests with an obviously wrong bearer token are also accepted. The default Python API bind host for Agents.launch() is 0.0.0.0, and official documentation shows host="0.0.0.0" for remote access. This is a sibling/incomplete-fix variant of PraisonAI's prior unauthenticated API server and call server advisory family. Nearby server surfaces were hardened to require tokens, fail closed, or bind locally by default, but the AgentTeam.launch() FastAPI path still exposes unauthenticated agent execution on current upstream…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The MentionsParser in src/praisonai-agents/praisonaiagents/tools/mentions.py processes @file: mentions in agent prompts by reading arbitrary files from the filesystem. When a file path is not found relative to the workspace, the parser falls back to using the path as an absolute path without any validation or boundary check. This allows an attacker who can influence agent prompts (via chat messages, Telegram/Discord/Slack bot inputs, or YAML workflow configs) to read any file on the filesystem accessible to the process user. Details Vulnerable code (lines 165–178): The vulnerability is in the fallback at line 171–172: When the file is not found relative to workspacepath, the code constructs fullpath = Path(filepath), which accepts any absolute or relative path without validation. There is no: - .. path traversal check - Workspace boundary validation - Symlink resolution against workspace - Protected path guard The filepath parameter originates from parsing @file: mentions in…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research Target: https://github.com/MervinPraison/PraisonAI Weakness: CWE-918 Server-Side Request Forgery (SSRF). --- Summary The SSRF guard shared by PraisonAI's web tools (SpiderTools.validateurl → hostisblocked in praisonaiagents/tools/spidertools.py) inspects only literal IP-address encodings of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required. The guard's own docstring claims it returns True "when hostname resolves to loopback/private/internal targets," but no resolution is performed. The fix for CVE-2026-47390 added more encodings of literal IPs (decimal integer, 0x hex, inetaton); it…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated Remote Code Execution via Jobs API and Approval Bypass in PraisonAI Summary An unauthenticated attacker can execute arbitrary OS commands on any server running the PraisonAI Jobs API by submitting a crafted workflow YAML. The attack chains two weaknesses: the /api/v1/runs endpoint requires no credentials, and a top-level approve field in the submitted YAML unconditionally bypasses the @requireapproval safety decorator on dangerous tools such as executecommand. Ecosystem: pip | Package: praisonai | Affected: <= 4.6.48 | Patched: (none) --- Details Step 1 — No authentication on the Jobs API POST /api/v1/runs accepts and executes agent jobs from any caller with no token or session required: Compare with the authenticated endpoint in api/agentinvoke.py, which correctly includes Depends(verifytoken). Step 2 — approve YAML field bypasses @requireapproval The YAML parser extracts an attacker-controlled approve list and loads it into a ContextVar that the approval decorator…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The MCP SSE server started via ToolsMCPServer.runsse() / launchtoolsmcpserver(transport="sse") binds to 0.0.0.0 by default and builds its Starlette application with no authentication middleware and no Origin-header validation. The module mcp/mcpsecurity.py provides exactly the needed controls (origin validation, DNS-rebinding detection, auth-header enforcement, a SecurityConfig), but none of these functions are ever called by any transport — they are dead code. Any host that can reach the port can list and invoke every registered tool with no credentials, and a victim's browser can drive the same calls against a localhost instance via DNS rebinding. Affected code: src/praisonai-agents/praisonaiagents/mcp/mcpserver.py - runsse defaults host to all interfaces (line 245) and builds the app with only debug and routes - no middleware= and no per-route auth/origin gate (lines ~271-289): app = Starlette(debug=self.debug, routes= Route(ssepath, endpoint=handlesse), "/sse"…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The executecode tool's subprocess sandbox advertises a three-layer defense (AST validation, text-pattern blocklist, restricted builtins). In sandbox mode (the default) only two layers are active — the text-pattern blocklist is skipped — and both remaining layers are bypassed by combining two CPython semantics: 1. Runtime string assembly. The AST validator (src/praisonai-agents/praisonaiagents/tools/pythontools.py:75) enumerates blocked dunder names against ast.Attribute.attr, ast.Call.func.id, and ast.Constant string-substring. Names assembled at runtime (e.g. ""2 + "class" + ""2) appear in the AST as multiple short ast.Constant nodes, none containing a blocked substring, so the static check passes. 2. C-level attribute access via format-spec. str.format / str.formatmap resolve dotted field references through CPython's internal PyObjectGetAttr (dostringformat → getfield). This C path never consults the Python-level getattr binding. The sandbox's safegetattr wrapper…
Recommended action: Upgrade to 1.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.