月光愛靑狼

1. 개요

• 국제예술대학교는 서울에 소재한 예술 분야 전문 대학으로, 홈페이지 회원 서비스를 운영하고 있습니다. 
• 2026년 10월 20일, 카페24로부터 해커에 의한 홈페이지 공격으로 회원 개인정보 일부가 유출된 정황을 확인했다고 밝혔습니다.
• 사고 인지일: 2026년 10월 20일최초 통보일: 2026년 10월 16일, 카페24가 개인정보로 추정되는 파일의 유출 가능성을 통보
• 공식 통지일: 2026년 10월 21일
• 사고 유형: 홈페이지 해킹 및 웹셸 설치 정황에 따른 개인정보 유출

2. 피해범위

• 피해 대상은 국제예술대학교 홈페이지 가입 회원으로 확인됩니다. 
• 다만 유출된 회원 수, 계정 수, 파일 수 등 구체적인 피해 규모는 공식 통지문에 명시되지 않았습니다.

 - 확인된 내용

• 피해 대상: 국제예술대학교 홈페이지 가입 회원
• 유출 인원·건수: 확인되지 않음
• 유출 시점: 확인되지 않음
• 유출 경로: 카페24 호스팅 환경의 홈페이지 공격 정황

3. 유출항목

 - 대학은 유출된 개인정보 항목을 다음과 같이 안내했습니다.

• 성명
• 연락처
• 홈페이지 가입 ID(이메일)
• 비밀번호
• 주소

 - 비밀번호는 원문이 아닌 암호화된 데이터가 유출된 것으로 대학이 설명했습니다.

• 다만 동일한 계정 정보를 타 서비스에서 사용하는 경우 비밀번호 변경을 권고했습니다.

4. 원인

• 대학 공지에 따르면 카페24로부터 해커에 의한 홈페이지 공격 통보를 받았고, 서버에서 웹셸로 추정되는 악성 파일이 확인·제거되었습니다.
• 침입 경로: 홈페이지 파일 업로드 기능이 악용될 수 있는 취약점으로 추정되나, 대학은 “침입에 악용될 수 있는 홈페이지 기능”이라고만 표현했습니다.
• 정확한 초기 침투 방식, 공격자, 공격 시점: 확인되지 않음
• 카페24 인프라 자체의 책임 범위: 확인되지 않음

5. 대응

 - 대학은 사고 인지 후 홈페이지 서비스를 중단하고 다음 조치를 시행했다고 밝혔습니다.

• 서버 내 웹셸 등 악성 파일 점검 및 제거
• 파일 업로드 검증 강화 등 홈페이지 취약점 보완
• 서버·데이터베이스·관리자 계정 등 운영 접속정보 및 관련 계정 비밀번호 변경
• 한국인터넷진흥원(KISA)과 개인정보보호위원회 신고 및 조사 협조
• 비밀번호 암호화 방식 개선 등 추가 보안 조치
• 피싱·파밍·스미싱 주의 안내 및 112·1394 신고 채널 안내
• 개인정보유출사고 비상대책 TF 운영 및 문의 창구 제공

6. 문제점

 - 공개된 공식 내용만으로 확인되는 문제점은 다음과 같습니다.

• 피해 규모 미공개: 유출 회원 수, 계정 수, 유출 파일 규모가 공지되지 않았습니다.
• 유출 시점·침해 경위 미확인: 최초 통보는 10월 16일이지만 실제 유출 발생 시점과 침투 경로는 아직 확인되지 않았습니다.
• 웹셸 존재 확인: 서버에 웹셸로 추정되는 악성 파일이 남아 있었던 것으로 공지되어, 홈페이지 파일 업로드 및 서버 보안 통제가 충분하지 않았을 가능성을 시사합니다. 다만 구체적 취약점은 공개되지 않았습니다.
• 비밀번호 재사용 위험: 암호화된 비밀번호라도 동일한 ID·비밀번호를 타 서비스에 사용하는 이용자에게는 2차 피해 위험이 있어, 대학도 비밀번호 변경을 권고했습니다.

자세한 내용은 아래 교보문고 홈페이지를 참고바랍니다.

IT서비스 관리실무

1. 개요

• 한국국제교류재단(KF)은 대한민국의 국제 교류·문화외교·공공외교 사업을 수행하는 외교부 산하 재단입니다.
• 재단은 2026년 10월 19일 사이버 보안 점검 과정에서 메일시스템 침해 정황을 확인했으며, 해당 서버를 차단한 뒤 10월 22일 개인정보보호위원회에 신고하고 등록된 메일 대상자에게 통지했습니다.
• 침해 정황이 발견된 서버는 홍보메일 수신자 정보를 저장한 서버였습니다.

2. 피해범위

• 침해 정황이 발견된 서버에는 홍보메일 수신용 이메일 주소 약 22만 7,000건이 등록되어 있었습니다.
• 그중 상당수에 대해 홍보메일 구독자 성명 약 18만 7,000건과 전화번호 약 5,400건이 함께 저장된 것으로 확인됐습니다.
• 다만 실제 침해 범위와 규모, 침해 경로는 관계기관 협조 아래 정밀 조사 중이므로, 위 수치는 “서버에 저장된 정보 규모”이지 확인된 유출 건수는 아닙니다.
• 2026년 10월 22일 기준으로 확인된 다른 피해 규모 수치는 없습니다.

3. 유출항목

• 서버에 저장된 항목은 홍보메일 수신용 이메일 주소, 홍보메일 구독자 성명, 전화번호입니다.
• 이메일 주소 약 22만 7,000건, 성명 약 18만 7,000건, 전화번호 약 5,400건이 해당 서버에 저장돼 있었습니다.
• 실제로 외부로 유출된 항목과 범위는 확인되지 않았습니다.

4. 원인

• 침해 경로, 공격 방식, 공격자, 침해 시점 등 구체적 원인은 현재 확인되지 않았습니다.
• 재단은 사이버 보안 점검 과정에서 침해 정황을 발견했다고만 밝혔으며, 원인 규명은 관계기관과의 협력 아래 진행 중입니다.

5. 대응

• 재단은 10월 19일 침해 정황 확인 후 즉시 해당 서버를 차단했습니다.
• 10월 22일 관련 법령에 따라 개인정보보호위원회에 신고하고, 등록된 메일 대상자에게 통지하는 등 필요한 조치를 취했습니다.
• 재단은 관계기관과 협력해 조사를 실시하고, 재단 시스템 전반을 점검하며 사이버 보안 체계를 강화하겠다고 밝혔습니다.
• 별도 공지에서는 이메일 발송이 불가능한 상황을 안내하고, 신규 가입자는 이메일로 신청서를 제출하도록, 기존 가입자는 휴대폰 본인인증 기반 비밀번호 찾기를 이용하도록 안내했습니다.

6. 문제점

