GHSA-8PCW-H6W9-H46G: Denial of Service via Uncontrolled Resource Consumption in plone.app.contenttypes

The Plone Content Management System (CMS) relies on Dexterity-based content types provided by the standard plone.app.contenttypes package to manage core entities like files and images. During the file upload process, users often leave metadata fields such as the title and description blank, expecting the system to automatically generate these values. To facilitate this usability feature, the system registers an event subscriber that listens for object creation and automatically populates missing metadata.

This auto-population mechanism introduces an attack surface when processing the uploaded file's metadata. Specifically, the system reads the filename directly from the raw multipart upload header and stores it as the object's title property. Because there are no initial constraints on the length of this string, an authenticated attacker can supply an excessively long filename to trigger uncontrolled resource consumption.

The resulting vulnerability falls under the category of Application-level Denial of Service (DoS) and is tracked as GHSA-8PCW-H6W9-H46G. By exploiting this issue, standard authenticated users with basic content creation permissions can systematically degrade the performance of the Plone site, leading to high CPU load, memory exhaustion, and potential thread lockups.

The fundamental flaw resides within the set_title_description(obj, event) event handler defined in src/plone/app/contenttypes/subscribers.py. This handler is invoked whenever an IObjectCreatedEvent is fired for a Dexterity-based File or Image object. When the handler detects that the content object lacks a title, it queries the underlying data field to retrieve the filename property.

Prior to the remediation, the handler directly assigned the raw datafield.filename attribute to the obj.title attribute without any length validation or truncation. Because the Zope framework allows the extraction of raw header parameters directly from the incoming HTTP multipart request, the filename can contain tens of thousands of characters. The system stores this unbounded string directly into the database as-is.

Storing extremely long strings inside core metadata attributes triggers significant performance penalties due to Zope's object architecture. First, Plone's search indexer (portal_catalog) immediately attempts to tokenize and index the title of the newly created object, which spikes CPU utilization during indexing operations. Second, rendering views like folder listings, breadcrumbs, and navigation trees requires retrieving and displaying this massive title, which rapidly exhausts server memory allocations and blocks concurrent worker threads.

An examination of the vulnerable code path highlights the absence of boundary checks. The event handler extracts the filename without sanitization or length enforcement.

# Vulnerable implementation in subscribers.py
def set_title_description(obj, event):
    """Sets title to filename if no title
    """
    if not obj.title:
        if IImage.providedBy(obj):
            datafield = obj.image
        else:
            datafield = obj.file
        if datafield:
            filename = datafield.filename
            obj.title = filename  # Direct assignment of unbounded string

The remediated code resolves the boundary validation gap by introducing an explicit slicing fallback. The handler now attempts to import a defined maximum length configuration, MAX_TITLE_LENGTH, falling back to a default value of 1,024 characters.

# Patched implementation in subscribers.py
from plone.app.contenttypes.interfaces import IImage
 
try:
    from plone.app.dexterity.config import MAX_TITLE_LENGTH as _MAX_TITLE_LENGTH
except ImportError:
    _MAX_TITLE_LENGTH = 1024
 
def set_title_description(obj, event):
    """Sets title to filename if no title
    """
    if not obj.title:
        if IImage.providedBy(obj):
            datafield = obj.image
        else:
            datafield = obj.file
        if datafield:
            filename = datafield.filename or ""
            obj.title = filename[:_MAX_TITLE_LENGTH]  # Safe truncation

Additionally, the database and form-rendering schemas were updated. In both schema/file.xml and schema/image.xml, the system now enforces <max_length> limits (1,024 for title, 10,000 for description) directly in the Zope XML schemas. This defense-in-depth approach ensures both API-driven uploads and manual browser-based entries are constrained to safe limits before data serialization.

To execute the attack, an adversary requires low-privilege authentication that grants content creation rights within a target folder. In default Plone installations, roles such as Contributor or Member are sufficient to create File or Image objects. If the site is configured to permit anonymous submissions, the attack can be launched without authentication.

The exploit is delivered via an HTTP POST multipart/form-data request aimed at the file creation endpoint. The attacker omits the manual title parameter from the request, forcing the application to invoke the automatic title generation logic. Within the file upload section of the payload, the attacker crafts a malicious Content-Disposition header where the filename parameter is inflated with an excessively long pattern, such as 20,000 repetitive characters.

POST /Plone/my-folder/++add++File HTTP/1.1
Host: target.local
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXyZ
Authorization: Basic dXNlcjpwYXNzd29yZA==
 
------WebKitFormBoundaryXyZ
Content-Disposition: form-data; name="form.widgets.file"; filename="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...[20,000 characters]...AAAAA.png"
Content-Type: image/png
 
[PNG Binary Data]
------WebKitFormBoundaryXyZ--

Upon processing the request, Plone generates the File object and triggers the IObjectCreatedEvent subscriber. The backend processes the massive filename string and commits it to the ZODB. Any subsequent attempt to index the object or render the parent directory's listing view will hang, exhausting thread resources and causing a denial of service.

The main impact of this vulnerability is a complete loss of availability of the Plone application instance. Storing extremely long metadata attributes causes severe Zope Object Database (ZODB) bloat, significantly increasing transaction serialization time and degrading cache efficiency. This bloat directly impacts overall system database read and write latency for all users.

Furthermore, the catalog indexing engine (portal_catalog) consumes extensive CPU cycles while attempting to process and split the massive string. If multiple malicious uploads are performed in parallel, the server's CPU utilization reaches 100%, causing incoming requests to queue up. Eventually, the Zope worker thread pool is fully exhausted, rendering the application entirely unresponsive to legitimate traffic.

This vulnerability is assigned a CVSS v3.1 base score of 6.5 (Medium) under standard authenticated conditions. However, in environments configured to allow anonymous file uploads or guest submissions, the severity increases to 7.5 (High) due to the absence of authentication requirements. There is no impact on data confidentiality or integrity, as the attack does not leak information or modify arbitrary state.

The most reliable remediation is upgrading plone.app.contenttypes to a patched release. For Plone 5.x and 6.0 setups, administrators should upgrade to version 3.0.12 or 4.0.10. For Plone 6.1 deployments, upgrading to version 5.0.1 is required to ensure compatibility and protection.

If immediate patching is not possible, administrators can implement a temporary Web Application Firewall (WAF) rule. This rule should intercept multipart file upload requests and block any request containing a filename parameter in the Content-Disposition header that exceeds 1024 characters. This mitigation effectively neutralizes the primary injection vector before the payload reaches the Python runtime.

To identify and remediate existing large objects, administrators can execute a cleanup script via the Zope Python Interpreter Console. This script queries the portal catalog, checks the length of the Title and Description properties of existing objects, truncates any values exceeding the safe limits, and reindexes the corrected items. This process restores performance and recovers wasted database cache memory.