I found and reported an authentication failure in the WPForms PayPal Commerce webhook, the webhook route being public was not the vulnerability as webhooks have to be publicly reachable so that PayPal can deliver events.

The problem was what happened after the request arrived. In affected versions, the handler could process a supported event before establishing that PayPal was actually the sender. In my local lab, a forged event could change the state of a matching payment record. The expected order is:

1. Authenticate the sender 2. Validate the event 3. Change payment state

The affected flow effectively performed steps 2 and 3 without first completing step 1. The issue was fixed in WPForms 1.10.0.5 and is tracked as CVE-2026-4986. Then came the part I found more interesting: triage told me I was reporter #11. That number does not prove exploitation, and it does not tell us the total number of people who found the vulnerability. It does establish a lower bound: at least eleven researchers independently converged on the same trust failure.

The write up covers: \- the vulnerable code path \- my local reproduction \- why payload validation was not sender authentication \- the fallback listener \- the patch \- why duplicate reports may be useful rediscovery intelligence

Full write-up: https://blog.himanshuanand.com/2026/07/reporter-11-10-people-found-the-wpforms-paypal-bug-before-me-cve-2026-4986/

Testing was limited to my own local environment. I am not claiming original CVE credit; I independently rediscovered and reported the issue. Disclosure: I wrote and performed the research, code review and local reproduction.

I used an AI to help copy edit and organize the final article.

Should duplicate report volume affect how urgently a vendor treats a vulnerability?

The WPForms – Easy Form Builder for WordPress – Contact Forms, Payment Forms, Surveys, & More plugin for WordPress is vulnerable to Insufficient Verification of Data Authenticity in versions up to and including 1.10.0.1. This is due to the PayPal Commerce webhook endpoint processing unauthenticated JSON webhook payloads without verifying that the request originated from PayPal using the required HMAC-SHA256 webhook signature, and only checking whether the supplied eventtype is whitelisted before dispatching the attacker-controlled resource data to handlers that update payment records. This makes it possible for unauthenticated attackers who know a valid PayPal subscriptionid to forge PayPal webhook events and modify subscription payment records, such as reactivating a cancelled or suspended subscription by setting its subscriptionstatus to active.

WPForms 1.7.8 contains a cross-site scripting vulnerability in the slider import search feature and tab parameter. Attackers can inject malicious scripts through the ListTable.php endpoint to execute arbitrary JavaScript in victim's browser.

The WPForms – Easy Form Builder for WordPress – Contact Forms, Payment Forms, Surveys, & More plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘fieldHTML’ parameter in all versions up to, and including, 1.9.3.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The WPForms – Easy Form Builder for WordPress – Contact Forms, Payment Forms, Surveys, & More plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.9.1.6. This is due to missing or incorrect nonce validation on the processadminui function. This makes it possible for unauthenticated attackers to delete WPForm logs via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

The Tablesome Table – Contact Form DB – WPForms, CF7, Gravity, Forminator, Fluent plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the setfeaturedimagefromexternalurl() function in all versions up to, and including, 1.1.32. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible in configurations where unauthenticated users have been provided with a method for adding featured images, and the workflow trigger is created.