• 현재 확인된 자료만으로는 침해 경로와 실제 유출 여부가 밝혀지지 않았으며, 원인 규명이 진행 중입니다.
• 이메일 주소 약 22만 7,000건과 함께 성명·전화번호가 저장된 상태였다는 점에서, 유출이 확정될 경우 스푸핑·피싱 등 2차 피해 가능성이 제기될 수 있습니다. 다만 이는 확인된 피해가 아니라 일반적 위험 요소입니다.
• 재단은 2026년 10월 12일 이미 임직원 사칭 이메일 주의 및 24시간 대응 센터 안내를 공지한 바 있으나, 이 공지와 10월 19일 확인된 메일시스템 침해 정황 사이의 직접적 연관성은 확인되지 않았습니다.
• 피해 통지 대상, 유출 정보의 구체적 조합, 침해 지속 기간, 보안 통제 실패 원인 등은 아직 공개되지 않았습니다.

1. 개요

• 부산고등법원은 부산·울산·경남 지역을 관할하는 고등법원입니다. 
• 동 법원 홈페이지의 「우리 법원 주요판결」에 게시된 2007~2014년 판결문 일부에서 비실명화가 불완전하게 이루어진 사실이 확인되었습니다.
• 공지 작성일: 2026년 10월 21일
• 유출 판결문 게시 시기: 2007년부터 2014년 사이
• 유출 경로: 부산고등법원 홈페이지에 공개된 판결문 파일
• 해킹 여부: 확인되지 않음

2. 피해범위

 - 유출이 확인된 판결문은 총 11건이며, 해당 문서들에서 총 12명의 성명과 계좌번호 2건이 노출되었습니다.

  > 확인된 내용

• 유출: 판결문 11건
• 노출: 성명 12명
• 노출: 계좌번호 2건
• 정보주체별 연락 가능 여부: 연락처를 알 수 없어 홈페이지 공지로 대체

  > 다만 개인정보보호법상 통지 기준에 해당하는지, 12명이 모두 서로 다른 정보주체인지 등은 공개된 내용만으로 확인되지 않습니다.

3. 유출항목

 - 노출된 개인정보는 다음과 같습니다.

• 성명 12건
• 계좌번호 2건

 - 부산고등법원은 성명과 계좌번호 외 다른 개인정보는 노출되지 않았다고 밝혔습니다.

• 노출 위치는 일부 판결문의 판결이유 및 별지이며, 판결요지·판결이유·별지 등에서 확인되었다는 내용도 함께 제시되었습니다.

4. 원인

• 법원은 판결문을 홈페이지에 게시하기 전 비실명화 처리를 수행했으나, 일부 판결문의 판결이유와 별지에서 성명·계좌번호가 그대로 남았다고 설명했습니다. 
• 즉, 확인된 직접 원인은 판결문 비실명화 처리의 불완전성입니다.
• 외부 해킹에 의한 유출 여부: 확인되지 않음
• 담당자 실수, 처리 절차·검수 체계의 구체적 결함: 확인되지 않음

5. 대응

 - 부산고등법원은 유출 사실을 확인한 즉시 해당 판결문을 홈페이지에서 삭제했습니다. 

  > 정보주체 연락처를 알 수 없어 개인정보보호법 제34조 제1항 단서 및 같은 법 시행령 제39조 제3항에 근거해 홈페이지에 유출 사실을 공지했습니다.

• 유출 판결문 삭제
• 홈페이지 공지 및 사과
• 명의도용·보이스피싱 등 2차 피해 주의 당부
• 금융기관·공공기관 사칭 문자·전화에 응하지 말 것, 출처 불명 링크·첨부파일 클릭 금지 안내
• 문의 창구: 부산고등법원 총무과, 051-590-1098
• 개인정보침해 신고센터(118), 개인정보분쟁조정위원회(1833-6972), 경찰청 사이버범죄 신고시스템(182) 안내
• 피해 발생 시 개인정보보호법상 손해배상·법정손해배상 청구 및 분쟁조정 신청 가능 안내

6. 문제점

• 확인된 사실을 기준으로 보면, 판결문 공개 전 비실명화 작업이 일부 문서에서 완전히 이루어지지 않았다는 점이 핵심 문제입니다. 
• 특히 판결이유와 별지처럼 본문 외 부분에 개인정보가 남을 수 있다는 점에서, 게시 전 검수가 충분하지 않았을 가능성을 시사하지만 구체적 검수 절차의 결함은 공개되지 않았습니다.
• 유출 판결문이 2007~2014년 게시분으로, 장기간 홈페이지에 공개된 상태였을 가능성이 있으나 실제 게시·노출 기간은 확인되지 않음
• 정보주체에게 직접 통지하지 못하고 홈페이지 공지로 대체한 점
• 계좌번호 노출에 따른 금융 사기·명의도용 등 2차 피해 우려가 제기된 점
• 재발 방지를 위한 구체적 기술적·절차적 조치 내용은 확인되지 않음
• 법원 전체적으로는 2026년 9월까지 개인정보 유출이 14건으로 전년 대비 크게 증가했고, 상당수가 내부 실수·시스템 오류와 관련된 것으로 집계되어 판결문 비실명화 품질관리 문제가 반복적으로 제기될 수 있는 배경입니다.

1. 개요

• 놀유니버스는 여행·여가 플랫폼 ‘놀(NOL)’을 운영하는 기업입니다.
• 2026년 10월 19일 오전 2시 40분경 외부 공격자가 시스템 보안 취약점을 이용해 일부 임직원 정보 조회 기능에 비정상적으로 침투했고, 놀유니버스는 같은 날 개인정보 유출 사실을 인지했습니다.

2. 피해범위

• 놀유니버스가 공식적으로 밝힌 피해 대상은 이용자 2명, 일부 임직원, 협력사 관계자입니다.
• 임직원 피해 명단에는 2018년 퇴사한 인원의 정보도 포함된 것으로 확인됐습니다.
• 정확한 총 피해 인원 수, 임직원·협력사 관계자별 인원 수, 이용자 2명의 구체적 피해 내용은 공개되지 않았으며, 회사는 유출 범위와 영향에 대한 추가 조사를 진행 중이라고 밝혔습니다.

3. 유출항목

• 공식 안내에 명시된 유출 항목은 이름, 전화번호, 회사 이메일, 사번입니다.
• 주민등록번호, 결제정보, 비밀번호 등의 유출 여부는 언급되지 않았습니다.

4. 원인

• 외부 공격자가 시스템 보안 취약점을 이용해 일부 임직원 정보 조회 기능에 비정상적으로 침투한 것으로 파악됐습니다.
• 놀유니버스는 해당 사고를 “시스템을 대상으로 한 외부의 비정상적인 접근”에 따른 개인정보 유출로 설명했습니다.
• 구체적인 취약점 유형, 초기 침투 수단, 공격자 정보는 공개되지 않았습니다.

5. 대응

