Analysis of Security Incident on Pump Platform

Recently, a serious security incident occurred on the Pump platform, resulting in significant losses of user funds. This article will provide an in-depth analysis of the ins and outs of this event.

Attack Process

The attacker is not a skilled hacker, but rather a former employee of the Pump platform. He has control over the wallet used by Pump to create token trading pairs on a certain DEX, which we refer to as the "victim account." All Bonding Curve LP pools on Pump that have not yet met the listing standards of a certain DEX are referred to as "preparatory accounts."

The attacker first obtained a flash loan from a lending platform to fill all the token pools that did not meet the listing standards. Normally, when the pool reaches the listing standards, the SOL in the "preparatory account" should be transferred to the "victim account." However, at this moment, the attacker withdrew the transferred SOL, causing the tokens that were supposed to be listed and locked in the pool to be unable to be listed as scheduled.

Victim Analysis

According to the analysis, the victims were mainly users who had purchased tokens that had not yet filled the pool on the Pump platform before the attack occurred. Their SOL was taken away by the aforementioned attack method. This also explains why the initial estimated loss could be as high as 80 million dollars (latest data shows the actual loss is about 2 million dollars).

It is worth noting that tokens that have already been listed on a certain DEX should not be affected by this attack due to the LP being locked.

Attacker Identity Inference

The attacker possessing the private key of the "victim account" undoubtedly exposes a significant oversight in the platform's permission management. We can speculate that filling the token pool may have been one of the attacker's previous job responsibilities.

Similar to the practices of other platforms, Pump may have assigned this employee to use project funds to fill the pools of newly issued tokens (most likely their own issued test tokens) in order to achieve a cold start, so that these tokens could be listed on the exchange and generate hype. Unexpectedly, this ultimately became a breakthrough point for internal threats.

Lessons Learned

1. For similar projects, merely imitating the surface is not enough. To attract users to trade, initial incentives need to be provided.

2. The project team must attach great importance to permission management and security measures. It is crucial to allocate permissions reasonably, conduct regular audits, and prevent internal risks.

3. Users should remain vigilant when participating in emerging platforms, especially when trading tokens that are not fully filled or not listed on mainstream exchanges.

4. The project party should establish a sound risk management mechanism, including multi-signature, permission levels, etc., to reduce the risk of single points of failure.

5. Regularly conduct security audits and penetration testing to promptly identify and fix potential vulnerabilities.

6. Strengthen employee training and ethical education, establish a healthy corporate culture, and reduce internal threat risks.

This event reminds us once again that security is always the top priority in the rapidly evolving cryptocurrency industry. Both project teams and users need to remain vigilant at all times and take necessary security measures.