2026년 10월 20일, 인도의 인증기관(CA) eMudhra(emSign)의 8개 중간 CA 인증서 개인키가 치명적으로 약한 엔트로피로 생성되어 누구나 수학적으로 개인키를 추출할 수 있는 상태임이 공개되었다. Oracle은 10월 21일 긴급 보안 경고 CVE-2026-91403을 발표했으며, CVSS 3.1 기준 9.1점(Critical)의 심각도를 부여했다.

이 취약점은 Java의 JSSE(Java Secure Socket Extension) 컴포넌트에 영향을 미치며, 침해된 CA 인증서가 JVM의 신뢰 저장소(cacerts)에 포함되어 있어, 패치 없이는 위조된 TLS 인증서를 신뢰하게 된다.

1. 취약점 개요

영향 받는 버전

2. 사건 배경 - eMudhra CA 개인키 침해

2025년 4월 eMudhra의 키 생성 세레모니에서 극도로 낮은 엔트로피로 개인키가 생성되었다. 이로 인해 공개 인증서에서 수 밀리초 만에 개인키를 수학적으로 역산할 수 있게 되었으며, 총 8개 중간 CA의 16개 인증서(직접 발급 8개 + Sectigo AAA 크로스사인 8개)가 영향을 받았다.

침해된 개인키를 보유한 공격자는:

• 임의 도메인에 대한 유효한 TLS 인증서를 위조 가능
• MitM(중간자) 공격으로 HTTPS 통신을 가로채거나 위변조 가능
• 위조된 코드서명 인증서로 악성코드에 정상 서명 가능

3. Java가 특히 취약한 이유

Chrome, Firefox 등 주요 브라우저는 이미 10월 17~20일 사이에 긴급 차단 목록(CRLSets, CRLite, OneCRL)을 배포하여 보호된다. 그러나 Java JVM은 다음 이유로 여전히 취약하다:

즉, JVM에서 HttpClient, HttpsURLConnection, Spring WebClient, OkHttp 등으로 HTTPS 요청 시 기본 신뢰 저장소를 사용하면, 위조된 인증서를 그대로 신뢰하게 된다.

4. 외부 HTTPS 통신이 없는 환경의 안전성 분석

이 취약점의 핵심은 TLS 인증서 검증에 있다. 따라서 다음 조건을 모두 충족하는 환경이라면 직접적인 위험은 낮다:

결론: Java 8 취약 버전을 사용하더라도, 외부로 나가는 HTTPS 통신이 없고 외부 TLS 인증서를 검증하지 않는 환경이라면 이 취약점에 의한 직접적인 위험은 없다. 다만, 향후 기능 추가나 라이브러리 업데이트로 외부 통신이 발생할 수 있으므로 패치 적용을 권장한다.

⚠ 주의사항: 외부 HTTPS 호출이 없다고 단정하기 전에, 로깅 라이브러리(Log4j 등), 모니터링 에이전트, 라이선스 검증, NTP 클라이언트 등 애플리케이션이 간접적으로 HTTPS를 사용하는 경우가 없는지 반드시 확인해야 한다.

5. 진단 방법

5.1 Java 버전 확인

java -version

# 취약 여부 확인
# 8u511 이하, 11.0.33 이하, 17.0.21 이하, 21.0.13 이하 → 취약

5.2 침해 CA 인증서 존재 확인

# JDK 8
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -v | grep -i "emSign"

# JDK 11+
keytool -list -cacerts -storepass changeit -v | grep -i "emSign"

# Comodo AAA (크로스사인 루트)도 확인
keytool -list -cacerts -storepass changeit -v | grep -i "AAA Certificate"

5.3 OpenJDK 공식 검증 프로그램 실행

# OpenJDK에서 제공하는 CheckCerts.java 다운로드 및 실행
# JDK 11+ 필요
curl -O https://cr.openjdk.org/~mr/CheckCerts.java
javac CheckCerts.java
java CheckCerts

