| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| plone.app.dexterity is a content-type system for the Plone content management system, and plone.app.contenttypes provides Plone’s Dexterity-based content types. Plone.app.dexterity versions through 3.2.2, 4.0.0 through 4.1.2, and 5.0.0, and plone.app.contenttypes versions through 3.0.11, 4.0.0 through 4.0.9, and 5.0.0 are vulnerable to denial of service because an authenticated user can create content with excessively long titles, descriptions, or uploaded-file names, causing Plone to become unresponsive and potentially making the resulting content difficult to edit or delete. The vulnerability is patched in plone.app.dexterity versions 3.2.3, 4.1.3, and 5.0.1, and in plone.app.contenttypes versions 3.0.12, 4.0.10, and 5.0.1. |
| 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.) |
| plone.app.textfield provides a zope.schema-style field type called RichText for storing a value with a related MIME type. Prior to 2.0.2, 3.0.2, and 4.0.1, depending on the release line, RichTextValue.output returns an unsanitized stored RichText value when mimeType equals outputMimeType, including values that claim the text/x-html-safe output type. This equality shortcut bypasses the safe_html transform even though the transform itself correctly removes event-handler attributes and unsafe URI schemes. Equal types can result from a RichText field configured with the same mimeType and outputMimeType or from REST API input that supplies text/x-html-safe as its content type. The raw stored value is then emitted through tal:content=structure without escaping, allowing a user who can set a RichText field to store JavaScript that executes in a viewer's browser. This issue is fixed in versions 2.0.2, 3.0.2, and 4.0.1. |
| plone.app.event provides the event content type for Plone. Prior to versions 5.2.4 and 6.0.1, the iCalendar import in src/plone/app/event/ical/importer.py accepts insufficiently restricted calendar and event URLs, does not adequately bound downloaded bytes or imported events, and commits work per event. A logged-in editor can make the server request internal network resources or local calendar files, exhaust resources and take the site offline, and store a malicious event URL that executes script in another user's browser. The fix restricts accepted URLs, applies MAXIMUM_ICAL_IMPORT_SIZE_BYTES and MAXIMUM_ICAL_IMPORT_EVENTS limits, uses transaction savepoints, and validates event URLs. This issue is fixed in versions 5.2.4 and 6.0.1. |
| plone.app.portlets provides portlets and a Plone-specific user interface for plone.portlets. Prior to 5.0.8, 6.0.4, and 7.0.2, a member who can add an RSS portlet can set its feed URL to a very large response, causing src/plone/app/portlets/portlets/rss.py to download and retain excessive data in memory and deny service. The same RSS URL handling accepts internal hosts, IP addresses, single-word domains, and explicit ports, allowing server-side requests that can probe internal network services and open ports. A malicious feed item can also supply a JavaScript URL that is retained as the item link and can execute script when used by a victim. The affected logic includes _rss_feed_url_validator, _normal_url_validator, RSSFeed._retrieveFeed, RSSFeed._buildItemDict, and the FEED_DATA in-memory cache. This issue is fixed in versions 5.0.8, 6.0.4, and 7.0.2. |
| An issue in Plone Docker Official Image 5.2.13 (5221) open-source software that could allow for remote code execution due to a package listed in ++plone++static/components not existing in the public package index (npm). |
| Plone 2.5 through 2.5.4 and 3.0 through 3.0.2 allows remote attackers to execute arbitrary Python code via network data containing pickled objects for the (1) statusmessages or (2) linkintegrity module, which the module unpickles and executes. |
| Cross-site scripting (XSS) vulnerability in the LiveSearch module in Plone before 3.0.4 allows remote attackers to inject arbitrary web script or HTML via the Description field for search results, as demonstrated using the onerror Javascript even in an IMG tag. |
| Plone CMS 3.x uses invariant data (a client username and a server secret) when calculating an HMAC-SHA1 value for an authentication cookie, which makes it easier for remote attackers to gain permanent access to an account by sniffing the network. |
| Plone CMS before 3 places a base64 encoded form of the username and password in the __ac cookie for all user accounts, which makes it easier for remote attackers to obtain access by sniffing the network. |
| Unspecified vulnerability in the Password Reset Tool before 0.4.1 on Plone 2.5 and 2.5.1 Release Candidate allows attackers to reset the passwords of other users, related to "an erroneous security declaration." |
| Multiple cross-site request forgery (CSRF) vulnerabilities in Plone CMS 3.0.5 and 3.0.6 allow remote attackers to (1) add arbitrary accounts via the join_form page and (2) change the privileges of arbitrary groups via the prefs_groups_overview page. |
| Plone CMS 3.0.5, and probably other 3.x versions, places a base64 encoded form of the username and password in the __ac cookie for the admin account, which makes it easier for remote attackers to obtain administrative privileges by sniffing the network. |
| Unspecified vulnerability in PlonePAS in Plone 2.5 and 2.5.1, when anonymous member registration is enabled, allows an attacker to "masquerade as a group." |
| The PlonePAS product 3.x before 3.9 and 3.2.x before 3.2.2, a product for Plone, does not properly handle the login form, which allows remote authenticated users to acquire the identity of an arbitrary user via unspecified vectors. |
| Plone CMS does not record users' authentication states, and implements the logout feature solely on the client side, which makes it easier for context-dependent attackers to reuse a logged-out session. |
| Products.isurlinportal is a replacement for isURLInPortal method in Plone. Prior to versions 2.1.0, 3.1.0, and 4.0.0, a url /login?came_from=////evil.example may redirect to an external website after login. This issue has been patched in versions 2.1.0, 3.1.0, and 4.0.0. |
| Plone 2.0.5, 2.1.2, and 2.5-beta1 does not restrict access to the (1) changeMemberPortrait, (2) deletePersonalPortrait, and (3) testCurrentPassword methods, which allows remote attackers to modify portraits. |
| Volto is a React based frontend for the Plone Content Management System. In versions from 19.0.0-alpha.1 to before 19.0.0-alpha.4, 18.0.0 to before 18.24.0, 17.0.0 to before 17.22.1, and prior to 16.34.0, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. The problem has been patched in versions 16.34.0, 17.22.1, 18.24.0, and 19.0.0-alpha.4. To mitigate downtime, have setup automatically restart processes that quit with an error. |
| Volto is a ReactJS-based frontend for the Plone Content Management System. Versions 16.34.0 and below, 17.0.0 through 17.22.1, 18.0.0 through 18.27.1, and 19.0.0-alpha.1 through 19.0.0-alpha.5, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. This issue is fixed in versions 16.34.1, 17.22.2, 18.27.2 and 19.0.0-alpha.6. |
