HomeTech한얼닷컴도 피하지 못한 Global PHP Security Vulnerability

한얼닷컴도 피하지 못한 Global PHP Security Vulnerability

지난 약 3주간 사이트에 접속하실 수 없었던 점에 대해 진심으로 사과드립니다. 그 이유는 PHP Security Vulnerability.

10월 하순, 전 세계 수많은 웹사이트가 사용하는 프로그래밍 언어인 PHP에서 매우 심각한 보안 취약점이 발견되었습니다. 이 취약점은 별도의 로그인 없이도 외부에서 서버를 장악할 수 있을 만큼 위험한 것으로 알려졌고, 실제 공격 사례도 빠르게 보고되었습니다. 저희 사이트 역시 PHP를 기반으로 운영되고 있어 영향을 받을 수 있는 상황이었습니다.

당시 저는 해외에 머물고 있어 즉시 조치를 취하기 어려웠습니다. 사이트와 독자 여러분의 정보를 보호하는 것이 무엇보다 중요하다고 판단하여, 근본적인 조치가 가능할 때까지 사이트 운영을 잠시 중단하기로 결정했습니다.

보안 문제를 겪은 사이트가 할 수 있는 선택은 두 가지입니다. 조용히 고치고 아무 일 없었던 것처럼 넘어가거나, 무엇이 있었는지 먼저 말하는 것입니다. 저희는 후자를 택했습니다.

숨기는 쪽이 더 위험한 이유는 분명합니다. 이번 PHP 보안 취약점은 특정 사이트의 관리 실수로 생긴 문제가 아니라 PHP라는 언어 자체의 결함이었습니다. 한얼닷컴만의 문제가 아니라, 독자분들이 매일 들어가는 한인 커뮤니티 사이트, 교회 홈페이지, 동네 가게 예약 페이지 상당수가 같은 조건에 놓여 있었다는 뜻입니다. 저희가 입을 닫으면 그 사이트들을 확인해볼 계기도 함께 사라집니다.

이 글에서는 이번 PHP 보안 취약점이 무엇이었는지, 한얼닷컴이 PHP 8.2.35로 올라오기까지 실제로 어떤 작업이 있었는지, 아직 남아 있을 수 있는 문제에 대해 왜 미리 양해를 구하는지 순서대로 정리합니다.

PHP Security Vulnerability가 정확히 무엇이었는가

이번 사태의 공식 명칭은 CVE-2026-109618과 CVE-2026-109619입니다. 보안 업계에서는 PHP2Shell이라는 이름으로 더 많이 불립니다. 두 건 모두 CVSS v4.0 기준 9.2점으로, 10점 만점에서 9점대는 Critical 등급입니다. 실무에서는 사실상 가장 높은 경보 수준입니다.

기술적으로는 PHP 엔진이 요청을 처리하다가 메모리가 부족해지는 순간을 악용합니다. 내부 구조가 절반만 완성된 상태에서 정리 코드가 그 깨진 데이터를 정상인 것처럼 처리하면서 공격자의 코드가 실행됩니다. 결과는 RCE(Remote Code Execution, 원격 코드 실행)입니다. 로그인조차 필요하지 않습니다. 보안업체 Sansec의 분석에 따르면 문제가 된 코드는 2012년 PHP 5.4.0까지 거슬러 올라갑니다. 14년 가까이 같은 자리에 있었던 셈입니다.

규모도 문제였습니다. 영향을 받는 버전은 PHP 5.4부터 8.5.11까지 전부입니다. Palo Alto Networks의 Cortex Xpanse는 외부에 노출된 취약 가능 인스턴스를 2,260만 개 이상으로 집계했습니다. W3Techs 기준으로 서버 언어가 확인된 웹사이트의 약 70%가 PHP를 쓰니, 사실상 웹의 절반 이상이 같은 문턱에 서 있었습니다.

대응 속도도 이례적이었습니다. PHP 측은 10월 21일 패치 버전을 공개했고, 미국 CISA는 10월 26일 두 CVE를 Known Exploited Vulnerabilities(실제 악용이 확인된 취약점) 목록에 올렸습니다. FBI는 즉시 업데이트가 어렵다면 해당 시스템을 아예 오프라인으로 내리라고 권고했습니다. CISA의 공식 권고문에는 Apache mod_php와 PHP-FPM을 포함해 웹 요청을 처리하는 모든 PHP 구동 방식이 영향권이라고 명시되어 있습니다.

WordPress를 업데이트해도 막히지 않았던 이유

