Python
Monthly
Argument injection in the Claude Agent SDK for Python (claude-agent-sdk) before 0.2.121 allows remote attackers to achieve arbitrary command execution when an embedding application passes untrusted input into the SDK's `resume` option. Because `--resume` is declared by the Claude CLI with an optional value, a session identifier beginning with `-` is parsed as a separate CLI flag rather than the option's value, letting an attacker inject `--mcp-config` and register a stdio MCP server that executes arbitrary commands at CLI startup while bypassing the SDK's permission controls. The assessed CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates no authentication is required but exploitation is high-complexity and conditional on the host application forwarding attacker-controlled data as the session ID; a vendor patch is available as version 0.2.121, and no public exploit code was identified at time of analysis.
Python code injection in SGLang 0.5.10 through 0.5.22 allows unauthenticated remote attackers to escape an eval() sandbox in the _evaluate_filter() helper and execute arbitrary Python in the scheduler process. Exploitation is strongly gated: the optional debug dumper server must be explicitly enabled by setting the DUMPER_SERVER_PORT environment variable, which is what exposes the unauthenticated /dumper/configure endpoint; default deployments do not enable it. Once the endpoint is reachable, a crafted filter expression is stored and runs on the next forward pass, giving full code execution with high confidentiality, integrity, and availability impact; no vendor-released patch has been identified at time of analysis, and no public exploit code was identified at time of analysis.
Absolute plot names passed to MatplotlibDataset.save() in kedro-datasets 9.3.0 through 9.6.0 let an authenticated user with the ability to influence plot-name keys write files outside the configured dataset directory, overwriting or creating files anywhere the Kedro process has write access. The flaw is rooted in validate_sub_path(), which strips leading slashes before validation, combined with pathlib join semantics that discard the base path whenever the supplied sub-path is absolute (POSIX '/outside.png', Windows 'C:\\outside.png', or UNC '\\\\server\\share\\outside.png'). Integrity impact is rated High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; CVSS 4.0 base 7.1), no public exploit code has been identified at time of analysis, and no CISA KEV entry exists; exploitability is gated by the attacker's ability to inject the plot-name keys (e.g., through untrusted input data or catalog configuration) and by the write permissions of the process running Kedro.
Authentication bypass in the joserfc Python library before 1.7.4 lets remote, unauthenticated attackers submit a JWS General JSON Serialization whose "signatures" array is empty and have joserfc.jws.deserialize_json() accept it as authenticated, so relying applications can be fooled into treating an arbitrary attacker-chosen payload as a signed, trustworthy message. Exposure is scoped: only the General JSON Serialization code path is affected - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing do not reach the vulnerable logic - but where the vulnerable API is used and its success is treated as proof of authenticity, the integrity impact is high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N per the independent assessment; the published base score is 9.1). No public exploit code or confirmed active exploitation has been identified at time of analysis; the fix commit, tests, and security advisory are publicly available.
Arbitrary file overwrite in HPE NonStop Python 3.x lets an attacker who supplies a crafted TAR archive escape the intended extraction directory via .. (dot-dot) sequences in member filenames and clobber files on the NonStop host, with the overwritten data potentially leading to code execution or system compromise depending on the privileges of the extracting process. The vendor rates this 8.0 (CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), while our independent assessment scores it lower at CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H, treating it as local rather than adjacent-vector and integrity/availability-only; unauthenticated access is implied by PR:N in both vectors, but successful exploitation is not automatic - it requires the victim to extract an attacker-controlled archive (UI:R), and the write primitive is bounded by the privileges of the extracting account. No public exploit code was identified at time of analysis, there is no CISA KEV entry, and no EPSS score was supplied, so real-world risk is moderated by the mandatory user interaction rather than by the headline score.
Arbitrary file read in GitPython before 3.2.0 occurs when a vulnerable application clones an attacker-controlled repository and then calls Head.checkout() on the repository's default branch; a branch named like --pathspec-from-file=<path> is parsed by Git as an option rather than a branch, causing readable file contents to be leaked through GitCommandError messages. This is a credible but conditional information-disclosure flaw, not a drop-everything emergency: only confidentiality is affected, exploitation requires the target to process untrusted repositories and surface error output, and no public exploit identified at time of analysis. Unauthenticated network exploitation is possible per the PR:N vector, and the vendor patch is GitPython 3.2.0.
Regular expression denial of service in GitPython before 3.2.0 allows remote, unauthenticated attackers to exhaust CPU on applications that parse Git commit or tag objects taken from an attacker-controlled repository. The flaw is in the _re_actor_epoch pattern used by parse_actor_and_date on author, committer, and tagger lines, which slips into quadratic backtracking when those lines are padded with long space-filled sequences that lack a valid epoch or timezone. Impact is strictly availability (CVSS 4.0 VA:H with VC:N/VI:N) - there is no confidentiality or integrity exposure, so the 8.7 High score reflects CPU exhaustion only, not code execution or data compromise; no public exploit identified at time of analysis.
Information disclosure in GitPython before 3.2.0 lets attackers leak environment-variable secrets through crafted submodule names in a repository's .gitmodules file. The flaw occurs when Repo._clone() calls Git.polish_url() without expand_vars=False, so variable syntax in a submodule name is expanded during clone plus submodule_update and the resulting values surface in .git/modules directory names and DEBUG logs. Exploitation is unauthenticated per the CVSS vector (PR:N) but requires the victim to clone an attacker-supplied repository and invoke submodule handling, and leakage only materializes if sensitive values are present in the process environment; no public exploit code, CISA KEV entry, or EPSS score was identified in the provided data, and integrity and availability are unaffected (CVSS 4.0 base 7.1, moderate severity).
Arbitrary file access and operating-system command execution in Stirling-PDF prior to 2.13.2 are reachable by an authenticated administrator who uploads a crafted SQL file to POST /api/v1/database/import-database on instances running the default H2 database backend with security mode enabled. DatabaseService.validateSqlContent() splits the normalized input on semicolons and accepts a statement if it merely contains an allowed keyword, so dangerous H2 constructs such as FILE_READ, CSVWRITE and CREATE ALIAS slip past the whitelist and execute when RUNSCRIPT processes the import; the demonstrated chain writes attacker-controlled startup files to a user-site location and triggers the application's Python interpreter to load them, yielding command execution as the JVM service account. The CVSS 3.1 base score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) reflects network reachability with full confidentiality, integrity and availability impact and a scope change, but PR:H means the attacker must already hold administrative privileges and non-H2 deployments are unaffected; no public exploit code identified at time of analysis, and the issue is fixed in version 2.13.2.
Arbitrary filesystem write in Ludwig versions prior to 0.17.8: the dataset archive extraction routine (ludwig.datasets.archives.extract_archive) validates tar member names but never validates symlink or hard-link members, so a crafted archive can create a link that escapes the extraction directory and then write a later member through that link, placing attacker-controlled content at an arbitrary path with the extracting process's privileges. The same name check relied on os.path.commonprefix, a character-based comparison that also lets a sibling path sharing the destination's character prefix pass. Exploitation requires the victim to load a dataset whose configured archive URL points at an attacker-controlled or attacker-compromised tar file (CVSS 3.1: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H - unauthenticated from the network, but mandatory user interaction), and is limited to Python 3.12 and 3.13 runtimes because Python 3.14's default tar 'data' filter already rejects escaping links; no public exploit code or confirmed active exploitation was identified at time of analysis.
Unbounded HTTP request-body buffering in the Model Context Protocol Python SDK (the 'mcp' package) before 1.29.1 and in 2.0.0a1 through 2.0.1 allows unauthenticated remote attackers who can reach an exposed HTTP transport endpoint to exhaust server memory and potentially terminate the process. The Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes read complete request bodies without any maximum-size check, so a single large declared or streamed body can consume multiple times its own size in process memory and repeated requests can drive sustained memory pressure. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) the impact is availability-only, and no public exploit code was identified at time of analysis; stdio-only servers and deployments behind an effective upstream request-size limit are not affected. This is a genuine but bounded-priority availability issue - the fix is a vendor-released patch in 1.29.1 and 2.1.0 that enforces a 4 MiB default body cap and returns HTTP 413, and the primary residual exposure is default HTTP deployments with no reverse-proxy or gateway body limit.
Account pre-hijacking in the Prowler API (5.4.0 up to but not including 5.35.0) lets an unauthenticated remote attacker gain persistent control of a user account that has not yet registered, by self-registering the victim's email address before the real owner ever signs up or links single sign-on. Because social account linking in ProwlerSocialAccountAdapter.pre_social_login() matches a Google or GitHub login to any existing local account with the same email address without requiring the address to be verified by the provider or on the local account, the genuine owner's later social sign-in is silently connected to the attacker's pre-created account, and the attacker's original password remains valid, exposing cloud provider credentials, scan findings and tenant memberships held in that account. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, though exploitation requires only open self-registration plus a victim who later authenticates through Google or GitHub (a race condition that closes once the legitimate owner has an account). The source assigns CVSS 4.0 7.6 (HIGH); our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N.
mise (a polyglot dev tool manager for node, python, cmake, terraform, and others) before version 2026.7.14 lets a malicious local project inject interpreter arguments through an untrusted .mise.toml [settings] file, causing attacker-chosen commands to execute with the developer's privileges. In default non-safe mode, mise applies local project settings before trust approval, and the unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args, and windows_default_inline_shell_args fields were missing the global_only marker, so they survived strip_local_only_settings. When a developer later runs a trusted task, postinstall directive, template exec, or hook that has no explicit shell, mise appends the legitimate command after the attacker-controlled interpreter arguments, and the attacker's command runs first despite the config never being trusted. Exploitation is local and requires user interaction (the victim must clone/open and run the affected task); there is no public exploit code and no confirmed active exploitation at time of analysis, and this is best characterized as a conditional local-escalation risk rather than a mass-exploitation threat. Fixed in 2026.7.14.
OS command injection in the thumbnail Python package through version 1.5 allows attackers who control a filename passed to generate_thumbnail() to execute arbitrary shell commands with the privileges of the Python process. The vulnerable code concatenates user-influenced values (input, output, width, height, quality, trim) directly into os.system() calls invoking ffmpeg, convert or unoconv, so shell metacharacters such as ';', backticks or $(...) in a filename break out of the intended command. The package is a library with no network listener of its own, so real-world reachability depends on the consuming application exposing untrusted filenames - classically a file-upload feature - and on ffmpeg/convert/unoconv being installed for the relevant code branch; where those conditions hold, no authentication or user interaction beyond submitting the malicious filename is required. An upstream fix exists in pull request #9, and no public exploit code has been identified at time of analysis.
OS command injection in xhtml2pdf before 0.2.19 lets an attacker execute arbitrary OS commands as the invoking user when the pisa command-line tool is run with the -s/--start-viewer option against a file whose name contains a double quote plus shell metacharacters. The flaw lives in pisa.startViewer(), which interpolates an unescaped filename into os.system('open "%s"'); because the vulnerable path is only reached in viewer-launch mode, the default programmatic HTML-to-PDF conversion API is not affected. The vector is local and requires a user (or job) to actually launch the viewer, and no public exploit code has been identified at time of analysis - confirmed actively exploited status is not present in the available data.
OS command injection in the Python library pypdftk (through version 0.5) lets attackers who control the pdf_path or out_file arguments of fill_form(), dump_data_fields(), or pdftk_cmd_util() execute arbitrary operating-system commands with the privileges of the hosting Python process. The three functions concatenate caller-supplied paths into a command string using '%s' formatting and pass it to subprocess.Popen with shell=True, so shell metacharacters embedded in a filename or path are interpreted by the shell rather than treated as literal arguments. CVSS v4.0 scores the flaw 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N), and the independent assessment concurs with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, but real-world reachability is bounded by the calling application - pypdftk is a library, not a network service, so exploitation requires the embedding application to forward untrusted input into those parameters, and no public exploit code has been identified at time of analysis. No CISA KEV entry exists for this CVE, and a source-level fix is available from upstream via pull request 57, which replaces string command construction with argument lists.
Privilege escalation in Red Hat OpenShift Container Platform 4's insights-runtime-extractor DaemonSet lets an authenticated low-privileged tenant who can schedule a pod on a node run attacker-controlled code as root in the host user namespace. The extractor scanner enters the workload's namespaces and executes the workload's argv[0] via exec.Command after only seteuid() has changed, leaving real/saved UID 0 and retaining capabilities; a malicious pod binary matching node, python, python3, MainThread, or any path containing java can call setuid(0) and reach the host CRI-O socket from the inherited cwd. CVSS 8.8 (AV:L/PR:L/S:C) reflects local, non-network exploitation requiring workload scheduling, and no public exploit was identified at time of analysis.
Unauthenticated remote code execution in Xorbits Xoscar through 0.11.2 lets any attacker who can reach the actor-pool TCP channel run arbitrary code as the server process, because the receive path hands raw network bytes straight to cloudpickle.loads() before the message type is validated. The CVSS 4.0 vector (AV:N/PR:N/UI:N, 9.3) confirms the bug is remotely reachable and requires no credentials or user interaction, so any deployment exposing an actor pool on a routable interface is exposed at default configuration; impact is worst where the process runs as root, typical of GPU-node deployments. No public exploit code or confirmed active exploitation was identified at time of analysis, and the exposure is bounded by network reachability - installations that bind the actor-pool port to localhost or keep it on an isolated segment are not remotely exploitable.
Local privilege escalation affecting Microsoft Windows builds that ship the vulnerable Python component allows an authenticated, low-privileged local user to elevate to SYSTEM-level rights, resulting in full loss of confidentiality, integrity, and availability on the host (CVSS 7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The flaw is not remotely exploitable and requires a pre-existing foothold or valid local account on an unpatched build, with no user interaction needed once that access exists; there is no public exploit identified at time of analysis and no CISA KEV entry, so exploitation is currently a post-compromise escalation concern rather than a remote mass-exploitation risk. Patches are available from Microsoft for all listed Windows 10, Windows 11, and Windows Server builds, and systems at or above the fixed build numbers (for example Windows 11 24H2 at 10.0.26100.9711 or Windows Server 2022 at 10.0.20348.5761) are not exposed.
Code injection in dataclasses-avroschema versions 0.38.0 through 0.70.5 lets an attacker who controls the Avro schema consumed by the library's model-generator classes inject arbitrary statements into the generated Python source, because enum symbols are used as generated enum member names after case conversion without being validated as Python identifiers. Exploitation is not on the library's default runtime serialization path: it requires an application to invoke the generator classes directly (BaseGenerator.parse_enum / EnumRepresentation.render_symbols) on an attacker-supplied schema and then import or execute the emitted module, which is why the assessed vector carries UI:R despite being network-reachable and unauthenticated (PR:N). Impact when the chain is completed is code execution and namespace modification in the importing process with high confidentiality, integrity, and availability consequences (CVSS 8.8); no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis. Version 0.70.6 fixes the issue by validating every enum symbol as a name.
Arbitrary code execution in dataclasses-avroschema versions 0.38.0 through 0.70.5, where BaseGenerator.parse_fixed writes a fixed type's 'aliases' value straight into the generated types.confixed annotation: a bare string alias (instead of a JSON list) is emitted as an unquoted Python expression and evaluated the moment the generated module is imported. Exploitation is not automatic - it requires a developer to run the library's Avro-schema-to-Python code generation over an attacker-influenced schema and then import the resulting module, which is why the vector carries UI:R despite PR:N and network-level delivery of the malicious schema. The flaw is a genuine CWE-94 code-injection issue with high confidentiality, integrity and availability impact under our assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; no public exploit code has been identified at time of analysis and it is not in CISA KEV. Version 0.70.6 fixes it by rejecting any 'aliases' value that is not a list.
Code injection in dataclasses-avroschema 0.38.0 through 0.70.5 allows an attacker who supplies a crafted Avro schema to the library's Avro-to-Python code generator (model_generator) to embed arbitrary Python statements into the generated module via an enum field default, and those statements execute when the generated module is imported, either modifying the module namespace or preventing it from loading (CVSS 3.1 8.8, CWE-94). The CVSS vector (AV:N/AC:L/PR:N/UI:R) indicates the flaw is unauthenticated but requires user interaction: a victim must run the generator against the attacker-controlled schema and then import the resulting module, so environments that only generate code from their own trusted models or never load attacker-influenced generated code are not exposed. The maintainer confirmed and patched the issue in 0.70.6 by validating enum defaults as names; no public exploit code has been identified at time of analysis, and no active exploitation is confirmed (CISA KEV) at the time of writing.
Python code injection in dataclasses-avroschema versions 0.38.0 through 0.70.5 lets an attacker with control over Avro schema content smuggle arbitrary Python statements into the enum class body that the library emits, so simply importing the generated module executes the attacker's code. The flaw sits in EnumRepresentation.render_symbols, which wraps each schema-supplied enum symbol in double quotes without escaping it, allowing a quote character to close the literal and append attacker-chosen Python. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8, CWE-94) indicates no privileges are required but that user interaction is essential, since the victim must run the import of the generated file; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, and version 0.70.6 fixes it by escaping enum symbol values before rendering.
Arbitrary Python code execution in dataclasses-avroschema versions 0.44.0 through 0.70.5 occurs because the Pydantic and AvroDantic model generators embed an Avro schema field's pydantic-class value directly into a generated field annotation after the literal prefix 'pydantic.', without sanitizing the expression. When a victim runs the code-generation path (ModelGenerator) on an attacker-influenced schema and then imports the generated Python module, the injected annotation is evaluated at import time and the payload executes with the privileges of that process, giving full confidentiality and integrity impact (CVSS 8.8, AV:C:N/AC:L/PR:N/UI:R). Exploitation is unauthenticated from the network perspective (CVSS PR:N) but requires the victim to generate and import the code, and no public exploit code or CISA KEV entry was identified at time of analysis; version 0.70.6 restricts the value to a bare name or a call to a bare name with literal arguments.
Arbitrary Python code execution is possible in dataclasses-avroschema versions 0.65.9 through 0.70.5 when the library's Pydantic or AvroDantic model-generation path is run over an Avro schema the attacker controls: the schema field's 'doc' value is interpolated unescaped between the quotes of a generated pydantic.Field(description="...") argument, so a crafted quote can close the string and inject a Python expression that is evaluated when the generated class is defined (CWE-94). The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (8.8), reflecting high confidentiality and integrity impact with user interaction required because a developer or build process must actively generate models from the malicious schema; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, and urgency is further moderated because only the Pydantic/AvroDantic generators are affected and only versions 0.65.9-0.70.5 are vulnerable.
Code injection in dataclasses-avroschema 0.38.0 through 0.70.5 lets an attacker-influenced Avro schema execute arbitrary Python when the library's model generator renders a 'fixed' type's namespace into generated source. BaseGenerator.parse_fixed interpolates the namespace between quotes inside a generated types.confixed annotation without escaping, so a namespace containing a quote character terminates the string literal and turns the remainder into live Python that runs when the generated class is defined or the generated module is imported; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (8.8), unauthenticated over the network but requiring the victim to run code generation on the crafted schema and then import the result. The flaw is fixed in 0.70.6, which enforces that namespaces are dot-separated sequences of valid Avro names; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, but the high CVSS score, confirmed GHSA-h9q3-f96w-f88j advisory, and availability of a vendor fix commit make prompt upgrading advisable for anyone generating code from externally sourced schemas.
Code injection in dataclasses-avroschema versions 0.40.0 through 0.70.5 lets an attacker who controls the `doc` value of an Avro schema record close the generated class docstring and inject arbitrary Python statements into the emitted class body, achieving code execution when the generated module is imported. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) rates the flaw as network-reachable, low-complexity and unauthenticated with high confidentiality and integrity impact, but exploitation is gated by user interaction: a developer or CI pipeline must both run the library's model generator against the attacker-influenced schema and import the resulting Python file. No public exploit code has been identified at time of analysis, and the vendor released a fix in 0.70.6.
Code injection in dataclasses-avroschema 0.62.3 through 0.70.5 allows an attacker-supplied Avro record name to break out of the quoted Meta.schema_name string literal and inject arbitrary Python statements into the generated model's class body, which then execute when that generated module is imported. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R) means no authentication is required but a victim must run the Avro-to-Python code generator on an untrusted or tainted schema and subsequently import the generated file; generating Avro schemas from trusted local dataclasses does not trigger it. Vendor-released patch: 0.70.6. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV entry).
Code injection in dataclasses-avroschema versions 0.38.0 through 0.70.5 allows remote, unauthenticated attackers who supply a crafted Avro schema to inject constrained Python statements into the module produced by the schema-to-code generator; the injected code executes when that generated module is imported. Exploitation requires the victim to deliberately process an untrusted schema through the avro-to-code path and then import the resulting module (the UI:R gate), which limits exposure to pipelines that ingest third-party schemas. CVSS 3.1 base score is 8.8 (High) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; no public exploit identified at time of analysis, and version 0.70.6 fixes the flaw by validating enum defaults as names.
Arbitrary code execution in dataclasses-avroschema 0.38.0 through 0.70.5 occurs when the library's Avro-to-Python model generator processes a schema containing a fixed type whose 'aliases' value is a bare string instead of a list; the value is interpolated unquoted into a generated 'types.confixed' annotation and evaluated when the generated module is imported, giving an attacker code execution in the victim's Python process. Exploitation is unauthenticated from the network perspective (CVSS:3.1/AV:N/AC:L/PR:N/UI:R) but gated on victim interaction: someone must run the schema-to-code generation path on attacker-controlled schema content and then import the resulting module. There is no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV), so this is a high-severity but precondition-gated code-injection flaw; the vendor released 0.70.6, which rejects non-list aliases.
Authenticated users with workflow create/edit rights on self-hosted Heym deployments prior to 0.0.40 can escape the application's blacklist-based Python sandbox and execute arbitrary commands and file operations as the backend service account. The flaw lives in backend/app/services/python_tool_executor.py, where the allowlisted standard-library modules still expose OS, process, and filesystem primitives through public attributes, so tool source that passes _safe_import() and _validate_code_safety() is ultimately run through exec() with full application privileges (CVSS 8.8, CWE-78). Exploitation requires a low-privilege authenticated account (PR:L) with permission to create or edit a workflow containing an Agent custom Python tool; enabling self-registration makes that account trivially obtainable, though merely triggering a workflow from the portal does not grant code control. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), but the fix in 0.0.40 is available and the assessed risk is high for any multi-user deployment.
Server-side request forgery in the SAP Cloud SDK for Python lets remote, unauthenticated attackers redirect OAuth2 token requests to a server they control by manipulating the tenant_subdomain value used to build the token endpoint URL, resulting in exfiltration of the application's OAuth2 client credentials. Exposure is limited to multi-tenant SAP BTP applications that use the SDK for OAuth2 token acquisition and allow attacker influence over the tenant_subdomain input; single-tenant deployments, or those that do not derive the token URL from attacker-supplied data, are not exposed. The vulnerability carries a maximum-severity score of CVSS 10.0, and no public exploit code was identified at time of analysis; no confirmed actively exploited (CISA KEV) status applies.
Information disclosure in Open WebUI 0.11.0 through 0.11.3 allows an authenticated non-admin user who holds the tool export permission to retrieve the complete Python source code of tools shared with them in read-only mode by calling GET /api/v1/tools/export, exposing any API keys or credentials embedded in that source. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the impact is bounded by three prerequisites: a valid account, the specific tool export permission, and the presence of read-only shared tools that actually contain secrets. The issue is rated CVSS 4.0 7.1 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) and is fixed in 0.11.4.
Server-side template injection in Wizarr before 2026.9.1 allows an authenticated user with privileges to create or edit wizard steps - or an administrator who imports an attacker-supplied wizard bundle - to execute arbitrary Python in the context of the application process. Because the stored step Markdown is compiled by the application's non-sandboxed Jinja2 environment with application globals exposed, successful exploitation can run operating-system commands as the application user, disclose the Flask SECRET_KEY, reach connected media-server service credentials and the database, and inject stored cross-site scripting into pages rendered at GET /wizard/{server}/{idx}. The issue is rated 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) and is fixed in 2026.9.1; no public exploit code was identified at the time of analysis, and the PR:H prerequisite narrows the realistic attacker population to trusted-but-malicious insiders or admins socially engineered into importing a hostile bundle.
Authenticated low-privilege tenant users of iFlytek Astron Agent prior to 1.1.2 can run arbitrary Python as root inside the core-workflow container by submitting a workflow Code node, because the shipped default configuration routes dynamic code execution to an unsandboxed LocalExecutor that exposes the full set of Python builtins. From that foothold the attacker can read shared service and database credentials and use them to bypass application-level tenant checks, read or modify other tenants' data, and disrupt shared services (CVSS 9.9, scope-changed, CWE-95). Exploitation requires a valid tenant account plus the ability to create or run a workflow containing a Code node; no public exploit identified at time of analysis, and the vendor-released patch is version 1.1.2.
Processing an attacker-controlled Protobuf schema with datamodel-code-generator 0.59.0 through 0.80.0 lets a crafted weak-import path escape the `__weak_imports__` temporary directory, creating directory trees and new files, or overwriting existing files that are writable by the running process (assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N; the vendor-reported vector is 7.5 with a higher integrity rating). Exploitation requires a victim or automated CI job to invoke the tool with `--input-file-type protobuf` on a malicious .proto supplied locally via `--input` or remotely via `--url`, and the grpcio-tools package must be installed to enable Protobuf input support; the payload is limited to a `syntax = "proto2";` or `syntax = "proto3";` declaration, so fully attacker-controlled content and direct arbitrary code execution have not been demonstrated. No active exploitation is confirmed (not in CISA KEV), though the upstream GitHub advisory carries a proof-of-concept and technical write-up, and the fix ships in version 0.81.0.
Cross-site request forgery in the CISA Malcolm network traffic analysis platform lets a remote attacker who lures the operator into loading attacker-controlled web content force that operator's browser to fire unauthenticated management commands at the kiosk's POST /script_call/<script> endpoint. Successful abuse yields high integrity and availability impact (I:H/A:H) with no confidentiality impact (C:N), because the reachable commands are destructive rather than data-stealing - most notably control.py --wipe, which permanently deletes all captured network traffic and forensic logs, and control.py --stop, which blinds security monitoring. The endpoint ships with zero authentication and wildcard CORS (CORS(app)) in its default state, so no server-side misconfiguration is required; the only real barrier is inducing the specific operator to render a malicious page (UI:R). No public exploit code and no confirmed active exploitation were identified at time of analysis.
Cross-site request forgery in Pydantic AI's development web chat UI allows any website a developer happens to visit while `Agent.to_web()` or `clai web` is running to fire forged chat requests at the loopback-hosted server, causing the served agent to start a run and execute its tools with the privileges and credentials of the local process. The pre-patch `/api/chat` endpoint performed no Content-Type validation, so a malicious page can deliver a JSON body cross-origin using a CORS-safelisted content type (text/plain, multipart/form-data, application/x-www-form-urlencoded, or none at all) without triggering a preflight; binding the server to localhost - the default - provides no protection because a browser page can reach 127.0.0.1. Realized damage is bounded by the tools the agent exposes, and `requires_approval=True` does not help because the endpoint trusts approval decisions relayed by the client; exploitation is unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:L, 7.6) but requires the developer to browse an attacker-controlled page while the dev UI is running, and there is no public exploit code identified at time of analysis. Vendor-released patches are available in 1.107.4 and 2.28.0.
Concurrency slot exhaustion in Pydantic AI 2.10.0 through 2.52.x lets streamed model requests permanently occupy slots in a shared ConcurrencyLimiter, progressively starving later requests until a service that reuses one long-lived limiter can no longer make model calls - an availability-only denial of service (C:N/I:N/A:H) with no confidentiality or integrity impact. The issue is remotely reachable and unauthenticated (PR:N), but our independent assessment rates it AC:H rather than GitHub's AC:L because exploitation requires a specific deployment pattern: model requests wrapped in ConcurrencyLimitedModel (or covered by limit_model_concurrency) that share a single long-lived limiter across streamed responses; agent-level max_concurrency and all non-streaming model requests are explicitly unaffected, and a short-lived or per-request limiter never accumulates enough leaked slots to deadlock. Slots are leaked by early stream termination, cancellation, consumer exceptions, or even full stream_text() consumption with debounce_by=0.1, and the vendor-released fix in 2.53.0 is available; no public exploit code identified at time of analysis.
Python code injection in PraisonAI's deploy tooling (all versions up to and including 4.6.77) lets a high-privileged actor who controls the `agents_file` value break out of an f-string and execute arbitrary code on the host running the deploy command. The flaw is triggered at build/deploy time: the unsanitized value is interpolated into generated server or Dockerfile source in `deploy/api.py` and `deploy/docker.py`, written to disk, and then launched via `subprocess.Popen(['python', server_file])`, so the primary realistic exposure is CI/CD pipelines or shared build environments where `agents_file` originates from externally influenced configuration. The vendor advisory includes a proof-of-concept demonstrating the string-breakout payload and a fix is available in 4.6.78; no CISA KEV entry or other confirmation of active exploitation was present in the source data, and this is not a remotely reachable flaw in a default running service - exploitation requires the attacker to already be positioned to set or tamper with deploy-time input and for someone to invoke the deploy command.
Unauthenticated remote code execution in LMCache through 0.5.5 allows network-reachable attackers to execute arbitrary Python and operating-system commands as the LMCache process by posting scripts to the /run_script endpoint; the endpoint's existing __import__ guard is bypassed via the injected FastAPI app object, which exposes real builtins (CWE-306, CVSS 9.3 v4.0 / 3.1 AV:N/AC:L/PR:N/UI:N). No public exploit code or confirmed in-the-wild activity has been identified at time of analysis, though the vulnerability details and vendor advisory are public. The primary limiting factor is deployment exposure: exploitation requires the internal API HTTP server to be enabled and bound to a network-accessible interface rather than restricted to localhost or a trusted management network.
Authenticated remote code execution in the @backstage/plugin-techdocs-node package shipped with the Backstage developer portal framework allows a user who can register or influence an SCM-backed documentation source to execute arbitrary code on the TechDocs backend host. The flaw (CWE-502, CVSS 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) arises because mapping-style markdown_extensions entries in a committed mkdocs.yml were not sanitized, letting an attacker name Python callables such as subprocess:Popen or os:system that MkDocs then imports and instantiates during documentation generation. Exploitation requires a valid account and an instance that performs server-side TechDocs generation of attacker-controlled sources, so risk is highest where generation runs with backend credentials, filesystem access, or internal network reachability; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Cross-tenant information disclosure in wger allows an authenticated trainer account that holds both the gym.gym_trainer and gym.add_adminusernote permissions but has no gym assignment (userprofile.gym = None) to read private admin notes, uploaded documents, gym contracts, user configuration and permission data belonging to any other unassigned (gym = None) user on the same instance. The root cause is an authorization guard that fails open: the five affected views compare gym objects with the Python operator '!=', and 'None != None' evaluates to False, so HttpResponseForbidden is never reached and the following queryset is filtered only by the attacker-supplied member_id. Rated CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, authenticated, low privilege), the bug is amplified because gym = None is the default state for newly registered users, so any instance with public registration plus delegated trainer permissions is exposed; a detailed proof-of-concept is documented in the published GitHub advisory and the permission-edit endpoint is also reachable, giving a possible privilege-escalation path, though no confirmed in-the-wild exploitation has been reported.
Arbitrary code execution in AWS Bedrock AgentCore Starter Toolkit before 0.3.14 allows an authenticated same-account actor to inject malicious Python code into generated agent source by importing a crafted Bedrock Agent configuration, which executes when the victim runs or deploys the agent. Exploitation requires the victim to import and then run or deploy the agent, and the actor must have valid same-account credentials. No public exploit identified at time of analysis; remediation requires upgrading to 0.3.14 and re-importing any previously affected agents because the generated source persists.
Hydra 1.3.4 through 1.3.5 and the 1.4.0.dev line prior to 1.4.0.dev9 can execute attacker-chosen code when an application runs Hydra's instantiate() on configuration an attacker can influence, because the callable blacklist added for CVE-2026-68508 is name-based and can be sidestepped via wrappers, aliases, dispatch helpers, or deferred invocation. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 7.8) indicates no attacker privileges are required but a victim application must actually instantiate untrusted or externally sourced config, which is why user interaction is scored; the flaw is CWE-184 (Incomplete List of Disallowed Inputs) and is best understood as an incomplete fix rather than a new class of bug. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, and vendor-released patches exist in Hydra 1.3.6 and 1.4.0.dev9. Applications that only ever instantiate developer-authored, trusted configuration are not exposed, and the vendor explicitly documents the blocklist as a best-effort defense-in-depth stopgap rather than a security boundary.
Code injection in the Hydra configuration framework (all releases prior to 1.3.6 and 1.4.0.dev9) lets an attacker who controls the application's Hydra logging configuration name an arbitrary importable class or factory that Hydra will then import and invoke with the application's own privileges. Hydra routes logging settings to Python's logging.config.dictConfig() without applying its own target policy, so the handler 'class' values and the formatter, filter, handler, queue and listener factories are resolved and called directly - this bypasses the _target_whitelist_ protection that otherwise guards instantiate(), meaning even hardened deployments are exposed. The assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8): a local, unprivileged attacker must plant malicious logging configuration (a config file, an override, or a shared/untrusted config source) and the victim must then run the Hydra application, yielding high confidentiality, integrity and availability impact; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but exploitation only requires that the victim execute the tampered configuration.
Configuration-controlled code execution in the hydra-optuna-sweeper package (Hydra 1.2.0 up to but not including 1.3.0, plus 1.4.0 development builds before 1.4.0.dev10) allows an attacker who controls Optuna sweep configuration or command-line overrides to name an arbitrary importable Python callable in hydra.sweeper.custom_search_space that Hydra resolves and then invokes inside the controller process at the application's privilege level, including bypassing the trusted execution whitelist introduced on affected 1.4.0 development releases. The assessed CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8 High): delivery is local and unauthenticated, but a victim must actually launch the sweep, after which confidentiality, integrity, and availability impact is total for the affected process. Exploitation is only meaningful where sweep configuration or overrides cross a trust boundary; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Code execution with the hosting application's privileges is possible in Hydra 1.3.4 through versions before 1.3.7 (and before 1.4.0.dev10) when an attacker controls multiple sibling target entries in a configuration that the application passes to instantiate(). One sibling resolves hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard to delete a denied target from Hydra's process-global blocklist, and a later sibling - processed in insertion order against the same mutated policy - invokes the now-permitted callable; the mutation persists for the life of the process. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, 8.5) indicates no privileges are required and only passive user interaction, and no public exploit identified at time of analysis (not in CISA KEV, no POC referenced); exploitation is limited to deployments that feed untrusted configuration content to instantiate(), and a narrow execution whitelist supplied by trusted Python code is not bypassed by the reported direct mutation path.
Openapi-python-client before 0.29.1 fails to neutralize attacker-influenced content from an OpenAPI document when rendering string, docstring, and f-string contexts, so a malicious or untrusted specification can cause arbitrary Python to be emitted into the generated client - code that then executes when that client is imported, compromising the integrity of the importing environment and potentially its confidentiality and availability. Exposure is conditional: it requires someone to generate a client from a spec they do not fully control (a third-party, public, or otherwise untrusted API definition) and then import the generated code, which is the trigger point, so organizations generating only from trusted internal specs are effectively unaffected. The flaw is rated 8.4 under CVSS 4.0 in the source data (independent assessment maps it to CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), which is consistent with a serious but conditionally triggered supply-chain and code-generation issue rather than a remotely reachable mass-exploitation vector. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has shipped a fix in version 0.29.1.
Denial of service in Scrapy 1.4.0 through 2.14.1 allows any web server the crawler visits to terminate the crawler process by returning a crafted Referrer-Policy response header, such as 'sys.exit', which the built-in RefererMiddleware treats as a Python import path and invokes. The flaw is reachable over the network without authentication or user interaction (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U, base 7.5 High), and its impact is limited to availability because only importable, zero-argument callables can be triggered, making realistic effect process termination rather than general arbitrary code execution. Any crawler left in its default configuration (RefererMiddleware enabled via REFERER_ENABLED=True) that fetches attacker-controlled pages is exposed; no public exploit identified at time of analysis, and the vendor-released patch is Scrapy 2.14.2.
Import-time code execution in Docling 2.27.0 through 2.131.0 lets any distribution already present in the same Python environment that registers an entry point in the 'docling' group run arbitrary code as soon as Docling's plugin factories initialize - even when allow_external_plugins is set to false, because the plugin manager imports every registered module before the namespace allow-list is applied and then misleadingly logs that the plugin was skipped. The assessed vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) confirms this is a local, supply-chain-style prerequisite: an attacker must first get a third-party or compromised package installed and registered, and Docling must then be started by a user, so there is no remote network exploitation path. No public exploit code or active exploitation is known at time of analysis (EPSS 0.11%, percentile 1%; CISA SSVC exploitation: none), and the vendor has shipped a fix in 2.131.0.
Unauthenticated remote attackers can forge Django-signed session cookies, CSRF tokens, and password-reset tokens, and bypass live-service authentication, against Plane installations that shipped with publicly known default secrets. Plane versions prior to 1.4.0 distributed fixed SECRET_KEY (60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5) and LIVE_SERVER_SECRET_KEY (htbqvBJAgpm9bzvf3r4urJer0ENReatceh) values in the deployments/aio/community/ and deployments/cli/community/ manifests, while the top-level setup.sh randomized secrets only for the development Docker Compose path, leaving AIO and CLI community deployments with shared production secrets by default. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, C/I/A:H) and classified CWE-798; no public exploit identified at time of analysis, although the default key values are published in the vendor repository and are therefore trivially usable by anyone who reads it. Exposure is limited to network-reachable instances deployed via those community manifests whose operators never overrode the secrets; deployments created through the development Compose path, operator-hardened installs with unique secrets, and instances upgraded to 1.4.0 are not exploitable.
Brute-forceable magic-code email login in Plane versions prior to 1.4.0 allows unauthenticated remote attackers to guess a six-digit numeric login code and take over accounts. The verify endpoint extends django.views.View instead of DRF's APIView, so the configured AnonRateThrottle never runs, and there is no per-code attempt counter, no counter invalidation, and no Django-level throttle middleware behind it, leaving roughly 20 bits of OTP entropy with effectively unlimited guesses inside the code's Redis TTL window. There is no public exploit identified at time of analysis and no confirmed active exploitation, but the 9.1 CVSS reflects a full account takeover path (C:H/I:H) with no authentication or user interaction required, and the fix was released in Plane 1.4.0.
Papermerge 3.5.3 permits an authenticated standard user to achieve remote code execution by uploading a crafted file to /api/documents/upload with directory-traversal sequences in the filename, causing a malicious Python .pth file to be written into the interpreter's site-packages directory; the embedded code executes only when the Python interpreter next starts, for example on an application or worker restart. Publicly available exploit code exists via a GitHub PoC repository and accompanying PDF, and the flaw is conditionally gated by requiring the Papermerge process to have write access to site-packages and by the attacker not controlling restart timing, making it a credible but conditionally-gated RCE rather than an immediately triggerable one.
Code injection in InternLM MindSearch 0.1.0 allows unauthenticated remote attackers to execute arbitrary code through the Planner Agent component, specifically by manipulating the inputs argument processed by ExecutionAction.run in mindsearch/agent/graph.py. The issue is rated critical (CVSS 9.3 per the CVSS 4.0 vector; the independent assessment likewise has PR:N/UI:N with high confidentiality, integrity, and availability impact), and publicly available exploit code exists. The vendor was contacted but did not respond, no vendor-released patch has been identified, and risk is concentrated in internet-reachable or otherwise accessible self-hosted MindSearch 0.1.0 deployments.
Incorrect authorization in the LangGraph Python SDK (langgraph-sdk) versions 0.1.45 through 0.4.3 lets an authenticated user read, update, or delete resources belonging to other users, because the resource-scoped decorators @auth.on.threads, @auth.on.assistants, and @auth.on.crons ignore their actions= argument and register the handler as a wildcard for every action on that resource. That wildcard handler is matched ahead of broader fallback handlers, so any action, ownership, or permission checks implemented in those fallbacks are silently skipped. The flaw is conditionally scoped: a deployment is only exposed if it uses these decorators together with actions= and relies on separate fallback handlers for enforcement, and authentication requirements are confirmed as authenticated (CVSS PR:L) with no public exploit identified at time of analysis. This is fixed in langgraph-sdk 0.4.4.
Opening an attacker-controlled Kerchunk reference document with fsspec's ReferenceFileSystem can execute arbitrary Python code, because versions from 0.9.0 up to (but not including) 2026.6.0 render reference fields through unrestricted jinja2 templates instead of treating them as inert data. The vulnerability is exploitable by unauthenticated attackers but requires user interaction: the victim application - or a downstream consumer such as xarray - must actually open the malicious document, which can be supplied inline or fetched from an attacker-controlled URL, and the gen-array code path triggers with no special configuration at all. Rated CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, CWE-94), it is addressed by the vendor's 2026.6.0 release, which makes jinja interpretation opt-in; no public exploit identified at time of analysis.
Uncontrolled resource allocation in Apache Thrift versions before 0.25.0 allows remote unauthenticated attackers to exhaust memory, CPU, or worker/connection capacity in services built on the C++, Java, Go, netstd, Python, and Delphi bindings (CWE-770), disrupting availability. The impact is availability-only - no confidentiality or integrity loss - rated CVSS 8.2 under CVSS 4.0, with the 4.0 AT:P flag and the independent CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both indicating a specific condition must hold for the allocation to trigger, so exploitation is not guaranteed against every message or deployment. No public exploit code and no CISA KEV listing were identified at time of analysis; upgrading to 0.25.0 removes the condition entirely.
Stack exhaustion in Apache Thrift before 0.25.0 allows remote, unauthenticated attackers to crash processes that deserialize attacker-controlled Thrift messages, because the protocol skip routine in several language bindings fails to apply the binding's recursion limit when skipping unknown fields. The affected bindings are the Python C++ accelerator (the pure-Python protocols are not affected), the PHP library and its thrift_protocol extension, and the Perl, Lua, Smalltalk and OCaml libraries; the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms the bug is reachable over the network with no privileges or user interaction, but the impact metrics (VC:N/VI:N/VA:H) restrict the consequence to availability loss. There is no code execution or data exposure, no public exploit code and no confirmed active exploitation at time of analysis, and Apache has released version 0.25.0 which restores the recursion limit.
Denial of service in Apache Thrift Python bindings before 0.25.0 allows unauthenticated remote attackers to hang the service by sending crafted Thrift messages that drive the parser into an infinite loop (CWE-835). Exploitation is network-based but requires a specific condition, such as a particular protocol/transport or malformed message structure, to trigger the loop (AT:P / AC:H). The impact is limited to availability-no data disclosure or code execution-and only services exposing a Thrift endpoint that processes untrusted input using the Python bindings are affected; no public exploit code has been identified at time of analysis.
Denial of service in Apache Thrift before 0.25.0 allows unauthenticated remote attackers to crash or exhaust services running affected language bindings by sending malformed Thrift protocol data. The flaw combines improper length-parameter handling with excessive memory allocation, inefficient algorithmic complexity, uncaught exceptions, and insecure default initialization across the Python, Ruby, Erlang, Lua, Dart, JavaME, Perl, PHP, and D bindings. It is availability-only: no code execution, data disclosure, or data tampering is known from this issue. No public exploit code or confirmed active exploitation was identified at time of analysis; upgrading to 0.25.0 resolves it.
Denial of service in Apache Thrift's Python bindings (all versions before 0.25.0) allows remote, unauthenticated clients to force unbounded memory allocation by sending crafted messages that declare oversized containers or strings, crashing or hanging the affected service. The flaw pairs a missing resource limit with an insecure default configuration in which the bindings apply no read or container size cap unless the application explicitly sets one, so any network-reachable Thrift service that accepts untrusted traffic while running on those defaults is exposed. Impact is confined to availability with no confidentiality or integrity effect, and the CVSS 4.0 AT:P component reflects that a specific, not fully attacker-controlled deployment condition must be met; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Code injection in Vanna 2.0.2's VannaBase.get_plotly_figure presents conflicting signals that must be weighed carefully: the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8), yet EPSS is only 0.36% (27th percentile) and there is no CISA KEV entry, so no public exploit identified at time of analysis. In CVSS terms this is an unauthenticated remote issue, but the governing exploitation condition is that a deploying application exposes vanna's figure/plot-generation entry to attacker-influenced input; where the plotting path is exposed via bundled Flask/Streamlit/API front ends, an attacker who can shape the question or prompt can achieve attacker-controlled code or command execution, while embedded deployments that gate, authenticate, or do not expose that path are substantially less exposed than the 9.8 score implies.
Denial of service in Amazon Ion Python before 0.15.0 allows remote, unauthenticated attackers to crash applications that parse attacker-supplied Ion data by submitting a deeply nested Ion value that exhausts the interpreter's recursion stack. The flaw is availability-only (CWE-674 uncontrolled recursion) and requires the target service to route untrusted Ion input into the Ion reader; applications that only parse trusted, internally generated Ion are not realistically exposed, and no authentication, user interaction, or non-default configuration is needed otherwise (PR:N/UI:N). No public exploit code was identified at time of analysis and there is no indication of confirmed active exploitation (not listed in CISA KEV); the vendor fix in 0.15.0 caps container nesting past the recursion limit and surfaces the condition as an IonException instead of an uncontrolled crash.
Improper TLS certificate validation in the Confluent Kafka Python client's HashiCorp Vault KMS integration (confluent-kafka versions 0 through 2.14.2) allows a man-in-the-middle attacker to obtain sensitive information when the integration is used with its default configuration, which disables certificate verification. Successful exploitation requires the application to use the Vault KMS integration and the attacker to achieve a MITM position on the TLS connection to Vault, making this a conditional but significant risk (CVSS 7.4). No public exploit has been identified at the time of analysis.
Poisoned OAuth/OIDC discovery metadata in Authlib 1.7.2 and earlier allows an attacker who controls or intercepts the metadata fetch to replace every cached endpoint - authorization, token, JWKS and userinfo URLs - with attacker-controlled values, enabling token theft, credential interception and authentication bypass in applications built on the library. Publicly available exploit code exists (SSVC exploitation: poc) and the flaw is rated fully automatable with total technical impact, although it is not listed in CISA KEV; EPSS is low at 0.10% (1st percentile). The supplied CVSS of 9.8 overstates realistic reachability versus our assessed 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), because exploitation requires a privileged network position on the discovery fetch or a compromised/malicious issuer endpoint, and TLS-validated metadata from a trusted issuer is not exploitable without first defeating that channel.
Unauthenticated local file disclosure in Tornado before 6.5.9 lets remote attackers read files outside a configured static root by requesting a symbolic link that lives inside that root but resolves elsewhere, exposing configuration files, private keys, and application secrets readable by the Tornado process user. Exploitation is a single GET request requiring no authentication and no user interaction (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N), but it depends on a precondition rather than being turnkey: an out-of-root symlink must already exist inside the static directory, a situation the upstream advisory says arises in applications serving user-uploadable content or where build/deploy pipelines (npm link, webpack, Docker volume mounts, CDN sync tools) create symlinks. The issue is fixed in 6.5.9, public reproduction steps are published in the upstream GitHub Security Advisory, and there is no CISA KEV listing.
Denial of service in the Tornado web framework's CurlAsyncHTTPClient (all releases before 6.5.9) lets an unauthenticated remote server OOM-kill the application process by answering a fetch with a gzip decompression bomb: libcurl decompresses the body before invoking the client's write callback, and Tornado appends the decoded bytes to an unbounded BytesIO with no post-decompression size check, so a few megabytes on the wire expand to gigabytes of resident memory. Exposure is genuinely conditional - the application must be explicitly configured to use CurlAsyncHTTPClient (via AsyncHTTPClient.configure), must leave decompress_response at its default True, and must fetch a URL the attacker controls or has compromised; the default SimpleAsyncHTTPClient is not affected because the size gates added for CVE-2026-49855 live in code the curl client never executes. The upstream GHSA advisory documents a verified end-to-end reproduction on master (6.6.dev1) and v6.5.8 where a ~2.8 MB gzip payload grew client RSS from roughly 31 MB to about 1,032 MB in 3.18 seconds (exit 137, cgroup OOMKilled=true); the only incidental ceiling before the patch was the default 20-second request_timeout. No public exploit code or active exploitation has been identified at time of analysis, and no CISA KEV listing applies.
Authenticated code injection in langflow-ai Langflow up to and including v1.9.3 lets any user holding a valid account execute arbitrary Python on the server by POSTing raw source to the /api/v1/validate/code endpoint, which feeds the input straight into a server-side compile/exec validation path without sandboxing or an entitlement check (CWE-94). The supplied CVSS score is 9.8 under a PR:N vector, but the authoritative assessment applies PR:L because exploitation requires a valid Langflow session, making authentication the primary limiting factor; impact on confidentiality, integrity, and availability is rated High across the board. EPSS is only 0.17% (6th percentile), Langflow is not in CISA KEV, and no public exploit code has been identified at time of analysis, so mass opportunistic exploitation is not currently indicated - the realistic risk concentrates on internet-exposed, multi-tenant, or weakly authenticated Langflow deployments.
Memory exhaustion in pypdf versions prior to 6.19.0 allows a remote, unauthenticated attacker to make an application unavailable by supplying a crafted PDF whose page-label numbering tree uses an alphabetical style (/S /A or /S /a) with an oversized /St start value, causing the library to generate pathologically long label strings when an application requests document page labels. The impact is strictly availability-related (C:N/I:N/A:H) with no data exposure, integrity loss, or code execution, and it only triggers if the consuming application actually reads page labels rather than merely opening the file. There is confirmed actively exploited status: no public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis beyond the fixed release 6.19.0; the independent assessment rates this as a genuine but bounded denial-of-service rather than an RCE despite the elevated CVSS 4.0 score of 8.7.
Denial of service in pypdf versions prior to 6.19.0 allows an unauthenticated remote attacker to pin a PDF-processing worker by supplying a document containing a large number of embedded files, because the dictionary-based attachments API re-enumerates and reparses the entire /EmbeddedFiles attachment list on every content lookup instead of indexing it once. The impact is limited to availability (CPU and wall-clock exhaustion); there is no code execution, data disclosure, or integrity impact, and the exposure is conditional on the host application actually enumerating or reading embedded-file attachments rather than merely opening the PDF. No public exploit identified at time of analysis, and the issue is fixed in the vendor's 6.19.0 release, so this should be treated as a bounded availability bug rather than a critical priority.
Denial of service in pypdf versions prior to 6.19.0 allows remote, unauthenticated attackers to exhaust application CPU by supplying a crafted PDF whose AcroForm choice field carries a large number of options and selected values; when a consuming application calls update_page_form_field_values with flatten=True, the appearance-stream generator recomputes the same invariant selection-glyph set once per line, driving runtimes up until the host process or worker becomes unavailable. The flaw is rated CVSS 4.0 8.7 (and 3.1 8.1 by independent assessment) with availability-only impact - no confidentiality or integrity loss, and no code execution. Exploitation requires the application to explicitly perform form-field updates with flattening on attacker-controlled input; merely opening, parsing, or reading the PDF does not reach the vulnerable code path. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV); the fix ships in upstream release 6.19.0.
Denial of service in pypdf before 6.18.1 lets a crafted PDF drive the library's FlateDecode recovery path into inefficient byte-by-byte decompression, consuming CPU until the consuming application becomes unavailable. Exploitation is unauthenticated and requires only that a pypdf-based service parse or extract text from an attacker-supplied PDF (CVSS v4.0 8.7, AV:N/AC:L/PR:N/UI:N, availability-only); no public exploit identified at time of analysis. The flaw is a residual case left after the earlier malformed-FlateDecode recovery fix and is resolved in 6.18.1.
Memory exhaustion in pypdf versions prior to 6.18.1 lets a crafted PDF force the library to allocate and process far more font-width data than a simple font can legitimately hold, degrading or crashing any process that extracts text or font metrics from untrusted documents. The parser fails to cap the /Widths array of a simple TrueType or Type1 font at the 256 one-byte character codes that such fonts can actually address, so an oversized array is walked entry by entry while widths are collected. The CVSS 4.0 vector (8.7, AV:N/AC:L/PR:N/UI:N, high availability-only impact) reflects unauthenticated remote triggering with no user interaction beyond supplying the file, and the availability-only profile confirms no confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV), though the trigger is trivially reproducible by anyone who can hand a PDF to a pypdf-consuming service; a vendor patch in 6.18.1 is available.
Memory exhaustion in pypdf versions prior to 6.18.1 allows unauthenticated remote attackers to crash or degrade any application that parses attacker-supplied PDFs, by embedding oversized source-code or destination-string tokens inside a font /ToUnicode CMap. Processing such a file (for example during text extraction, which routes through pypdf/_cmap.py parse_bfchar) makes the library decode and retain these oversized values, driving availability-impacting memory consumption with no confidentiality or integrity effect. The vendor CVSS 4.0 vector (8.7, VA:H only, PR:N/UI:N) matches the assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; no public exploit code or KEV-listed active exploitation was identified at time of analysis, and a vendor-released patch (6.18.1) is available.
Denial of service in pypdf versions prior to 6.18.0 allows remote, unauthenticated attackers to stall PDF parsing by supplying a crafted file whose indirect-object identifier or generation-number token continues for an excessive length without a whitespace delimiter. The parser's read_until_whitespace helper in pypdf/_utils.py scans unbounded input, so the consuming process hangs or runs for an extremely long time, making any service that parses untrusted PDFs unavailable (CVSS 4.0 8.7, availability-only; assessed CVSS 3.1 8.0 AV:N/AC:L/PR:N/UI:N/A:H). Impact is confined to availability - there is no path to code execution or data disclosure - and no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor-released fix is available in pypdf 6.18.0.
Memory-exhaustion denial of service in pypdf versions prior to 6.17.0 allows remote attackers to inflate application memory usage by supplying a crafted PDF whose /PageLabels /Nums dictionary declares a Roman-numeral numbering style (/S /R) with an extremely large start value (/St), causing the library to construct a numeral string proportional to that value. The CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VA:H) indicates an unauthenticated, network-reachable, low-complexity attack with high availability impact and no confidentiality or integrity effect, but the practical precondition is that the consuming application must actually invoke pypdf's page-label retrieval on attacker-supplied documents - applications that never read page labels are unaffected. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; the vendor released a fix in 6.17.0 that rejects Roman start values above 3,999.
Certificate hostname verification is silently skipped in CPython's TLS stack when an application enables SSLContext.check_hostname but supplies no server_hostname (None or an empty string) to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls(). In that exact state SSLObject still validates the certificate chain but never matches the peer's identity against the requested name, so an unauthenticated attacker holding a man-in-the-middle position on the connection path and a certificate chaining to a CA the client trusts can intercept traffic while the program believes hostname checking succeeded. Exploitation is gated by two independent conditions - the application-side misconfiguration and an active network-intercept position - no public exploit code has been identified at time of analysis, and applications that pass a valid non-empty server_hostname are completely unaffected regardless of patch status.
Unauthenticated remote code execution affects LightLLM through 1.2.0 when it is deployed in visual_only (multimodal/vision) mode, which exposes an RPyC inference service that performs no authentication and unpickles the arguments passed to its remote_infer_images method. Any attacker who can reach that visual RPyC port can send a crafted object whose __reduce__ method runs on the server, achieving code execution with the privileges of the LightLLM service account and resulting in high confidentiality, integrity, and availability impact (CVSS 4.0 base 9.3; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N with high C/I/A). Text-only LightLLM deployments do not expose the affected service, no public exploit code has been identified at time of analysis, and real-world exposure hinges on whether the visual RPyC port is bound to an untrusted-reachable interface rather than to localhost or an isolated network.
Command injection in the AiSOC actions service (AiSOC 7.2.0 up to, but excluding, 12.0.0) allows a low-privileged authenticated user to break out of quoted arguments in the file_path, path, script_name, or script_args parameters and execute arbitrary commands with SYSTEM/root privileges on CrowdStrike-managed endpoints. Exploitation requires that the deployment expose the actions service, that at least one CrowdStrike-managed endpoint is enrolled so a Real Time Response (RTR) session can be established, and that a mutating endpoint action (quarantine_file/rm, the automatic post-quarantine path_exists/ls probe, or a runscript path) is reachable with attacker-controlled input. No public exploit identified at time of analysis, and the practical weight of this flaw is tempered mainly by the small footprint of AiSOC deployments rather than by technical severity; note that the vendor's own fix commit documents that on default installs the dedicated actions-service token was never generated and its guard exempted itself while AISOC_DEV_MODE was enabled, so mutating routes could respond to anyone able to reach the port - materially lowering the authentication barrier described by the CVSS PR:L metric.
Authorization bypass in the MSSP (multi-tenant) module of AiSOC 10.0.0 through before 12.0.0 allows any authenticated user who already owns at least one portfolio to submit arbitrary tenant UUIDs to the add_tenants_to_portfolio endpoint and pull unclaimed tenants into their own portfolio without those tenants' consent. Once a victim tenant is claimed, the attacker can read its security alerts, incidents, and posture metrics, giving high confidentiality impact with limited integrity impact but no availability loss (assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N). Exploitation requires a valid account with portfolio ownership in an MSSP-enabled deployment and only works against tenants not already managed by another organisation; single-tenant installations are unaffected, and no public exploit code was identified at time of analysis.
Directory traversal in agent-zero 1.7 through 1.10 allows remote attackers to write files to arbitrary locations outside the intended file-browser directory via the save_file_b64 method, with the evaluated CVSS vector indicating PR:N/UI:N and high integrity impact according to the authoritative assessment. No CISA KEV listing was provided, and no public exploit identified at time of analysis; EPSS is 0.33% (24th percentile), and the supplied CVSS 3.1 score is 7.5, though the independent assessment shifts the impact from confidentiality to integrity (C:N/I:H/A:N) because exploitation concerns unauthorized file writes rather than reads.
Directory traversal in Agent Zero 1.7 through 1.10 lets the AI agent's file-browser component read files anywhere on the host, because FileBrowser is initialized with the host root as its workspace rather than a confined sandbox. The CVSS 3.1 vector is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), which models unauthenticated network access, but the practical risk is gated by whether the Agent Zero UI is exposed to untrusted networks; Agent Zero is often a local single-operator tool, so the AV:N/PR:N rating only applies when that interface is deliberately reachable without an authentication layer. At time of analysis there is no confirmed active exploitation (no CISA KEV entry) and no public exploit identified at time of analysis, and EPSS is 0.33% (24th percentile), indicating low predicted exploitation activity; reference material consists of a GitHub issue and a gist.
Code execution in camel-ai's CodeExecutionToolkit (versions 0.2.91a1, 0.2.91a2, and 0.2.91a3) lets remote, unauthenticated attackers run arbitrary Python through the SubprocessInterpreter with no approval or confirmation boundary. The attacker must be able to influence the agent's model output - for example via prompt or task injection - so that the LLM emits executable Python, and the host application must have opted into the code-execution toolkit and routed untrusted input to it; exposure is therefore conditional rather than default, which is reflected in the independent assessment's High attack complexity (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) versus the vendor's 9.8 AV:N/AC:L rating. Risk weighting is tempered by a low EPSS of 0.22% (11th percentile), no CISA KEV listing, and no vendor-released patch identified at time of analysis, though a public GitHub issue and a third-party gist describing the flaw are referenced.
Remote code execution in AgentScope 1.0.18 and 1.0.19 allows remote attackers to execute arbitrary Python in the service environment: when a RealtimeAgent session has execute_python_code registered as an available tool, the agent's _acting path forwards a model-produced tool call straight to Toolkit.call_tool_function with no approval prompt and no sandbox boundary, so a remote WebSocket user who can reach the endpoint and steer the agent can obtain code execution with the service's privileges. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) no authentication is required, and the SSVC assessment records that publicly available exploit code exists (exploitation: poc), so the vulnerability is automatable with total technical impact; EPSS is low at 0.20% (9th percentile), indicating limited observed exploitation activity so far. Exploitation is conditional on the deployment exposing the execute_python_code tool in a RealtimeAgent session and on the WebSocket interface being network-reachable - instances that do not register that tool are not vulnerable via this path.
Directory traversal in Bisheng 2.3.0, 2.4.0, and 2.4.0-beta1 lets a remote attacker use crafted filename/path input to break out of the intended download/cache directory through the save_download_file routine (src/backend/bisheng/core/cache/utils.py:290), yielding arbitrary file read and write with a CVSS 3.1 base score of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). The vector indicates an unauthenticated, network-reachable attack with no user interaction, though the practical limiting factor is whether the API route that reaches save_download_file is exposed without a login - defenders should verify that against their own deployment before assuming unauthenticated reachability. Exploitation status: no public exploit identified at time of analysis, and there is no CISA KEV entry; EPSS is 0.33% (24th percentile), so mass exploitation is not currently expected, but the impact per successful attack is severe given the high confidentiality and integrity ratings and the absence of any availability impact.
Memory exhaustion in LightLLM through 1.2.0 lets unauthenticated remote attackers crash KV-transfer worker processes when the server is started with the non-default `--pd_trans_mode nccl` flag. Under that mode the NCCL-based prefill-decode control channel exposes a `set_value` method that stores caller-supplied key-value pairs with no size or count limit, so repeated calls consume worker memory until the process dies and the node fails. Impact is availability-only (CVSS 4.0 base 8.7, VA:H; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) with no data disclosure or modification; exploitation requires the opt-in NCCL transport mode plus network reachability to the control channel, and no public exploit has been identified at time of analysis.
Unauthenticated remote code execution affects ModelTC LightLLM through version 1.2.0 when it is run in a multimodal deployment configuration, which starts an embed-cache RPyC service bound to all network interfaces with pickle deserialization enabled. Because the service performs no authentication and accepts attacker-controlled serialized objects through its exposed cache methods, any remote party that can reach the RPyC port can execute arbitrary code with the privileges of the LightLLM service (CVSS 4.0 base score 9.3; AV:N/AC:L/AT:N/PR:N/UI:N with high confidentiality, integrity, and availability impact). Exposure is configuration-dependent: non-multimodal deployments do not start this service, and instances whose port is bound to loopback or blocked by firewall rules on the host or network are not remotely reachable. No public exploit code has been identified at time of analysis, and the issue has been reported publicly by VulnCheck (also tracked in the project's GitHub issue #1596), so the primary risk is rapid weaponization against internet-facing multimodal inference deployments that have not been patched or isolated.
Remote code execution in LightLLM through 1.2.0 allows unauthenticated attackers to run arbitrary code on the host when the server is launched with the --enable_profiling flag, because that flag starts a router profiler service that exposes an RPyC listener with pickle deserialization enabled and no authentication (CVSS 4.0 base 9.3; CWE-502). The flaw is not reachable in a default deployment since profiling must be explicitly enabled, but once it is on, any network-reachable attacker can push crafted serialized objects onto the profiler command queue and gain high-integrity, high-availability code execution without credentials or user interaction (PR:N/UI:N). There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, so exposure is currently driven by the non-default profiling configuration and network reachability of the RPyC port rather than by active exploitation.
Command injection in PyPA virtualenv before 21.7.12 allows an attacker who controls the environment's prompt value - via the --prompt argument, the VIRTUALENV_PROMPT environment variable, or the equivalent configuration setting - to run arbitrary cmd.exe commands on Windows with the privileges of the user who activates the generated environment. The flaw is confined to the batch activator: BatchActivator.quote() returns the prompt text unchanged, so a supplied double quote closes the `set "VAR=value"` assignment in activate.bat and any following cmd.exe operators are executed as live syntax when the victim runs the script. Coverage is limited by a local attack vector, Windows-only exposure, and mandatory victim interaction (generating and then activating the environment); no public exploit was identified at time of analysis, and a vendor fix is available in 21.7.12.
Argument injection in the Claude Agent SDK for Python (claude-agent-sdk) before 0.2.121 allows remote attackers to achieve arbitrary command execution when an embedding application passes untrusted input into the SDK's `resume` option. Because `--resume` is declared by the Claude CLI with an optional value, a session identifier beginning with `-` is parsed as a separate CLI flag rather than the option's value, letting an attacker inject `--mcp-config` and register a stdio MCP server that executes arbitrary commands at CLI startup while bypassing the SDK's permission controls. The assessed CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates no authentication is required but exploitation is high-complexity and conditional on the host application forwarding attacker-controlled data as the session ID; a vendor patch is available as version 0.2.121, and no public exploit code was identified at time of analysis.
Python code injection in SGLang 0.5.10 through 0.5.22 allows unauthenticated remote attackers to escape an eval() sandbox in the _evaluate_filter() helper and execute arbitrary Python in the scheduler process. Exploitation is strongly gated: the optional debug dumper server must be explicitly enabled by setting the DUMPER_SERVER_PORT environment variable, which is what exposes the unauthenticated /dumper/configure endpoint; default deployments do not enable it. Once the endpoint is reachable, a crafted filter expression is stored and runs on the next forward pass, giving full code execution with high confidentiality, integrity, and availability impact; no vendor-released patch has been identified at time of analysis, and no public exploit code was identified at time of analysis.
Absolute plot names passed to MatplotlibDataset.save() in kedro-datasets 9.3.0 through 9.6.0 let an authenticated user with the ability to influence plot-name keys write files outside the configured dataset directory, overwriting or creating files anywhere the Kedro process has write access. The flaw is rooted in validate_sub_path(), which strips leading slashes before validation, combined with pathlib join semantics that discard the base path whenever the supplied sub-path is absolute (POSIX '/outside.png', Windows 'C:\\outside.png', or UNC '\\\\server\\share\\outside.png'). Integrity impact is rated High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; CVSS 4.0 base 7.1), no public exploit code has been identified at time of analysis, and no CISA KEV entry exists; exploitability is gated by the attacker's ability to inject the plot-name keys (e.g., through untrusted input data or catalog configuration) and by the write permissions of the process running Kedro.
Authentication bypass in the joserfc Python library before 1.7.4 lets remote, unauthenticated attackers submit a JWS General JSON Serialization whose "signatures" array is empty and have joserfc.jws.deserialize_json() accept it as authenticated, so relying applications can be fooled into treating an arbitrary attacker-chosen payload as a signed, trustworthy message. Exposure is scoped: only the General JSON Serialization code path is affected - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing do not reach the vulnerable logic - but where the vulnerable API is used and its success is treated as proof of authenticity, the integrity impact is high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N per the independent assessment; the published base score is 9.1). No public exploit code or confirmed active exploitation has been identified at time of analysis; the fix commit, tests, and security advisory are publicly available.
Arbitrary file overwrite in HPE NonStop Python 3.x lets an attacker who supplies a crafted TAR archive escape the intended extraction directory via .. (dot-dot) sequences in member filenames and clobber files on the NonStop host, with the overwritten data potentially leading to code execution or system compromise depending on the privileges of the extracting process. The vendor rates this 8.0 (CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), while our independent assessment scores it lower at CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H, treating it as local rather than adjacent-vector and integrity/availability-only; unauthenticated access is implied by PR:N in both vectors, but successful exploitation is not automatic - it requires the victim to extract an attacker-controlled archive (UI:R), and the write primitive is bounded by the privileges of the extracting account. No public exploit code was identified at time of analysis, there is no CISA KEV entry, and no EPSS score was supplied, so real-world risk is moderated by the mandatory user interaction rather than by the headline score.
Arbitrary file read in GitPython before 3.2.0 occurs when a vulnerable application clones an attacker-controlled repository and then calls Head.checkout() on the repository's default branch; a branch named like --pathspec-from-file=<path> is parsed by Git as an option rather than a branch, causing readable file contents to be leaked through GitCommandError messages. This is a credible but conditional information-disclosure flaw, not a drop-everything emergency: only confidentiality is affected, exploitation requires the target to process untrusted repositories and surface error output, and no public exploit identified at time of analysis. Unauthenticated network exploitation is possible per the PR:N vector, and the vendor patch is GitPython 3.2.0.
Regular expression denial of service in GitPython before 3.2.0 allows remote, unauthenticated attackers to exhaust CPU on applications that parse Git commit or tag objects taken from an attacker-controlled repository. The flaw is in the _re_actor_epoch pattern used by parse_actor_and_date on author, committer, and tagger lines, which slips into quadratic backtracking when those lines are padded with long space-filled sequences that lack a valid epoch or timezone. Impact is strictly availability (CVSS 4.0 VA:H with VC:N/VI:N) - there is no confidentiality or integrity exposure, so the 8.7 High score reflects CPU exhaustion only, not code execution or data compromise; no public exploit identified at time of analysis.
Information disclosure in GitPython before 3.2.0 lets attackers leak environment-variable secrets through crafted submodule names in a repository's .gitmodules file. The flaw occurs when Repo._clone() calls Git.polish_url() without expand_vars=False, so variable syntax in a submodule name is expanded during clone plus submodule_update and the resulting values surface in .git/modules directory names and DEBUG logs. Exploitation is unauthenticated per the CVSS vector (PR:N) but requires the victim to clone an attacker-supplied repository and invoke submodule handling, and leakage only materializes if sensitive values are present in the process environment; no public exploit code, CISA KEV entry, or EPSS score was identified in the provided data, and integrity and availability are unaffected (CVSS 4.0 base 7.1, moderate severity).
Arbitrary file access and operating-system command execution in Stirling-PDF prior to 2.13.2 are reachable by an authenticated administrator who uploads a crafted SQL file to POST /api/v1/database/import-database on instances running the default H2 database backend with security mode enabled. DatabaseService.validateSqlContent() splits the normalized input on semicolons and accepts a statement if it merely contains an allowed keyword, so dangerous H2 constructs such as FILE_READ, CSVWRITE and CREATE ALIAS slip past the whitelist and execute when RUNSCRIPT processes the import; the demonstrated chain writes attacker-controlled startup files to a user-site location and triggers the application's Python interpreter to load them, yielding command execution as the JVM service account. The CVSS 3.1 base score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) reflects network reachability with full confidentiality, integrity and availability impact and a scope change, but PR:H means the attacker must already hold administrative privileges and non-H2 deployments are unaffected; no public exploit code identified at time of analysis, and the issue is fixed in version 2.13.2.
Arbitrary filesystem write in Ludwig versions prior to 0.17.8: the dataset archive extraction routine (ludwig.datasets.archives.extract_archive) validates tar member names but never validates symlink or hard-link members, so a crafted archive can create a link that escapes the extraction directory and then write a later member through that link, placing attacker-controlled content at an arbitrary path with the extracting process's privileges. The same name check relied on os.path.commonprefix, a character-based comparison that also lets a sibling path sharing the destination's character prefix pass. Exploitation requires the victim to load a dataset whose configured archive URL points at an attacker-controlled or attacker-compromised tar file (CVSS 3.1: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H - unauthenticated from the network, but mandatory user interaction), and is limited to Python 3.12 and 3.13 runtimes because Python 3.14's default tar 'data' filter already rejects escaping links; no public exploit code or confirmed active exploitation was identified at time of analysis.
Unbounded HTTP request-body buffering in the Model Context Protocol Python SDK (the 'mcp' package) before 1.29.1 and in 2.0.0a1 through 2.0.1 allows unauthenticated remote attackers who can reach an exposed HTTP transport endpoint to exhaust server memory and potentially terminate the process. The Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes read complete request bodies without any maximum-size check, so a single large declared or streamed body can consume multiple times its own size in process memory and repeated requests can drive sustained memory pressure. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) the impact is availability-only, and no public exploit code was identified at time of analysis; stdio-only servers and deployments behind an effective upstream request-size limit are not affected. This is a genuine but bounded-priority availability issue - the fix is a vendor-released patch in 1.29.1 and 2.1.0 that enforces a 4 MiB default body cap and returns HTTP 413, and the primary residual exposure is default HTTP deployments with no reverse-proxy or gateway body limit.
Account pre-hijacking in the Prowler API (5.4.0 up to but not including 5.35.0) lets an unauthenticated remote attacker gain persistent control of a user account that has not yet registered, by self-registering the victim's email address before the real owner ever signs up or links single sign-on. Because social account linking in ProwlerSocialAccountAdapter.pre_social_login() matches a Google or GitHub login to any existing local account with the same email address without requiring the address to be verified by the provider or on the local account, the genuine owner's later social sign-in is silently connected to the attacker's pre-created account, and the attacker's original password remains valid, exposing cloud provider credentials, scan findings and tenant memberships held in that account. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, though exploitation requires only open self-registration plus a victim who later authenticates through Google or GitHub (a race condition that closes once the legitimate owner has an account). The source assigns CVSS 4.0 7.6 (HIGH); our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N.
mise (a polyglot dev tool manager for node, python, cmake, terraform, and others) before version 2026.7.14 lets a malicious local project inject interpreter arguments through an untrusted .mise.toml [settings] file, causing attacker-chosen commands to execute with the developer's privileges. In default non-safe mode, mise applies local project settings before trust approval, and the unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args, and windows_default_inline_shell_args fields were missing the global_only marker, so they survived strip_local_only_settings. When a developer later runs a trusted task, postinstall directive, template exec, or hook that has no explicit shell, mise appends the legitimate command after the attacker-controlled interpreter arguments, and the attacker's command runs first despite the config never being trusted. Exploitation is local and requires user interaction (the victim must clone/open and run the affected task); there is no public exploit code and no confirmed active exploitation at time of analysis, and this is best characterized as a conditional local-escalation risk rather than a mass-exploitation threat. Fixed in 2026.7.14.
OS command injection in the thumbnail Python package through version 1.5 allows attackers who control a filename passed to generate_thumbnail() to execute arbitrary shell commands with the privileges of the Python process. The vulnerable code concatenates user-influenced values (input, output, width, height, quality, trim) directly into os.system() calls invoking ffmpeg, convert or unoconv, so shell metacharacters such as ';', backticks or $(...) in a filename break out of the intended command. The package is a library with no network listener of its own, so real-world reachability depends on the consuming application exposing untrusted filenames - classically a file-upload feature - and on ffmpeg/convert/unoconv being installed for the relevant code branch; where those conditions hold, no authentication or user interaction beyond submitting the malicious filename is required. An upstream fix exists in pull request #9, and no public exploit code has been identified at time of analysis.
OS command injection in xhtml2pdf before 0.2.19 lets an attacker execute arbitrary OS commands as the invoking user when the pisa command-line tool is run with the -s/--start-viewer option against a file whose name contains a double quote plus shell metacharacters. The flaw lives in pisa.startViewer(), which interpolates an unescaped filename into os.system('open "%s"'); because the vulnerable path is only reached in viewer-launch mode, the default programmatic HTML-to-PDF conversion API is not affected. The vector is local and requires a user (or job) to actually launch the viewer, and no public exploit code has been identified at time of analysis - confirmed actively exploited status is not present in the available data.
OS command injection in the Python library pypdftk (through version 0.5) lets attackers who control the pdf_path or out_file arguments of fill_form(), dump_data_fields(), or pdftk_cmd_util() execute arbitrary operating-system commands with the privileges of the hosting Python process. The three functions concatenate caller-supplied paths into a command string using '%s' formatting and pass it to subprocess.Popen with shell=True, so shell metacharacters embedded in a filename or path are interpreted by the shell rather than treated as literal arguments. CVSS v4.0 scores the flaw 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N), and the independent assessment concurs with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, but real-world reachability is bounded by the calling application - pypdftk is a library, not a network service, so exploitation requires the embedding application to forward untrusted input into those parameters, and no public exploit code has been identified at time of analysis. No CISA KEV entry exists for this CVE, and a source-level fix is available from upstream via pull request 57, which replaces string command construction with argument lists.
Privilege escalation in Red Hat OpenShift Container Platform 4's insights-runtime-extractor DaemonSet lets an authenticated low-privileged tenant who can schedule a pod on a node run attacker-controlled code as root in the host user namespace. The extractor scanner enters the workload's namespaces and executes the workload's argv[0] via exec.Command after only seteuid() has changed, leaving real/saved UID 0 and retaining capabilities; a malicious pod binary matching node, python, python3, MainThread, or any path containing java can call setuid(0) and reach the host CRI-O socket from the inherited cwd. CVSS 8.8 (AV:L/PR:L/S:C) reflects local, non-network exploitation requiring workload scheduling, and no public exploit was identified at time of analysis.
Unauthenticated remote code execution in Xorbits Xoscar through 0.11.2 lets any attacker who can reach the actor-pool TCP channel run arbitrary code as the server process, because the receive path hands raw network bytes straight to cloudpickle.loads() before the message type is validated. The CVSS 4.0 vector (AV:N/PR:N/UI:N, 9.3) confirms the bug is remotely reachable and requires no credentials or user interaction, so any deployment exposing an actor pool on a routable interface is exposed at default configuration; impact is worst where the process runs as root, typical of GPU-node deployments. No public exploit code or confirmed active exploitation was identified at time of analysis, and the exposure is bounded by network reachability - installations that bind the actor-pool port to localhost or keep it on an isolated segment are not remotely exploitable.
Local privilege escalation affecting Microsoft Windows builds that ship the vulnerable Python component allows an authenticated, low-privileged local user to elevate to SYSTEM-level rights, resulting in full loss of confidentiality, integrity, and availability on the host (CVSS 7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The flaw is not remotely exploitable and requires a pre-existing foothold or valid local account on an unpatched build, with no user interaction needed once that access exists; there is no public exploit identified at time of analysis and no CISA KEV entry, so exploitation is currently a post-compromise escalation concern rather than a remote mass-exploitation risk. Patches are available from Microsoft for all listed Windows 10, Windows 11, and Windows Server builds, and systems at or above the fixed build numbers (for example Windows 11 24H2 at 10.0.26100.9711 or Windows Server 2022 at 10.0.20348.5761) are not exposed.
Code injection in dataclasses-avroschema versions 0.38.0 through 0.70.5 lets an attacker who controls the Avro schema consumed by the library's model-generator classes inject arbitrary statements into the generated Python source, because enum symbols are used as generated enum member names after case conversion without being validated as Python identifiers. Exploitation is not on the library's default runtime serialization path: it requires an application to invoke the generator classes directly (BaseGenerator.parse_enum / EnumRepresentation.render_symbols) on an attacker-supplied schema and then import or execute the emitted module, which is why the assessed vector carries UI:R despite being network-reachable and unauthenticated (PR:N). Impact when the chain is completed is code execution and namespace modification in the importing process with high confidentiality, integrity, and availability consequences (CVSS 8.8); no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis. Version 0.70.6 fixes the issue by validating every enum symbol as a name.
Arbitrary code execution in dataclasses-avroschema versions 0.38.0 through 0.70.5, where BaseGenerator.parse_fixed writes a fixed type's 'aliases' value straight into the generated types.confixed annotation: a bare string alias (instead of a JSON list) is emitted as an unquoted Python expression and evaluated the moment the generated module is imported. Exploitation is not automatic - it requires a developer to run the library's Avro-schema-to-Python code generation over an attacker-influenced schema and then import the resulting module, which is why the vector carries UI:R despite PR:N and network-level delivery of the malicious schema. The flaw is a genuine CWE-94 code-injection issue with high confidentiality, integrity and availability impact under our assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; no public exploit code has been identified at time of analysis and it is not in CISA KEV. Version 0.70.6 fixes it by rejecting any 'aliases' value that is not a list.
Code injection in dataclasses-avroschema 0.38.0 through 0.70.5 allows an attacker who supplies a crafted Avro schema to the library's Avro-to-Python code generator (model_generator) to embed arbitrary Python statements into the generated module via an enum field default, and those statements execute when the generated module is imported, either modifying the module namespace or preventing it from loading (CVSS 3.1 8.8, CWE-94). The CVSS vector (AV:N/AC:L/PR:N/UI:R) indicates the flaw is unauthenticated but requires user interaction: a victim must run the generator against the attacker-controlled schema and then import the resulting module, so environments that only generate code from their own trusted models or never load attacker-influenced generated code are not exposed. The maintainer confirmed and patched the issue in 0.70.6 by validating enum defaults as names; no public exploit code has been identified at time of analysis, and no active exploitation is confirmed (CISA KEV) at the time of writing.
Python code injection in dataclasses-avroschema versions 0.38.0 through 0.70.5 lets an attacker with control over Avro schema content smuggle arbitrary Python statements into the enum class body that the library emits, so simply importing the generated module executes the attacker's code. The flaw sits in EnumRepresentation.render_symbols, which wraps each schema-supplied enum symbol in double quotes without escaping it, allowing a quote character to close the literal and append attacker-chosen Python. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8, CWE-94) indicates no privileges are required but that user interaction is essential, since the victim must run the import of the generated file; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, and version 0.70.6 fixes it by escaping enum symbol values before rendering.
Arbitrary Python code execution in dataclasses-avroschema versions 0.44.0 through 0.70.5 occurs because the Pydantic and AvroDantic model generators embed an Avro schema field's pydantic-class value directly into a generated field annotation after the literal prefix 'pydantic.', without sanitizing the expression. When a victim runs the code-generation path (ModelGenerator) on an attacker-influenced schema and then imports the generated Python module, the injected annotation is evaluated at import time and the payload executes with the privileges of that process, giving full confidentiality and integrity impact (CVSS 8.8, AV:C:N/AC:L/PR:N/UI:R). Exploitation is unauthenticated from the network perspective (CVSS PR:N) but requires the victim to generate and import the code, and no public exploit code or CISA KEV entry was identified at time of analysis; version 0.70.6 restricts the value to a bare name or a call to a bare name with literal arguments.
Arbitrary Python code execution is possible in dataclasses-avroschema versions 0.65.9 through 0.70.5 when the library's Pydantic or AvroDantic model-generation path is run over an Avro schema the attacker controls: the schema field's 'doc' value is interpolated unescaped between the quotes of a generated pydantic.Field(description="...") argument, so a crafted quote can close the string and inject a Python expression that is evaluated when the generated class is defined (CWE-94). The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (8.8), reflecting high confidentiality and integrity impact with user interaction required because a developer or build process must actively generate models from the malicious schema; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, and urgency is further moderated because only the Pydantic/AvroDantic generators are affected and only versions 0.65.9-0.70.5 are vulnerable.
Code injection in dataclasses-avroschema 0.38.0 through 0.70.5 lets an attacker-influenced Avro schema execute arbitrary Python when the library's model generator renders a 'fixed' type's namespace into generated source. BaseGenerator.parse_fixed interpolates the namespace between quotes inside a generated types.confixed annotation without escaping, so a namespace containing a quote character terminates the string literal and turns the remainder into live Python that runs when the generated class is defined or the generated module is imported; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (8.8), unauthenticated over the network but requiring the victim to run code generation on the crafted schema and then import the result. The flaw is fixed in 0.70.6, which enforces that namespaces are dot-separated sequences of valid Avro names; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, but the high CVSS score, confirmed GHSA-h9q3-f96w-f88j advisory, and availability of a vendor fix commit make prompt upgrading advisable for anyone generating code from externally sourced schemas.
Code injection in dataclasses-avroschema versions 0.40.0 through 0.70.5 lets an attacker who controls the `doc` value of an Avro schema record close the generated class docstring and inject arbitrary Python statements into the emitted class body, achieving code execution when the generated module is imported. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) rates the flaw as network-reachable, low-complexity and unauthenticated with high confidentiality and integrity impact, but exploitation is gated by user interaction: a developer or CI pipeline must both run the library's model generator against the attacker-influenced schema and import the resulting Python file. No public exploit code has been identified at time of analysis, and the vendor released a fix in 0.70.6.
Code injection in dataclasses-avroschema 0.62.3 through 0.70.5 allows an attacker-supplied Avro record name to break out of the quoted Meta.schema_name string literal and inject arbitrary Python statements into the generated model's class body, which then execute when that generated module is imported. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R) means no authentication is required but a victim must run the Avro-to-Python code generator on an untrusted or tainted schema and subsequently import the generated file; generating Avro schemas from trusted local dataclasses does not trigger it. Vendor-released patch: 0.70.6. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV entry).
Code injection in dataclasses-avroschema versions 0.38.0 through 0.70.5 allows remote, unauthenticated attackers who supply a crafted Avro schema to inject constrained Python statements into the module produced by the schema-to-code generator; the injected code executes when that generated module is imported. Exploitation requires the victim to deliberately process an untrusted schema through the avro-to-code path and then import the resulting module (the UI:R gate), which limits exposure to pipelines that ingest third-party schemas. CVSS 3.1 base score is 8.8 (High) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; no public exploit identified at time of analysis, and version 0.70.6 fixes the flaw by validating enum defaults as names.
Arbitrary code execution in dataclasses-avroschema 0.38.0 through 0.70.5 occurs when the library's Avro-to-Python model generator processes a schema containing a fixed type whose 'aliases' value is a bare string instead of a list; the value is interpolated unquoted into a generated 'types.confixed' annotation and evaluated when the generated module is imported, giving an attacker code execution in the victim's Python process. Exploitation is unauthenticated from the network perspective (CVSS:3.1/AV:N/AC:L/PR:N/UI:R) but gated on victim interaction: someone must run the schema-to-code generation path on attacker-controlled schema content and then import the resulting module. There is no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV), so this is a high-severity but precondition-gated code-injection flaw; the vendor released 0.70.6, which rejects non-list aliases.
Authenticated users with workflow create/edit rights on self-hosted Heym deployments prior to 0.0.40 can escape the application's blacklist-based Python sandbox and execute arbitrary commands and file operations as the backend service account. The flaw lives in backend/app/services/python_tool_executor.py, where the allowlisted standard-library modules still expose OS, process, and filesystem primitives through public attributes, so tool source that passes _safe_import() and _validate_code_safety() is ultimately run through exec() with full application privileges (CVSS 8.8, CWE-78). Exploitation requires a low-privilege authenticated account (PR:L) with permission to create or edit a workflow containing an Agent custom Python tool; enabling self-registration makes that account trivially obtainable, though merely triggering a workflow from the portal does not grant code control. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), but the fix in 0.0.40 is available and the assessed risk is high for any multi-user deployment.
Server-side request forgery in the SAP Cloud SDK for Python lets remote, unauthenticated attackers redirect OAuth2 token requests to a server they control by manipulating the tenant_subdomain value used to build the token endpoint URL, resulting in exfiltration of the application's OAuth2 client credentials. Exposure is limited to multi-tenant SAP BTP applications that use the SDK for OAuth2 token acquisition and allow attacker influence over the tenant_subdomain input; single-tenant deployments, or those that do not derive the token URL from attacker-supplied data, are not exposed. The vulnerability carries a maximum-severity score of CVSS 10.0, and no public exploit code was identified at time of analysis; no confirmed actively exploited (CISA KEV) status applies.
Information disclosure in Open WebUI 0.11.0 through 0.11.3 allows an authenticated non-admin user who holds the tool export permission to retrieve the complete Python source code of tools shared with them in read-only mode by calling GET /api/v1/tools/export, exposing any API keys or credentials embedded in that source. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the impact is bounded by three prerequisites: a valid account, the specific tool export permission, and the presence of read-only shared tools that actually contain secrets. The issue is rated CVSS 4.0 7.1 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) and is fixed in 0.11.4.
Server-side template injection in Wizarr before 2026.9.1 allows an authenticated user with privileges to create or edit wizard steps - or an administrator who imports an attacker-supplied wizard bundle - to execute arbitrary Python in the context of the application process. Because the stored step Markdown is compiled by the application's non-sandboxed Jinja2 environment with application globals exposed, successful exploitation can run operating-system commands as the application user, disclose the Flask SECRET_KEY, reach connected media-server service credentials and the database, and inject stored cross-site scripting into pages rendered at GET /wizard/{server}/{idx}. The issue is rated 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) and is fixed in 2026.9.1; no public exploit code was identified at the time of analysis, and the PR:H prerequisite narrows the realistic attacker population to trusted-but-malicious insiders or admins socially engineered into importing a hostile bundle.
Authenticated low-privilege tenant users of iFlytek Astron Agent prior to 1.1.2 can run arbitrary Python as root inside the core-workflow container by submitting a workflow Code node, because the shipped default configuration routes dynamic code execution to an unsandboxed LocalExecutor that exposes the full set of Python builtins. From that foothold the attacker can read shared service and database credentials and use them to bypass application-level tenant checks, read or modify other tenants' data, and disrupt shared services (CVSS 9.9, scope-changed, CWE-95). Exploitation requires a valid tenant account plus the ability to create or run a workflow containing a Code node; no public exploit identified at time of analysis, and the vendor-released patch is version 1.1.2.
Processing an attacker-controlled Protobuf schema with datamodel-code-generator 0.59.0 through 0.80.0 lets a crafted weak-import path escape the `__weak_imports__` temporary directory, creating directory trees and new files, or overwriting existing files that are writable by the running process (assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N; the vendor-reported vector is 7.5 with a higher integrity rating). Exploitation requires a victim or automated CI job to invoke the tool with `--input-file-type protobuf` on a malicious .proto supplied locally via `--input` or remotely via `--url`, and the grpcio-tools package must be installed to enable Protobuf input support; the payload is limited to a `syntax = "proto2";` or `syntax = "proto3";` declaration, so fully attacker-controlled content and direct arbitrary code execution have not been demonstrated. No active exploitation is confirmed (not in CISA KEV), though the upstream GitHub advisory carries a proof-of-concept and technical write-up, and the fix ships in version 0.81.0.
Cross-site request forgery in the CISA Malcolm network traffic analysis platform lets a remote attacker who lures the operator into loading attacker-controlled web content force that operator's browser to fire unauthenticated management commands at the kiosk's POST /script_call/<script> endpoint. Successful abuse yields high integrity and availability impact (I:H/A:H) with no confidentiality impact (C:N), because the reachable commands are destructive rather than data-stealing - most notably control.py --wipe, which permanently deletes all captured network traffic and forensic logs, and control.py --stop, which blinds security monitoring. The endpoint ships with zero authentication and wildcard CORS (CORS(app)) in its default state, so no server-side misconfiguration is required; the only real barrier is inducing the specific operator to render a malicious page (UI:R). No public exploit code and no confirmed active exploitation were identified at time of analysis.
Cross-site request forgery in Pydantic AI's development web chat UI allows any website a developer happens to visit while `Agent.to_web()` or `clai web` is running to fire forged chat requests at the loopback-hosted server, causing the served agent to start a run and execute its tools with the privileges and credentials of the local process. The pre-patch `/api/chat` endpoint performed no Content-Type validation, so a malicious page can deliver a JSON body cross-origin using a CORS-safelisted content type (text/plain, multipart/form-data, application/x-www-form-urlencoded, or none at all) without triggering a preflight; binding the server to localhost - the default - provides no protection because a browser page can reach 127.0.0.1. Realized damage is bounded by the tools the agent exposes, and `requires_approval=True` does not help because the endpoint trusts approval decisions relayed by the client; exploitation is unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:L, 7.6) but requires the developer to browse an attacker-controlled page while the dev UI is running, and there is no public exploit code identified at time of analysis. Vendor-released patches are available in 1.107.4 and 2.28.0.
Concurrency slot exhaustion in Pydantic AI 2.10.0 through 2.52.x lets streamed model requests permanently occupy slots in a shared ConcurrencyLimiter, progressively starving later requests until a service that reuses one long-lived limiter can no longer make model calls - an availability-only denial of service (C:N/I:N/A:H) with no confidentiality or integrity impact. The issue is remotely reachable and unauthenticated (PR:N), but our independent assessment rates it AC:H rather than GitHub's AC:L because exploitation requires a specific deployment pattern: model requests wrapped in ConcurrencyLimitedModel (or covered by limit_model_concurrency) that share a single long-lived limiter across streamed responses; agent-level max_concurrency and all non-streaming model requests are explicitly unaffected, and a short-lived or per-request limiter never accumulates enough leaked slots to deadlock. Slots are leaked by early stream termination, cancellation, consumer exceptions, or even full stream_text() consumption with debounce_by=0.1, and the vendor-released fix in 2.53.0 is available; no public exploit code identified at time of analysis.
Python code injection in PraisonAI's deploy tooling (all versions up to and including 4.6.77) lets a high-privileged actor who controls the `agents_file` value break out of an f-string and execute arbitrary code on the host running the deploy command. The flaw is triggered at build/deploy time: the unsanitized value is interpolated into generated server or Dockerfile source in `deploy/api.py` and `deploy/docker.py`, written to disk, and then launched via `subprocess.Popen(['python', server_file])`, so the primary realistic exposure is CI/CD pipelines or shared build environments where `agents_file` originates from externally influenced configuration. The vendor advisory includes a proof-of-concept demonstrating the string-breakout payload and a fix is available in 4.6.78; no CISA KEV entry or other confirmation of active exploitation was present in the source data, and this is not a remotely reachable flaw in a default running service - exploitation requires the attacker to already be positioned to set or tamper with deploy-time input and for someone to invoke the deploy command.
Unauthenticated remote code execution in LMCache through 0.5.5 allows network-reachable attackers to execute arbitrary Python and operating-system commands as the LMCache process by posting scripts to the /run_script endpoint; the endpoint's existing __import__ guard is bypassed via the injected FastAPI app object, which exposes real builtins (CWE-306, CVSS 9.3 v4.0 / 3.1 AV:N/AC:L/PR:N/UI:N). No public exploit code or confirmed in-the-wild activity has been identified at time of analysis, though the vulnerability details and vendor advisory are public. The primary limiting factor is deployment exposure: exploitation requires the internal API HTTP server to be enabled and bound to a network-accessible interface rather than restricted to localhost or a trusted management network.
Authenticated remote code execution in the @backstage/plugin-techdocs-node package shipped with the Backstage developer portal framework allows a user who can register or influence an SCM-backed documentation source to execute arbitrary code on the TechDocs backend host. The flaw (CWE-502, CVSS 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) arises because mapping-style markdown_extensions entries in a committed mkdocs.yml were not sanitized, letting an attacker name Python callables such as subprocess:Popen or os:system that MkDocs then imports and instantiates during documentation generation. Exploitation requires a valid account and an instance that performs server-side TechDocs generation of attacker-controlled sources, so risk is highest where generation runs with backend credentials, filesystem access, or internal network reachability; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Cross-tenant information disclosure in wger allows an authenticated trainer account that holds both the gym.gym_trainer and gym.add_adminusernote permissions but has no gym assignment (userprofile.gym = None) to read private admin notes, uploaded documents, gym contracts, user configuration and permission data belonging to any other unassigned (gym = None) user on the same instance. The root cause is an authorization guard that fails open: the five affected views compare gym objects with the Python operator '!=', and 'None != None' evaluates to False, so HttpResponseForbidden is never reached and the following queryset is filtered only by the attacker-supplied member_id. Rated CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, authenticated, low privilege), the bug is amplified because gym = None is the default state for newly registered users, so any instance with public registration plus delegated trainer permissions is exposed; a detailed proof-of-concept is documented in the published GitHub advisory and the permission-edit endpoint is also reachable, giving a possible privilege-escalation path, though no confirmed in-the-wild exploitation has been reported.
Arbitrary code execution in AWS Bedrock AgentCore Starter Toolkit before 0.3.14 allows an authenticated same-account actor to inject malicious Python code into generated agent source by importing a crafted Bedrock Agent configuration, which executes when the victim runs or deploys the agent. Exploitation requires the victim to import and then run or deploy the agent, and the actor must have valid same-account credentials. No public exploit identified at time of analysis; remediation requires upgrading to 0.3.14 and re-importing any previously affected agents because the generated source persists.
Hydra 1.3.4 through 1.3.5 and the 1.4.0.dev line prior to 1.4.0.dev9 can execute attacker-chosen code when an application runs Hydra's instantiate() on configuration an attacker can influence, because the callable blacklist added for CVE-2026-68508 is name-based and can be sidestepped via wrappers, aliases, dispatch helpers, or deferred invocation. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 7.8) indicates no attacker privileges are required but a victim application must actually instantiate untrusted or externally sourced config, which is why user interaction is scored; the flaw is CWE-184 (Incomplete List of Disallowed Inputs) and is best understood as an incomplete fix rather than a new class of bug. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, and vendor-released patches exist in Hydra 1.3.6 and 1.4.0.dev9. Applications that only ever instantiate developer-authored, trusted configuration are not exposed, and the vendor explicitly documents the blocklist as a best-effort defense-in-depth stopgap rather than a security boundary.
Code injection in the Hydra configuration framework (all releases prior to 1.3.6 and 1.4.0.dev9) lets an attacker who controls the application's Hydra logging configuration name an arbitrary importable class or factory that Hydra will then import and invoke with the application's own privileges. Hydra routes logging settings to Python's logging.config.dictConfig() without applying its own target policy, so the handler 'class' values and the formatter, filter, handler, queue and listener factories are resolved and called directly - this bypasses the _target_whitelist_ protection that otherwise guards instantiate(), meaning even hardened deployments are exposed. The assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8): a local, unprivileged attacker must plant malicious logging configuration (a config file, an override, or a shared/untrusted config source) and the victim must then run the Hydra application, yielding high confidentiality, integrity and availability impact; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but exploitation only requires that the victim execute the tampered configuration.
Configuration-controlled code execution in the hydra-optuna-sweeper package (Hydra 1.2.0 up to but not including 1.3.0, plus 1.4.0 development builds before 1.4.0.dev10) allows an attacker who controls Optuna sweep configuration or command-line overrides to name an arbitrary importable Python callable in hydra.sweeper.custom_search_space that Hydra resolves and then invokes inside the controller process at the application's privilege level, including bypassing the trusted execution whitelist introduced on affected 1.4.0 development releases. The assessed CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8 High): delivery is local and unauthenticated, but a victim must actually launch the sweep, after which confidentiality, integrity, and availability impact is total for the affected process. Exploitation is only meaningful where sweep configuration or overrides cross a trust boundary; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Code execution with the hosting application's privileges is possible in Hydra 1.3.4 through versions before 1.3.7 (and before 1.4.0.dev10) when an attacker controls multiple sibling target entries in a configuration that the application passes to instantiate(). One sibling resolves hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard to delete a denied target from Hydra's process-global blocklist, and a later sibling - processed in insertion order against the same mutated policy - invokes the now-permitted callable; the mutation persists for the life of the process. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, 8.5) indicates no privileges are required and only passive user interaction, and no public exploit identified at time of analysis (not in CISA KEV, no POC referenced); exploitation is limited to deployments that feed untrusted configuration content to instantiate(), and a narrow execution whitelist supplied by trusted Python code is not bypassed by the reported direct mutation path.
Openapi-python-client before 0.29.1 fails to neutralize attacker-influenced content from an OpenAPI document when rendering string, docstring, and f-string contexts, so a malicious or untrusted specification can cause arbitrary Python to be emitted into the generated client - code that then executes when that client is imported, compromising the integrity of the importing environment and potentially its confidentiality and availability. Exposure is conditional: it requires someone to generate a client from a spec they do not fully control (a third-party, public, or otherwise untrusted API definition) and then import the generated code, which is the trigger point, so organizations generating only from trusted internal specs are effectively unaffected. The flaw is rated 8.4 under CVSS 4.0 in the source data (independent assessment maps it to CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), which is consistent with a serious but conditionally triggered supply-chain and code-generation issue rather than a remotely reachable mass-exploitation vector. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has shipped a fix in version 0.29.1.
Denial of service in Scrapy 1.4.0 through 2.14.1 allows any web server the crawler visits to terminate the crawler process by returning a crafted Referrer-Policy response header, such as 'sys.exit', which the built-in RefererMiddleware treats as a Python import path and invokes. The flaw is reachable over the network without authentication or user interaction (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U, base 7.5 High), and its impact is limited to availability because only importable, zero-argument callables can be triggered, making realistic effect process termination rather than general arbitrary code execution. Any crawler left in its default configuration (RefererMiddleware enabled via REFERER_ENABLED=True) that fetches attacker-controlled pages is exposed; no public exploit identified at time of analysis, and the vendor-released patch is Scrapy 2.14.2.
Import-time code execution in Docling 2.27.0 through 2.131.0 lets any distribution already present in the same Python environment that registers an entry point in the 'docling' group run arbitrary code as soon as Docling's plugin factories initialize - even when allow_external_plugins is set to false, because the plugin manager imports every registered module before the namespace allow-list is applied and then misleadingly logs that the plugin was skipped. The assessed vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) confirms this is a local, supply-chain-style prerequisite: an attacker must first get a third-party or compromised package installed and registered, and Docling must then be started by a user, so there is no remote network exploitation path. No public exploit code or active exploitation is known at time of analysis (EPSS 0.11%, percentile 1%; CISA SSVC exploitation: none), and the vendor has shipped a fix in 2.131.0.
Unauthenticated remote attackers can forge Django-signed session cookies, CSRF tokens, and password-reset tokens, and bypass live-service authentication, against Plane installations that shipped with publicly known default secrets. Plane versions prior to 1.4.0 distributed fixed SECRET_KEY (60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5) and LIVE_SERVER_SECRET_KEY (htbqvBJAgpm9bzvf3r4urJer0ENReatceh) values in the deployments/aio/community/ and deployments/cli/community/ manifests, while the top-level setup.sh randomized secrets only for the development Docker Compose path, leaving AIO and CLI community deployments with shared production secrets by default. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, C/I/A:H) and classified CWE-798; no public exploit identified at time of analysis, although the default key values are published in the vendor repository and are therefore trivially usable by anyone who reads it. Exposure is limited to network-reachable instances deployed via those community manifests whose operators never overrode the secrets; deployments created through the development Compose path, operator-hardened installs with unique secrets, and instances upgraded to 1.4.0 are not exploitable.
Brute-forceable magic-code email login in Plane versions prior to 1.4.0 allows unauthenticated remote attackers to guess a six-digit numeric login code and take over accounts. The verify endpoint extends django.views.View instead of DRF's APIView, so the configured AnonRateThrottle never runs, and there is no per-code attempt counter, no counter invalidation, and no Django-level throttle middleware behind it, leaving roughly 20 bits of OTP entropy with effectively unlimited guesses inside the code's Redis TTL window. There is no public exploit identified at time of analysis and no confirmed active exploitation, but the 9.1 CVSS reflects a full account takeover path (C:H/I:H) with no authentication or user interaction required, and the fix was released in Plane 1.4.0.
Papermerge 3.5.3 permits an authenticated standard user to achieve remote code execution by uploading a crafted file to /api/documents/upload with directory-traversal sequences in the filename, causing a malicious Python .pth file to be written into the interpreter's site-packages directory; the embedded code executes only when the Python interpreter next starts, for example on an application or worker restart. Publicly available exploit code exists via a GitHub PoC repository and accompanying PDF, and the flaw is conditionally gated by requiring the Papermerge process to have write access to site-packages and by the attacker not controlling restart timing, making it a credible but conditionally-gated RCE rather than an immediately triggerable one.
Code injection in InternLM MindSearch 0.1.0 allows unauthenticated remote attackers to execute arbitrary code through the Planner Agent component, specifically by manipulating the inputs argument processed by ExecutionAction.run in mindsearch/agent/graph.py. The issue is rated critical (CVSS 9.3 per the CVSS 4.0 vector; the independent assessment likewise has PR:N/UI:N with high confidentiality, integrity, and availability impact), and publicly available exploit code exists. The vendor was contacted but did not respond, no vendor-released patch has been identified, and risk is concentrated in internet-reachable or otherwise accessible self-hosted MindSearch 0.1.0 deployments.
Incorrect authorization in the LangGraph Python SDK (langgraph-sdk) versions 0.1.45 through 0.4.3 lets an authenticated user read, update, or delete resources belonging to other users, because the resource-scoped decorators @auth.on.threads, @auth.on.assistants, and @auth.on.crons ignore their actions= argument and register the handler as a wildcard for every action on that resource. That wildcard handler is matched ahead of broader fallback handlers, so any action, ownership, or permission checks implemented in those fallbacks are silently skipped. The flaw is conditionally scoped: a deployment is only exposed if it uses these decorators together with actions= and relies on separate fallback handlers for enforcement, and authentication requirements are confirmed as authenticated (CVSS PR:L) with no public exploit identified at time of analysis. This is fixed in langgraph-sdk 0.4.4.
Opening an attacker-controlled Kerchunk reference document with fsspec's ReferenceFileSystem can execute arbitrary Python code, because versions from 0.9.0 up to (but not including) 2026.6.0 render reference fields through unrestricted jinja2 templates instead of treating them as inert data. The vulnerability is exploitable by unauthenticated attackers but requires user interaction: the victim application - or a downstream consumer such as xarray - must actually open the malicious document, which can be supplied inline or fetched from an attacker-controlled URL, and the gen-array code path triggers with no special configuration at all. Rated CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, CWE-94), it is addressed by the vendor's 2026.6.0 release, which makes jinja interpretation opt-in; no public exploit identified at time of analysis.
Uncontrolled resource allocation in Apache Thrift versions before 0.25.0 allows remote unauthenticated attackers to exhaust memory, CPU, or worker/connection capacity in services built on the C++, Java, Go, netstd, Python, and Delphi bindings (CWE-770), disrupting availability. The impact is availability-only - no confidentiality or integrity loss - rated CVSS 8.2 under CVSS 4.0, with the 4.0 AT:P flag and the independent CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both indicating a specific condition must hold for the allocation to trigger, so exploitation is not guaranteed against every message or deployment. No public exploit code and no CISA KEV listing were identified at time of analysis; upgrading to 0.25.0 removes the condition entirely.
Stack exhaustion in Apache Thrift before 0.25.0 allows remote, unauthenticated attackers to crash processes that deserialize attacker-controlled Thrift messages, because the protocol skip routine in several language bindings fails to apply the binding's recursion limit when skipping unknown fields. The affected bindings are the Python C++ accelerator (the pure-Python protocols are not affected), the PHP library and its thrift_protocol extension, and the Perl, Lua, Smalltalk and OCaml libraries; the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms the bug is reachable over the network with no privileges or user interaction, but the impact metrics (VC:N/VI:N/VA:H) restrict the consequence to availability loss. There is no code execution or data exposure, no public exploit code and no confirmed active exploitation at time of analysis, and Apache has released version 0.25.0 which restores the recursion limit.
Denial of service in Apache Thrift Python bindings before 0.25.0 allows unauthenticated remote attackers to hang the service by sending crafted Thrift messages that drive the parser into an infinite loop (CWE-835). Exploitation is network-based but requires a specific condition, such as a particular protocol/transport or malformed message structure, to trigger the loop (AT:P / AC:H). The impact is limited to availability-no data disclosure or code execution-and only services exposing a Thrift endpoint that processes untrusted input using the Python bindings are affected; no public exploit code has been identified at time of analysis.
Denial of service in Apache Thrift before 0.25.0 allows unauthenticated remote attackers to crash or exhaust services running affected language bindings by sending malformed Thrift protocol data. The flaw combines improper length-parameter handling with excessive memory allocation, inefficient algorithmic complexity, uncaught exceptions, and insecure default initialization across the Python, Ruby, Erlang, Lua, Dart, JavaME, Perl, PHP, and D bindings. It is availability-only: no code execution, data disclosure, or data tampering is known from this issue. No public exploit code or confirmed active exploitation was identified at time of analysis; upgrading to 0.25.0 resolves it.
Denial of service in Apache Thrift's Python bindings (all versions before 0.25.0) allows remote, unauthenticated clients to force unbounded memory allocation by sending crafted messages that declare oversized containers or strings, crashing or hanging the affected service. The flaw pairs a missing resource limit with an insecure default configuration in which the bindings apply no read or container size cap unless the application explicitly sets one, so any network-reachable Thrift service that accepts untrusted traffic while running on those defaults is exposed. Impact is confined to availability with no confidentiality or integrity effect, and the CVSS 4.0 AT:P component reflects that a specific, not fully attacker-controlled deployment condition must be met; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Code injection in Vanna 2.0.2's VannaBase.get_plotly_figure presents conflicting signals that must be weighed carefully: the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8), yet EPSS is only 0.36% (27th percentile) and there is no CISA KEV entry, so no public exploit identified at time of analysis. In CVSS terms this is an unauthenticated remote issue, but the governing exploitation condition is that a deploying application exposes vanna's figure/plot-generation entry to attacker-influenced input; where the plotting path is exposed via bundled Flask/Streamlit/API front ends, an attacker who can shape the question or prompt can achieve attacker-controlled code or command execution, while embedded deployments that gate, authenticate, or do not expose that path are substantially less exposed than the 9.8 score implies.
Denial of service in Amazon Ion Python before 0.15.0 allows remote, unauthenticated attackers to crash applications that parse attacker-supplied Ion data by submitting a deeply nested Ion value that exhausts the interpreter's recursion stack. The flaw is availability-only (CWE-674 uncontrolled recursion) and requires the target service to route untrusted Ion input into the Ion reader; applications that only parse trusted, internally generated Ion are not realistically exposed, and no authentication, user interaction, or non-default configuration is needed otherwise (PR:N/UI:N). No public exploit code was identified at time of analysis and there is no indication of confirmed active exploitation (not listed in CISA KEV); the vendor fix in 0.15.0 caps container nesting past the recursion limit and surfaces the condition as an IonException instead of an uncontrolled crash.
Improper TLS certificate validation in the Confluent Kafka Python client's HashiCorp Vault KMS integration (confluent-kafka versions 0 through 2.14.2) allows a man-in-the-middle attacker to obtain sensitive information when the integration is used with its default configuration, which disables certificate verification. Successful exploitation requires the application to use the Vault KMS integration and the attacker to achieve a MITM position on the TLS connection to Vault, making this a conditional but significant risk (CVSS 7.4). No public exploit has been identified at the time of analysis.
Poisoned OAuth/OIDC discovery metadata in Authlib 1.7.2 and earlier allows an attacker who controls or intercepts the metadata fetch to replace every cached endpoint - authorization, token, JWKS and userinfo URLs - with attacker-controlled values, enabling token theft, credential interception and authentication bypass in applications built on the library. Publicly available exploit code exists (SSVC exploitation: poc) and the flaw is rated fully automatable with total technical impact, although it is not listed in CISA KEV; EPSS is low at 0.10% (1st percentile). The supplied CVSS of 9.8 overstates realistic reachability versus our assessed 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), because exploitation requires a privileged network position on the discovery fetch or a compromised/malicious issuer endpoint, and TLS-validated metadata from a trusted issuer is not exploitable without first defeating that channel.
Unauthenticated local file disclosure in Tornado before 6.5.9 lets remote attackers read files outside a configured static root by requesting a symbolic link that lives inside that root but resolves elsewhere, exposing configuration files, private keys, and application secrets readable by the Tornado process user. Exploitation is a single GET request requiring no authentication and no user interaction (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N), but it depends on a precondition rather than being turnkey: an out-of-root symlink must already exist inside the static directory, a situation the upstream advisory says arises in applications serving user-uploadable content or where build/deploy pipelines (npm link, webpack, Docker volume mounts, CDN sync tools) create symlinks. The issue is fixed in 6.5.9, public reproduction steps are published in the upstream GitHub Security Advisory, and there is no CISA KEV listing.
Denial of service in the Tornado web framework's CurlAsyncHTTPClient (all releases before 6.5.9) lets an unauthenticated remote server OOM-kill the application process by answering a fetch with a gzip decompression bomb: libcurl decompresses the body before invoking the client's write callback, and Tornado appends the decoded bytes to an unbounded BytesIO with no post-decompression size check, so a few megabytes on the wire expand to gigabytes of resident memory. Exposure is genuinely conditional - the application must be explicitly configured to use CurlAsyncHTTPClient (via AsyncHTTPClient.configure), must leave decompress_response at its default True, and must fetch a URL the attacker controls or has compromised; the default SimpleAsyncHTTPClient is not affected because the size gates added for CVE-2026-49855 live in code the curl client never executes. The upstream GHSA advisory documents a verified end-to-end reproduction on master (6.6.dev1) and v6.5.8 where a ~2.8 MB gzip payload grew client RSS from roughly 31 MB to about 1,032 MB in 3.18 seconds (exit 137, cgroup OOMKilled=true); the only incidental ceiling before the patch was the default 20-second request_timeout. No public exploit code or active exploitation has been identified at time of analysis, and no CISA KEV listing applies.
Authenticated code injection in langflow-ai Langflow up to and including v1.9.3 lets any user holding a valid account execute arbitrary Python on the server by POSTing raw source to the /api/v1/validate/code endpoint, which feeds the input straight into a server-side compile/exec validation path without sandboxing or an entitlement check (CWE-94). The supplied CVSS score is 9.8 under a PR:N vector, but the authoritative assessment applies PR:L because exploitation requires a valid Langflow session, making authentication the primary limiting factor; impact on confidentiality, integrity, and availability is rated High across the board. EPSS is only 0.17% (6th percentile), Langflow is not in CISA KEV, and no public exploit code has been identified at time of analysis, so mass opportunistic exploitation is not currently indicated - the realistic risk concentrates on internet-exposed, multi-tenant, or weakly authenticated Langflow deployments.
Memory exhaustion in pypdf versions prior to 6.19.0 allows a remote, unauthenticated attacker to make an application unavailable by supplying a crafted PDF whose page-label numbering tree uses an alphabetical style (/S /A or /S /a) with an oversized /St start value, causing the library to generate pathologically long label strings when an application requests document page labels. The impact is strictly availability-related (C:N/I:N/A:H) with no data exposure, integrity loss, or code execution, and it only triggers if the consuming application actually reads page labels rather than merely opening the file. There is confirmed actively exploited status: no public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis beyond the fixed release 6.19.0; the independent assessment rates this as a genuine but bounded denial-of-service rather than an RCE despite the elevated CVSS 4.0 score of 8.7.
Denial of service in pypdf versions prior to 6.19.0 allows an unauthenticated remote attacker to pin a PDF-processing worker by supplying a document containing a large number of embedded files, because the dictionary-based attachments API re-enumerates and reparses the entire /EmbeddedFiles attachment list on every content lookup instead of indexing it once. The impact is limited to availability (CPU and wall-clock exhaustion); there is no code execution, data disclosure, or integrity impact, and the exposure is conditional on the host application actually enumerating or reading embedded-file attachments rather than merely opening the PDF. No public exploit identified at time of analysis, and the issue is fixed in the vendor's 6.19.0 release, so this should be treated as a bounded availability bug rather than a critical priority.
Denial of service in pypdf versions prior to 6.19.0 allows remote, unauthenticated attackers to exhaust application CPU by supplying a crafted PDF whose AcroForm choice field carries a large number of options and selected values; when a consuming application calls update_page_form_field_values with flatten=True, the appearance-stream generator recomputes the same invariant selection-glyph set once per line, driving runtimes up until the host process or worker becomes unavailable. The flaw is rated CVSS 4.0 8.7 (and 3.1 8.1 by independent assessment) with availability-only impact - no confidentiality or integrity loss, and no code execution. Exploitation requires the application to explicitly perform form-field updates with flattening on attacker-controlled input; merely opening, parsing, or reading the PDF does not reach the vulnerable code path. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV); the fix ships in upstream release 6.19.0.
Denial of service in pypdf before 6.18.1 lets a crafted PDF drive the library's FlateDecode recovery path into inefficient byte-by-byte decompression, consuming CPU until the consuming application becomes unavailable. Exploitation is unauthenticated and requires only that a pypdf-based service parse or extract text from an attacker-supplied PDF (CVSS v4.0 8.7, AV:N/AC:L/PR:N/UI:N, availability-only); no public exploit identified at time of analysis. The flaw is a residual case left after the earlier malformed-FlateDecode recovery fix and is resolved in 6.18.1.
Memory exhaustion in pypdf versions prior to 6.18.1 lets a crafted PDF force the library to allocate and process far more font-width data than a simple font can legitimately hold, degrading or crashing any process that extracts text or font metrics from untrusted documents. The parser fails to cap the /Widths array of a simple TrueType or Type1 font at the 256 one-byte character codes that such fonts can actually address, so an oversized array is walked entry by entry while widths are collected. The CVSS 4.0 vector (8.7, AV:N/AC:L/PR:N/UI:N, high availability-only impact) reflects unauthenticated remote triggering with no user interaction beyond supplying the file, and the availability-only profile confirms no confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV), though the trigger is trivially reproducible by anyone who can hand a PDF to a pypdf-consuming service; a vendor patch in 6.18.1 is available.
Memory exhaustion in pypdf versions prior to 6.18.1 allows unauthenticated remote attackers to crash or degrade any application that parses attacker-supplied PDFs, by embedding oversized source-code or destination-string tokens inside a font /ToUnicode CMap. Processing such a file (for example during text extraction, which routes through pypdf/_cmap.py parse_bfchar) makes the library decode and retain these oversized values, driving availability-impacting memory consumption with no confidentiality or integrity effect. The vendor CVSS 4.0 vector (8.7, VA:H only, PR:N/UI:N) matches the assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; no public exploit code or KEV-listed active exploitation was identified at time of analysis, and a vendor-released patch (6.18.1) is available.
Denial of service in pypdf versions prior to 6.18.0 allows remote, unauthenticated attackers to stall PDF parsing by supplying a crafted file whose indirect-object identifier or generation-number token continues for an excessive length without a whitespace delimiter. The parser's read_until_whitespace helper in pypdf/_utils.py scans unbounded input, so the consuming process hangs or runs for an extremely long time, making any service that parses untrusted PDFs unavailable (CVSS 4.0 8.7, availability-only; assessed CVSS 3.1 8.0 AV:N/AC:L/PR:N/UI:N/A:H). Impact is confined to availability - there is no path to code execution or data disclosure - and no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor-released fix is available in pypdf 6.18.0.
Memory-exhaustion denial of service in pypdf versions prior to 6.17.0 allows remote attackers to inflate application memory usage by supplying a crafted PDF whose /PageLabels /Nums dictionary declares a Roman-numeral numbering style (/S /R) with an extremely large start value (/St), causing the library to construct a numeral string proportional to that value. The CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VA:H) indicates an unauthenticated, network-reachable, low-complexity attack with high availability impact and no confidentiality or integrity effect, but the practical precondition is that the consuming application must actually invoke pypdf's page-label retrieval on attacker-supplied documents - applications that never read page labels are unaffected. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; the vendor released a fix in 6.17.0 that rejects Roman start values above 3,999.
Certificate hostname verification is silently skipped in CPython's TLS stack when an application enables SSLContext.check_hostname but supplies no server_hostname (None or an empty string) to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls(). In that exact state SSLObject still validates the certificate chain but never matches the peer's identity against the requested name, so an unauthenticated attacker holding a man-in-the-middle position on the connection path and a certificate chaining to a CA the client trusts can intercept traffic while the program believes hostname checking succeeded. Exploitation is gated by two independent conditions - the application-side misconfiguration and an active network-intercept position - no public exploit code has been identified at time of analysis, and applications that pass a valid non-empty server_hostname are completely unaffected regardless of patch status.
Unauthenticated remote code execution affects LightLLM through 1.2.0 when it is deployed in visual_only (multimodal/vision) mode, which exposes an RPyC inference service that performs no authentication and unpickles the arguments passed to its remote_infer_images method. Any attacker who can reach that visual RPyC port can send a crafted object whose __reduce__ method runs on the server, achieving code execution with the privileges of the LightLLM service account and resulting in high confidentiality, integrity, and availability impact (CVSS 4.0 base 9.3; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N with high C/I/A). Text-only LightLLM deployments do not expose the affected service, no public exploit code has been identified at time of analysis, and real-world exposure hinges on whether the visual RPyC port is bound to an untrusted-reachable interface rather than to localhost or an isolated network.
Command injection in the AiSOC actions service (AiSOC 7.2.0 up to, but excluding, 12.0.0) allows a low-privileged authenticated user to break out of quoted arguments in the file_path, path, script_name, or script_args parameters and execute arbitrary commands with SYSTEM/root privileges on CrowdStrike-managed endpoints. Exploitation requires that the deployment expose the actions service, that at least one CrowdStrike-managed endpoint is enrolled so a Real Time Response (RTR) session can be established, and that a mutating endpoint action (quarantine_file/rm, the automatic post-quarantine path_exists/ls probe, or a runscript path) is reachable with attacker-controlled input. No public exploit identified at time of analysis, and the practical weight of this flaw is tempered mainly by the small footprint of AiSOC deployments rather than by technical severity; note that the vendor's own fix commit documents that on default installs the dedicated actions-service token was never generated and its guard exempted itself while AISOC_DEV_MODE was enabled, so mutating routes could respond to anyone able to reach the port - materially lowering the authentication barrier described by the CVSS PR:L metric.
Authorization bypass in the MSSP (multi-tenant) module of AiSOC 10.0.0 through before 12.0.0 allows any authenticated user who already owns at least one portfolio to submit arbitrary tenant UUIDs to the add_tenants_to_portfolio endpoint and pull unclaimed tenants into their own portfolio without those tenants' consent. Once a victim tenant is claimed, the attacker can read its security alerts, incidents, and posture metrics, giving high confidentiality impact with limited integrity impact but no availability loss (assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N). Exploitation requires a valid account with portfolio ownership in an MSSP-enabled deployment and only works against tenants not already managed by another organisation; single-tenant installations are unaffected, and no public exploit code was identified at time of analysis.
Directory traversal in agent-zero 1.7 through 1.10 allows remote attackers to write files to arbitrary locations outside the intended file-browser directory via the save_file_b64 method, with the evaluated CVSS vector indicating PR:N/UI:N and high integrity impact according to the authoritative assessment. No CISA KEV listing was provided, and no public exploit identified at time of analysis; EPSS is 0.33% (24th percentile), and the supplied CVSS 3.1 score is 7.5, though the independent assessment shifts the impact from confidentiality to integrity (C:N/I:H/A:N) because exploitation concerns unauthorized file writes rather than reads.
Directory traversal in Agent Zero 1.7 through 1.10 lets the AI agent's file-browser component read files anywhere on the host, because FileBrowser is initialized with the host root as its workspace rather than a confined sandbox. The CVSS 3.1 vector is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), which models unauthenticated network access, but the practical risk is gated by whether the Agent Zero UI is exposed to untrusted networks; Agent Zero is often a local single-operator tool, so the AV:N/PR:N rating only applies when that interface is deliberately reachable without an authentication layer. At time of analysis there is no confirmed active exploitation (no CISA KEV entry) and no public exploit identified at time of analysis, and EPSS is 0.33% (24th percentile), indicating low predicted exploitation activity; reference material consists of a GitHub issue and a gist.
Code execution in camel-ai's CodeExecutionToolkit (versions 0.2.91a1, 0.2.91a2, and 0.2.91a3) lets remote, unauthenticated attackers run arbitrary Python through the SubprocessInterpreter with no approval or confirmation boundary. The attacker must be able to influence the agent's model output - for example via prompt or task injection - so that the LLM emits executable Python, and the host application must have opted into the code-execution toolkit and routed untrusted input to it; exposure is therefore conditional rather than default, which is reflected in the independent assessment's High attack complexity (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) versus the vendor's 9.8 AV:N/AC:L rating. Risk weighting is tempered by a low EPSS of 0.22% (11th percentile), no CISA KEV listing, and no vendor-released patch identified at time of analysis, though a public GitHub issue and a third-party gist describing the flaw are referenced.
Remote code execution in AgentScope 1.0.18 and 1.0.19 allows remote attackers to execute arbitrary Python in the service environment: when a RealtimeAgent session has execute_python_code registered as an available tool, the agent's _acting path forwards a model-produced tool call straight to Toolkit.call_tool_function with no approval prompt and no sandbox boundary, so a remote WebSocket user who can reach the endpoint and steer the agent can obtain code execution with the service's privileges. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) no authentication is required, and the SSVC assessment records that publicly available exploit code exists (exploitation: poc), so the vulnerability is automatable with total technical impact; EPSS is low at 0.20% (9th percentile), indicating limited observed exploitation activity so far. Exploitation is conditional on the deployment exposing the execute_python_code tool in a RealtimeAgent session and on the WebSocket interface being network-reachable - instances that do not register that tool are not vulnerable via this path.
Directory traversal in Bisheng 2.3.0, 2.4.0, and 2.4.0-beta1 lets a remote attacker use crafted filename/path input to break out of the intended download/cache directory through the save_download_file routine (src/backend/bisheng/core/cache/utils.py:290), yielding arbitrary file read and write with a CVSS 3.1 base score of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). The vector indicates an unauthenticated, network-reachable attack with no user interaction, though the practical limiting factor is whether the API route that reaches save_download_file is exposed without a login - defenders should verify that against their own deployment before assuming unauthenticated reachability. Exploitation status: no public exploit identified at time of analysis, and there is no CISA KEV entry; EPSS is 0.33% (24th percentile), so mass exploitation is not currently expected, but the impact per successful attack is severe given the high confidentiality and integrity ratings and the absence of any availability impact.
Memory exhaustion in LightLLM through 1.2.0 lets unauthenticated remote attackers crash KV-transfer worker processes when the server is started with the non-default `--pd_trans_mode nccl` flag. Under that mode the NCCL-based prefill-decode control channel exposes a `set_value` method that stores caller-supplied key-value pairs with no size or count limit, so repeated calls consume worker memory until the process dies and the node fails. Impact is availability-only (CVSS 4.0 base 8.7, VA:H; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) with no data disclosure or modification; exploitation requires the opt-in NCCL transport mode plus network reachability to the control channel, and no public exploit has been identified at time of analysis.
Unauthenticated remote code execution affects ModelTC LightLLM through version 1.2.0 when it is run in a multimodal deployment configuration, which starts an embed-cache RPyC service bound to all network interfaces with pickle deserialization enabled. Because the service performs no authentication and accepts attacker-controlled serialized objects through its exposed cache methods, any remote party that can reach the RPyC port can execute arbitrary code with the privileges of the LightLLM service (CVSS 4.0 base score 9.3; AV:N/AC:L/AT:N/PR:N/UI:N with high confidentiality, integrity, and availability impact). Exposure is configuration-dependent: non-multimodal deployments do not start this service, and instances whose port is bound to loopback or blocked by firewall rules on the host or network are not remotely reachable. No public exploit code has been identified at time of analysis, and the issue has been reported publicly by VulnCheck (also tracked in the project's GitHub issue #1596), so the primary risk is rapid weaponization against internet-facing multimodal inference deployments that have not been patched or isolated.
Remote code execution in LightLLM through 1.2.0 allows unauthenticated attackers to run arbitrary code on the host when the server is launched with the --enable_profiling flag, because that flag starts a router profiler service that exposes an RPyC listener with pickle deserialization enabled and no authentication (CVSS 4.0 base 9.3; CWE-502). The flaw is not reachable in a default deployment since profiling must be explicitly enabled, but once it is on, any network-reachable attacker can push crafted serialized objects onto the profiler command queue and gain high-integrity, high-availability code execution without credentials or user interaction (PR:N/UI:N). There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, so exposure is currently driven by the non-default profiling configuration and network reachability of the RPyC port rather than by active exploitation.
Command injection in PyPA virtualenv before 21.7.12 allows an attacker who controls the environment's prompt value - via the --prompt argument, the VIRTUALENV_PROMPT environment variable, or the equivalent configuration setting - to run arbitrary cmd.exe commands on Windows with the privileges of the user who activates the generated environment. The flaw is confined to the batch activator: BatchActivator.quote() returns the prompt text unchanged, so a supplied double quote closes the `set "VAR=value"` assignment in activate.bat and any following cmd.exe operators are executed as live syntax when the victim runs the script. Coverage is limited by a local attack vector, Windows-only exposure, and mandatory victim interaction (generating and then activating the environment); no public exploit was identified at time of analysis, and a vendor fix is available in 21.7.12.