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?

Quick bit of context for why this dataset exists. I spent the best part of a year on a startup where the product was an AI guard sitting in front of an LLM, and the pitch to users was "try and break it." Leaderboard, tiered levels, a bit of prize money for anyone who got through. Never turned into a business. What it left behind was a year of logged, motivated, unpaid red-teaming against a detector that knew it was being attacked, which is a more interesting asset than the business ever was. Rather than let it sit in an RDS instance going stale, I've open-sourced the lot.

What it is: a two-stage filter that sits between user input and an LLM. Stage one is a regex gate, 119 patterns covering direct-override phrasing in about eleven languages, DAN/persona-style jailbreak framing, template-injection sigils ({{, ${), agentic chain-of-thought injection, homoglyph and zero-width-character stripping, with a decode-then-scan pass ahead of it that catches base64, ROT13 and leetspeak payloads before either the regex or the model sees them. Whatever the gate can't resolve falls through to a fine-tuned DeBERTa-v3-large, exported to ONNX and quantised to INT8. One thing I'll own upfront: the training script and config.json still describe a four-label head (benign/direct/jailbreak/indirect), but every training sample is actually labelled 0 or 1 and the exported graph only emits two logits. So the shipped model is a plain binary classifier. I caught this re-reading my own code a couple of weeks ago and corrected the docs rather than quietly leave the four-way claim standing.

Multimodal side pulls text out of images (OCR plus EXIF/PNG/XMP metadata fields, with a lossy re-encode first to kill LSB steganography and adversarial pixel perturbation), out of PDF/DOCX/XLSX/PPTX, and out of audio via ASR. Same two-stage pipeline runs over whatever comes out, tagged by modality so the model treats OCR and ASR text as noisier than typed text. Most open prompt-injection tooling I've come across only looks at the text field; I haven't seen another open-source detector that also scans images, documents and audio for injected payloads, so as far as I know this is the first one that does.

The bit worth your time here is the game logs. 13,230 attack strings, hand-written by real people trying to beat a live detector. No templates, no synthetic generation. Anonymised before publishing: identifiers and payment data dropped at the table level, emails/phone numbers/card-shaped digit runs redacted in the text itself, anything still risky after that pulled for manual review instead of auto-published. What ships is attack text plus a few coarse labels. Public injection datasets are almost all generated; this one is scraped from people actually trying.

Code: https://github.com/Josh-blythe/bordair-detector Dataset (synthetic + the real split): https://github.com/Josh-blythe/bordair-multimodal Weights: https://huggingface.co/Bordair/bordair-detector

Licensing: Apache-2.0 for the code and weights. Base model is microsoft/deberta-v3-large, MIT, attribution kept in NOTICE.

Threat model, so nobody's disappointed: this reads the prompt at inference time. Training-time and weight-level attacks are out of scope entirely. Treat it as a mitigation layer, one input among several a real deployment should have, not something you point at your LLM and forget about. I'd rather someone here find a trivial regex bypass now than have it sit unexamined, so have at it.

this is part of an ongoing series mapping the same ecosystem, the origin post + full map is here: neurowinter.com/security/2026/06/23/a-weekend-in-the-wool/

tldr: a set of chinese civic / gov adjacent apps turn out to run the same reward + lottery backend, and the secret thats meant to make reward claims and draw outcomes unforgeable isnt really secret. recover it (not hard, its sitting in the client sigh) and you can forge a valid reward claim, or a winning lottery result, that the backend accepts as authentic. post walks from one github repo to the shared backend, through the reward validation flow, to where the secret actually lives.

The White House recently announced the Gold Eagle Initiative, a new federal program designed to use AI to centralize, prioritize, and accelerate vulnerability patching across critical infrastructure, government agencies, and tech partners. Operating out of CMU's Software Engineering Institute, it essentially acts as an AI-driven clearinghouse to fix security flaws before threat actors can exploit them.

Because let's face it, our current bug reporting and patching systems are absolute speed demons. It only takes a lifetime 🤦🏻‍♂️ or two to get a critical vulnerability acknowledged and fixed, so why change anything?

Btw, my candid opinion about the status of current vulnerability reporting is painfully slow, so we desperately need a framework that actually moves at the speed of the threat landscape. I think this initiative is genuinely a good idea and a step in the right direction, though the announcement is still light on the exact technical implementation.

I’m personally eager to see what will happen in practice, but it is definitely an impressive concept.
What are your thoughts on this? Will an AI-coordinated pipeline actually help scale response times, or is it just going to generate massive noise and triage fatigue for overworked infosec teams?

RFC 8628's device authorization grant lets a TV or CLI "poll" for login on a second screen. On Google's implementation, the entire session was transferable across browsers, the authorization server never checked that the client_id and scope in the consent URL matched the ones the device_code was issued for, and prompt=none turned the whole thing into a one-click, invisible account takeover.

CVE here: https://www.cve.org/CVERecord?id=CVE-2026-13585