JetBrains IDE와 Toolbox, eMudhra 보안 업데이트를 지금 적용하자

지금 무엇부터 해야 할까?

JetBrains IDE와 Toolbox를 수정 버전으로 업데이트하고, JCEF와 jetbrainsd까지 따로 확인해야 한다. OS와 일반 브라우저를 최신으로 유지했어도 이번 문제를 모두 막았다고 볼 수 없다. IDE에 번들된 JBR 신뢰 저장소, 내장 브라우저 JCEF, 백그라운드 서비스 jetbrainsd의 인증서 신뢰가 각각 걸려 있기 때문이다. 개발자가 많이 쓰는 IDE인 만큼 이번 보안 업데이트는 반드시 적용하자.

이 글의 공식 자료 재확인 시점은 2026년 10월 31일 10시 08분 KST다. 연구자 보고는 10월 17일, JetBrains 공지는 10월 30일이다. 게시 시점에 JetBrains는 사용자 대상 악용을 인지하지 못했다고 밝혔다. 이는 공격이 없었다거나 피해가 없다는 확정이 아니다. 그렇다고 대규모 해킹이 발생했다고 확대할 근거도 없다.

eMudhra에서 무슨 일이 있었을까?

중간 인증기관 8개의 키 생성 취약점 때문에 개인키 복구가 가능하다는 보고가 나왔다. 문제가 된 인증서 체인을 계속 신뢰하는 환경에서는 공격자가 신뢰받는 것처럼 보이는 인증서를 만들 수 있다. 네트워크 트래픽을 가로챌 수 있는 공격자라면 JetBrains 도구가 연결하는 웹사이트나 서비스를 사칭할 수 있다는 것이 공지의 경고다.

개발자로서 걱정되는 지점은 보안 업데이트의 경계다. OS나 브라우저 벤더가 인증서를 차단했더라도, 별도 신뢰 저장소를 쓰는 프로그램까지 자동으로 정리되지는 않는다. 늘 실행하는 개발 도구 안에 다른 신뢰 기준이 남을 수 있다는 뜻이다.

JBR에는 Oracle의 CVE-2026-91403·CVE-2026-114820 수정이 통합됐다. JCEF 대응은 CVE-2026-118696, jetbrainsd 대응은 CVE-2026-118697로 구분된다. 하나의 업데이트 알림만 보고 모두 같은 조치라고 판단하지 말아야 한다.

어떤 제품을 어느 버전으로 올려야 할까?

아래는 공식 공지의 일부 라인에서 고른 대표 수정 버전이며, 전체 목록은 아니다. 업무용은 현재 사용하는 지원 라인의 수정 안정판을 우선 확인하자. 보안 패치를 받기 위해 RC나 EAP를 기본 선택으로 삼을 필요는 없다. 다른 라인은 글 끝의 IDE 보안 공지 전체 표와 대조해야 한다.

DataSpell은 표에 적은 2026.1 라인의 수정 버전을 확인하자. IDE 2025.1 이하와 Toolbox 3.7 이하는 이번 수정이 제공되지 않으므로 지원되는 수정 버전으로 이전해야 한다. Android Studio는 이번 JetBrains 표에 이름이 없어 포함 여부와 수정 버전을 확인하지 못했다. Google 안내를 별도로 확인해야 한다.

특히 2025.2.6.* IDE 패치는 현재 JBR만 수정하며, JCEF는 별도 핫픽스가 예정돼 있다. 2025.2 계열 사용자는 패치를 설치한 뒤에도 아래 JCEF 비활성화 임시 조치를 함께 적용해야 한다.

어떻게 업데이트하고 JCEF 예외를 처리할까?

Toolbox 자체 업데이트와 관리 중인 IDE 각각의 업데이트를 나눠 진행해야 한다. 먼저 Toolbox를 수정 버전으로 올리고, 설치된 각 IDE 인스턴스 옆의 Update를 적용한 다음 재시작하자. 자동 업데이트는 Settings → Tools → Update all tools automatically에서 설정할 수 있다. 인스턴스별 업데이트 정책도 확인한다.

Toolbox만 올렸다고 모든 IDE의 JBR와 JCEF가 수정되는 것은 아니다. 반면 수정 Toolbox나 IDE를 설치·업데이트한 뒤 실행하면, 포함된 최신 jetbrainsd가 이전 것을 교체한다. 사용자당 하나의 jetbrainsd가 동작하는 구조이므로 이 서비스의 갱신은 다른 JetBrains 앱에도 적용된다. 그렇더라도 각 IDE의 번들 런타임 점검은 별개로 남는다.

독립 설치한 IntelliJ IDEA의 공식 업데이트 확인 경로는 Windows/Linux에서 Help | Check for Updates, macOS에서 IntelliJ IDEA | Check for Updates다. 다른 제품은 해당 제품의 공식 업데이트 안내를 확인하자. 외부망 접근이 불가능하면 공식 새 설치파일을 받아 사내 승인 절차에 맞춰 배포·설치해야 한다.

패키지 관리자로 설치했다면 해당 설치 채널에서 갱신한 뒤 실제 패치 버전을 확인하자. 공식 IntelliJ IDEA snap 수동 갱신 명령은 다음과 같다.

sudo snap refresh intellij-idea

다른 제품은 각 제품의 공식 설치 문서에서 패키지명을 확인하자.

JCEF는 버전과 네트워크 조건을 함께 봐야 한다. 2025.3 이상 수정 버전에서는 IDE 시작 후 Google 업데이트 서버에서 인증서 차단 갱신을 받는다. 해당 서버 접근이 막혀 있으면 내장 브라우저가 보호되지 않으므로, 수정 버전이라도 JCEF를 꺼야 한다. 사내 프록시·방화벽 환경에서는 IDE 설치 성공과 인증서 차단 갱신 성공을 같은 것으로 취급하면 안 된다.

