MyCryptoCheckout v2.164

Hi everyone, We have rebuilt the API servers and released MyCryptoCheckout v2.164 as a security focused update. This was a tedious process and took some time. This release further hardens plugin-side handling of remote account data, including stricter sanitization before account data is stored, safer handling of checkout wallet-link data, and additional API version handling. For user safety, MCC API access is not being fully restored to normal operation while vulnerable older plugin versions remain installed. Older versions do not include the new account data hardening, and we do not believe it is responsible to restore normal API account data delivery to those versions. We have contacted the WordPress.org Plugin Team to request assistance with a forced or accelerated security update to v2.164. While we wait for their response, please update MyCryptoCheckout to v2.164 manually from your WordPress admin or by reinstalling the latest version from WordPress.org. We will post another update once we know whether WordPress.org can assist with accelerating the update process. Our priority right now is restoring service only in a way that does not expose users running older vulnerable plugin versions. Appreciate the transparency and the work that went into rebuilding the API infrastructure and hardening the plugin. One suggestion for the future: could you implement API version management or version-gated access so that users already updated to v2.164+ are able to operate normally, while older vulnerable versions remain restricted? For example, the API could return full account data only to v2.164+ clients, or just swap api endpoint for later versions. Also, you must have email addresses for those who have active licenses from after they paid you, a mass email sent to them telling users to update their plugin wouldnt hurt either. You can only do so much though (as long as your side is secure). Continuing to keep every merchant cut off from processing payments (for over a week now) while you wait for holdouts isnt great either. I dont really want to keep losing days while Joe Schmo never logs into their WP admin panel. Thanks, both points are fair. We are working through version gated restoration options now to allow API functionality for installations confirmed to be running v2.164 or newer, while older or unknown versions remain restricted until they update. Regarding direct emails: MCC is a open source WordPress plugin, and we do not have complete or reliable contact information for all active installations. We have evaluated whether a limited security/service notice to known account contacts makes sense, but it would not reach everyone and cannot be relied on as the primary update path. That is why we have asked the WordPress.org Plugin Team whether they can assist with a forced or accelerated update to v2.164. We understand merchants do not want service limited while inactive sites may never update. We are trying to balance restoring functionality with making sure the v2.164 security changes are in place first. We will post another update once we know whether WordPress.org can assist or have a restore path for confirmed v2.164+ installations only. My concern is that the core architecture still appears largely the same. From what I can see, the plugin still accepts remote update_account data from the MCC API and saves it locally into the account data option. That was one of the main areas of concern in the previous incident, where remote data could be poisoned and then stored locally. The part that still worries me is this general flow: case ‘update_account’: $new_account_data = (object) (array) $message->account; $this->save_data( ‘account_data’, json_encode( $new_account_data ) ); break; Unless there is strong validation elsewhere, this still looks like the plugin is trusting remote account data too much before saving it. What I would personally like clarified by the developer is: Is all remote update_account data now strictly schema-validated before being saved? Are risky fields like URLs, wallet data, payment counters, and display fields sanitised before storage, not just escaped later when displayed? Is there now proper cryptographic verification, such as HMAC/signature checking, on API messages? If the MCC API/server was compromised again, would a malicious payload be rejected before it ever reached the WordPress database? My honest take: 2.164 is definitely better than the earlier affected versions, but I still do not see enough to call this a complete architectural fix, huge security flaws.For a normal plugin bug, output escaping might be enough. But for a payment plugin handling crypto checkout data, especially after a remote account-data compromise, I would expect the plugin to treat all remote API data as hostile until validated. I would suggest you guys do some heavy pen testing. I have personally moved away after 3 breaches over last couple of months and thousands lost you guys need to redesign this plugin from the ground up. For a normal plugin bug, output escaping might be enough. But for a payment plugin handling crypto checkout data, especially after a remote account-data compromise, I would expect the plugin to treat all remote API data as hostile until validated. I have personally moved away from MCC after 3 breaches over last couple of months and thousands lost you guys need to redesign this plugin from the ground up. Recommendations Wallet/payment settings controlled locally Remote API used only for licensing or optional services No remote checkout HTML injection No remote wallet/address overrides Strict schema validation before saving API data Signed API messages Full audit logs for payment/account changes Emergency local-only mode Hello, I am getting this error after upgrading the plugin. No other changes have been made to the site or server. “Error refreshing your account data. Is your site password protected? Do you have coming soon / maintenance mode enabled? A firewall blocking api.mycryptocheckout.com?” If I go to Tools > Test comm, I get: Exception: Did not receive a JSON reply from the API server: <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html> #0 /var/www/html/wp-content/plugins/mycryptocheckout/vendor/mycryptocheckout/api/src/v2/wordpress/API.php(132): mycryptocheckout\api\v2\API->parse_response() #1 /var/www/html/wp-content/plugins/mycryptocheckout/vendor/mycryptocheckout/api/src/v2/API.php(416): mycryptocheckout\api\v2\wordpress\API->send_post() #2 /var/www/html/wp-content/plugins/mycryptocheckout/vendor/mycryptocheckout/api/src/v2/API.php(425): mycryptocheckout\api\v2\API->send_post_with_account() #3 /var/www/html/wp-content/plugins/mycryptocheckout/src/admin_trait.php(1040): mycryptocheckout\api\v2\API->test_communication() #4 [internal function]: mycryptocheckout\MyCryptoCheckout->admin_tools() #5 /var/www/html/wp-content/plugins/mycryptocheckout/vendor/plainview/sdk/wordpress/tabs/tabs.php(328): call_user_func_array() #6 /var/www/html/wp-content/plugins/mycryptocheckout/src/menu_trait.php(130): plainview\sdk_mcc\wordpress\tabs\tabs->render() #7 /var/www/html/wp-includes/class-wp-hook.php(341): mycryptocheckout\MyCryptoCheckout->admin_menu_tabs() #8 /var/www/html/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters() #9 /var/www/html/wp-includes/plugin.php(522): WP_Hook->do_action() #10 /var/www/html/wp-admin/admin.php(264): do_action() #11 /var/www/html/wp-admin/options-general.php(10): require_once('...') #12 {main} Could this be a cloud flare issue that your plugin is not handling well ? It was working perfectly before. Thanks. @mrsrmguy Thanks for the feedback. I want to clarify a few points and answer the technical questions directly. MCC has been operating for roughly 8 years. The earlier winter issue was a plugin/API trust-path issue involving API impersonation/spoofing, not a breach of the MCC API servers. After that, we spent months hardening the plugin and worked through review with WordPress. The recent incident was different. It involved unauthorized access to part of the server environment, which was related to recently disclosed Linux-level issues. The Copy Fail / Dirty Frag activity was part of the same broader server-side incident. This was not a case where every API field was blindly unsafe. A lot of plugin-side escaping and hardening was already in place from the previous security work. The issue was that after the server-side compromise, attackers were able to send trusted-looking account-data updates, and a small number of remaining remote account-data fields still had too much trust for display/template behavior. You are correct that the broader update_account storage boundary needed additional hardening. v2.164 addressed the known exploited paths, including the abused payments_left field and the checkout wallet-link path. We have now released an additional update that further hardens the account-data storage path itself. The vulnerable update_account flow quoted above is no longer the same. Remote retrieve_account and update_account data is now sanitized before storage. Sensitive account fields are hard-typed, currency data and QR/wallet-link-related fields are sanitized, and the previous raw API-provided checkout HTML path has been removed/hardened. On the API side, we rebuilt the API servers, cleaned and re-sent API-side account data, rotated domain keys, added stricter account payload handling, and added API version handling so older plugin versions can be restricted while updated installations are handled separately. To answer directly: Yes, the current release adds before-storage sanitization/hardening for remote account data. Yes, risky fields such as payment counters, currency data, QR data, wallet-link-related fields, and display/template-related fields are sanitized or hard-typed before storage where appropriate. Larger architectural changes, including additional message-authentication design, stronger audit logging, local/emergency-safe modes, and reducing what remote API data is allowed to affect, are being evaluated separately. We do not want to bolt those on hastily and risk breaking existing installations. For the known payload paths involved in this incident, the current plugin-side hardening is intended to neutralize those values before storage, and the API-side changes reduce what is sent and how older versions are handled. Some recommendations, like removing all API connections or making the API only for licensing, are not realistic without breaking how MCC currently works. MCC uses the API for more than licensing, including payment detection, exchange rates, supported currency metadata, account status, and related services. The practical goal is not “no API ever.” The practical goal is reducing what remote API data is allowed to control, validating/sanitizing it before it is stored or displayed, and keeping older versions that do not have those protections restricted. MCC is open-source software, so anyone who wants to review the plugin code or suggest concrete improvements is welcome to do so. We are open to practical security feedback and code contributions that improve safety without breaking existing installations. Hello MCC team, Could you make it compatible with older versions of WordPress? I have a site running an older WordPress version that is quite complicated to update, and I can’t use the new version of the plugin. Thank you. WordPress shows a new version is available 2.165 however when updated, uninstalled, etc still shows error unable to retrieve, did not receive a JSON reply. It was working fine before this issue. @traceyj007 v2.165 and 2.164 are essentially the same. The API has been disabled for the past couple of days. So it is not possible that anything before 2.164 has been working fine the past couple of days and 2.165 doesn’t work. We are working with WordPress regarding...