Jfarthing84 Theme My Login vulnerabilities

3 vulnerabilities

Known vulnerabilities in Jfarthing84 Theme My Login, newest first, with CVSS severity, EPSS, KEV listings, ransomware use and the affected versions.

9.8CVE-2026-89079jfarthing84theme my login
EPSS score
0.29%
The Theme My Login plugin for WordPress is vulnerable to privilege escalation via account takeover in versions up to, and including, 7.2.1. This is due to the plugin not properly validating a user's identity prior to updating their password. This makes it possible for unauthenticated attackers to change arbitrary user's passwords on multi-site setups in certain configurations.4.3CVE-2024-7422jfarthing84theme my login+1
EPSS score
0.20%
The Theme My Login plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 7.1.7. This is due to missing or incorrect nonce validation on the tml_admin_save_ms_settings() function. This makes it possible for unauthenticated attackers to update the theme's settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. Please note that this only affects multi-site instances.4.3CVE-2026-83628jfarthing84theme my login+1
EPSS score
0.39%
The Theme My Login plugin for WordPress is vulnerable to Missing Authorization in versions up to, and including, 7.1.15 on Multisite installations. This is due to the `tml_ms_signup_handler()` function's `gimmeanotherblog` branch failing to enforce the network's `active_signup` registration policy, checking only `is_user_logged_in()` while sibling branches such as `validate-blog-signup` apply the full policy gate. This makes it possible for authenticated attackers, with Subscriber-level access and above, to directly POST `stage=gimmeanotherblog` to Theme My Login's signup route, bypassing the configured registration policy entirely — even when it is set to `none` or `user` — which causes `wpmu_create_blog()` to execute with the attacker's user ID, after which WordPress core assigns the Administrator role on the newly created subsite via `add_user_to_blog()`. The privilege gain is scoped to the newly created subsite only; the attacker's account retains Subscriber-level access on the main site and does not obtain Super Admin or network-level capabilities such as `manage_network` or `manage_sites`.