Playwright 1.64.1, 번들 Chromium 구버전·샌드박스 기본 꺼짐

Playwright로 AI 에이전트가 웹을 탐색한다면 패키지 버전과 브라우저 실행 설정을 함께 확인해야 한다. 2026년 11월 3일 13:09 KST 재확인 기준, 최신 안정판 Playwright 1.64.1의 번들 Chromium은 156.0.8078.4다. Chrome의 10월 27일 보안 수정 공지 버전인 156.0.8078.73/.74보다 앞선 빌드이며, Playwright의 chromiumSandbox 옵션은 기본값이 false다.[2][3][4][5]

위험은 악성 페이지가 브라우저 취약점 악용에 성공하고, 샌드박스가 꺼져 있으며, 브라우저 프로세스에 중요한 파일을 읽을 권한까지 있을 때 커진다. 버전 차이만으로 실제 침해를 단정할 수는 없다. 업데이트만으로 점검이 끝나지 않는 이유도 여기에 있다. 확인 시점에는 최신 Playwright도 위 번들을 사용하고, 패키지를 갱신해도 샌드박스 기본값은 true로 바뀌지 않는다.[2][3][5]

점검 요약

Playwright 패키지와 실제 실행 브라우저 버전을 따로 확인한다. 임의의 웹사이트를 여는 작업은 업데이트된 별도 Chrome, 명시적인 샌드박스 설정, non-root 실행을 함께 검토한다. 컨테이너나 VM에도 실계정·홈 디렉터리·상시 토큰을 그대로 넘기지 않는 구성이 필요하다. 버전 차이만으로 개별 CVE의 악용 가능성이나 침해 발생을 확정해서는 안 된다.

최신 Playwright인데도 왜 브라우저 버전을 확인해야 할까?

Playwright 패키지의 최신 여부와 그 패키지가 사용하는 브라우저의 보안 업데이트 상태는 별개의 확인 항목이기 때문이다.

공식 1.64 릴리즈 노트에는 Chromium 156.0.8078.4가 기재돼 있다. v1.64.1의 browsers.json에서 chromium과 chromium-headless-shell 모두 browserVersion이 156.0.8078.4, revision이 1248로 지정돼 있다. npm의 최신 안정판 정보도 확인 시점에는 1.64.1이었다.[1][2][3]

따라서 이 시점에 “최신 Playwright로 올렸다”는 사실만으로 번들 Chromium이 Chrome의 보안 수정 공지 버전까지 올라갔다고 볼 수 없다. 이후 패치에서는 구성이 달라질 수 있으므로, 이 숫자를 영구적인 상태로 받아들이기보다 업데이트할 때마다 패키지와 브라우저를 나눠 확인하는 편이 맞다.[2][3]

버전은 개발자 노트북보다 실제 작업이 돌아가는 환경에서 먼저 확인한다. CI, 컨테이너, 에이전트 실행 서버에서 선택한 채널과 실행 브라우저 버전을 기록하고, 재배포 뒤에도 같은 항목을 확인하는 방식이다. 패키지만 갱신하고 실행 환경에는 이전 브라우저가 남는 일을 피하기 위해서다.

Chrome 보안 공지에서 어디까지 확인된 사실일까?

확인된 것은 보안 수정 공지와 버전의 선후 관계이며, 해당 Playwright 번들에서 각 취약점을 재현했다는 사실은 아니다.

Chrome은 2026년 10월 27일 Windows와 Mac에 156.0.8078.73/.74, Linux에 156.0.8078.73 업데이트를 공지했다.

공지에는 Critical 등급으로 CVE-2026-118306의 FileSystem 메모리 손상, CVE-2026-118331의 FileAPI 입력 검증, CVE-2026-118348의 Skia 입력 검증, CVE-2026-118344의 Layout use-after-free가 포함돼 있다.[4]

번들의 156.0.8078.4가 이 공지 버전보다 앞선 빌드라는 비교는 가능하다. 그러나 이 비교만으로 개별 CVE가 해당 번들에 정확히 어떻게 영향을 미치는지, 별도 백포트가 있는지, 특정 실행 환경에서 악용이 가능한지까지 확정할 수는 없다. 개별 영향 판단에는 추가 확인이 필요하다. Chrome도 상세 정보 접근이 제한될 수 있다고 안내한다.[2][4]

이번 경고는 개발자 nisten의 X 게시물과 후속 설명에서 제기됐다. 후속 글은 개별 CVE를 테스트한 결과가 아니라 버전 번호를 비교한 판단이라고 밝힌다. X 뉴스도 이를 소개하지만 게시물 요약이므로 독립적인 취약점 검증 자료로 보기는 어렵다. 이 글에서 대조한 자료만으로 Playwright를 통한 대규모 실제 침해가 발생했다고 확인할 수는 없다.[8][9][10]

자기 사이트 E2E 테스트와 AI 에이전트 탐색은 무엇이 다를까?

주요 차이는 브라우저가 방문할 대상과 실행할 콘텐츠를 운영자가 얼마나 제한할 수 있느냐에 있다.

자기 사이트의 E2E 테스트는 보통 정해진 주소와 테스트 흐름을 따른다. 반면 AI 에이전트는 검색 결과, 페이지 링크, 외부 문서의 지시를 따라 예상하지 못한 주소를 열 수 있다. 프롬프트 주입 자체가 브라우저 취약점은 아니지만, 에이전트의 이동 대상을 바꿔 악성 페이지에 닿게 하는 경로가 될 수 있다는 차이다.

