YaySMTP EUVD-2026-102789

Requires an authenticated account at subscriber level or above (PR:L), which is commonly available where open user registration is enabled on WordPress. Full remote code execution is achievable only on nginx, or on Apache configured with AllowOverride None, because these ignore the '.htaccess Require all denied' guard written by writeGuards(); on Apache honoring .htaccess, that guard blocks execution of the uploaded file and limits impact to file write without reliable RCE. The vulnerability exists in all YaySMTP versions up to and including 2.7.7 due to putFile relying on sanitize_file_name(), which does not strip executable extensions and applies no allow-list, MIME check, or safe-extension rename. The primary limiting factors are the required authentication level and the server's handling of .htaccess directives.

This is a genuine high-priority issue on the affected product, though its real-world severity is strongly conditioned by server configuration. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity attack requiring only low privileges, with full C/I/A impact consistent with the CWE-434 arbitrary file upload leading to RCE. The low privilege requirement is significant: WordPress sites commonly allow open subscriber registration, so PR:L is often trivially satisfied, effectively turning this into a near-unauthenticated RCE on many deployments. The description is internally consistent with the vector and credibly explains the I:H/A:H/C:H rating via code execution. However, note conflicting/limiting signals: the vendor advisory itself states the only server-side guard (a '.htaccess Require all denied' from writeGuards()) is bypassed only on nginx or Apache with AllowOverride None - on Apache honoring .htaccess, upload may succeed but code execution is blocked, reducing impact to file write without guaranteed RCE. No EPSS score, KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the real-time exploitation probability signal is therefore absent. Treat as a priority to patch due to low attack complexity and widely-satisfiable privilege requirement, while recognizing exploitability-to-RCE depends on web server configuration.

An attacker registers or obtains a subscriber-level account on a WordPress site running YaySMTP ≤ 2.7.7, then abuses the putFile function to upload a PHP file because sanitize_file_name() does not strip executable extensions and no allow-list/MIME/safe-rename is applied. On nginx or Apache with AllowOverride None, the uploaded script is directly requestable and executes, yielding remote code execution. No public proof-of-concept was provided in the input, so no public exploit is identified at time of analysis.