high · CVSS v3 7.5 · EPSS 0.00147

CVE-2026-111949

The miniOrange 2FA WordPress plugin (v<6.3.1) allows an attacker who knows a user’s password to register an additional passkey on an account

Overview

The miniOrange 2FA WordPress plugin (v<6.3.1) allows an attacker who knows a user’s password to register an additional passkey on an account that already has one configured, effectively bypassing the second factor. This flaw can lead to unauthorized account access on WordPress sites using the plugin. The vulnerability is rated high severity with a CVSS v3 score of 7.5.

Description

The miniOrange 2FA WordPress plugin before 6.3.1 does not prevent a pending passkey login from registering an additional passkey on an account that already has one configured, allowing an attacker who knows a user's password to add their own authenticator and bypass the second factor.

Impact

Confidentiality: attackers can gain unauthorized access to user accounts. Integrity: attackers can modify account settings or add malicious authenticators. Availability: not directly impacted. Site administrators and end‑users are the primary stakeholders.

Remediation

Update the miniOrange 2FA plugin to version 6.3.1 or later, which fixes the passkey registration issue. If an update is not immediately possible, disable passkey login or enforce a stricter MFA policy that requires a separate authenticator device. Monitor plugin updates and apply security patches promptly.

Risk context

The vulnerability is classified as high severity with a CVSS v3 score of 7.5, but the EPSS score of 0.00147 indicates a low likelihood of exploitation. Defenders should treat it as a moderate‑to‑high risk and prioritize patching.

Affected products

  • miniOrange 2FA
  • WordPress

Scores

Severity
high
CVSS v2
7.1
CVSS v3
7.5
CVSS v4
—
EPSS
0.00147

WordPress miniOrange 2FA MFA Authentication CVE-2026-111949

← All CVEs

Related CVEs

high

CVE-2026-98507

In the Linux kernel, the following vulnerability has been resolved: mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't v ---truncated---

View analysis

high

CVE-2026-111948

The User Profile Builder WordPress plugin before 4.0.1 does not escape the current page URL before outputting it in a JavaScript context on one of its admin pages, leading to Reflected Cross-Site Scripting against high-privilege users.

View analysis

high

CVE-2026-79627

The Advanced File Manager WordPress plugin before 6.0.0 does not correctly determine whether a stored file is an SVG before sanitising it, allowing users granted file-manager access by an administrator to store a file containing script that is not stripped and that runs in the browser of anyone who opens it, including an administrator.

View analysis

high

CVE-2026-81813

The Elementor Website Builder WordPress plugin before 4.3.5 does not sanitize the text content of SVG files, checking only their elements and attributes, allowing users with the Contributor role and above to store a payload which breaks out when the SVG is rendered inline in a page and executes in the browser of any user viewing it. Execution is specific to Chromium-based browsers; Firefox is not affected.

View analysis