"피해 미확인"이라도 안심할 수 없는 이유 - PHP 취약성으로 사이트 중단, 지금 무슨 일이 일어나고 있는가

항상 사용하던 사이트가 갑자기 열리지 않게 되었다. 그러나 그 이유가 사이버 공격에 의한 파괴가 아니라, 공격으로부터 보호하기 위한 일시 중단이었다면, 어떻게 받아들일 것인가.

웹사이트나 웹 애플리케이션을 지탱하는 프로그래밍 언어 PHP에서 중대한 취약성이 드러나, 독일에서는 행정기관 등이 예방적으로 사이트를 중단했다.

BUSINESS-PANORAMA가 게재한 10월 22일의 AFP 기사에 따르면, 독일 연방 정보 보안청(BSI)은 이 취약성을 악용한 사례를 그 시점에서는 확인하지 않았다고 설명했다. 그러나 공격이 성공했을 가능성까지 배제한 것은 아니다.

이 뉴스를 읽을 때 중요한 것은, "피해를 확인하지 않았다"와 "안전이 확인되었다"는 같은 것이 아니라는 점이다.

BSI의 발표는 "종식 선언"이 아니다

원 기사에 따르면, BSI는 10월 21일 오후, PHP의 취약성에 대해 경고하고, 같은 날 16시에 보안 업데이트가 예정되어 있음을 안내했다.

경계된 것은, 업데이트 내용 공개 후에 공격이 확산될 가능성이었다. 수정에 의해 문제의 소재가 명확해지면, 공격자가 그 정보를 분석하여 미수정 시스템을 노릴 수도 있다. 기사에서는 그 분석이 AI에 의해 용이해질 것에 대한 우려도 전하고 있다.

다음 날 22일, BSI는 예방적으로 중단된 연방 행정기관의 사이트 대부분이 복구되었다고 설명했다. 침해된 시스템의 보고가 없는 상황에 대해, 많은 운영자가 권장에 따라 업데이트를 완료했을 가능성이 있다는 견해를 보였다.

그러나 이는 파악된 정보에 기반한 평가다. 모든 사이트에 대해 조사를 마치고, 침입이 없었다고 보증한 것은 아니다.

사이트의 복구는 이용자에게 반가운 소식이지만, 그것만으로 문제 전체가 해결되었다고 판단하기에는 이르다.

문제는 웹사이트의 "기반"에 있다

이번에 PHP 측이 수정한 것은, "PHP2Shell"이라 불리는 두 개의 중대한 취약성이다. 식별 번호는 CVE-2026-109618과 CVE-2026-109619. 심각도를 나타내는 CVSS v4.0의 평가는 모두 9.2로, "Critical"로 분류되어 있다.

PHP Foundation은 10월 21일, 조건이 갖춰지면 인증되지 않은 공격자가 PHP를 실행하는 서버에서 코드를 실행할 수 있는 문제를 수정했다고 발표했다.

일반 이용자에게 PHP는 평소에는 의식하지 않는 존재다. 화면의 디자인이나 기사 그 자체가 아니라, 그 뒤에서 처리를 담당하고 있다.

따라서 이번 대응을 생각할 때는, 사이트의 외관이나 관리 화면만을 바라봐서는 충분하지 않다. 애플리케이션을 구동하는 기반의 수정 상황을 확인할 필요가 있다.

PHP Foundation이 공표한 수정판은, PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12. 운영자는 자신의 환경을 제공하는 사업자의 안내도 포함하여, 수정의 적용 상황을 확인하게 된다.

"공격 시도"와 "침입 성공"을 혼동하지 말라

BSI에 관한 원 기사와 함께 알아두어야 할 것은, AWS에 의한 관측 보고다.

AWS는, 공격을 관측하기 위한 시스템 "MadPot"에서, 10월 17일로 거슬러 올라가는 PHP2Shell의 악용 시도를 확인했다고 공표했다. 이는 취약성의 상세 공개 이전 시점에 해당한다.

한편, AWS는, 관측한 시도가 실제 시스템에서 성공했는지는 불명이라고 하고 있다.