결과에 "BAD ROOT"이 포함되면 패치가 필요하다.

5.4 외부 HTTPS 통신 여부 확인

# Java 프로세스의 외부 HTTPS(443) 연결 확인 (Linux)
# 실행 중인 Java 프로세스 PID 확인
pgrep -a java

# 해당 PID의 네트워크 연결 확인
ss -tnp | grep <PID> | grep ":443"

# 또는 netstat 사용
netstat -tnp | grep <PID> | grep ":443"

6. 대응방안

6.1 JDK 패치 적용 (최우선)

Oracle 또는 OpenJDK 벤더에서 배포한 패치 버전으로 업데이트한다. JDK-8395690 수정이 포함된 릴리스를 확인한다.

6.2 즉시 패치 불가 시 - blocked.certs 파일 업데이트

JVM의 blocked.certs 파일에 침해된 48개 SHA-256 해시를 추가하여 해당 인증서를 차단한다. cacerts에서 루트를 삭제하는 것보다 이 방법이 정확하다.

# JDK 11+
BLOCKED="$JAVA_HOME/lib/security/blocked.certs"

# JDK 8
BLOCKED="$JAVA_HOME/jre/lib/security/blocked.certs"

# 백업
cp "$BLOCKED" "$BLOCKED.bak"

# 48개 해시 추가 (침해된 16개 중간CA × 인코딩 변형)
cat << 'EOF' >> "$BLOCKED"

# eMudhra compromised intermediate CAs (2026-10-20 / CVE-2026-91403)
42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
EOF

# JVM 재시작 필요

6.3 cacerts에서 루트 인증서 삭제 (대안)

blocked.certs 방식을 적용할 수 없는 환경에서의 대안이다. 단, emSign 루트만 삭제하면 Sectigo AAA 크로스사인 체인은 여전히 취약하므로 주의.

# JDK 8
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "emsignrootcag1 [jdk]" -storepass changeit
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "emsignrootcag2 [jdk]" -storepass changeit
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "emsigneccrootcag3 [jdk]" -storepass changeit
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "comodoaaaca [jdk]" -storepass changeit

# JDK 11+
keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

# 주의: comodoaaaca 삭제 시 정상적인 Sectigo/Comodo 인증서도 신뢰 불가

6.4 임시 완화 - OCSP/CRL 검증 활성화

# Java 실행 시 JVM 옵션 추가
java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -jar your-application.jar

※ OCSP/CRL 서버 접근이 가능해야 하며, 성능 저하가 발생할 수 있다.

7. 주의사항 - cacerts에서 emSign만 삭제하면 불충분

일부 보안 권고에서 emSign 루트 인증서만 삭제하라고 안내하지만, 이는 불완전한 조치이다.

8. 타임라인

9. 참고자료

• Oracle Security Alert - CVE-2026-91403
• OpenJDK eMudhra 대응 가이드
• eMudhra CA 침해 공개 사이트
• Guillaume Laforge - JVM 취약점 상세 분석 및 blocked.certs 패치 방법
• Red Hat - RHSB-2026-012
• Ubuntu - eMudhra CA compromise fixes

PHP2Shell은 2026년 10월 21일 공개된 PHP의 두 가지 치명적 취약점(CVE-2026-109618, CVE-2026-109619)을 통칭하는 이름이다. 인증 없이 원격 코드 실행(RCE)이 가능하며, CVSS v4.0 기준 9.2점의 최고 수준 위험도를 갖는다. PHP가 전 세계 웹사이트의 약 70%에서 사용되는 만큼 파급력이 극히 크며, 패치 공개 전부터 이미 공격 시도가 관측되었다.

1. 취약점 개요

2. 공격 원리

CVE-2026-109618 (OOM 메모리 손상)

