익스플로잇 흐름```

┌─────────────────────────────────────────────────────────────────────┐ │ 1. Attacker sends multipart form with fake chunk object │ │ → decodeReply() parses form fields 0, 1, 2 │ │ → Object has: then, status, value, _response │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 2. Self-reference makes object thenable with real function │ │ → then: "$1:proto:then" → Chunk.prototype.then │ │ → Chunk.prototype.then(this) calls initializeModelChunk(this) │ │ → Uses this._response (attacker's fake _response) │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 3. parseModelString() handles "$B1337" reference │ │ → case "B": return response._formData.get(response._prefix+id) │ │ → Calls _formData.get with attacker's _prefix + "1337" │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 4. getOutlinedModel() resolves _formData.get (lazy evaluation): │ │ → "$1:constructor:constructor" traverses prototype chain │ │ → Returns Function constructor │ │ → Function(code + "1337") → RCE │ └─────────────────────────────────────────────────────────────────────┘

자기 참조 Thenable (then)

then: "$1:__proto__:then"는 자체 참조를 생성하여 실제 함수로 해석됩니다:``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this)는 this._response를 사용합니다 - 공격자의 가짜 _response:```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Stage 1: 외부 객체의 자기 참조 then이 청크 처리를 트리거합니다

Stage 2: React가 모델을 해석할 때 value를 파싱하고 then: "$B1337"을 가진 다른 thenable을 만납니다. $B 접두사가 핸들러를 트리거합니다:```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

React의 내부 코드는 처리 중에 response._chunks.get() 또는 response._chunks.has()에 접근할 수 있습니다. 빈 Map은 오류 없이 이 호출들을 만족시켜 실행이 취약한 $B 핸들러에 도달할 수 있게 합니다.

취약한 코드 경로

decodeReply()는 진입점이며, 자체적으로 취약하지 않습니다.

경로 순회 (getOutlinedModel()):```javascript for (key = 1; key < reference.length; key++) parentObject = parentObject[reference[key]]; // No validation!

$B 핸들러 RCE (parseModelString()):```javascript case "B": return response._formData.get(response._prefix + obj); // RCE!

2. hasOwnProperty의 getOutlinedModel()에서의 확인 - 프로토타입 탐색 차단 ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. reviveModel()에서의 __proto__ 처리 - 프로토타입 오염 방지 ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. initializeModelChunk()의 타입 검사 - 리스너 검증 ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

영향 및 버전

영향 평가

영향받는 버전

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: 동일한 버전
• Next.js: 15.x, 16.x (패치 이전), 14.3.0-canary.77+부터의 카나리

수정된 버전

• React: 19.0.1+, 19.1.2+, 19.2.1+
• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7+

서명 기반 WAF 탐지가 실패하는 이유

이 섹션에서는 전통적인 패턴 매칭 WAF 규칙이 이 익스플로잇을 안정적으로 탐지할 수 없는 이유를 설명합니다. 이러한 한계를 이해하는 것은 보안 팀이 방어 태세를 평가할 때 필수적입니다.

핵심 문제: 여러 계층에서의 인코딩

익스플로잇 페이로드는 각각 다른 인코딩 지원을 가진 여러 파서를 통과합니다. 원시 HTTP 바이트를 검사하는 WAF는 인코딩된 문자열을 보지만, 서버는 처리하기 전에 이를 디코딩합니다:

이는 근본적인 불일치를 만듭니다: WAF는 인코딩된 바이트를 보지만, 애플리케이션은 디코딩된 문자열을 봅니다.

서명이 일치해야 하는 대상

순진한 WAF는 constructor, __proto__, resolved_model, 또는 child_process와 같은 패턴을 찾을 수 있습니다. 그러나 JSON은 모든 문자에 대해 유니코드 이스케이프를 허용합니다:

페이로드 내 JavaScript 코드에는 더 많은 인코딩 옵션이 있습니다:

탐지 격차

모든 인코딩 기술이 결합될 때:

• JSON 키는 유니코드 시퀀스가 됩니다 (\u0074\u0068\u0065\u006e는 then에 해당)
• JS 식별자는 숫자 배열이 됩니다 (S(99,104,105,108,100,95,...)는 child_process에 해당)
• 원시 페이로드에는 인식 가능한 키워드가 전혀 포함되지 않습니다

HTTP 본문을 스캔하는 WAF는 이스케이프 시퀀스와 숫자만 보게 됩니다 - 전통적인 공격 서명과 일치하는 것은 아무것도 없습니다.

방어자에게 중요한 이유

1. 서명 기반 규칙은 잘못된 확신을 줍니다 - 페이로드가 탐지되지 않고 서버에 도달합니다
2. 인코딩은 무한합니다 - 모든 문자는 다르게 이스케이프될 수 있습니다. 정규식으로 모든 변형을 열거할 수 없습니다
3. 공격은 프로토콜을 준수합니다 - 모든 인코딩은 사양에 따라 유효한 JSON/JavaScript입니다

헤더 탐지 고려사항

Next-Action 헤더는 Server Action 요청을 식별합니다. 헤더 이름은 유니코드로 인코딩할 수 없지만 (RFC 7230은 ASCII 토큰을 요구), WAF와 서버 간의 정규화 차이로 인해 탐지 격차가 발생합니다:

방어 권장사항

패치가 유일한 신뢰할 수 있는 완화 방법입니다. WAF 규칙은 인코딩 유연성으로 인해 이 공격을 포괄적으로 차단할 수 없습니다.

필요한 버전:

• React: 19.0.1+, 19.1.2+, 19.2.1+
• Next.js: 15.0.5+, 15.1.9+, 15.2.6+, 15.3.6+, 15.4.8+, 15.5.7+, 16.0.7+

패치가 지연될 경우 다음을 고려하십시오:

1. 일치 전에 디코딩 - WAF는 패턴 매칭 전에 \uXXXX, \xXX를 디코딩하고 fromCharCode() 호출을 정규화해야 합니다
2. 구조적 탐지 - _response, _prefix, _chunks 또는 순환 참조($@0)를 포함하는 JSON 구조를 찾습니다
3. 헤더 정규화 - next-action 헤더를 대소문자 구분 없이 공백을 제거하여 매칭합니다
4. Server Actions 차단 - Server Actions를 사용하지 않는 경우, Next-Action 헤더가 있는 요청을 완전히 차단합니다
5. 런타임 모니터링 - 동적 문자열 인수를 사용하는 Function() 호출에 대해 경고합니다

핵심 요점: 패턴 매칭만으로는 이러한 유형의 공격을 막을 수 없습니다. 인코딩 표면이 너무 방대하여 나열할 수 없습니다.

AWS WAF 본문 검사 제한 우회

포괄적인 WAF 규칙이 있더라도 AWS WAF에는 악용될 수 있는 본문 검사 크기 제한이 있습니다. 이 섹션에서는 과도한 크기의 페이로드를 사용한 테스트된 우회 기술을 문서화합니다.

본문 검사 제한

AWS WAF는 요청 본문의 일부만 검사합니다:

OversizeHandling 문제

WAF 규칙은 검사 제한을 초과하는 요청을 처리하는 방법을 지정합니다:

WAF 규칙이 OversizeHandling: CONTINUE (일반적인 기본값)을 사용하는 경우 우회는 간단합니다.

우회 전략: 페이로드 앞에 패딩

무해한 패딩 데이터를 익스플로잇 페이로드 앞에 배치하여 검사 창 밖에 위치하도록 합니다:``` ┌─────────────────────────────────────────────────────────────────┐ │ Multipart Form Body │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: padding] 65KB of 'A' characters │ │ ↑ WAF inspects first 8-64KB (sees only this) │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: 0] {"then":"$1:proto:then", ...} │ │ [Field: 1] "$@0" │ │ [Field: 2] [] │ │ ↑ Exploit payload - beyond WAF inspection limit │ └─────────────────────────────────────────────────────────────────┘