즉, BSI에 관한 "악용 사례를 확인하지 않았다"는 보도와, AWS의 "공격 시도를 관측했다"는 보고는, 대상도 확인 내용도 다르다. 한쪽만을 들어 "공격은 없었다", 혹은 "대규모 침입 피해가 확정되었다"고 결론지을 수는 없다.

이용자로서도 운영자로서도, 취약성의 존재, 공격의 관측, 침입의 성공, 정보 유출의 확인을 나누어 읽을 필요가 있다.

SNS에서는, 신속한 수정을 평가하는 목소리도

SNS나 온라인 커뮤니티에서는, 위기감뿐만 아니라, 보도에 대한 받아들이는 방식에 관한 의견도 보인다.

Reddit의 PHP 커뮤니티에 게시된 "Has PHP2Shell borne fruit?"에서는, 공포를 조장하는 기사나 PHP에 대한 비판에 대해, 수정이나 주요 Linux 배포판의 대응이 신속했다는 점을 평가하는 의견이 확인되었다.

이는, 취약성의 심각성과는 별개로, 개발자나 배포원의 대응도 봐주길 바라는 받아들이는 방식이다. 다만, 게시자에 의한 피해 상황의 평가는, 그대로 세계 전체의 안전성을 나타내는 것은 아니다.

한편, 메일 에일리어스 서비스 addy.io에 관한 Reddit 게시물에서는, PHP2Shell에 대한 대응으로 웹 시스템을 일시 중단한 것이 공유되었다. 거기에서는, 메일 배송은 계속된다고 설명되었고, 그 후, 수정을 적용하여 복구했다는 안내도 게재되어 있다.

"서비스를 사용할 수 없다"는 한마디로 끝내지 않고, 어디가 중단되었고, 무엇이 이용 가능하며, 언제 복구되었는지를 전한다. 이러한 정보 공유는, 이용자의 불안을 줄이는 데 참고가 된다.

덧붙여, 여기서 소개한 것은 확인된 개별 게시물이며, SNS 전체의 다수 의견이나 여론 조사를 나타내는 것은 아니다.

사이트를 멈추는 판단에도, 설명이 필요하다

예방적인 중단은, 이용자에게 불편을 초래한다. 문의가 불가능하고, 절차가 진행되지 않으며, 상품을 구매할 수 없는 등의 영향이 나타나면, 운영 측에도 부담이 된다.

그럼에도 불구하고, 수정이 완료될 때까지 외부로부터의 접근을 제한하는 것은, 공격에 대한 노출을 줄이는 의미가 있다. CERT-EU도, 즉시 수정할 수 없는 경우에는, 인터넷에 공개된 애플리케이션을 공공 네트워크에서 격리하는 것을 검토하도록 안내하고 있다.

그렇기 때문에, 중단했는지 여부만으로 운영의 좋고 나쁨을 판단하기는 어렵다.

오히려 물어야 할 것은, 중단의 이유를 설명했는지, 영향을 미치는 기능을 명시했는지, 다음 안내를 어디서 확인할 수 있게 했는지라는 대응이다.

아무 설명 없이 사라진 사이트와, 이용자를 보호하기 위한 대응을 전한 사이트는, 같은 중단이라도 받아들여지는 방식이 달라진다.

일본의 운영자에게도 "해외의 뉴스"가 아니다

PHP의 문제는, 독일어 사이트에만 관련된 이야기가 아니다. 같은 기술을 사용하는 환경이라면, 일본의 사업자도 확인이 필요하다.

그때, 첫 번째 과제는, 전문적인 설정 변경보다도, 자사 사이트를 누가 관리하고 있는지를 명확히 하는 것일지도 모른다.

제작 회사가 담당하고 있는가. 렌탈 서버 회사가 기반을 업데이트하는가. 아니면, 자사 담당자가 대응해야 하는가.

확인하고 싶은 점은, 다음과 같이 정리할 수 있다.

