PHP가 '인터넷 수준' 고위험 취약점을 노출, Web3의 '오프체인 약점'은 어떻게 해결해야 할까?

원제: 'PHP, 인터넷 수준 중대 취약점 노출: Web3의 오프체인 약점은 어떻게 보완할 것인가?' 원저자: 슬로우미스트 보안팀

사건 개요

10월 21일, PHP 프로젝트는 CVE-2026-109618 및 CVE-2026-109619 두 가지 치명적 취약점을 해결하기 위한 긴급 보안 업데이트를 발표했다. 이들은 인증 없이 원격 코드 실행(RCE)을 허용하며, CVSS v4.0 기준 위험도는 9.2다. PHP 공식 입장에 따르면, 패치 적용 전까지 외부 웹 서비스를 제공하는 모든 PHP 설치본이 영향을 받을 수 있다.

10월 20일, 취약점 세부 정보가 공식 공개 전 유출되었고, 패치는 아직 배포되지 않았다. PHP 보안팀은 기존 예정일(10월 22일)에서 긴급 릴리스를 10월 21일 14:00(UTC)으로 당겼다.

더 우려되는 점은 공개 이전부터 공격 시도가 있었을 가능성이다. 아마존 위협 인텔리전스 팀은 10월 17일, 자사 MadPot 허니팟 네트워크에서 php2shell을 겨냥한 악용 시도를 관측했으며, 이는 공개보다 4일 앞선 시점이다.

슬로우미스트는 PHP의 사전 공지 직후 즉각적인 보안 경고 및 권고사항을 발표했다.

두 취약점은 무엇인가?

CVE-2026-109618(OOM 메모리 손상): PHP가 메모리 부족 상태에 도달하면 처리 흐름이 중단되고, 현재 데이터는 반만 준비된 상태다. 정리 과정에서 PHP는 이러한 미완성 데이터를 완성된 것으로 간주해 메모리 손상을 유발한다.

CVE-2026-109619(오래된 글로벌 상태): 요청 처리 후 메모리는 해제되지만 관련 상태가 그대로 남아 있다. 동일한 워커 프로세스가 다음 요청을 처리할 때, 정상 초기화 전에 만료된 상태를 재사용할 수 있으며, 이는 PHP-FPM 공격 및 원격 코드 실행으로 이어질 수 있다.

공격 경로 측면에서 이 유형의 취약점은 공격자가 사이트 계정 확보나 비즈니스 계층 로그인·권한·API 키 검증을 우회할 필요 없이, 공개 인터넷에 노출된 PHP 애플리케이션으로 악성 요청을 전송함으로써 웹 서비스 프로세스 권한으로 임의 코드 실행이 가능하다는 점에서 위험하다.

영향 범위: PHP 5.4~8.5.11 버전 모두 해당. 수정된 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35다. PHP 8.1 이하 버전은 정기 지원 종료로 일반 채널을 통한 패치는 기대할 수 없으며, 지지 중인 버전으로의 마이그레이션이 필요하다.

왜 전 세계가 긴장하는가?

PHP가 지나치게 보편적이기 때문이다. W3Techs 통계에 따르면, 서버측 언어를 식별 가능한 웹사이트 중 69.3%가 PHP를 사용한다. 워드프레스, 워쿠머스, 매그엔토 등 익숙한 시스템도 모두 PHP 기반으로 구동된다.

각국의 대응도 문제를 잘 보여준다—네덜란드 국가사이버보안센터(NCSC-NL)는 예방 차원에서 웹사이트를 일시 폐쇄했고, 한국 대통령실은 긴급 사이버보안 회의를 소집하며 정부 사이버보안 경보 수준을 상향 조정했다.

또한 보도에 따르면, 북한의 공식 미디어 및 정부 포털을 포함한 거의 모든 공식 웹사이트가 24시간 이상 오프라인이었으며, 이 사건과의 연관 여부는 아직 확인되지 않았다.

Web3에 미치는 영향

이는 전통적인 웹사이트 운영 및 유지보수에만 국한되는 문제가 아닙니다. Web3 환경에서도 체인 상 계약(온체인 컨트랙트)에 취약점이 없더라도, 계약 실행 주변에 존재하는 다수의 '오프체인 구성요소'—프론트엔드 페이지, API, 예치형 지갑(custodial wallet), 서명 서비스, 에어드롭 수령 페이지, 운영 백엔드, 데이터 서비스 등—는 종종 PHP(WordPress, WooCommerce, Magento 등)로 구축됩니다. 계약 자체에 취약점이 없다고 해서 이러한 구성요소들이 안전하다는 의미는 아닙니다.

