PYSEC-2026-4138

Impact

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.

Patches

The problem has been patched in plone.app.portlets

• For Plone 6.2, upgrade to plone.app.portlets 7.0.2.
• For Plone 6.1, upgrade to plone.app.portlets 6.0.4.
• For Plone 6.0, upgrade to plone.app.portlets 5.0.8.

Workarounds

If upgrading is not immediately possible:

• 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, so it is not a quick fix.
• You could 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 customising a template, but in this case it is quite effective.)

Credits

Discovered by Giuseppe Caruso, and reported to the Plone/Zope Security Team. Thanks!