이 부분은 놓치기 쉬운데, 이번 문제는 WordPress나 플러그인의 결함이 아닙니다. 취약한 코드는 WordPress가 로딩되기 전, PHP 엔진이 웹 요청을 받아들이는 자리에서 실행됩니다. 그래서 WordPress 코어와 플러그인을 전부 업데이트해도 구멍은 그대로 남습니다. 서버의 PHP 런타임 자체를 교체하지 않으면 해결되지 않습니다.

반대로 말하면, 사이트 쪽 코드가 아무리 깔끔해도 안전하지 않았다는 뜻입니다. Sansec은 Magento, Shopware, WooCommerce 기반 쇼핑몰도 자체 코드와 무관하게 영향을 받았다고 정리했습니다. 한얼닷컴도 플러그인 관리 부실이 아니라 PHP를 쓰는 모든 사이트가 공유한 조건 때문에 노출됐습니다. 다만 그렇다고 패치를 적용하기까지 걸린 시간에 대한 책임이 사라지는 것은 아닙니다.

PHP 8.2.35 업그레이드가 예상보다 오래 걸린 이유

패치 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35 네 가지였고, 한얼닷컴은 8.2.35를 택했습니다. 최신인 8.5 계열로 한 번에 올리는 선택지도 있었지만, 수년간 쌓인 커스텀 코드를 생각하면 같은 메이저 계열 안에서 패치 버전만 올리는 쪽이 사이트가 멈출 위험이 훨씬 낮았습니다. 보안 패치를 적용하다가 사이트가 죽으면 그것도 결국 사고입니다.

문제는 같은 계열 안의 업그레이드라도 손이 많이 간다는 점입니다. PHP 8 계열은 문자열과 배열 처리가 훨씬 엄격해서, 예전에는 경고만 띄우고 넘어갔던 코드가 이제는 fatal error(치명적 오류)로 페이지 전체를 흰 화면으로 만듭니다. 중괄호로 문자열의 특정 위치를 꺼내 쓰던 옛 문법은 아예 제거됐습니다. 수년에 걸쳐 덧붙인 코드에는 이런 자리가 생각보다 많습니다.

플러그인 쪽은 더 번거로웠습니다. 업데이트가 멈춘 지 오래된 플러그인은 PHP 버전이 올라가는 순간 그대로 깨집니다. WPML이나 Toolset 같은 플러그인 개발사 포럼에는 PHP 8.2로 올린 뒤 결제 페이지나 번역 페이지가 죽었다는 보고가 수년간 쌓여 있습니다. 표준 대응은 플러그인을 전부 끈 뒤 하나씩 다시 켜면서 원인을 찾는 방식인데, 수십 개면 이 작업만으로 긴 시간이 들어갑니다.

솔직히 가장 오래 걸린 쪽은 플러그인이 아니라 자체 수정 부분이었습니다. 테마 파일이나 기능에 직접 손을 댄 흔적은 기록에 남지 않는 경우가 많습니다. 어디를 왜 고쳤는지 모르는 상태에서 PHP 버전이 바뀐 뒤 그 코드가 조용히 잘못된 값을 돌려주면 에러 로그에도 잡히지 않습니다. 결국 몇 군데는 눈으로 하나씩 확인하는 수밖에 없었습니다. 마지막으로 PHP-FPM과 웹서버를 재시작해 기존 워커 프로세스가 구 버전 바이너리를 계속 쓰지 않도록 하는 것까지가 작업의 끝입니다. 이 단계를 빼먹고 패치를 마쳤다고 믿는 사례가 생각보다 흔합니다.

아직 남아 있을 수 있는 문제들

현재 한얼닷컴은 PHP 8.2.35에서 정상 동작하고 있고 주요 기능은 모두 확인을 마쳤습니다. 다만 완료라고 단언하지는 않겠습니다. 이런 작업에서 남는 문제는 대개 사용 빈도가 낮은 자리에 숨어 있습니다. 오래된 글의 이미지가 뜨지 않거나, 특정 기기에서 레이아웃이 어긋나거나, 댓글이나 검색이 특정 조건에서만 반응하지 않는 식입니다.

그래서 이상한 점을 발견하시면 알려주시는 것이 가장 빠른 해결입니다. 어느 페이지에서, 어떤 기기나 브라우저로, 무엇을 하려다 막혔는지 세 가지만 적어 보내주시면 재현이 훨씬 수월합니다. 불편을 드린 부분에 대해 양해를 부탁드립니다. 독자분들이 한얼닷컴을 열어둔 채로 글을 읽으신다는 사실이 이번 작업의 우선순위를 정한 기준이었습니다.

독자가 지금 당장 확인해야 할 필수 3가지

