OpenMonero

Хроника инцидента

1. 2026-05-21 Prior exploit (~40 XMR); operator later claimed all affected users were fully refunded.
2. 2026-06-08 Operator posted an "OpenMonero is Back" announcement following the May incident.
3. 2026-06-10 OrangeFren publicly reported "hacked again, 200 XMR stolen" (citing an OpenMonero Telegram screenshot). Downgraded to D.
4. 2026-06-11 Operator has not confirmed the 06-08 incident. Some claim a negative-trade-amount input bug, others call it a rug — unverified. Treat funds as at-risk pending a verifiable post-mortem.
5. 2026-06-25auto Within the last 7 days, OpenMonero's operator issued a post-breach remediation notice (tracked by kycnot.me ~10h before this scan, source: openmonero.com): all user 2FA tokens were reset, users were told to change passwords and settlement wallet addresses, April 12-May 22 registrants were asked to file support ticke…
6. 2026-06-28 Operator recovery post: "OpenMonero is back after 2 weeks of downtime." Security posture rebuilt — servers switched, new onion address generated, env vars and backup codes reset, full wallet isolation from the frontend, backend IP hidden. 90 XMR were refunded to affected users on 2026-06-24 (partial recovery vs. the ~200 XMR reported stolen by OrangeFren; not the full loss). No independent audit disclosed.
7. 2026-07-07 Curator re-verified: clearnet homepage carries an alert banner directing users registered Apr 12 – May 22 to open a support ticket, passwords in that window to be reset, OTP codes reset platform-wide (users must reactivate 2FA), and the new onion pinned. xmr.club rotated the tor field to the new onion address. Grade held at D — the 2026-06-28 recovery post reports 90 XMR refunded of a claimed ~200 XMR loss (partial, not full), and no public post-mortem or independent audit has been published. This is a resumption of service, not a rehabilitation of the trust track.
8. 2026-07-24 New outage window. Operator posted an "API server under attack" banner on the website for ~17h then removed it with no follow-up statement. xmr.club chatbox users (registered handles 610fd67f, cd55da94) report they cannot withdraw from active trades and question whether this is turning into an exit scam. Operator X account (@OpenMonero) has posted nothing since 2026-06-08. No independent DDoS confirmation. Withdrawal status unverified. Grade reverted from the 2026-07-07 D → C lift back to D pending withdrawal-restoration confirmation from our own reader channel.
9. 2026-07-25 24h re-check on 2026-07-24 outage escalated to full compromise incident. kycnot.me published a critical advisory (2026-07-24) based on a Monero Matrix Channel disclosure: "By executing a single GET request, an attacker could gain full access to the oldest existing user account on OpenMonero. This broken endpoint allowed taking over all other accounts on a sequential basis—from oldest to newest. The user claims OpenMonero admins have chosen to remain silent on the issue and are actively ignoring a similar unpatched vulnerability, leading to user accounts getting drained and their full trading history getting leaked. Other sensitive data such as shipping addresses and private chat logs is also believed to have been compromised." (source: https://kycnot.me/service/openmonero, cite: xcancel.com/monerobull/status/2080627692773282014). Operator X account (@OpenMonero) still silent since 2026-06-08 — no acknowledgement of the API vulnerability, no post-mortem, no user notification. Chat context on xmr.club chatbox (handles 610fd67f, cd55da94) reporting frozen trades from 2026-07-23/24 is now recontextualised as consistent with the API-endpoint compromise. Grade escalated D → F. Tagline updated. Recommendation now unambiguous: do not deposit; withdraw anything still accessible; treat trading history / shipping-address / chat-log data as exfiltrated. Prior lift path (post-mortem + independent audit + no-incident window) is now blocked by the data-leak class — even a full post-mortem cannot un-leak exfiltrated data. No further wake scheduled — grade is stable at F pending an operator response that would meaningfully change the picture.
10. 2026-07-30 THIRD documented exploit. OpenMonero posted an update (surfaced 2026-07-30 via OrangeFren + Dark Web Informer on X) claiming another **399 XMR drain** (~$60k+ at current prices) attributed to "a zero-day vulnerability that had been hiding since the start of the project." OrangeFren's public reaction: "I lost track how many times they claimed to have been exploited at this point." Combined pattern now on record: (a) 2025-06 first drain (~90 XMR, later claimed fully refunded); (b) 2026-06 second drain (~200 XMR reported, only ~90 XMR refunded per operator recovery post); (c) 2026-07 API-endpoint sequential-account-takeover exploit reported by kycnot 2026-07-24; (d) 2026-07-30 third drain of 399 XMR now announced. Grade held at F (no lower tier). No wake reschedule — the incident record now speaks for itself. Reader takeaway: repeated-exploit pattern with each event framed as a fresh "zero-day" makes competence claims unfalsifiable; the operational security track record is broken. Community sentiment reflected in our own X: "Just forget about them already."
11. 2026-09-18auto On 2026-09-13 the operator posted that a series of past hacks (lumped as one zero-day) is patched and that most victims are refunded, with only 4 users remaining unpaid; a same-day reply to a thread listing the June 200 XMR theft claimed they have always made users whole. These are unverified operator claims that co…