끄는 순서는 Search Everywhere → Actions → Registry → ide.browser.jcef.enabled 끄기 → 재시작이다. 2025.2 계열의 별도 핫픽스 대기 중이거나 Google 업데이트 서버에 접근할 수 없는 환경에서 적용한다.

내장 브라우저를 끄면 Markdown·HTML 미리보기와 Jupyter 노트북 출력 등 관련 기능에 영향이 생길 수 있고, 일부 플러그인도 정상 동작하지 않을 수 있다. 다시 켜는 기준은 단순히 IDE 업데이트를 마쳤는지가 아니다. 해당 라인의 JCEF 핫픽스 반영 여부와 인증서 차단 갱신에 필요한 네트워크 조건을 확인한 뒤 켜고 재시작해야 한다.

내 설치 버전은 어떻게 확인할까?

Toolbox의 설치 인스턴스 버전이나 업데이트 화면, 설치·배포 기록을 공식 수정 버전 표와 대조하면 된다. 같은 제품을 여러 라인으로 설치했다면 인스턴스마다 확인해야 한다. 다운로드 완료나 업데이트 예약만으로 끝내지 말고, 수정본으로 실행한 뒤 다시 확인하자.

jetbrainsd는 IDE 버전만으로 확인을 대신하지 말자. 공식 IDE 보안 공지에 있는 OS별 설치 경로의 실행파일에 --version을 붙여 실행하고, 0.9.9728 이상인지 확인한다. 경로가 길고 OS별로 다르므로 공지의 해당 항목을 그대로 참고하는 편이 낫다.

프로젝트 JDK와 IDE 실행용 JBR도 별개다. IDE 보안 패치를 설치했다고 프로젝트의 컴파일·실행에 사용하는 JDK까지 바뀐 것은 아니다. Node.js·Python·Go처럼 별도 런타임과 신뢰 저장소를 사용하는 외부 도구도 각 벤더 권고에 따라 따로 확인해야 한다. IDE 업데이트 하나로 개발 환경 전체가 해결된다고 보면 점검이 빠진다.

팀과 회사에서는 무엇을 일괄 점검할까?

개인 PC의 업데이트 여부보다 전체 설치 목록과 예외 조치의 완료 기록을 함께 관리해야 한다. 다음 항목을 점검표로 옮겨 담당자와 확인 결과를 남기자.

• 인벤토리 확인: 로컬 IDE뿐 아니라 원격 개발 환경의 IDE, Gateway, Toolbox, 사용자별 jetbrainsd까지 목록에 넣는다. 자주 쓰지 않는 병행 설치본도 빠뜨리지 않는다.

• 배포 이력 확인: 설치 채널, 제품·라인·패치 버전, 담당자, 완료 여부를 기록한다. 업데이트 뒤 수정본을 실제로 실행하고 버전을 재확인한 결과까지 남긴다.

• JCEF 예외 확인: 2025.2 계열의 비활성화 상태와 별도 핫픽스 일정을 추적한다. 2025.3 이상 수정본도 Google 업데이트 서버 접근을 확인하고, 접근 불가 환경은 JCEF를 꺼 둔다.

• 런타임 확인: 프로젝트 JDK와 별도 런타임은 각 벤더 업데이트 대상으로 분리한다. 개발자 PC의 IDE 목록만 보고 서버와 빌드 에이전트 점검까지 완료 처리하지 않는다.

• 서버·에이전트 확인: 확인 시점에 TeamCity는 수정 진행 중이다. 제품 업데이트만으로 Java가 바뀌지 않을 수 있으므로 모든 서버 노드와 빌드 에이전트의 Java 런타임을 확인하고 필요하면 갱신·재시작해야 한다. TeamCity Cloud의 셀프호스트 에이전트도 고객이 점검해야 한다. 이 상태는 2026년 10월 31일 KST 기준이며 이후 공식 안내를 다시 확인하자.

• 연결 오류 대응: 제거된 루트 인증서에 기대던 정상 서버와 연결이 끊기면 서버 인증서 교체 담당자에게 요청한다. 인증서 검증을 끄거나 신뢰하지 않는 인증서를 자동 수락하는 방식으로 우회하지 않는다.

즉시 업데이트할 수 없는 경우의 수동 cacerts 조치는 공식 IDE 보안 공지를 따른다. 경로나 설정 실수로 보호가 빠질 수 있으므로 여기서는 상세 명령을 옮기지 않는다. JBR 신뢰 저장소 수동 조치가 jetbrainsd에 적용되는 것도 아니며, 서비스는 별도로 수정해야 한다.

업데이트 버튼을 누르면 끝일까?

수정 버전으로 실행하고 JCEF 예외와 jetbrainsd 버전까지 확인해야 이번 IDE 대응을 마쳤다고 볼 수 있다. 개발 도구는 자주 쓰는 만큼 업데이트를 미루기 쉽지만, 이번에는 OS가 대신 해결해 주지 않는 경계가 분명하다.

지금 쓰는 JetBrains IDE와 Toolbox부터 반드시 업데이트하자. 그리고 팀에서는 원격 환경, 프로젝트 JDK, 서버와 빌드 에이전트를 별도 항목으로 남기자. 안심의 기준은 업데이트 알림이 사라졌다는 사실이 아니라, 빠진 구성요소 없이 확인했다는 기록이어야 한다.

공식 출처