마침내 사이트가 돌아왔습니다.
2026 년 10 월 22 일 밤 9 시 45 분.
장시간 사용하지 못했던 거래처 사이트가 드디어 다시 열렸습니다. 관리 화면에 로그인도 확인되었습니다.
야, 결국 돌아왔어.
안도했다. 하지만 아직 일은 끝나지 않았다. 사이트 표시가 정상으로 돌아온 후에도 확인해야 할 사항이 남아있었기 때문이다.
저는 레이즈 주식회사에서 AI 개발과 사이버 보안 업무를 수행하고 있습니다. 이번에는 본사 서버와 거래처의 사이트 및 업무 시스템을 병행하여 점검하게 되었습니다.
이것은 거래처가 사이버 공격을 받았다고 단정하는 피해 보고서가 아닙니다. 갑작스러운 심각한 보안 문제에 대해 우리 측이 어떻게 대응했는지에 대한 이야기입니다.
그런데 'PHP2Shell'이란 무엇인가요?
PHP 는 서버 내부에서 홈페이지나 웹 시스템을 구동하는 소프트웨어입니다. 워드프레스도 PHP 를 사용합니다.
PHP 본체에 심각한 결함이 발견되었습니다. 이번에는 'PHP2Shell'이라는 이름으로 불리며, 두 가지 중대한 취약점이 존재합니다. 특정 조건에서는 로그인하지 않은 외부 사용자가 서버에서 불법적인 명령을 실행할 수 있습니다.
사이트의 변조 또는 정보 유출의 위험이 있습니다. 또한, WordPress 나 플러그인만 업데이트한다고 해결되지 않습니다. 그 아래에서 작동하는 PHP 본체 자체를 수정해야 합니다. PHP 공식 주의보 (https://www.php.net/archive/2026.php#2026-10-21-5)
또 하나의 사례를 들면, 저는 이 문제의 발견과 실제 공격이 성립할지 여부를 검증하는 연구에 AI 가 사용되었다는 사실을 강력하게 반발했습니다.
연구팀의 보고서 (https://www.wiz.io/blog/php2shell-php-rce) 에 따르면, AI 가 복잡한 취약점 분석과 공격 기법 검증에 도움을 주었다는 내용이 담겨 있습니다. AI 와 보안 분야를 모두 업무로 삼고 있는 저에게 이는 충격이었습니다.
AI 의 발전이 일상적인 유지보수나 고객 업무에 직접적인 영향을 미친다는 점을 이번 대응을 통해 체감했습니다.
사실 발표 당일 PHP 를 업데이트했습니다.
한 날 전으로 이야기를 되돌립니다.
10 월 21 일 오전에 미리 계획했던 거래처 사이트의 PHP 업데이트를 완료하고, 제공업체에서 업데이트를 적용받아 이후 동작을 확인했습니다.
화면 표시와 관리 화면을 확인하고 구매 여부도 확인했습니다. 문의 사항도 단순히 전송 가능한 것을 넘어 상대방에게 실제로 도달했는지까지 확인했습니다.
그 날 밤, PHP2Shell 수정안이 공개되었습니다.
방금 업데이트했으니 괜찮다'라고는 할 수 없었다.
오전 업데이트와 그 이후에 발표된 보안 패치는 별도로 확인해야 합니다. 업데이트 날짜만으로 안심할 수 없으며, 이번 문제를 해결한 PHP 가 실제로 사용되고 있는지 다시 점검해야 합니다.
분노한 파도의 대응. 우리가 실제로 한 일
먼저, 본사와 거래처에서 사용하고 있는 사이트와 시스템을 파악했습니다.
회사 홈페이지, 온라인 스토어, 블로그, 업무 앱은 소속 회사나 계약처, 실행 중인 서버가 다를 수 있습니다. 하나만 확인한다고 해서 모두 해결되는 것은 아닙니다.
자신들이 직접 업데이트할 수 있는 항목, 서비스 제공자가 수정하는 항목, 제공자에게 문의해야 하는 항목을 각각 정리하고 가능한 작업부터 진행했습니다.
비즈니스 앱에서는 업데이트 전 데이터와 설정을 백업한 후 PHP 를 수정 버전으로 전환했습니다. 업데이트 후에는 실제 실행 중인 PHP 와 설정, 관리 화면 및 주요 화면을 확인했습니다.
이번 주와 그 전후로 진행 중인 보안 개선 작업도 있었습니다. WordPress 플러그인 업데이트, 접근 제한, 작업 기록 관리가 이루어졌으며, 대상 사용자의 비밀번호 변경과 이메일로 확인 코드를 받는 두 단계 인증도 진행되었습니다.
다만, 두 단계 인증을 추가한다고 PHP2Shell 을 막을 수 있다는 것은 아닙니다. PHP 자체 수정과 관리 화면 인증 강화는 각각 필요한 작업으로 진행되었습니다.
확인 절차를 어렵게 만든 것이 PHP 버전 표시였습니다.
자사 서버를 운영 중인 업체는 표시되는 번호를 변경하지 않고 수정 프로그램을 탑재해 있었습니다. 오래된 번호가 표시되더라도 반드시 수정되지 않았다는 뜻은 아닙니다. 제공元の 대응 완료 공지 (https://www.onamae.com/news/article/11594)
따라서 제공元の 완료 안내, 자체 계약 플랜, 실제 사이트를 구동 중인 PHP 상태를 교차 검증했습니다. 다른 환경에서는 제공元の 이번 2 건 수정 완료에 대한 답변을 받았습니다.
한편, 긴급 유지보수 중인 사이트에서는 해당 페이지에서 조작할 수 없는 시간이 길어졌습니다. 그 사이에도 안내를 따라가며 재개 후 확인해야 할 화면과 기능을 정리했습니다.
그리고 22 일 밤, 초기 복원 확인에 이어졌습니다. 다음 날에도 공개 페이지와 관리 화면 등을 계속 점검했습니다.
하지만 보안을 강화하면……
다음 날 거래처에서 연락이 왔다.
잠시 후 영어 오류가 발생하며, 주문 변경 시 경고가 표시됩니다.
여기서 확인을 계속 진행하더라도 평소 업무 흐름에서 활용하면 다른 문제가 드러날 수 있습니다.
영어 표시는 로그인 인증 기한이 만료되었을 때 안내되는 내용입니다. 안전을 위해 작업을 중단하더라도 그 이유와 다음 단계를 알 수 없다면 사용자는 곤란에 빠질 수 있습니다.
이에 따라 상황을 일본어로 설명하고 로그인 화면으로 돌아가는 버튼을 추가했습니다. 인증 유지 시간도 거래처의 사용 방식과 요구 사항을 확인하여 조정했습니다.
주문 화면의 경고는 다른 원인이었습니다. 자유롭게 입력할 수 있는 상품 항목에도 불구하고, 이미 등록된 상품을 검색하는 처리가 실행되어 찾지 못했다는 오류가 발생했습니다.
필요 없는 검색을 수정하고, 입력된 상품명, 금액 및 합계 계산이 정확히 유지되는지 확인했습니다. 경고 메시지를 제거하는 것뿐만 아니라, 필요한 처리가 올바르게 남아있는지도 검증했습니다.
마지막으로 실제 사용자에게 직접 조작을 받아보았습니다. 주문 수정 및 저장 모두 문제없다는 답변을 받으며, 이번 수정을 마무리로 삼았습니다.
보안을 강화한다고 해서 그것이 끝이 아닙니다.
매일 사용하는 사람들이 망설임 없이 업무를 계속할 수 있도록 확인하는 것도 대응 측의 업무라고 생각합니다.
이번에 가장 느낀 점
사이트가 열리는 것과 안전한 것은 다릅니다.
수정이 적용되었다고 해서 과거에 공격받지 않았다는 뜻은 아니며, 수정이 확인되더라도 과거의 침해가 없었음을 단정할 수는 없습니다.
무엇을 확인했는지, 무엇을 아직 알지 못하는지, 누구의 답변을 기다리는지. 이를 모호하게 하지 않고 하나씩 기록해야 한다.
시스템 보호와 업무 중단은 모두 중요하며, 특히 긴급 상황에서는 업무 중단 여부를 결정할 수 있어야 합니다. 이후 어떻게 확인하고 어떻게 재개할지 미리 고려해 두어야 합니다.
AI 를 통해 복잡한 취약점을 식별하고 검증하는 능력이 높아지고 있습니다. 방어 측에도 최신 정보를 신속히 파악하고, 자체 환경에 적용한 후 필요한 대응을 추진할 수 있는 역량이 요구됩니다.
우리는 현장에서 조사, 수정, 이용자 설명, 작동 확인까지 확실하게 차근차근 수행해 나가고 싶습니다.
본사의 홈페이지는 괜찮을까요?
그 확인을 누가 하고 있는 걸까.
전문 용어를 몰라도 제작사나 유지보수 담당자에게 문의할 수 있습니다.
우리 사이트가 이번 문제의 대상인가요? 필요한 수정 사항도 이 사이트에도 적용되나요? 아직 확인되지 않은 부분이 있으신가요?
이번 경험을 바탕으로 기업용「PHP2Shell 확인 10 가지 항목」을 공개했습니다. 대상 사이트 식별부터 업데이트 전후 점검, 결과 기록까지 한 권에 정리했습니다.
먼저, 회사 사이트의 URL 을 함께 첨부해 주시고 평소 담당자에게 문의해 보아 주세요. 그 답변을 기록해 두는 것이 다음 조치 방향을 결정하는 단서가 될 것입니다.
PHP2Shell, 우리 회사는 안전한가요? 홈페이지 및 온라인 스토어 확인 10 가지 항목 (https://security.raise-co.net/articles/php-vulnerability-checklist.html)
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 45청크
원문 보기 | 출처: note.com