슬로우마이스트(SlowMist) 산하 위협 인텔리전스 시스템 미스트아이(MistEye) 통계에 따르면, 분석 대상 1,488개 암호화폐 산업 관련 도메인 중 793개(약 53.3%)에서 직접적인 PHP 식별 정보가 확인되었습니다. 단, 이는 단순히 PHP 사용 여부를 나타낼 뿐, 해당 사이트에 취약점이 있거나 이미 침해당했음을 의미하지 않습니다.

1. 플랫폼 측: 대표적인 위험 경로들

프론트엔드 조작을 통한 사용자 서명 유도

디파이(DeFi), 지갑형 웹사이트 또는 에어드롭 페이지 서버가 침해받을 경우, 공격자는 페이지 상 RPC 주소, 권한 부여 대상, 컨트랙트 주소, 서명 요청 문구 등을 교체할 수 있습니다. 이로 인해 정상 거래가 악성 권한 부여, 악성 컨트랙트 상호작용, 혹은 가짜 입금 절차로 변질될 수 있습니다. 공격자는 컨트랙트 자체를 침해할 필요 없이, 사용자가 악성 권한을 직접 서명하도록 유도하기만 하면 됩니다.

키 및 자격 증명 유출

서버가 침해된 후 공격자는 설정 파일, 데이터베이스 비밀번호, API 토큰, 환경 변수 등을 읽어올 수 있습니다. 백엔드가 PHP를 통해 노드 RPC 또는 핫월렛 서비스에 연결하고 있다면, API 키나 세션 토큰 유출 시 핫월렛 자산 이체나 서명 권한 남용으로 이어질 수 있습니다.

백엔드 및 API 장악

거래소, NFT 마켓플레이스, 크로스체인 브리지, 결제 게이트웨이, 노드 서비스 제공업체 등은 일반적으로 운영 백엔드뿐 아니라 KYC/리스크 관리 인터페이스, 입금 주소 할당, 출금 승인, 티켓 관리 시스템 등을 운영합니다. 공격자가 권한을 확보하면 설정 조작, 사용자 데이터 탈취, 고권한 계정 생성, 업무 프로세스 우회 등이 가능합니다.

공급망을 통한 수평 이동

PHP 프로세스의 권한은 일반적으로 서버 최고 권한과 동일하지 않지만, CI/CD 키, 컨테이너 런타임 소켓, 데이터베이스 자격 증명, 클라우드 접근 토큰 등을 읽을 수 있다면 공격 범위는 단일 웹 노드에서 데이터베이스, 빌드 시스템, 심지어 전체 프로덕션 계정까지 확대될 수 있습니다.

결제 플러그인 및 제3자 서비스

바이낸스 페이(Binance Pay), 크립토닷컴 페이(Crypto.com Pay), 비트페이(BitPay), 코인게이트(CoinGate), 코인페이먼츠(CoinPayments) 등 암호화폐 결제 솔루션은 모두 워드프레스 쇼핑몰(WooCommerce) 연동 기능을 제공하며, 패치되지 않은 서버는 심각한 노출 위험을 안고 있습니다. 또한 RPC, 블록 탐색기, 데이터 분석 플랫폼 등 제3자 서비스의 백엔드나 운영 시스템이 영향 받는 PHP 환경에서 구동된다면 이 역시 침입 경로가 될 수 있습니다. 물론 RPC 노드, 스마트 컨트랙트, 블록 탐색기, 지갑 자체는 본질적으로 PHP에 의존하지 않으며, 실제 기술 스택은 제품별로 달라질 수 있습니다.

다만, 서버가 침해되었다고 해서 반드시 체인 상 자산이 도난당했다는 뜻은 아닙니다. 웹 서비스 침해에서 실제 금융 손실로 이어지기까지는 공격자가 민감한 자격 증명, 서명 프로세스, 관리자 권한 또는 사용자 상호작용 지점에 접근할 수 있는지 여부에 따라 달라집니다. 핫월렛이 웹 계층과 격리되어 있는지, 키가 HSM/KMS에 저장되어 있는지, 권한이 최소화되어 있는지 여부가 잠재적 손실의 상한선을 직접 결정합니다.

2. 일반 사용자: 자산을 인출해야 하나요?

필요 없습니다.

그 이유는 간단합니다:

해당 취약점은 특정 조건을 충족하는 서버 환경에만 영향을 미치며, 모든 사용자의 지갑이 위험에 처했다는 의미는 아닙니다.

웹사이트를 방문하고 지갑을 연결하는 행위는 개인 키 노출과 동일하지 않으며, 취약점 자체가 사용자 지갑이나 서명을 직접 해독할 수 없습니다.

