Answer in brief
CVE-2026-83628 records a Unknown severity vulnerability in Theme My Login <= 7.1.15 - Authenticated (Subscriber+) Missing Authorization to Unauthorized Multisite Subsite Creation via 'gimmeanotherblog' Signup Stage. The current sources do not mark it as known exploited. The current feed maps jfarthing84/Theme My Login (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps jfarthing84/Theme My Login (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| jfarthing84/Theme My Logingeneric | 0 | Not reported |
Published upstream
Sep 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 5, 2026
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`.
Quoted source text, attributed separately from HOL analysis.