CVE-2026-55247: Multiple Vulnerabilities (DoS, SSRF, and Stored XSS) in plone.app.event iCalendar Import

The core event management functionality of the Plone CMS is provided by the plone.app.event package. This component features an iCalendar (.ics) import mechanism allowing editors to sync external calendars with the CMS database.

The import functionality represents a significant attack surface because it accepts arbitrary URLs from users and fetches external content directly on the server host. Prior to the release of security patches, this interface did not implement proper boundary checks or validation constraints on imported data.

Consequently, authenticated editors could leverage this trust boundary to trigger three distinct classes of security vulnerabilities: uncontrolled resource consumption leading to Denial of Service, Server-Side Request Forgery facilitating access to internal assets, and Stored Cross-Site Scripting through unvalidated URL attributes.

The primary vulnerability lies within the iCalendar parsing implementation in src/plone/app/event/ical/importer.py and structural URL handling in src/plone/app/event/base.py. Under default configurations, the application used Python's native urllib.request.urlopen library to fetch the resource specified by the editor.

Because the network call lacked size constraints, timeouts, or scheme validation, the server would unconditionally download and attempt to parse any remote file. During parsing, the application invoked the Zope Object Database (ZODB) transaction manager to commit changes to disk for every single imported event record. This repetitive disk I/O, combined with unrestricted file sizes, allowed attackers to exhaust server memory and CPU cycles.

Additionally, the absence of protocol and domain restrictions enabled attackers to supply non-HTTP schemes such as file:// to fetch arbitrary local server files. The system also accepted URLs pointing to loopback or private networks, turning the server into a proxy for internal scanning. Finally, the calendar fields permitted malicious URI schemes like javascript: to be saved as active hyperlinks, introducing stored XSS vectors into the CMS frontend.

To address these vulnerabilities, the developers introduced substantial structural changes in commits 1e3c83c15a24d1a789cdb012593505bc5620e28e and 4de5eb3ea9e4f7f1781622e6d64fc086629d1437. The key updates replaced basic urllib calls with streaming requests objects and integrated syntactic validators.

The updated download implementation enforces binary size limits and prevents infinite redirect loops during retrieval. The logic now raises a ValueError if the HTTP headers or the actual payload size exceeds configured bounds.

Below is the comparison of the network retrieval mechanisms before and after the remediation:

# VULNERABLE CODE
# Allowed uncontrolled resource download and file:// schemas
ical_resource = urllib.request.urlopen(ical_url).read()
 
# PATCHED CODE
# Implements size limits, redirects prevention, and explicit timeouts
def download_ical(url, limit=MAXIMUM_ICAL_IMPORT_SIZE_BYTES):
    if limit <= 0:
        raise ValueError('You must pass a limit for the number of bytes.')
    
    response = requests.get(url, stream=True, allow_redirects=False, timeout=3.5)
    response.raise_for_status()
 
    length = response.headers.get('Content-Length')
    if length and int(length) > limit:
        raise ValueError('Content-Length header too large')
 
    # Limit chunk iteration to prevent downloading massive data streams
    for chunk in response.iter_content(limit + 1):
        if len(chunk) > limit:
            raise ValueError('Downloaded too much content.')
    return chunk

The fix also introduced the no_file_protocol_url validator, which restricts the destination domain. It blocks ports in URLs, stops single-label hostnames, and rejects IP notation to neutralize SSRF and local file disclosures.

Exploitation of these flaws requires authenticated access as an editor with permissions to configure or trigger an iCalendar import. Although authentication is required, many CMS installations grant event creation privileges to broad directories of low-privileged users.

To execute a Denial of Service attack, the attacker hosts a crafted .ics file containing hundreds of thousands of valid event definitions or a highly nested recursive structure. Upon submitting the URL to the Plone importer, the server begins retrieving the file and initiating individual ZODB commits. The server quickly reaches maximum CPU utilization, disk write bottlenecks, and eventually experiences memory exhaustion, crashing the daemon process.

To execute a Server-Side Request Forgery or Local File Disclosure, the attacker registers an import source pointing to local paths. By specifying file:///etc/passwd, the importer reads the local operating system file, which is then parsed as an iCalendar stream. Errors raised during parsing can leak snippets of the local file contents through application stack traces or logs.

The combination of Denial of Service, SSRF, and Stored XSS yields a CVSS Base Score of 9.1, indicating a critical security impact. The scope of the vulnerability is classified as changed because an attacker can leverage the application's network privileges to access external and internal systems.

While the Denial of Service impact primarily affects system availability, the SSRF vulnerability exposes highly sensitive backend infrastructure. On modern cloud architectures, this can allow attackers to probe local metadata endpoints (such as 169.254.169.254) and retrieve sensitive instance credentials or API tokens.

Lastly, the stored XSS vector jeopardizes the confidentiality of administrative sessions. If an administrative user views the imported calendar event containing a malicious URL, the payload executes in their browser, potentially leading to administrative session takeover or remote code execution via administrative endpoints.

The implementation of syntactic filters significantly reduces the attack surface, but several theoretical bypasses remain due to the reliance on string-based checks rather than structural resolution.

First, the no_file_protocol_url function does not resolve domain names to IP addresses before initiating the request. This leaves the system vulnerable to DNS Rebinding attacks, where an attacker-controlled domain initially resolves to a safe public IP to pass the string validation, but subsequently resolves to 127.0.0.1 during the socket connection phase.

Second, the IPv4-centric parser splits the domain string by dots to identify integer-based IPs. This parser fails to account for bracketed IPv6 notation, which may allow attackers to bypass the check and access local IPv6 interfaces (e.g., http://[::1]). System administrators must implement operating system or firewall-level controls to fully isolate outbound traffic.