简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

PHP에서 '인터넷 규모'의 고위험 취약점이 폭로됐는데, Web3의 '오프체인 약점'은 어떻게 보완해야 할까?

이 글을 읽으려면 26 분

PHP에서 CVSS 9.2점 원격 코드 실행 취약점 두 개를 긴급 수정했으며, 5.4부터 8.5.11 버전까지 영향을 받습니다. 세부 내용이 사전에 유출되었고 이미 악용되고 있습니다. 암호화폐 업계 도메인 약 53%가 PHP를 사용하므로 Web3 플랫폼은 가능한 한 빨리 업그레이드해야 합니다.

원문 제목: 《PHP, '인터넷급' 고위험 취약점 발생, Web3의 '오프체인 약점'은 어떻게 보완해야 하나?》
원문 저자: SlowMist 보안팀

무슨 일이 있었나

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)로 앞당겨 발표했습니다.

더욱 경계해야 할 점은 공격이 공개보다 더 일찍 발생했을 수 있다는 것입니다. Amazon 위협 인텔리전스 팀은 10월 17일에 자사의 MadPot 허니팟 네트워크에서 php2shell을 겨냥한 익스플로잇 시도를 관찰했다고 보고했으며, 이는 공개披露보다 나흘 앞선 것입니다.

SlowMist도 PHP 공식 예고 발표 후 즉시 보안 경고와 권고를 발송했습니다.

두 취약점은 각각 무엇인가

CVE-2026-109618 (OOM 메모리 손상): PHP 메모리가 고갈되면 처리 흐름이 중단되는데, 이때 보유한 데이터는 절반만 준비된 상태입니다. 마무리 정리 시 PHP는 이 반제품을 완전한 데이터로 사용하여 결과적으로 메모리가 엉망이 됩니다.

CVE-2026-109619 (오래된 전역 상태): 하나의 요청 처리가 완료되어 메모리는 이미 해제되었지만 관련 상태는 '그 자리에 남아' 있습니다. 동일한 워커 프로세스가 다음 요청을 인계받을 때 정상 초기화 전에 이 만료된 상태를 사용할 수 있습니다. 공식은 이를 통해 PHP-FPM을 공격하고 원격 코드 실행을 달성할 수 있음을 확인했습니다.

공격 경로를 보면, 이런 취약점이 위험한 이유는 공격자가 먼저 사이트 계정을 탈취할 필요도 없고, 비즈니스 계층의 로그인, 권한 또는 API Key 검증을 뚫을 필요도 없다는 점입니다. 공용 인터넷에 노출된 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를 사용합니다. WordPress, WooCommerce, Magento 같은 익숙한 시스템들도 그 밑바탕은 모두 PHP입니다.

각국의 반응도 문제를 보여줍니다. 네덜란드 국가사이버보안센터는 예방적으로 웹사이트를 폐쇄했고, 한국 대통령실은 긴급 사이버보안 회의를 소집했으며, 정부는 사이버보안 경보 수준을 상향했습니다.

또한 보도에 따르면, 북한의 거의 모든 공식 웹사이트가 공식 미디어와 정부 포털 사이트를 포함해 24시간 이상 오프라인 상태이며, 현재 이 취약점 사건과 관련이 있는지는 아직 알려지지 않았습니다.

Web3에 대한 영향

이것은 전통적인 웹사이트 운영 관리만의 문제가 아닙니다. Web3의 경우, 온체인 컨트랙트에 취약점이 없더라도 컨트랙트를 둘러싸고 작동하는 수많은 '오프체인环节'—프론트엔드 페이지, API, 커스터디 지갑, 서명 서비스, 에어드롭 수령 페이지, 운영 백오피스 및 데이터 서비스—중 상당수가 PHP(WordPress, WooCommerce, Magento 등)로 구축되어 있습니다. 컨트랙트 자체에 취약점이 없다고 해서 이러한环节이 안전하다는 뜻은 아닙니다.

SlowMist의 위협 인텔리전스 시스템 MistEye 통계에 따르면, 스캔한 암호화폐 업계 관련 도메인 1488개 중 793개가 직접적인 PHP 지문을 가지고 있어 약 53.3%에 해당합니다. 강조하건대, 이는 PHP를 사용했다는 것만을 의미할 뿐, 해당 웹사이트에 취약점이 있거나 이미 공격당했다는 뜻은 아닙니다.

1. 플랫폼 측: 몇 가지 전형적인 리스크 경로

