제로콘 2026, React2Shell 발견자 “웹 개발 편의성은 새 공격 통로”

23개국 연구자 모인 제로콘 2026, React2Shell 발견자 “최신 웹 개발의 편의성은 새 공격 통로”

Zer0Con 2026 · 서울 페어몬트 엠베서더 서울 · 서버 액션·Flight 프로토콜·역직렬화 이슈 집중 조명

현장 요약

한 문장 정리 제로콘 2026 첫 세션은 “개발자가 믿는 실행 경계”와 “서버가 실제로 받아들이는 입력” 사이의 틈이 커질수록 공격 표면도 커진다는 메시지를 던졌다.

비공개 오펜시브 보안 컨퍼런스 제로콘(Zer0Con) 2026이 2026년 4월 2일 서울 페어몬트 엠베서더 서울에서 열렸다. 10회를 맞은 이번 행사에는 23개국 130여 명의 글로벌 취약점 연구자가 참석해 최신 연구를 공유했다.

운영 환경에서는 “새 기능이 추가됐다”는 소식만큼이나 “그 기능이 외부 입력과 어떤 방식으로 맞닿는가”가 중요하다. 실무 기준으로 보면, 프레임워크의 편의 기능은 개발 속도를 올리지만 동시에 검증 책임을 개발자와 운영팀 쪽으로 밀어 넣기도 한다.

첫 발표: React2Shell 발견자 래클런 데이비드슨

올해 첫 발표는 카라페이스(Carafe)의 래클런 데이비드슨(Lachlan Davidson)이 맡았다. 그는 React2Shell(CVE-2025-55182)로 알려진 취약점을 최초로 발견한 연구자로 소개되며, 발표 제목은 “Discovering React2Shell and Unleashing the New Age of JavaScript Exploits”였다.

그가 던진 핵심 메시지 개발자가 “이 코드는 안전하게 동작할 것”이라고 믿는 방식과,
실제 서버가 받아들이고 실행하는 방식이 다르면 그 틈에서 취약점이 발생한다.
편의성은 곧바로 안전을 의미하지 않는다.

“서버에서만 실행된다”는 믿음이 위험해지는 순간

발표의 출발점은 최신 웹 개발에서 자주 보이는 “서버 전용” 신호다. 예를 들어 use server 같은 표식을 보면 많은 개발자는 “이 코드는 서버 내부에서만 실행될 것”이라고 직관적으로 받아들인다. 하지만 공격자 관점에서 보면, 이런 기능이 외부에서 호출 가능한 창구처럼 보일 수 있고, 접근 제어와 입력 검증이 빠져 있으면 예상치 못한 방식으로 두드릴 여지가 생긴다.

개발자가 놓치기 쉬운 지점

• 권한 확인의 누락: “내부 기능”이라고 생각해 인증/인가 체크를 생략하기 쉬움
• 입력 검증의 약화: 편의 기능이 데이터를 “알아서” 변환해줄 것이라 기대하는 순간이 생김
• 실행 경계 착시: 코드는 서버에 있지만, 호출은 네트워크 너머에서 올 수 있음

운영팀 관점 체크 “서버 액션(Server Actions)” 계열 엔드포인트가 어떤 규칙으로 노출되는지,
라우팅/미들웨어/권한 정책이 코드 단위로 일관되게 적용되는지부터 점검하는 게 현실적이다.

타입이 보장해주지 못하는 것들

데이비드슨은 타입 문제도 강조했다. 에디터와 타입 시스템은 “이 값은 숫자”, “이 값은 객체”라고 친절하게 알려주지만, 자바스크립트 런타임은 그 기대를 그대로 지켜주지 않을 수 있다. 겉으로는 안전해 보이는 코드가 실제 서버 입력에서 전혀 다른 형태의 값과 만나면, 예외 처리의 빈틈이나 예상치 못한 분기 흐름이 생기며 공격으로 이어질 수 있다.

현장에서 자주 나오는 패턴 “프론트에서 이미 검증했다” → “서버에서는 가볍게만 확인했다” → “예상치 못한 형태의 입력이 서버까지 도달했다”
이런 흐름이 반복되면, React2Shell 같은 체인형 취약점이 만들어질 토양이 생긴다.

Flight 프로토콜과 역직렬화, 그리고 ‘복잡한 데이터’의 시대

발표에서 특히 눈길을 끈 대목은 서버가 상태/데이터를 잠시 숨겨 보관했다가 다시 복원하는 구조에 대한 설명이었다. 최신 프레임워크는 개발 편의성을 위해 더 복잡한 형태의 데이터 구조를 서버와 주고받는다. 과거처럼 단순한 JSON만 오가던 시절에는 입력 형태를 예측하기 쉬웠지만, 이제는 Map/Set, 특수 객체, 지연 처리용 데이터 등 다양한 구조가 섞일 수 있다.

이 과정에서 “암호화되어 있으니 괜찮다”는 판단이 들어가면 위험해질 수 있다. 중요한 것은 암호화 자체보다, 복원 시점에서 다시 권한을 확인하고 입력을 검증하는 절차다. React2Shell 논의에서도 Flight 프로토콜과 역직렬화(Deserialization) 이슈가 자주 함께 거론되는 이유가 여기에 있다.

개발팀·보안팀이 함께 정리할 질문 이 데이터는 어디서 생성되고 어디서 복원되는가?
복원 과정에서 “신뢰 경계”는 어디까지인가?
복원 직후에 권한/입력 검증을 반드시 거치는가?

React2Shell을 “버그 하나”로만 보면 놓치는 것

데이비드슨은 React2Shell(CVE-2025-55182)을 단순히 “리액트에서 발생한 버그”로만 보지 않았다. 더 편리한 개발 경험을 만들기 위해 프레임워크가 복잡한 내부 프로토콜과 데이터 구조를 사용하기 시작했고, 그 결과 예전에는 잘 보이지 않던 새로운 공격 방법이 생겨났다고 설명했다.

실제 사용 시, 이 메시지는 특정 프레임워크를 탓하자는 이야기가 아니라 “경계의 변화”를 읽자는 쪽에 가깝다. 서버 액션, Flight 프로토콜, 역직렬화 같은 키워드는 지금의 웹 보안에서 “새로운 기본값”이 되어가고 있다.

현업을 위한 정리

바로 적용 가능한 5가지 점검 포인트 1) 서버 액션/서버 함수 엔드포인트에 인증·인가가 “기본 적용”인지 확인
2) 입력 검증은 클라이언트가 아니라 서버에서 종결되는지 재점검
3) 상태 복원/역직렬화 구간에 대한 로깅·모니터링 포인트를 확보
4) “암호화/서명됨”이라는 이유로 신뢰 경계를 넓히지 않기
5) 프레임워크 업데이트 공지에서 보안 이슈(특히 RCE/역직렬화)를 최우선으로 반영

제로콘 2026 첫 세션이 던진 결론은 명확했다. 최신 웹 개발의 편의성은 개발 속도를 올리지만, 동시에 새로운 공격 통로를 만들 수 있다. React2Shell을 계기로 서버 액션과 Flight 프로토콜, 역직렬화 구간을 “그냥 프레임워크가 처리해주는 영역”으로 남겨두지 않는 태도가 중요해졌다.