• 놀유니버스는 사고 인지 직후 공격에 이용된 접근 경로를 차단하고 보안 취약점을 조치했습니다.
• 피해자에게 유출 사실과 대처 방법 등을 안내했으며, 한국인터넷진흥원(KISA) 등 유관기관 신고를 완료했습니다.
• 비정상 접근을 실시간으로 감지·차단하는 탐지 체계를 강화하고, 추가 피해 여부를 상시 점검하고 있다고 밝혔습니다.
• 이용자에게는 출처가 불분명한 링크 접속, 인증정보 입력, 의심스러운 이메일·문자·전화에 대한 주의를 당부했습니다.

6. 문제점

• 퇴사한 지 8년이 넘은 2018년 퇴직자 정보가 시스템에 남아 있었다가 유출된 점이 지적됐습니다. 
• 해당 내용은 개인정보 및 퇴직자 서류의 보존기한 경과 후 관리 문제와 연결될 수 있습니다.
• 이용자 2명 외 임직원·협력사 관계자의 정확한 피해 인원과 유출 정보의 실제 악용 여부가 아직 공개되지 않아, 피해 범위 파악이 완료되지 않은 상태입니다.
• 공개된 자료만으로는 취약점의 세부 원인과 재발 방지 대책의 구체적 내용이 확인되지 않습니다.

1. 개요

• 연세 포털서비스는 연세대학교 구성원이 이용하는 대학 포털 서비스입니다.
• 외부 세력이 연세 포털서비스에 비인가 접근해 일부 구성원의 개인정보를 유출한 사고입니다.
• 사고는 2026년 10월 20일 오후 7시 41분~43분과 10월 21일 오전 10시 4분~11분, 두 차례 발생했습니다.
• 연세대는 10월 22일 홈페이지 공지와 학내 구성원 대상 문자 안내를 통해 사실을 알렸습니다.

2. 피해범위

• 피해 대상: 재학생, 졸업생, 교직원 등 학내 구성원
• 피해 규모: 약 1만여 명
• KISA 신고 기준: 약 1만5,000여 명(또는 건)

3. 유출항목

• 학번
• 직원번호(일부 자료에서는 “직번”으로 표기)
• 성명
• 휴대전화번호
• 이메일 주소
• 일부 시스템 관리 정보

 - 개인별로 유출된 항목은 서로 다른 것으로 안내되었습니다.

• 주민등록번호 등 고유 식별정보와 민감정보는 유출되지 않은 것으로 연세대가 설명했습니다.

4. 원인

• 연세대는 연세 포털서비스에 대한 외부의 비인가 접근이 원인이라고 공지했습니다.
• 구체적인 침해 경로, 공격자, 공격 기법, 취약점은 현재 확인된 자료에서 공개되지 않았습니다.

5. 대응

• 해킹 확인 직후 유출 경로를 차단했습니다.
• 한국인터넷진흥원(KISA)에 유출 사실을 신고했습니다.
• 수사기관에 수사를 의뢰했습니다. 다만 한 자료는 “자료 취합해 수사 의뢰”라고 표현해, 수사 의뢰 절차가 진행 중이었음을 시사합니다.
• 추가 보안 점검을 실시했습니다.
• 유출 가능성이 있는 정보주체에게 사고 사실과 유출 항목을 개별 안내하고 있습니다.

6. 문제점

• 포털서비스에 외부 비인가 접근이 적어도 두 차례 발생했으며, 두 번째 접근은 첫 번째 발생 다음 날에도 이어졌습니다.
• 외부 접근이 발생한 정확한 침해 경로와 근본 원인은 아직 공개되지 않았습니다. 
• 초기 공지에서는 “1만여 명”으로 안내된 반면, KISA 신고 내용은 “1만5,000여 건”으로 확인되어 피해 규모 산정의 정확한 기준과 범위가 추가로 명확히 공개될 필요가 있습니다.
• 유출된 “일부 시스템 관리 정보”의 구체적 항목과 악용 가능성에 대한 설명은 현재 확인된 자료에서 제시되지 않았습니다. 

◎ 들어가기전에

• 2026년 10월, PHP 생태계 전반을 뒤흔든 PHP2Shell 사태가 발생했습니다.
• 이는 단일 취약점이 아니라 PHP 코어 엔진의 메모리 안전성 결함을 묶어 부른 이름으로, CVE-2026-109618과 CVE-2026-109619 두 개의 치명적 취약점을 가리킵니다.
• 인증 없이 원격 코드 실행(RCE)과 프로세스 메모리 유출이 가능할 수 있어, WordPress·Drupal·Joomla처럼 PHP 기반으로 운영되는 수많은 웹 서비스에 즉각적인 패치가 요구됐습니다.
• 특히 이번 사건은 원래 10월 22일 책임 있는 공개(responsible disclosure)를 예정하고 있었지만, 10월 20일 취약점 정보와 PoC 관련 자료가 온라인에 유출되면서 PHP 프로젝트가 하루 앞당겨 긴급 패치를 배포한 점에서 주목할 만합니다.

◎ 배경 및 개요

• PHP는 WordPress, Drupal, Joomla, MediaWiki, Laravel 등 수많은 웹 애플리케이션의 기반이 되는 서버 사이드 언어입니다. 
• Wiz Research는 PHP가 전 세계 웹사이트의 약 70%를 구동한다고 설명하며, 이번 결함이 애플리케이션 계층이 아니라 PHP 엔진 자체에 있기 때문에 영향 범위가 매우 넓다고 지적했습니다.

 - PHP2Shell은 두 개의 CVE로 구성됩니다.

• 두 취약점 모두 PHP가 웹 요청을 처리하는 과정에서 발생하는 메모리 안전성 문제, 특히 out-of-memory(OOM) 오류 이후 요청 관련 상태가 제대로 정리되지 않는 구조에서 출발합니다.

◎ 주요 변경 사항

 - PHP 프로젝트는 2026년 10월 21일 다음 버전을 긴급 배포했습니다.

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

 - 다만 PHP 8.1 이하는 이미 지원 종료(EOL) 상태이므로 공식 바이너리 패치는 제공되지 않습니다.

• 대신 PHP는 PHP 7.4, 8.0, 8.1을 위한 최소한의 소스 코드 백포트를 공개해, 직접 빌드하거나 LTS 벤더 패키지를 활용할 수 있도록 했습니다.
• 중요한 점은 배포판에 따라 업스트림 PHP 버전 번호를 그대로 유지한 채 보안 수정 사항을 백포트할 수 있다는 것입니다.
• 따라서 php -v 출력만으로 패치 여부를 판단하기보다, 사용 중인 Linux 배포판의 보안 공지와 패키지 변경 이력을 확인해야 합니다.

◎ 상세 기능 설명

 - CVE-2026-109618: 업로드 진행 상태와 OOM 손상

