| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Python StateMachine versions 3.0.0 before 3.2.0 contains a remote code execution vulnerability that allows attackers to execute arbitrary code by supplying malicious SCXML documents containing crafted `<data expr="...">` attributes evaluated unsafely. The SCXMLProcessor passes attacker-controlled expression strings through a call chain ending in Python's built-in eval() without sandboxing, enabling arbitrary code execution in the context of the hosting process. |
| 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. |
| Trilium is an open-source hierarchical note-taking application. In versions up to and including 0.103.0, the default-on "Safe import" filter sanitizes HTML only for text notes and excludes the book note type, whose content is stored without sanitization and later rendered as HTML, allowing an attacker-supplied import archive to embed a payload that executes as script. A book note's content is routed through the same rendering path as text notes and injected into the page with jQuery's html method when the note is shown as a grid-view preview card, so a malicious note survives Safe import and runs as soon as the victim opens the containing note. On the desktop client the Electron renderer runs with Node integration enabled, so the injected JavaScript escalates from cross-site scripting to full remote code execution on the victim's machine. This issue is fixed in version 0.104.0. |
| Budibase versions before 3.41.3 contain a remote code execution vulnerability in plugin handling that allows authenticated admin users to execute arbitrary code by uploading a malicious plugin tarball. The server calls eval() on plugin JavaScript files without sandboxing in the main Node.js process, enabling attackers to exfiltrate environment variables and credentials with root privileges in default deployments. |
| Code injection in Bisection in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to obtain sensitive information via a crafted file. (Chromium security severity: Medium) |
| A security vulnerability has been detected in RooCodeInc Roo-Code up to 3.51.1. This affects the function fetch_instructions of the file malicious_mcp_server.py of the component MCP Integration Trust Model. The manipulation leads to code injection. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used. Multiple isses were reported to the vendor beforehand. They explain, that "they all apply to Roo Code, a project we no longer support - the repository was archived a while ago, and we don't encourage anyone to use it." This vulnerability only affects products that are no longer supported by the maintainer. |
| A weakness has been identified in primefaces primereact up to 10.9.8. This issue affects the function ObjectUtils.mutateFieldData of the file components/lib/utils/ObjectUtils.js of the component API. This manipulation of the argument Field causes improperly controlled modification of object prototype attributes. The attack is possible to be carried out remotely. Upgrading to version 10.9.9 and 11.0.0 is capable of addressing this issue. Patch name: 61f182e11d9ef52032ff56f420da763a6938236f. It is recommended to upgrade the affected component. |
| SQL injection in Hive Metastore direct SQL partition-name resolution in Apache Hive before 4.2.1 on all platforms allows authenticated users with access to Hive Metastore APIs to read, modify, or affect unintended partition metadata (including statistics updates, truncation targets, and file-metadata cache operations) via crafted partition names in metastore RPC requests when direct SQL is enabled (the default). Users are recommended to upgrade to version 4.2.1, which fixes this issue.
Details about the issue:
Several Hive Metastore RPCs resolve partitions by full partition name (PART_NAME) through direct-SQL helpers. In those paths, client-supplied partition names are embedded into SQL using string concatenation (DirectSqlUpdatePart.quoteString() → '...') instead of bind parameters. A partition name containing a single quote (and crafted SQL) can alter the generated WHERE clause so that lookups intended for one partition match additional rows. That can affect reads, stats updates, truncate targets, metadata-cache targets, and related operations when metastore.try.direct.sql is enabled (default: true). An authenticated or network-trusted caller with the ability to invoke Hive Metastore partition-name APIs against a target table (directly or via Hive/other clients), when direct SQL is enabled can perform this attack. Also, the impact is mainly within table & partition targeting (read/update/truncate/drop/cache the wrong partitions in a table they can reference), not arbitrary cross-database access via this bug alone. |
| A vulnerability was determined in jQWidgets up to 24.0.1. This affects the function JQXLite.extend/jqxBaseFramework.extend of the file jqwidgets/jqx-all.js. This manipulation causes improperly controlled modification of object prototype attributes. The attack can be initiated remotely. The reported GitHub issue was closed with the label "not planned". |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an authenticated user who does not hold a role with the edit_manager_xml capability could write a malicious Splunk Web Manager Extensible Markup Language (XML) configuration. When the same user opens the affected Splunk Web Manager page, Splunk Enterprise runs attacker-controlled operating-system commands as the user account running Splunk Enterprise. The vulnerability is possible because Splunk Web does not require the edit_manager_xml capability before accepting Splunk Web Manager XML configuration changes. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could inject Search Processing Language (SPL) into saved-search dispatch requests. This could allow for unauthorized access to all relevant data and affect system integrity within Splunk Enterprise. The vulnerability is possible because Splunk Enterprise does not correctly validate caller-supplied time values before using them in saved-search dispatch. For more information see Search endpoint descriptions (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.2/search-endpoints/search-endpoint-descriptions) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.9, and 9.4.14, an unauthenticated user who can reach the Splunk management port could store a Search Processing Language (SPL) pipeline that runs when an administrator opens the Add Data forwarder workflow. The SPL pipeline could access all relevant data, affect system integrity, and affect availability of the Splunk platform instance. The SPL injection is possible because Deployment Server client identifiers are placed into dispatched searches without neutralizing special characters. Successful exploitation requires an administrator to open the affected Add Data forwarder workflow after the unauthenticated user registers a crafted Deployment Server client identity. For more information see Forward data (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.2/how-to-get-data-into-your-splunk-deployment/forward-data) and About agent management (https://help.splunk.com/en/splunk-enterprise/administer/update-your-deployment/10.4/agent-management/about-agent-management) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could execute arbitrary code on the Splunk platform instance through Splunk Web Manager Configuration. The user could then access all relevant data and affect system integrity and availability on the Splunk platform instance. The vulnerability is possible because Splunk Web Manager Configuration evaluates manager configuration values, and the Representational State Transfer (REST) API path for manager configuration does not require the permission that normally controls manager configuration writes. For more information see About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) and restmap.conf (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/restmap.conf) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could perform Remote Code Execution (RCE) by submitting crafted Splunk Web Manager Configuration content. The user could then access all relevant data and affect system integrity and availability. The vulnerability is possible because Splunk Web evaluates manager Extensible Markup Language expressions without sufficient input restrictions, and the associated configuration route does not require the capability expected for manager configuration changes. For more information see About configuration files (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.4/administer-splunk-enterprise-with-configuration-files/about-configuration-files) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, 9.4.14, and 9.3.14, an unauthenticated user could cause another user to dispatch arbitrary Search Processing Language (SPL) pipelines from Dataset Explorer with the same privileges as that user, which can allow for access to all relevant data and system integrity available to that user and affect system availability. The vulnerability is possible because Dataset Explorer does not validate or escape dataset names before building SPL searches and does not apply SPL safeguards for risky commands to those searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will. For more information see Explore a dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.4/manage-and-explore-datasets/explore-a-dataset) and SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) in the Splunk documentation. |
| Phalcon is a high-performance, full-stack PHP framework. In 5.15.0 and earlier, resolveFilter in phalcon/Mvc/View/Engine/Volt/Compiler.zep builds the join filter by inserting the raw separator and array token values into generated PHP without passing them through expression(). An attacker who can influence Volt template source can place quote-breaking content in a join argument, inject PHP into the compiled cache file, and execute it when Phalcon\Mvc\View\Engine\Volt::render() loads the template. This issue is fixed in version 5.16.0. |
| The Smush WordPress plugin before 4.3.2 does not restrict a network-wide setting to network administrators, allowing an administrator of any single site on a multisite network to execute arbitrary code across the entire network. |
| The Defender Security WordPress plugin before 6.2.0 does not restrict a network-wide setting to network administrators, allowing an administrator of any single site on a multisite network to execute arbitrary code across the entire network. |
| Affected versions of Flowintel improperly trust configuration keys supplied to the alerts settings update endpoint. While configuration values were normalized to Python literals, the corresponding keys were used directly when constructing and replacing lines in conf/config_module.py.
The vulnerable code used requester-controlled keys in both the regular expression and the generated assignment:
f'{key} = {py_val}'
and appended an assignment if the key was not already present. The modified Python configuration module was subsequently reloaded using importlib.reload(). This creates a code-generation boundary in which specially crafted configuration keys can alter the Python source structure and result in execution of attacker-controlled Python statements.
Version impacted >=3.3.0 |
| Affected versions of Flowintel allow the LOG_FILE configuration value to be modified through system settings without restricting it to a filename inside the intended log directory.
Because the application constructs the log destination from this configurable value, an administrator could set LOG_FILE to an arbitrary filesystem path. Since attackers can influence logged content, this enables controlled data to be written into unintended files. The upstream commit specifically describes an exploitation chain in which an attacker injects a template into a chosen file and subsequently abuses application rendering behavior to execute code.
The patch removes LOG_FILE from the web-editable settings, introduces validate_log_file_name() to reject absolute paths, traversal, Windows paths, null bytes, and directory components, and centralizes log path construction through resolve_log_file_path().
Version impacted: >=3.3.0 |
