PHP 취약점 공개 후 GitHub에 공격 코드 확산…안랩, 저장소 100개 분석

PHP 취약점 공개 직후 GitHub에 관련 저장소 급증

안랩은 2026년 10월 22일 13시 30분 기준 GitHub에서 'php2shell'을 검색해 상위 100개 저장소를 분석했다. 분석 대상에서는 포크(Fork) 저장소를 제외했으며, 저장소 이름과 설명, 토픽 등 공개된 정보를 기준으로 관련성과 용도를 분류했다.

분석 결과 100개 중 99개가 CVE-2026-109618 및 CVE-2026-109619와 관련된 내용을 다루고 있는 것으로 나타났다.

특히 분석 대상 저장소 100개 중 96개가 10월 21일에 생성됐다. 시간대별로는 15시(UTC)에 19개가 생성돼 가장 높은 수치를 기록했다.

보고서에 따르면 방어 관련 저장소가 먼저 등장했으며, 공격 PoC 관련 저장소는 시간이 지날수록 증가하는 양상을 보였다. 초기 관련 저장소 중에는 10월 18일 생성된 Corelight의 탐지 규칙 저장소가 포함됐고, 공격 PoC로 분류된 저장소 중에서는 10월 20일 생성된 dinosn의 저장소가 가장 빨랐다.

이러한 결과는 중대 취약점 공개를 전후해 공격 가능성을 검증하거나 보안 대응 정보를 공유하려는 움직임이 단기간에 집중됐음을 보여준다.

다만 이번 분석은 수집된 저장소의 공개 정보를 기준으로 한 것으로, 저장소 생성 추이가 실제 공격 발생 현황을 의미하는 것은 아니다.

방어 도구가 더 많았지만, GitHub 관심은 공격 PoC에 집중

안랩은 분석 대상 저장소 100개를 목적에 따라 방어, 공격, 기타 유형으로 분류했다.

그 결과 방어 관련 저장소가 46개로 가장 많았고, 공격 관련 저장소는 36개, 기타 유형은 18개로 나타났다.

방어 관련 저장소에서는 취약점 점검 도구가 23개로 가장 많았다. 이어 완화·패치 도구 17개, 탐지 규칙 및 침해지표(IoC) 관련 저장소 6개가 확인됐다.

공격 관련 저장소는 PoC·익스플로잇 27개와 취약 환경 재현 도구 9개로 구성됐다. 기타 유형은 기술 분석·정보 제공 4개, 용도 판단 불가 13개, 검색어만 일치하는 무관한 저장소 1개로 분류됐다.

그러나 GitHub 사용자들의 관심도는 저장소 수와 다른 양상을 보였다.

GitHub의 스타(Star)는 사용자가 관심 있는 저장소를 표시하는 기능으로, 공개 코드에 대한 관심도를 파악하는 지표로 활용된다.

분석 대상 저장소의 전체 스타 수는 1,394개였다. 이 중 공격 관련 저장소 36개가 1,178개로 전체의 약 85%를 차지했다. 특히 PoC·익스플로잇 저장소 27개에 1,158개, 전체의 약 83%가 집중됐다.

반면 방어 관련 저장소 46개의 스타 수는 148개로 약 11%에 그쳤다.

특히 ikow의 PoC 저장소는 617개, eness의 PoC 저장소는 333개의 스타를 기록했다. 두 저장소가 받은 스타는 총 950개로, 분석 대상 전체 스타의 약 68%에 해당한다.

또한 상위 5개 저장소가 전체 스타의 약 81%를 차지하는 등 소수의 인기 저장소에 관심이 집중되는 현상이 확인됐다.

반면 PoC·익스플로잇 관련 저장소 27개 중 21개는 스타가 10개 미만이었다. 전체 분석 대상에서도 스타가 1개 이하인 저장소가 61개로 나타났다.

이러한 결과는 방어 관련 저장소가 더 많이 등장했음에도, 사용자들의 관심은 소수의 공격 PoC에 집중됐음을 보여준다.

다만 GitHub 스타 수는 코드에 대한 관심도를 나타낼 뿐, 실제 공격 성공 여부나 기술적 완성도를 의미하지는 않는다.

Python·Shell 기반 도구 다수…저장소 절반 이상 라이선스 미표기

안랩은 공개된 저장소의 프로그래밍 언어와 라이선스 분포도 분석했다.

분석 결과 Python이 47개로 가장 많았고, Shell이 24개로 뒤를 이었다. Python은 주로 공격 PoC와 취약점 점검 도구에, Shell은 서버 설정 변경이나 임시 완화 스크립트에 사용된 것으로 나타났다.

이 밖에도 PHP 5개, JavaScript 3개, PowerShell·TypeScript·HTML 각 2개, C·Go·Rust·Zeek 각 1개가 확인됐다. 코드 언어 정보가 없는 저장소도 11개였다.

이는 이번 취약점과 관련해 다양한 프로그래밍 언어로 공격 검증, 취약점 점검, 탐지 및 완화 도구가 공개됐음을 보여준다.

라이선스 측면에서는 분석 대상 100개 중 51개가 라이선스를 명시하지 않았다. MIT 라이선스가 37개였으며, NOASSERTION 7개, Apache-2.0 2개, EUPL-1.2·AGPL-3.0·BSD-3-Clause가 각각 1개로 나타났다.

라이선스가 명시되지 않은 공개 코드는 사용·수정·재배포에 관한 허용 범위가 불분명할 수 있다. 따라서 기업이 이러한 코드를 보안 점검이나 내부 도구 개발에 활용할 경우 기술적 안전성뿐 아니라 라이선스 조건도 확인할 필요가 있다.

저장소 설명은 대부분 영어로 작성됐지만 중국어, 프랑스어, 러시아어, 포르투갈어, 스페인어, 네덜란드어 등 다양한 언어도 확인됐다. 한국어로 작성된 저장소는 없었다.

또한 분석 대상 중 토픽(Topic)을 설정한 저장소는 27개였으며, 대부분 CVE-2026-109618 또는 CVE-2026-109619를 포함하고 있었다.

공개 PoC의 실효성 주장 엇갈려…복제 저장소도 확인

이번 보고서에서는 공개된 공격 PoC의 실제 동작 여부를 둘러싼 상반된 주장도 확인됐다.

PoC(Proof of Concept)는 특정 취약점의 발생이나 공격 가능성을 검증하기 위한 개념 증명 코드다. 보안 연구에 활용되지만, 저장소에서 주장하는 기능이 실제로 구현됐거나 검증됐다는 의미는 아니다.

안랩 분석에 따르면 dinosn과 3em0의 저장소는 이번 PHP 취약점을 이용한 원격 코드 실행(RCE)이 가능하다고 주장했다. 반면 allureluoli는 RCE가 아닌 내부 상태 손상만 재현했다고 설명했으며, VKKKV는 공격 재현에 실패했다는 기록을 남겼다.

이처럼 공개된 PoC의 실효성을 둘러싼 주장이 엇갈리는 만큼, 저장소의 설명만으로 실제 원격 코드 실행 가능성을 판단해서는 안 된다.

복제 저장소도 주의해야 할 요소로 나타났다. 안랩은 AsviS/PHP2Shell의 설명이 ikow/php2shell-poc와 동일한 사례를 확인했다.

설명이 동일하다는 사실만으로 악성 여부를 판단할 수는 없다. 그러나 인기 저장소의 설명을 복제한 뒤 실제 코드를 변경해 배포하는 방식이 악용될 가능성도 있어, 저장소의 출처와 코드 내용을 확인할 필요가 있다.

또한 분석 대상 중 29개는 저장소 설명이 없었으며, 11개는 코드 언어 정보가 확인되지 않았다. 이러한 저장소는 공개된 정보만으로 실제 제공 기능이나 목적을 파악하기 어렵다.

특히 인기 취약점의 PoC를 사칭해 악성 코드를 배포하는 수법이 알려져 있는 만큼, 공개 직후 등장한 코드를 검증 없이 실행하는 행위는 주의해야 한다.

보안 도구를 가장한 위험 가능성…관리자 권한 실행에 주의

이번 분석에서는 취약점 대응을 목적으로 공개된 도구 역시 새로운 보안 위험을 초래할 수 있다는 점이 제기됐다.

특히 일부 완화 스크립트는 간단한 명령어만으로 서버에 설치된 PHP 환경 전체에 설정 변경을 적용할 수 있다고 안내한다.

그러나 이러한 스크립트는 관리자(root) 권한으로 실행되는 경우가 있어 주의가 필요하다. 관리자 권한으로 실행되는 코드는 PHP 설정뿐 아니라 서버의 다른 구성 요소에도 영향을 미칠 수 있기 때문이다.

출처가 불분명하거나 내부 동작을 확인하지 않은 스크립트를 실행하면 보안 조치를 위한 작업이 오히려 새로운 공격 경로가 될 가능성도 있다.

또한 mothproof3512의 저장소처럼 AI를 활용해 도구를 제작했으며 정상 동작을 보증하지 않는다고 명시한 사례도 확인됐다.

이러한 사례는 공개 도구의 편의성이나 설명만으로 신뢰성을 판단해서는 안 된다는 점을 보여준다. 특히 운영 중인 서버에 적용하는 점검·완화 스크립트는 코드의 실행 내용과 권한, 설정 변경 범위를 확인해야 한다.

공개 코드 활용 시 확인해야 할 보안 대응 사항

안랩은 이번 보고서에서 PHP 취약점 관련 공개 코드를 활용할 때 공식 보안 업데이트를 우선 적용하고, 검증되지 않은 코드를 운영 환경에서 실행하지 않도록 주의할 것을 권고했다.

• 첫째, 공식 보안 업데이트를 우선 적용해야 한다.
  공개 저장소에서 제공하는 임시 완화 도구나 비공식 패치는 공식 보안 업데이트를 대체할 수 없다. 운영 중인 PHP 버전과 배포판 공급업체의 보안 수정 사항을 확인해야 한다.
• 둘째, 임시 완화 조치는 적용 대상과 영향을 검토해야 한다.
  즉시 업데이트하기 어려운 경우에는 session.upload_progress.enabled = Off와 같은 임시 완화 설정을 검토할 수 있다. 다만 해당 설정은 파일 업로드 진행률 표시 기능을 비활성화하므로 서비스 영향과 적용 대상 취약점을 확인해야 한다.
• 셋째, 탐지 규칙은 실제 환경에서 검증한 후 적용해야 한다.
  웹 방화벽에서 의심스러운 multipart 요청을 탐지하거나 차단하는 규칙은 정상적인 파일 업로드 요청에도 영향을 줄 수 있다. 따라서 적용 전 오탐 가능성을 확인해야 한다.
  또한 Corelight의 Zeek·Suricata 탐지 규칙이나 NCSC-NL의 공개 운영 정보 등 신뢰할 수 있는 자료를 우선 참고하되, 자사 환경에서 유효성을 검증해야 한다.
• 넷째, 공개 PoC와 점검 도구는 코드를 검토한 후 격리된 환경에서 실행해야 한다.
  저장소의 이름이나 스타 수만으로 코드의 신뢰성을 판단해서는 안 된다. 코드의 출처와 변경 이력, 실행 권한 등을 확인하고 실제 운영 환경과 분리된 환경에서 검증해야 한다.
  특히 관리자 권한을 요구하는 스크립트는 실행 전에 전체 동작을 확인하고, 필요한 경우 변경 사항을 되돌릴 수 있는 절차를 마련해야 한다.

참고자료

1. AhnLab, 「GitHub php2shell 저장소 분석 보고서」, 2026년 10월 22일.
2. PHP 공식 홈페이지

분석 기준: 2026년 10월 22일 13시 30분. GitHub 'php2shell' 검색 결과 상위 100개 저장소(포크 제외)를 대상으로 저장소 이름, 설명, 토픽 등 공개된 정보를 분석했다. 개별 코드를 직접 검토하거나 실행해 실제 동작 여부와 공격 성공 가능성을 검증한 결과는 아니다.