• 이 취약점은 PHP의 세션 모듈이 multipart/form-data 업로드 진행 상태를 처리하는 초기 요청 단계와 관련이 있습니다. 
• 공격자는 메모리 할당 실패를 유도해 요청 처리 도중 비정상 종료를 발생시키고, 그 과정에서 남는 비정상 상태를 이용해 이후 요청에서 메모리를 재활용하거나 손상시킬 수 있습니다.
• Wiz Research는 이 경로를 이용해 WordPress, Drupal, Joomla의 최신 컨테이너 이미지에서 인증 없는 RCE를 재현했다고 밝혔습니다.
• 또한 RCE에 도달하지 않더라도 PHP 워커 프로세스의 메모리에 있는 비밀번호, 인증 토큰, API 키, 인증서 등 민감 정보를 읽을 수 있는 메모리 유출 가능성도 시연했습니다.

 - CVE-2026-109619: 워커 재사용과 잔존 전역 상태

• PHP-FPM이나 Apache의 mod_php처럼 PHP 워커는 하나의 요청을 처리한 뒤 종료되지 않고 다음 요청을 위해 재사용되는 경우가 많습니다. 
• 문제는 치명적 오류가 발생했을 때 일부 전역 상태가 이전 요청의 메모리를 계속 가리킬 수 있다는 점입니다. 
• 이후 같은 워커가 새 요청을 받으면, 정상적인 초기화가 끝나기 전에 그 잘못된 포인터를 참조할 수 있습니다.
• 이를 정교하게 조작하면 공격자는 메모리 레이아웃을 제어해 임의 코드 실행으로 연결할 수 있습니다.
• GuidePoint Security는 이 경로가 일반적으로 두 개의 HTTP 요청, 즉 첫 번째 요청으로 잔존 상태를 만들고 두 번째 요청으로 이를 활용하는 방식으로 작동한다고 설명합니다.

 - 왜 애플리케이션 방어가 무력한가

• 이번 취약점의 가장 큰 특징은 공격이 PHP가 multipart/form-data 요청 본문을 파싱하는 단계, 즉 애플리케이션 코드가 실행되기 전에 발생할 수 있다는 점입니다. 
• 따라서 CMS 관리자 화면 보호, 보안 플러그인, 로그인 요구, 업로드 기능 비활성화만으로는 근본적인 방어가 되지 않습니다.
• Wiz는 “Hello World” 수준의 단순 PHP 애플리케이션도 취약 버전에서는 영향을 받을 수 있다고 설명합니다.
• 즉, WordPress 플러그인이나 테마의 취약점이 아니라 PHP 런타임 자체의 문제이기 때문에, 애플리케이션 코드가 안전하더라도 PHP 버전이 취약하면 서버가 위험에 노출될 수 있습니다.

◎ 기획 의도 및 기술적 개선

• PHP2Shell은 단순히 새로운 취약점 하나가 공개된 사건을 넘어, AI가 오래된 복잡한 취약점을 실제 공격 도구로 바꾸는 속도를 보여준 사례로 평가됩니다. 
• Wiz Research에 따르면 해당 결함의 뿌리는 10년 이상 전 PHP 코드베이스에 존재했지만, 이를 실제 RCE로 연결하려면 여러 결함을 연쇄하고 대상별 메모리 배치에 맞춰 반복적으로 조정해야 했습니다.
• 과거에는 이런 작업이 소수의 고도화된 연구자만 수행할 수 있는 영역이었습니다.
• 그러나 프론티어 AI 모델과 자동화된 테스트·디버깅 환경을 결합하면, 서로 다른 PHP 버전·설정·애플리케이션 환경에 맞춰 익스플로잇을 적응시키는 과정이 크게 단축될 수 있습니다.
• Wiz는 이번 연구에서 Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol을 활용했다고 밝혔습니다.
• 이는 방어자에게도 기회입니다.
• AI는 공격자가 취약점을 무기화하는 시간을 줄이는 동시에, 보안 연구자가 오래된 코드베이스의 숨은 결함을 찾고 패치를 검증하는 데에도 활용될 수 있습니다.
• 실제로 이번 사례에서는 Wiz, Calif, OpenAI, PHP 팀이 협업해 취약점 발견, 조율, 패치 검증을 진행했습니다.

◎ 사용방법 및 가이드

1단계: 영향 대상 확인

• 먼저 웹 서버, 컨테이너, 호스팅 환경에서 실행 중인 PHP 버전과 실행 방식을 확인합니다. 
• PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 모든 PHP 실행 환경이 관련 대상입니다.

php -v
php-fpm -v

• 컨테이너 환경에서는 실행 중인 이미지와 컨테이너를 점검합니다.

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec  php -v

• 단, 배포판이 백포트한 경우 버전 문자열만으로는 부족하므로 패키지 변경 이력도 함께 확인해야 합니다.

# Debian/Ubuntu 계열 예시
apt-cache policy php8.2-fpm

# RHEL 계열 예시
dnf info php

2단계: 우선순위에 따른 패치

• 인터넷에 직접 노출된 PHP 서버를 최우선으로 패치합니다. 
• 지원 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35로 업데이트하는 것이 원칙입니다.
• Debian/Ubuntu 계열에서는 일반적으로 다음과 같이 진행할 수 있습니다.

sudo apt update
sudo apt upgrade php8.2-fpm php8.2-common

• RHEL 계열에서는 배포판 또는 벤더가 제공하는 보안 업데이트를 적용합니다.

sudo dnf update php

• 패치 후에는 단순히 바이너리를 교체하는 것으로 끝나지 않습니다. 
• 기존 PHP-FPM 워커, Apache 프로세스, 큐 워커, 스케줄러 등 장기 실행 프로세스는 여전히 이전 바이너리를 사용할 수 있으므로 재시작해야 합니다.

sudo systemctl restart php8.2-fpm
sudo systemctl restart apache2

• 컨테이너를 사용하는 경우 호스트 패키지만 올리는 것으로는 부족합니다. 
• 패치된 PHP가 포함된 이미지를 다시 빌드하고, 실행 중인 모든 컨테이너를 재배포해야 합니다.

docker compose build
docker compose up -d

3단계: 즉시 패치가 어려운 경우의 임시 완화

• PHP 프로젝트의 공식 입장은 업데이트만이 완전한 해결책이라는 점입니다. 

 - 다만 당장 패치가 어려운 환경에서는 노출을 줄이기 위한 임시 조치를 적용할 수 있습니다.

• 웹 서버 단계에서 Content-Type: multipart/form-data 요청을 차단합니다.
• 이 조치는 파일 업로드 기능을 중단시키므로 업무 영향을 반드시 검토해야 합니다.
• CVE-2026-109618 완화를 위해 memory_limit=-1을 설정해 애플리케이션이 조작 가능한 PHP 메모리 한도 실패를 유발하지 않도록 합니다.
• 업로드가 필요 없다면 post_max_size=8M, 필요하다면 32M 수준으로 낮추고, upload_max_filesize는 post_max_size보다 작게 유지합니다.
• CVE-2026-109619 완화를 위해 session.upload_progress.enabled=0을 설정하고 모든 PHP 워커를 재시작합니다.
• PHP 8.5 환경에서는 fatal_error_backtraces=0 설정으로 확인된 치명 오류 백트레이스 경로를 차단할 수 있습니다.

 - 여기서 주의할 점은 ini_set()이나 FPM의 .user.ini 설정에 의존하지 말라는 것입니다.

  > 완화 설정은 요청 파싱이 시작되기 전에 적용되어야 하므로, php.ini, FPM 풀 설정 또는 웹 서버 설정 수준에서 적용하는 것이 안전합니다.

