Summary
On May 1, 2026, MyCryptoCheckout experienced a security incident involving unauthorized access to part of the MCC server environment and unauthorized account-data updates sent to a subset of MCC installations.
Based on our investigation, the server-side compromise involved a recently disclosed Linux privilege-escalation vulnerability commonly referred to as “Copy Fail” / CVE-2026-31431 https://xint.io/blog/copy-fail-linux-distributions. After gaining root privileges on one of the MCC API servers, the attackers used SSH proxy tooling to access the server and perform reconnaissance.
The attackers then ran scripts from the server’s /tmp/ directory. These scripts retrieved legitimate MCC account data, modified certain account-data fields to include malicious JavaScript, assembled unauthorized update_account messages, and sent those messages directly to some MCC client sites.
Because the messages came from an expected MCC server IP and included the correct domain key for each target, affected MCC clients accepted the account-data updates. The plugin-side weakness was that certain remote account-data fields were stored and later rendered without sufficient schema validation and escaping.
We contained the server-side breach, removed the unauthorized tooling/scripts, rotated all domain keys, cleaned and re-sent MCC account data, and released MyCryptoCheckout v2.163 to patch the plugin-side vulnerability.
Root Cause
This incident required two issues to chain together:
- Infrastructure compromise
A recently disclosed Linux privilege-escalation vulnerability allowed attackers to gain elevated privileges on one MCC API server. The attackers used SSH proxy tooling and ran scripts outside the normal MCC application request flow, which limited visibility in standard MCC API and webserver logs. - Account-data handling weakness
The plugin trustedupdate_accountpayloads from expected MCC server IPs when they contained a valid domain key. Certain account-data fields were not strictly schema-validated before storage or safely escaped everywhere they were rendered.
How Impact Varied
Not every MCC installation was affected in the same way.
A site was at risk only if it received and accepted one of the unauthorized account-data updates during the incident window. The potential effect then depended on how the site was used while the malicious account data was present.
If a logged-in WordPress administrator viewed an affected MCC admin page during that window, the injected script could run in that administrator’s browser session and attempt actions such as disabling MCC security settings, creating an unauthorized administrator user, creating a WordPress Application Password, or modifying plugin files where plugin editing was available.
If a customer reached an affected checkout page while malicious checkout/open-wallet data was present, displayed payment instructions or QR codes could have been altered.
If the site received the unauthorized account data but neither of those conditions occurred before clean account data was re-sent, the expected local impact would be limited to the temporary poisoned account data.
Containment and Remediation
On the infrastructure side, we terminated the unauthorized access, removed SSH proxy tooling, purged the attacker scripts from /tmp, restored the API server software from source control, changed infrastructure passwords, rotated all domain keys, cleaned MCC API-side account data, and re-sent clean account data after containment was completed.
On the plugin side, MyCryptoCheckout v2.163 changes how remote account data is handled. Remote account data is now treated as untrusted input. The update adds stricter schema validation before storage and safer escaping/output handling for account-data fields rendered in WordPress admin and checkout contexts.
Action for MCC Users
The server-side threat has been contained and MCC API-side account data has been cleaned and re-sent. However, all MCC users should still update to MyCryptoCheckout v2.163 because it includes the plugin-side hardening that prevents this class of account-data injection from executing.
After updating:
- Refresh MCC account data. The MCC API-side account data has been cleaned and re-sent after containment was completed.
- Review all WordPress administrator users and remove any unauthorized accounts.
- Re-enable any MCC security functions that were previously active.
- Verify configured wallet addresses.
- Scan the WordPress site for modified plugin, theme, or core files.
Going Forward
We regret the impact this incident had on merchants who rely on MyCryptoCheckout. Processing peer-to-peer cryptocurrency payments requires a defense-in-depth approach, even when MCC does not custody funds.
Going forward, MCC will treat remote API data as untrusted by default. A server-side issue should not be able to become executable code inside a WordPress installation. We are continuing to harden MCC around stricter account-data validation, safer output handling, reduced trust in remote account data, and additional safeguards.