edward_plainview

@farame

Try manually downloading the plugin, edit the readme.txt file and edit the lines at the top containing “requires”.

@moxi

We are currently speaking with the ww.wp.xz.cn Plugin Team about whether they can assist with a forced or accelerated update to the latest hardened version. If that path is not available, then we will move forward with the version gated API access.

We will post another update shortly.

@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:

1. Yes, the current release adds before-storage sanitization/hardening for remote account data.
2. 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.
3. 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.
4. 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.

We understand many users are asking when MCC API services will be restored.

At this time, we do not have a confirmed ETA. Because MCC is used for cryptocurrency payments, we will not bring hosted/API services back online until we can verify that the infrastructure and payment-data path are safe.

We are evaluating whether a limited/safe mode can be restored first, but payment-related account data will remain offline until the trust path is rebuilt and verified.

We know this creates disruption, especially because there are limited p2p alternatives. Our priority is preventing unsafe payment data from being served.

Additionally, the decentralized nature of WordPress creates unique challenges for a cryptocurrency payment plugin. Unlike a fully hosted service, we cannot instantly update every installation or force all sites onto the latest hardened version. Some installations update quickly, while others may remain on older versions for extended periods. Given the rise in sophisticated attacks targeting payment-related software and infrastructure, this makes restoring hosted/API functionality more complicated than simply bringing servers back online.