PHP2Shell의 두 번호(CVE‑2026‑109618, CVE‑2026‑109619)는 긴급 사안으로 처리해야 합니다. 공격자는 어떤 계정이나 비밀번호도 필요 없이, 공인 인터넷에 노출된 서비스에 접근할 수만 있다면 곧바로 당신의 서버에서 명령을 실행할 수 있습니다. 대응 순서는 다음과 같이 권장합니다. 먼저 자신이 영향을 받는 범위에 있는지 확인하고, 그다음 패치를 적용할지 임시 완화를 먼저 적용할지 결정하며, 마지막으로 반드시 검증하고 로그를 재점검해야 합니다. 아래에서 실행 가능한 순서대로 나누어 설명합니다.
첫 번째 단계: 30분 이내에 실제로 영향을 받는지 판단하기
무작정 사이트 전체를 중단하지 말고, 먼저 세 가지를 통해 노출 면을 파악하세요.
1. 버전 확인. 서버에 로그인하여 `php -v`를 실행하고, 컨테이너 이미지 tag, `composer.lock`, 패널에서 전환한 PHP 버전을 확인하세요. 많은 기업 웹사이트가 오래된 7.x를 운영하고 있는데, 운영팀은 업그레이드했다고 생각하지만 실제로는 다른 환경이 돌아가고 있는 경우가 많습니다.
2. 노출 면 확인. 외부 관점에서 한 번 스캔하세요. 어떤 도메인/IP의 80, 443, 8080 포트가 공인 인터넷에 직접 개방되어 있는지, 테스트 환경, 구버전 관리자 페이지, 임시로 오픈한 인터페이스를 닫지 않았는지 확인하세요. 내부망에서 접근 가능하다고 해서 안전한 것은 아닙니다. 측면 이동은 대개 여기서 시작됩니다.
3. 트리거 경로 확인. 공식 공지에서 제시한 영향을 받는 컴포넌트와 진입점을 대조하여, 당신의 라우트, 업로드 인터페이스, 역직렬화 진입점, 템플릿 렌더링 지점이 포함되는지 확인하세요. 판단할 수 없다면 "영향 받음"으로 처리하는 것이 비용이 더 낮습니다.
결과를 표로 정리하세요. 도메인, PHP 버전, 공인 인터넷 여부, 영향을 받는 컴포넌트 포함 여부, 담당자. 이 표는 이후 검증과 회고에 모두 사용됩니다.
두 번째 단계: 패치를 적용할 수 있다면 패치를 적용하고, "설정 변경"으로 업그레이드를 대체하지 마세요
패치가 유일한 근본 해결 수단이며, 임시 완화는 시간을 벌어줄 뿐입니다.
- 먼저 스테이징에서 검증. 운영 환경에서 바로 업그레이드하는 것은 위험이 매우 높습니다. 특히 수년간 운영된 기업 웹사이트는 확장과 프레임워크 버전이 서로 얽혀 있습니다. 스테이징에서 핵심 경로를 한 번 실행하세요. 로그인, 주문/폼 제출, 결제 콜백, 파일 업로드.
- 의존성 순서대로 업그레이드. 먼저 런타임을 올리고, 그다음 프레임워크와 서드파티 라이브러리를 올리며, 마지막으로 비즈니스 코드에서 폐기된 호출을 처리하세요. 업그레이드 후 `composer update`를 실행하면 lock 파일을 다시 생성하여 커밋해야 합니다.
- 롤백 경로 유지. 업그레이드 전에 스냅샷을 찍거나 이전 이미지 tag를 남기고, 롤백 명령을 명확히 기록하세요. 롤백 계획 없는 업그레이드는 본질적으로 도박입니다.
- 주의: 한 대만 업그레이드하고 완료를 선언하지 마세요. 로드 밸런서 뒤에는 종종 손대지 않은 서버가 몇 대 더 있으며, 공격자가 노리는 것은 바로 빠뜨린 그 서버입니다.
비즈니스가 외주로 제작되어 소스 코드를 받을 수 없다면, 먼저 원 개발사에 버전 정보와 패치 계획을 요청하세요. 받을 수 없다면 다음 섹션의 임시 방안으로 우선 버티세요.
세 번째 단계: 패치를 적용할 수 없을 때의 임시 완화, 우선순위대로 실행
완화 조치는 "악용 확률을 낮추는 것"이지 "수리된 것"이 아니므로, 반드시 일정표에 기한을 정해 업그레이드해야 합니다.
1. 노출 면 축소: 관리자 백엔드, 디버그 인터페이스, 테스트 환경을 공인 인터넷에서 제거하고 내부망 접근 또는 IP 화이트리스트로 변경하세요. 이 항목이 효과가 가장 크고 비용이 가장 낮습니다.
2. 전면 차단: WAF 또는 Nginx 계층에서 공지에 제시된 특징에 대한 규칙 차단을 적용하고, 동시에 업로드 디렉터리의 실행 권한을 제한하세요(`php_flag engine off` 또는 이에 상응하는 설정).
3. 권한 낮춰 실행: 웹 프로세스를 root로 실행하지 말고, 파일 디렉터리에서 불필요한 쓰기 권한을 제거하며, `disable_functions`에서 닫을 수 있는 위험 함수를 닫으세요.
4. 모니터링 추가: 비정상 자식 프로세스, 외부 연결, 업로드 디렉터리 내 새로 나타난 실행 파일에 대해 경보를 설정하세요.
주의: WAF 규칙만 추가하고 코드를 변경하지 않는 것은 규칙 라이브러리에 목숨을 맡기는 것과 같습니다. 공격자가 인코딩 방식을 바꾸면 우회될 수 있으므로, 완화 기간에는 매일 한 번 차단 로그를 확인해야 합니다.
네 번째 단계: 수정 후 반드시 검증, 그렇지 않으면 수정하지 않은 것과 같습니다
많은 팀이 패치를 적용하고 마무리하지만, 구 프로세스가 여전히 실행 중인 경우가 있습니다.
- PHP-FPM과 웹 서비스를 재시작하고, `php -v`가 모든 노드에서 새 버전인지 확인하세요.
- 외부 스캔 도구로 원래 트리거 경로를 재테스트하여, 반환값이 더 이상 악용 가능한 상태가 아님을 확인하세요.
- 로그 재점검: 취약점 공개부터 수정 사이의 시간 창 내에 비정상 POST, 의심스러운 업로드, 비정상 외부 연결이 있었는지 확인하세요. 있다면 단순 패치가 아니라 침해 사건으로 처리해야 합니다.
- 크론 작업, SSH 공개 키, 새로 추가된 계정을 확인하여 백도어가 남아 있지 않은지 점검하세요.
구체적인 시나리오 예시: 모 기업 웹사이트 개편 기간에 디자이너용으로 파일 업로드 인터페이스를 임시로 열어두고 닫는 것을 잊었는데, 마침 영향을 받는 버전에 해당했습니다. 이러한 "임시 인터페이스"는 취약 지대이므로, 개편 마무리 시 "임시 진입점 정리 체크리스트"가 있어야 합니다.
어떤 경우 MIC Studio에 의뢰하는 것이 적합한가
다음과 같은 상황이라면 직접 버티는 것의 비용 효율이 낮습니다.
- 소스 코드가 외주 업체에 있어 버전 정보를 명확히 알 수 없고 패치 계획을 세울 수 없는 경우;
- 사이트가 많고 환경이 복잡하여 어떤 것이 공인 인터넷에 있고 어떤 것이 영향 범위에 있는지 구분하기 어려운 경우;
- 패치 후 보안 테스트와 역방향 테스트를 한 차례 더 수행하여 잔여 진입점과 백도어가 없는지 확인하고 싶은 경우;
- 겸사겸사 노후 시스템을 재구축하여 웹사이트 개발, 미니프로그램 개발 또는 App 개발의 기술 스택을 유지보수 가능한 버전으로 통일하고 싶은 경우.
MIC Studio는 기업 웹사이트, 미니프로그램, App 및 스크립트 개발을 수행하며, 웹사이트 보안 테스트와 역방향 테스트도 수행합니다. "먼저 지혈, 그다음 검증, 마지막 재구축" 순서로 협력할 수 있습니다. 모든 문제를 외주로 해결해야 하는 것은 아니며, 직접 패치를 적용할 수 있다면 먼저 패치를 완료하는 것이 더 중요합니다.
마무리: 오늘 바로 할 수 있는 세 가지
1. 오늘 목록 작성: 공인 인터넷에서 접근 가능한 모든 PHP 환경을 나열하고 버전과 담당자를 표시하세요. 기억에 의존하지 마세요.
2. 48시간 이내 업그레이드 또는 완화 완료: 업그레이드할 수 있으면 업그레이드하고, 불가능하면 노출 면을 제거하고 차단을 추가하며 기한을 명시하세요.
3. 증거 보존: 업그레이드 전후로 로그를 각각 백업하고, 수정 후 시간 창 내의 비정상 요청을 재점검하여 침해되지 않았음을 확인하세요.
자주 묻는 질문
내부망에서만 사용하는데 수정해야 하나요?
필요합니다. 내부망은 격리 구역이 아니며, 직원 단말, 테스트 머신, 서드파티 접속이 모두 발판이 될 수 있습니다. 공인 인터넷에 노출된 것을 우선 수정하고, 내부망은 동일한 유지보수 창에서 함께 처리하세요.
WAF 규칙을 적용했으니 업그레이드하지 않아도 되나요?
과도기적 조치로만 가능합니다. 규칙은 특징 매칭에 의존하므로 우회 비용이 높지 않고, 규칙 유지보수 자체에 사람이 붙어 있어야 합니다. WAF를 지혈대로 보고 업그레이드를 수술로 보세요. 둘은 서로 대체할 수 없습니다.