프로젝트가 PHP를 사용한다고 해서 이미 침해당했다는 뜻은 아닙니다. 모든 거래소가 이미 침해당했다고 가정할 근거는 없으며, 더욱이 이 사안만으로 자산 전체를 인출할 이유는 전혀 없습니다. 사용자에게 진정으로 주의해야 할 것은 방문하는 웹사이트가 실제로 침해당했는지 여부입니다. 사용자는 해당 사이트가 패치되었는지 여부를 판단할 수 없으므로, 이번 사건은 ‘웹사이트 인터페이스를 맹신하지 말라’는 경고로 받아들여야 합니다. 공격자는 대중의 관심을 악용해 가짜 로그인 페이지, 가짜 보상 포털, 악성 지갑 연결 요청 등을 유포할 수도 있습니다.

프로젝트가 공식적으로 웹사이트 또는 백엔드가 침해되었음을 확인한 경우, 사용자는 공개된 실제 영향을 기준으로 상호작용 일시 중단 여부, 비정상 거래 여부 점검, 의심스러운 승인 철회 여부를 결정해야 합니다. 서명용 개인 키 또는 시드 문구가 유출되었다면 이는 키 유출 사고로 간주하여 처리해야 하며, 단순히 비밀번호 변경이나 웹사이트 연결 해제만으로는 부족합니다. 트레이딩 봇, 자동 실행 도구, 클라우드 배포 서비스를 사용하는 사용자도 관련 서비스에서 영향을 받은 버전 또는 자격 증명 갱신 공지를 발표했는지 주의 깊게 확인해야 합니다.

대응 방법

1. 플랫폼 및 프로젝트 팀:

첫 번째 단계: 자산 점검 후 즉시 업그레이드

공용 및 내부 네트워크 PHP 자산 전체(호스트, 컨테이너 이미지, 쿠버네티스 워크로드, 구식 CMS, 관리자 백엔드, 파트너 호스팅 환경, 타사 플러그인, 관리형 서비스)를 점검하세요. 기술적 지문은 단서일 뿐이며, 이를 근거로 ‘취약성 확정’이라 단정 지을 수 없습니다.

8.2.35 / 8.3.36 / 8.4.27 / 8.5.12로 업그레이드하거나, 배포사·클라우드 제공업체·관리형 서비스 제공업체가 제공한 동등 패치를 적용하세요. 8.1 이하 버전을 사용 중이라면 공급업체에 백포트 요청을 하거나 가능한 한 빨리 마이그레이션하세요. ‘레거시 환경이 안정적이다’ 또는 ‘애플리케이션이 거의 업데이트되지 않는다’는 이유로 본 취약성 위험이 감소하지 않습니다.

업그레이드 후에는 컨테이너 이미지를 재빌드하고 롤링 재시작을 수행하거나 모든 PHP 워커 프로세스를 교체한 후, 빌드 머신 또는 명령줄 버전이 아닌 실제 프로덕션에서 요청을 처리하는 런타임 버전을 반드시 검증하세요.

두 번째 단계: 당장 업그레이드가 불가능할 경우 대응법

우선 노출 면적을 줄여 시간을 벌되, 이는 패치 대체 수단이 아닙니다:

공용 인터넷에 노출된 PHP 애플리케이션을 격리하거나, 인그레스 계층에서 네트워크 인증 및 접근 제어를 추가하세요.

불필요한 파일 업로드를 비활성화하고, WAF 또는 웹 서버 계층에서 불필요한 multipart/form-data 요청을 차단하세요.

일부 보안 권고에서는 memory_limit=-1 설정, session.upload_progress.enabled 비활성화, PHP 8.5의 경우 추가로 fatal_error_backtraces 비활성화를 포함합니다. 이러한 설정은 비즈니스 및 가용성에 영향을 줄 수 있으므로, 반드시 사전 테스트 후 각 변경 시 모든 PHP 워커를 재시작하세요.

세 번째 단계: 침해 여부 점검 및 자격 증명 갱신

공용 인터넷에 노출된 영향받은 서비스의 경우 로그, 엔드포인트 모니터링, 비정상 네트워크 연결(예: PHP 프로세스가 갑작스럽게 시스템 명령어 실행) 등을 통해 조사하세요. 침해 의심 시 우선 증거를 보존한 후, 사고 대응 절차에 따라 처리하세요.

최악의 상황을 전제로, 패치가 지연된 서버의 경우 API 키, 세션 키, TLS 인증서, 데이터베이스 비밀번호, 클라우드 접근 토큰, CI/CD 자격 증명, RPC/API 키, 웹후크 시크릿, 타사 토큰 등을 모두 갱신하고, 비정상 사용 기록을 점검하세요.

영향을 받은 소프트웨어 버전이 환경에 설치 또는 실행된 경우, 단순 업그레이드나 재설치만으로는 위험이 제거됐다고 볼 수 없으며, 자격 증명 유출 및 지속성 백도어 조사가 필수입니다. 필요 시 깨끗한 환경을 새로 구축하세요.

