Between October 30 and November 1, 2026, five vulnerabilities across three WordPress plugins moved through the usual disclosure path: notices published by WPScan on October 30, then indexed by Patchstack on November 1. They are not one kind of flaw. The set is a mixture of information disclosure, missing authorization checks that allow email abuse, and stored cross-site scripting, which is an output-escaping flaw rather than an access-control one. This roundup covers each product separately, with its own applicability, action and sources. It was checked as of November 2, 2026.

One framing point before the details. These are conditional update needs. A site is affected only if it runs one of the named plugins below the fixed version listed. The notices do not establish that any WordPress site has been compromised, and they do not establish the opposite either.

MapPress

Applies to: plugin slug mappress-google-maps-for-wordpress, versions below 2.97.15. Fixed in 2.97.15.

What the notice establishes: CVE-2026-118168 is an unauthenticated information disclosure. A front-end map embed handler could be used to enumerate user IDs and return the email address and display name of each user. No login is needed. The WPScan notice was published and last updated on October 30, 2026 and credits vuxvinh. The plugin changelog for 2.97.15 describes fixing user details exposed through the map embed URL and removing email from user mashup popups.

Action: update to 2.97.15 or later, then open a page with a contact or location map and confirm it still renders. The disclosed data is email addresses and display names. The notice does not describe password or payment data exposure.

Kali Forms

Applies to: plugin slug kali-forms, versions below 2.4.30 for both CVEs. Fixed in 2.4.30.

What the notices establish: both issues need a logged-in account at Subscriber level or above. A public contact form submission by an anonymous visitor is not enough on its own. Sites that allow open registration should therefore treat these as higher priority.

  • CVE-2026-107343: the test-email handler lacked a capability check, and the nonce it required was available to any logged-in user. A Subscriber could send email to an arbitrary recipient with a spoofed sender address. WPScan notice, published October 30, credited to Sai Praneeth Koti.
  • CVE-2026-107342: under the same condition, the plugin could disclose email addresses of registered users, including administrators. WPScan notice, published October 30, credited to Usama Arshad.

The vendor changelog confirms that 2.4.30 restricts test mail to administrators and valid addresses. The current release, 2.4.31, also fixes a problem with administrators opening settings and form entries, and limits entries to administrators.

Action: 2.4.30 is the security floor. We recommend moving to 2.4.31 or later so you also receive the administrator fixes. After updating, submit a legitimate form and confirm the notification arrives, then open the plugin settings as an administrator. As a practical check, review your mail logs, and review any accounts or access you no longer need under your own process. Treat this as housekeeping, not as proof that abuse occurred. The notices do not claim any bypass of SPF or DKIM.

Media Library Assistant

Applies to: plugin slug media-library-assistant, versions below 3.44 for both CVEs. Fixed in 3.44.

What the notices establish:

  • CVE-2026-113482: a Contributor or higher could store cross-site scripting through the mla_item_parameter shortcode attribute. Its value was output, without escaping, into a link attribute that the plugin generates. WPScan notice.
  • CVE-2026-113481: a Subscriber or higher could learn the taxonomy term assignments of private posts and attachments because the handler did not check view authorization. This is limited to term assignments. The notice does not describe downloading private files, reading post bodies, or exposing all metadata. WPScan notice.

Both notices were published on October 30 and credit Karthik Ramakrishnan. The vendor changelog for 3.44 confirms the stored XSS and exposure fixes, alongside other fixes that are outside this roundup.

Action: update to 3.44 or later, then test galleries and media listings. Review which accounts hold Contributor or Subscriber roles and whether each still needs them.

Practical checklist for owners and providers

These are practical checks, not vendor requirements.

  1. Inventory what is actually installed: plugin slug and exact version, on each site you manage.
  2. Back up the database and files before changing anything.
  3. Use your normal testing or maintenance route, such as a staging copy, if you have one.
  4. Where a matching plugin and version is in use, update that product as described above. This does not replace your regular updates for other plugins, themes and WordPress core.
  5. Confirm the deployed version, then test the relevant pages, forms, galleries and mail delivery.
  6. If anything looks unusual, inspect it: unexpected accounts, outbound mail you did not send, or unfamiliar scripts in content. Escalate abnormal account, mail or script activity rather than assuming an update settled it.

Business implications

If staff email addresses are disclosed, they can be used for phishing aimed at your team, and administrator addresses are especially valuable targets. If a logged-in low-privileged account can send spoofed mail through your form plugin, messages that appear to come from your business could reach customers or partners and damage trust. If a Contributor can store script in a gallery or media listing, that script could run for anyone who views the affected page, including editors and administrators with higher privileges. Each of these depends on the conditions above: the plugin and version must be in use, and for four of the five issues an attacker needs a logged-in account. We recommend timely, risk-based maintenance. Sites with open registration or many low-privileged accounts should move first.

Remaining limits

The opened notices establish affected versions and the privilege needed. Patchstack records from November 1 corroborate those ranges and privilege levels. The notices do not establish active exploitation, and this article does not claim there has been none. Updating closes these specific paths but is not a retrospective clearance of past incidents. Removing an unused plugin is sensible maintenance, but deactivation should not be assumed to neutralise every path. ViWeb has not scanned or remediated any third-party site as part of this writing.

Further reading