첫째, 본인이나 가족이 운영하는 사이트가 있다면 호스팅 업체에 PHP 버전을 직접 확인하십시오. 보안업체 CleanTalk는 배포판이 패치를 백포트하면 버전 숫자만으로는 판단이 어렵다며, 수정이 적용됐다는 확인을 문서로 받아두라고 권고합니다. 8.5.12, 8.4.27, 8.3.36, 8.2.35 가운데 하나인지 숫자로 확인하는 것이 가장 확실합니다.

둘째, PHP 8.1 이하를 쓰고 있다면 선택지가 사실상 없습니다. 8.1과 그 이전 계열에는 공식 패치가 나오지 않습니다. 이 경우는 패치가 아니라 버전 이전을 계획하셔야 합니다. 한인 소상공인 사이트 중에는 제작 후 몇 년째 손대지 않은 경우가 많아 이 조건에 걸릴 가능성이 작지 않습니다.

셋째, 이번 PHP 보안 취약점은 공격이 성공하면 서버에서 명령을 실행할 수 있게 해주고, 데이터베이스 접근도 가능한 범위에 들어갑니다. 평소 여러 사이트에 같은 비밀번호를 쓰고 계셨다면 이번 주에 바꾸시는 쪽을 권합니다. 비밀번호 재사용은 이번 사건과 무관하게 가장 흔한 2차 피해 경로입니다.

자주 묻는 질문

  1. 한얼닷컴에서 제 개인정보가 유출됐나요?

    현재까지 침해 흔적은 발견되지 않았습니다. 이번 PHP 보안 취약점은 서버에서 코드를 실행할 수 있게 해주는 종류였기 때문에 데이터베이스 접근도 이론상 가능한 범위에 들어가지만, 로그 점검 결과 실제 악용 흔적은 확인되지 않았습니다. 다만 여러 사이트에 같은 비밀번호를 쓰고 계셨다면 이번 기회에 바꾸시는 것을 권합니다.

  2. PHP 보안 취약점은 어떤 버전으로 올려야 안전한가요?

    2026년 10월 21일 공개된 8.5.12, 8.4.27, 8.3.36, 8.2.35 가운데 하나여야 합니다. 한얼닷컴은 8.2.35를 적용했습니다. PHP 8.1 이하 계열에는 공식 패치가 나오지 않으므로, 그 버전을 쓰고 있다면 패치가 아니라 버전 이전을 계획해야 합니다.

  3. WordPress와 플러그인을 전부 업데이트했는데 왜 안전하지 않다고 하나요?

    취약한 코드가 WordPress보다 아래 단계인 PHP 엔진에 있기 때문입니다. PHP가 웹 요청을 받아들이는 시점, 즉 WordPress가 로딩되기도 전에 실행되는 자리라서 WordPress 쪽을 아무리 최신으로 올려도 구멍은 남습니다. 서버의 PHP 자체를 패치 버전으로 올려야 해결됩니다.

  4. 호스팅 업체가 알아서 패치해줬는지 어떻게 확인하나요?

    업체에 PHP 버전 숫자를 직접 물어보시고, 패치 적용 여부를 문서나 이메일로 받아두시는 것이 가장 확실합니다. 패치 적용 뒤 PHP-FPM이나 웹서버를 재시작하지 않으면 기존 프로세스가 구 버전을 계속 쓰기 때문에, 재시작까지 완료됐는지도 함께 확인하시는 편이 좋습니다.

정리하며

이번 PHP 보안 취약점은 개별 사이트의 관리 부실이 아니라 웹 전체가 공유한 기반의 결함이었고, 한얼닷컴도 그 영향권 안에 있었습니다. PHP 8.2.35 업그레이드는 마쳤고 주요 기능은 정상입니다. 남은 문제가 하나도 없다고는 말씀드리지 못합니다.

보안은 사고가 없을 때는 보이지 않고, 사고가 난 뒤에만 평가받습니다. 그래서 운영자가 실제로 선택할 수 있는 것은 사고를 완전히 없애는 것이 아니라, 사고가 났을 때 무엇을 했고 무엇이 남았는지 먼저 말하는 쪽입니다. 독자분들의 데이터와 시간을 다루는 사이트라면 그 정도는 공개하는 것이 기본이라고 생각합니다.

예고 없이 사이트가 중단되어 불편을 드린 점 다시 한번 사과드립니다. 그리고 그동안 변함없이 기다려 주시고 관심을 보내 주신 모든 분께 진심으로 감사드립니다. 앞으로도 좋은 글로 보답하겠습니다.

혹시 최근 한얼닷컴에서 이전과 다르게 작동하는 부분을 보셨다면 댓글로 남겨주시겠습니까? 그리고 운영 중인 사이트의 PHP 버전을 확인해보셨다면 어떤 숫자가 나왔는지도 알려주시면 좋겠습니다.

RELATED ARTICLES

Most Popular