PHP 취약점 조치와
버전 업그레이드

먼저 인터넷에 공개된 사이트의 실제 PHP 버전을 확인합니다. 패치 버전이 나온 8.2~8.5는 해당 버전 이상으로 업데이트한 뒤 PHP를 실행하는 웹 서비스를 모두 재시작하고, 공식 패치가 없는 8.1 이하는 지원 버전으로 전환해야 합니다. KISA는 업데이트 뒤 로그 점검과 DB 비밀번호·API 키 교체도 권고합니다.

서버에서 php -v 로 확인할 수 있지만 웹 서비스가 실제로 쓰는 PHP와 다를 수 있습니다. 호스팅 관리 화면이나 phpinfo 결과로 웹에서 쓰는 버전을 함께 확인하고, 확인용 phpinfo 파일은 바로 지웁니다. 한 서버에 PHP가 여러 개 설치돼 있으면 각각 확인합니다.

PHP 공식 업데이트는 없습니다. 리눅스 배포판·장기지원 업체의 보안 패치나 PHP 보안팀이 공개한 7.4·8.0·8.1용 소스 패치를 임시로 적용할 수 있지만, KISA도 이를 전환 전 임시 조치로 안내합니다. 지원 버전으로 옮기는 계획을 함께 세웁니다.

8.2.35 이상이면 PHP2Shell은 고쳐진 상태입니다. 다만 8.2는 2026년 12월 31일에 보안 지원이 끝나므로 8.3 이상으로 옮길 계획이 필요합니다.

화면과 기능 수, 사라진 함수가 쓰인 곳, 데이터 양과 외부 연동에 따라 달라집니다. 코드와 서버를 먼저 진단한 뒤 방법과 범위를 정하고 일정과 비용을 협의합니다. 진단 전에 고정 금액을 약속하지 않습니다.

구조를 그대로 써도 되고 오류와 보안 문제만 막으면 되는 경우는 버전 업그레이드로 충분합니다. 구조 자체가 한계이거나 화면을 새로 만들어야 하면 단계적 전환이나 재구축을 검토합니다. 진단 결과를 보고 함께 정합니다.

새 서버나 별도 환경에서 작업하고 검수를 마친 뒤 전환하므로 작업 기간 내내 멈추지는 않습니다. 전환할 때 마지막 데이터를 옮기는 점검 시간이 필요할 수 있으며, 시간대는 미리 협의합니다.

버전과 직접 고친 범위에 따라 다릅니다. 스킨·플러그인·수정한 코드를 확인한 뒤 최신 버전으로 올릴지, 필요한 기능만 새로 만들지 제안합니다.

기존 URL을 유지하거나 바뀌는 주소는 301로 연결하고 사이트맵을 다시 제출합니다. 검색엔진이 다시 평가하는 데 시간이 걸리며, 순위 유지를 보장하지는 않습니다.

예전 방식으로 저장된 비밀번호를 확인할 수 있다면, 회원이 로그인할 때 최신 방식으로 다시 저장해 재설정 없이 옮길 수 있습니다. 저장 방식은 진단에서 확인합니다.

서버 접근 권한이 있으면 코드와 설정을 직접 확인해 진단합니다. 작업이 끝나면 서버 구성, 배포 절차, DB 구조를 인수 문서로 남깁니다.