Threats Tagged 'cwe-95'

plone.app.portlets.portlets provides a Plone-specific user interface for plone.portlets, as well as a standard set of portlets that ship with Plone. Starting in version 5.0.0 and prior to versions 5.0.8, 6.0.4, and 7.0.2, the Classic portlet (plone.app.portlets.portlets.classic) used its user-supplied template/macro fields to build a TALES path expression that was then evaluated by the TAL path() helper. Because the value was interpreted as a full TALES expression, a user able to add or edit a Classic portlet could supply a crafted value that escapes simple path traversal and is evaluated as arbitrary code. This is exploitable by any authenticated user who can configure a Classic portlet - which, with the default role map, includes regular users on their personal dashboard. The result is code execution in the context of the Plone process, i.e. a privilege escalation across the trust boundary between an authenticated web user and the server-side process. The problem has been patched in `plone.app.portlets` 5.0.8, 6.0.4, and 7.0.2. Some workarounds are available. Restrict who can manage portlets: remove the `plone.app.portlets.ManageOwnPortlets` permission from untrusted roles, and limit Manage portlets to trusted administrators (usually this is already restricted to the Manager and Site Administrator roles). Where the Classic portlet is not needed, unregister it so it cannot be added. This would need to be done by editing a `portlets.xml` in your own code. One may also effectively disable showing the classic portlet by customising its template. In the Zope Management Interface go to the `portal_view_customizations` tool, locate the `classic.pt` template and click it. Click the Customize button. Remove all text and replace it with `<div>The classic portlet was disabled.</div>`. (This is not a recommended way of customizing a template, but in this case it is quite effective.)

SAP Fiori Launchpad does not sufficiently validate certain user-controlled input. An unauthenticated attacker could craft a malicious link that, when clicked by an authenticated user, causes the browser to load attacker-controlled content from an external location. This could be used to exfiltrate sensitive information from the victim's session, resulting in a high impact on confidentiality. There is no impact on integrity and availability.

XWiki Rendering is a generic rendering system that converts textual input in a given syntax (wiki syntax, HTML, etc) into another syntax (XHTML, etc). Prior to versions 14.10.2 and 15.0 RC1, any user who can edit their own user profile or any other document can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The reason is that rendering output is included as content of HTML macros without further escaping and it is thus possible to close the HTML macro and inject script macros that are executed with programming rights. This has been patched in XWiki 14.10.2 and 15.0 RC1 by making sure that rendering output cannot close the surrounding HTML macro. A possible workaround is available. It is, in principle, possible to add escaping to all places where rendering output is used in wiki documents, but at the moment there is no list of them.

Redocly CLI makes OpenAPI validation, linting, and documentation workflows easier. Prior to version 2.33.0 of @redocly/respect-core and @redocly/cli, the respect command dynamically evaluates $faker runtime expressions in Arazzo descriptions. A crafted expression can traverse constructor, prototype, or __proto__ properties in packages/respect-core/src/modules/context-parser/get-value-from-context.ts, reach the JavaScript Function constructor, and execute arbitrary code when a user processes an untrusted description. The executed code runs with the privileges of the CLI process and can execute shell commands or read CI secrets. Users processing only trusted, self-authored workflows are not affected. This issue is fixed in @redocly/respect-core and @redocly/cli version 2.33.0.

DIRAC is an interware, meaning a software framework for distributed computing. Prior to versions 8.0.79, 9.0.22, and 9.1.10, DataManagementSystem/Service/FileCatalogHandler.py checkDataset forwards an authenticated caller-controlled datasets value to DatasetManager.py __checkDataset, where datasetName is interpolated into an FC_MetaDatasets SQL query without parameterization. The injected query can control the returned MetaQuery value, which is passed to Python eval and permits command execution as the account running the DIRAC services. Successful exploitation can expose dirac.cfg, database passwords, stored proxies, and tokens, fully compromise the DIRAC system, and allow alteration of local log evidence. This issue is fixed in versions 8.0.79, 9.0.22, and 9.1.10.

DIRAC is an interware, meaning a software framework for distributed computing. Prior to versions 8.0.79, 9.0.22, and 9.1.10, the RequestManagementSystem/Service/ReqManagerHandler.py export_getRequestCountersWeb function passes an authenticated caller-controlled groupingAttribute to RequestManagementSystem/DB/RequestDB.py getRequestCountersWeb. An unrecognized value is resolved against the Request object and evaluated as Python code, allowing a crafted dunder attribute expression to reach operating-system functions and execute commands as the account running the DIRAC services. Successful exploitation can expose dirac.cfg, database passwords, stored proxies, and tokens, fully compromise the DIRAC system, and allow alteration of local log evidence. This issue is fixed in versions 8.0.79, 9.0.22, and 9.1.10.

A high-severity vulnerability (CVE-2026-78136) exists in chirpmyradio CHIRP before commit 39178db, where crafted CSV data can trigger an eval injection flaw in the _clean_tmode function within drivers/kenwood_itm.py. This improper neutralization of directives in dynamically evaluated code (CWE-95) can lead to full compromise of confidentiality, integrity, and availability. No official patch or remediation guidance is currently available.

Improper neutralization of directives in dynamically evaluated code ('eval injection') vulnerability in Apache Camel K. An improper neutralization of directives in dynamically evaluated Maven configuration allows tenant-controlled repository content to influence code execution within the operator pod, potentially enabling tenants to execute arbitrary code with the privileges of the operator. This issue affects Apache Camel K: from 2.0.0 before 2.9.3, from 2.10.1 before 2.10.2. Users are recommended to upgrade to version 2.9.3, 2.10.2 or 2.11.0, which fixes the issue.

Adobe ColdFusion 2025 is affected by a critical vulnerability (CVE-2026-48273) involving improper neutralization of directives in dynamically evaluated code, also known as 'Eval Injection'. This flaw allows a low-privileged attacker to execute arbitrary code without requiring user interaction. The vulnerability impacts confidentiality, integrity, and availability, with a high CVSS score of 9.9. The scope of the vulnerability is changed, indicating that the impact extends beyond the vulnerable component. No patch information is provided in the input data.

ColdFusion is affected by an Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.