[2025.12.12 주간 개발 트렌드] GPT-5.2 정리 (긴 작업, 도구 호출, Agent 운영)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# React 의존성도 서버 보안 패치 대상이다

프론트엔드 라이브러리의 문제라고 하면 브라우저 화면이나 사용자 입력부터 생각하기 쉽다. 그런데 서버에서 실행되는 React 기능을 사용한다면 영향 범위가 달라진다.

이번주 12월 3일에 React 팀이 [React Server Components의 치명적인 취약점](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)을 공개했다. CVE-2025-55182로 등록됐고 CVSS는 10.0이다. 인증 없이 서버에서 원격 코드를 실행할 수 있는 문제다.

이번주에는 React2Shell로 알려진 이번 취약점에서 어떤 구성을 확인하고 어떻게 패치 결과를 검증해야할지 정리해보려고 한다.

# 1. 우선 문제가 발생하는 위치를 보자

이번 문제는 React가 Server Function 엔드포인트로 전달된 payload를 해석하는 과정과 관련된다. 공격자가 보낸 요청이 서버의 코드 실행으로 이어질 수 있다는 점이 핵심이다.

```text
외부 요청
    ↓
서버의 RSC 관련 처리
    ↓
payload 해석 과정의 취약점
    ↓
서버에서 의도하지 않은 코드 실행 가능
```

브라우저에서 화면이 잘 보이는지와는 다른 문제다. 공격자가 정상 화면의 버튼을 순서대로 눌러야만 요청을 보낼 수 있는것도 아니다.

또한 직접 Server Function을 구현하지 않았더라도 RSC를 지원하는 구성이면 영향을 받을 수 있다고 React 팀은 설명한다. 소스에서 use server를 검색해서 나오지 않는다는 이유만으로 확인을 끝내면 안되겠다.

반면 서버를 사용하지 않는 React 코드나 RSC를 지원하는 프레임워크·번들러를 사용하지 않는 앱은 이 취약점의 대상이 아니다. 모든 React 프로젝트를 같은 영향 범위로 묶기보다는 실제 실행 구성을 봐야한다.

# 2. 어떤 의존성을 확인해야할까

React 발표에서 다루는 패키지는 react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack이다. 이번 공개에서 안내된 수정 버전은 19.0.1, 19.1.2, 19.2.1이다.

프레임워크가 해당 구현을 포함하거나 의존할 수 있으므로 package.json에 패키지를 직접 적었는지만 보면 놓칠 수 있다.

```text
확인할 범위
package.json → lockfile → 실제 설치된 의존성
                         ↓
                배포 이미지와 실행 환경
```

