ApostropheCMS Form EUVD-2026-105185

Exploitation requires a publicly reachable ApostropheCMS Form add-on (@apostrophecms/form) submission route prior to version 1.5.5, where the multipart upload is staged to temporary disk before form validation or authentication occurs. The specific prerequisite is simply that at least one form built with this add-on is exposed to untrusted clients - the default behavior lacks upload size, count, and rate limits, so no special configuration is needed to exploit it. Limiting factors: impact is confined to availability (temporary disk/host disruption, not data compromise); effectiveness depends on the host's available temp storage and any external rate-limiting, reverse-proxy upload caps, or WAF controls in front of the application, which can blunt the attack.

This is a genuine but low-to-moderate priority issue, correctly rated 5.3 (Medium). The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L is internally consistent with the description: a remote, unauthenticated, low-complexity attack with no confidentiality or integrity impact and only partial (A:L) availability impact - a resource-exhaustion denial of service, matching CWE-770 (Allocation of Resources Without Limits or Throttling). No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis. The low impact ceiling (A:L, Scope:Unchanged) reflects that an attacker can disrupt form handling or temporarily affect the host via temp-disk exhaustion but cannot read data, alter data, or take over the system. Weigh this as a hygiene/patch-when-convenient item rather than an emergency: the ease of exploitation (PR:N/AC:L) raises nuisance potential, but the capped impact and absence of any exploitation signal keep real-world risk modest, further tempered by the niche deployment footprint of ApostropheCMS.

An attacker script repeatedly POSTs large multipart file uploads to a public ApostropheCMS form endpoint without authenticating. Because uploads are buffered to temporary disk before validation and there are no size, count, or rate limits, the flood fills the temp storage and degrades form processing and potentially other services on the same host. No public exploit code is identified, but the attack requires only a trivial HTTP client given the network vector and low complexity (AV:N/AC:L).