프런트엔드가 변조되어 사용자가 서명을 유도되는 경우.

DeFi, 지갑类 웹사이트 또는 에어드롭 페이지의 서버가 장악되면, 공격자는 페이지 내 RPC 주소, 승인 대상, 컨트랙트 주소 또는 서명 프롬프트를 교체하여 정상 거래를 악성 승인, 악성 컨트랙트 상호작용 또는 가짜 입금 절차로 바꿀 수 있습니다. 공격자는 컨트랙트를 공격할 필요 없이 사용자가 직접 악성 승인에 서명하도록 만들면 됩니다.

키와 자격 증명 유출.

서버가 장악된 후 공격자는 설정 파일, 데이터베이스 비밀번호, API Token, 환경 변수 등을 읽을 수 있습니다. 백엔드가 PHP로 노드 RPC 또는 핫월렛 서비스와 연동되는 경우, API Key와 세션 토큰이 유출되면 핫월렛 자산 이전 또는 서명 권한 남용으로 확대될 수 있습니다.

백오피스와 API가 탈취되는 경우.

거래 플랫폼, NFT 마켓, 크로스체인 브리지, 결제 게이트웨이 및 노드 서비스 제공업체는 일반적으로 운영 백오피스와 KYC/리스크 관리 인터페이스, 입금 주소 할당, 출금 심사, 티켓 시스템 등을 갖추고 있습니다. 공격자가 권한을 획득하면 설정을 변조하거나, 사용자 데이터를 탈취하거나, 고권한 계정을 생성하거나, 비즈니스 프로세스를 우회할 수 있습니다.

공급망 횡적 이동.

PHP 프로세스의 권한은 일반적으로 서버의 최고 권한과 같지 않지만, CI/CD 키, 컨테이너 런타임 socket, 데이터베이스 자격 증명 또는 클라우드 액세스 토큰을 읽을 수 있다면 공격 범위가 단일 웹 노드에서 데이터베이스, 빌드 시스템, 나아가 전체 프로덕션 계정으로 확장될 수 있습니다.

결제 플러그인과 제3자 서비스.

알려진 바에 따르면 Binance Pay, Crypto.com Pay, BitPay, CoinGate, CoinPayments 등 암호화폐 결제 솔루션은 모두 WooCommerce 통합을 갖추고 있어 서버가 패치되지 않으면 심각한 노출 위험이 있습니다. RPC, 블록 탐색기, 데이터 분석 플랫폼 등 제3자 서비스도 백오피스나 운영 시스템이 영향을 받은 PHP 환경에서 실행되는 경우 진입점이 될 수 있습니다. 물론 RPC 노드, 스마트 컨트랙트, 블록 탐색기 및 지갑 자체는 본질적으로 PHP에 의존하지 않으며, 구체적인 제품의 기술 스택에 따라 달라집니다.

하지만 주의해야 할 점은 서버가 침해되었다고 해서 온체인 자산이 반드시 도난당하는 것은 아니라는 것입니다. 웹 서비스 침해에서 실제 자금 손실로 이어지기까지는 공격자가 민감한 자격 증명, 서명 프로세스, 관리 권한 또는 사용자 상호작용环节에 접근할 수 있는지 여부를 따져봐야 합니다. 핫월렛이 웹 계층과 격리되어 있는지, 키가 HSM/KMS에 보관되어 있는지, 권한이 최소화되어 있는지가 손실의 상한을 직접 결정합니다.

2. 일반 사용자: 코인을 출금해야 할까?

필요 없습니다.

이유는 간단합니다:

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

웹사이트를 탐색하고 지갑을 연결하는 것은 개인키 유출과는 다른 문제입니다. 취약점 자체만으로는 사용자의 지갑이나 서명을 직접 해킹할 수 없습니다.

어떤 프로젝트가 PHP를 사용했을 수 있다고 해서 이미 사고가 발생했다는 의미는 아닙니다. 모든 거래 플랫폼이 이미 침해되었다고 가정할 이유가 없으며, 그렇다고 모든 자산을 출금할 필요도 없습니다. 사용자가 진짜 경계해야 할 것은 자신이 방문하는 웹사이트가 이미 침해되었는지 여부입니다. 사용자는 웹사이트에 패치가 적용되었는지 판단할 수 없으므로, 이번 사건은 교훈이 됩니다: 웹사이트 인터페이스를 맹목적으로 신뢰하지 마십시오. 공격자는 여론의 열기를 이용해 가짜 로그인 페이지, 가짜 보상 페이지, 악성 지갑 연결 요청을 유포할 수도 있습니다.

