This sentence uses \` and \` delimiters to show math inline:

Incident Summary

On April 12 2025, an unverified contract, 0x623c, was exploited, leading to the loss of approximately $28,000 due to a lack of access control. The exploit was the fourth incident linked to this same attacker, who had already conducted exploits on Gemcy, OPC, and AIRWA, gaining around $181,000. On April 23, the attacker conducted a fifth attack on ACB.

Here, we break down how the Sola Token was exploited from the event flow, then decompile the unverified contract in order to confirm the root cause of the incident.

Key Transactions

Exploit Transaction:

https://bscscan.com/tx/0x9371eb4b0da7dedc95568d508a7fc97298a27bb44947c82dc4542fe3a4e5e3c9

Attack Flow

Addresses

Attack wallet: 0x70f0406e0A50C53304194B2668Ec853D664a3D9C

Attack contract: 0xD306C1f4506C89929820a10163206E337658E2b4

Victim contract: 0x623c1c6693e1425a7E691a0FF5C256Cb276522CA

Step by Step Event Flow

1. The attacker started by transferring 0.4 BNB to the exploit contract. The SOLA balance of the victim contract was checked, as well the amount of tokens that would be exchanged for swapping the SOLA balance to USDT. Then, the swap() function of PancakePair 0xdf9 was called to conduct the swap.

If we take a closer look at the data field, we can see that there were three bits of information passed:

• The victim contract
• SOLA Token address 0x4819
• Token amount

2. In the getAmountsOut step, it was calculated that 2,143,036 SOLA would be swapped for 23,235 USDT. As this is a flash swap, the USDT was sent to the attacker before Pancake received the SOLA.

Once the USDT was transferred, the withdrawToken() function was called in order to transfer the owed SOLA tokens from the victim contract.

3. After the swap, the attacker repeated the process again for a second SOLA token 0xef7, this time swapping 247,425 of a different SOLA token from the victim contract for 8.92 WBNB.

Vulnerability

Analyzing unverified contracts

The event flow indicates that, for an unconfirmed reason, the attacker was allowed to transfer tokens from SOLA contract 0x623c1c6693e1425a7E691a0FF5C256Cb276522CA when conducting a swap. This could either be that they have permission via a privileged wallet address or it’s a publicly accessible function with no permission checks. In order to confirm, we need to decompile the contract and look at the withdrawToken() function.

The decompiled code can look quite unreadable until it is converted into its original format. Typically, this would involve recognition of common lines of code and replacing known variables. For example, in this code, v0 is true or false and v1 is token balance. We can use AI to speed up this process:

Now, the code is more readable. We can confirm that the withdrawToken() function has no modifiers, such as onlyOwner, nor does it have any 'require' statement which limits who can access this public function.

Fund Flow

The attacker’s address 0x70f0406e0A50C53304194B2668Ec853D664a3D9C was funded on March 29 by address 0x326f75EA9C85337f88087155bf6220Fa8DE81324 with both addresses having already been used in a number of other exploits before this incident.

• 21 March GEMCY ~$40k
• 1 April OPC ~$107k
• 4 April AIRWA ~$34k
• 23 April ACB ~$90k

In total, the attacker has sent 498 BNB to Tornado Cash from across the five incidents listed.

The Stats

Since the beginning of 2025, incidents related to code issues remain one of the most common attack vectors. The number of incidents due to code vulnerabilities has remained fairly consistent in the last four years, though losses have decreased year on year.

So far in 2025, we have recorded 93 incidents linked to code vulnerabilities for a total loss of around $52.5 million. This makes it the second most common cause of losses by number of incidents, just behind phishing.

To keep up to date on the latest incident alerts and statistics, follow @certikalert on X or read our latest analysis on certik.com.