PHP 보안 점검, PHP2Shell 대응 체크리스트

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• PHP2Shell은 PHP 실행 환경의 두 취약점을 가리키며 실제 영향은 버전과 구성에 따라 달라집니다.

• 북한 연계 공격 준비는 CYFIRMA의 분석으로, 해당 조직의 대규모 침해가 확정됐다는 뜻은 아닙니다.

• 운영자는 적용 버전과 구성을 확인하고 패치·로그 점검·복구 준비를 함께 진행해야 합니다.

북한 연계가 의심되는 해커들이 PHP 취약점을 이용해 전 세계 웹 서버를 노리고 있다는 소식이 나왔습니다. 전자신문의 10월 24일 보도는 보안업체 사이퍼마(CYFIRMA)가 포착한 공격 준비 정황을 전하며, 한국의 정부기관과 금융기관도 표적으로 거론됐다고 설명했습니다. 북한 해킹조직 라자루스와의 연관성이 제기됐지만, 직접적인 연결이 확인된 단계는 아닙니다.

이런 뉴스를 보면 서비스 운영자는 “우리 회사 홈페이지도 PHP를 쓰는데 괜찮을까?”부터 걱정하게 됩니다. 화면이 평소처럼 잘 열리더라도 서버에 보안 업데이트가 적용됐는지는 따로 확인해야 하는데요. 이번에 알려진 PHP2Shell은 특정 조건에서 외부인이 로그인 없이 서버에서 코드를 실행할 수 있는 취약점이기 때문입니다. PHP 개발팀은 관련 보안 업데이트와 대응 조건을 안내하고 있습니다.

다만 PHP로 만든 모든 서비스가 같은 위험에 놓이는 것은 아닙니다. 실제로 사용하는 PHP 버전과 서버 구성, 패치 적용 여부에 따라 확인할 내용이 달라집니다. 오늘은 PHP2Shell의 북한 연계 분석이 어디까지 확인됐는지 짚고, 서비스 운영자가 개발사나 호스팅 업체와 함께 확인할 PHP 보안 점검 체크리스트를 정리해보겠습니다.

1. 북한 연계 분석과 실제 영향 범위

보안업체 CYFIRMA는 한국어를 쓰는 운영자의 비공개 채널 활동과 작전 양상 등을 근거로 북한 연계 캠페인을 평가했습니다. 보고서는 북한 국가 연계 판단에는 높은 신뢰도를, Lazarus 연관성에는 중간 신뢰도를 표시하기도 합니다. 이를 근거로 북한의 소행이 확정됐다고 말하면 분석의 범위를 벗어납니다.

같은 보고서는 해당 행위자의 대규모 침해와 실명 피해 조직을 확인하지 않았다고 밝힙니다. 공격 준비·스캔과 침해 성공은 다른 상태입니다. 근거와 확인하지 못한 범위를 구분해 읽고 싶다면 CYFIRMA의 PHP2Shell 위협 보고서의 확인·평가 항목을 함께 살펴보세요.

두 취약점의 동작은 무엇이 다른가요?

CVE-2026-109618은 메모리 부족 처리 과정에서 불완전한 요청 데이터가 정리될 때 문제가 생깁니다. CVE-2026-109619는 해제된 요청의 상태가 작업 프로세스에 남아 다음 요청에서 사용되는 결함입니다. 후자는 같은 프로세스가 요청을 이어 처리하는 방식과 설정·애플리케이션 동작이 영향을 줍니다.

실행 방식도 확인 대상입니다. Apache mod_php와 PHP-FPM을 같은 조건으로 판단하지 말고 실제 웹 요청을 처리하는 환경을 조사해야 합니다. PHP-FPM도 특정 경로에서 영향을 받을 수 있으므로 이름만 보고 제외하면 안 됩니다. 조건별 기술 설명은 PHP 개발팀의 메모리 부족 취약점 공지와 잔존 상태 취약점 공지를 참고해 보세요.

2. 버전 확인과 패치 체크리스트

홈페이지뿐 아니라 관리자 화면, 오래된 이벤트 사이트, 컨테이너와 내장 솔루션도 목록에 넣습니다. 각 항목에는 패치 담당자와 확인 근거를 함께 남기세요. 외주사나 호스팅 업체가 관리한다면 “조치했습니다”라는 답만 받기보다 적용 패키지와 재시작 여부를 요청하는 편이 좋습니다.

