Oracle 2026년 10월 취약점 대응: CPU와 Java eMudhra 점검

10월 CPU와 다음 날 Java 경고를 별도 작업으로 기록합니다

Oracle의 2026년 10월 Critical Patch Update(CPU)는 10월 20일 Rev 1으로 공개됐습니다. 공지의 1,295는 여러 제품에 걸친 새 보안 패치 수입니다. 고유 CVE가 1,295개라는 뜻이나, 내가 운영하는 제품에 그 수만큼 취약점이 있다는 뜻으로 읽으면 안 됩니다.

10월 21일에는 Java의 eMudhra 인증서 신뢰와 관련된 CVE-2026-91403 경고가 별도로 나왔고, 연결된 ops.java 대응 지침은 22일 갱신됐습니다. 이 글의 자료 확인일은 23일, 최초 발행일은 24일입니다. CPU 적용 기록과 Java 인증서 대응 기록을 각각 만들어야 한 작업의 완료를 다른 작업의 완료로 오인하지 않습니다.

클라우드 계정 대신 실제 제품과 실행 단위를 목록으로 만듭니다

OCI 가상머신을 사용한다는 사실만으로 Oracle Database나 Oracle JDK가 설치됐다고 볼 수는 없습니다. 반대로 서버의 기본 Java가 새 버전이어도 애플리케이션이 별도 JDK나 이전 컨테이너 이미지를 사용할 수 있습니다. 운영 판단은 계정 이름이 아니라 실제 실행 대상에서 시작합니다.

아래 표는 공지를 대조하기 위한 HLB Studio의 재고 목록 제안입니다. 같은 서비스라도 운영·대기·배치·복구 환경을 나누어 적습니다. 설치 경로만 찾고 실행 중인 프로세스와 연결하지 못했다면 확인 상태로 남겨두세요.

• 명령의 결과는 현재 셸이 선택한 Java입니다. 모든 애플리케이션의 실행 버전을 증명하지는 않습니다.
• 명령이 없다는 결과만으로 다른 경로나 컨테이너 안에도 Java가 없다고 결론내리지 않습니다.
• 확인 기록에는 비밀번호·인증 토큰·개인 키·전체 환경변수 출력을 넣지 않습니다.

java -version

CPU 영향 표의 제품·버전·조건을 한 행씩 대조합니다

공식 위험 매트릭스의 Supported Versions Affected는 영향받는 버전입니다. 수정 버전 목록이 아닙니다. 아래 두 행은 이번 CPU에서 확인한 표본이며 전체 제품 목록이나 모든 공격 경로를 대신하지 않습니다.

예를 들어 Database의 OpenSSL 행과 APEX 행은 제품과 접근 프로토콜이 다릅니다. 점수가 같아도 같은 패치를 적용하는 문제가 아닙니다. 제품명이 맞는지 먼저 확인하고, 버전·구성요소·접근 조건을 순서대로 대조하세요.

• 다른 Oracle 제품에 같은 CVE가 있어도 그 제품의 영향 행을 따로 확인합니다.
• 공식 매트릭스가 제품 내 악용 불가로 분류한 Security-in-Depth 항목을 실제 악용 가능한 항목과 합산하지 않습니다.
• 목록에 없는 오래된 버전을 안전한 버전으로 판정하지 말고 지원 상태와 공급자의 안내를 확인합니다.

수정 버전 하나를 찾기보다 적용할 패치의 근거를 확정합니다

모든 제품을 포괄하는 하나의 “Oracle 보안 버전”은 없습니다. CPU의 제품별 Patch Availability 링크에서 해당 제품의 패치 가용성과 설치 지침을 확인해야 합니다. 지원 문서에 로그인이 필요해 내용을 확인하지 못했다면 패치 번호나 수정 빌드를 추측해 채우지 않습니다.

실행 전 작업표에는 대상 제품·원래 버전·운영체제와 플랫폼·적용할 패치 식별자·근거 문서의 확인일을 연결해 둡니다. 재시작 범위, 선행 패치, 백업과 복구 조건은 실제 패치 README에서 확인한 내용으로 작성합니다. 이 글은 특정 패키지 이름이나 실행 순서를 대신 정하지 않습니다.

일부 인스턴스만 갱신했거나 새 이미지가 준비됐지만 아직 실행되지 않았다면 진행 중입니다. 현재 서비스와 대기 인스턴스, 다음 배포에 쓰일 이미지가 어느 상태인지 각각 표시해야 이전 버전이 다시 투입되는 상황을 찾을 수 있습니다.

• 대상 일치: 제품·플랫폼·원래 패치 수준에 맞는 설치 문서를 확보했는가?
• 변경 준비: 필요한 백업과 복구 경로, 시험 범위, 담당자를 확인했는가?
• 검증 계획: 적용 이력뿐 아니라 실제 실행 버전과 서비스 동작을 확인할 수 있는가?
• 남은 범위: 대기·배치·복구 이미지 중 아직 처리하지 않은 대상을 기록했는가?

Java 경고의 버전 목록은 수정판 목록이 아닙니다

10월 21일의 CVE-2026-91403은 JSSE와 eMudhra 관련 중간 CA 인증서 신뢰를 다루는 별도 경고입니다. 공식 점수는 CVSS 3.1 9.1이며, 인증 없는 네트워크 접근 가능성이 표시돼 있습니다. 이를 Database CPU의 실행 코드 문제와 같은 취약점으로 묶지 않습니다.

다음은 경고가 명시한 영향 버전입니다. 공개 경고는 최신 Java 업데이트 또는 권고된 완화를 안내하지만, 10월 23일 이 글에서 확인한 공개 자료만으로 정확한 수정 빌드 번호를 확정할 수 없었습니다. 아래 숫자를 설치 목표로 복사하지 말고 실제 공급자의 업데이트 안내와 Patch Availability를 확인하세요.

