PHP 취약점 2건, CISA 악용 목록에 등재…패치 적용 시점도 점검

취약점은 프로그램의 약점이고, 패치는 그 약점을 고친 프로그램입니다. KEV 수록은 약점이 존재한다는 설명에서 더 나아가 실제 악용 근거가 확인됐다는 운영상의 신호입니다. 공격에 쓰인 모든 방법이나 피해 대상이 목록에 공개되는 것은 아닙니다.

두 결함은 서버가 요청을 처리하는 동안 메모리나 이전 요청의 내부 상태를 잘못 다루는 문제입니다. 공격자가 영향을 주는 요청이 취약한 처리 경로에 도달하면, 서버의 PHP 프로세스 권한으로 코드를 실행하는 피해로 이어질 수 있습니다. 구체적인 도달 조건은 서버 구성과 처리 경로에 따라 달라집니다. 메모리 부족 처리 결함 · 남은 내부 상태 결함

가령 가상의 호스팅사 A에서 취약한 PHP로 사이트를 운영한다고 해 봅시다. 공격자가 보낸 웹 요청이 결함을 일으키는 조건에 도달하면, 사이트 운영자가 의도하지 않은 명령이 PHP의 권한으로 실행될 수 있습니다. 그 권한으로 읽거나 바꿀 수 있는 파일에는 정보 노출·변조 위험이 생기고, 사이트가 멈출 수도 있습니다. 이는 원격 코드 실행의 피해를 설명하는 가상 사례이며, 모든 서버의 파일이나 계정 전체를 장악했다는 뜻은 아닙니다.

PHP는 WordPress 같은 사이트의 서버 처리를 맡습니다. 서버에서 요청을 받아 일하는 실행 단위를 워커라고 부릅니다. 설치 파일을 내려받았어도 기존 워커가 계속 옛 프로그램을 사용한다면, 새 패키지를 보유했다는 사실만으로 적용이 끝나지는 않습니다.

아래는 패치 적용을 증명하기 위해 이어 봐야 할 기록입니다. 특정 업체나 사이트의 현재 완료 상태를 그린 것이 아닙니다.

%% 패치 적용의 확인 경로 · PHP 개발팀과 운영자의 역할
flowchart TD
  A["개발팀: 수정판 공개"] --> B["공급자: 패키지 제공"]
  B --> C["운영자: 웹 PHP에 반영"]
  C --> D["적용 버전·시각 기록"]

이번 두 결함의 최초 공식 수정판은 다음과 같습니다. 이후 버전이나 공급자 백포트를 쓴다면, 두 수정이 포함됐다는 해당 배포판의 근거를 대조해야 합니다. PHP 공식 변경 기록

백포트는 고친 내용을 기존 계열의 패키지에 옮기는 작업입니다. 화면의 버전 숫자가 같아도 패키지 개정이 다를 수 있어, 공급자의 수정 이력과 실제 웹 실행 환경의 적용을 함께 봅니다. WordPress 본체나 플러그인의 업데이트는 서버 PHP 패키지를 대신 고치지 않습니다. 실제 교체는 백업 확보, 테마·플러그인 호환성 및 시험 환경 점검, 적용 후 로그인·주요 기능 확인을 담당자와 계획합니다. WordPress의 서버 PHP 업데이트 안내

패치를 적용하면 같은 약점을 이용한 이후 공격을 막는 데 도움이 됩니다. 그러나 그전에 무슨 일이 있었는지는 과거 운영 기록으로 조사해야 합니다. CISA는 외부에 공개된 시스템을 우선 패치하고, PHP 프로세스의 셸 실행이나 도구 다운로드 같은 의심 활동을 살피라고 권고합니다.

담당자는 “우리 사이트가 외부에 열린 때부터, 수정된 웹 PHP가 실제 요청을 처리하기 시작한 때까지”를 기록으로 이어 봅니다. 아래 기준점은 수정판의 발표일이나 파일 다운로드 시각이 아니라, 해당 사이트의 실제 반영을 확인한 시각입니다. 각 구간에 어떤 기록이 필요한지 함께 표시했습니다.

로그에 특이 사항이 없더라도 수집하지 않은 경로나 기간까지 조사한 것은 아닙니다. 개발팀도 오류 로그가 없다는 이유만으로 안전하다고 판단하지 말라고 설명합니다. 의심 징후가 있다면 담당 보안팀이나 호스팅 지원팀과 조사 범위를 정하고 기록을 보존할 필요가 있습니다.