프로젝트 공식 측이 웹사이트나 백엔드 침해를 확인한 경우, 공지에서 공개된 실제 영향에 따라 상호작용 중단 여부, 비정상 거래 확인, 의심스러운 승인 철회 여부를 판단해야 합니다. 서명 개인키나 니모닉이 유출된 것이 확인된 경우에는 키 유출 사건으로 처리해야 하며, 비밀번호 변경이나 웹사이트 연결 해제만으로는 부족합니다. 거래 봇, 자동화 실행 도구 또는 클라우드 배포 서비스를 사용하는 사용자도 해당 서비스가 영향을 받은 버전이나 자격 증명 교체 공지를 발표했는지 주의해야 합니다.

대응 방법

1. 플랫폼과 프로젝트 측:

첫 번째 단계: 현황 파악, 신속한 업그레이드

모든 공용 및 내부 네트워크의 PHP 자산을 점검하십시오: 호스트, 컨테이너 이미지, Kubernetes 워크로드, 레거시 CMS, 관리 백엔드, 파트너 호스팅 환경, 서드파티 플러그인 및 호스팅 서비스. 기술 지문은 단서로만 활용할 수 있으며, '취약점 확인'의 결론으로 직접 사용해서는 안 됩니다.

8.2.35 / 8.3.36 / 8.4.27 / 8.5.12로 업그레이드하거나, 배포판, 클라우드 사업자, 호스팅 서비스 제공업체가 제공하는 동등한 패치를 적용하십시오. 8.1 및 이전 버전을 사용하는 경우 공급업체에 백포트를 요청하거나 가능한 한 빨리 마이그레이션해야 합니다. 「구 환경이 안정적이다」「애플리케이션이 자주 업데이트되지 않는다」는 이유로 이 취약점의 위험을 낮출 수 없습니다.

업그레이드 후 컨테이너 이미지를 재빌드하고, 롤링 재시작 또는 모든 PHP 워커 프로세스를 교체하며, 빌드 머신이나 명령줄의 버전이 아닌 온라인에서 실제로 요청을 처리하는 런타임 버전을 확인하십시오.

2단계: 당장 업그레이드할 수 없다면 어떻게 해야 하나

먼저 노출 면을 줄여 시간을 확보하되, 이는 패치를 대체할 수 없습니다:

공인 인터넷에 노출된 PHP 애플리케이션을 격리하거나, 진입 계층에 네트워크 인증과 접근 제어를 추가하십시오.

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

일부 보안 권고에는 memory_limit=-1 설정, session.upload_progress.enabled 비활성화, PHP 8.5에서는 추가로 fatal_error_backtraces 비활성화도 포함됩니다. 이러한 설정은 비즈니스와 가용성에 부작용이 있으므로 먼저 테스트해야 하며, 변경할 때마다 모든 PHP 워커를 재시작해야 합니다.

3단계: 침해 여부를 확인하고 자격 증명을 정리하십시오

공인 인터넷에 노출된 적이 있는 영향을 받은 서비스에 대해 로그, 터미널 모니터링, 비정상 네트워크 연결을 결합하여 조사하십시오. 예를 들어 PHP 프로세스가 갑자기 시스템 명령을 실행하는 경우입니다. 침해가 의심되면 먼저 증거를 보존한 후 사고 대응 절차에 따라 처리하십시오.

최악의 상황을 가정하십시오: 적시에 패치되지 않은 서버의 경우 API 키, 세션 키, TLS 인증서, 데이터베이스 비밀번호, 클라우드 액세스 토큰, CI/CD 자격 증명, RPC/API Key, Webhook 키 및 타사 Token을 교체하고 비정상 사용 기록이 있는지 확인하십시오.

환경에 오염된 것으로 확인된 소프트웨어 버전이 설치되었거나 실행된 적이 있다면, 단순히 업그레이드하거나 재설치하는 것만으로는 위험이 제거되었다고 할 수 없습니다. 자격 증명 유출과 지속성 백도어를 추가로 조사하고, 필요한 경우 깨끗한 환경을 재구축하십시오.

4단계: 자산 통제 영역 사수

PHP 패치는 유일한 조치여서는 안 됩니다. 더욱 중요한 것은 "웹 서버 한 대가 침해당해도 자금 시스템에 영향을 미치지 않도록" 보장하는 것입니다:

