captaincrank

Would explain why so many have reported slow and sites that time out. I haven’t made the plunge to upgrade, and probably won’t for a while until these issues get ironed out.

WC 8.5 is not secure.

“The WooCommerce plugin for WordPress is vulnerable to Reflected Cross-Site Scripting in all versions up to, and including, 8.4.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. Additional Information From WooCommerce Slack: For those who are not yet aware, on Tuesday there was an issue with our release of 8.5. The problem was identified, we reverted the stable tag to 8.4 (effectively preventing 8.5 from being downloaded further) and communicated the known issue in the release notes. The issue has since been fixed. However, for the sake of comprehensive testing around the fix release and in order to address a few other minor problems, we are delaying version 8.5.1 until Monday, January 15th. We are digging into how the issue was able to be released and will be addressing this internally as necessary to prevent future disruptions. I would also like to acknowledge the general lack of communication around this issue until now. This is another area we are investigating and are hopeful to improve in the future. Thank you for your patience as we get this fully resolved.”

Why would you install 8.5.0 on six sites knowing it has a security vulnerability? 8.4 is the one that should be installed until they release 8.5.1 on Monday that fixes 8.5.0?

We haven’t upgraded because of all the bugs and emails are fine in 8.4. You may want to check your server error logs and/or install the WP Mail Logging plugin to identify errors. We also use WP Mail SMTP plugin which helps to get beyond free email provider mail filters.

Edit: It looks like they pulled 8.5, likely due to enormous bugs and site crashes.

WordHab, you can download the last working version at: https://downloads.www.ads-software.com/plugin/google-sitemap-generator.4.1.13.zip

Be blessed

Thanks for your response. Internal support at WC has the system report and login details for a staging copy to replicate the problem with all plugins disabled. I’ll mark this thread as resolved since it’s being handled outside of this forum. Thanks for your help and happy holidays!

I tried a chat in WC account, but nobody responded. Hopefully they get the full text where I referenced this thread and provided a link to the video.

Using the visual editor, each time the product page is saved a new non breaking space is added. We usually only modify the product pages to update inventory, which is why this post title referenced updating inventory.

• This reply was modified 1 year, 3 months ago by captaincrank.

Thanks for your reply Peter. The problem appeared to resolve itself a couple hours after I made my post here. Likely a temporary connectivity issue somewhere. I’ll mark this thread as resolved.

Thank you for your response. Based on the information you provided, I will perform more research on our side. Have a good day.

Previous version at: https://downloads.www.ads-software.com/plugin/woocommerce.7.6.1.zip

We do have Wordfence Security Premium installed and at best I can rate limit the IP which would also impact mobile users. I can and did ban IPs, and all the attacker does is move onto another IP. For the now $129 yearly fee for Wordfence, it would be nice if they would add some features for us Woocommerce users.

The big concern here are swipe fees. Even though not one transaction was accepted, we will probably get hit with a lot of swipe fees. At $.30 per swipe, times 1,000 failed orders, that’s $300. I’m not sure how Stripe handles this, but I know other processors don’t care and bill the sellers. It would be nice if some protections from carding/credit card testing were built into the Woocommerce Stripe Payment Gateway plugin. Loading up a DB with hundreds or thousands of failed orders, and potentially being socked with huge fees, isn’t something any store owner likes. Heaven forbid some of these tests get accepted and result in chargebacks.

For anyone reading this post with the same problem, look into the free Checkout Rate Limiter plugin. This will limit orders from the same IP with the number of orders and time configurable via plugin. This won’t stop the attacker from attempting to test credit cards, but it will make the attacker burn through a lot of IP addresses in the process – likely forcing them onto another Woocommerce store that isn’t protected. See https://github.com/BrianHenryIE/bh-wc-checkout-rate-limiter

I am pleased to report the callbacks from ShipStation’s IP 18.211.231.40 are now sending data and updating orders as completed with tracking info as expected. My guess is there was a problem with their server sending empty data. We did not update anything and am running the latest version of this plugin with the older version of WC (6.9.4) as we await some bugs to be fixed in WC 7.

Rolling back the plugin to V. 4.2.0 did not resolve the problem for us and is isolated to communications from ShipStation’s IP 18.211.231.40. FWIW, our site is hosted with SiteGround. We also have WordFence installed, and when active we can see all calls to ShipStation in real-time except those coming from IP 18.211.231.40.

Please post back if you find a solution.

Do you have ShipStation set to “standardize and correct US addresses?” If so, you should be able to click the revert link on orders as needed or disable the setting under settings > selling channels > store setup > edit store details

In the example you provided, it’s not uncommon for ShipStation to remove the street address for those orders shipping directly to a post office box located inside a postal facility. In these case of post office boxes located inside a USPS facility, the street address is not needed and is how USPS has the address stored in their database of validated addresses.

When labels are printed in ShipStation, the callback to WC is handled from a variety of IPs. In a prior setup we had all of their IPs whitelisted in our firewall, which I believe was (7) IP addresses. But our setup changed a few years back, and we didn’t need to whitelist them anymore so I have no idea how many IP addresses they are operating on now.

We have no fatal errors in the WC debug logs and no activity in the WC debug logs either from notifications sent back to WC from ShipStation IP 18.211.231.40. For example, I ran a batch of (4) orders, (3) of which updated the status to processed in WC after printing labels. The activity for the successful status updates are logged, but (1) did not update, is not logged in WC debug logs and the notification came from IP 18.211.231.40.

I can go to server logs and see the connect from IP 18.211.231.40, but it looks like an empty data/quick disconnect from this IP. Here’s a snippet:

HTTP/1.1″ 200 279 “-” “RestSharp/106.3.1.0” | TLSv1.3 | – – 0.001 – 0 NC:000000 UP:-DT

After going to ShipStation, and clicking “notify marketplace” for the order that did not update from IP 18.211.231.40, the notification was sent back to WC from a different IP 52.203.135.90 which was successful. Here’s a snippet of the successful update from IP 52.203.135.90:

HTTP/1.1″ 200 31 “-” “RestSharp/106.3.1.0” | TLSv1.3 | 0.938 0.956 0.956 – 0 NC:000000 UP:-DT

I may roll back to the previous version of this plugin to see if that makes a difference. We’re not blocking that IP, so it must either be the plugin or something on ShipStation’s side. Either way, the workaround for us will be logging into ShipStation and resending those failed notifications as it’s easier than copying and pasting tracking info.