Repository navigation
Releases: ClickClickMedia/CCM-Woo-Defender
Releases · ClickClickMedia/CCM-Woo-Defender
Release list
v1.6.2
v1.6.1
What's Changed
Updated
- Overview "How it works" rewritten to accurately describe current detection signals — removes stale "IP/device consistency" references. Now mentions GeoIP country blocking, gateway fraud auto-detection, manual IP block/whitelist controls, and the specific block token types (IP, email, address).
- Friendly reason labels in History table and CSV exports. Raw slugs are now human-readable:
matched_existing_block→ "Existing block match"suspicious_address→ "Suspicious address"reused_gateway_amount_identity_churn→ "Gateway+amount churn"same_ip_multi_identity→ "IP identity churn"repeat_after_blocks→ "Repeat after block"gateway_fraud→ "Gateway fraud"manual_ip_block→ "Manual IP block"geoip_country_block:XX→ "GeoIP block: XX"- Legacy
same_device_multi_identity→ "Device churn (legacy)"
v1.6.0
What's Changed
Fixed
- Eliminated same-device identity churn signal. The
same_device_multi_identityscoring check used User-Agent hashes as a device fingerprint — UA strings are shared by millions of users and caused cascading false positives. Signal removed entirely;same_ip_multi_identityprovides equivalent coverage using a more reliable identifier. - Fixed blocked_attempts_recent matching. The repeat-after-blocks counter previously matched visitors by
ua_hash(coarse and shared). Now matches only byip_hashandemail_hash. - Manual IP blocks now logged to history.
checkout_process_guard()was blocking manually-listed IPs but skipping event logging, making those blocks invisible in the History tab. Now logs amanual_ip_blockevent with score 999.
Changed
- Auto-purge block tokens on upgrade. On first load after upgrading to 1.6.0, all stored block tokens are cleared to remove contaminated
ua_hashandpayment_hashentries from earlier versions. - Removed "Same device identity churn" weight and threshold fields from Advanced Detection Controls UI (settings keys kept for backward compatibility).
v1.5.2 - Remove payment_hash from block tokens to fix false positives
Bug Fix
- Remove payment_hash from block tokens — The payment signature (gateway + total + country) is shared by every buyer using the same payment method, amount, and country. When a fraudster was blocked, their payment_hash entered the block list and every legitimate customer with the same payment profile was caught by matched_existing_block.
Root Cause
Your colleague at 180.150.45.221 was blocked because the store owner's test order at 180.181.228.227 (braintree_cc, $1.00, AU) was blocked earlier. That block stored the payment_hash for "braintree_cc|1.00|AU" in the block list. Any subsequent $1.00 Braintree order from Australia then matched that token.
This is the same class of false-positive as the ua_hash issue fixed in v1.5.1.
What changed
- payment_hash is no longer stored in the block list when a visitor is blocked
- payment_hash is no longer checked for matched_existing_block on future attempts
- payment_hash is still used for the reused_gateway_amount_identity_churn scoring signal (counts unique emails per gateway+amount+country combo)
Block tokens now only include
- ip_hash (unique per IP address)
- email_hash (unique per email)
- address_hash (unique per billing address)
v1.5.1 - Fix false positives from shared User-Agent tokens
Bug Fix
- Remove ua_hash from block tokens - User-Agent strings are shared by millions of users running the same browser + OS. When a fraudster was blocked, their ua_hash entered the block list and every legitimate customer with the same browser/OS was caught by matched_existing_block, causing cascading false positives.
What changed
- ua_hash is no longer stored in the block list when a visitor is blocked
- ua_hash is no longer checked for matched_existing_block on future attempts
- ua_hash is still used for the same_device_multi_identity scoring signal (counts unique emails per device fingerprint) - this signal contributes to scoring but does not poison the block list
Impact
Eliminates the cascade where one blocked fraudster could cause all users with the same browser version to be blocked. Only genuinely unique identifiers (IP, email, address, payment signature) are now used as block tokens.
v1.5.0 – IP Whitelist, History Export/Search/Sort
New Features
- IP Whitelist – Add trusted IP addresses that always bypass all fraud checks (manual blocks, GeoIP, and scoring). Configured under Settings > Whitelisted IPs.
- History CSV Export – Download the full checkout history as a CSV file from the History tab toolbar.
- History Search – Server-side search across IP address, country, gateway, order ID, status, and more.
- Sortable History Columns – Click column headers to sort by Date/Time, Order, IP Address, Country, Gateway, or Status (ascending/descending).
UI Improvements
- Whitelisted IPs displayed on the Overview tab with green badges.
- New Whitelisted IPs settings card with description and textarea input.
- Search + Export toolbar integrated into the History tab header.
- Sort arrows on active column headers.
v1.4.0 - Gateway fraud auto-block & history deduplication
Added
- Gateway fraud auto-detection. When a payment fails, order notes are scanned for fraud keywords (e.g. Gateway Rejected: fraud, risk_threshold). On first detection the customer IP is auto-blocked and a single BLOCKED event (score 999) is recorded. Keyword list is filterable via
ccm_wd_fraud_patterns.
Fixed
- Duplicate History rows for the same order caused by repeated track_order_outcome calls on each pending-failed status flip.
- Blocked + Allowed inconsistency on Store API orders: cancelled/failed orders that were already blocked by GeoIP no longer get a second ALLOWED event.
v1.3.4
Fixed
- Classic checkout events now show the order number. The
validate_checkoutevent is recorded before WooCommerce creates the order, soorder_idwas always 0. A newwoocommerce_checkout_order_processedhook now backfills the order ID on the most recent event matching the current IP.