핫월렛, 집금 월렛, 핵심 서명 서비스의 개인키를 웹 노드에서 완전히 격리하십시오. HSM, MPC, 전용 서명 네트워크 또는 최소 권한의 KMS 정책을 사용하십시오.

웹 서비스, 서명 서비스, 온체인 노드, 데이터베이스, 빌드 시스템을 서로 다른 네트워크 세그먼트와 신원 경계에 배치하십시오.

사건 발생 기간 동안 출금, 주소 화이트리스트 변경, 관리자 권한 상승, API Key 생성, 리스크 관리 규칙 수정 등 고위험 작업을 일시적으로 강화하고, 필요 시 수동 검토 또는 지연 적용을 활성화하십시오.

온체인에서 자동 실행되는 서비스는 업무 특성에 따라 독립 서명, 다중 서명 승인, 거래 한도 제한, 긴급 중단 메커니즘을 적용할 수 있습니다.

웹사이트 정적 리소스, JavaScript 패키지, 리버스 프록시 설정, DNS/CDN 규칙, 거래 구성 서비스를 점검하여 악성 스크립트가 삽입되거나 교체되지 않았는지 확인하십시오.

2. 일반 사용자:

정식 경로 이용: 최근에는 북마크나 공식 채널을 통해 플랫폼에 접속하고, "보안 사건"을 명목으로 발송된 링크에 주의하십시오.

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

서명 전 항목별 확인: 수신 주소, 소속 체인, 승인 한도, 호출된 컨트랙트, 거래 시뮬레이션 결과를 확인하십시오. 특히 approve와 setApprovalForAll에 주의하고, 무한 한도 승인은 더욱 신중해야 합니다.

"보상", "마이그레이션", "재검증" 경계: 사건 기간 동안 "재로그인", "월렛 재검증", "자산 마이그레이션", "보상 수령" 등의 안내가 나타날 수 있습니다. 사이트 내 팝업만으로 판단하지 말고 프로젝트 공식의 여러 채널을 통해 교차 검증하십시오.

자산 계층화: 대액 자산은 하드웨어 지갑으로 보관하고, 일상적인 상호작용에는 별도의 한도가 설정된 지갑을 사용하며, 정기적으로 승인을 정리합니다. 이렇게 하면 특정 프런트엔드나 플랫폼에 문제가 생기더라도 단일 손실에 상한이 생깁니다.

이상 징후가 있으면 우선 중단: 비정상적인 서명 요청, 예상치 못한 승인 알림, 또는 웹사이트 동작이 이상할 경우 우선 멈추고 공식 채널을 통해 확인합니다.

마지막으로 하고 싶은 말

PHP2Shell과 같은 로그인 불필요 원격 코드 실행 취약점은 일단 Web 계층을 뚫으면 전통적인 서버 침해가 프런트엔드 오염, 신원 도용, 서명 권한 남용, 핫월렛 리스크, 나아가 공급망 수준의 횡적 침투로 이어질 수 있습니다.

플랫폼 입장에서 가장 우선순위가 높은 일은 세 가지입니다: 패치된 버전으로 업그레이드하고, 당장 패치할 수 없는 노후 환경을 격리하며, 키와 자산 통제면을 감사하는 것입니다. 업그레이드 후에는 침해 징후 조사를 사건 대응의 일부로 삼아야 합니다. 사용자 입장에서는 이 기간 동안 페이지 인터페이스에 대한 맹목적 신뢰를 줄이고, 매번 서명 전에 한 번 더 확인해야 합니다. 다만 과도하게 공포를 느낄 필요는 없습니다: 취약점이 존재한다고 해서 자산이 반드시 위협받는 것은 아니며, 서버가 침해되었다고 해서 반드시 온체인 자금 손실로 이어지는 것도 아닙니다. 실제로 리스크의 크기를 결정하는 것은 공격자가 어떤 자격 증명을 확보할 수 있는지, 그 자격 증명이 얼마나 큰 권한을 가지는지, 그리고 프로젝트가 얼마나 빠르게 이러한 권한을 격리하고 취소할 수 있는지입니다. Web3 프로젝트 입장에서 보안 구축은 공격 발생을 막는 방법을 강구하는 것뿐만 아니라, 특정 구성 요소가 실제로 침해되었을 때 영향을 국소적으로 제한하여 리스크가 핵심 비즈니스와 자산 단계로 확산되지 않도록 할 수 있는지도 고려해야 합니다.