핵심 POINT
React 프로젝트는 2026년 10월 14일 서버 컴포넌트의 인증 없는 원격 코드 실행 취약점(CVE-2026-126187)을 공개하고 보안 업데이트를 권고했습니다. 이 권고는 11월 10일 갱신됐고, KISA도 11월 12일 업데이트를 권고했습니다. 심각도는 Critical, CVSS v4 기준 9.5점입니다.
영향 대상은 모든 React 앱이 아니라 react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack 세 패키지입니다. 서버 컴포넌트를 쓰지 않는 앱은 영향이 없다고 공식 권고가 밝혔습니다.
해결 버전은 19.0.9, 19.1.10, 19.2.9, 19.3.1입니다. Next.js도 별도 보안 권고를 내고 16.4.1에서 고쳤습니다. 이 패키지는 프레임워크 안에 포함돼 있는 경우가 많아, 직접 설치한 적이 없어도 의존성 목록과 프레임워크 공지를 함께 확인해야 합니다.
React 서버 컴포넌트 취약점, 우리 웹서비스도 영향받을까?
웹 프런트엔드 개발에서 React를 쓰는 조직은 많고, 최근에는 서버에서 화면 일부를 만들어 내려보내는 서버 컴포넌트 방식도 프레임워크를 통해 널리 쓰입니다. 그런데 이 서버 컴포넌트에서 인증 없이 원격으로 코드를 실행할 수 있는 취약점이 공개됐습니다. 우리 서비스가 해당되는지, 어떤 버전을 확인해야 하는지가 개발·보안 담당자의 가장 큰 관심사입니다.
React 프로젝트는 2026년 10월 14일 GitHub 보안 권고(GHSA-xqc2-xf4c-x3h3)를 공개하고 취약점을 고친 패치 버전을 안내했습니다. 이 권고는 11월 10일 갱신됐고, KISA도 11월 12일 보호나라 보안공지로 같은 취약점의 업데이트를 권고했습니다. 이번 글에서는 두 공식 자료와 Next.js의 별도 보안 권고를 바탕으로 영향받는 패키지와 버전, 서버 컴포넌트를 쓰지 않는 앱의 해당 여부, 우리 서비스에서 확인하는 방법과 업데이트 순서를 차례대로 정리합니다.
■ React 서버 컴포넌트 취약점
출처: AI(ChatGPT) 생성 이미지
React 서버 컴포넌트는 화면을 구성하는 일부 코드를 브라우저가 아니라 서버에서 실행해 결과를 내려보내는 방식입니다. 서버와 브라우저가 주고받는 데이터를 정해진 형식으로 풀어내는 과정이 필요한데, 이번 취약점은 이 과정에서 발생합니다. KISA는 이를 신뢰할 수 없는 데이터의 역직렬화(Deserialization of Untrusted Data) 취약점으로 분류했고, 식별 번호는 CVE-2026-126187입니다.
React 프로젝트의 보안 권고는 조작한 요청 데이터를 서버 컴포넌트를 지원하는 프레임워크에 보내면 원격 코드 실행으로 이어질 수 있다고 설명합니다. 인증이 필요하지 않고, 네트워크를 통해 공격할 수 있으며, 공격 복잡도가 낮다는 점이 CVSS v4 평가 항목에 반영돼 9.5점(Critical)이 매겨졌습니다. 발견자는 권고문에 evolutionstorm으로 표기돼 있습니다.
다만 같은 권고문은 이 취약점이 응답 데이터에 여러 개의 타입 배열(Typed Array)과 공격자가 통제할 수 있는 값이 함께 포함되는 매우 드문 조건에서 발생한다고 적었습니다. CVSS 평가 항목으로 보면 공격 복잡도는 낮고(AC:L), 인증이나 사용자 상호작용은 필요하지 않지만(PR:N, UI:N), 공격이 성립하려면 특정 조건이 필요하다(AT:P)는 뜻입니다. 인증 없이 공격할 수 있지만 특정 조건이 충족돼야 하므로, 서버 컴포넌트를 쓰는 모든 서비스에서 곧바로 코드 실행이 가능한 것은 아닙니다. 그럼에도 React 프로젝트는 즉시 업데이트하라고 권고했습니다. 공식 자료에는 실제 공격이나 피해 사례가 언급돼 있지 않으므로, 이 글에서도 공격이 진행 중이라고 단정하지 않습니다.
■ 영향받는 패키지와 해결 버전
영향 대상은 React 전체가 아니라 서버 컴포넌트와 번들러를 연결하는 아래 세 패키지입니다. 세 패키지는 버전 구간과 해결 버전이 같습니다.
| 영향받는 버전 | 해결 버전 |
|---|---|
| 19.0.0 이상 19.0.9 미만 | 19.0.9 이상 |
| 19.1.0 이상 19.1.10 미만 | 19.1.10 이상 |
| 19.2.0 이상 19.2.9 미만 | 19.2.9 이상 |
| 19.3.0 | 19.3.1 이상 |
대상 패키지는 react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack 입니다. KISA 보안공지(2026년 11월 12일)와 React 보안 권고 기준입니다.
버전 구간을 보면 19.0, 19.1, 19.2 계열은 각각 마지막 패치 버전으로, 19.3 계열은 19.3.1로 올리라는 의미입니다. 쓰고 있는 계열을 건너뛰어 다른 계열로 옮길 필요는 없습니다. 권고문도 해당 계열에 수정을 이식(백포트)했다고 설명합니다. 반대로 19 미만 버전은 권고문의 영향 버전 목록에 없으므로, 이번 권고만 놓고 보면 대상이 아닙니다. 다만 이전 버전에는 다른 취약점이 있을 수 있어 별도로 확인이 필요합니다.
■ 서버 컴포넌트를 쓰지 않으면 안전할까?
출처: AI(ChatGPT) 생성 이미지
React 보안 권고는 해당 여부를 두 가지로 구분합니다. 앱의 React 코드가 서버를 쓰지 않으면 영향받지 않고, 서버 컴포넌트를 지원하는 프레임워크나 번들러, 번들러 플러그인을 쓰지 않아도 영향받지 않습니다. 브라우저에서만 동작하는 단일 페이지 앱이 여기에 해당합니다.
반대로 서버 컴포넌트를 지원하는 프레임워크로 만든 서비스는 확인이 필요합니다. 공식 권고는 영향 패키지를 세 가지로 적었지만, 실제 서비스에서는 프레임워크 버전으로 확인하게 됩니다. 여기서 놓치기 쉬운 부분이 있습니다. 위 세 패키지를 개발자가 package.json에 직접 적지 않았더라도, 프레임워크가 내부 의존성으로 가져오거나 자체 빌드에 포함시켜 쓰는 경우가 있습니다. 이런 경우에는 프레임워크 개발사가 내놓는 보안 공지와 업데이트 버전을 따라야 합니다. 예를 들어 Next.js는 이번 취약점과 관련해 별도의 보안 권고를 공개했고, 그 내용은 아래 업데이트 순서에서 설명합니다.
정리하면 아래와 같습니다.
• 서버 없이 브라우저에서만 도는 React 앱. 권고문 기준으로 영향이 없습니다.
• 서버 컴포넌트를 지원하는 프레임워크나 번들러 플러그인을 쓰는 서비스. 위 세 패키지의 버전 확인이 필요합니다.
• 외부 업체가 만든 웹사이트나 솔루션. 개발 업체나 공급사에 서버 컴포넌트 사용 여부와 패치 계획을 문의합니다.
■ 우리 서비스가 해당되는지 확인하는 방법
출처: AI(ChatGPT) 생성 이미지
아래 순서대로 보면 서비스별로 영향 여부를 빠르게 가릴 수 있습니다. 명령어는 공식 권고에 포함된 내용이 아니라 일반적인 Node.js 개발 환경의 점검 방법입니다. 프로젝트 폴더에서 실행합니다.
1. 세 패키지가 설치돼 있는지 확인
직접 설치하지 않은 간접 의존성까지 보려면 전체 의존성 트리를 조회해야 합니다.
npm ls --all react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopackpnpm이나 yarn을 쓴다면 같은 목적의 명령을 쓸 수 있습니다.
pnpm why react-server-dom-webpack
yarn why react-server-dom-webpack조회 결과 해당 패키지가 나타나지 않는다면 현재 확인 중인 프로젝트의 의존성 트리에서는 발견되지 않은 것입니다. 다만 프레임워크 내부에 포함된 패키지나 실제 운영 환경의 빌드 결과물은 별도로 확인해야 하므로, 미검출 결과만으로 영향이 없다고 단정해서는 안 됩니다. pnpm why와 yarn why는 패키지 하나씩 조회하므로 패키지 이름을 바꿔 반복합니다.
2. 잠금 파일과 운영 배포물의 버전 비교
잠금 파일은 프로젝트가 실제로 설치하도록 고정한 의존성 버전을 담은 중요한 자료입니다. 다만 사용하는 패키지 관리자에 따라 package-lock.json, pnpm-lock.yaml, yarn.lock 등 파일 형식이 다릅니다. 먼저 의존성 조회 명령어로 설치된 버전을 확인하고, 사용 중인 잠금 파일과 운영 배포물의 버전이 같은지 비교하는 것이 좋습니다.
3. 서버 컴포넌트 사용 여부 확인
프레임워크의 서버 컴포넌트 기능을 쓰는지 개발팀에 확인합니다. 설치돼 있어도 쓰지 않는다면 위험 정도가 달라질 수 있지만, 권고문은 해당 패키지를 쓰고 있다면 즉시 올리라고 안내했으므로 쓰지 않는 것이 확인되기 전에는 업데이트 대상에 포함하는 것이 안전합니다.
4. 개발 환경 밖의 배포물 확인
소스 저장소만 확인하면 이미 배포된 서버가 빠질 수 있습니다. 운영 중인 컨테이너 이미지와 서버에 배포된 빌드 결과물의 의존성도 같은 방식으로 확인합니다. 개발 환경은 올렸지만 운영 이미지는 이전 빌드 그대로인 경우가 빠지기 쉬운 부분입니다.
■ 해결 버전으로 업데이트하는 순서
해결 버전은 쓰고 있는 계열의 패치 버전입니다. 프레임워크가 세 패키지를 관리하는 경우와 직접 의존하는 경우에 따라 방법이 다릅니다. 아래는 일반적인 업데이트 순서이며, 공식 권고는 패치 버전으로 올리라는 내용까지만 안내합니다.
• 프레임워크가 패키지를 관리하는 경우. 프레임워크 개발사가 이번 취약점을 반영한 새 버전을 내놓았는지 확인하고 프레임워크를 올립니다. 올린 뒤에는 위 확인 방법으로 세 패키지가 해결 버전 이상으로 바뀌었는지 다시 봅니다.
• 직접 의존하는 경우. 쓰는 계열에 맞는 해결 버전으로 올립니다.
npm install react-server-dom-webpack@19.2.9위 명령은 19.2 계열에 웹팩 패키지를 쓰는 경우의 예시입니다. 다른 번들러 패키지나 계열이라면 이름과 버전을 해당 값으로 바꿉니다.
• Next.js를 사용하는 경우. Next.js는 별도의 보안 권고(GHSA-673q-mjm6-r5xr)를 2026년 10월 14일 공개했습니다. App Router와 Cache Components를 쓰는 애플리케이션에서 여러 개의 타입 배열을 반환하는 use cache 함수가 있으면 원격 코드 실행으로 이어질 수 있다는 내용입니다. 영향 버전은 16.0.0부터 16.4.0까지이고 수정 버전은 16.4.1입니다. 해당 권고는 알려진 우회 방법이 없다고 밝혔고, 그런 함수가 없는 애플리케이션도 즉시 업데이트하라고 안내했습니다. Next.js를 쓰는 조직은 React 패키지 버전만이 아니라 Next.js 자체의 수정 버전 적용 여부도 확인해야 합니다. 다른 프레임워크는 각 개발사의 보안 공지를 따릅니다.
• 올린 뒤 빌드와 테스트를 거쳐 운영에 반영하고, 컨테이너 이미지를 다시 빌드해 배포합니다. 잠금 파일이 갱신됐는지도 확인합니다.
외부 업체가 운영하는 서비스는 직접 올릴 수 없으므로, 업체에 영향 여부와 패치 일정을 서면으로 확인해 두는 것이 좋습니다.
■ 업데이트가 늦어질 때 함께 보아야 할 점검 사항
공식 자료는 업데이트 외의 임시 완화 방법을 따로 제시하지 않았습니다. 업데이트가 바로 어렵다면 아래 일반적인 운영 점검으로 노출 범위를 파악해 둘 수 있습니다. 이 내용은 공식 권고가 아니라 웹서비스 운영에서 통상 확인하는 항목이며, 패치를 대신하지는 못합니다.
• 서버 컴포넌트를 처리하는 서비스가 인터넷에 직접 노출돼 있는지, 내부망 서비스인지 구분합니다.
• 웹 방화벽이나 접근 제어 장비의 로그에서 해당 서비스로 들어오는 비정상 요청이나 오류가 늘었는지 살펴봅니다.
• 서버의 프로세스 생성, 외부로 나가는 연결, 새로 생긴 파일처럼 평소와 다른 동작이 없는지 확인합니다.
• 업데이트 일정이 정해지면 담당자, 배포 시각, 롤백 방법을 함께 정해 둡니다.
이상 징후가 보이면 업데이트와 별개로 침해 여부를 따로 조사해야 합니다.
■ 오픈소스 의존성 관리, 이번에 점검할 항목
이번 사례는 개발자가 직접 설치하지 않은 패키지에서 문제가 생길 수 있다는 점을 보여 줍니다. 아래 항목은 공식 발표 내용이 아니라 소프트웨어 공급망 보안 관점에서 일반적으로 점검하는 사항입니다.
• 의존성 목록 관리. 서비스별로 쓰는 프레임워크와 주요 패키지의 버전을 한 곳에서 조회할 수 있게 합니다.
• 취약점 알림 체계. 보안 권고가 나왔을 때 누가 영향 여부를 판단하고 언제까지 처리할지 책임과 기한을 정합니다.
• 운영 배포물의 추적. 어떤 소스 버전으로 만든 이미지가 운영에 떠 있는지 대응시켜 두면 영향 범위를 빠르게 좁힐 수 있습니다.
• 외부 개발 업체 관리. 위탁 개발한 서비스의 사용 기술과 패치 책임을 계약과 운영 절차에 명시합니다.
SK쉴더스는 웹 애플리케이션 취약점 진단과 모의해킹으로 서비스의 보안 수준을 점검하고, 보안관제와 침해사고 대응 서비스로 이상 징후 탐지와 사고 분석을 지원하고 있습니다.
■ 자주 묻는 질문
Q. React를 쓰면 모두 영향받나요?
A. 아닙니다. 영향 대상은 react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack 세 패키지의 해당 버전입니다. 권고문은 서버를 쓰지 않는 React 앱과, 서버 컴포넌트를 지원하는 프레임워크나 번들러를 쓰지 않는 앱은 영향받지 않는다고 밝혔습니다.
Q. 점수가 9.5점인데 모든 서비스가 위험한가요?
A. 점수는 취약점이 성립했을 때의 영향 정도를 나타냅니다. 권고문은 응답에 여러 타입 배열과 공격자가 통제하는 값이 함께 전달되는 매우 드문 경우에 영향을 준다고 설명했습니다. 다만 즉시 업데이트하라는 권고가 함께 있으므로 해당 패키지를 쓴다면 일정에 올리는 것이 좋습니다.
Q. 실제 공격이 있었나요?
A. React 보안 권고와 KISA 공지에는 실제 공격이나 피해 사례가 언급돼 있지 않습니다. 공개된 사실만으로 공격이 진행 중이라고 단정할 수 없지만, 수정 버전이 나온 만큼 빠른 업데이트가 권고됩니다.
Q. package.json에 없는데 확인해야 하나요?
A. 확인이 필요합니다. 프레임워크가 내부 의존성으로 가져오는 경우가 있어, 전체 의존성 트리와 잠금 파일을 조회하고 프레임워크 개발사의 보안 공지도 함께 보는 것이 좋습니다.
Q. Next.js를 쓰는데 어떻게 해야 하나요?
A. Next.js는 별도 보안 권고에서 16.0.0부터 16.4.0까지를 영향 버전으로, 16.4.1을 수정 버전으로 안내했습니다. React 패키지 버전과 함께 Next.js 버전도 확인하고 업데이트해야 합니다.
Q. 개발 환경만 올리면 되나요?
A. 부족합니다. 이미 배포된 컨테이너 이미지와 서버의 빌드 결과물은 다시 빌드하고 배포해야 바뀝니다. 운영 환경의 의존성 버전도 함께 확인해야 합니다.