그렇다고 신뢰된 사이트의 위험이 0이라는 뜻은 아니다. 제3자 리소스와 사용자 입력이 섞일 수 있으므로 테스트 대상의 이름만 보고 실행 권한을 넓혀서는 안 된다. 위 표는 안전과 위험을 단정하는 구분이 아니라, 어떤 노출 경로부터 줄일지 정하는 기준이다.

앞서 설명한 조건이 겹치면 사용자 권한으로 코드가 실행되고, 그 권한으로 접근 가능한 .env, SSH 키, 토큰 등이 유출될 가능성을 고려해야 한다. 반대로 브라우저를 띄운 사실만으로 이런 결과가 발생했다고 볼 수는 없다. 샌드박스 역시 피해를 제한하기 위한 방어 계층이지 모든 공격을 막는 보증은 아니다.

별도 Chrome과 샌드박스는 어떻게 적용할까?

Google Chrome을 별도로 설치하고 업데이트 상태를 확인한 뒤, Chrome 채널과 샌드박스 옵션을 명시하는 구성을 검토할 수 있다.[5][7]

const browser = await chromium.launch({
  channel: 'chrome',
  chromiumSandbox: true,
});

channel: 'chrome'은 별도 설치된 Google Chrome을 선택하기 위한 설정이다. 이 코드가 Chrome을 설치하거나 자동 업데이트 완료를 보장하지는 않는다. 실제 작업 환경에 Chrome이 설치돼 있는지, 업데이트가 적용됐는지 별도로 확인해야 한다. 샌드박스도 설정값만 적고 끝내지 말고 해당 환경에서 정상적으로 실행되는지 점검해야 한다.[5][7]

브라우저를 바꾸면 회귀 테스트도 필요하다. 공식 문서는 Chrome 채널과 기본 브라우저의 headless 구현 차이를 설명한다. 기존 작업이 그대로 통과할 것이라고 가정하지 말고 로그인, 페이지 이동, 다운로드처럼 업무에 필요한 흐름을 확인한다. 오류가 난다는 이유로 샌드박스를 끄고 원래 권한을 돌려주는 대신 실행 사용자와 환경 제약부터 살펴보는 편이 낫다.[7]

컨테이너 안에서 실행하면 충분할까?

컨테이너 하나만으로 충분하다고 볼 수 없으며, 사용자 권한과 마운트 구성을 함께 제한해야 한다.

Playwright 공식 Docker 이미지는 testing과 development 용도이며, 신뢰할 수 없는 웹사이트 방문에는 권장되지 않는다. 기본 실행 사용자는 root이고 이 경우 Chromium 샌드박스가 비활성화된다. 공식 문서는 crawling과 scraping에 별도 사용자 및 seccomp profile 사용을 권고한다.[6]

접근 범위를 줄이는 방법으로는 non-root 실행, 컨테이너 또는 VM 격리, 홈 디렉터리와 브라우저 프로필 분리가 있다. 호스트 홈 전체, 실계정의 로그인 프로필, SSH 키와 상시 토큰을 그대로 마운트하지 않는다. Docker socket 연결과 privileged 실행도 피하는 구성을 권한다.

이는 특정 CVE의 공식 해결책이 아니라, 브라우저 프로세스가 침해됐을 때 접근 범위를 줄이기 위한 제안이다.

운영자는 무엇을 확인하고 작업을 다시 열면 될까?

버전, 실행 옵션, 권한, 회귀 테스트 결과를 각각 확인한 뒤 허용할 작업 범위를 정하면 된다.

• 버전: 최신 Playwright로 갱신하고 번들 및 실제 실행 브라우저 버전을 각각 기록한다.
• 방문 범위: 자기 사이트 E2E와 임의 URL을 여는 에이전트를 구분한다.
• 실행 옵션: 열린 웹에는 업데이트된 별도 Chrome과 chromiumSandbox: true를 명시하고 실제 적용을 확인한다.
• 권한·격리: root 실행을 피하고 컨테이너나 VM에 실계정·홈 디렉터리·실사용 프로필을 넘기지 않는다.
• 동작 확인: 변경 뒤 로그인·이동·다운로드 등 필요한 흐름을 회귀 테스트한다.

이어서 접근 가능한 파일과 자격증명을 확인한다. 실계정 대신 테스트 전용 계정을 사용하고, 필요한 토큰도 범위와 수명을 최소화하는 구성을 권한다. 에이전트가 문서나 검색 결과를 읽는 권한과, 그 내용에 따라 다른 도구를 실행하는 권한도 분리해서 검토할 항목이다. 에이전트 도구 실행 환경을 다룬 글도 이 권한 경계를 살피는 관점에서 함께 읽을 수 있다.

마지막으로 정상 업무 흐름을 다시 실행해 브라우저 변경에 따른 오류를 확인한다. 완료 기준은 “업데이트 버튼을 눌렀다”가 아니라 실제 실행 버전과 설정, 접근 가능한 자원, 회귀 테스트 결과가 남아 있는 상태다. 보안 공지의 버전 비교와 자기 환경의 노출 조건을 분리해서 기록하면, 이후 패치가 나왔을 때도 같은 기준으로 재점검할 수 있다.

출처