◎ 기대효과 및 주의사항

• 패치를 적용하면 PHP 코어의 확인된 메모리 손상 경로가 제거되어, 인증 없는 RCE 및 메모리 유출 위험을 크게 낮출 수 있습니다. 
• 다만 패치는 앞으로의 공격을 막는 조치일 뿐, 유출 시점 이전에 이미 침해가 발생했을 가능성을 배제하지는 않습니다.

 - 따라서 패치 이후에는 다음 항목을 중심으로 역방향 조사를 권장합니다.

• PHP-FPM 또는 Apache 워커 프로세스가 셸, wget, curl 등을 비정상적으로 실행했는지 확인
• PHP-FPM 및 웹 서버 로그에서 설명되지 않는 세그먼테이션 오류나 워커 비정상 종료 점검
• 2026년 10월 20일 15:00 UTC 이후의 비정상 multipart/form-data 요청 조사
• 웹 루트, 업로드 디렉터리, 플러그인 디렉터리의 신규 또는 변경된 파일 점검
• .user.ini, auto_prepend_file 설정 변경 여부 확인
• 새로운 cron 작업, systemd 유닛, Supervisor 항목, SSH authorized_keys 추가, 비정상 아웃바운드 연결 등 지속성 지표 점검

 - 특히 로그는 패치나 컨테이너 재배포 전에 백업해야 합니다.

• 로그 로테이션, 재배포, 이미지 재빌드는 침해 조사에 필요한 포렌식 증거를 삭제할 수 있습니다.

◎ 조기 유출이 만든 비상 대응

• 이번 사태의 비하인드는 취약점 자체만큼이나 공개 절차의 붕괴에 있습니다. 
• 원래 PHP2Shell 관련 세부 정보와 패치는 10월 22일에 공개될 예정이었습니다. 
• 그러나 10월 20일 Hacker News 게시물, watchTowr Labs의 X 게시물, 그리고 Calif가 실수로 선공개한 PoC 시연 영상 등을 통해 취약점 존재와 익스플로잇 도구 정보가 확산됐습니다.
• 문제는 단순한 정보 유출에 그치지 않았습니다.
• PoC 영상이 공개되면서 여러 연구자와 공격자가 유사한 익스플로잇을 빠르게 개발할 동기와 단서를 얻었고, PHP 측은 패치 배포와 세부 공지 준비가 완료되기 전에 사실상 공개 대응에 들어갈 수밖에 없었습니다.
• SecurityWeek는 이 과정에서 다양한 PoC 개발이 가속됐다고 보도했습니다.
• 결과적으로 PHP는 10월 21일 패치와 보안 권고를 앞당겨 공개했고, 일부 보고에 따르면 패치 공개 전에도 이미 익스플로잇 시도가 관측됐습니다. 이는 “취약점이 알려졌지만 패치가 아직 없는 창(window)”이 얼마나 위험한지를 보여주는 사례입니다.

◎ 마무리

• PHP2Shell은 PHP 코어의 메모리 안전성 결함이 애플리케이션 방어선과 무관하게 전체 웹 인프라에 영향을 줄 수 있음을 보여준 사건입니다. 
• WordPress, Drupal, Joomla를 사용하는 조직이라면 더욱 즉각 대응해야 하지만, 문제의 본질은 특정 CMS가 아니라 PHP 런타임 자체에 있습니다.
• 지금 해야 할 일은 명확합니다.
• 인터넷 노출 PHP 서버를 우선 패치하고, PHP-FPM과 웹 서버를 재시작하며, 컨테이너 이미지를 재빌드해 배포하는 것입니다.
• 즉시 패치가 불가능하다면 multipart 요청 차단과 세션 업로드 진행 기능 비활성화 같은 임시 완화를 적용하되, 이를 영구 대책으로 착각해서는 안 됩니다.
• 또한 이번 사태는 AI 시대의 취약점 관리 방식도 바꾸고 있습니다.
• 오래되고 복잡해 실무적 악용이 어렵다고 여겨졌던 결함도, AI 지원 연구 환경에서는 빠르게 무기화될 수 있습니다.
• 따라서 조직은 단순한 CVE 대응을 넘어, PHP·Python·Node.js 같은 런타임과 컨테이너 베이스 이미지의 패치 주기를 단축하고, 로그 보존과 침해 이력 조사 체계를 함께 갖추는 것이 필요합니다.

◎ PHP 제품 보안 업데이트 권고

https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=72227&menuNo=205020

◎ php2shell Detection Rules

https://github.com/ikow/php2shell-poc/tree/main/detection

◎ K000163821: PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619

https://my.f5.com/manage/s/article/K000163821

1. 개요

• 기장수협은 부산광역시 기장군에 있는 수협 회원조합입니다.
• 2026년 9월 9일경, 조합원명부 발급 과정에서 개인정보가 포함된 자료가 발급되어 유출된 사실이 2026년 9월 30일 공식 공지로 안내되었습니다.

2. 피해범위

• 공지에는 유출된 자료가 “전량 회수”되었다고만 명시되어 있으며, 유출 대상 조합원 수, 발급 부수, 회수 경위 등 구체적인 피해 규모는 확인되지 않습니다.

3. 유출항목
 - 공지에 명시된 유출 항목은 다음과 같습니다.

• 이름
• 생년월일
• 연락처
• 주소

4. 원인

• 공지는 유출 경위를 “조합원명부 발급 과정에서 이름, 생년월일, 연락처, 주소가 포함된 자료가 발급”된 것으로 설명합니다.
• 발급 승인 절차, 담당자 실수 여부, 시스템 권한 관리 문제 등 구체적 원인은 공지에 명시되지 않아 확인되지 않습니다.

5. 대응

• 기장수협은 해당 자료를 전량 회수했다고 밝혔습니다.
• 전화·광고 등 피해가 의심되는 조합원에게 기장수협에 즉시 연락하도록 안내했습니다.
• 피해가 발생했거나 예상되는 경우 담당부서 상담을 받고, 필요한 조사 후 손실보상 등 구제절차를 진행하겠다고 밝혔습니다.
• 전담상담센터 연락처는 051-722-1905입니다.
• 개인정보보호위원회 또는 한국인터넷진흥원 신고 여부, 개별 통지 방식·범위 등은 공지에서 확인되지 않습니다.
• 개인정보 유출 통지·신고는 관련 절차에 따라 이루어져야 합니다.

6. 문제점

• 공지에 유출 인원, 발급 건수, 회수 방법, 유출 자료의 보관·파기 여부가 기재되지 않아 피해 범위와 후속 조치의 실효성을 외부에서 확인하기 어렵습니다.
• 유출 원인이 구체적으로 공개되지 않아 재발 방지 대책도 확인되지 않습니다.
• 개인정보보호위원회·한국인터넷진흥원 신고 및 정보주체 개별 통지 여부가 공지에 명시되지 않아 확인되지 않습니다.