PHP 공식 배포본의 두 취약점 수정 버전은 아래와 같습니다. 배포판의 백포트 패치를 쓰는 환경은 버전 문자열이 그대로일 수 있으므로 공급자 공지와 패키지 변경 이력을 대조합니다.

설치 완료와 적용 완료는 다릅니다

터미널의 php -v만으로 웹 서비스의 패치 적용을 확정하지 마세요. 여러 버전이 설치된 서버에서는 웹 서비스가 다른 실행 파일을 사용할 수 있습니다. 테스트 후 업데이트하고 모든 PHP 작업 프로세스를 재시작하거나 새 컨테이너로 재배포한 뒤 실제 사용 버전을 다시 확인합니다.

즉시 패치가 어렵다면 취약점별 임시 조치를 구분해야 합니다. 파일 업로드 진행률 비활성화는 확인된 세션 경로를 줄이지만 모든 변형을 막지는 못합니다. PHP 8.5의 추가 설정도 다른 계열에 그대로 적용할 항목이 아닙니다. 공식 PHP 보안 공지의 설정 조건을 담당자가 검토하고, 외부 접근 제한과 패치 일정을 함께 정해야 합니다. 임시 설정이나 WAF만으로 대응 완료로 처리하지 않습니다.

• 서버·컨테이너·내장 제품별 PHP 버전과 실행 방식을 기록했나요?

• 공급자 패치에 두 CVE가 모두 포함됐는지 확인했나요?

• 업데이트 후 이전 프로세스가 남지 않았는지 확인했나요?

• 로그인·업로드 등 주요 기능과 운영 오류를 다시 점검했나요?

3. 로그와 침해 의심 시 대응 순서

패치를 마쳤더라도 패치 이전의 침해 가능성은 따로 살펴야 합니다. 비정상 요청 뒤 서버 오류나 프로세스 종료가 이어졌는지, 웹 서버가 명령 실행 도구를 띄웠는지 살펴봅니다. 웹·업로드 폴더의 낯선 PHP 파일, 예상하지 않은 외부 연결도 점검 대상입니다. 한 가지 흔적만으로 침해를 확정하거나, 로그가 조용하다는 이유로 안전하다고 판단하지 않습니다.

KISA는 최소 10월 20일 이후 기록과 가능하면 그 이전 기록까지 살필 것을 권고합니다. 패치 전 인터넷에 노출된 서버의 중요 인증정보 교체도 안내하고 있습니다. 점검할 로그와 신고 절차는 KISA 기업 보안 대응 수칙에서 구체적으로 살펴보실 수 있습니다.

침해가 의심되면 증거부터 보존해야 합니다

의심 서버는 외부 연결을 차단해 격리하고 대응 담당자에게 알립니다. 바로 전원을 끄거나 재시작하면 메모리의 흔적이 사라질 수 있으므로 로그·프로세스·연결 정보를 먼저 보존합니다. 침해가 의심될 때는 일반 패치 절차와 순서를 구분하고, 조사 결과에 따라 패치·웹셸 제거·인증정보 교체를 진행합니다.

운영 복구를 준비할 때는 백업의 정상 여부도 확인합니다. 다음 항목은 취약점 탐지 조건과 별개인 복구 준비 사항입니다. 백업이 있다는 사실만으로 복구 가능하다고 표시하지 말고, 격리된 환경에서 복원하고 점검한 결과를 남겨 두세요.

• 의심 시점 이전의 백업과 설정 기록을 보관하고 있나요?

• 복원 환경에도 수정된 PHP와 필요한 보안 설정이 적용되나요?

• 재연결 전에 변경 파일·계정·외부 연결을 확인할 담당자가 있나요?

• 백업 이후의 정상 데이터 변경분을 대조할 방법이 있나요?

운영 환경과 유지보수 범위를 함께 살펴봅니다

똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 기획·개발·운영 경험을 갖고 있습니다. 서비스 운영을 이어가려면 현재 시스템과 관리 주체를 이해하고 변경 범위와 확인 항목을 연결해 두어야 합니다.

운영 중인 서비스의 관리 담당이나 개선 범위가 불분명하신가요? 유지보수와 시스템 개선 범위를 정리하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요.

감사합니다. :)

📚 이어서 읽어보세요

• 서비스 운영 로그, 고객 문의를 추적하는 방법

• 서비스 데이터 이전, 검수와 전환 기준 정하기