{"content_id":"vufynon7qa","slug":"php2shell-enterprise-security-patch-response-guide","locale":"ko","schema_type":"HowTo","category":"how_to","category_name":"하우투","title":"PHP2Shell 기업 서버 보안 대응 방법","summary":"PHP2Shell 대응은 실제 웹 서비스의 PHP 업데이트와 재시작부터 진행합니다. 침해가 의심되면 증거 보존을 먼저 진행하고, 패치 이후에도 로그 점검과 인증정보 교체가 필요합니다.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"인조이스 편집팀","url":"https://injoys.com/ko/about"},"key_points":["운영 중인 서버와 내장 제품의 PHP 사용 현황을 확인하세요.","침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존하세요.","수정 버전을 적용하거나 업데이트 전까지 공식 임시 조치를 적용하세요.","PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스의 패치 반영을 확인하세요.","과거 로그를 점검하고 노출된 서버의 인증정보를 교체하세요."],"content_markdown":"PHP2Shell 대응은 PHP 사용 현황 확인과 수정 버전 적용부터 시작합니다. 업데이트 뒤에는 실행 서비스를 재시작하세요. 침해가 의심되면 재시작 전에 증거를 보존해야 합니다. 패치 후에도 로그 점검과 인증정보 교체가 필요합니다.\n\n버전과 설정은 2026년 10월 22일 KISA 공지와 10월 23일 PHP 추가 공지를 기준으로 합니다.\n\n## PHP2Shell은 어떤 취약점인가요?\n\nPHP2Shell은 인증 없이 서버 코드를 실행할 수 있는 PHP 취약점입니다. 웹 서버가 요청을 처리하는 과정의 메모리 관리 문제입니다. 공격 성공 여부는 실행 환경과 설정에 따라 달라집니다.\n\n| 구분 | 식별 번호 | 문제의 성격 |\n| --- | --- | --- |\n| 메모리 부족 처리 문제 | CVE-2026-109618 | 메모리 부족 상황에서 불완전한 내부 데이터를 처리 |\n| 요청 사이에 남은 상태 문제 | CVE-2026-109619 | 해제된 메모리를 가리키는 상태를 이후 요청에서 사용 |\n\nKISA는 두 취약점의 심각도를 CVSS 9.2점으로 안내합니다. 공격에 성공하면 웹셸 설치나 고객정보 유출이 가능합니다. 웹셸은 서버를 원격으로 조종하는 데 악용되는 파일입니다. 홈페이지 변조와 내부망 침투로 이어질 수도 있습니다.\n\nKISA는 패치 배포 전 정보 유출과 공격 시도를 안내했습니다. 연구진은 AI를 활용한 취약점 발견 과정을 공개했습니다. 문제는 PHP 자체에 있어 특정 웹사이트 제품에만 한정되지 않습니다. [KISA 기업 대응 수칙](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230), [연구진의 PHP2Shell 설명](https://www.php2shell.com/)\n\n## 조건별 대응 순서\n\n침해 의심 여부에 따라 업데이트와 증거 보존의 순서가 달라집니다. 평상시 패치 작업은 테스트 후 업데이트와 재시작을 진행합니다. 침해가 의심되는 서버는 먼저 격리하세요.\n\n| 현재 상태 | 먼저 할 일 | 이어서 할 일 |\n| --- | --- | --- |\n| 침해 징후가 없는 공개 서버 | 호환성 검토와 수정 버전 적용 | 재시작, 실제 버전 확인, 로그 점검 |\n| 웹셸이나 의심스러운 연결 발견 | 네트워크 격리와 신고 | 증거 보존 후 복구 조치 |\n| 즉시 업데이트가 어려운 서버 | 공식 임시 설정과 앞단 요청 제한 | 패치 일정 수립과 적용 |\n| 임시 조치도 어려운 서버 | 외부 접속 차단 또는 일시 중단 검토 | 패치 후 재개 여부 판단 |\n| 호스팅·제조사가 관리하는 환경 | 관리 업체에 적용 여부 확인 | 실행 환경의 반영 근거 확보 |\n\n업데이트 후 재시작은 수정 코드를 실행하기 위한 절차입니다. 사고 대응 중 재시작을 미루는 이유는 증거 보존입니다. 같은 서버라도 침해 의심 상태라면 후자의 순서를 따르세요.\n\n## PHP 사용 현황 확인 방법\n\n자산 목록과 실제 동작 중인 서버를 함께 확인하세요. 대표 홈페이지만 점검하면 관리에서 빠진 서버를 놓칠 수 있습니다. PHP가 포함된 장비와 컨테이너도 확인 대상입니다.\n\n1. 인터넷에 공개된 홈페이지와 시스템을 목록으로 만드세요.\n2. 외주 제작 사이트와 오래된 사이트를 확인하세요.\n3. 이벤트·테스트 서버와 관리자 페이지를 확인하세요.\n4. 장비 관리화면과 솔루션의 PHP 포함 여부를 확인하세요.\n5. 컨테이너 이미지와 실행 중인 컨테이너를 확인하세요.\n6. 각 환경의 PHP 버전과 관리 담당자를 기록하세요.\n\n호스팅을 이용한다면 업체에 패치가 적용됐는지 확인을 요청하세요. 장비에 포함된 PHP는 제조사 업데이트를 확인하세요. 내부 시스템도 점검하되 인터넷 공개 서버부터 조치하세요.\n\n## PHP 수정 버전과 지원 종료 기준\n\nPHP 공식 공지의 8.5 계열 수정 버전은 **8.5.12**입니다. KISA 원문도 같은 버전을 안내합니다. 8.5.13을 기다려야 패치할 수 있다는 뜻이 아닙니다.\n\n| 사용 계열 | 두 취약점의 수정 버전 | 대응 기준 |\n| --- | --- | --- |\n| PHP 8.5 | 8.5.13 이상 | 해당 계열의 최신 보안 릴리스 확인 |\n| PHP 8.4 | 8.4.27 이상 | 해당 계열의 최신 보안 릴리스 확인 |\n| PHP 8.3 | 8.3.36 이상 | 해당 계열의 최신 보안 릴리스 확인 |\n| PHP 8.2 | 8.2.35 이상 | 패치와 함께 상위 계열 전환 준비 |\n| PHP 8.1 이하 | 정규 보안 지원 종료 | 지원 계열 전환 또는 공급업체 패치 확인 |\n\n표는 2026년 10월 21일 발표된 수정 버전 기준입니다. 배포판 패키지는 표시 버전이 그대로일 수 있습니다. 이 경우 변경 이력에서 두 CVE의 수정 여부를 확인하세요. [PHP 보안 릴리스 공지](https://www.php.net/archive/2026.php)\n\nPHP 8.2의 보안 지원 종료일은 2026년 12월 31일입니다. KISA는 PHP 8.3 이상으로 전환할 것을 권고합니다. 전환 전에는 애플리케이션 호환성을 테스트하세요. [PHP 지원 일정](https://www.php.net/supported-versions.php)\n\nPHP 8.1 이하는 정규 보안 지원이 끝난 상태입니다. 배포판이나 장기지원 업체의 패치는 별도로 확인해야 합니다. 이번에 공개된 구버전용 소스 패치도 정규 지원 재개를 뜻하지 않습니다.\n\n## 업데이트와 재시작 방법\n\n설치 파일 교체 뒤에는 PHP 실행 서비스의 재시작이 필요합니다. 기존 프로세스가 메모리에 남은 코드를 계속 실행할 수 있습니다. 침해가 의심된다면 아래 작업보다 증거 보존을 먼저 진행하세요.\n\n1. 패치가 기존 기능에 미치는 영향을 검토하세요.\n2. 테스트 환경에서 서비스 호환성을 확인하세요.\n3. 인터넷 공개 서버부터 수정 패키지를 적용하세요.\n4. PHP를 실행하는 모든 서비스를 재시작하세요.\n5. 컨테이너 환경은 수정된 이미지로 다시 배포하세요.\n6. 실제 웹 요청을 처리하는 PHP의 반영 상태를 확인하세요.\n\n재시작 대상에는 PHP-FPM과 Apache mod_php가 포함됩니다. php-cgi, FrankenPHP, LiteSpeed도 확인하세요. 서버에 여러 PHP 환경이 있다면 각각 점검해야 합니다.\n\n`php -v`는 명령줄에서 실행되는 PHP 버전을 보여줍니다. 웹 서비스가 사용하는 PHP와 다를 수 있습니다. 명령줄 출력만으로 업데이트 완료를 판단하지 마세요.\n\n## 업데이트 전 임시 설정 기준\n\n임시 조치는 일부 공격 경로를 줄이는 수단입니다. 전체 취약점을 해결하지는 못합니다. 설정 적용이 어렵다면 외부 접속 차단을 검토하세요.\n\n### memory_limit 설정은 어떻게 적용하나요?\n\n이번 취약점의 공식 임시 권고는 `memory_limit=-1`입니다. 이 값은 PHP 자체의 메모리 사용 한도를 해제합니다. 일반적인 운영 설정으로 받아들이지 마세요.\n\n한도를 해제하면 메모리 부족을 유발하는 특정 경로가 줄어듭니다. 실제 메모리 할당 실패까지 막는 설정은 아닙니다. 요청 크기 제한과 자원 관리 대책을 함께 검토해야 합니다. [PHP 메모리 부족 취약점 권고](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)\n\n| 항목 | 공식 임시 조치 | 적용 시 확인할 내용 |\n| --- | --- | --- |\n| `memory_limit` | `-1`로 지정 | 애플리케이션이 바꾸지 못하도록 관리자 설정 적용 |\n| `session.upload_progress.enabled` | `0`으로 지정 | 요청 처리 전에 적용되는 설정 위치 사용 |\n| `post_max_size` | 업로드 불필요 시 `8M` 예시 | 실제 서비스 요구와 앞단 제한을 함께 검토 |\n| `upload_max_filesize` | `post_max_size`보다 작게 지정 | 파일 업로드 기능의 영향 확인 |\n| `fatal_error_backtraces` | PHP 8.5에서 `0`으로 지정 | 다른 계열에 일괄 적용하지 않음 |\n\n표의 설정값은 2026년 10월 공식 대응 공지 기준입니다. `8M`은 업로드가 불필요한 서비스에 제시된 예시입니다. 모든 서비스에 같은 크기를 적용하는 기준은 아닙니다.\n\n1. 웹방화벽·웹 서버·프록시에서 요청 크기를 제한하세요.\n2. 크기 정보가 없는 요청에도 제한이 적용되는지 확인하세요.\n3. 업로드가 불필요하면 multipart 요청을 앞단에서 차단하세요.\n4. 웹방화벽의 최신 차단 규칙을 확인하세요.\n5. `php.ini`나 PHP-FPM pool 등에서 설정을 적용하세요.\n6. 증거 보존이 필요한지 확인한 뒤 PHP 프로세스를 재시작하세요.\n\n`ini_set()`만으로 임시 설정을 적용하지 마세요. 요청 처리 전에 필요한 설정이 늦게 적용될 수 있습니다. PHP-FPM의 `.user.ini`에도 같은 역할을 기대하지 마세요. [PHP 공식 임시 조치](https://www.php.net/archive/2026.php)\n\n### 10월 23일 추가 공지에서 확인할 내용\n\nPHP는 추가 공지에서 업로드 진행률 기능을 끄도록 권고했습니다. 일부 설정 조합에 남은 별도 실행 경로에 대한 안내입니다. 이미 기능을 껐다면 다음 정기 수정 릴리스까지 유지하도록 안내합니다.\n\n해당 조건에는 실행 중 세션 직렬화 방식 변경이 포함됩니다. 모든 PHP 설치에서 같은 조건이 성립하는 것은 아닙니다. 패치 뒤 설정 복원 여부는 추가 공지를 확인해 결정하세요. (확인값 session.upload_progress.enabled=0을 다음 정기 버그 수정 릴리스까지 유지하도록 권고 · 출처 php.net · 2026-10-23 확인) [PHP Session upload progress 추가 공지](https://www.php.net/archive/2026.php)\n\n## 로그 점검과 인증정보 교체 방법\n\nKISA는 최소 **2026년 10월 20일 이후** 기록 점검을 권고합니다. 가능하면 그 이전 기록도 확인하세요. 패치는 이미 발생한 침해나 정보 유출을 되돌리지 못합니다.\n\n| 점검 대상 | 확인할 흔적 |\n| --- | --- |\n| 웹 서버 로그 | 반복되는 HTTP 500 오류 |\n| PHP 실행 기록 | 비정상 종료와 segfault |\n| 웹·업로드·임시 폴더 | 새로 생기거나 바뀐 PHP 파일 |\n| 프로세스 실행 기록 | 웹 서버의 sh·bash·다운로드 도구 실행 |\n| 네트워크 연결 | 낯선 외부 주소로 새로 연결한 흔적 |\n| 홈페이지·관리 페이지 | 몰래 추가된 외부 스크립트 |\n\n오류가 있다는 사실만으로 침해를 확정할 수는 없습니다. 반대로 이상 기록이 없다고 안전을 확정할 수도 없습니다. KISA는 다음과 같이 안내합니다.\n\n\u003e 기록상 이상이 없더라도 안전이 보장되지 않으므로, 업데이트와 인증정보 교체를 함께 진행\n\u003e\n\u003e KISA 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」\n\n패치 전 인터넷에 노출된 서버는 인증정보 교체가 권고됩니다. 침해 흔적이 발견된 서버는 반드시 교체하세요. 대상에는 DB 비밀번호와 관리자 비밀번호가 포함됩니다. API 키와 접속 토큰도 노출 가능성을 점검하세요.\n\n개인정보 DB를 연결한 서비스는 DB 기록도 확인하세요. 대량 조회와 반출 흔적을 점검할 필요가 있습니다. phpMyAdmin의 인터넷 직접 접근도 제한하세요. 웹서비스 계정의 DB 권한은 필요한 범위로 줄이세요. [개인정보보호위원회 예방조치 안내](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588)\n\n## 침해가 의심될 때 대응 순서\n\n침해가 의심되면 서버를 끄거나 바로 재시작하지 마세요. 재시작으로 메모리에 남은 공격 흔적이 사라질 수 있습니다. 네트워크 격리 뒤 증거 확보를 진행하세요.\n\n1. 서버의 외부 접속을 네트워크에서 차단하세요.\n2. 국내 기업은 보호나라의 침해사고 신고 메뉴로 신고하세요.\n3. 로그와 실행 중인 프로그램 목록을 보존하세요.\n4. 현재 네트워크 연결 정보도 보존하세요.\n5. 증거 확보 뒤 업데이트와 재시작을 진행하세요.\n6. 웹셸 제거와 인증정보 교체를 진행하세요.\n\n국내 상담 창구는 KISA 118입니다. 신고 메뉴는 보호나라 \u003e 침해사고 신고 \u003e 신고하기입니다. 해외에서 운영한다면 해당 지역의 신고 창구를 확인하세요.\n\n## 흔한 실수 비교\n\n패치 적용 여부는 실행 상태와 변경 이력까지 확인해야 합니다. 설치 완료 메시지만으로는 확인이 끝나지 않습니다. 다음 판단을 점검표에 넣어두세요.\n\n| 흔한 판단 | 확인해야 할 내용 |\n| --- | --- |\n| `php -v`가 바뀌면 완료 | 웹 서비스가 실제 사용하는 PHP 확인 |\n| 패키지만 설치하면 완료 | PHP 실행 서비스 재시작 확인 |\n| 버전 숫자가 그대로면 미조치 | 배포판 변경 이력의 CVE 수정 여부 확인 |\n| 웹방화벽이 있으면 패치 생략 가능 | 최신 규칙 확인과 PHP 업데이트 병행 |\n| 로그가 깨끗하면 유출 없음 | 인증정보의 노출 가능성까지 검토 |\n| 외주 사이트는 업체가 알아서 처리 | 서비스별 적용 근거 요청 |\n\n인터넷에서 찾은 검증 코드를 운영 서버에 실행하지 마세요. KISA는 악성코드가 포함된 가짜 PoC를 경고합니다. PoC는 취약점 악용 가능성을 보여주는 검증 코드입니다. 취약 여부는 버전과 패치 이력부터 확인하세요.\n\n## 외주·호스팅 환경의 조치 완료 확인표\n\n조치 완료 보고에는 서비스별 확인 근거를 남기는 편이 좋습니다. 아래 표는 KISA 대응 수칙을 업무 확인 항목으로 묶은 것입니다. 별도의 공식 제출 서식은 아닙니다.\n\n| 확인 항목 | 업체나 담당자에게 요청할 내용 |\n| --- | --- |\n| 대상 누락 여부 | 홈페이지·관리 페이지·테스트 서버의 점검 목록 |\n| 취약점 수정 | 적용 버전 또는 두 CVE가 적힌 패키지 변경 이력 |\n| 실행 상태 | 서비스 재시작 또는 컨테이너 재배포 기록 |\n| 실제 반영 | 웹 서비스에서 확인한 PHP 실행 환경 |\n| 침해 점검 | 점검한 로그 기간과 발견 사항 |\n| 인증정보 | 교체 대상과 완료 여부 |\n| 남은 작업 | 임시 조치만 적용된 서버와 후속 패치 계획 |\n\n예를 들어 업체가 패키지 설치 완료만 알렸다고 가정합니다. 이때는 재시작과 웹 실행 환경의 확인 결과를 요청하세요. 로그 점검과 인증정보 교체는 별도 항목으로 확인하면 됩니다.","content_html":"\u003cp\u003ePHP2Shell 대응은 PHP 사용 현황 확인과 수정 버전 적용부터 시작합니다. 업데이트 뒤에는 실행 서비스를 재시작하세요. 침해가 의심되면 재시작 전에 증거를 보존해야 합니다. 패치 후에도 로그 점검과 인증정보 교체가 필요합니다.\u003c/p\u003e\n\u003cp\u003e버전과 설정은 2026년 10월 22일 KISA 공지와 10월 23일 PHP 추가 공지를 기준으로 합니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#php2shell%EC%9D%80-%EC%96%B4%EB%96%A4-%EC%B7%A8%EC%95%BD%EC%A0%90%EC%9D%B8%EA%B0%80%EC%9A%94\" class=\"anchor\" id=\"php2shell은-어떤-취약점인가요\"\u003e\u003c/a\u003ePHP2Shell은 어떤 취약점인가요?\u003c/h2\u003e\n\u003cp\u003ePHP2Shell은 인증 없이 서버 코드를 실행할 수 있는 PHP 취약점입니다. 웹 서버가 요청을 처리하는 과정의 메모리 관리 문제입니다. 공격 성공 여부는 실행 환경과 설정에 따라 달라집니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e구분\u003c/th\u003e\n\u003cth\u003e식별 번호\u003c/th\u003e\n\u003cth\u003e문제의 성격\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"구분\"\u003e메모리 부족 처리 문제\u003c/td\u003e\n\u003ctd data-label=\"식별 번호\"\u003eCVE-2026-109618\u003c/td\u003e\n\u003ctd data-label=\"문제의 성격\"\u003e메모리 부족 상황에서 불완전한 내부 데이터를 처리\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"구분\"\u003e요청 사이에 남은 상태 문제\u003c/td\u003e\n\u003ctd data-label=\"식별 번호\"\u003eCVE-2026-109619\u003c/td\u003e\n\u003ctd data-label=\"문제의 성격\"\u003e해제된 메모리를 가리키는 상태를 이후 요청에서 사용\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eKISA는 두 취약점의 심각도를 CVSS 9.2점으로 안내합니다. 공격에 성공하면 웹셸 설치나 고객정보 유출이 가능합니다. 웹셸은 서버를 원격으로 조종하는 데 악용되는 파일입니다. 홈페이지 변조와 내부망 침투로 이어질 수도 있습니다.\u003c/p\u003e\n\u003cp\u003eKISA는 패치 배포 전 정보 유출과 공격 시도를 안내했습니다. 연구진은 AI를 활용한 취약점 발견 과정을 공개했습니다. 문제는 PHP 자체에 있어 특정 웹사이트 제품에만 한정되지 않습니다. \u003ca href=\"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026amp;menuNo=205020\u0026amp;nttId=72230\"\u003eKISA 기업 대응 수칙\u003c/a\u003e, \u003ca href=\"https://www.php2shell.com/\"\u003e연구진의 PHP2Shell 설명\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%A1%B0%EA%B1%B4%EB%B3%84-%EB%8C%80%EC%9D%91-%EC%88%9C%EC%84%9C\" class=\"anchor\" id=\"조건별-대응-순서\"\u003e\u003c/a\u003e조건별 대응 순서\u003c/h2\u003e\n\u003cp\u003e침해 의심 여부에 따라 업데이트와 증거 보존의 순서가 달라집니다. 평상시 패치 작업은 테스트 후 업데이트와 재시작을 진행합니다. 침해가 의심되는 서버는 먼저 격리하세요.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e현재 상태\u003c/th\u003e\n\u003cth\u003e먼저 할 일\u003c/th\u003e\n\u003cth\u003e이어서 할 일\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"현재 상태\"\u003e침해 징후가 없는 공개 서버\u003c/td\u003e\n\u003ctd data-label=\"먼저 할 일\"\u003e호환성 검토와 수정 버전 적용\u003c/td\u003e\n\u003ctd data-label=\"이어서 할 일\"\u003e재시작, 실제 버전 확인, 로그 점검\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"현재 상태\"\u003e웹셸이나 의심스러운 연결 발견\u003c/td\u003e\n\u003ctd data-label=\"먼저 할 일\"\u003e네트워크 격리와 신고\u003c/td\u003e\n\u003ctd data-label=\"이어서 할 일\"\u003e증거 보존 후 복구 조치\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"현재 상태\"\u003e즉시 업데이트가 어려운 서버\u003c/td\u003e\n\u003ctd data-label=\"먼저 할 일\"\u003e공식 임시 설정과 앞단 요청 제한\u003c/td\u003e\n\u003ctd data-label=\"이어서 할 일\"\u003e패치 일정 수립과 적용\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"현재 상태\"\u003e임시 조치도 어려운 서버\u003c/td\u003e\n\u003ctd data-label=\"먼저 할 일\"\u003e외부 접속 차단 또는 일시 중단 검토\u003c/td\u003e\n\u003ctd data-label=\"이어서 할 일\"\u003e패치 후 재개 여부 판단\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"현재 상태\"\u003e호스팅·제조사가 관리하는 환경\u003c/td\u003e\n\u003ctd data-label=\"먼저 할 일\"\u003e관리 업체에 적용 여부 확인\u003c/td\u003e\n\u003ctd data-label=\"이어서 할 일\"\u003e실행 환경의 반영 근거 확보\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e업데이트 후 재시작은 수정 코드를 실행하기 위한 절차입니다. 사고 대응 중 재시작을 미루는 이유는 증거 보존입니다. 같은 서버라도 침해 의심 상태라면 후자의 순서를 따르세요.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#php-%EC%82%AC%EC%9A%A9-%ED%98%84%ED%99%A9-%ED%99%95%EC%9D%B8-%EB%B0%A9%EB%B2%95\" class=\"anchor\" id=\"php-사용-현황-확인-방법\"\u003e\u003c/a\u003ePHP 사용 현황 확인 방법\u003c/h2\u003e\n\u003cp\u003e자산 목록과 실제 동작 중인 서버를 함께 확인하세요. 대표 홈페이지만 점검하면 관리에서 빠진 서버를 놓칠 수 있습니다. PHP가 포함된 장비와 컨테이너도 확인 대상입니다.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e인터넷에 공개된 홈페이지와 시스템을 목록으로 만드세요.\u003c/li\u003e\n\u003cli\u003e외주 제작 사이트와 오래된 사이트를 확인하세요.\u003c/li\u003e\n\u003cli\u003e이벤트·테스트 서버와 관리자 페이지를 확인하세요.\u003c/li\u003e\n\u003cli\u003e장비 관리화면과 솔루션의 PHP 포함 여부를 확인하세요.\u003c/li\u003e\n\u003cli\u003e컨테이너 이미지와 실행 중인 컨테이너를 확인하세요.\u003c/li\u003e\n\u003cli\u003e각 환경의 PHP 버전과 관리 담당자를 기록하세요.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e호스팅을 이용한다면 업체에 패치가 적용됐는지 확인을 요청하세요. 장비에 포함된 PHP는 제조사 업데이트를 확인하세요. 내부 시스템도 점검하되 인터넷 공개 서버부터 조치하세요.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#php-%EC%88%98%EC%A0%95-%EB%B2%84%EC%A0%84%EA%B3%BC-%EC%A7%80%EC%9B%90-%EC%A2%85%EB%A3%8C-%EA%B8%B0%EC%A4%80\" class=\"anchor\" id=\"php-수정-버전과-지원-종료-기준\"\u003e\u003c/a\u003ePHP 수정 버전과 지원 종료 기준\u003c/h2\u003e\n\u003cp\u003ePHP 공식 공지의 8.5 계열 수정 버전은 \u003cstrong\u003e8.5.12\u003c/strong\u003e입니다. KISA 원문도 같은 버전을 안내합니다. 8.5.13을 기다려야 패치할 수 있다는 뜻이 아닙니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e사용 계열\u003c/th\u003e\n\u003cth\u003e두 취약점의 수정 버전\u003c/th\u003e\n\u003cth\u003e대응 기준\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"사용 계열\"\u003ePHP 8.5\u003c/td\u003e\n\u003ctd data-label=\"두 취약점의 수정 버전\"\u003e8.5.13 이상\u003c/td\u003e\n\u003ctd data-label=\"대응 기준\"\u003e해당 계열의 최신 보안 릴리스 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"사용 계열\"\u003ePHP 8.4\u003c/td\u003e\n\u003ctd data-label=\"두 취약점의 수정 버전\"\u003e8.4.27 이상\u003c/td\u003e\n\u003ctd data-label=\"대응 기준\"\u003e해당 계열의 최신 보안 릴리스 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"사용 계열\"\u003ePHP 8.3\u003c/td\u003e\n\u003ctd data-label=\"두 취약점의 수정 버전\"\u003e8.3.36 이상\u003c/td\u003e\n\u003ctd data-label=\"대응 기준\"\u003e해당 계열의 최신 보안 릴리스 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"사용 계열\"\u003ePHP 8.2\u003c/td\u003e\n\u003ctd data-label=\"두 취약점의 수정 버전\"\u003e8.2.35 이상\u003c/td\u003e\n\u003ctd data-label=\"대응 기준\"\u003e패치와 함께 상위 계열 전환 준비\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"사용 계열\"\u003ePHP 8.1 이하\u003c/td\u003e\n\u003ctd data-label=\"두 취약점의 수정 버전\"\u003e정규 보안 지원 종료\u003c/td\u003e\n\u003ctd data-label=\"대응 기준\"\u003e지원 계열 전환 또는 공급업체 패치 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e표는 2026년 10월 21일 발표된 수정 버전 기준입니다. 배포판 패키지는 표시 버전이 그대로일 수 있습니다. 이 경우 변경 이력에서 두 CVE의 수정 여부를 확인하세요. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003ePHP 보안 릴리스 공지\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003ePHP 8.2의 보안 지원 종료일은 2026년 12월 31일입니다. KISA는 PHP 8.3 이상으로 전환할 것을 권고합니다. 전환 전에는 애플리케이션 호환성을 테스트하세요. \u003ca href=\"https://www.php.net/supported-versions.php\"\u003ePHP 지원 일정\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003ePHP 8.1 이하는 정규 보안 지원이 끝난 상태입니다. 배포판이나 장기지원 업체의 패치는 별도로 확인해야 합니다. 이번에 공개된 구버전용 소스 패치도 정규 지원 재개를 뜻하지 않습니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%97%85%EB%8D%B0%EC%9D%B4%ED%8A%B8%EC%99%80-%EC%9E%AC%EC%8B%9C%EC%9E%91-%EB%B0%A9%EB%B2%95\" class=\"anchor\" id=\"업데이트와-재시작-방법\"\u003e\u003c/a\u003e업데이트와 재시작 방법\u003c/h2\u003e\n\u003cp\u003e설치 파일 교체 뒤에는 PHP 실행 서비스의 재시작이 필요합니다. 기존 프로세스가 메모리에 남은 코드를 계속 실행할 수 있습니다. 침해가 의심된다면 아래 작업보다 증거 보존을 먼저 진행하세요.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e패치가 기존 기능에 미치는 영향을 검토하세요.\u003c/li\u003e\n\u003cli\u003e테스트 환경에서 서비스 호환성을 확인하세요.\u003c/li\u003e\n\u003cli\u003e인터넷 공개 서버부터 수정 패키지를 적용하세요.\u003c/li\u003e\n\u003cli\u003ePHP를 실행하는 모든 서비스를 재시작하세요.\u003c/li\u003e\n\u003cli\u003e컨테이너 환경은 수정된 이미지로 다시 배포하세요.\u003c/li\u003e\n\u003cli\u003e실제 웹 요청을 처리하는 PHP의 반영 상태를 확인하세요.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e재시작 대상에는 PHP-FPM과 Apache mod_php가 포함됩니다. php-cgi, FrankenPHP, LiteSpeed도 확인하세요. 서버에 여러 PHP 환경이 있다면 각각 점검해야 합니다.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ephp -v\u003c/code\u003e는 명령줄에서 실행되는 PHP 버전을 보여줍니다. 웹 서비스가 사용하는 PHP와 다를 수 있습니다. 명령줄 출력만으로 업데이트 완료를 판단하지 마세요.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%97%85%EB%8D%B0%EC%9D%B4%ED%8A%B8-%EC%A0%84-%EC%9E%84%EC%8B%9C-%EC%84%A4%EC%A0%95-%EA%B8%B0%EC%A4%80\" class=\"anchor\" id=\"업데이트-전-임시-설정-기준\"\u003e\u003c/a\u003e업데이트 전 임시 설정 기준\u003c/h2\u003e\n\u003cp\u003e임시 조치는 일부 공격 경로를 줄이는 수단입니다. 전체 취약점을 해결하지는 못합니다. 설정 적용이 어렵다면 외부 접속 차단을 검토하세요.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#memory_limit-%EC%84%A4%EC%A0%95%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%A0%81%EC%9A%A9%ED%95%98%EB%82%98%EC%9A%94\" class=\"anchor\" id=\"memory_limit-설정은-어떻게-적용하나요\"\u003e\u003c/a\u003ememory_limit 설정은 어떻게 적용하나요?\u003c/h3\u003e\n\u003cp\u003e이번 취약점의 공식 임시 권고는 \u003ccode\u003ememory_limit=-1\u003c/code\u003e입니다. 이 값은 PHP 자체의 메모리 사용 한도를 해제합니다. 일반적인 운영 설정으로 받아들이지 마세요.\u003c/p\u003e\n\u003cp\u003e한도를 해제하면 메모리 부족을 유발하는 특정 경로가 줄어듭니다. 실제 메모리 할당 실패까지 막는 설정은 아닙니다. 요청 크기 제한과 자원 관리 대책을 함께 검토해야 합니다. \u003ca href=\"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w\"\u003ePHP 메모리 부족 취약점 권고\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e항목\u003c/th\u003e\n\u003cth\u003e공식 임시 조치\u003c/th\u003e\n\u003cth\u003e적용 시 확인할 내용\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e\u003ccode\u003ememory_limit\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"공식 임시 조치\"\u003e\n\u003ccode\u003e-1\u003c/code\u003e로 지정\u003c/td\u003e\n\u003ctd data-label=\"적용 시 확인할 내용\"\u003e애플리케이션이 바꾸지 못하도록 관리자 설정 적용\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e\u003ccode\u003esession.upload_progress.enabled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"공식 임시 조치\"\u003e\n\u003ccode\u003e0\u003c/code\u003e으로 지정\u003c/td\u003e\n\u003ctd data-label=\"적용 시 확인할 내용\"\u003e요청 처리 전에 적용되는 설정 위치 사용\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e\u003ccode\u003epost_max_size\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"공식 임시 조치\"\u003e업로드 불필요 시 \u003ccode\u003e8M\u003c/code\u003e 예시\u003c/td\u003e\n\u003ctd data-label=\"적용 시 확인할 내용\"\u003e실제 서비스 요구와 앞단 제한을 함께 검토\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e\u003ccode\u003eupload_max_filesize\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"공식 임시 조치\"\u003e\n\u003ccode\u003epost_max_size\u003c/code\u003e보다 작게 지정\u003c/td\u003e\n\u003ctd data-label=\"적용 시 확인할 내용\"\u003e파일 업로드 기능의 영향 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e\u003ccode\u003efatal_error_backtraces\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"공식 임시 조치\"\u003ePHP 8.5에서 \u003ccode\u003e0\u003c/code\u003e으로 지정\u003c/td\u003e\n\u003ctd data-label=\"적용 시 확인할 내용\"\u003e다른 계열에 일괄 적용하지 않음\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e표의 설정값은 2026년 10월 공식 대응 공지 기준입니다. \u003ccode\u003e8M\u003c/code\u003e은 업로드가 불필요한 서비스에 제시된 예시입니다. 모든 서비스에 같은 크기를 적용하는 기준은 아닙니다.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e웹방화벽·웹 서버·프록시에서 요청 크기를 제한하세요.\u003c/li\u003e\n\u003cli\u003e크기 정보가 없는 요청에도 제한이 적용되는지 확인하세요.\u003c/li\u003e\n\u003cli\u003e업로드가 불필요하면 multipart 요청을 앞단에서 차단하세요.\u003c/li\u003e\n\u003cli\u003e웹방화벽의 최신 차단 규칙을 확인하세요.\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003ephp.ini\u003c/code\u003e나 PHP-FPM pool 등에서 설정을 적용하세요.\u003c/li\u003e\n\u003cli\u003e증거 보존이 필요한지 확인한 뒤 PHP 프로세스를 재시작하세요.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003ccode\u003eini_set()\u003c/code\u003e만으로 임시 설정을 적용하지 마세요. 요청 처리 전에 필요한 설정이 늦게 적용될 수 있습니다. PHP-FPM의 \u003ccode\u003e.user.ini\u003c/code\u003e에도 같은 역할을 기대하지 마세요. \u003ca href=\"https://www.php.net/archive/2026.php\"\u003ePHP 공식 임시 조치\u003c/a\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#10%EC%9B%94-23%EC%9D%BC-%EC%B6%94%EA%B0%80-%EA%B3%B5%EC%A7%80%EC%97%90%EC%84%9C-%ED%99%95%EC%9D%B8%ED%95%A0-%EB%82%B4%EC%9A%A9\" class=\"anchor\" id=\"10월-23일-추가-공지에서-확인할-내용\"\u003e\u003c/a\u003e10월 23일 추가 공지에서 확인할 내용\u003c/h3\u003e\n\u003cp\u003ePHP는 추가 공지에서 업로드 진행률 기능을 끄도록 권고했습니다. 일부 설정 조합에 남은 별도 실행 경로에 대한 안내입니다. 이미 기능을 껐다면 다음 정기 수정 릴리스까지 유지하도록 안내합니다.\u003c/p\u003e\n\u003cp\u003e해당 조건에는 실행 중 세션 직렬화 방식 변경이 포함됩니다. 모든 PHP 설치에서 같은 조건이 성립하는 것은 아닙니다. 패치 뒤 설정 복원 여부는 추가 공지를 확인해 결정하세요. (확인값 session.upload_progress.enabled=0을 다음 정기 버그 수정 릴리스까지 유지하도록 권고 · 출처 php.net · 2026-10-23 확인) \u003ca href=\"https://www.php.net/archive/2026.php\"\u003ePHP Session upload progress 추가 공지\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EB%A1%9C%EA%B7%B8-%EC%A0%90%EA%B2%80%EA%B3%BC-%EC%9D%B8%EC%A6%9D%EC%A0%95%EB%B3%B4-%EA%B5%90%EC%B2%B4-%EB%B0%A9%EB%B2%95\" class=\"anchor\" id=\"로그-점검과-인증정보-교체-방법\"\u003e\u003c/a\u003e로그 점검과 인증정보 교체 방법\u003c/h2\u003e\n\u003cp\u003eKISA는 최소 \u003cstrong\u003e2026년 10월 20일 이후\u003c/strong\u003e 기록 점검을 권고합니다. 가능하면 그 이전 기록도 확인하세요. 패치는 이미 발생한 침해나 정보 유출을 되돌리지 못합니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e점검 대상\u003c/th\u003e\n\u003cth\u003e확인할 흔적\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"점검 대상\"\u003e웹 서버 로그\u003c/td\u003e\n\u003ctd data-label=\"확인할 흔적\"\u003e반복되는 HTTP 500 오류\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"점검 대상\"\u003ePHP 실행 기록\u003c/td\u003e\n\u003ctd data-label=\"확인할 흔적\"\u003e비정상 종료와 segfault\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"점검 대상\"\u003e웹·업로드·임시 폴더\u003c/td\u003e\n\u003ctd data-label=\"확인할 흔적\"\u003e새로 생기거나 바뀐 PHP 파일\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"점검 대상\"\u003e프로세스 실행 기록\u003c/td\u003e\n\u003ctd data-label=\"확인할 흔적\"\u003e웹 서버의 sh·bash·다운로드 도구 실행\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"점검 대상\"\u003e네트워크 연결\u003c/td\u003e\n\u003ctd data-label=\"확인할 흔적\"\u003e낯선 외부 주소로 새로 연결한 흔적\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"점검 대상\"\u003e홈페이지·관리 페이지\u003c/td\u003e\n\u003ctd data-label=\"확인할 흔적\"\u003e몰래 추가된 외부 스크립트\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e오류가 있다는 사실만으로 침해를 확정할 수는 없습니다. 반대로 이상 기록이 없다고 안전을 확정할 수도 없습니다. KISA는 다음과 같이 안내합니다.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e기록상 이상이 없더라도 안전이 보장되지 않으므로, 업데이트와 인증정보 교체를 함께 진행\u003c/p\u003e\n\u003cp\u003eKISA 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e패치 전 인터넷에 노출된 서버는 인증정보 교체가 권고됩니다. 침해 흔적이 발견된 서버는 반드시 교체하세요. 대상에는 DB 비밀번호와 관리자 비밀번호가 포함됩니다. API 키와 접속 토큰도 노출 가능성을 점검하세요.\u003c/p\u003e\n\u003cp\u003e개인정보 DB를 연결한 서비스는 DB 기록도 확인하세요. 대량 조회와 반출 흔적을 점검할 필요가 있습니다. phpMyAdmin의 인터넷 직접 접근도 제한하세요. 웹서비스 계정의 DB 권한은 필요한 범위로 줄이세요. \u003ca href=\"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026amp;mCode=C010010000\u0026amp;nttId=12588\"\u003e개인정보보호위원회 예방조치 안내\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%B9%A8%ED%95%B4%EA%B0%80-%EC%9D%98%EC%8B%AC%EB%90%A0-%EB%95%8C-%EB%8C%80%EC%9D%91-%EC%88%9C%EC%84%9C\" class=\"anchor\" id=\"침해가-의심될-때-대응-순서\"\u003e\u003c/a\u003e침해가 의심될 때 대응 순서\u003c/h2\u003e\n\u003cp\u003e침해가 의심되면 서버를 끄거나 바로 재시작하지 마세요. 재시작으로 메모리에 남은 공격 흔적이 사라질 수 있습니다. 네트워크 격리 뒤 증거 확보를 진행하세요.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e서버의 외부 접속을 네트워크에서 차단하세요.\u003c/li\u003e\n\u003cli\u003e국내 기업은 보호나라의 침해사고 신고 메뉴로 신고하세요.\u003c/li\u003e\n\u003cli\u003e로그와 실행 중인 프로그램 목록을 보존하세요.\u003c/li\u003e\n\u003cli\u003e현재 네트워크 연결 정보도 보존하세요.\u003c/li\u003e\n\u003cli\u003e증거 확보 뒤 업데이트와 재시작을 진행하세요.\u003c/li\u003e\n\u003cli\u003e웹셸 제거와 인증정보 교체를 진행하세요.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e국내 상담 창구는 KISA 118입니다. 신고 메뉴는 보호나라 \u0026gt; 침해사고 신고 \u0026gt; 신고하기입니다. 해외에서 운영한다면 해당 지역의 신고 창구를 확인하세요.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%ED%9D%94%ED%95%9C-%EC%8B%A4%EC%88%98-%EB%B9%84%EA%B5%90\" class=\"anchor\" id=\"흔한-실수-비교\"\u003e\u003c/a\u003e흔한 실수 비교\u003c/h2\u003e\n\u003cp\u003e패치 적용 여부는 실행 상태와 변경 이력까지 확인해야 합니다. 설치 완료 메시지만으로는 확인이 끝나지 않습니다. 다음 판단을 점검표에 넣어두세요.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e흔한 판단\u003c/th\u003e\n\u003cth\u003e확인해야 할 내용\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"흔한 판단\"\u003e\n\u003ccode\u003ephp -v\u003c/code\u003e가 바뀌면 완료\u003c/td\u003e\n\u003ctd data-label=\"확인해야 할 내용\"\u003e웹 서비스가 실제 사용하는 PHP 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"흔한 판단\"\u003e패키지만 설치하면 완료\u003c/td\u003e\n\u003ctd data-label=\"확인해야 할 내용\"\u003ePHP 실행 서비스 재시작 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"흔한 판단\"\u003e버전 숫자가 그대로면 미조치\u003c/td\u003e\n\u003ctd data-label=\"확인해야 할 내용\"\u003e배포판 변경 이력의 CVE 수정 여부 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"흔한 판단\"\u003e웹방화벽이 있으면 패치 생략 가능\u003c/td\u003e\n\u003ctd data-label=\"확인해야 할 내용\"\u003e최신 규칙 확인과 PHP 업데이트 병행\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"흔한 판단\"\u003e로그가 깨끗하면 유출 없음\u003c/td\u003e\n\u003ctd data-label=\"확인해야 할 내용\"\u003e인증정보의 노출 가능성까지 검토\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"흔한 판단\"\u003e외주 사이트는 업체가 알아서 처리\u003c/td\u003e\n\u003ctd data-label=\"확인해야 할 내용\"\u003e서비스별 적용 근거 요청\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e인터넷에서 찾은 검증 코드를 운영 서버에 실행하지 마세요. KISA는 악성코드가 포함된 가짜 PoC를 경고합니다. PoC는 취약점 악용 가능성을 보여주는 검증 코드입니다. 취약 여부는 버전과 패치 이력부터 확인하세요.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%99%B8%EC%A3%BC%ED%98%B8%EC%8A%A4%ED%8C%85-%ED%99%98%EA%B2%BD%EC%9D%98-%EC%A1%B0%EC%B9%98-%EC%99%84%EB%A3%8C-%ED%99%95%EC%9D%B8%ED%91%9C\" class=\"anchor\" id=\"외주호스팅-환경의-조치-완료-확인표\"\u003e\u003c/a\u003e외주·호스팅 환경의 조치 완료 확인표\u003c/h2\u003e\n\u003cp\u003e조치 완료 보고에는 서비스별 확인 근거를 남기는 편이 좋습니다. 아래 표는 KISA 대응 수칙을 업무 확인 항목으로 묶은 것입니다. 별도의 공식 제출 서식은 아닙니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e확인 항목\u003c/th\u003e\n\u003cth\u003e업체나 담당자에게 요청할 내용\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e대상 누락 여부\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e홈페이지·관리 페이지·테스트 서버의 점검 목록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e취약점 수정\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e적용 버전 또는 두 CVE가 적힌 패키지 변경 이력\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e실행 상태\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e서비스 재시작 또는 컨테이너 재배포 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e실제 반영\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e웹 서비스에서 확인한 PHP 실행 환경\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e침해 점검\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e점검한 로그 기간과 발견 사항\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e인증정보\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e교체 대상과 완료 여부\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"확인 항목\"\u003e남은 작업\u003c/td\u003e\n\u003ctd data-label=\"업체나 담당자에게 요청할 내용\"\u003e임시 조치만 적용된 서버와 후속 패치 계획\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e예를 들어 업체가 패키지 설치 완료만 알렸다고 가정합니다. 이때는 재시작과 웹 실행 환경의 확인 결과를 요청하세요. 로그 점검과 인증정보 교체는 별도 항목으로 확인하면 됩니다.\u003c/p\u003e\n","tags":["개인정보보호","PHP","보안 업데이트"],"faqs":[{"question":"PHP2Shell은 로그인 비밀번호를 바꾸면 막을 수 있나요?","answer":"로그인 없이 악용될 수 있어 비밀번호 변경만으로 해결되지 않습니다. PHP 보안 업데이트가 필요합니다. 인증정보 교체는 유출 가능성에 대응하는 별도 조치입니다."},{"question":"PHP 8.5는 8.5.13까지 기다려야 하나요?","answer":"PHP와 KISA 원문은 두 취약점의 수정 버전을 8.5.13로 안내합니다. 8.5.13을 기다려야 한다는 뜻이 아닙니다. 적용할 때는 해당 계열의 최신 공식 릴리스도 확인하세요."},{"question":"PHP-FPM을 사용하면 점검하지 않아도 되나요?","answer":"PHP-FPM도 점검 대상입니다. 실행 방식에 따라 공격 조건은 달라질 수 있습니다. 환경 이름만으로 안전을 판단하지 마세요."},{"question":"php -v 결과가 수정 버전이면 조치가 끝난 것인가요?","answer":"명령줄 PHP와 웹 서비스의 PHP가 다를 수 있습니다. 실제 웹 요청을 처리하는 환경을 확인하세요. 실행 서비스의 재시작 여부도 확인해야 합니다."},{"question":"패치 후 버전 번호가 그대로면 실패한 것인가요?","answer":"배포판이나 제조사 패키지는 기존 버전에 수정 사항을 반영할 수 있습니다. 패키지 변경 이력에서 두 CVE의 반영 여부를 확인하세요."},{"question":"memory_limit=-1은 이번 대응에서 금지되는 설정인가요?","answer":"이번 취약점의 공식 임시 권고에는 해당 설정이 포함됩니다. 일반적인 운영 권고와 구분해야 합니다. 요청 제한과 자원 관리 대책을 함께 검토하세요."},{"question":"파일 업로드가 없는 사이트도 대상인가요?","answer":"업로드 기능이 없다는 이유만으로 대상에서 제외할 수 없습니다. PHP 자체의 취약점이므로 사용 버전과 패치 상태를 확인하세요. 불필요한 multipart 요청 차단은 임시 조치입니다."},{"question":"PHP 8.1 이하에 업체 패치가 있으면 계속 사용해도 되나요?","answer":"업체 패치는 정규 지원 종료와 별도로 확인해야 합니다. 해당 패치를 임시 적용하더라도 지원 버전 전환 계획을 세우세요."},{"question":"로그에서 이상이 없으면 인증정보를 유지해도 되나요?","answer":"로그만으로 정보 유출이 없었다고 판단할 수 없습니다. KISA는 패치 전 인터넷에 노출된 서버의 인증정보 교체를 권고합니다. 침해 흔적이 있으면 반드시 교체하세요."},{"question":"침해가 의심되는데 업데이트를 먼저 해야 하나요?","answer":"먼저 네트워크에서 격리하세요. 신고와 증거 확보 후 업데이트를 진행하세요. 재시작하면 메모리에 남은 공격 흔적이 사라질 수 있습니다."},{"question":"호스팅 이용자는 무엇을 확인해야 하나요?","answer":"업체에 서비스별 패치 적용 근거를 요청하세요. 재시작과 실제 웹 실행 환경의 확인 결과도 요청하세요. 로그 점검과 인증정보 교체 여부는 별도로 확인하세요."},{"question":"패치 후 업로드 진행률 설정을 다시 켜도 되나요?","answer":"PHP의 2026년 10월 23일 추가 공지를 확인하세요. 일부 설정 조합의 추가 문제 때문에 기능 비활성화 유지가 권고됩니다. 설정 복원은 후속 수정 사항을 확인한 뒤 판단하세요."}],"sources":[{"url":"https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026menuNo=205020\u0026nttId=72230","title":"KISA 보호나라: PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙, 2026년 10월 22일","type":"source"},{"url":"https://www.php.net/archive/2026.php","title":"PHP 2026년 공지: 10월 21일 보안 업데이트와 10월 23일 Session upload progress 추가 안내","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w","title":"PHP 보안 권고: RCE via OOM corruption","type":"source"},{"url":"https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp","title":"PHP 보안 권고: RCE via stale global state","type":"source"},{"url":"https://www.php.net/supported-versions.php","title":"PHP Supported Versions: 공식 지원 기간","type":"data_point"},{"url":"https://www.php2shell.com/","title":"PHP2Shell: 연구진의 취약점 설명과 영향 범위","type":"source"},{"url":"https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074\u0026mCode=C010010000\u0026nttId=12588","title":"개인정보보호위원회: PHP 보안 취약점 관련 개인정보 유출 예방조치 당부, 2026년 10월 22일","type":"source"}],"images":[{"id":2106,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.","caption":"침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존해야 합니다.","description":null},"en":{"alt":"A woman holds a blue Ethernet cable connector near a rack server’s network port in a server room.","caption":"If a compromise is suspected, isolate the server and preserve evidence before restarting.","description":null},"ja":{"alt":"サーバールームで、女性がラックサーバーのネットワークポートの前に青いLANケーブルのコネクターを持っている。","caption":"侵害が疑われる場合は、サーバーを隔離し、再起動前に証拠を保全する必要があります。","description":null},"es":{"alt":"Una mujer sostiene el conector de un cable Ethernet azul junto al puerto de un servidor en una sala de servidores.","caption":"Si se sospecha una intrusión, hay que aislar el servidor y preservar las pruebas antes de reiniciarlo.","description":null},"id":{"alt":"Seorang perempuan memegang konektor kabel Ethernet biru di dekat port jaringan server rak di ruang server.","caption":"Jika dicurigai terjadi penyusupan, isolasi server dan amankan bukti sebelum memulai ulang.","description":null},"pt":{"alt":"Uma mulher segura o conector de um cabo Ethernet azul perto da porta de um servidor em uma sala de servidores.","caption":"Se houver suspeita de invasão, isole o servidor e preserve as evidências antes de reiniciá-lo.","description":null},"zh-hant":{"alt":"一名女子在伺服器機房內，手持藍色網路線接頭，靠近機架式伺服器的網路埠。","caption":"若懷疑遭到入侵，應先隔離伺服器，並在重新啟動前保全證據。","description":null},"de":{"alt":"Eine Frau hält den Stecker eines blauen Netzwerkkabels vor den Netzwerkanschluss eines Rackservers.","caption":"Bei Verdacht auf einen Angriff muss der Server isoliert und müssen vor dem Neustart Beweise gesichert werden.","description":null}}},{"id":2107,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습","caption":"PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스에 패치가 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"An older technician checks a tablet status screen beside an open network equipment cabinet in a factory.","caption":"After restarting PHP services, verify that the patch has taken effect on the live web service.","description":null},"ja":{"alt":"工場で、開いたネットワーク機器盤の横にあるタブレットの状態画面を確認する年配の技術者","caption":"PHP実行サービスの再起動後、実際のWebサービスにパッチが反映されていることを確認してください。","description":null},"es":{"alt":"Un técnico mayor revisa una tableta junto a un armario abierto con equipos de red en una fábrica.","caption":"Tras reiniciar los servicios de PHP, compruebe que el parche se haya aplicado al servicio web en producción.","description":null},"id":{"alt":"Teknisi senior memeriksa layar status tablet di samping kabinet perangkat jaringan yang terbuka di pabrik.","caption":"Setelah memulai ulang layanan PHP, pastikan patch telah diterapkan pada layanan web yang beroperasi.","description":null},"pt":{"alt":"Um técnico mais velho verifica um tablet ao lado de um armário aberto com equipamentos de rede numa fábrica.","caption":"Após reiniciar os serviços PHP, confirme que a correção foi aplicada ao serviço web em produção.","description":null},"zh-hant":{"alt":"一名年長技術人員在工廠內，查看開啟的網路設備櫃旁平板電腦上的狀態畫面","caption":"重新啟動 PHP 執行服務後，應確認實際運作的網頁服務已套用修補程式。","description":null},"de":{"alt":"Ein älterer Techniker prüft ein Tablet neben einem offenen Netzwerkschrank in einer Fabrik.","caption":"Prüfen Sie nach dem Neustart der PHP-Dienste, ob der Patch im laufenden Webdienst wirksam ist.","description":null}}},{"id":2108,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzOTUsInB1ciI6ImJsb2JfaWQifX0=--dacb7fe617f3f237c4c74b415c08756ecf82ee8b/ai-bd9f0440.webp","is_representative":false,"generation_method":"ai_infographic","license":"ai_generated","mime_type":"image/webp","width":1024,"height":1536,"visible_locales":["ko"],"translations":{"ko":{"alt":"서버 사용 현황 확인부터 침해 여부별 대응, 패치, 서비스 재시작, 로그 점검과 인증정보 교체까지 정리한 흐름도","caption":"패치만으로 기존 침해가 해결되지는 않으므로 과거 로그를 점검하고 노출된 서버의 인증정보를 교체해야 합니다.","description":null},"en":{"alt":"Server security flowchart covering inventory, compromise checks, patching, restarts, log review and credential rotation","caption":"Patching alone does not resolve an existing compromise; review past logs and rotate credentials on exposed servers.","description":null},"ja":{"alt":"サーバーの使用状況確認から侵害の有無による対応、パッチ適用、再起動、ログ確認、認証情報変更までのフロー図","caption":"パッチ適用だけでは既存の侵害は解消されないため、過去のログを確認し、露出したサーバーの認証情報を変更する必要があります。","description":null},"es":{"alt":"Diagrama de seguridad de servidores: inventario, intrusiones, parches, reinicio, revisión de registros y credenciales","caption":"Aplicar parches no resuelve por sí solo una intrusión previa; hay que revisar los registros y cambiar las credenciales de los servidores expuestos.","description":null},"id":{"alt":"Bagan keamanan server: inventarisasi, pemeriksaan penyusupan, patch, mulai ulang, tinjauan log, dan penggantian kredensial","caption":"Patch saja tidak mengatasi penyusupan yang sudah terjadi; periksa log terdahulu dan ganti kredensial server yang terekspos.","description":null},"pt":{"alt":"Fluxograma de segurança de servidores: inventário, invasões, patches, reinício, revisão de logs e troca de credenciais","caption":"Aplicar patches não resolve por si só uma invasão anterior; é preciso revisar os logs e trocar as credenciais dos servidores expostos.","description":null},"zh-hant":{"alt":"伺服器安全應變流程圖，涵蓋使用情況盤點、依入侵跡象分流、修補、重新啟動、日誌檢查與憑證更換","caption":"僅套用修補程式無法解決既有入侵，仍須檢查過往日誌，並更換暴露伺服器的驗證憑證。","description":null},"de":{"alt":"Ablaufplan zur Serversicherheit: Bestandsaufnahme, Einbruchsprüfung, Patches, Neustart, Logprüfung und Zugangsdatenwechsel","caption":"Patches allein beheben keinen bestehenden Einbruch; frühere Logs müssen geprüft und Zugangsdaten exponierter Server ersetzt werden.","description":null}}}],"published_at":"2026-10-24T16:09:48+09:00","updated_at":"2026-10-24T16:09:48+09:00","license":"cc_by","translation_status":"original","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/ko/articles/php2shell-enterprise-security-patch-response-guide"}