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 traditional vulnerability disclosure timeline relies on a fundamental assumption: exploit development and vulnerability discovery take time. Over the last 12 months the integration of LLMs into offensive tooling has demonstrably broken this assumption.
I recently published a technical write-up arguing that the 90-day disclosure window is effectively dead backed by three specific observations from recent incidents:

1. Automated Diff Analysis (30-minute n-days) : The safety net between a patch release and an in-the-wild exploit is gone. Taking a recent React security patch (CVE-2026-23870), I used an LLM to analyze the diff, identify the vulnerable path, and write a working DoS PoC in roughly 30 minutes. The human reverse-engineering bottleneck has been bypassed.
2. Vulnerability Convergence : I recently reported a critical P0 to a vendor and was told I was the 11th reporter in 6 weeks. LLM assisted scanners are causing independent researchers to converge on the same bugs simultaneously. An embargo no longer contains the vulnerability; it simply provides a head start to whichever threat actor also found it.
3. The Linux Kernel (Copy Fail & Dirty Frag) : The recent kernel exploits highlight this perfectly. Copy Fail (CVE-2026-31431) went from an automated AI scan to a public PoC to nation state weaponization in days. Shortly after the embargo for Dirty Frag (CVE-2026-43284 / CVE-2026-43500) was broken in hours because an unrelated third party independently discovered the same bug class using similar tooling.

The defense cannot operate on monthly cycles when the offense is operating in hours. The focus needs to shift to real-time, PR-level AI scanning to match the pace.
can read the full technical breakdown and case studies on my blog:https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/

I am curious if the researchers here are experiencing similar convergence rates or if you view this as a temporary anomaly while legacy codebases are scanned with new tools.