plone.app.portlets EUVD-2026-84802

Requires an authenticated Plone account holding the plone.app.portlets.ManageOwnPortlets permission and the ability to add or edit a Classic portlet (plone.app.portlets.portlets.classic) - under Plone's DEFAULT role map ordinary registered users have this on their personal dashboard, so on sites permitting self-registration or granting portlet management broadly the effective bar is any logged-in user. Exploitation is limited where administrators have already restricted 'Manage portlets' to Manager/Site Administrator roles, removed ManageOwnPortlets from untrusted roles, unregistered the Classic portlet via portlets.xml, or blanked the classic.pt template. Affected versions: plone.app.portlets 5.0.0 up to but not including 5.0.8, 6.0.4, and 7.0.2.

This is a genuine high-priority issue, not a CVSS-inflated one. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) reflects network-reachable, low-complexity server-side code execution requiring only low-privilege authentication, with a scope change because the attacker crosses the trust boundary from an authenticated web user into the Plone/Zope server process. The critical aggravating factor is that under Plone's DEFAULT role map, ordinary registered users hold the ManageOwnPortlets permission on their personal dashboard, so the PR:L barrier is effectively 'any account the site allows to register or log in' - for public-registration Plone sites this approaches unauthenticated RCE in practice. Mitigating signals: no EPSS score, no CISA KEV entry, and no public exploit code were supplied, so exploitation status is 'no public exploit identified at time of analysis' - the risk is driven by the low technical bar (TALES expression injection is trivial to weaponize for anyone who understands Zope/TAL) rather than by observed in-the-wild activity. No SSVC decision data was provided. Net: patch urgently on any Plone instance that permits user self-registration or grants portlet management to non-administrators.

An attacker registers or uses any low-privilege account on a Plone site and navigates to their personal dashboard, where the default role map grants the ManageOwnPortlets permission. They add a Classic portlet and set its template/macro field to a crafted TALES expression that escapes the intended path lookup; when the portlet renders, the TAL path() helper evaluates the value as arbitrary code inside the Plone process. No user interaction and no public exploit code are required - the technique follows directly from how the field is evaluated.