PHP가 메모리 부족(OOM) 상태에서 내부 요청 데이터를 채우는 도중 fatal error가 발생하면, 아직 정리되지 않은 메모리 포인터가 persistent 변수에 남게 된다. 이후 동일 워커가 처리하는 다음 요청이 이 해제된(freed) 메모리를 참조하여 Use-After-Free(UAF) 상태가 되며, 공격자가 제어하는 데이터로 RCE가 가능하다.

CVE-2026-109619 (Stale Global State)

PHP의 Session Upload Progress 기능이 핵심 공격 경로이다. 공격 흐름은 다음과 같다:

1. 공격자가 multipart POST 요청으로 PHP_SESSION_UPLOAD_PROGRESS 필드와 조작된 세션 ID를 전송
2. PHP가 세션 파일을 디스크에 생성하고, 업로드 진행 상황을 직렬화(serialize)하여 저장
3. 세션 파일에 공격자가 제어하는 데이터(세션 ID, 업로드 progress key, 파일명)가 그대로 기록됨
4. 동일 워커의 다음 요청에서 세션을 열면, PHP가 이 파일을 역직렬화(unserialize)하면서 공격자가 삽입한 악성 객체를 로드
5. 이전 요청의 에러로 정리되지 않은 stale 포인터가 남아있어, 해제된 메모리를 재사용하며 RIP 레지스터 제어 → RCE 달성

핵심 포인트: session.upload_progress.enabled가 기본값 On이므로, 별도 설정 변경 없이 기본 PHP 설치 환경이 모두 취약하다. 세션을 사용하지 않는 애플리케이션이라도 영향을 받는다.

3. 공격 현황 (2026년 10월 기준)

• 패치 공개 4일 전부터 Amazon Threat Intelligence가 공격 시도 탐지
• Cloudflare: 공개 10시간 전 수천 건, 45분 내 수만 건, 2시간 내 수백만 건의 공격 시도 관측
• Censys 기준 약 3,440만 대의 취약한 PHP 서비스가 인터넷에 노출
• 10월 24일, Perplexity 보안팀 허니팟에서 Apache mod_php(PHP 8.4.26) 대상 실제 RCE 성공 사례 최초 확인
• 다수의 가짜(Fake) PoC가 GitHub에 유포되어 2차 피해 주의 필요

4. 진단 방법

4.1 PHP 버전 확인

# CLI에서 확인
php -v

# 웹서버 응답 헤더 확인
curl -sI "http://your-server/" | grep -i 'x-powered-by'

# 취약 버전 범위
# PHP 8.2.x < 8.2.35
# PHP 8.3.x < 8.3.36
# PHP 8.4.x < 8.4.27
# PHP 8.5.x < 8.5.12

4.2 Session Upload Progress 활성화 여부

# php.ini 설정 확인
php -i | grep session.upload_progress.enabled

# 기본값이 On이면 취약

4.3 공격 시도 탐지 (IOC)

다음 지표는 공개된 PoC 기반이므로 변형 가능성이 있다:

CISA SIGMA 룰: CISA에서 공식 SIGMA 탐지 규칙을 배포하였으며, GitHub에서 확인 가능하다.
→ CISA SIGMA Rule (GitHub)

4.4 웹 로그 분석

# Apache/Nginx 액세스 로그에서 의심 패턴 검색
grep -iE "php2shell|PHP_SESSION_UPLOAD_PROGRESS|B7kQpoc" /var/log/apache2/access.log
grep -iE "php2shell|PHP_SESSION_UPLOAD_PROGRESS|B7kQpoc" /var/log/nginx/access.log

# multipart POST 요청 중 비정상적으로 큰 응답 확인
awk '$10 > 800000 && $6 ~ /POST/' /var/log/apache2/access.log

5. 대응방안

5.1 긴급 패치 적용 (최우선)

아래 버전으로 즉시 업데이트한다. 인터넷에 노출된 시스템을 최우선으로 처리한다.

# 패치 확인 (Debian/Ubuntu)
apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"