네 번째 단계: 자산 제어 평면 강화

PHP 패치는 단일 조치가 되어서는 안 됩니다. 더 중요한 것은 ‘웹 서버가 침해되어도 자금 시스템이 함께 무너지지 않도록’ 하는 것입니다:

핫월렛, 수집용 월렛, 핵심 서명 서비스의 개인 키를 웹 노드와 완전히 분리하세요. HSM, MPC, 전용 서명 네트워크 또는 최소 권한 KMS 정책을 활용하세요.

웹 서비스, 서명 서비스, 온체인 노드, 데이터베이스, 빌드 시스템을 서로 다른 네트워크 세그먼트 및 신원 경계로 분리하세요.

사고 발생 시, 인출, 주소 화이트리스트 변경, 관리자 권한 상승, API 키 생성, 리스크 제어 규칙 수정 등 고위험 작업을 일시적으로 강화하고, 필요 시 수동 검토 또는 지연 활성화를 적용합니다.

온체인 자동 실행 서비스의 경우, 업무 요구에 따라 독립 서명, 다중서명 승인, 거래 금액 제한, 비상 정지 메커니즘을 도입합니다.

웹사이트 정적 리소스, JavaScript 패키지, 리버스 프록시 설정, DNS/CDN 규칙, 거래 생성 서비스를 점검해 악성 스크립트 삽입·교체 여부를 확인합니다.

2. 일반 사용자:

공식 진입 경로 이용: 최근에는 북마크나 공식 채널을 통해 플랫폼에 접속하고, '보안 사고'라는 명목으로 전송된 링크는 신중히 대응하세요.

도메인과 인터페이스만 보지 말 것: 익숙한 dApp 도메인이라도 서버 측에서 페이지 스크립트, 거래 파라미터, RPC 설정이 침해자에 의해 교체되었을 수 있습니다.

서명 전 항목별 확인: 수신 주소, 체인, 승인 금액, 호출 계약, 거래 시뮬레이션 결과를 반드시 검증하세요. 특히 approve 및 setApprovalForAll는 각별히 주의하고, 무제한 승인은 더욱 신중히 처리해야 합니다.

'보상', '마이그레이션', '재확인' 유도에 주의: 사고 기간 중 '재로그인', '월렛 재인증', '자산 이전', '보상 청구' 등 안내가 나타날 수 있으나, 사이트 내 팝업만으로 판단하지 말고 프로젝트의 여러 공식 채널로 복수 확인하세요.

자산 계층화: 대규모 보유 자산은 하드웨어 월렛으로 보관하고, 일상 상호작용용으로는 한도가 있는 별도 월렛을 사용하며, 승인 내역을 정기적으로 정리하세요. 이렇게 하면 프론트엔드나 플랫폼이 침해되더라도 단일 손실 규모가 제한됩니다.

의심스러운 상황 시 즉시 중단: 비정상적인 서명 요청, 예기치 않은 승인 팝업, 혹은 의심스러운 웹사이트 동작을 발견하면 우선 중단하고 공식 채널을 통해 검증하세요.

마무리하며

PHP2Shell과 같은 로그인 불필요 원격 코드 실행 취약점은 웹 계층을 넘어선 후, 전통적 서버 침해를 프론트엔드 오염, 신원 모방, 서명 권한 남용, 핫 월렛 위협, 심지어 공급망 차원의 수평 확산까지 초래할 수 있습니다.

플랫폼 입장에서는 세 가지가 최우선입니다: 패치된 버전으로 업그레이드, 현재 패치 불가능한 레거시 환경 격리, 키 및 자산 제어 평면 감사. 업그레이드 후에는 침해 징후 탐색을 사고 대응의 필수 과정으로 간주해야 합니다. 사용자 입장에서는 이 기간 동안 페이지 인터페이스를 덜 맹신하고, 모든 거래 서명 전 추가 확인을 실천하세요. 그러나 과도한 공포는 금물입니다: 취약점 존재는 자산이 반드시 위협받는다는 의미가 아니며, 서버 침해도 체인상 자금 유출을 반드시 수반하지 않습니다. 실제 위험 규모는 공격자가 확보한 자격 증명의 종류, 그 자격 증명이 부여하는 권한 수준, 그리고 프로젝트가 해당 권한을 격리·취소하는 속도에 달려 있습니다. Web3 프로젝트의 보안 구축은 공격을 방지하는 방법을 찾는 것뿐 아니라, 구성 요소가 실제로 침해되었을 때 영향을 지역적으로 제한해 핵심 비즈니스 및 자산 운영으로의 확산을 막을 수 있는지 고민하는 것을 포함합니다.

원문 링크