1. 개요

• 코베이옥션은 1999년 설립된 취미·예술품 전문 온라인 경매업체로, 고서적·미술품·골동품·수집품 등을 거래하는 경매 서비스를 운영합니다.
• 회사는 2026년 10월 19일 관리자사이트에 대한 외부 비정상 접근을 확인했고, 조사 과정에서 전체 회원정보 목록이 조회된 사실을 확인했다고 10월 21일 공지했습니다.

2. 피해범위

• 회사는 “전체 회원정보 목록이 조회”됐다고 밝혔지만, 영향받은 회원 수·유출 건수는 공지하지 않았습니다.
• 피해 규모는 현재 확인되지 않음이며, 외부 반출 여부와 추가 피해 가능성도 관계기관 신고 후 조사 중입니다.

3. 유출항목

 - 회사가 공지한 조회·유출 가능 항목은 다음과 같습니다.

• 이름
• 아이디
• 연락처: 집전화, 휴대전화, 직장 연락처
• 이메일

  > 비밀번호, 주소, 결제정보, 거래내역 등은 유출 항목으로 명시되지 않았습니다.

4. 원인

• 회사는 관리자사이트에 대한 외부의 비정상적인 접근을 원인으로 확인했다고 밝혔습니다.
• 다만 공격자 신원, 침해 경로, 관리자 계정 탈취 여부, 특정 취약점 명칭 등은 제시되지 않았습니다.

5. 대응

• 회사는 유출 사실 인지 후 해커가 접속한 IP와 외부 접속을 즉시 차단했다고 밝혔습니다.
• 홈페이지 취약점 점검 및 보완 조치를 실시했다고 공지했습니다.
• 관계기관에 신고해 외부 반출 여부와 추가 피해 가능성을 조사 중이며, 확인되는 대로 추가 안내할 계획입니다.
• 영향 가능성이 있는 회원에게는 이메일과 문자메시지로 개별 안내할 예정입니다.
• 이용자에게는 비밀번호 즉시 변경, 동일 비밀번호 사용 사이트의 비밀번호 변경, 스미싱·피싱 주의, 명의도용 확인을 권고했습니다.
• 고객관리팀(02-738-1268)과 master@kobay.co.kr을 통해 피해 접수 및 문의를 받고 있습니다.

6. 문제점

• 회사는 “전체 회원정보 목록”이 조회됐다고 밝혔지만, 영향 회원 수와 유출 건수를 공개하지 않아 피해 범위를 이용자가 정확히 파악하기 어렵습니다.
• 정보가 외부로 실제 반출됐는지, 추가 피해가 발생할 가능성이 있는지도 조사 중이라고만 안내해 현재로서는 불확실합니다.
• 관리자사이트에 대한 외부 비정상 접근이 확인된 점에서는 관리자 페이지 접근통제와 침해 탐지 체계의 문제 가능성이 제기되지만, 구체적 취약점이나 관리 소홀 여부는 확인되지 않습니다.
• 유출 항목에 연락처와 이메일이 포함된 만큼, 회사도 보이스피싱·스미싱 등 2차 피해 우려를 언급했습니다. 

◎ 들어가기전에

• Windows 11을 새로 설치하거나 OEM PC를 구매하면 사용하지 않는 앱, 제조사 유틸리티, 원격 분석(telemetry), 광고성 콘텐츠가 함께 제공되는 경우가 많습니다. 
• Debloat-Win11은 이런 요소를 PowerShell 기반으로 점검·정리하고, 하드웨어 특성에 맞는 설정과 감사 로그, 되돌리기 정보까지 제공하는 오픈소스 프로젝트입니다.
• 이 글에서는 공식 GitHub 저장소의 최신 README를 기준으로 v2.3.11의 구조, 주요 기능, 실행 방법, 기업 환경에서의 활용법과 주의점을 정리했습니다.

◎ 배경 및 개요

• Debloat-Win11은 SysAdminDoc이 공개한 Windows 10/11용 “debloating” 스크립트입니다. 
• 여기서 debloating은 게임, 소셜 앱, 체험판, OEM 유틸리티, 불필요한 백그라운드 서비스처럼 사용자 환경을 무겁게 만들거나 관리 범위를 넓히는 요소를 정리하는 작업을 뜻합니다.
• 프로젝트는 단순히 앱을 대량 삭제하는 도구가 아니라, 다음과 같은 운영 목표를 전제로 설계되어 있습니다.
• Windows 기본 탑재 앱과 OEM 제조사 앱 정리
• 원격 분석, 광고 ID, 활동 기록, Bing 검색 연동 등 프라이버시 설정 강화
• 데스크톱·노트북, SSD·HDD 등 하드웨어 조건에 따른 성능 최적화
• 변경 전 미리보기, 로그, JSON 기반 되돌리기 매니페스트 제공
• Intune, SCCM, PDQ Deploy 같은 배포 도구에서 활용할 수 있는 종료 코드와 탐지 스크립트 제공
• 현재 README 기준 버전은 v2.3.11이며, 2026년 8월에 마지막으로 업데이트되었습니다.
• 지원 범위는 Windows 10 1903(빌드 18362) 이상과 Windows 11이며, x86·x64·ARM64 아키텍처를 포함합니다.
• 원래 의료 영상 장비용 워크스테이션 환경에서 개발된 배경이 있어, 일반적인 개인 PC 최적화 도구보다 변경 가능성 추적, 승인 절차, 복구 가능성을 중시하는 점이 특징입니다.

◎ 주요 변경 사항

 - v2.3.11의 핵심 변화는 “되돌릴 수 없는 작업”을 기본 실행에서 분리한 점입니다. 

• AppX 패키지 삭제, OEM 앱 정리, Office·OneDrive 제거, 방화벽 규칙 교체, 광범위한 파일·캐시 정리 등은 기본 실행만으로는 수행되지 않고, 명시적으로 -AllowIrreversibleChanges를 지정해야 합니다.

  > 또한 최근 버전에서는 다음과 같은 기능이 강화되었습니다.

• -DryRun으로 실제 변경 없이 예상 작업을 점검
• 실행 결과를 planned, succeeded, failed, skipped로 구분한 JSON 매니페스트 생성
• 변경 실패 시 매니페스트를 불완전 상태로 표시해 감사 신뢰성 확보
• 공용 네트워크에서 네트워크 검색, 파일 공유, LLMNR을 기본적으로 활성화하지 않도록 조정
• Intune 탐지 시 정책·구성 해시, 대상 범위, 지원 런타임, 실패 작업, 레지스트리 스탬프까지 검증
• Windows AI 관련 정책을 Modules/PolicyCatalog.psd1로 통합해 드리프트 탐지와 복구의 일관성 확보
• WIM 오프라인 이미지 모드에서 DISM·이미지·마운트 상태 검증 및 비변경형 -DryRun 지원
• 이벤트 로그 삭제를 기본값이 아닌 명시적 옵트인으로 변경해 SIEM·감사 증거 보존

  > 특히 v2.3.2부터는 ClearEventLogs를 설정하지 않으면 이벤트 로그를 지우지 않도록 바뀌었습니다.

