2026 년 10 월 21 일, 전 세계 웹사이트들이 큰 혼란에 빠진 것으로 알려졌습니다.
PHP 이라는 프로그래밍 언어에 심각한 취약점이 공개되었습니다.
PHP。
그 이름은 다 알고 있을 것이다. 웹사이트 뒤에서 작동하며 꽤 중요한 역할을 하는 프로그램이다.
어쨌든 이번 취약점을 악용하면 외부에서 서버를 탈취할 수 있다는 소문이 돌고 있습니다.
알겠습니다.
그런 일이니 참으로 어렵다.
하지만 왜 그런 일을 할 수 있단 말인가.
확인해 보았습니다.
메모리 부족. 비정상 종료. 방출된 메모리. Use After Free. 원격 코드 실행.
……。
알 수 없다.
아니, 각 단어의 뜻은 대충 알 수 있다.
하지만 메모리가 부족하면 일반적으로 프로그램이 멈추지 않나요.
이미 멈춰버렸는데 왜 빼앗기는 거야.
그래서 이번에도 ChatGPT에게 물어봤습니다.
그런데도 저는 보안 전문가가 아닙니다. 프로그래밍도 초보자에게는 털이 돋아난 정도일 뿐입니다. 털의 양에 대해서는 건드리지 않으셨으면 합니다. (아니요, 저는 털이 많아요. 좋아요?)
아래는 문과 출신이자 실무에 능통한 사람이 이번 사건을 이해하기 위해 GPT 와 대화하며 기록한 설명입니다.
목차
- 먼저, PHP 가 무엇인지
- 전체 대상을 공격하는 게 아니라고요?
- 메모리 누수?
- 중지한 일을 뒤늦게 정리하다 보니 사고가 발생했습니다.
- 퇴직자가 일하고 있다
- 그렇다면 왜 해킹당하는 것일까
- 사이버펑크 세계가 아니라고?
- 그리고 여기에도 AI 가 등장합니다.
- 그럼 어떻게 해야 할까요
- 그럼에도 불구하고 실무자로서는
먼저, PHP 가 무엇인지
PHP 는 웹사이트 백엔드에서 작동하는 프로그래밍 언어입니다.
예를 들어, 온라인 쇼핑몰에서 상품을 검색하고, 회원 정보를 조회하며, 주문을 접수합니다.
이러한 처리는 웹 서버 측에서 실행하기 위해 사용됩니다.
유명한 WordPress 역시 PHP 로 작동합니다.
그리고 여기서 중요한 점은 PHP 가 개별 웹사이트 프로그램을 실행하기 위한 공통 기반이 된다는 사실입니다.
즉, 인터넷 상점을 만든 사람이 프로그램을 얼마나 정확하게 작성하더라도, 그 아래에서 작동하는 PHP 자체에 문제가 있다면 영향을 받을 수 있습니다.
우리들이 사용하는 일본어를 예로 들자면, 일본어 실력이 얼마나 뛰어난 사람이든 말하더라도 일본어 자체에 특정 조합이 반드시 악마를 불러일으킨다고 한다면, 그 조합을 입에 올리면 악마가 찾아오는 것입니다. 바로 그런 것입니다.
오히려 더 헷갈릴까? 아, GPT 님이 "조금 다르다"고 지적해 주셨네요.……まあ, 일단은 괜찮다.
이번에 발견된 것은 바로 이러한 PHP 자체의 취약점입니다.
이름은「PHP2Shell」입니다.
조개껍질……? 갑각류……? 아, 이제 더 이상 몰라. 아니, 그런 이름들이 있다는 거지. 일단 계속해 보자.
그리고 문제가 된 취약점은 두 가지로, 둘 다 심각도가 매우 높았습니다.
그렇다면 어떤 일이 벌어질까.
전부 걸고 공격하는 건 아니죠?
처음 생각한 것은 총포격이었다.
비밀번호를 여러 번 시도하거나, 대량의 요청을 보내 서버를 마비시키십시오.
그런 종류의 공격이라고 생각했다.
그렇지 않다.
이번 문제는 비밀번호를 해독하는 것이 아닙니다.
서버 자체에 본래 수행해서는 안 되는 처리를 허용해버리는 것이었다.
이를 원격 코드 실행 (RCE) 이라고 부릅니다.
원격 코드 실행. 원격지에서 코드를 실행하는 행위. 그대로의 의미.
하지만 이름만 알더라도 그 원리는 통하지 않습니다.
정작 타인의 서버에 임의로 어떤 처리를 실행시키는지.
그리고 등장한 것이 바로 메모리였습니다.
메모리 누수?
먼저 떠오른 것은 메모리 누수였습니다.
프로그램이 종료된 메모리를 방치하여 사용량이 계속 증가하는 문제입니다.
이건 알고 있습니다. 회사에서 캐비넷에서 가져온 파일을 언제까지 돌려주지 않고, 오히려 하나씩 하나씩 가져와서 책상 위가 가득 차는 그런 상태입니다. 음, 이 비유는 딱 맞네요.
하지만 GPT 님에 따르면 이번 문제는 그와 다르다.
첫 번째 문제는 메모리 부족으로 처리가 중단될 때, 작성 중인 데이터를 정상적인 것으로 잘못 처리하는 문제입니다.
두 번째 문제는 메모리를 해제했는데도 해당 영역을 가리키는 정보가 남아 있어 나중에 다시 참조하는 문제입니다.
……。
잠깐만요.
그렇군요, 그 두 번째는.
사용 가능한 메모리를 다시 쓸 거야? 없는 걸? 이미 없는 걸? 지운 건 너였지?
그건 정말 안 좋은 건 아닌지.
그리고 첫 번째는 다음과 같습니다.
메모리가 부족해 처리가 중단되었는데, 왜 완성되지 않은 데이터를 사용하느냐? 완성되지 않은 것은 완성되지 않은 것이니 사용에는 적합하지 않겠는가.
여기서야 비로소 이번 사건의 기묘함이 드러났습니다.
중지한 일을 뒤늦게 정리하다 보니 사고가 발생했습니다.
먼저, 첫 번째 문제를 살펴보자.
기술적으로는 CVE-2026-109618 이라는 취약점입니다.
그 이름은 정말로 기억하기 어렵다. 더 이상 기억할 필요가 없다. 나는 잊어버렸다. 그런 일에 뇌의 메모리를 할애할 필요는 없다.
이 문제의 핵심은 이상을 감지하고 처리를 중단한 이후에 있습니다.
메모리 확보 실패.
PHP 는 예외를 감지했습니다.
따라서 일반적인 처리를 중단했습니다.
지금까지도 괜찮습니다.
문제는 그 이후의 처리 문제입니다.
예를 들어, PHP 는 웹사이트에서 전송된 정보를 처리할 때 먼저 메모리에 데이터를 할당합니다. 그리고 관리 정보에 '여기에 데이터가 하나 있다'고 기록한 후 실제 데이터를 등록해 나갑니다. 그러나 관리 정보에는 '데이터가 하나 있다'고 기록되어 있지만, 핵심인 데이터 등록이 아직 완료되지 않은 순간 메모리 부족이 발생할 수 있습니다.
그런데 처리가 중단됩니다.
즉, 앞서 '한 가지'라고 기록한 바 있는데, 핵심인 그 한 가지를 등록하기 전에 멈춰버린 것입니다.
그러나 후속 처리를 수행하는 프로그램은 관리 정보에 '한 건이 있다'고 기록되어 있으므로, 해당 데이터가 정상적인 것으로 간주하고 처리를 계속해버립니다.
아니요, 등록이 완료된 후에야 '한 건 있습니다'로 설정해 주세요.
완료되지 않은 사건의 처리가 완료 처리로 잘못 적용되어 있고, 심지어 취소 처리까지 불가능한 상태입니다.
네……? 그건 나중에 문제가 될 기운이 선명하게 느껴져. 송장 처리 같은 건데.
아, 그렇군요.
이 내용을 실제 업무에 적용해 보겠습니다. 이제부터 짧은 연극을 삽입해 보겠습니다.
어떤 회사에서 영수증을 등록하고 있습니다. "새로운 영수증을 한 건 등록합니다"——네, 등록 건수를 한 건 늘렸습니다. "그럼 거래처와 금액을 입력해서……아, 오류가 났습니다. 등록을 취소합니다"——알겠습니다. 처리를 맡기겠습니다. 처리 담당자가 등장합니다.——네, 이미 등록된 영수증이 한 건 있네요. 그럼 이것을 정리하겠습니다. 먼저 거래처는……
"아직 입력하지 않았습니다"——그럼 금액은? "그것도 아직입니다"
전표가 뭐야?
완료하지 않았습니다.
—하지만 등록 건수는 하나뿐인가요? "건수만 미리 등록해버린 거예요."
그럼, 등록한 건물이 어디에 있죠? "없어요."
—그렇게 적혀 있잖아요!
그래서 등록 중 오류가 났단 거야!
—그럼 건수를 되돌려달라고 하세요! "되돌리지 않았어요!"
왜냐?…… 아니, 그렇다. 등록이 완료된 후에야『한 건 있습니다』라고 하세요.
사람이라면 여기서 작업을 멈추고 확인했을 것이다. 그러나 프로그램은 관리 정보를 신뢰하고 처리를 계속 진행한다.
무슨 처리를 하고 있니, 너야. 아, 뒤처리인가.
알겠습니다. 완성되지 않은 데이터를 정리하려는 거군요.
……。
아니요, 완성된 제품과 같은 순서로 아직 완성되지 않은 데이터를 정리해서는 안 되겠어요. 분류, 다이치.
물론 실제 PHP 가 영수처를 처리하고 있는 것은 아닙니다.
문제는 아직 올바르게 완성되지 않은 데이터를 후속 처리 프로그램이 정상적인 것으로 간주하고, 일반적인 절차에 따라 그 내용을 참조해버리는 일입니다.
……참조?
그건 그냥 없애려던 게 아니었을까?
데이터를 삭제할 때도 해당 데이터의 종류를 확인해야 하는 것 같습니다.
데이터의 종류에 따라 정리 방법이 다릅니다. 단순한 숫자라면 그렇지만 문자열이나 배열 같은 경우에는 각각 정리해야 할 항목이 있습니다.
따라서 먼저 종류를 확인하고 그에 맞는 정리 방법을 선택하세요.
알겠습니다. 버리기 전에 선별하는 것이군요.
그런데 이번 문제에서는 핵심인 종류를 나타내는 정보가 아직 정확히 설정되지 않았습니다.
그런데도 그곳을 조사하고, 기록된 내용에 따라 정리하려 한다.
……。
아니, 그렇다고 해서 그 구분 표시가 반드시 정확한 건 아니라는 거야!
구별, 다이치.
올바른 구분, 더 진지하게.
이로 인해 프로그램이 비정상 동작을 할 수 있습니다.
그리고 공격자는 바로 그 이상점을 노리고 의도적으로 문제를 일으킬 수 있는 데이터를 전송합니다.
즉, 단순한 프로그램의 결함이 공격 수단으로 악용될 수 있다는 뜻이다.
이상 징후가 감지되어 처리가 중단되었음에도 불구하고.
퇴직자가 일하고 있다
다음으로 두 번째 항목입니다.
이것은 CVE-2026-109619 입니다.
사용 후 방출 (Use After Free) 이라는 문제, 일본어에서는 '해방 후 사용'이라고 불립니다.
이 문제를 이해하려면 메모리 해제라는 행위를 조금 더 깊이 생각해 봐야 합니다.
메모리를 해제한다는 것은 해당 물리적 영역이 소멸한다는 뜻이 아닙니다.
그 영역을 다른 처리로 활용 가능하도록 하는 것입니다.
예를 들어, 회사의 자리라고 가정해 보십시오.
어떤 직원이 퇴직했습니다.
물론, 해당 직원이 사용하던 자리도 비워둘 수 있습니다.
결국 새로운 사원이 입사하여 그 자리를 차지하게 되었습니다.
그런데 회사 내 좌석표 관리 대장에는 이전 직원의 정보가 남아있었다.
어느 날 관리 시스템이 관리 명부를 참조했습니다.
이 자리에는 타나카 씨가 계신가요
아니요, 타나카 씨는 퇴사했습니다.
하지만 관리 장부에에는 나카다 씨라는 이름만 적혀 있습니다.
현재 자리에는 사토미가 앉아 있습니다.
아니요. 그 자리는 타나카 씨의 자리입니다. 타나카 씨에게 처리를 요청하겠습니다.
그래서, 타나카 씨는 없단 말이지!
그 자리에서 지시를 내렸습니다.
그래서 그 곳에 있는 사람이 사토 씨라고!
"……츠우~"
내, 들어봐. 제대로 들어봐.
이번 문제는 이와 유사하다.
요청 처리가 완료되었습니다.
해제된 메모리를 사용했습니다.
하지만 메모리 자체는 제대로 해제되었음에도 해당 위치를 가리키는 정보만 PHP 의 처리 프로세스에 남아있을 수 있습니다. 이후 같은 프로세스가 다음 요청을 받으면 그 오래된 정보를 사용하게 됩니다.
즉, 이미 다른 용도로 사용될 수 있는 영역을 이전 데이터가 남아있는 것으로 간주해버리는 것입니다.
이것은 Use After Free입니다.
보물은 이미 발굴되어 버린 상태다. 그럼에도 낡은 보물 지도를 믿고 같은 곳을 다시 파헤치려 하는 셈이다. 게다가 그 장소에는 이미 다른 누군가가 다른 것을—예를 들어 산업폐기물—을 묻어두었을지도 모른다. 파낸 것이 있다면 그것은 이미 너의 보물이 아니다. 오히려 독을 뿌린 쓰레기일지도 모른다. 그리고 그것을 보물이라고 착각하고 가져가버리는 것이다.
물론 퇴직자의 자리에서 지시만 내린다면 회사 내에서 다소 혼란이 발생할 정도일 것이다. (……아, 오보의 이야기는 잠시 잊어두자.)
그러나 컴퓨터 내부에서 참조하는 것은 단순한 이름이 아닙니다.
프로그램의 동작을 결정하는 정보입니다.
공격자가 해당 위치에 미리 준비한 데이터를 배치할 수 있는 상황을 조성하면, PHP 의 처리가 원래 의도하지 않은 방향으로 유도될 가능성이 있습니다.
아, 알겠습니다.
알겠습니다.
이미 사라져야 할 그 사람을 믿고 일을 진행하다 보니, 어느새 다른 사람의 지시대로 움직이고 있었다.
그런군요.
……아, 그런 뜻이 아니었다.
이거 진짜 위험하네. 위험한 위험한 위험.
그렇다면 왜 해커들에게 털릴까
지금까지 두 가지 문제는 어느 정도 파악했습니다.
하지만 의문이 남는다.
메모리 관리에 문제가 있다는 것과 서버가 탈취당한다는 것은 별개의 문제일 수 있는가.
예를 들어, 완성되지 않은 관리 정보를 참조하여 프로그램이 충돌할 수 있습니다.
그렇다면 이해가 갑니다.
오래된 메모리를 참조하여 이상한 데이터를 읽어들입니다.
그것도 이해할 수 있다.
하지만 그로부터 왜 공격자의 명령을 따르려 하는 말이 되는 것일까.
이 부분이 이번 공격의 핵심입니다.
메모리에는 단순한 텍스트나 숫자뿐만 아니라, "프로그램이 다음에 무엇을 수행할지 결정하는" 정보도 포함되어 있습니다.
원래 이러한 정보는 올바르게 관리되어야 합니다.
그러나 이번 결함을 이용하면 프로그램이 본래 신뢰해서는 안 되는 메모리 영역의 내용을 신뢰하게 할 수 있는 경우가 있다.
그리고 공격자가 해당 내용이나 메모리 배치를 적절히 조작할 수 있다면, 프로그램의 실행 흐름 자체를 변경할 수 있을지도 모릅니다.
즉, 외부에서,
이 명령을 실행해 주세요.
그것은 정당한 요청을 하는 것이 아닙니다.
프로그램이 잘못된 관리 정보를 바탕으로 공격자에게 유리한 처리를 실행해버립니다.
그런 모양이다.
이것이 성공하면 데이터 읽기, 변조, 불법 프로그램 설치 등 다양한 문제가 발생할 수 있습니다.
물론 메모리 관리의 오류가 발생한다고 해서 반드시 침략당하는 것은 아닙니다.
프로그램이 단순히 중단되는 경우도 있으며, 공격을 성공시키려면 환경과 조건이 갖춰져 있어야 합니다.
하지만 이번에는 연구자들이 실제 원격으로 코드를 실행할 수 있음을 검증 환경에서 입증했습니다.
알겠습니다.
단순히 '파손'이라는 문제만이 아닙니다.
조작하면 공격자가 원하는 대로 움직이게 됩니다.
그것이 사실입니다.
사이버펑크 세계가 아닌가요
이 정도까지 들으니 묘한 낯선 느낌을 느꼈다.
SF나 사이버펑크 작품에서 이런 공격을 본 적이 있다고 느껴집니다.
적의 시스템에 이상을 일으키다.
시스템이 정지되었습니다.
복구 처리가 시작됩니다.
복구 처리의 틈을 노려 공격 프로그램을 침투시킵니다.
그런 식으로, 정말로 위대한 해커들이 할 법한 공격이다.
이 문제도 그와 유사하다.
다만, 엄밀히 말하면 조금 다르다는 듯합니다.
서버 전체를 재부팅할 필요는 없습니다.
일반적인 요청 처리 과정에서 발생하는 예외나, 처리가 완료되어 다음 요청으로 전환될 때 발생하는 불일치를 활용합니다.
따라서 영화처럼 거대한 시스템을 정지시킬 필요는 없다.
인터넷을 통해 특수한 요청만 보낼 경우 공격의 계기를 만들 수 있습니다.
그런데 로그인조차 필요 없는 경우도 있다는 것입니다.
……。
사이버펑크의 해킹이라는 말은 화려한 화면에 대량의 문자열이 흐르고, 검은 배경에 녹색 글씨로 'ACCESS GRANTED' 같은 문구가 표시되는 듯한 인상을 줍니다.
실제로는 웹 서버 내부에서 메모리 관리의 일관성이 무너집니다.
지미하다. 그러나 결과는 화려하다.
공연은 평범했지만 피해는 파산이었다. 에지를 공격했다.
그리고 여기에도 AI 가 등장합니다.
이번 사건에는 또 다른 흥미로운 점이 있습니다.
AI 입니다.
이번 취약점 발견과 공격 가능성 검증에는 AI 를 활용한 연구가 크게 기여했습니다.
보안 기업 Wiz 는 "여러 AI 모델을 활용하여 PHP 에 숨겨진 취약점을 발견하고, 이를 실제 공격으로 성공적으로 검증했다"고 설명했습니다.
다만 오해해서는 안 됩니다.
이번 결함은 AI 가 만든 것이 아니며, AI 가 PHP 서버에 무단 침입했다는 이야기도 아닙니다.
결함 자체는 이미 존재해 있었다.
문제는 그 결함을 실제 공격에 활용할 수 있음을 증명하는 것이 과거에는 매우 어려웠다는 점에 있습니다.
메모리 사용 방식을 조사하고, 오류 발생 조건을 파악하며, 프로그램 동작을 분석합니다. 시도하고 실패하며, 조건을 변경하고 다시 시도합니다.
이러한 작업에는 높은 수준의 전문 지식과 상당한 시행착오, 즉 반복 횟수가 필요합니다.
그렇기에 AI 가 그 역할을 맡게 됩니다.
AI 가 분석이나 시행착오를 지원하며, 때로는 그 일부를 대신함으로써 과거에는 어려웠던 결함 발견이나 공격 시뮬레이션이 현실적으로 가능해지기 시작했습니다.
물론, 이는 방어측에게도 큰 이점이 됩니다.
인간이 놓치던 문제를 AI 의 도움으로 발견하고 수정할 수 있기 때문이다.
그러나 같은 기술은 공격자도 활용할 수 있다.
즉,
결함이 있기는 하지만, 공격 수단으로 활용하기는 어렵다.
이러한 상태가 앞으로 안전의 근거가 될 수 없을 수도 있습니다.
이러한 점을 고려하면, 이는 PHP 만의 문제일 뿐입니다.
AI 가 사이버 보안 분야에 어떤 변화를 가져올지.
その一端を見せつけ、実証した事件でもあるのだろう。
그럼 어떻게 해야 할까요
행운히 이번 두 가지 취약점에 대해 PHP 개발자가 수정 버전을 공개했습니다.
2026 년 10 월 24 일 현재, PHP 8.2 에서 8.5 의 각 버전 시리즈에 대응된 버전이 제공되고 있습니다.
웹사이트 운영자는 PHP 사용 현황을 확인하고 필요한 업데이트를 적용하는 것이 중요합니다.
반면, 단순히 웹 사이트를閲覧하는 사용자라면 기본적으로 자신의 컴퓨터나 스마트폰에서 PHP 를 업데이트할 필요가 없습니다. 문제의 핵심은 서버 측에서 실행되는 PHP 에 있기 때문입니다. 본질적으로, 그저 보는 것이라면 사용하고 있지 않은 PHP 가 아니겠습니까.
그리고 이번 사건에 보고된 공격 시도와 실제로 서버 침입이 성공한 사례는 구분하여 고려해야 한다.
취약점이 존재한다.
공격을 시도하는 자가 있다.
공격으로서 성립함이 입증되었다.
이것들은 매우 중요한 사항이지만, 모든 PHP 서버가 무조건 침입당하는 것은 아닙니다.
그곳에서는 차분히 생각할 수 있다.
그렇다면 실무자로서는
지금까지 조사해 온 결과, 이번 문제의 핵심을 어느 정도 파악한 것 같습니다.
그리고 이번 사건에서 가장 기억에 남은 것은 사실 메모리도 인공지능도 아니었다.
이상 감지 가능성과 이상 발생 후 안전하게 처리할 수 있는 가능성은 동일하지 않습니다.
그렇다.
우리는 실무자로서 일이 잘 풀리지 않을 때 매일 어떻게 대처해야 할지 고민합니다.
문제가 발생하면 보고하고 작업을 중단한 후 관련자에게 연락하여 처리되지 않은 업무를 정리한 뒤, 필요시 원상태로 복원하고 재발 방지 대책을 마련합니다.
이러한 절차가 있습니다.
하지만 생각해보면, 그 곳에 하나의 전제가 깔려 있습니다.
이상 발생 후에도 후속 조치 절차는 정상적으로 진행됩니다.
이러한 전제 하에.
이번 사건은 그 전제를 직접 공격했습니다.
정상적으로 작동할 때는 문제가 발생하지 않습니다. 이상을 감지할 수도 있지만, 이상 발생 후의 처리가 항상 안전하다고 보장할 수는 없습니다.
그리고 그 이후의 과정 자체가 새로운 문제를 야기하게 됩니다.
……。
어떤 말인가 하면, 저에게도 연관이 있는 이야기입니다.
문제가 발생하자 작업을 중단하고, 사태를 수습하기 위해 관계자들이 모여 회의를 열었습니다. 대응책을 논의한 끝에 새로운 규칙을 마련했으나, 이후 후속 조치 회의에서 추가적인 문제가 발생했습니다.
……。
아니요.
PHP 만으로 된 것 같지는 않아.
참고 자료
- PHP 취약점 대응 방안 (PHP2Shell)
- PHP 공식: 메모리 부족 발생 시의 비정상 처리 관련 취약점
- PHP 공식: 해방된 메모리 참조 취약점
- Wiz Research: PHP2Shell 과 AI 를 활용한 취약점 연구
본 문서의 업무 관련 비유는 기술적 원리를 쉽게 이해하도록 돕기 위한 것이지, 실제 프로그램의 동작을 그대로 반영한 것은 아닙니다.
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 133청크
원문 보기 | 출처: note.com