GHSA-RR49-F9G6-C9R5
Vulnerability from github – Published: 2026-09-23 13:55 – Updated: 2026-09-23 13:55Impact
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.portlets7.0.2. - For Plone 6.1, upgrade to
plone.app.portlets6.0.4. - For Plone 6.0, upgrade to
plone.app.portlets5.0.8.
Workarounds
If upgrading is not immediately possible:
- Restrict who can manage portlets: remove the
plone.app.portlets.ManageOwnPortletspermission 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.xmlin 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_customizationstool, locate theclassic.pttemplate 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!
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.1"
},
"package": {
"ecosystem": "PyPI",
"name": "plone.app.portlets"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.3"
},
"package": {
"ecosystem": "PyPI",
"name": "plone.app.portlets"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.7"
},
"package": {
"ecosystem": "PyPI",
"name": "plone.app.portlets"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-57149"
],
"database_specific": {
"cwe_ids": [
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-23T13:55:47Z",
"nvd_published_at": "2026-09-22T19:16:43Z",
"severity": "CRITICAL"
},
"details": "### Impact\nThe 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.\n\nThis 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.\n\n### Patches\nThe problem has been patched in `plone.app.portlets`\n\n* For Plone 6.2, upgrade to `plone.app.portlets` 7.0.2.\n* For Plone 6.1, upgrade to `plone.app.portlets` 6.0.4.\n* For Plone 6.0, upgrade to `plone.app.portlets` 5.0.8.\n\n### Workarounds\nIf upgrading is not immediately possible:\n\n- 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).\n- 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.\n- 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 `\u003cdiv\u003eThe classic portlet was disabled.\u003c/div\u003e`. (This is not a recommended way of customising a template, but in this case it is quite effective.)\n\n### Credits\n\nDiscovered by Giuseppe Caruso, and reported to the [Plone/Zope Security Team](mailto:security@plone.org). Thanks!",
"id": "GHSA-rr49-f9g6-c9r5",
"modified": "2026-09-23T13:55:47Z",
"published": "2026-09-23T13:55:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/security/advisories/GHSA-rr49-f9g6-c9r5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57149"
},
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/commit/1d9cacacfad9ed08b890dadc6e75741e295dc151"
},
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/commit/8a0641dc4054a2b13834bba00c67cd9a2fd189e1"
},
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/commit/fb979f01b57dd2fc06c90ee6577eb5eb285da8f1"
},
{
"type": "PACKAGE",
"url": "https://github.com/plone/plone.app.portlets"
},
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/releases/tag/5.0.8"
},
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/releases/tag/6.0.4"
},
{
"type": "WEB",
"url": "https://github.com/plone/plone.app.portlets/releases/tag/7.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "plone.app.portlets Vulnerable to Remote Code Execution via TALES Injection"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.