Next.js도 [별도 보안 공지](https://nextjs.org/blog/CVE-2025-66478)에서 App Router를 사용하는 영향 범위를 안내했다. Next.js 15와 16, 일부 14 canary 구성이 포함된다. Pages Router나 안정 버전의 Next.js 14를 같은 범위로 취급하면 안된다.

모노레포라면 루트 의존성만 보지말고 실제 배포하는 앱 단위로 확인하면 좋겠다. 사용하지 않는 패키지가 설치돼있는것과 취약한 처리가 외부 요청을 받는 서버에서 실행되는것은 구분해서 파악해야한다.

# 3. 패치는 설치한 다음 배포까지 이어져야한다

이번주 Next.js 공지에서 안내한 해당 취약점의 수정 버전은 다음과 같다. 사용하는 릴리스 계열에 맞춰 확인해야한다.

| 사용 계열 | 안내된 수정 버전 |
| --- | --- |
| 15.0.x | 15.0.5 |
| 15.1.x | 15.1.9 |
| 15.2.x | 15.2.6 |
| 15.3.x | 15.3.6 |
| 15.4.x | 15.4.8 |
| 15.5.x | 15.5.7 |
| 16.0.x | 16.0.7 |

코드 저장소에서 버전을 바꿨다고 이미 실행중인 서버까지 바뀌는것은 아니다. lockfile을 갱신하고 새 결과물을 빌드한 다음 실제 인스턴스를 교체해야한다.

```text
영향 확인 → 의존성 업데이트 → 빌드와 검증
         → 배포 → 실행중인 결과물의 버전 확인
```

배포가 여러 리전이나 여러 서비스로 나뉘어있다면 빠진 환경이 없는지도 살펴보자. 오래된 Preview나 테스트용 서버가 계속 외부에 열려있는 경우도 확인 대상이 될 수 있다.

호스팅 업체가 임시 완화 조치를 제공하더라도 패치를 대신하는것으로 보면 안된다. React 팀도 완화 조치에만 의존하지 말고 업데이트하도록 안내하고있다.

# 4. 수정한 서버가 정상 동작하는지도 확인하자

보안 업데이트에서는 빠르게 적용하는것이 중요하다. 동시에 변경한 결과물이 실제 서비스를 처리하는지도 확인해야한다.

우선 주요 페이지와 로그인, 폼 제출, 서버와 연결되는 화면을 확인해보자. 빌드가 성공해도 배포 환경의 설정이나 특정 경로에서 문제가 발생할 수 있다.

패치 전후에 어떤 이미지와 lockfile을 사용했는지 기록하면 대응 범위를 설명하기 쉽다. 보안 공지를 읽은 시점과 전체 인스턴스의 교체가 끝난 시점도 다를 수 있다.

```text
남겨둘 정보
영향받는 서비스 / 변경 버전 / 빌드 식별자
배포 범위 / 확인 결과 / 추가 조사 항목
```

의심스러운 요청이나 실행 흔적이 있다면 패치 작업과 별도로 조사해야한다. 업데이트는 취약한 코드 경로를 수정하는 작업이지 이미 발생한 변경까지 자동으로 되돌리는 작업은 아니다.

원격 코드 실행은 서버 프로세스가 접근할 수 있는 범위와도 연결된다. 운영 계정과 네트워크, 비밀값의 접근 범위를 평소에 제한하는 이유도 이런 상황에서 중요해진다.

# 5. 프론트엔드와 백엔드의 경계가 달라졌다

이번 문제를 보면 프론트엔드 의존성은 화면 배포때만 신경쓰면 된다는 구분이 어렵다. React 기반 프레임워크가 서버 요청을 처리한다면 그 의존성도 서버의 공격 표면에 포함된다.

팀에서 누가 해당 공지를 확인하고 어느 서비스의 버전을 추적할지 정해두면 좋겠다. 담당 영역이 프론트엔드라는 이유로 서버 패치 절차에서 빠지면 대응이 늦어질 수 있다.

또한 의존성 목록을 갖고있는것과 실제 실행 위치를 아는것은 다르다. 어떤 앱이 어떤 환경에 배포돼있는지 연결할 수 있어야 영향을 확인하기 쉽다.

새로운 기능을 도입할때도 실행 경계를 같이 이해하면 좋겠다. 코드가 브라우저에서 실행되는지, 서버에서 외부 입력을 처리하는지에 따라 운영 책임이 달라진다.

# 마무리

이번 React2Shell은 React의 서버 기능을 사용하는 서비스에서 의존성 보안 패치를 직접적인 운영 작업으로 다뤄야한다는 사실을 보여준다.

개인적으로는 React를 사용한다는 정보만으로 영향을 판단하기보다 RSC와 프레임워크, 실제 배포 버전을 연결해서 확인하는 과정이 중요해보인다.

우선 운영중인 서비스의 구성과 수정 버전을 확인하고 배포까지 이어가야겠다. 저장소의 숫자를 바꾼것에서 끝내지 말고 외부 요청을 받는 서버가 실제로 바뀌었는지 확인해야겠다..


[2025.12.05 주간 개발 트렌드] React2Shell 정리 (RSC 취약점, 영향 범위, 패치)

독자의 메모