CVE-2026-57149: CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') in plone plone.app.portlets
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.)
AI Analysis
Technical Summary
The vulnerability arises from improper neutralization of directives in dynamically evaluated TALES expressions within the Classic portlet of plone.app.portlets. User-supplied template or macro fields are used to build a TALES path expression evaluated by the TAL path() helper without sufficient sanitization. This allows an authenticated user with the ability to add or edit Classic portlets to inject arbitrary code executed in the context of the Plone server process, effectively escalating privileges. The issue affects plone.app.portlets versions >=5.0.0 <5.0.8, >=6.0.0 <6.0.4, and >=7.0.0 <7.0.2 and has been fixed in 5.0.8, 6.0.4, and 7.0.2. Mitigations include restricting the ManageOwnPortlets permission from untrusted roles, limiting Manage portlets permission to trusted administrators, unregistering the Classic portlet if unused, or disabling its template via customization.
Potential Impact
Successful exploitation allows an authenticated user with permission to configure Classic portlets (including regular users on their personal dashboard by default) to execute arbitrary code on the server running Plone. This results in privilege escalation across the trust boundary between the authenticated web user and the server-side process, potentially compromising confidentiality, integrity, and availability of the system. The CVSS v3.1 score is 9.9 (critical), reflecting network attack vector, low attack complexity, low privileges required, no user interaction, and complete impact on confidentiality, integrity, and availability.
Mitigation Recommendations
A fix is available in plone.app.portlets versions 5.0.8, 6.0.4, and 7.0.2. Users should upgrade to these or later versions. Where upgrading is not immediately possible, workarounds include restricting the ManageOwnPortlets permission from untrusted roles and limiting Manage portlets permission to trusted administrators only. Additionally, if the Classic portlet is not needed, it can be unregistered by editing portlets.xml in custom code or effectively disabled by customizing its template in the Zope Management Interface to remove all content. These mitigations reduce the attack surface until patching is applied.
CVE-2026-57149: CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') in plone plone.app.portlets
Description
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.)
CVSS v3.1
Score 9.9critical
Affected software
plone
plone.app.portlets
pkg:pypi/plone-app-portletsRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises from improper neutralization of directives in dynamically evaluated TALES expressions within the Classic portlet of plone.app.portlets. User-supplied template or macro fields are used to build a TALES path expression evaluated by the TAL path() helper without sufficient sanitization. This allows an authenticated user with the ability to add or edit Classic portlets to inject arbitrary code executed in the context of the Plone server process, effectively escalating privileges. The issue affects plone.app.portlets versions >=5.0.0 <5.0.8, >=6.0.0 <6.0.4, and >=7.0.0 <7.0.2 and has been fixed in 5.0.8, 6.0.4, and 7.0.2. Mitigations include restricting the ManageOwnPortlets permission from untrusted roles, limiting Manage portlets permission to trusted administrators, unregistering the Classic portlet if unused, or disabling its template via customization.
Potential Impact
Successful exploitation allows an authenticated user with permission to configure Classic portlets (including regular users on their personal dashboard by default) to execute arbitrary code on the server running Plone. This results in privilege escalation across the trust boundary between the authenticated web user and the server-side process, potentially compromising confidentiality, integrity, and availability of the system. The CVSS v3.1 score is 9.9 (critical), reflecting network attack vector, low attack complexity, low privileges required, no user interaction, and complete impact on confidentiality, integrity, and availability.
Mitigation Recommendations
A fix is available in plone.app.portlets versions 5.0.8, 6.0.4, and 7.0.2. Users should upgrade to these or later versions. Where upgrading is not immediately possible, workarounds include restricting the ManageOwnPortlets permission from untrusted roles and limiting Manage portlets permission to trusted administrators only. Additionally, if the Classic portlet is not needed, it can be unregistered by editing portlets.xml in custom code or effectively disabled by customizing its template in the Zope Management Interface to remove all content. These mitigations reduce the attack surface until patching is applied.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-06-24T01:45:48.697Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6ab2d481f7a7c54106a364cb
Added to database: 09/22/2026, 19:18:25 UTC
Last enriched: 09/22/2026, 19:33:01 UTC
Last updated: 09/23/2026, 01:58:06 UTC
Views: 8
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.