• 침해사고 대응이나 로그 수집 환경에서는 매우 중요한 변화입니다.

◎ 상세 기능 설명

 - 불필요 앱 및 OEM 소프트웨어 정리

• 스크립트는 80개 이상의 AppX 패키지를 대상으로 하며, 사용자 프로필에 등록된 앱과 향후 새 사용자에게 설치될 수 있는 프로비저닝 패키지를 함께 다룹니다. 
• Microsoft의 공식 문서도 기존 사용자에게 설치된 앱과 신규 사용자에게 설치되는 프로비저닝 앱은 제거 방식이 다르다는 점을 설명합니다.
• 대상에는 Cortana, Copilot, Xbox 관련 구성요소, Bing 계열 앱, Clipchamp, Microsoft Teams 개인용 앱, Your Phone, Zune Music/Video 등이 포함됩니다.
• 또한 Dell, HP, Lenovo, ASUS, Acer, MSI, Razer 등 6개 OEM 벤더의 앱과 서비스·예약 작업·폴더·레지스트리 항목까지 정리하는 “OEM Nuclear Cleanup” 단계를 제공합니다.
• 다만 무조건 삭제하지는 않습니다.
• OneDrive는 계정이 로그인되어 있거나 파일이 존재하면 보존되고, Office는 라이선스가 있거나 실행 중인 앱이 있으면 제거를 건너뜁니다.

 - 프라이버시 및 원격 분석 제어

• 프로젝트는 Windows 진단 데이터, 광고 ID, 활동 기록, Cortana·Copilot·Recall, Bing 검색, 자동 앱 설치, 시작 메뉴 광고성 콘텐츠 등을 줄이는 레지스트리 및 정책 구성을 포함합니다.
• Microsoft 역시 기업 환경에서는 그룹 정책 또는 MDM CSP를 통해 System/AllowTelemetry, System/LimitDumpCollection, System/LimitDiagnosticLogCollection 같은 정책으로 진단 데이터 수집을 제어할 수 있다고 안내합니다.
• Debloat-Win11은 이런 관리 방식과 유사한 방향으로 로컬 정책을 구성하지만, 조직에서는 스크립트가 만든 설정과 기존 GPO·Intune 정책이 충돌하지 않는지 반드시 검토해야 합니다.

 - 하드웨어 인식 최적화

• 실행 전에 노트북·데스크톱 여부와 SSD·HDD 여부를 확인합니다. 
• 노트북은 배터리 상태에 따라 절전·화면 꺼짐·최대 절전 모드를 다르게 구성하고, 데스크톱은 고성능 전원 계획을 적용합니다.
• SSD에서는 SysMain(Superfetch), Prefetch, 마지막 액세스 타임스탬프를 비활성화하고 TRIM은 유지합니다.
• HDD에서는 반대로 SysMain과 Prefetch를 활성화합니다. 즉, 모든 장비에 동일한 “성능 향상” 설정을 적용하는 방식이 아닙니다.

 - 보안 및 관리 기능

• 프로젝트는 Windows Defender, Windows Firewall, BitLocker, SmartScreen을 기본 보존 대상으로 명시합니다. 
• Windows Update도 비활성화하는 것이 아니라, 활성 시간과 기능 업데이트·품질 업데이트 지연 기간을 설정하는 방식입니다.

  > 또한 다음과 같은 보안 관련 기능을 제공합니다.

• S Mode 및 Defender 변조 방지(Tamper Protection) 상태 사전 점검
• 도메인 가입 여부, 디스크 여유 공간, 재부팅 대기 상태 점검
• 자동 시스템 복원 지점 생성
• SMB1, PowerShell 2.0, Internet Explorer 선택 구성요소 등 위험도가 높은 레거시 기능 비활성화
• 보안 강화 프리셋 presets/security.psd1 제공
• PSScriptAnalyzer 기반 정적 분석 도구와 Pester 테스트, GitHub Actions CI 구성

◎ 기획 의도 및 기술적 개선

 - 이 프로젝트의 기획 의도는 “가볍게 만드는 것” 자체보다 예측 가능하고 복구 가능한 Windows 엔드포인트 구성에 가깝습니다. 

• README는 문제를 단순한 느린 PC가 아니라, 불필요한 앱·원격 분석·일률적인 전원 설정·감사 기록 부재·되돌리기 불가능성으로 정의합니다.

  > 기술적으로 주목할 부분은 다음과 같습니다.

• 특히 v2.3.x에서는 정책 카탈로그가 단순 설정 목록을 넘어, 각 정책의 위험도·범위·선행 조건·롤백 정보·지원 플랫폼을 함께 갖도록 개선되었습니다.
• 지원되지 않는 작업은 실제 변경 전에 실패 처리되며, -AllowUnsupportedPlatform으로 강제 실행하면 해당 실행은 비준수 상태로 기록됩니다.

◎ 사용방법 및 가이드

 - 사전 준비

  > README 기준 요구 사항은 다음과 같습니다.

• Windows 10 1903 이상 또는 Windows 11
• PowerShell 5.1 이상
• 관리자 권한
• 권장 여유 디스크 공간 5GB
• 네트워크 연결은 필수 아님

  > 개인 PC에서도 가능하면 중요한 문서·브라우저 프로필·암호 저장소를 먼저 백업하고, 시스템 복원 지점이 실제로 생성되었는지 확인한 뒤 진행하는 것이 좋습니다.

• 프로젝트 자체도 변경 전 복원 지점 생성을 안전 기능으로 제공합니다.

1단계: 저장소 내려받기

• GitHub에서 저장소를 내려받거나 ZIP으로 받아 로컬 폴더에 풀어둡니다. 
• 예를 들어 C:\Scripts\Debloat-Win11처럼 관리하기 쉬운 경로를 사용하는 것이 좋습니다.

2단계: 관리자 PowerShell 실행

• 시작 메뉴에서 PowerShell을 검색한 뒤 관리자 권한으로 실행합니다. 이후 저장소 폴더로 이동합니다.

cd C:\Scripts\Debloat-Win11

3단계: 설명 및 예행 실행

• 먼저 각 단계가 무엇을 하는지 확인하려면 -Explain을 사용합니다. 이 모드는 변경 없이 각 단계의 목적을 출력합니다.

.\Debloat-Win11.ps1 -Explain

• 다음으로 실제 변경 없이 시스템을 점검하려면 -DryRun을 실행합니다.

.\Debloat-Win11.ps1 -DryRun

• 이 단계에서는 제거 대상 앱, 적용될 레지스트리 값, 비활성화될 서비스, 건너뛸 작업 등을 확인할 수 있습니다. 
• 로그와 JSON 매니페스트도 함께 생성되므로, 실행 전 검토 자료로 보관하는 것이 좋습니다.

