SURIQ
FunnelKit's checkout and thank-you pages exist to show a customer their own order. A flaw disclosed on October 15 turns that convenience into a public records desk: on an affected store, anyone with no account and no login can read the customer name, home address, email, and phone number tied to any order, simply by asking for it by number. The fix, version 3.17.0, is already out. The urgent question for a store owner is not whether to patch, but whether their store is one of the ones actually exposed.
Tracked as CVE-2026-107746, the issue sits in FunnelKit, the Funnel Builder for WooCommerce Checkout plugin that runs on more than 30,000 WordPress stores. Wordfence, which assigned the identifier, rates it 7.5 on the Common Vulnerability Scoring System (CVSS) scale and classifies it as a missing authorization flaw, meaning the software does not check that the requester is allowed to see the data. Every release through 3.16.0.6 carries the bug; 3.17.0 closes it. The researcher credited as Kuba reported it, and as of publication there is no public proof-of-concept and no report of exploitation in the wild.
What the flaw exposes, and what it does not
This is a confidentiality bug, not a takeover. The CVSS vector marks the impact to confidentiality as high and both integrity and availability as none, which matches the behavior: an attacker reads data, but cannot change an order, place one, or gain a foothold on the site. What leaks is personally identifiable information (PII), the customer billing details WooCommerce stores for every order: full name, address, email, and phone number. No passwords and no payment card numbers are in scope here.
That lower ceiling is exactly why this one deserves attention rather than a shrug. A pure data leak will never earn a spot on an emergency patch list the way a remote code execution bug does, so it tends to sit unpatched for months while quietly bleeding customer records. For the store operator, a silent leak of customer names and addresses is also a data-protection problem, not only a security one.
Why an enumerable sequential order ID is the real teeth
The advisory's own phrasing, that the data is retrieved by submitting an enumerable sequential order ID, is the part worth slowing down on. WooCommerce order numbers are sequential WordPress post identifiers: order 1,000 is followed by 1,001, then 1,002. An attacker does not have to guess anything. They count. Starting from a low number and walking upward, a script can pull the entire order history of a store in sequence, one record at a time, until it runs out of orders.
That is the difference between a leak of one record and a leak of the whole customer list. A random, unguessable token would have contained the damage to whatever single order an attacker already knew about. Sequential numbering removes that friction and turns a single-record disclosure into a full scrape. It is a recurring lesson, and not a FunnelKit-specific one: predictable identifiers are a force multiplier for any access-control mistake sitting behind them.
Are you actually exposed? Check for the shortcode
The install count sounds alarming, but the real reach is narrower than 30,000. Per the advisory, the leak is reachable only on stores where a FunnelKit thank-you page renders one of the plugin's order-detail shortcodes, the tags that print order metadata or the order total onto the confirmation page. A store that uses FunnelKit for funnels but never built a public thank-you page around those shortcodes is not exposed through this path.
So the first triage step is not do we run FunnelKit but does any published page render those order-detail shortcodes. If one does, treat the store as exposed and act now. If none does, you still patch, because the next person to edit a thank-you page template should not be able to reopen the hole by accident.
What to do now
Update FunnelKit to 3.17.0. That is the whole fix, and on most WordPress stores it is a one-click plugin update. If you manage stores for clients, push the update across all of them rather than waiting for each to notice, the same discipline any WooCommerce plugin advisory deserves.
If you genuinely cannot patch within the hour, the interim move is to pull the FunnelKit order-detail shortcodes off any public thank-you page until you can, which removes the reachable surface without touching the rest of your funnels. Then look backward. A leak that works by counting shows up in your web server access log as a run of requests walking sequential order numbers from a single source. This surfaces the pattern:
grep -E "POST .*[?&](order_id|order)=[0-9]+" access.log \ | awk '{print $1, $7}' \ | sort | uniq -c | sort -rn | head -20
One source address paired with a long, climbing run of order numbers against the same thank-you URL is the tell. A handful of real customers opening their own confirmation pages looks nothing like a machine counting from one upward. If you find that pattern dated before your patch, treat the exposed order details as a customer-data exposure and handle it under whatever data-protection rules apply to you. For teams with managed detection in place, that climbing run of order numbers is exactly the sort of anomaly log monitoring is meant to catch before the scrape finishes.
FunnelKit is not having a quiet stretch on this surface: a separate unauthenticated cross-site scripting flaw, CVE-2026-100147, landed in version 3.16.0.5 just before this one. The checkout and thank-you path is a structural soft spot across the WooCommerce plugin world, because it legitimately needs to read order data and is, by design, reachable by the public. Any plugin that renders order records on a page a stranger can load is worth the same two questions: who is allowed to ask, and are the identifiers guessable.