# 패치 확인 (RHEL/CentOS)
rpm -q --changelog php | grep -E "CVE-2026-109618|CVE-2026-109619"

5.2 즉시 패치 불가 시 임시 완화 조치

※ 아래 조치는 패치를 대체하지 않으며, 각각 부분적 완화에 불과하다.

① Session Upload Progress 비활성화 (CVE-2026-109619 세션 경로 차단)

# php.ini 수정
session.upload_progress.enabled = 0

# 워커 재시작 필수
systemctl restart php-fpm
# 또는
systemctl restart apache2

※ 파일 업로드 진행률 표시 기능이 중단됨. INI_PERDIR 설정이므로 ini_set()으로는 변경 불가.

② 메모리 제한 해제 (CVE-2026-109618 OOM 트리거 방지)

# php.ini 수정
memory_limit = -1

※ OOM 공격 경로는 차단하지만, 리소스 고갈 보호가 제거되므로 주의.

③ PHP 8.5 전용 추가 조치

# php.ini 수정
fatal_error_backtraces = 0

④ FPM max_requests 제한 (동일 워커 재사용 방지)

# php-fpm pool 설정
pm.max_requests = 1

※ 성능 저하가 발생하므로 임시 조치로만 사용.

5.3 네트워크 레벨 대응

• WAF 규칙 적용: Cloudflare, Akamai, AWS WAF 등에서 PHP2Shell 관련 긴급 WAF 규칙 배포 중. 즉시 활성화
• 불필요한 PHP 노출 차단: 인터넷에 직접 노출된 PHP 서비스를 최소화하고, 방화벽/리버스 프록시 뒤에 배치
• X-Powered-By 헤더 제거: PHP 버전 정보 노출을 차단 (expose_php = Off)

5.4 사후 점검

• 웹 로그에서 IOC 패턴 검색하여 기존 공격 시도 여부 확인
• 웹쉘 탐지 스캔 수행 (신규 파일 생성, 파일 변경 시점 확인)
• PHP 호스트의 IAM 권한을 최소 권한으로 제한 (웹쉘 획득 시 피해 최소화)
• 로그를 PHP 호스트 외부로 전송하여 공격자의 로그 삭제 방지

6. 타임라인

7. 참고자료

• PHP 공식 보안 권고
• CVE-2026-109618 GitHub Advisory
• CVE-2026-109619 GitHub Advisory
• JFrog - PHP2Shell 기술 분석
• CISA 보안 권고
• Red Hat - RHSB-2026-013

개인정보 처리방침

시행일: 2026년 9월 20일

본 앱(이하 “앱”)은 사용자의 개인정보를 소중하게 생각하며, 개인정보 보호를 위해 노력합니다.

1. 개인정보 수집 및 이용

본 앱은 회원가입을 요구하지 않으며, 사용자를 식별할 수 있는 개인정보를 직접 수집하거나 저장하지 않습니다.

2. 권한 및 이용 목적

본 앱은 삼성 및 LG TV의 원격 제어 기능을 제공하기 위해 필요한 경우 다음 권한을 사용할 수 있습니다.

• 로컬 네트워크 접근: TV 검색 및 연결, 리모컨 명령 전송
• 네트워크 접근: TV 제어 기능 제공

해당 권한은 앱의 기능 제공 목적으로만 사용됩니다.

3. 개인정보의 제3자 제공

본 앱은 사용자의 개인정보를 수집하거나 제3자에게 제공하지 않습니다.

4. 개인정보의 보관 및 파기

본 앱은 개인정보를 별도로 수집하거나 서버에 저장하지 않습니다.

5. 개인정보 보호 관련 문의

개인정보 처리방침에 관한 문의사항은 아래 연락처로 문의해 주시기 바랍니다.

• 이메일: crazyj7@gmail.com

본 개인정보 처리방침은 앱의 기능 및 운영 방식에 따라 변경될 수 있습니다.