Discourse EUVD-2026-42729

Exploitation requires the attacker to hold a valid regular user account on the target Discourse instance (PR:L per CVSS vector). The Discourse deployment must have direct S3 multipart uploads enabled and configured - this is a non-default configuration requiring an administrator to have set up an S3 bucket and enabled the ExternalUploadManager flow. Instances using local file storage are not affected by this specific code path. What limits exploitation: authentication is mandatory (unauthenticated access is not possible per PR:L); S3 direct upload must be explicitly enabled by an admin; the impact is write-only to the admin backup store - no read access or remote code execution is implied by the available data. On closed-registration or invite-only forums, the attacker pool is further constrained to existing account holders.

The CVSS 3.1 score of 6.5 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N accurately reflects the threat profile: network-exploitable over standard HTTP, low attack complexity, requiring only a regular user account (PR:L), with no user interaction needed. The high integrity impact (I:H) reflects the ability to write arbitrary content into the privileged admin backup store. Confidentiality and availability are unaffected per the vector. EPSS data was not provided in the source intelligence, so exploitation probability cannot be quantified numerically. The vulnerability is not listed in CISA KEV, and no public proof-of-concept has been identified. Real-world risk is moderate but context-dependent: on open-registration Discourse forums, obtaining a low-privilege account is trivial, lowering the effective barrier. The absence of confidentiality impact limits the immediate data exfiltration threat, but integrity compromise of the backup store could enable backup poisoning or interference with disaster recovery operations. No conflicting signals between data sources were identified.

An attacker registers or already holds a standard (non-admin) account on a Discourse instance configured with direct S3 multipart uploads. They initiate an upload via ExternalUploadManager, manipulating the upload destination parameter to target the admin backup store S3 prefix rather than the user content bucket. Because the authorization check is absent, the server completes the multipart upload and stores the attacker-controlled file in the admin backup store, potentially overwriting legitimate backup objects or injecting malicious content into the backup archive. No public proof-of-concept has been identified, but the attack requires only standard HTTP requests and knowledge of the ExternalUploadManager API.