• Oracle이 시험하지 않은 이전 지원 종료 버전도 영향을 받을 수 있습니다. 목록에 없다는 사실만으로 제외하지 않습니다.
• 다른 공급자의 JDK를 사용한다면 공급자와 실제 신뢰 저장소의 대응 안내를 별도로 확인합니다.
• CPU 적용 완료 기록만으로 이 별도 인증서 경고까지 처리됐다고 표시하지 않습니다.

truststore 변경은 백업과 연결 영향 판단부터 시작합니다

10월 22일 갱신된 ops.java 지침은 truststore 백업 후 지정된 두 루트 인증서를 제거하거나 인증서 취소 확인을 활성화하는 대응을 안내합니다. 모든 영향 Java 설치와 애플리케이션의 사용자 정의 truststore에도 확인이 필요합니다. 구체적 선택과 명령은 글 아래의 공식 eMudhra 대응 지침에서 현재 내용을 확인하세요.

운영에서는 먼저 어느 프로세스가 어느 truststore를 읽는지, 정상 외부 연동이 어떤 인증서 체인에 의존하는지 기록합니다. 패키지를 갱신해도 별도 복사한 truststore까지 바뀌었는지 확인하지 못하면 대응 범위가 남습니다. 이 글에는 다른 환경에 그대로 적용할 CA 일괄 삭제 명령을 싣지 않습니다.

변경 전 사본과 식별 가능한 상태 기록을 보존하고 시험 환경에서 정상 TLS 연결을 대조하세요. 취소 확인 방식을 선택한다면 실행 설정뿐 아니라 필요한 네트워크 접근과 실제 검증 결과를 확인해야 합니다. 어느 방식을 선택했는지, 어떤 근거로 운영 반영했는지 남기는 것이 변경 증거입니다.

• 백업: 대상 truststore와 복원 절차를 확인하되 비밀번호를 작업 기록에 남기지 않습니다.
• 범위: 기본 저장소·사용자 정의 저장소·컨테이너 안의 사본을 프로세스와 연결합니다.
• 판단: 공식 지침의 대응 방식과 정상 연동의 영향을 검토한 뒤 적용 범위를 정합니다.
• 검증: 설정 변경 사실과 실제 새 연결에서의 인증서 검증 결과를 따로 남깁니다.

가상 예시로 적용·추가 확인·미완료를 구분해 봅니다

아래는 분류 방법을 보여주기 위한 가상 환경입니다. HLB Studio의 서버 점검 결과나 실제 제품에 패치를 적용한 기록이 아닙니다. 같은 “Oracle 사용”이라는 표현 안에서도 필요한 다음 행동이 다를 수 있습니다.

판정에 필요한 정보가 부족하면 “영향 없음” 대신 확인할 항목과 담당자를 적습니다. 네트워크 접근을 제한했더라도 영향 버전이 바뀐 것은 아니므로 임시 조치와 패치 완료를 구분하세요.

업데이트 뒤에는 새 연결과 실제 업무 흐름을 검증합니다

설치 작업의 성공 메시지와 서비스의 정상 동작은 별도 확인입니다. 변경 후에는 실제 프로세스가 사용할 버전과 구성을 확인하고, 사용 중인 데이터베이스 연결·배치·외부 HTTPS 연동 등 대표 업무를 시험합니다. 특정 제품의 재시작과 검증 절차는 해당 패치 문서를 따릅니다.

Java 인증서 대응에서는 기존 연결이 유지되는 것만 보지 말고 새 TLS 연결도 확인하세요. 사용자 정의 truststore를 쓰는 경로와 기본 저장소를 쓰는 경로를 모두 점검하고, 시험 시각·대상·기대 결과·실제 결과를 남깁니다. 로그에 오류가 없다는 사실만으로 검사하지 않은 모든 경로가 정상이라고 확대하지 않습니다.

인증서 오류가 생기면 TLS 검증을 끄거나 광범위한 인증서를 다시 신뢰하는 방식으로 통과시키지 마세요. 실패한 연동과 체인을 좁혀 변경 영향을 판단합니다. 복구가 필요하더라도 이전 신뢰 상태를 되돌리면 보안 대응도 되돌아갈 수 있으므로, 서비스 복구와 남은 위험의 처리 계획을 함께 기록합니다.

• 실행 확인: 설치 기록과 실제 프로세스의 버전·경로가 일치하는가?
• 업무 확인: 대표 요청, 배치와 연결 의존성이 기대한 결과를 내는가?
• TLS 확인: 새 연결에서 정상 인증서 검증을 유지하는가?
• 복구 판단: 실패 범위·되돌릴 대상·복구 후 남는 위험을 설명할 수 있는가?

완료는 변경 기록과 남은 대상이 함께 보일 때 판단합니다

완료 표에는 “패치함” 한 줄 대신 무엇을 확인했는지 연결합니다. CPU는 적용 대상과 패치 증거, Java 경고는 실행 환경과 선택한 인증서 대응 증거를 각각 남깁니다. 두 작업 중 하나라도 미확인 항목이 있으면 전체 완료로 합치지 않습니다.

이 점검표는 새 공지가 나오거나 제품·이미지·truststore 구성이 바뀌면 다시 확인하는 기준입니다. 특히 공개 자료에서 확정하지 못한 수정 빌드, 아직 로그인해 확인하지 않은 지원 문서, 처리하지 않은 인스턴스는 담당자와 다음 확인일을 지정해 남겨두세요.