2026년 10월 24일 기준
PHP 보안 패치를 먼저 적용한 뒤, 내 사이트에 필요한 보조 설정을 확인하면 됩니다. 10월 23일 추가 공지가 나왔다고 해서 앞서 배포된 두 취약점의 패치가 무효가 된 것은 아닙니다.
저도 보안 소식을 보고 워드프레스 업데이트를 서둘렀습니다. 이번에는 그다음에 살펴볼 설정과 적용 순서를 정리했습니다. 보조 조치는 공격에 노출될 기회를 줄이거나 이상을 알아차리기 위한 것으로, PHP 패치를 대신하지 못합니다.
먼저 PHP를 패치하고, 실행 중인 서비스에도 반영합니다
10월 21일 공개된 두 취약점을 수정한 버전은 PHP 8.2.35·8.3.36·8.4.27·8.5.12입니다. 현재 PHP 8.3 계열을 쓴다면 8.3.36처럼, 같은 계열의 수정 버전이나 그 이후 보안 업데이트를 적용합니다. 공급사가 버전 번호를 바꾸지 않고 보안 수정만 넣기도 하므로, 이 경우에는 해당 업체의 공지에서 수정 여부를 확인합니다.
업데이트한 뒤에는 홈페이지를 처리하는 PHP도 모두 다시 시작해야 합니다. 예전 PHP로 계속 일하는 프로그램이 남지 않게 하기 위해서입니다. PHP-FPM을 쓴다면 해당 서비스를, Apache 안에서 PHP를 실행한다면 Apache를 재시작하는 등 서버의 운영 방식에 맞게 처리합니다. 그 뒤 홈페이지가 열리는지 확인하고 로그인과 파일 첨부도 해 봅니다.
그다음에는 추가 공지에서 직접 다룬 설정부터 살펴봅니다. 개인 사이트 운영자에게 제안하는 네 가지 보조 조치와 점검 순서는 다음과 같습니다.
| 순서 | 보조 조치 | 적용할 때 볼 점 |
|---|---|---|
| 1 | 사용하지 않는 PHP 업로드 진행 추적 끄기 | 추가 공지에 해당하는지 |
| 2 | 요청·첨부 파일의 허용 크기 줄이기 | 실제로 필요한 파일 크기 |
| 3 | 웹방화벽의 관련 차단 규칙 확인하기 | 정상적인 글쓰기·첨부가 가능한지 |
| 4 | 오류 기록을 남기고 이상 요청 살피기 | 기록이 실제로 저장되는지 |
이어서 나오는 ini 코드는 PHP 설정 파일에 넣는 예시입니다. 터미널에서 실행하는 명령이 아닙니다. 홈페이지의 PHP가 방문자의 요청을 처리하기 전에 읽는 php.ini나 서버 관리 설정에 적용합니다. 바꾸기 전의 값을 보관하고, 필요한 서비스를 재시작한 뒤 설정이 적용됐는지와 홈페이지 기능이 정상인지 확인합니다. 호스팅을 맡겼다면 업체에 설정 변경과 적용 확인을 함께 요청합니다.
1. 쓰지 않는 ‘업로드 진행 추적’을 끕니다
session.upload_progress는 파일이 얼마나 올라갔는지 PHP가 기억하는 기능입니다. 이 기능을 꺼도 파일 업로드 자체를 끄는 것은 아닙니다.
PHP는 다음 정기 수정 버전이 나올 때까지 이 기능을 끄도록 권고했습니다. 쓰지 않는다면 아래처럼 끄고, 이미 꺼 두었다면 유지합니다.
session.upload_progress.enabled = 0모든 PHP 사이트에 문제가 생기는 것은 아닙니다. PHP의 10월 23일 공지는 사이트 이용 정보를 보관하는 ‘세션’의 저장 형식을 실행 중에 바꾸고, 진행 추적도 켜진 드문 경우를 설명합니다.
서버 관리자에게 아래 세 조건이 모두 겹치는지 확인을 요청합니다.
- 저장 형식 설정인 session.serialize_handler가 처음에는 php_binary 또는 php_serialize입니다.
- 실행 중 설정 변경 명령 ini_set()으로 형식을 php로 바꿉니다.
- 이어서 세션 시작 명령 session_start()를 호출하고, 업로드 진행 추적도 켜져 있습니다.
PHP는 실행 중 저장 형식을 바꾸지 않는 앱은 진행 추적을 유지할 수 있다고도 설명했습니다. 이 기능을 쓴다면 위 조건부터 확인해 끌지 판단합니다.
적용 뒤에는 홈페이지를 처리하는 PHP에서 ini_get("session.upload_progress.enabled") 값이 0인지 관리자에게 확인을 요청합니다. 파일도 직접 첨부해 봅니다. 진행 상태 표시가 달라질 수 있기 때문입니다. 파일 업로드 자체를 제어하는 file_uploads까지 끄지는 않습니다.
2. 사이트에 필요한 만큼만 파일을 받습니다
사이트에서 쓰는 파일 크기에 맞춰 한도를 정하면, 필요 이상으로 큰 요청이 PHP에 들어오는 것을 줄일 수 있습니다. 다만 이 설정으로 PHP의 취약점 자체가 고쳐지는 것은 아닙니다.
다음은 첨부 파일 하나를 최대 8M까지 받으려는 사이트의 설정 예시입니다. 8M와 12M는 설명을 위한 값이므로, 실제 필요한 크기에 맞춰 바꿉니다.
upload_max_filesize = 8M
post_max_size = 12M첫 줄은 파일 하나의 최대 크기입니다. 둘째 줄은 파일과 글 내용 등을 함께 보내는 묶음, 즉 POST 요청 전체의 최대 크기입니다. 파일에 딸려오는 정보도 포함되므로 둘째 줄의 값은 첫째 줄보다 커야 합니다. 파일 여러 개를 한 번에 받는다면 파일 크기의 합계와 함께 보내는 내용까지 들어갈 여유가 있어야 합니다.
평소 올리는 파일과 가져오는 자료의 크기를 확인해 한도를 정하고, 변경 뒤에는 글쓰기·사진 첨부·자료 가져오기가 정상적으로 되는지 시험합니다. 요청이 PHP에 도착하기 전에 거치는 웹서버나 호스팅에서도 크기를 제한하는 것이 중요합니다. 그 한도가 더 작으면 PHP에서 허용한 파일도 올리지 못할 수 있으므로 함께 확인합니다.
3. 웹방화벽은 정상 요청을 시험한 뒤 차단합니다
웹방화벽은 방문자의 요청이 PHP에 도착하기 전에 살펴보는 검사대입니다. 공격으로 의심되는 요청을 걸러 위험을 줄이지만, PHP 자체의 문제를 고치지는 못합니다. 웹방화벽을 쓰더라도 PHP 보안 업데이트는 적용해야 합니다.
웹방화벽 공급사가 제공하는 PHP2Shell 대응 규칙을 확인하고, 그 규칙이 내 사이트에 실제로 적용되어 있는지 살펴봅니다. AWS WAF를 쓴다면 AWS 공식 안내에서 관련 규칙과 적용 절차를 확인합니다.
AWS 안내에 따라 처음에는 Count 모드로 살펴봅니다. 규칙에 걸린 요청을 바로 막지 않고 기록만 하는 방식입니다. 이 상태에서 평소처럼 글을 쓰고 파일을 첨부해 보면서, 정상적인 이용도 차단 대상으로 잡히는지 기록을 확인합니다. 정상 이용을 막지 않는다고 확인한 뒤, 실제로 요청을 차단하는 Block 모드로 바꿉니다.
파일 첨부에 쓰는 요청 형식을 통째로 막으면 정상적인 첨부도 실패할 수 있습니다. 사용 중인 서비스의 공식 절차를 따라 적용하고, 관련 규칙이 어떤 요청을 검사하는지와 정상 파일을 올릴 수 있는지를 함께 확인합니다.
4. 오류는 방문자 화면 대신 운영 기록에 남깁니다
오류가 생기면 운영자가 원인을 찾을 수 있어야 합니다. 자세한 오류 내용은 방문자 화면 대신 운영 기록에 남기도록 다음 설정을 검토합니다.
display_errors = Off
log_errors = On첫 줄은 오류를 방문자 화면에서 숨기고, 둘째 줄은 서버에 기록을 남깁니다. 화면에서 오류를 숨겨도 공격이 차단되거나 이번 취약점이 고쳐지는 것은 아닙니다.
호스팅 관리 화면의 ‘오류 로그’ 메뉴나 서버의 error_log 설정에서 저장 위치를 확인합니다. 그곳에 기록을 쓸 권한이 있는지, 실제로 오류가 남는지도 살핍니다. log_errors를 켜기만 하면 기록이 남는다고 단정할 수 없습니다.
PHP 오류 기록에는 프로그램에서 생긴 문제가, 웹서버와 웹방화벽의 요청 기록에는 사이트로 들어온 요청이 담깁니다. 두 기록을 함께 보며 큰 요청이 반복되는지, 메모리 부족 오류가 있는지 확인합니다. 설정을 바꾼 뒤 평소 올리던 첨부 파일도 잘 올라가는지 살핍니다. 오류 기록에 별다른 내용이 없어도 안전하다는 증거는 아닙니다.
0 댓글