Approximately 64,000 Bitcoin mining machines were reportedly hijacked, redirecting 13 exahashes per second of computing power to the OCEAN mining pool, according to a WuBlockchain post published at 14:30 UTC on November 15, 2026, citing Bitcoin News.
The reported scale puts mining fleet administration at the center of the story. Machines can continue producing computational work while an unauthorized configuration sends that work to a different destination. For their owners, keeping hardware running does not ensure they receive the intended mining credit.
The figures remain reported estimates. Naming OCEAN as the destination should not be read as an allegation that OCEAN carried out the attack or that its systems were breached.
A pool address determines the destination of work
OCEAN's setup instructions show how operators configure a miner's output. They enter the pool endpoint into their mining hardware's interface and use a Bitcoin reward address as the username.
Multiple miners can connect with the same username, and OCEAN aggregates those connections. Operators can append worker names to distinguish machines or groups in the dashboard.
Those details explain the economic significance of a pool change. In SpendNode's analysis, an unauthorized edit to the endpoint or reward identity can separate the person paying to operate a machine from the person receiving credit for its output. The hardware can keep running throughout.
OCEAN also tells operators to check their statistics after connecting. Its documentation warns that an invalid Bitcoin address used as a username can leave submitted work without earnings.
Verifying the configuration therefore helps operators verify their revenue. A machine reporting activity gives an operator one piece of information; accepted work credited to the intended address supplies another. An inspection focused only on whether equipment is running would miss where its work is being credited.
Fleet controls concentrate the consequences of an edit
Modern mining software makes changes across large groups of machines practical. As an example of that capability, Luxor's Commander documentation describes bulk operations that can change pool settings across hundreds or thousands of miners in one workflow.
The documented pool command changes the stratum URL, worker name and password for selected machines. Commander also has an actions log recording operations, their originating user or automation, timestamps, affected sites and results.
Such tools reduce the work required to administer a fleet. They also concentrate authority in a way that deserves attention in a security review: permission to change a pool destination is permission to redirect productive equipment.
For an operator investigating suspicious routing, a useful question is which administrative control could have applied the observed configuration. Comparing the intended settings with the recorded action history can help narrow the investigation. A command recorded as completed still needs to be checked against the owner's intended destination.
The size of the reported diversion raises the stakes beyond correcting an isolated configuration mistake. SpendNode's assessment is that controls over fleet changes should receive the same scrutiny as the resulting hashrate totals. A dashboard can report substantial activity without showing whether the intended owner receives credit for it.
Recovery needs a destination check
For affected operators, a practical recovery sequence begins with confirming the intended pool endpoint and reward identity on the machines involved. Restoring those values should be followed by checking that the destination records accepted work under the correct identity.
SpendNode also recommends reviewing access alongside that correction. If an unauthorized actor retains permission to issue configuration changes, restoring a setting alone leaves them able to change it again.
Operators should preserve the relevant configuration history before replacing evidence with fresh settings. An incident review needs to distinguish an unauthorized command from a mistaken administrative change and identify which machines received it.
The 13 EH/s figure measures computational throughput. Calculating financial damage would require evidence about the diversion's duration and the mining credit affected, so converting the headline number into a dollar loss estimate would overstate the available account.
The immediate business issue is attribution of work. Owners need to establish that the equipment they operate is contributing to the destination they approved, with credit assigned as intended.
Overview
WuBlockchain reported that approximately 64,000 Bitcoin mining machines had 13 EH/s redirected to OCEAN. The reported diversion illustrates how control over mining output depends on the settings applied to running equipment.
The technical documentation explains the exposure: pool endpoints direct connections, reward identities determine attribution, and fleet tools can apply settings across many machines. For operators, recovery is complete only after accepted work appears under the intended reward identity.