• 사이트의 가동 환경에서, PHP를 사용하고 있는가.
• 이번 취약성에 대한 수정이 적용되었는가.
• 업데이트의 담당자와, 대응 완료의 확인 방법이 정해져 있는가.
• 즉시 수정할 수 없는 경우, 공개를 제한하는 판단을 누가 하는가.

"위탁처가 대응하고 있을 것이다"와 "대응 완료의 연락을 확인했다" 사이에는, 큰 차이가 있다.

또한, CERT-EU는, PHP 8.1 이전의 지원 종료된 계열에 대해, PHP 프로젝트에서 업데이트가 제공되지 않는 점을 나타내고 있다. 오래된 환경을 계속 사용하는 경우에는, 그 환경의 제공원에 의한 수정 여부와, 이행의 필요성을 확인해야 한다.

방어책이 있어도, 업데이트의 대체가 되지는 않는다

공격을 막는 시스템을 도입하고 있으니 괜찮다고 생각하고 싶은 경우도 있다.

그러나, AWS는 이번 문제에 대해, WAF에 의한 대책은 위험에 노출되는 범위를 줄이는 보조책이며, PHP의 업데이트를 대신하는 것이 아니라고 명시하고 있다.

중요한 것은, 어떤 방어 제품을 사용하고 있다는 사실보다, 그 대책이 이번 문제를 어디까지 커버하고 있는가이다.

원 기사에서는, BSI가 일반 이용자에게, 라우터를 외출 시에 접근할 수 있는 상태로 두지 말 것과, 다운로드, 기밀 정보 제공에 주의할 것을 권고한 것도 소개되고 있다.

이는, 모든 이용자의 단말기나 라우터가 이번 취약성에 직접 영향을 받는다는 의미는 아니다. 운영 측의 대응과, 이용자가 일상적으로 행하는 주의는, 나누어 받아들이고 싶다.

"아무 일도 일어나지 않았다"를 지탱하는 일이 있다

큰 경고 후에 두드러진 피해가 전해지지 않으면, "너무 소란스러웠던 것은 아닌가"라고 느끼는 사람도 있을 것이다.

그러나, 피해가 보이지 않는 이유에는, 조기 업데이트나 예방 중단이 작용했을 가능성도 있으며, 아직 파악되지 않은 가능성도 있다. 현 시점의 정보만으로, 그 어느 쪽인지 단정할 수는 없다.

이번 PHP 취약성이 보여주는 것은, 사이트를 계속 공개하는 것만이 운영의 책임이 아니라는 것이다. 필요할 때 멈추고, 수정하고, 상태를 확인하고, 이용자에게 설명한다. 그 일련의 대응도, 서비스를 지탱하는 일이다.

"피해 미확인"이라는 소식은, 대응을 멈추는 이유가 되지 않는다. 우리 환경은 어떻게 되어 있는가. 그 확인까지 마쳐야 비로소, 뉴스를 읽은 것이 실제 대비로 이어진다.

출처

1. BUSINESS-PANORAMA／AFP（2026년 10월 22일）
   BSI가 악용 사례를 확인하지 않았다고 한 것, 침입 가능성을 배제하지 않은 것, 행정 사이트의 복구 상황, 일반 이용자에 대한 주의 환기의 근거.
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation "Today's PHP Security Release, and How We're Strengthening PHP Security"
   10월 21일의 수정판 공개와, 취약성이 초래하는 위험에 대한 공식 설명.
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU "Critical Vulnerabilities in PHP"
   CVE 번호, 심각도, 영향을 미치는 환경, 지원 종료 계열, 수정 및 격리에 관한 공식 조언.
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog: MadPot에 의한 PHP2Shell 관측 보고
   공개 전의 공격 시도와, 실제 환경에서의 성공에 대해서는 불명으로 하는 설명. "공격의 관측"과 "피해 확인"을 구별하는 근거.
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog: PHP2Shell에 대한 WAF의 완화책
   WAF의 위치와, PHP의 업데이트가 필요하다는 것을 설명한 공식 자료.
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com

6. Reddit・r/PHP "Has PHP2Shell borne fruit?"##