CVE-2026-55247: 
Python Análise e mitigação de vulnerabilidades

CVE-2026-55247 is a multi-vector vulnerability in plone.app.event, the event content type package for the Plone CMS, affecting versions prior to 5.2.4 and 6.0.0 (fixed in 6.0.1). The flaw resides in the iCalendar import functionality (src/plone/app/event/ical/importer.py), which accepts insufficiently restricted calendar and event URLs, does not bound downloaded bytes or the number of imported events, and commits a transaction per event rather than using savepoints. These weaknesses collectively enable denial of service (DoS), Server-Side Request Forgery (SSRF), and stored Cross-Site Scripting (XSS). The vulnerability was discovered by Timothy Dudley, responsibly disclosed to the Plone Security Team, and published on June 23, 2026, with a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory).

The root cause is uncontrolled resource consumption (CWE-400) combined with insufficient URL validation, classified under GHSA-r82h-mqw3-fc56. Three distinct attack paths exist in importer.py: (1) DoS — the importer used urllib.request.urlopen().read() with no byte limit or timeout, allowing an attacker to supply a URL pointing to a multi-gigabyte file, exhausting server memory; additionally, per-event transaction.commit() calls on large imports could cause FileStorageError; (2) SSRF — the original URL validator only blocked file:// schemes, permitting requests to internal network addresses (e.g., http://192.168.1.1/, http://localhost/, http://host.docker.internal/) or local filesystem calendar files; (3) Stored XSS — event URL fields imported from iCalendar data were not validated for dangerous schemes (e.g., javascript:), allowing a malicious payload to be persisted and executed in other users' browsers. The fix introduces MAXIMUM_ICAL_IMPORT_SIZE_BYTES (default 100,000 bytes) and MAXIMUM_ICAL_IMPORT_EVENTS (default 53) limits, a 3.5-second request timeout, redirect blocking, IP address and internal hostname rejection, and a _normal_url_validator constraint on event URL fields (GitHub Commit 1e3c83c, GitHub Commit 4de5eb3).

A logged-in user with the editor role can exploit this vulnerability to take the entire Plone site offline (DoS), probe and exfiltrate data from internal network services or local files via SSRF, and inject stored XSS payloads into event URL fields that execute in the browsers of other authenticated users — including administrators. The SSRF vector enables lateral movement into backend infrastructure (e.g., cloud metadata endpoints, internal APIs, Docker networks), while the stored XSS can be used for session hijacking or privilege escalation. The scope is marked as Changed in CVSS, reflecting that the impact extends beyond the vulnerable component to other users and internal systems (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is reported as 0.0, and the vulnerability does not appear in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a valid editor-level account on the Plone instance, which limits the attack surface compared to unauthenticated vulnerabilities, though the editor role is commonly granted to content contributors on Plone sites.

1. Obtain editor credentials: Acquire a Plone account with at least the Editor role — this may be through registration on a public Plone site, credential theft, or social engineering.
2. Navigate to the iCalendar import form: Access the iCal import settings page, typically at http://<plone-site>/folder/ical_import_settings or via the folder's action menu.
3. DoS attack: Supply a URL pointing to a very large file (e.g., a multi-gigabyte HTTP resource) as the iCalendar URL. The unpatched importer will attempt to download and process the entire file, exhausting server memory and taking the site offline.
4. SSRF attack: Supply a URL targeting an internal resource such as http://192.168.1.1/calendar.ics, http://localhost:8080/, or http://169.254.169.254/latest/meta-data/ (AWS metadata). The server will fetch the resource and may return or process its contents.
5. Stored XSS attack: Craft a malicious .ics file containing a VEVENT with a URL property set to a javascript: payload (e.g., URL:javascript:alert(document.cookie)). Import this file via the iCal import form. The malicious URL is stored in the event object and executes in the browser of any user who views the event (GitHub Advisory, GitHub Commit 1e3c83c).

• Network: Outbound HTTP requests from the Plone/Zope server process to internal IP ranges (RFC 1918: 10.x.x.x, 172.16-31.x.x, 192.168.x.x), localhost, cloud metadata endpoints (169.254.169.254), or Docker-internal hostnames; large outbound HTTP downloads initiated by the Zope process.
• Logs: Zope/Plone access logs showing POST requests to ical_import_settings or similar iCal import endpoints by editor-role accounts; error log entries containing FileStorageError: description too long or memory exhaustion messages during import operations.
• Application: Plone event objects with event_url fields containing javascript:, data:, file:, or other non-HTTP/HTTPS schemes; event objects with URLs pointing to internal hostnames or IP addresses.
• Process: Unusual memory growth or CPU spikes in the Zope/Plone server process coinciding with iCal import activity; server unresponsiveness or restart events following an iCal import request.

Upgrade plone.app.event to the patched versions: 5.2.4 for Plone 6.0 and 6.1, or 6.0.1 for Plone 6.2 (Release 5.2.4, Release 6.0.1). As a temporary workaround for the DoS and SSRF vectors, navigate to the site root in the Zope Management Interface (ZMI) at manage_access (Security tab), locate the plone.app.event: Import Ical permission, and restrict it to the Manager role only — this prevents editor-role users from accessing the iCal import form. Note: There is no workaround for the stored XSS vulnerability in the event URL field; upgrading to a patched version is the only remediation for this vector (GitHub Advisory).

The vulnerability was responsibly disclosed by security researcher Timothy Dudley to the Plone Security Team and published by Plone maintainer Maurits van Rees on June 23, 2026. The advisory was noted by automated security tracking accounts on X (formerly Twitter) and Mastodon shortly after publication. No significant independent researcher commentary or major media coverage has been identified beyond standard CVE aggregator reporting.