4단계: 되돌릴 수 없는 변경 승인

• 검토가 끝났다면 실제 정리 작업을 수행합니다. AppX 제거, OEM 정리, Office·OneDrive 제거, 방화벽 규칙 교체, 광범위한 정리 작업은 다음 플래그가 필요합니다.

.\Debloat-Win11.ps1 -AllowIrreversibleChanges

• Office와 OneDrive를 유지하려면 다음처럼 실행할 수 있습니다.

.\Debloat-Win11.ps1 -AllowIrreversibleChanges -SkipOfficeRemoval -SkipOneDriveRemoval

• Windows Defender 설정을 건드리지 않으려면 다음을 추가합니다.

.\Debloat-Win11.ps1 -AllowIrreversibleChanges -KeepDefender

5단계: 결과 확인 및 복구

• 실행이 끝나면 기본 로그 디렉터리인 %ProgramData%\Debloat-Win11\Logs에 로그, JSON 매니페스트, JSON 요약, HTML 보고서가 생성됩니다. 각 아티팩트 유형별로 최신 50개 파일만 유지됩니다.
• 앱을 다시 설치해야 한다면 정확한 패키지 ID를 지정해 복원할 수 있습니다.

.\Debloat-Win11.ps1 -RestoreApp "Microsoft.WindowsCamera" -RestoreSource "msstore"

• 두 시점의 되돌리기 매니페스트를 비교하려면 다음 명령을 사용합니다.

.\Debloat-Win11.ps1 -DiffManifests "manifest1.json","manifest2.json"

6단계: Windows Update 이후 점검

• Windows 기능 업데이트나 품질 업데이트 이후 일부 레지스트리 설정이 초기화될 수 있습니다. 
• 이를 확인하려면 다음을 실행합니다.

.\Debloat-Win11.ps1 -CheckDrift

• 기계 판독 가능한 결과가 필요하면 별도 스크립트에 출력 형식을 지정할 수 있습니다.

.\Detect-Debloat.ps1 -OutputFormat Json
.\Detect-Drift.ps1 -OutputFormat Json
.\Remediate-Drift.ps1 -OutputFormat Json
.\Debloat-Win11-Maintain.ps1 -OutputFormat Csv

 - 기업 배포 예시

• Intune이나 SCCM처럼 SYSTEM 권한으로 실행하는 환경에서는 모든 사용자 프로필에 HKCU 설정을 적용하기 위해 -AllUsers를 사용할 수 있습니다.

.\Debloat-Win11.ps1 -AllUsers

• 보안 강화 프리셋을 적용하려면 다음과 같이 실행합니다.

.\Debloat-Win11.ps1 -ConfigPath .\presets\security.psd1

• Windows 11 24H2 이상의 Enterprise 또는 Education 환경에서는 Microsoft가 제공하는 정책 기반 기본 앱 제거 기능도 활용할 수 있습니다. 
• Microsoft는 해당 기능을 24H2 이상에서 지원하며, 정적 목록과 동적 앱 제거 목록을 통해 사전 설치된 Microsoft Store 앱을 제거할 수 있다고 설명합니다.
• Debloat-Win11도 Enterprise·Education 24H2 이상 실행 시 Microsoft 호환 DynamicRemovalList CSP 페이로드를 로그로 남기며, GPO 레지스트리 방식과 Intune OMA-URI 방식을 동시에 섞어 적용할 경우 충돌 위험을 경고합니다.

◎ 기대효과 및 주의사항

 - 기대효과

• 잘 설계된 환경에서 이 도구는 다음과 같은 효과를 기대할 수 있습니다.
• 불필요한 앱·서비스·예약 작업 감소로 시작 및 백그라운드 부담 완화
• 광고성 콘텐츠, 자동 앱 설치, 일부 원격 분석 관련 설정 축소
• 장비 유형에 맞는 전원 및 저장장치 최적화
• 변경 이력과 결과 보고서 확보로 문제 발생 시 원인 추적 용이
• Windows Update 이후 설정 초기화를 점검하고 재적용하는 운영 흐름 구축
• WIM 기반 이미지 정리로 신규 PC 배포 시 초기 상태 일관성 확보

 - 반드시 점검할 주의사항

• 이 도구는 강력한 만큼, 운영 환경에서는 무분별한 적용이 위험합니다. 다음 사항을 우선 확인하시기 바랍니다.
• 프로덕션 PC에 바로 적용하지 마세요. 반드시 테스트 장비 또는 가상머신에서 -DryRun과 실제 실행을 먼저 검증하세요.
• 되돌릴 수 없는 작업을 이해하세요. AppX 제거, OEM 정리, OneDrive·Office 제거, 방화벽 규칙 교체 등은 -AllowIrreversibleChanges가 필요한 고위험 작업입니다.
• 조직 정책과 충돌 여부를 확인하세요. GPO, Intune, SCCM, 보안 에이전트가 이미 같은 레지스트리·서비스·방화벽 영역을 관리한다면 설정이 덮어써지거나 충돌할 수 있습니다.
• 업무용 앱과 주변기기 호환성을 확인하세요. 프로젝트는 Teams, Zoom, Slack, Cisco WebEx 시작 항목과 생체 인식, 터치 입력, 프록시 자동 검색 등 일부 서비스를 보존하지만, 조직의 실제 사용 환경은 다를 수 있습니다.
• 이벤트 로그 삭제는 기본적으로 피하세요. 보안 감사와 침해사고 대응 관점에서 SIEM 수집 대상 로그를 지우는 것은 바람직하지 않으며, 프로젝트도 이를 명시적 옵트인으로 제한했습니다.
• Windows Update 완전 차단은 권장하지 않습니다. 이 프로젝트도 Windows Update를 비활성화하기보다 지연·활성 시간·강제 재부팅 방지를 설정하는 방식입니다.
• 최신 README와 CHANGELOG를 확인하세요. Windows 업데이트, Copilot·Recall·AI 관련 정책, AppX 패키지 목록은 계속 변할 수 있으므로 실행 전 최신 문서를 대조하는 것이 안전합니다.

◎ 마무리

• Debloat-Win11은 “Windows를 무조건 가볍게 만드는 스크립트”라기보다, 기업 환경에서도 감사·미리보기·복구·유지보수를 고려한 Windows 구성 자동화 도구에 가깝습니다. 
• 특히 -DryRun, JSON 매니페스트, -AllowIrreversibleChanges 분리, 드리프트 점검 같은 설계는 개인 사용자에게도 실수를 줄여 주는 장점입니다.
• 다만 Windows 설정 변경은 보안 정책, 업무 앱, 주변기기, 로그 보존 요구와 직접 연결됩니다.
• 개인 PC에서는 DryRun → 로그 검토 → 필요한 플래그만 사용 → 결과 보고서 보관의 순서를 지키고, 조직 환경에서는 반드시 테스트 그룹과 승인 절차를 거친 뒤 배포하는 것을 권장합니다.