「업데이트는 이미 완료되었습니다」と는 한 마디로, 정말로 안심할 수 있을까요.
AI 가 오랫동안 간과되어 온 취약점을 발견하고, 공격자 또한 AI 를 활용해 약점을 탐지하는 시대가 이미 시작되었습니다.
이 글에서 논의하고 싶은 것은 기술의 발전 그 자체보다, 우리가 "누군가가 우리를 지켜줄 것"이라고 믿어 왔던 시스템의 취약점입니다.
2026 년 10 월 21 일, PHP 라는 프로그래밍 언어에 매우 심각한 취약점이 공개되었습니다.
이름은「PHP2Shell」입니다.
PHP 을 모르는 사람에게는 먼 나라 이야기처럼 들릴 수도 있습니다.
하지만 PHP 는 워드프레스를 비롯한 수많은 웹사이트와 업무 시스템을 구동하고 있습니다.
귀사의 홈페이지, 고객용 서비스, 외부 업체에 위탁한 시스템 중 어느 곳이라도 PHP 가 사용되어 있을 가능성이 있습니다.
그리고 이번 문제의 핵심은 AI 기반 보안 연구가 취약점 발견에 크게 기여했다는 점입니다.
AI 는 인간보다 훨씬 빠르게 약점을 찾아낼 수 있다.
그것은 우리를 지키는 힘이 될 것입니다.
하지만, 같은 힘을 공격하는 쪽이 손에 넣었다면 어떨까.
그리고 AI 가 아무리 똑똑해지더라도, 그 결함을 수정하거나 시스템을 정지시키거나, 이를 이용자에게 설명하는 것은 결국 인간이 해야 할 일입니다.
목차
- 1. PHP2Shell 을 통해 실제로 어떤 일이 발생했는지
- 2. 더욱 생각하게 된 것은 2024 년의 이야기였다.
- 3. AI 는 방어하는 일도 공격하는 일도 모두 수행합니다.
- 4. 같은 날, AI 를 지원하던 소프트웨어까지 공격당했다.
- 5. PHP 를 사용하는 사람이 지금 바로 확인해야 할 사항
- PHP2Shell 수정 버전
- 또한 10 월 23 일의 추가 정보
- 먼저 확인해야 할 6 가지 사항
- 6. 외부 벤더에 위임한 경우, 즉시 사용할 수 있는 확인 문
- 7. 관리자가 기술자에게 듣고 싶은 일
1. PHP2Shell 을 통해 실제로 어떤 일이 발생했는지
먼저, 어려운 기술 내용을 가능한 한 간결하게 정리해 보겠습니다.
이번 PHP2Shell에는 두 가지 중대한 취약점이 존재합니다.
- CVE-2026-109618: PHP 가 메모리 부족 등 예외를 처리할 때 내부 데이터가 비정상적인 상태로 변할 수 있는 취약점.
- CVE-2026-109619: 처리가 종료된 후에도 잔존하는 오래된 메모리 정보를 재사용할 수 있는 취약점.
모든 경우, 조건이 충족되면 공격자가 로그인하지 않고도 서버에서 불법 프로그램을 실행할 수 있습니다.
이를 '원격 코드 실행 (RCE)'라고 합니다.
심각도는 모두 CVSS v4.0 기준으로 9.2 입니다.
이번에는 특히 고려해야 할 점은 문제가 웹사이트 화면이나 프로그램 작성 방식에만 국한되지 않는다는 사실입니다.
PHP 그 자체에 취약점이 있었습니다.
즉, WordPress 나 비즈니스 애플리케이션 프로그램에 문제가 없더라도 PHP 실행 환경이 영향을 받을 수 있습니다.
Wiz 연구자들은 WordPress, Drupal, Joomla 를 활용한 환경에서 공격이 성공할 수 있음을 입증했습니다.
물론 PHP 를 사용하는 모든 사이트가 동일한 방식으로 침해당하는 것은 아닙니다. 실제 위험성은 버전, 실행 방식, 설정, 주변 환경에 따라 달라집니다.
그럼에도 불구하고 이번 문제가 큰 이유는 광범위한 웹 서비스의 공통 기반과 밀접하게 연관되어 있기 때문입니다.
그리고 이는 PHP 만의 이야기일 뿐입니다.
우리가 매일 사용하는 편리한 서비스는 눈에 보이지 않는 수많은 소프트웨어에 의해 뒷받침되고 있습니다.
그 중 하나만 무너졌을 때 그 영향은 어디까지 미칠까.
보통 그 전체상을 알고 있는 사람은 몇 명일까.
2. 더 크게 생각하게 된 것은 2024 년의 이야기였습니다.
이번 뉴스에서 제가 기사의 중심에 두고 싶은 것은 바로 이 부분입니다.
PHP Foundation 은 2026 년 10 월 21 일의 공식 설명에서 이번 문제의 근본 원인을 가리키는 징후가 이미 2024 년에 파악되었음을 밝힌 바 있다.
그러나 당시에는 구체적인 공격 실행 방법을 아직 확인하지 못했습니다.
수정안도 하나만은 아니었다.
수정은 기존 시스템과의 호환성을 해칠 수 있습니다.
다른 수정은 새로운 문제를 야기할 우려가 있다.
또한 PHP 를 지원하는 외부 확장 기능에도 영향을 미칩니다.
개발자들은 아무것도 생각하지 않았던 것은 아닙니다.
오히려 영향을 고려해야 했기 때문에 판단이 어려웠습니다.
그곳에는 깊은 내부 지식을 갖춘 개발자의 부족과 합의 도출의 어려움이 겹쳤다.
수정 노력은 여러 차례 정체기에 빠졌다는 것이다.
PHP Foundation 은 이 지연이 조직적 문제였음을 인정하고 있습니다.
저는 이 일을 단순히 "반응이 느렸다고" 비판하는 것으로 끝내지 않으려 합니다.
물론, 중요한 문제를 신속하게 해결하지 못한 책임은 검증되어야 한다.
하지만 동시에 생각해보고 싶은 일도 있다.
판단하려는 시도 자체가 오히려 판단을 불가능하게 만드는 조직.
실패를 피하려는 시도만큼이나 결정이 미루어지는 회의.
업무의 중요성은 커지고 있지만, 이를 감당할 수 있는 인력이 부족해지고 있는 현장입니다.
이건 IT 업계만의 문제일까요.
저는 대형 SI 기업에서 약 23 년간 시스템 엔지니어, 프로젝트 관리자 및 관리직으로 근무해 왔습니다. 이후 병원 정보시스템, 의료관리, 경영기획, 디지털전략 분야에도 참여했습니다.
그런 경력의 맥락에서 다시 한번 되돌아봐야 한다.
책임감을 가진 사람이 있다는 것과, 그 사람이 책임을 다할 수 있는 상태에 있다는 것은 같은 것인가.
책임자를 결정한다고 해서 조직을 지키는 것은 불가능하다.
판단할 권한이 있는지.
필요한 정보가 도착할까요.
전문가가 충분한가.
그 부서나 경영진에게 리스크를 설명할 수 있는가.
그리고 위험하다고 깨달았을 때, 정말로 '멈춰라'라고 말할 수 있을까.
이제야 '책임'이라는 단어에 실질적인 무게가 생기는 것일지도 모른다.
3. AI 는 방어하는 일도 공격하는 일도 모두 수행합니다.
이번 취약점 발견에는 AI 가 활용되었습니다.
OpenAI 의 'Patch the Planet' 프로젝트에서 캘리포니아주는 GPT-5.6 Sol 을 활용해 중대한 문제를 식별했습니다.
Wiz 역시 여러 AI 모델을 활용하여 독립적으로 취약점 발견 및 공격 가능성 검증 작업을 수행했습니다.
여기서는 오해하지 말아야 합니다.
AI 가 PHP 를 공격했다고 하는 이야기는 아닙니다.
보안 연구자가 AI 를 활용해 오랫동안 방치되어 온 취약점을 발견하고 검증했다는 이야기입니다.
이것은 AI 의 큰 잠재력이라고 생각합니다.
인간이 방대한 시간을 들여 확인해 왔던 코드를 AI 가 분석하여 놓치기 쉬운 이상을 찾아냅니다.
이로 인해 공격자가 악용되기 전에 수정할 가능성이 높아집니다.
반면, 또 다른 현실도 존재한다.
JPCERT/CC 는 2026 년 10 월 23 일 국내 조직 대상 불법 접근 경보에 AI 를 활용한 침투 테스트 기지 악용 사례를 추가했습니다.
Cairn, CyberStrikeAI, ARTEX 등의 도구를 활용하여 인터넷에 공개된 웹 애플리케이션의 취약점을 탐지하는 공격 시도가 확인되었습니다.
그리고 AWS 는 PHP2Shell 정보가 공개된 4 일 전인 10 월 17 일에 공격 시도를 감지했다고 발표했습니다.
다만, 공격 시도가 관측되었다는 사실과 시스템에 대한 실제 침입이 성공했다는 것은 별개의 문제입니다. 관측된 통신이 모두 성공한 공격이라고 단정할 수 없습니다.
가장 중요한 것은 공격 준비나 검증에 소요되는 시간이 단축될 수 있다는 점이다.
과거에는 공개된 취약점 정보를 파악하고 공격 방법을 구축하려면 고급 전문 지식과 시간이 필요했습니다.
현재는 AI 가 그 일부에 도움을 주고 있습니다.
물론, AI 를 사용하면 누구나 쉽게 침입할 수 있는 것은 아닙니다.
하지만 공격자에게 시행착오의 부담이 줄어들면 방어측의 여유 시간도 짧아진다.
여기서 우리는 생각을 바꿔야 한다.
정보를 공개했으니 이제부터 대응 방안을 마련하겠습니다.
그렇다면 늦을 수도 있습니다.
위험한 정보가 드러났을 때, 누가 인지하고 누가 판단하며 어디까지 서비스를 중단할 수 있는지에 대한 문제입니다.
그 준비는 뉴스가 되기 전에 반드시 해야 한다.
4. 같은 날, AI 를 지탱하는 소프트웨어까지 공격당했다.
2026 년 10 월 21 일에는 또 다른 중요한 사건이 발생했습니다.
악의적인 코드가 삽입된 'LiteLLM' 버전 1.107.0 이 여러 생성 AI 서비스 연결 등에 활용되고 있습니다.
이것은 PHP2Shell 사건과 별개의 사건입니다.
LiteLLM 개발자의 말에 따르면, 공격자는 탈취한 개발자 인증 정보를 이용해 소프트웨어 배포 과정을 불법적으로 변경했습니다.
결과적으로, 인증 정보를 탈취하는 악성 프로그램이 공식 배포 경로에 포함되었습니다.
문제의 배포물이 삭제되었으나, 영향을 받은 환경에서는 소프트웨어를 재설치만으로는 해결되지 않습니다.
인증 정보가 유출되었을 가능성을 고려하여 API 키 및 관련 인증 정보를 무효화하거나 재발급하고, 환경을 재구성해야 할 수 있습니다.
이 사건은 AI 의 답변이 옳은지 아닌지와는 별개의 위험을 드러냈다.
AI 활용을 위해 도입한 소프트웨어.
개발 효율화를 위해 구축한 자동화 시스템.
편의성 때문에 신뢰하는 공식 배포 경로입니다.
그들도 공격 대상이 됩니다.
AI 의 안전성을 고려할 때 우리는 종종 AI 가 잘못된 답변을 하지 않는지에 대해 걱정합니다.
물론, 그것도 중요하다는 것이다.
하지만 AI 가 올바른 답을 내놓아도 그 뒤에서 작동하는 메커니즘이 반드시 안전하다고 보장할 수는 없습니다.
관리자 및 활용 부서 모두 이 차이를 인지해야 합니다.
5. PHP 를 사용하는 사람이 지금 바로 확인해야 할 사항
이제부터는 실무 이야기를 하겠습니다.
웹사이트나 업무 시스템 관리자라면 이번 PHP2Shell 관련 이슈에 대해 적어도 다음 사항을 반드시 확인해야 합니다.
PHP2Shell 수정 버전
2026 년 10 월 25 일 기준 PHP 공식 수정 버전은 다음과 같습니다.
PHP 계열 수정 완료 버전: PHP 8.28.2.35 이후, PHP 8.38.3.36 이후, PHP 8.48.4.27 이후, PHP 8.58.5.12 이후
PHP 8.1 이전에는 PHP 본체의 일반적인 지원이 종료되었습니다. 사용 중인 운영체제나 제품의 제공자가 개별적으로 패치를 제공할 가능성은 있으나, 지원 상태를 확인하고 지원되는 버전으로의 이동을 계획해야 합니다.
주의할 사항이 있습니다.
Linux 디스트리뷰션이나 상용 제품에서는 보안 패치를 적용하되 오래된 버전 번호를 유지하는 '백포팅'이 이루어질 수 있습니다.
따라서 단순히 숫자만 비교하여 대응되지 않았다고 단정 짓는 것은 위험할 수 있다.
또한, 명령줄에서 확인한 PHP 와 웹 서버가 실제로 사용하는 PHP 가 다를 수 있습니다.
확인한 것이 무엇인지가 중요한 것이다.
또한 10 월 23 일 추가된 정보
PHP 공식은 10 월 23 일 다른 취약점인 'CVE-2026-115560'에 대해서도 주의할 것을 촉구했습니다.
특정 세션 설정과 애플리케이션 처리가 겹치는 경우에만 발생하는 제한적인 문제입니다. 10 월 21 일 수정판을 사용하더라도 조건에 따라 영향을 받을 수 있습니다.
공식은 다음 일반적인 수정이 제공될 때까지 필요에 따라 다음 설정을 비활성화하는 것을 권장합니다.
세션 업로드 진행 상태 활성화: 비활성화
다만, 설정 변경은 해당 기능의 영향을 확인한 후에만 시행합니다. 이번 추가 문제와 10 월 21 일에 수정된 두 가지 중대한 취약점은 구분해야 합니다.
전자의 설정 변경만으로 후자의 대응을 완료할 수는 없습니다.
먼저 확인해야 할 6 가지 사항
- 공개 웹사이트뿐만 아니라 업무 애플리케이션,社内 시스템, 외부 위탁 서비스 등 PHP 가 사용될 가능성이 있는 시스템을 모두 파악해야 합니다.
- 실행 환경과 수정 상태를 확인합니다. 실제로 웹 요청을 처리 중인 PHP 버전, OS 제공자의 패치, 수정 적용 여부, 프로세스 반영 여부를 확인합니다. WordPress 만 업데이트해도 PHP 자체의 문제는 해결되지 않습니다.
- 외부 공개 유무와 중요도를 확인하기 위해 인터넷 접근 여부, 개인정보 처리 여부, 서비스 정지 시 업무에 미치는 영향 정도를 정리합니다.
- PHP2Shell 은 수정과 임시 대응책을 명확히 구분합니다. 수정 버전을 적용하는 것이 완전한 대응의 기본이 되며, WAF(웹 애플리케이션 방화벽) 는 공격 가능성을 줄이는 보조 수단일 뿐 수정을 대체할 수 없습니다. 즉시 수정이 불가능한 공개 서비스의 경우 일시 정지나 접근 제한을 고려해야 합니다.
- AWS 의 관측 결과를 바탕으로 과거 침해 가능성을 검토하고, 최소한 10 월 17 일 이후의 이상한 요청, 비정상 종료, 예상치 못한 파일 변경 또는 프로세스 실행 등을 조사합니다. 수정되어도 과거 침해는 자동으로 사라지지 않습니다.
- 책임자, 보고 대상, 기술적 확인 담당자, 업무 영향도 판단자, 중단 결정자, 이용자 설명 담당자를 명확히 구분해야 하며, 이상 징후가 발견되면 증거를 보존하고 CSIRT 또는 전문가에게 연계해야 합니다.
기술적 조사 및 업데이트는 반드시 관리 권한을 가진 담당자가 PHP 공식 정보 및 벤더의 최신 정보를 준수하여 수행해 주십시오.
6. 외부 벤더에 위임한 경우, 즉시 적용 가능한 확인 문
회사에 전문 정보 시스템 담당자가 없는 경우도 있습니다.
웹 사이트를 외부 제작사에 의뢰하고 있습니다.
클라우드 서비스를 이용해 예약 시스템을 운영하고 있습니다.
계약은 유지되지만, PHP 를 사용하는지 알 수 없습니다.
그런 조직도 생각보다 적지 않다고 생각합니다.
그런 경우에는 어려운 기술 용어를 먼저 이해할 필요는 없습니다.
다음 글을 의뢰자에게 확인 요청용으로 사용하시기 바랍니다.
제목: PHP 의 중대한 취약점 'PHP2Shell'에 대한 대응 현황 확인
2026 년 10 월 21 일에 공개된 PHP 의 중대한 취약점 (CVE-2026-109618, CVE-2026-109619) 에 대해, 저희가 사용하고 있는 시스템에 미치는 영향을 확인하기 위해 연락드립니다.
다음에 대해 답변해 주십시오.
- 이 시스템은 PHP 를 사용하고 있습니까?
- 해당 기능을 사용 중인지 확인해야 이 취약성의 영향을 받을 수 있는지 알 수 있습니다.
- 수정 프로그램 또는 제공자의 수정이 적용되었는지 확인해 주세요. 적용된 경우, 적용 날짜와 확인 결과를 알려주세요.
- 2026 년 10 월 17 일 이후에 이상한 접속이나 침해가 있는지 조사 중입니까?
- 대응되지 않은 항목이 있다면 임시 조치 방안, 대응 예정일, 예상되는 업무 영향에 대해 알려주세요.
- 10 월 23 일 추가 공표된 CVE-2026-115560 에 대한 관련성과 대응 방안을 알려주세요.
보안상의 중요 사항이므로 확인 부탁드립니다.
이 확인문에는 어려운 내용은 담기지 않았습니다.
하지만 중요한 점이 있습니다.
「大丈夫ですか」と尋ねるだけではない。
「무엇을 기준으로 '무방'이라고 판단했는지」를 확인하고 있다.
평안을 얻기 위해 평안을 얻을 수 있는 근거를 찾습니다.
그것은 상대방을 의심하는 것과 다르다고 생각합니다.
7. 관리자가 기술자에게 듣고 싶은 사항
만약 당신이 관리직이나 조직의 책임자라면, 이번 문제를 정보시스템 담당자만의 업무로만 남겨두지 마십시오.
보안 담당자는 업데이트의 필요성을 판단할 수 있습니다.
하지만 서비스 중단으로 인한 매출 감소나 고객에게 미치는 영향까지도 혼자 결정할 수 있는 것은 아닙니다.
병원이라면 진료에 관여하는 시스템인지, 환자나 직원에게 어떤 영향을 미치는지, 대체 수단이 있는지 반드시 고려해야 합니다.
기술적 정확성만으로는 결정할 수 없는 경우도 있다.
그렇기에 관리직에게는 다른 책임이 있습니다.
언제 고쳐질까
물론, 그 질문은 필요하다.
하지만 그것뿐만 아니라, 다음 사항도 확인해 달라.
안전상 멈춰야 한다면 누가 결정할까?
일반 업무를 우선시하면 그 사람의 대응 시간이 부족해지지 않나요?
현재 체제로 어려운 경우라면 무엇을 줄이고 어디에서 지원을 받을 수 있을까요?
저는 여기에는 기술 도입과 디지털 전환 추진의 어려움이 있다고 생각합니다.
시스템을 도입할 때는 예산을 책정해야 합니다.
납기 결정.
책임자를 두다.
하지만 도입 후 수 년간 지속 사용을 위한 유지보수 체계나, 비상 상황에서의 판단까지도 같은 열정으로 고민하고 있는가.
그리고 실무에 통찰을 가진 사람일수록 더 많은 일을 맡기는 것은 아닌지.
기술자가 뛰어나다고 해서 안심할 수는 없다.
노력하지 않아도 유지될 수 있는 조직이 되는가.
그렇게까지 볼 수 있는 것이 관리자의 일인가.
8. AI 시대의 보안은 "인력을 추가하지 않아도 된다"는 이야기라고 할 수 없다.
AI 가 semakin pintar, pekerjaan manusia semakin berkurang.
그런 이야기를 자주 듣는다.
물론입니다. 조사와 분석, 코드 검증, 로그 정리 등 AI 가 도움을 줄 수 있는 업무는 늘어날 것입니다.
하지만, 그 반대로 AI 를 통해 지금까지 발견되지 않았던 문제들이 하나씩 드러날 가능성도 있다.
발견 속도가 빨라지면 수정 속도도 빨라져야 한다.
보고가 늘어나면 그 중에서도 진정으로 위험한 것을 선별해야 한다.
또한 수정으로 인해 다른 시스템이 작동하지 않을 가능성이 있다면 그 판단도 필요합니다.
AI 가 업무의 일부 속도를 높여도 책임이 가벼워진다고 해서 되는 것은 아닙니다.
오히려 판단을 요구받는 경우가 늘어날 수도 있습니다.
이번 PHP Foundation 설명에는 고려할 수 있는 자료가 많습니다.
AI 를 통한 취약점 발견뿐만이 아닙니다.
이를 수정할 숙련된 개발자의 부재.
조직으로 결정을 내리는 어려움.
소수의 사람들이 의존하는 기반을 지탱한다는 현실.
이곳에서 배워야 할 점은 PHP 언어에 대한 단순한 비판이 아니라고 생각합니다.
AI 를 활용한다고 해서 모든 문제가 해결되는 것은 아닙니다.
반대로, AI 가 위험해서 사용하지 않는다는 결론도 아닙니다.
AI 의 힘을 활용하되, 인간이 판단을 내릴 수 있는 시간, 권한, 지식, 그리고 여력을 어떻게 남길 것인가.
그것이 앞으로 조직이 직면한 과제라고 생각합니다.
마지막으로, 지키는 사람을 누가 지키겠는가.
이번 PHP2Shell 뉴스는 단순한 기술 정보로 끝까지 읽을 수도 있습니다.
PHP 를 업데이트하겠습니다.
물론, 그것은 옳습니다.
현재, 영향을 받는 시스템에 필요한 대응책이다.
하지만 그렇게 이야기를 마치면, 더 큰 질문이 남게 된다.
누군가가 수정해 주실 것입니다.
누군가 지켜봐 주겠지.
문제가 발생하면 전문가가 처리해 드립니다.
우리는 그런 '누군가'의 존재를 전제로 많은 편의를 받아오았습니다.
그들 사람들의 부담이 늘지 않았을까.
어려울 때, '어려운'이라고 말할 수 있을까요.
그리고 기술적으로 옳은 판단을 하더라도 조직이 그 판단을 뒷받침해 줄 것인가.
AI 는 앞으로도 더 많은 결함을 발견할 수 있습니다.
공격하는 측도 그 힘을 이용할 것이다.
그렇기에 보호자 측에서는 과거보다 더 빠른 대응이 요구됩니다.
하지만 인간은 기계처럼 무한히 빠르게 일할 수는 없다.
기술이 발전한다면, 그 기술을 뒷받침하는 인간의 작업 방식도 함께 변해야 한다.
시스템의 취약점은 프로그램 내부에 존재합니다.
하지만 조직의 취약성은 사람들이 무리를 하고 있는 한은 여전히 드러나지 않을 수도 있다.
AI 의 발전이 오를 때, 이 두 가지를 함께 살펴보고 싶습니다.
참고 자료 및 확인처
※2026 년 10 월 25 일 기준 공개 정보입니다. 취약점 정보 및 벤더 대응 내용은 업데이트될 수 있으므로 실제 대응 시 최신 공식 정보를 우선적으로 참조하시기 바랍니다.
PHP 및 국내 주의
PHP 공식: 2026 년 10 월 보안 정보
PHP Foundation: 이번 대응 과정과 보안 체계
PHP 취약점 대응 방안
JPCERT/CC: PHP 에서 발견된 다수의 취약점에 대한 주의보
JPCERT/CC: 국내 조직에 대한 불법 접근에 대한 경보
AI 를 활용한 실제 공격에 대한 조사
오픈AI: 지구를 치유하다
Wiz: PHP2Shell 기술 조사
AWS: 10 월 17 일 관측된 공격 시도
LiteLLM: 공식 사고 보고서
LiteLLM: 공격 경로 조사 결과
로비 | 말로 표현할 수 없는 마음을 풀어주는 사람
직업, 인간관계, 인생의 선택. 그리고 AI 와 DX 의 앞선 세계에 서 있는 인간에 대해 쓴다.
혼란을, 다음 판단으로.
#PHP #PHP2Shell #생성 AI #사이버 공격 #사이버 보안 #정보 보안 #취약성 대응 #AI #DX #시스템 운영
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 144청크
원문 보기 | 출처: note.com