요약
PHP의 원격 코드 실행 취약점 두 개가 고쳐졌고, 재단은 보안 체계를 손보겠다고 밝혔습니다.
PHP 재단이 10월 21일 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 내놓으며 취약점의 발견과 수정 과정을 공개했습니다. 두 결함 모두 원격 코드 실행(외부에서 서버에 임의 코드를 실행시키는 공격)으로 이어질 수 있습니다.
왜 중요한가
- Apache에 PHP를 모듈로 붙인 mod_php 환경에서는 로그인 없는 요청 하나로 기본 설정의 서버를 장악할 수 있었습니다.
- 재단은 2024년에 단서를 찾고도 수정이 몇 달씩 멈춘 것을 의사결정 구조와 인력 부족이 낳은 실패라고 인정했습니다.
- AI를 활용한 보안 연구가 늘면서 7월 이후 걸러 낸 무효·중복 보고만 100건이 넘습니다.
핵심 내용
- 첫째 결함(CVE-2026-109618)은 메모리 한도에 걸린 순간 덜 만들어진 내부 데이터가 남아 메모리를 망가뜨립니다.
- 둘째 결함(CVE-2026-109619)은 치명적 오류 뒤 남은 상태 때문에 다음 요청이 해제된 메모리를 다시 씁니다.
- 8월 보안 업체 캘리프와 오픈AI가 같은 원인을 각각 보고했고, 이어 위즈도 보고했습니다.
- 공개 전날 캘리프가 공격 시연 영상을 실수로 올렸고, 체인가드는 공개 6시간여 전에 수정본 이미지를 배포해 엠바고(공개 유예 약속)를 깼습니다.
- 재단은 보안 인력을 늘리고, 보안팀의 결정 방식을 합의제에서 다수결로 바꾸기로 했습니다.
HN 반응
- 여러 이용자가 멀티파트 업로드를 막는 nginx 설정 같은 임시 대응을 댓글로 나눴고, 이 덕분에 패치 전 공격 시도를 막아 냈다는 경험담도 나왔습니다.
- 캘리프가 영상을 실수로 올렸다는 재단 설명에는 미리 만들어 둔 홍보 영상을 서둘러 올린 것이라는 비판이 이어졌습니다.
다시는 이런 말을 못 들으실 수도 있습니다. 저는 성질 사나운 냉소가이고, 여기 죽치고 있는 게 정신건강에 좋은지도 잘 모르겠거든요. 그래도 HN이 있어서 정말 다행입니다.
오늘 이 문제를 해결하느라 여러 서버를 뛰어다니는 동안 알게 된 게 있습니다. 제가 GMT 기준 새벽에 쓴 세 줄짜리 nginx 완화책(멀티파트 업로드 차단)이, 제가 끌 수 없었던 취약한 서버를 조용히 지켜 주고 있었더군요. 앤트로픽, 오픈AI, Qwen 클라우드, 바이두, 아마 AWS와 메타까지, 주류 에이전트형 AI 도구 하나하나가 퍼붓는 공격을 막아 준 겁니다.
PHP 패치가 실제로 배포되기 한 시간 전부터 말이죠.
HN 토론이 없었다면 완화책을 알려 주는 사람을 충분히 만나지 못했을 테고, 서버 한 대를 잃었을 겁니다. 특히 두 번째 완화책을 알려 주신 분들께 감사드립니다.
맞아요!!!!
오늘 여기 있는 게 정말 좋았어요.
수많은 똑똑한 사람들이 함께 소리 지르고 욕하면서 밀려드는 파도를 버텨 보려고 애쓰는 모습이라니.
상업적 인터넷에서 이런 곳은 이제 많지 않아요. 특히 AI가 휩쓰는 이 멋진 신세계에서는요.
포스의 거대한 동요가 느껴졌어요. 물론 좋은 쪽으로요.
함께라면 우리는 강해요. 포스가 우리 모두와 함께하길!
옛날 자본주의는 좋고, 요즘 자본주의는 나쁘다는 거군요.
그게 그렇게 심각한가요? 공격 횟수를 실제로 재 보셨나요?
저는 작은 서버 하나를 운영합니다. 이 서버를 무척 아끼고요. 데비안 패키지가 나오고 한 시간쯤 뒤에 패치했고, 그 뒤로는 신경 쓰지 않았습니다. 제 작은 서버가 이미 뚫렸을 가능성이 실제로 있다는 말씀입니까?
[수정:] 제 서버도 꽤 공개적입니다. 두 번째 수준 도메인 네 개와 수많은 서브도메인을 호스팅하고, 사람과 봇 트래픽을 모두 받습니다. PHP를 쓰는 서브도메인은 한두 개뿐이지만, 합리적인 공격자라면 전부 시도해 볼 겁니다.
쏟아지는 수준은 아닙니다. 수천 건이 아니라 수십 건에서 수백 건 정도입니다.
하지만 성공할 가능성이 매우 높았을 겁니다. 거의 그대로 가져다 쓸 수 있는 취약점이니까요.
어느 쪽이라고 단정할 수는 없습니다. 로그 파일에서 다음과 같은 경로로 연달아 들어온 POST 요청이 있는지 확인해 보세요.
제 경우 "딱 봐도 PHP 앱"인 도메인은 전부 공격을 받았습니다. 직접 만든 앱 도메인(딱 봐서는 PHP인지 알 수 없는 것들)은 하나도 당하지 않았고요. 다만 시간이 지나면 직접 만든 도메인에도 모든 웹사이트가 받는 것처럼 WP 취약점 같은 시시한 탐색이 잔뜩 들어오긴 합니다.
그건 맞지 않는 것 같은데요. 저는 17일부터 이미 그런 요청을 받았습니다(제 로그가 거슬러 올라가는 한계가 거기까지일 뿐입니다). 그리고 맞아요, grokbot이니 claudebot이니 하는 식으로 UA를 위조해서 들어왔어요. 다만 이런 봇 트래픽은 한동안 계속 받아 왔습니다. 같은 IP가 요청마다 UA를 바꾸는 걸 보면 진짜 에이전트는 아닌 것 같습니다.
감사합니다(저는 django 사이트입니다).
구글 클라우드 IP에서 온 것 같네요.
공격자가 조금이라도 뒷정리를 하는 데 그렇게 대단한 실력이 필요하지는 않을 텐데요?
로그를 어떻게 관리하느냐에 달렸습니다. 로그를 원격 서버로 수집하고 있다면 공격자가 그걸 지우기는 꽤 어렵습니다. 또 오늘 시도된 PHP 익스플로잇 대부분은 정교한 공격이 아니라 무차별 대입이었을 테고, 목적은 코인 채굴이나 봇넷 편입 같은 것일 거라고 짐작합니다.
필요 없다고 생각합니다. 다만 저는 PHP 애플리케이션을 노린 자동화 공격 중에 굳이 흔적을 숨기려 한 것을 한 번도 본 적이 없습니다.
공격자가 아는 사람이거나 끈질기게 달라붙는 위협 세력이라면 숨길 수도 있겠죠. 하지만 이런 건 대개 웜처럼 움직입니다. 한 상자를 공격하고, 그걸 이용해 다른 상자를 공격하고, 다음으로 넘어가는 식이죠.
이 서버에 끈질긴 해커가 붙어 있을 가능성은 반반이라고 봅니다. 다만 제가 본 건 자동화된 공격 같았습니다. 말하자면 AI 스크립트 키디죠. 이 서버들에는 평소에도 전형적인 PHP 앱 탐색(WP2shell 등)이 들어옵니다.
참고로 실제로 가장 많았던 건 클라우드 기반 AI 검색 API로 보이는 곳에서 들어온 요청이었는데, 누가 플러그를 뽑기라도 한 것처럼 동시에 뚝 끊겼습니다. 에이전트형 검색 API를 운영하는 쪽에서 탐색에 가담하지 않기로 결정했을 수도 있겠죠.
그 말에는 동의합니다. 그런 스크립트 대부분은 최대한 게으르게 만들어져 있죠.
하지만 생존자 편향이 작용하는 건 아닐까 하는 생각이 자꾸 듭니다.
양도 질의 한 형태입니다.
코인 채굴기들이 자원을 두고 서로 치고받는 통에 사이트 성능이 바닥을 쳐도 들여다보지 않는 운영자가 엄청나게 많습니다. 어차피 유능한 관리자라면 외부로 나가는 트래픽만 보고도 알아챌 텐데, 그들의 눈을 피하겠다고 정교한 공격에 시간을 쓸 이유가 있을까요?
저는 Claude 세션 하나를 시켜서 15분마다 HN 스레드를 확인하게 했습니다. 링크를 따라가면서 공개된 익스플로잇이나 완화책, 제가 놓친 게 없는지 찾게 했죠. 글을 올려 주신 모든 분들 덕분에 하루 종일 한결 안심하고 필요한 조치를 다 할 수 있었습니다. 감사합니다.
인터넷의 보안 모델 자체를 바꿔야 합니다.
예를 들어 웹쇼핑몰에서 물건을 살 때, 그 쇼핑몰이 왜 제 개인정보를 가지고 있어야 합니까? 토큰만 주면 되지 않나요? 쇼핑몰은 그 토큰으로 택배를 보내고, 토큰에 연결된 주소는 우편 시스템만 알고 있는 식으로요.
그리고 광고 목적의 사용자 추적은 당연히 금지해야 하고요.
저는 이게 전부 막다른 길이라고 생각합니다. 아파트를 튼튼한 자물쇠 같은 것만으로 지키려는 셈이니까요. 현대 사회는 처벌과 도덕 규범으로 범죄를 막습니다. 자물쇠만으로 막는 게 아니고요.
이론상으로는 그렇죠.
인터넷에서 익명성을 완전히 없애지 않고 그게 어떻게 가능합니까? 사이버 범죄에 신경 쓰지 않는 나라에서 접속할 수 있는 한, 남을 해킹하는 걸 무슨 수로 막겠어요? 북한 해커를 처벌할 수는 영원히 없을 텐데요.
이 경우에는 해커를 신원 파악해서 기소하는 쪽이 맞다고 생각합니다. 일반적으로 신원을 밝혀내기는 어렵지만, IP를 쓰고 있는 한 그렇지도 않습니다. ISP는 바로 이런 경우를 위해 이미 IP 매핑을 저장해 두고 있고요.
그럴 필요 없습니다. 나라 전체에 벌금을 물리면 됩니다.
고전적인 사회는 그랬다는 말씀이겠죠. 현대 사회는 점점 더 자물쇠가 다시 필요해지고 있습니다.
Shopify를 다시 발명하자는 얘기네요.
마찰을 늘리는 것은 실제 상거래 세계에서는 무조건 안 되는 일입니다.
제대로 구현하면 지금 방식보다 마찰이 오히려 적습니다.
애플페이가 카드 정보를 직접 입력하는 것보다 온라인 결제에서 마찰이 적은 것과 같아요. 여기서 한 걸음 더 나아가 애플이 배송에 필요한 개인정보를 그때그때 제공해 줄 수도 있고요.
물론 청구지와 배송지가 다른 경우처럼 수동으로 덮어쓸 수 있어야 하긴 해요. 그래도 대부분의 정상적인 경로는 간소화할 수 있어요.
영지식 증명과 PKI 시스템이면 그 모든 걸 해결할 수 있습니다. 누구도 여러분의 개인정보를 전부 알 필요가 없고, 알아야 하는 사람만 알면 되며, 접근 권한도 쉽게 회수할 수 있으니까요. 하지만 이걸 결정하는 주체가 사람인 한 그런 일은 절대 일어나지 않을 것 같습니다. 적어도 지각 있는 AI가 권력을 쥐기 전까지는요.
저희는 사람들이 Apple Relay 이메일을 만들어서 가입하고는, 그 이메일을 비활성화해 놓고 작동하지 않는다고 항의하는 문제를 겪었습니다. 보통 사람들은 우리 같은 기술 감각이 없으니, 그 사람들에게 맞춰서 만들어야 합니다.
마찰이라... 해킹당하는 것, 아니면 고객의 개인정보나 금융 정보가 유출되는 것 같은 거요?
@patio11이 쓴 깔끔한 블로그 글이 있습니다. https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/ 이 문제에도 적용되는 이야기인데, 규모가 더 큽니다.
"결제를 마치려면 페이스북 계정을 만드세요" 같은 마찰이죠.
저한테는 이 부분이 가장 놀라웠습니다. Calif가 유출을 보고 엠바고가 깨졌다고 판단해서, 서둘러 [애니메이션 춤 영상] 홍보 영상을 올렸다는 얘기로 들리는데요. 이보다는 훨씬 나을 거라고 기대했습니다.
실수로요?
누가 넘어지면서 마우스 위로 쓰러졌는데 그 바람에 화면 녹화가 켜졌고, 익스플로잇을 몇 번 돌렸고, 애니메이션 소녀 에셋과 배경음악을 구했고, 그걸 전부 프리미어에 던져 넣고, 이상한 효과를 붙이고, 렌더링해서, 트위터에 올렸다는 얘기처럼 읽히네요. "아야. 내가 뭘 눌렀지? 아, 안 돼, 엠바고가 깨졌잖아!"
참 대단한 실수네요.
댓글은 웃기네요. 하지만 "실수로"는 당연히 엠바고가 깨졌다고 잘못 믿은 실수를 가리키는 겁니다. 그다음에 바보 같은 영상을 올린 건 아주 의도적이었고 실수가 아니었고요.