Firefox 158이 막은 샌드박스 탈출…업데이트를 미루면 안 되는 이유

Mozilla는 2026년 10월 13일 Firefox 158 보안 권고를 공개하고 전체 영향도를 ‘높음’으로 분류했다. 수정 목록에는 웹 콘텐츠를 가두는 샌드박스의 경계를 벗어날 수 있는 결함과 메모리 안전성 문제가 포함된다. 업무용 브라우저에서는 업데이트 파일의 배포 여부보다 수정된 버전이 실제로 실행 중인지가 중요하다.

같은 날 공개된 CVE-2026-109705 취약점 기록은 네트워크 구성요소의 경계 조건 오류와 해제 후 사용 문제가 샌드박스 탈출 및 사이트 격리 문제로 이어진다고 설명한다. 수정 버전은 일반판 Firefox 158과 장기 지원판 Firefox ESR 153.5로 각각 적혀 있다. 두 계열을 함께 쓰는 조직이라면 모든 기기에 같은 버전 번호를 요구하는 방식으로 패치 여부를 판정해서는 안 된다.

네트워크 결함이 격리 경계를 건드린다

이번 권고의 네트워크 항목에는 성격이 다른 샌드박스 탈출 결함이 함께 들어 있다. 하나는 잘못된 경계 조건과 해제 후 사용이 결합된 사이트 격리 문제이고, 다른 항목에는 해제 후 사용이나 잘못된 경계 조건에 따른 탈출 문제가 따로 기재됐다. 이름이 비슷해도 각각 별개의 취약점이므로 하나의 공격 과정으로 이어진다고 해석할 근거는 없다.

샌드박스는 웹 콘텐츠가 브라우저와 운영체제의 다른 영역에 미칠 수 있는 영향을 제한한다. 사이트 격리는 서로 다른 사이트의 처리 영역을 분리하는 보호 장치다. 네트워크 구성요소에서 이 경계와 관련된 결함이 수정됐다는 사실은, 웹페이지를 제한된 영역에서 실행한다는 브라우저의 기본 보호 방식과 직접 연결된다.

업무용 기기에서는 사내 서비스와 외부 웹사이트를 같은 브라우저에서 여는 경우가 있다. 이때 격리 결함을 남겨 두는 것은 특정 화면의 표시 오류를 남겨 두는 것과 성격이 다르다. 다만 공개된 취약점 설명만으로 특정 사이트 방문만으로 탈출이 성공한다거나 실제 침해가 발생했다고 단정할 수는 없다.

운영 판단의 출발점은 공격을 재현하는 일이 아니라 수정 버전의 존재다. 결함이 알려진 뒤에도 이전 빌드를 계속 실행하면 해당 결함을 고친 코드가 적용되지 않은 상태가 이어진다. 그래서 정기 기능 개선 일정에 맞춰 배포를 미루기보다 보안 수정의 적용 시점을 따로 정할 이유가 생긴다.

저장소와 그래픽에도 메모리 안전성 수정이 있다

수정 범위는 네트워크에 그치지 않는다. 웹사이트가 데이터를 저장하는 IndexedDB에는 해제 후 사용 문제가 기재됐고, 그래픽의 텍스트 처리와 Canvas2D에도 같은 유형의 결함이 올라 있다. 그래픽 구성요소에는 초기화되지 않은 메모리와 관련된 샌드박스 탈출 항목도 별도로 포함됐다.

해제 후 사용은 프로그램이 사용을 끝낸 메모리를 다시 참조하는 오류다. 같은 오류 유형이라도 발생 위치와 공격 조건에 따라 결과는 달라진다. 따라서 IndexedDB, 텍스트 처리, Canvas2D 항목을 모두 샌드박스 탈출 취약점이라고 부를 수는 없지만, 브라우저가 웹 콘텐츠를 처리하는 여러 경로에서 수정이 이뤄졌다는 점은 분명하다.

IndexedDB는 웹 애플리케이션의 로컬 데이터 저장에 쓰이고, 그래픽 경로는 페이지의 글자와 그림을 표시한다. 사용자가 별도 관리 기능을 켜야만 접하는 영역이 아니다. 업무용 브라우저의 위험을 평가할 때 특정 확장 기능이나 드문 설정만 살피는 방식으로는 이번 수정 범위를 제대로 설명하기 어렵다.

그래픽의 샌드박스 탈출 항목은 메모리 처리 오류가 격리 경계 문제로도 이어질 수 있음을 보여준다. 그렇다고 권고에 적힌 결함 유형만으로 실제 공격의 성공 조건이나 피해 범위를 계산할 수는 없다. 확인 가능한 조치는 각 결함을 고친 브라우저 계열의 버전을 배포하는 것이다.

