CVE-2026-92553: YaySMTP <= 2.7.7 - Authenticated (Subscriber+) Arbitrary File Upload via Attachment Filename Extension

Q: Which deployments are most exposed to remote code execution?

Deployments using nginx are exposed because nginx ignores the plugin's .htaccess guard. Apache deployments with AllowOverride None are also exposed for the same reason; on these configurations, an authenticated subscriber or higher-level user can upload a potentially executable file.

Q: What level of access does an attacker need?

The attacker must be authenticated with at least subscriber-level WordPress access. No user interaction is required, and the issue is rated low complexity over the network.

Q: Are default installations necessarily protected by the plugin's guard?

No. The plugin relies only on a .htaccess file containing 'Require all denied'; that protection is silently ineffective on nginx and on Apache when AllowOverride is set to None.

Q: What can be done while patching is unavailable?

Prevent untrusted subscriber-or-higher accounts from accessing the affected upload functionality, and ensure uploaded attachment files cannot be executed by the web server. Do not rely on the plugin's .htaccess guard if the site uses nginx or Apache with AllowOverride None.

Published Oct 16, 2026

Updated

The YaySMTP – WP Mail SMTP with Email Logs, Tracking & Reports plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 2.7.7 via the putFile function. This is due to insufficient file type validation in the putFile function, as sanitizefilename() does not strip executable extensions and no allow-list, MIME check, or safe-extension rename is applied. This makes it possible for authenticated attackers, with subscriber-level access and above, to upload files that may be executable, which makes remote code execution possible. The only server-side guard is a .htaccess file containing 'Require all denied' written by writeGuards(), which is silently ignored by nginx and by Apache configured with AllowOverride None, meaning RCE is fully achievable on those server configurations.

Affected Software

1 affected component

YaySMTP YaySMTP – WP Mail SMTP with Email Logs, Tracking & Reports<=2.7.7

Event History

Oct 16, 2026

CVE Published

via MITRE·06:41 AM

Data Sourced

via MITRE·06:41 AM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are most exposed to remote code execution?

Deployments using nginx are exposed because nginx ignores the plugin's .htaccess guard. Apache deployments with AllowOverride None are also exposed for the same reason; on these configurations, an authenticated subscriber or higher-level user can upload a potentially executable file.

What level of access does an attacker need?

The attacker must be authenticated with at least subscriber-level WordPress access. No user interaction is required, and the issue is rated low complexity over the network.

Are default installations necessarily protected by the plugin's guard?

No. The plugin relies only on a .htaccess file containing 'Require all denied'; that protection is silently ineffective on nginx and on Apache when AllowOverride is set to None.

What can be done while patching is unavailable?

Prevent untrusted subscriber-or-higher accounts from accessing the affected upload functionality, and ensure uploaded attachment files cannot be executed by the web server. Do not rely on the plugin's .htaccess guard if the site uses nginx or Apache with AllowOverride None.

CVE-2026-92553: YaySMTP <= 2.7.7 - Authenticated (Subscriber+) Arbitrary File Upload via Attachment Filename Extension

Affected Software

Event History

Frequently Asked Questions

Which deployments are most exposed to remote code execution?

What level of access does an attacker need?

Are default installations necessarily protected by the plugin's guard?

What can be done while patching is unavailable?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are most exposed to remote code execution?

What level of access does an attacker need?

Are default installations necessarily protected by the plugin's guard?

What can be done while patching is unavailable?