바로 어제, PHP 보안취약점(PHP2Shell)이 발견되어 웹사이트를 다루는 사람들은 바짝 긴장하지 않을 수 없게 되었다. 로그인 없이 외부에서 서버에 원하는 명령을 실행할 수 있는 매우 치명적인 취약점이라 한다.
PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙 - KISA 보호나라
나는 호스팅어에서 DokuWiki를 설치하여 공식 웹사이트로 사용하고 있다. PHP 8.2.34는 업데이트 대상이라고 하던데...
호스팅어에 접속하여 에이전트 창에 다음과 같이 물어 보았다.
I understand that the PHP 8.2.34 version currently running on my hosting account was built yesterday. However, I would like to confirm whether this build is vulnerable to the critical PHP security vulnerabilities disclosed recently. Could you please confirm whether your PHP 8.2.34 build includes the necessary security patches, even though the displayed version is still 8.2.34? If not, when will the patched version be deployed?
이에 대한 답변은 다음과 같다.
PHP 8.2.34 can already include the required security fix even though the displayed version remains 8.2.34. Hostinger added the protection to the existing PHP builds, and the managed-hosting rollout is complete; if your PHP Info → Build Date is October 21, 2026, or later, that build includes the fix for these vulnerabilities.
You do not need to wait for a newer version number or change PHP versions for this issue. Hostinger’s Security team could not reproduce the vulnerabilities in its managed hosting environment, and firewall protections block attack attempts across all PHP versions.
Read Hostinger’s official PHP2Shell update.
빌드 데이트가 2026년 10월 21일 이후라면 이번 취약점 패치가 적용된 것이고, PHP 버전은 8.2.34를 유지한다고 한다. 이번 보안 이슈에 대해서 상당히 발빠르게 대처함 셈이다. 다만 PHP 8.2는 올해 연말에 보안지원 종료이니, 해가 바뀌기 전에 8.3으로 올릴 것을 권장하고 있다.
만약 집에서 데스크톱 컴퓨터에 적당히 리눅스와 PHP를 설치해 서버를 운영하고 있었다면, 이번 사태에 어떻게 대처했어야 할까? 인터넷에 공개하지 않은 서버라면 그나마 느긋하게 대응할 수 있겠지만, 외부에 공개된 웹 서버라면 이야기가 완전히 달라진다. 취약점의 영향을 확인하고, 보안 패치가 나온 배포판 패키지를 찾아 업데이트하고, PHP와 웹 서버를 재시작하고, 혹시 그사이에 침입 흔적은 없었는지 로그까지 살펴야 한다. 실제 공격 시도가 패치 공개 전부터 나타난 이번 사태 같은 경우라면 정말 진땀나는 일이다. 이런 순간에는 약간의 비용을 들이더라도 서버의 보안과 업데이트를 전문가가 관리해 주는 상용 호스팅 서비스의 진가가 드러난다.
상황 종료!

댓글 없음:
댓글 쓰기