업데이트 구성요소와 프로세스 권한도 수정 대상이다

Application Update 구성요소에는 권한 상승 취약점이 포함됐다. 새 버전을 받는 기능 자체가 수정 목록에 있다는 점은 자동 업데이트 설정과 현재 보안 상태를 구분해야 하는 이유다. 자동으로 내려받도록 설정돼 있어도, 실제로 어떤 버전이 실행 중인지는 별도로 확인해야 한다.

프로세스 샌드박싱 구성요소에는 정보 노출과 권한 상승이 함께 적힌 항목이 있다. 네트워크의 샌드박스 탈출과 결함 위치는 다르지만, 두 항목 모두 브라우저 내부의 권한 경계와 관계된다. 이번 배포를 단순한 메모리 오류 수정으로만 분류하면 업데이트 구성요소와 프로세스 보호 영역의 변경을 놓치게 된다.

기업 정책 구성요소에는 완화 조치 우회로 분류된 항목도 있다. 이 분류가 곧 특정 기업의 관리 정책이 실제로 우회됐다는 뜻은 아니다. 중앙 정책으로 업데이트를 관리하는 조직에는 정책이 설정돼 있다는 사실과 단말에 수정 버전이 적용됐다는 사실을 따로 확인할 필요가 있다.

이처럼 취약점은 네트워크, 저장소, 그래픽, 업데이트와 프로세스 보호 영역에 흩어져 있다. 한 구성요소를 사용하지 않는다고 여겨 배포를 늦추기보다, 조직에서 실행 중인 Firefox 계열 전체를 확인하는 편이 수정 범위에 맞다. 호환성 점검이 필요하다면 영향을 받는 내부 웹 서비스와 확장 기능을 먼저 정해 점검 결과를 배포 결정에 바로 반영해야 한다.

일반판과 ESR은 서로 다른 수정 버전을 따른다

일반판과 ESR은 별도의 출시 계열이다. 따라서 일반판의 버전 번호를 기준으로 ESR 기기를 일괄 미패치로 표시하면 잘못된 결과가 나온다. 반대로 제품명에 ESR이 붙었다는 이유만으로 이미 수정됐다고 판단할 수도 없다. 자산 목록에는 제품 계열과 설치 버전을 함께 기록해야 한다.

개별 사용자는 브라우저 메뉴의 ‘도움말 → Firefox 정보’에서 실행 버전을 확인할 수 있다. Mozilla의 Firefox 업데이트 안내는 다운로드한 업데이트가 재시작 후 적용된다고 설명한다. 배포 시스템에 다운로드 성공이 표시돼도 재시작 전 브라우저가 이전 코드를 실행하고 있을 수 있으므로, 재시작 뒤 표시되는 버전을 기준으로 확인해야 한다.

설치 경로에 따라서도 업데이트를 받는 방식이 다르다. Mozilla에서 직접 설치한 브라우저와 운영체제의 패키지 관리자 또는 앱 스토어를 통해 설치한 브라우저는 같은 알림을 보여주지 않을 수 있다. 기업의 별도 배포 도구를 쓰는 경우에도 도구가 작업을 완료했다고 보고한 시점과 사용자가 새 버전으로 브라우저를 다시 연 시점은 구별해야 한다.

업무용 배포에서는 먼저 일반판과 ESR 기기를 나누고, 해당 계열의 수정 버전에 도달하지 못한 단말을 추려야 한다. 오래 실행한 브라우저나 재시작을 미룬 단말은 배포 성공 집계에서 빠뜨리기 쉬운 대상이다. 예외가 필요한 내부 서비스가 있다면 영향을 받는 기기와 재배포 시점을 기록해, 전체 배포 완료 표시가 남은 구버전을 가리지 않도록 해야 한다.

결국 이번 수정의 적용 여부는 패치 파일이 전달됐다는 기록만으로 결정되지 않는다. 각 단말에서 제품 계열에 맞는 버전이 재시작 후 실행되는지 확인해야, 알려진 격리 경계와 메모리 안전성 결함을 업무 환경에서 제거했다고 판단할 수 있다.

함께 읽기:

• Firefox 155 보안 패치…샌드박스 탈출 취약점까지 막았다
• Windows 제로데이 2건이 악용 중…업데이트 수보다 먼저 볼 CVE
• AI 코딩 에이전트 7종이 업데이트 훅에 뚫렸다…모델은 공격을 못 본다