패턴이 청크에 걸쳐 나뉨:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

WAF 동작 고려 사항

참고: AWS WAF는 일반적으로 청크로 분할된 본문을 검사 전에 재조립합니다. 그러나 각 환경별로 설정이 다를 수 있으므로 확인이 필요합니다.

완화 권장 사항

1. OversizeHandling을 MATCH로 변경 ```json "OversizeHandling": "MATCH"
   root@kitploit:~

이 규칙 조건이 충족되면 검사 한도를 초과하는 모든 요청을 차단합니다.

2. 본문 검사 한도 증가 (CloudFront/API Gateway 전용) 웹 ACL 설정에서 최대 64KB까지 구성할 수 있지만, 이는 우회를 완전히 막지 못합니다.

3. 크기 기반 차단 규칙 추가 합리적인 크기(예: 10KB)를 초과하는 Next-Action 헤더가 포함된 POST 요청을 차단합니다.

4. 애플리케이션 패치 - 유일한 완전한 해결책입니다.

테스트 스크립트

포함된 테스트 스크립트 참조:

• test-simple.cjs - 기본 비청크 페이로드 테스트
• test-oversize.cjs - 0~128KB 패딩 크기 테스트
• test-chunked-v2.cjs - $@ 분할을 사용한 청크 전송 인코딩
• test-chunked-bypass.cjs - 여러 청킹 전략(5바이트, 10바이트, 패턴 분할)

사용법:```bash

Start vulnerable Next.js server (port 3000)

cd nextjs-test && npm run dev

Run tests

node test-simple.cjs # Baseline node test-oversize.cjs # Oversize body bypass node test-chunked-v2.cjs # Chunked $@ split node test-chunked-bypass.cjs # All chunking strategies

Payload "$1:constructor:constructor" 사용 시:

1. chunk[1]["constructor"] → [Function: Object]
2. Object["constructor"] → [Function: Function]

시도했지만 차단된 경로

Function을 얻었지만, RCE를 달성하려면 제어된 인수로 호출해야 합니다. 다음 경로는 실패했습니다:

1. Thenable 경로 (차단됨)```javascript // Attempt: { then: Function } // When awaited, V8 calls: Function(resolve, reject) // resolve.toString() = "function () { [native code] }" // Result: SyntaxError - invalid parameter name

3. 반복자 경로 (차단됨)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute