Synology에서 PHP2Shell 사용: 하루 만에 6개 사이트 패치 완료 사례

PHP2쉘 PHP2Shell은 업계에서 합의한 CVE-2026-109618 및 CVE-2026-109619의 이름으로, 인증 없이 원격 코드 실행을 허용하는 PHP 엔진 자체의 심각한 취약점 두 가지입니다. 이 취약점에 대한 세부 정보는 공동 공개 하루 전인 2026년 10월 20일에 유출되었고, PHP 프로젝트는 10월 21일에 긴급 릴리스를 배포했습니다. 이 버그는 애플리케이션이 아닌 인터프리터에 존재하기 때문에 WordPress, Joomla 또는 MediaWiki를 패치해도 아무런 효과가 없습니다. 유일한 해결책은 새로운 PHP 빌드를 만드는 것입니다. 저희는 Synology 하드웨어에서 6개의 공개 WordPress 사이트를 운영하고 있는데, PHP2Shell 때문에 모든 사이트를 같은 주에 다시 빌드해야 했습니다. 이 가이드에서는 버그의 실제 내용, 패키지 센터를 통해 DSM에서 패치하는 방법, 컨테이너에서 사이트를 실행할 때 처리하는 방법, 그리고 Synology에서 배포한 버전과 다른 NAS 제조사들이 지금까지 제공한 버전 간의 불편한 비교에 대해 다룹니다.

SynoPower Club 포인트:저희 여섯 개 사이트는 PHP2Shell 권고 사항이 발표된 후 단 하루 만에 패치가 완료되었습니다. 이는 단순히 전문가들의 노력 덕분이 아니라, Synology에서 권고 사항 발표 당일에 수정된 패키지를 배포했기 때문입니다. Synology-SA-26:14는 10월 22일에 '해결됨' 상태와 함께 PHP 7.4까지의 수정 버전 목록이 포함된 전체 표를 배포했습니다. 같은 날 QNAP은 '수정 중' 상태와 함께 모든 수정 버전 항목에 '추후 공지 예정'이라는 문구가 적힌 QSA-26-18을 게시했고, ASUSTOR는 패치를 배포하는 대신 App Central에서 기존 PHP 버전을 삭제하는 것으로 대응했습니다. NAS에 공개 웹사이트를 자체 호스팅하는 경우, 이러한 시간적 차이는 단순한 마케팅 전략이 아닙니다. 패키지를 업데이트하는 것과 패치가 나올 때까지 사이트를 인터넷에서 차단하는 것 사이의 차이입니다.

PHP2Shell이란 무엇이며, 기존 서비스와 어떤 차이점이 있나요?

PHP2Shell은 하나의 버그가 아니라, PHP가 메모리 부족으로 인해 요청이 종료된 후 정리 작업을 수행하는 방식에서 발생하는 여러 관련 메모리 안전성 실패의 집합체입니다. PHP는 다음과 같은 방식을 사용합니다. longjmp() 치명적인 오류, 특히 메모리 부족 오류를 피하기 위해 해당 점프는 일반적으로 엔진을 알려진 상태로 되돌리는 정리 코드를 건너뜁니다. 해당 상태 중 일부는 전역적으로 저장되어 동일한 작업자 프로세스가 처리하는 다음 요청까지 유지됩니다.

CVE-2026-109618은 메모리 부족 취약점입니다. 조작된 HTTP 요청이 요청 데이터가 부분적으로만 초기화된 상태에서 메모리 제한을 초과하면, 정리 루틴이 완료되지 않은 구조체를 탐색하게 됩니다. CVE-2026-109619는 해제 후 사용(use-after-free) 취약점입니다. 해제된 요청 메모리를 가리키는 전역 상태가 동일한 워커에서 나중에 발생하는 요청에 의해 읽힐 수 있으며, 이로 인해 버그가 코드 실행이나 메모리 유출로 이어질 수 있습니다.

PHP2Shell 취약점은 일반적인 PHP 보안 권고보다 두 가지 점에서 더 심각합니다. 첫째, 사전 인증 단계까지 공격한다는 점입니다. 두 취약점 모두 애플리케이션 수준의 인증이 실행되기 전에 발생하므로 로그인 장벽, 회원 관리 플러그인 또는 관리자 비밀번호로는 아무것도 보호할 수 없습니다. 둘째, 메모리 노출 변종은 워커 프로세스의 메모리를 유출합니다. WordPress 사이트의 PHP 워커 프로세스는 데이터베이스 자격 증명, API 토큰 및 결제 키를 처리하고 있습니다. 메모리 읽기에 성공하면 코드 실행에 도달하지 않더라도 심각한 보안 문제를 야기할 수 있습니다.

PHP2Shell의 두 가지 CVE는 PHP 보안 팀에서 CVSS v4.0 9.2 등급으로 평가되었습니다. Synology는 자체 권고안에서 CVSS v3.1 기준으로 9.8 등급을 부여했습니다. 평가 척도는 다르지만 결론은 같습니다. 공격 사례 보고는 엇갈립니다. watchTowr는 허니팟 네트워크를 대상으로 한 공격 시도를 포착했다고 밝혔지만, Bitdefender는 작성 시점까지 원격 측정 데이터에서 아무런 정보를 수집하지 못했으며, QNAP은 자사 제품을 표적으로 한 공격 보고를 받지 못했다고 밝혔습니다.

PHP2Shell과 일반적인 WordPress 취약점 비교

공개된 WordPress 사이트를 공격하는 대부분의 문제는 플러그인 취약점 때문입니다. 그 패턴은 익숙합니다. 플러그인이 결함 있는 REST 엔드포인트를 제공하고, 스캐너가 이를 발견하면, 플러그인을 업데이트하여 취약점을 해결하는 식입니다. PHP2Shell은 이러한 관행을 완전히 바꿔놓으며, 플러그인 취약점을 감사하는 것은 시간 낭비일 뿐입니다.

측면	일반적인 플러그인 CVE	PHP2쉘
벌레가 사는 곳	애플리케이션 코드(플러그인 또는 테마)	PHP 인터프리터 자체
누가 그것을 작동시킬 수 있나요?	구독자 또는 관리자 역할이 필요한 경우가 많습니다.	아무도. 앱 로직이 실행되기 전, 사전 인증 단계입니다.
워드프레스 업데이트가 도움이 되나요?	보통 그렇습니다	아니요. 코어 및 플러그인 업데이트는 관련이 없습니다.
WAF(아내 승인 포럼)가 이를 막을 수 있을까요?	일반적으로 규칙이 일단 존재하게 되면	부분적으로 그렇습니다. 요청 형태 규칙에 OOM 경로가 누락되었습니다.
무엇이 실제로 문제를 해결할까요?	플러그인 업데이트	새로운 PHP 빌드일 뿐입니다. 그 외에는 아무것도 없습니다.
폭발 반경	한 사이트에 하나의 기능	서버에 있는 모든 PHP 사이트를 한 번에

마지막 줄 때문에 PHP2Shell 작업이 오후 시간이 아니라 하루 종일 걸리는 작업이 되었습니다. NAS에 있는 하나의 공유 PHP 패키지가 수십 개의 웹 스테이션 가상 호스트 뒤에 있을 수 있고, 하나의 컨테이너 이미지가 여러 사이트의 기반이 될 수 있습니다. 패치는 사이트별이 아니라 런타임별로 적용되므로, 작업이 완료되었다고 말하기 전에 모든 런타임을 열거해야 합니다.

NAS가 외부에 노출되었는지 확인하는 방법

PHP2Shell 노출 여부를 판단하려면 두 가지 질문을 구분하는 것부터 시작해야 합니다. 해당 시스템에 취약한 PHP 빌드가 있는지, 그리고 그 빌드가 인터넷에서 접근 가능한지 여부입니다. Synology는 이 두 가지를 명확히 구분합니다. DSM에는 운영 체제에서 사용하는 내부 PHP 구성 요소가 포함되어 있으며, Synology에 따르면 이 구성 요소에는 외부에서 접근 가능한 모듈이 없으므로 공격 표면이 노출되지 않습니다. 따라서 해당 구성 요소에 대한 위험도는 최소한이며, 취약점 검사에서 더 이상 취약점으로 표시되지 않도록 향후 DSM 릴리스에 패치가 포함될 예정입니다.

PHP2Shell에 중요한 패키지는 웹에 PHP를 제공하는 패키지입니다. Synology에는 Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station 및 WordPress가 나열되어 있습니다. 이러한 패키지 중 하나라도 설치되어 있고 접근 가능한 경우 PHP2Shell의 적용 범위에 포함됩니다.

대시보드를 신뢰하기보다는 버전을 직접 확인하세요. 패키지 센터에서는 설치된 PHP 패키지의 타일에 버전이 표시되고, 업데이트 알림에는 대상 빌드 이름이 나옵니다. 셸에서 런타임 자체에 문의할 수도 있습니다.

# Synology PHP 패키지(실행하는 버전에 맞게 경로를 조정하세요) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # 컨테이너화된 사이트 docker exec php -v

고집해야 하는 이유 php -v PHP2Shell을 검사할 때 가장 큰 문제는 다른 모든 신호가 거짓이라는 것입니다. 빌드 출력은 캐시된 레이어를 재사용하면서도 성공으로 보고할 수 있고, 대시보드는 실행 중인 워커가 최신 버전이 아닌데도 패키지를 최신 버전으로 표시할 수 있으며, HTTP 응답 헤더는 CDN에서 제거되어 사용자에게 표시되지 않을 수도 있습니다. 저희 사이트 6개 중 2개는 관리자 화면에서는 정상으로 보고되었지만, 실제로는 패치가 적용되지 않은 인터프리터를 실행하고 있었습니다.

Synology에서 PHP2Shell 패치하는 4단계

DSM의 웹 스테이션 사이트에서 PHP2Shell 문제를 해결하는 방법은 패키지 센터 업데이트뿐입니다. Synology는 DSM 7.4, 7.3, 7.2용 PHP 보안 업데이트를 제공하며, PHP 패키지 업데이트 후 종속 패키지들이 자동으로 재시작되어 문제가 해결됩니다. 단, 메일 스테이션은 예외적으로 수동 업데이트가 필요합니다.

위 스크린샷은 PHP2Shell 권고 발표 다음 날 아침 저희 시스템 중 하나에서 캡처한 것입니다. '새로운 기능' 패널에 업스트림 버전이 직접 표시되므로 Synology 빌드 접미사를 PHP 릴리스 버전과 대조하여 쉽게 확인할 수 있습니다. Synology 캘린더는 동일한 업데이트 목록에 3.0.4-21435 버전으로 나타나는데, 이는 권고에서 요구하는 버전과 정확히 일치합니다.

웹 스테이션 사용자를 위한 PHP2Shell의 함정 하나를 알려드리겠습니다. DSM 머신에는 여러 PHP 브랜치가 동시에 설치될 수 있으며, 각 가상 호스트는 하나의 프로필에 바인딩됩니다. 기본 프로필을 업데이트해도 다른 브랜치에 고정된 사이트에는 적용되지 않습니다. 먼저 프로필 목록을 확인하고 모두 업데이트한 다음, 웹 서비스에서 각 사이트의 바인딩 상태를 확인하십시오.

어떤 DSM 패키지가 영향을 받나요?

PHP2Shell의 Synology 오류 메시지는 패닉 메시지에서 제시된 것보다 범위가 좁습니다. 특정 PHP 종속 패키지를 실행하는 시스템에만 영향을 미치며, Synology Drive는 명시적으로 해당 패키지에 포함되지 않습니다. IDrive는 목록에 있지만 타사 소프트웨어입니다.

• 웹에서 바로 사용 가능하며 최우선 순위입니다. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer 및 phpMyAdmin은 접근 권한이 있는 모든 사용자에게 PHP를 제공합니다.
• 메일과 캘린더. PHP 패키지 설치 후 Mail Station을 수동으로 업데이트해야 합니다. Synology 캘린더는 3.0.4-21435 버전에서 자체적으로 수정된 빌드를 제공합니다.
• DSM 내부 구성 요소. 존재하지만 외부에서 접근할 수 없으며, 패치는 추후 DSM 릴리스로 연기되었고, Synology는 위험도를 최소로 평가했습니다.
• 컨테이너는 덮여 있지 않습니다. 컨테이너 관리자 내의 PHP 런타임은 사용자가 직접 패치할 수 있습니다. 패키지 업데이트는 이를 건드리지 않는데, 이것이 NAS 사용자가 패치가 완료되었다고 착각하는 가장 흔한 이유입니다.

DSM 7.2 이전 버전을 사용 중인 경우, Synology는 패치된 버전이 나올 때까지 해당 패키지를 일시적으로 비활성화할 것을 권장합니다. DSM 7.2는 이러한 PHP 업데이트를 받았음에도 불구하고 해당 공지에서 지원 종료(End of Life)로 표시되어 있습니다.

PHP2Shell의 가장 큰 문제는 PHP 7.3 이하 버전입니다. Synology는 해당 브랜치가 지원 종료되었고, 업스트림에서도 7.3 이하 버전에 대한 업데이트를 전혀 제공하지 않았기 때문에 7.3 버전을 지원하지 않습니다. 리눅스 배포판에서는 일부 구버전에 대한 백포트를 제공하기도 하지만, Synology PHP 패키지는 배포판 패키지가 아닙니다. 웹사이트 운영에 7.3 또는 5.6 버전이 필요한 경우, 패치는 제공되지 않으므로 사이트를 지원되는 브랜치로 이전하거나, 웹 방화벽(WAF) 뒤에 숨기거나, 인터넷에서 완전히 차단하는 것이 최선의 선택입니다.

컨테이너 사이트 소유자는 PHP2Shell을 어떻게 처리할까요?

저희 사이트 6개 중 5개는 웹 스테이션이 아닌 도커에서 WordPress를 실행하고 있는데, 바로 이 부분에서 PHP2Shell이 유용해집니다. 패키지 센터로는 해결할 수 없기 때문입니다. 런타임은 이미지에 포함된 내용에 따라 달라지며, 이미지를 다시 빌드하는 것과 업데이트하는 것은 다릅니다.

우리가 처음 발견했고, 다른 사람들도 겪을 가능성이 가장 높은 PHP2Shell 오류는 사용자 정의 이미지를 다시 빌드할 때 캐시된 기본 레이어를 재사용한다는 점입니다. 고정되지 않은 레이어는 이러한 문제를 야기합니다. 에서 태그가 최신 버전임을 의미하는 것은 아닙니다. 저희 이미지 중 하나는 4일 전에 재구축되었지만, Docker가 기본 이미지를 다시 가져오도록 강제하는 요소가 없었기 때문에 2025년 7월의 PHP 빌드를 여전히 포함하고 있었습니다. 이는 1년 이상 지난 보안 수정 사항들이 반영된 것입니다.

잘못된 예: 로컬에 캐시된 기본 레이어를 자동으로 재사용합니다. `docker build -t mysite .` 올바른 예: 항상 기본 이미지를 다시 가져옵니다. `docker build --pull -t mysite .` 그런 다음, 비활성화된 다른 서비스는 시작하지 않고 필요한 서비스만 실행합니다. `docker compose up -d --no-deps wordpress` 마지막으로, 실제로 중요한 부분을 확인합니다. `docker exec wordpress php -v`

두 번째 PHP2Shell 오류는 성공으로 보고되기 때문에 더 심각합니다. 빌드 출력을 파이핑하는 과정에서 문제가 발생했습니다. 꼬리 파이프라인의 종료 코드는 해당 파이프라인의 마지막 명령에 속하기 때문에 빌드 실패를 숨깁니다. 설정 -e 이 작업은 전혀 실행되지 않습니다. 그러면 구성 단계에서 이전 이미지로부터 컨테이너를 다시 생성하고 "시작됨"을 출력하며, 패치가 적용되지 않은 채 새로 배포된 것처럼 보이는 사이트를 확인할 수 있습니다. 빌드 결과를 단독으로 확인하고, 다음 명령으로 검증하십시오. php -v 나중에.

두 가지 작은 참고 사항이 있습니다. 이미지를 다시 빌드하기 전에 이전 이미지에 태그를 지정하세요. 이미지는 태그를 유지하므로 스냅샷보다 훨씬 저렴한 비용으로 롤백할 수 있는 지점을 제공합니다. 또한 이미지 업데이트를 통해 애플리케이션이 업그레이드될 것이라고 기대하지 마세요. 공식 WordPress 이미지 진입점은 문서 루트가 비어 있을 때만 핵심 파일을 복사하므로, 최신 이미지에서 컨테이너를 다시 생성해도 기존 설치는 이전 상태 그대로 유지됩니다. 프로덕션 환경에 적용하기 전에 스테이징 환경에서 이를 확인했으며 WordPress 버전은 변경되지 않았습니다.

session.upload_progress를 비활성화해도 문제가 절반만 해결되는 이유는 무엇일까요?

패치가 불가능한 시스템에 대해 유포되고 있는 PHP2Shell 완화 방법은 다음과 같습니다. session.upload_progress.enabled = 0, DSM에서는 웹 스테이션의 스크립트 언어 설정에서 PHP 프로필의 코어 탭에 해당 설정이 있습니다. 이 작업을 수행하는 것이 좋습니다. 완벽한 해결책은 아니지만, 이 격차는 중요합니다.

세션 업로드 진행률 경로는 취약점 발생 경로 중 하나일 뿐입니다. 메모리 노출 변형은 일반적인 멀티파트 요청 처리를 통해 발생하며 세션 기능을 전혀 필요로 하지 않으므로, 해당 기능을 비활성화해도 해당 경로는 여전히 열려 있습니다. PHP 프로젝트 측에서는 완벽한 완화책이 없으며 업데이트만이 유일한 안전한 해결책이라고 직접 밝혔습니다. Imunify360에 따르면 현재 CVE-2026-109618의 메모리 부족 경로를 차단하는 규칙은 없으며, Elastic은 업로드 진행률 설정이 확인된 세션 경로는 차단하지만 모든 변형을 차단하는 것은 아니라고 지적합니다.

또한 보게 될 것입니다 메모리 제한 = -1 버그가 메모리 부족 상태를 통해 발생한다는 논리에 근거하여 제안된 내용입니다. 이는 이득이 아니라 일종의 거래로 봐야 합니다. 공용 웹 서버에서 메모리 제한을 제거하면 한 가지 오류 유형이 다른 유형으로 바뀌고, 공유 메모리 예산을 사용하는 NAS에서는 작업자 풀이 전체 시스템의 메모리를 고갈시키도록 유도할 수 있습니다.

엣지 필터링은 PHP2Shell에서 실제로 중요한 역할을 하는 계층입니다. 라우터는 복호화된 트래픽을 볼 수 없지만 엣지 필터링은 복호화된 트래픽을 볼 수 있기 때문입니다. Cloudflare는 PHP2Shell에 대한 관리형 규칙 보호 기능을 배포했고, AWS는 PHP 관리형 규칙 그룹 버전 2.3에 CVE-2026-109619 관련 내용을 추가했으며, Azure Front Door는 기본적으로 비활성화된 규칙 99006001을 제공했습니다. GitHub에는 커뮤니티에서 만든 Snort 및 Suricata 규칙이 있지만, 이 글을 작성하는 시점에는 공식 Snort 및 Emerging Threats 규칙 세트에 관련 내용이 게시되지 않았으므로 NAS 침입 방지 기능은 이 문제를 해결해 주지 못할 것입니다. 어차피 NAS는 TLS 내부를 읽을 수 없기 때문입니다.

어느 NAS 공급업체가 실제로 수정 사항을 배포했습니까?

PHP2Shell 관련 이야기 중 구매 결정을 좌우해야 할 부분은 바로 이 부분입니다. PHP 업스트림은 10월 21일에 릴리스되었습니다. 다음은 언론 보도가 아닌 각 회사의 공지 페이지에서 발췌한, 주요 소비자 및 전문가용 NAS 제조사 4곳의 다음 날 상황입니다.

공급업체	자문	상태	수정된 버전이 게시되었습니다.
Synology	Synology-SA-26:14, 2026년 10월 22일	해결됨	네. PHP 7.4부터 8.4까지의 모든 지점과 캘린더 및 메일 스테이션이 포함됩니다.
큐냅	QSA-26-18, 2026년 10월 22일	고정	아니요. 모든 줄에 "추후 공지 예정"이라고 적혀 있습니다.
ASUSTOR	기존 PHP 서비스 종료일: 2026년 10월 22일	은퇴이지, 임시방편이 아닙니다.	아니요, PHP 7, 7.3, 7.4 및 8.1 버전이 앱 센트럴에서 제거되었습니다.
유그린	찾을 수 없음	알려지지 않은	UGOS Pro에 대한 권고사항을 찾을 수 없습니다.

Synology는 권고안 발표 당일 PHP2Shell 버전 표 전체를 게시하고 권고안을 해결됨으로 표시했습니다. DSM 담당자는 이를 확인하고 그날 오후에 패키지 센터를 열고 업데이트를 클릭한 후 확인하는 간단한 조치를 취했습니다. 이것이 전체 해결 경로이며, 웹 스테이션 시스템 문제가 며칠이 아닌 몇 분 만에 해결된 이유입니다.

QNAP은 같은 날짜에 공지를 발표하고 QTS 6.1.0, QTS 5.2.11 및 이전 버전, QuTS hero h6.1.0, h6.0.x 및 h5.2.11 및 이전 버전, QuTScloud c5.2.9 및 이전 버전, Note Station 3, QNE ADRA, ARM32 모델용 QVR Surveillance, TVR OS 등 영향을 받는 제품군 목록을 공개했습니다. 모든 제품은 수정 중(Fixing) 상태로 표시되며 수정된 버전은 없습니다. PHP 런타임은 QTS 웹 구성 요소의 일부이므로 업데이트할 패키지가 없어 펌웨어 업데이트를 통해 문제를 해결해야 합니다.

QNAP은 PHP2Shell 공격 피해자들에게 당분간 다음과 같은 완화 조치를 제공할 예정이며, 그 내용은 매우 중요하므로 꼼꼼히 읽어볼 필요가 있습니다. 라우터 포트 포워딩 및 UPnP 비활성화, myQNAPcloud 서비스 게시 취소, 원격 접속을 VPN 뒤로 이동, 관리 포트를 신뢰할 수 있는 서브넷으로 제한, 필요 없는 PHP 기반 애플리케이션 중지, 사용하지 않는 내장 웹 서버 비활성화, 그리고 QuLog Center에서 침해 징후 확인 등이 포함됩니다. 이는 패치가 적용되지 않은 시스템에 대한 유용한 조언이며, 공개 웹사이트를 운영하는 사용자라면 웹사이트를 중단하라는 권고이기도 합니다.

ASUSTOR는 세 번째 방식을 택했습니다. 10월 22일자 공지(제목: 레거시 PHP 지원 종료)에서 PHP 7, PHP 7.3, PHP 7.4, PHP 8.1을 App Central에서 즉시 삭제하고, 중요한 데이터 백업을 권장하며, 앞으로는 PHP 8.3 또는 8.4만 사용하도록 안내했습니다. 업스트림에서 8.2 이상 버전만 패치한다는 점을 고려하면 이러한 조치는 타당합니다. 하지만 오래된 PHP 애플리케이션을 사용하는 사용자는 해당 런타임이 수정되는 대신 스토어에서 사라지게 되며, ASUSTOR는 8.3 또는 8.4의 패치된 빌드를 배포했다는 언급도 하지 않았습니다. 이와 대조적으로 Synology는 ASUSTOR가 마이그레이션을 요청한 사용자들을 위해 7.4.33-0131 버전의 수정된 7.4 빌드를 배포했습니다.

UGREEN의 경우, UGOS Pro에 대한 PHP2Shell 보안 권고를 전혀 찾을 수 없었습니다. 공개적인 발표가 없다고 해서 제품이 취약하다는 증거는 아니며, UGOS Pro는 단순히 웹에서 사용할 수 있는 PHP 런타임을 제공하지 않을 수도 있습니다. 하지만 제품 소유자라면 침묵은 조치를 취할 수 있는 근거가 되지 못하며, 이는 그 자체로 일종의 취약점 노출로 볼 수 있습니다.

이 모든 것이 Synology를 완벽하게 만드는 것은 아닙니다. PHP 7.3 문제를 해결하지 못하고, DSM 7.2를 지원 종료로 표시하며, 자체 PHP 구성 요소는 패치가 아닌 업데이트 일정만 제공하고 있습니다. 핵심은 브랜드 논쟁보다 더 좁고 유용한 부분에 있습니다. PHP 엔진에서 사전 인증 원격 코드 실행 버그가 발견된 날, 한 업체는 패키지 센터에 해결 버튼을 추가했지만, 다른 업체들은 그저 기다리는 수밖에 없었습니다.

더 많은 공식 자료를 찾을 수 있는 곳

PHP2Shell은 이 글을 쓰는 시점에서 출시된 지 이틀밖에 되지 않았고 상황이 계속 변화하고 있으므로 요약보다는 원본 자료를 참고하시기 바랍니다. 아직 어떤 벤더에서도 공식적인 동영상 자료를 제공하지 않았으므로 아래 목록은 튜토리얼이 아닌 문서 자료입니다.

• Synology-SA-26:14 이 버전이 공식적인 버전표입니다. 권고 사항이 개정될 수 있으므로 패치를 적용하기 전에 다시 확인하십시오.
• Synology PSIRT 성명서 영향을 받는 패키지 목록을 제공하고 DSM 내부 구성 요소 및 메일 스테이션 예외에 대해 설명합니다.
• 상위 GitHub 권고 사항인 GHSA-w8hw-w9fx-j79w 및 GHSA-6wmf-4rv5-p3rp는 Synology 권고 사항에 링크되어 있으며 공급업체 패키징이 아닌 엔진 동작에 대해 설명합니다.
• 큐냅 QSA-26-18 QTS 또는 QuTS hero를 실행하면 고정된 펌웨어 버전이 표시되는 곳입니다. 뉴스 기사가 아니라 해당 페이지를 주시해야 합니다.
• 사용자의 패키지 센터는 설치된 항목에 대한 최종적인 정보를 제공합니다. 권고 사항은 목표 빌드를 알려주고, 타일은 실제로 설치된 항목을 보여줍니다. php -v 현재 실행 중인 항목을 알려줍니다.

Synology 가상 머신에서 공용 사이트를 운영하는 방법에 대한 자세한 내용은 다음 가이드를 참조하세요. VDSM 게스트 간에 Docker 스택을 이동하는 방법 이 글에서는 이번 비상 상황에서 생존할 수 있게 해준 스냅샷 및 롤백 습관에 대해 다룹니다.

PHP2Shell 제한 사항 및 보안 참고 사항

PHP2Shell 패치는 DSM에서는 간단하지만 다른 환경에서는 까다롭기 때문에 작업이 완료되었다고 선언하기 전에 몇 가지 제한 사항을 명확히 밝히는 것이 좋습니다.

PHP2Shell 패키지 업데이트는 사이트 감사가 아닙니다. PHP를 업데이트하면 해당 시점부터 취약점은 해결되지만, 10월 20일에서 22일 사이에 해당 서버에 인터넷 접근이 가능했다면 유효한 익스플로잇이 공개된 동안에도 접근이 가능했던 것입니다. 로그에서 예상치 못한 POST 요청량이 있는지 확인하고, 쓰기 가능한 디렉터리에 파일이 생성되었는지 살펴보고, PHP 워커가 보유하고 있을 수 있는 모든 자격 증명을 주기적으로 교체하십시오. 메모리 노출 변종의 경우 자격 증명 교체는 단순한 피해망상이 아니라 합리적인 예방 조치입니다.

PHP2Shell 검증은 실행 중인 인터프리터를 대상으로 해야 합니다. 대시보드, 빌드 로그, 응답 헤더 모두 이번 검증 과정에서 최소 한 번 이상 실패했습니다. CDN은 버전 정보를 알려주는 헤더를 제거할 수 있고, 빌드는 캐시된 레이어를 재사용하면서도 성공을 보고할 수 있으며, 패키지 타일은 이전 워커가 여전히 서비스를 제공하고 있음에도 불구하고 현재 버전을 표시할 수 있습니다. 오직... php -v 요청을 처리하는 내부에서 문제가 해결됩니다.

컨테이너는 어떤 벤더의 PHP2Shell 권고 사항에도 포함되지 않습니다. NAS에서 가장 흔히 발생하는 잘못된 보안 인식이기 때문에 이 점을 다시 한번 강조합니다. 사이트가 컨테이너 관리자에서 실행되는 경우, 패키지 센터에서 모든 것이 최신 상태라고 보고하더라도 사이트에 대한 정보는 전혀 제공하지 않습니다. 자체 런타임을 포함하는 타사 애플리케이션에도 동일하게 적용됩니다.

구성 완화 조치는 애초부터 부분적인 해결책일 뿐입니다. 세션 업로드 진행률 표시를 비활성화하면 도움이 되지만, 메모리 제한을 제거하는 것은 한 가지 위험을 다른 위험으로 바꾸는 것일 뿐이며, 라우터 침입 방지 기능은 다른 곳에서 종료되는 TLS 트래픽을 검사할 수 없습니다. 이러한 조치들은 모두 실제 패치를 마련하는 동안 시간을 벌어주는 수단으로 생각해야 하며, 패치를 대체하는 수단으로 여겨서는 안 됩니다.

지원이 종료된 런타임은 PHP2Shell 경로가 전혀 없습니다. PHP 7.3 이전 버전은 업스트림이나 Synology에서 아무런 지원도 받지 못했습니다. 만약 사이트에서 지원되지 않는 브랜치를 정말로 사용해야 한다면, 마이그레이션, 격리 또는 인터넷 접속 차단이라는 세 가지 선택지밖에 없습니다. 네 번째 옵션은 없으며, 그렇지 않은 척하는 것은 레거시 사이트가 같은 서버의 다른 모든 시스템과 연결되는 통로가 되는 결과를 초래할 뿐입니다.

마지막으로, 뉴스보다는 권고 사항을 주시하십시오. Synology는 SA-26:14가 해결되었다고 표시했으며, 게시 후 6분 이내에 한 번 수정했습니다. QNAP는 수정된 버전이 나오는 대로 QSA-26-18을 업데이트할 것이라고 밝혔습니다. 두 페이지 모두 변경될 예정이며, 이 글에 언급된 버전 번호는 2026년 10월 22일에 게시된 버전입니다.

참고문헌

• Synology-SA-26:14 PHP2Shell 보안 권고, 2026년 10월 22일 게시됨, 상태 해결됨, PHP 7.4부터 8.4까지 수정된 버전 포함.
• PHP2Shell 취약점에 대한 Synology 성명서, PSIRT 공지사항에는 영향을 받는 패키지와 DSM 적용 범위가 명시되어 있습니다.
• 큐냅 QSA-26-18, 상태: 수정 중, 영향을 받는 제품 목록 및 수정된 버전은 추후 공지 예정입니다.
• ASUSTOR Legacy PHP 서비스 종료 안내, 앱 센트럴에서 PHP 7, 7.3, 7.4 및 8.1 버전을 제거합니다.
• PHP2Shell 업스트림 릴리스에서 Net Security를 지원해 주세요., PHP 8.5.12, 8.4.27, 8.3.36 및 8.2.35 버전과 이전 브랜치에 대한 소스 코드만 포함된 백포트를 다룹니다.

자주 묻는 질문