요약
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 취약점 같은 시시한 탐색이 잔뜩 들어오긴 합니다.
감사합니다(저는 django 사이트입니다).
구글 클라우드 IP에서 온 것 같네요.
공격자가 조금이라도 뒷정리를 하는 데 그렇게 대단한 실력이 필요하지는 않을 텐데요?
로그를 어떻게 관리하느냐에 달렸습니다. 로그를 원격 서버로 수집하고 있다면 공격자가 그걸 지우기는 꽤 어렵습니다. 또 오늘 시도된 PHP 익스플로잇 대부분은 정교한 공격이 아니라 무차별 대입이었을 테고, 목적은 코인 채굴이나 봇넷 편입 같은 것일 거라고 짐작합니다.
필요 없다고 생각합니다. 다만 저는 PHP 애플리케이션을 노린 자동화 공격 중에 굳이 흔적을 숨기려 한 것을 한 번도 본 적이 없습니다.
공격자가 아는 사람이거나 끈질기게 달라붙는 위협 세력이라면 숨길 수도 있겠죠. 하지만 이런 건 대개 웜처럼 움직입니다. 한 상자를 공격하고, 그걸 이용해 다른 상자를 공격하고, 다음으로 넘어가는 식이죠.
이 서버에 끈질긴 해커가 붙어 있을 가능성은 반반이라고 봅니다. 다만 제가 본 건 자동화된 공격 같았습니다. 말하자면 AI 스크립트 키디죠. 이 서버들에는 평소에도 전형적인 PHP 앱 탐색(WP2shell 등)이 들어옵니다.
참고로 실제로 가장 많았던 건 클라우드 기반 AI 검색 API로 보이는 곳에서 들어온 요청이었는데, 누가 플러그를 뽑기라도 한 것처럼 동시에 뚝 끊겼습니다. 에이전트형 검색 API를 운영하는 쪽에서 탐색에 가담하지 않기로 결정했을 수도 있겠죠.
그 말에는 동의합니다. 그런 스크립트 대부분은 최대한 게으르게 만들어져 있죠.
하지만 생존자 편향이 작용하는 건 아닐까 하는 생각이 자꾸 듭니다.
양도 질의 한 형태입니다.
코인 채굴기들이 자원을 두고 서로 치고받는 통에 사이트 성능이 바닥을 쳐도 들여다보지 않는 운영자가 엄청나게 많습니다. 어차피 유능한 관리자라면 외부로 나가는 트래픽만 보고도 알아챌 텐데, 그들의 눈을 피하겠다고 정교한 공격에 시간을 쓸 이유가 있을까요?
동감입니다. 사람들이 구조를 기다리는 동안 댓글에서 서로 힘을 모아 벽에 모래주머니를 쌓는 모습을 보니, 늙다리 제 얼굴에도 미소가 번지면서 눈물구멍이 열리더군요.
그래도 아직 아무도 높은 곳으로 대피하지 못했다는 게 무섭네요.
이건 PHP로 만든 건 다 나쁘다는 식의 문제가 아니에요.
오히려 "어떤 C 프로그래밍 기법은 나쁘다"는 문제에 더 가깝죠.
log4j, 하트블리드 같은 사건과 비슷해요.
이게 마지막은 아닐 거예요.
인터넷의 보안 모델 자체를 바꿔야 합니다.
예를 들어 웹쇼핑몰에서 물건을 살 때, 그 쇼핑몰이 왜 제 개인정보를 가지고 있어야 합니까? 토큰만 주면 되지 않나요? 쇼핑몰은 그 토큰으로 택배를 보내고, 토큰에 연결된 주소는 우편 시스템만 알고 있는 식으로요.
그리고 광고 목적의 사용자 추적은 당연히 금지해야 하고요.
저는 이게 전부 막다른 길이라고 생각합니다. 아파트를 튼튼한 자물쇠 같은 것만으로 지키려는 셈이니까요. 현대 사회는 처벌과 도덕 규범으로 범죄를 막습니다. 자물쇠만으로 막는 게 아니고요.
인터넷에서 익명성을 완전히 없애지 않고 그게 어떻게 가능합니까? 사이버 범죄에 신경 쓰지 않는 나라에서 접속할 수 있는 한, 남을 해킹하는 걸 무슨 수로 막겠어요? 북한 해커를 처벌할 수는 영원히 없을 텐데요.
사업자가 가장 중요하게 추적하는 지표 중 하나가 재구매입니다. 재구매율을 보면 자기 제품이 고객을 붙잡아 둘 만큼 괜찮은지 알 수 있으니, 그 정보를 포기하려 하지 않을 겁니다.
그러니 토큰에는 (적어도 판매자 단위로는) 한 사용자의 구매를 시간에 걸쳐 연결할 수단이 있어야 합니다. 그렇지 않으면 사업자들은 절대 도입하지 않을 겁니다.
마찰을 늘리는 것은 실제 상거래 세계에서는 무조건 안 되는 일입니다.
제대로 구현하면 지금 방식보다 마찰이 오히려 적습니다.
애플페이가 카드 정보를 직접 입력하는 것보다 온라인 결제에서 마찰이 적은 것과 같아요. 여기서 한 걸음 더 나아가 애플이 배송에 필요한 개인정보를 그때그때 제공해 줄 수도 있고요.
물론 청구지와 배송지가 다른 경우처럼 수동으로 덮어쓸 수 있어야 하긴 해요. 그래도 대부분의 정상적인 경로는 간소화할 수 있어요.
마찰이라... 해킹당하는 것, 아니면 고객의 개인정보나 금융 정보가 유출되는 것 같은 거요?
"결제를 마치려면 페이스북 계정을 만드세요" 같은 마찰이죠.
저한테는 이 부분이 가장 놀라웠습니다. Calif가 유출을 보고 엠바고가 깨졌다고 판단해서, 서둘러 [애니메이션 춤 영상] 홍보 영상을 올렸다는 얘기로 들리는데요. 이보다는 훨씬 나을 거라고 기대했습니다.
실수로요?
누가 넘어지면서 마우스 위로 쓰러졌는데 그 바람에 화면 녹화가 켜졌고, 익스플로잇을 몇 번 돌렸고, 애니메이션 소녀 에셋과 배경음악을 구했고, 그걸 전부 프리미어에 던져 넣고, 이상한 효과를 붙이고, 렌더링해서, 트위터에 올렸다는 얘기처럼 읽히네요. "아야. 내가 뭘 눌렀지? 아, 안 돼, 엠바고가 깨졌잖아!"
참 대단한 실수네요.
댓글은 웃기네요. 하지만 "실수로"는 당연히 엠바고가 깨졌다고 잘못 믿은 실수를 가리키는 겁니다. 그다음에 바보 같은 영상을 올린 건 아주 의도적이었고 실수가 아니었고요.
영상은 이미 만들어 놨는데, 너무 일찍 올린 게 실수였을 것 같습니다.
그게 바로 방금 위 댓글이 한 말이잖아요??
올해의 "우리가 트위터 영상에 뭘 얹었나?" 목록 다음 회차에 들어갈 확실한 후보네요.
물라에게 전화를 걸어서 "샤와르마 접시 위로 넘어져서 그걸 먹어 버렸는데, 이제 어떻게 해야 합니까?" 하고 묻는 사람 얘기가 떠오르네요.
원래 운동신경이 모자란 사람들이 있죠.
마케팅·홍보 회사는 뭐라고 말하든 실제로 손발을 맞추는 방식이 바로 이래요.
춤추는 애니메이션 소녀 영상은 이게 아니죠?