PHP 를 업데이트한 후, 자체 사이트의 '검색 결과'까지 확인하셨나요?
10 월 21 일 PHP 는 네 가지 수정 버전을 발표했습니다. 이 수정들은 'PHP2Shell'이라는 이름의 취약점 2 개 (CVE-2026-109618, CVE-2026-109619) 에 대한 것입니다. 두 취약점 모두 CVSS v4.0 점수에서 9.2 를 기록했습니다. 인증 없이 원격에서 코드를 실행할 수 있는 취약점이라는 내용입니다.
정직하게 말씀드리면, 「업데이트했습니다」と서 보고를 마무리하면 절반이 빠진다는 것입니다. 오늘은 그 나머지 절반에 대한 이야기입니다.
먼저, 무엇이 일어났는지
수정 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35 입니다. PHP 공식 보안 업데이트는 웹 요청을 처리하는 모든 PHP 를 대상으로 하며, PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 를 명시적으로 언급하고 있습니다. 특히 mod_php 는 애플리케이션 코드가 실행되기 전에 공격이 가능하다는 것이 입증되었습니다.
각 릴리스 공지에는 '완전한 완화책은 없으며, 업데이트만이 유일한 안전한 선택지다'고 명시되어 있습니다.
관심 가는 것은 공개 전의 움직임입니다. Tenable 는 Amazon Threat Intelligence 가 10 월 17 일 악용 시도를 관측했다고 보도했습니다. Sansec 은 Cloudflare 의 보고서에 따르면, 공개 전 초기 공격이 10 월 21 일 07:43 UTC 에 있었다고 기록하고 있습니다. 두 곳 모두 보안 기업이 다른 기업의 관측을 전파한 2 차 정보이지만, "업데이트 전에 침입했을 가능성"을 고려하게 만듭니다.
PHP 를 업데이트하는 사람은 누구인가요?
이 부분이 이번 기회에 가장 강조하고 싶은 부분입니다. 사쿠라 인터넷은 10 월 22 일의 발표에서 경계를 명확히 했습니다.
사쿠라 렌탈 서버는 사쿠라가 제공하는 PHP 에 자체 수정을 적용하고 있으며, 지원 종료 버전에도 수정을 적용한 뒤 지원 중인 버전을 사용하도록 권장합니다.
사쿠라의 VPS 는 다릅니다. VPS 내부에서 실행 중인 PHP 는 고객에게 최신 버전으로 업데이트를 권장한다는 처리를 하고 있습니다. OS 나 소프트웨어를 스스로 관리하는 서비스 전반도 마찬가지입니다.
Sansec 은 "서버를 직접 관리하지 않는 경우라면, 호스팅 업체에 즉시 업데이트를 요청하라"고 명시하고 있습니다.
즉, 같은 '업데이트'라는 표현이라도, 실제 업데이트를 수행하는 사람은 장소에 따라 달라집니다. 공유レンタル 서버의 경우 사업자입니다. VPS 나 클라우드의 경우 사용자입니다. 제작사에 유지보수를 맡긴 경우라면 계약 내용次第입니다.
일본에 진출한 해외 브랜드의 경우 다음과 같은 형태가 가능합니다. 본사 사이트는 본사가 직접 관리하며, 일본어 사이트는 일본의 제작사가 제작해 일본의 서버에 호스팅합니다. 유지보수 계약은 콘텐츠 교체만 포함하고 있습니다. 본사는 PHP 버전을 알지 못해, 제작사는 "서버는 계약 대상이 아니다"라고 생각하기 때문에, 아무도 업데이트하지 않는 상황이 발생할 수 있습니다.
확인하려는 질문은 하나면 충분합니다. "일본어 사이트의 PHP 를 업데이트한 사람은 누구이며, 현재 버전은 무엇입니까?"
변조는 검색과 AI 의 기반에 침투합니다.
이제부터는 메뉴 메뉴다운 이야기입니다.
구글의 스팸 정책은 취약점을 통해 무단 게시된 콘텐츠를 '해킹된 콘텐츠'로 정의합니다. 특히 우려되는 것은 '페이지 인젝션'입니다. 기존 페이지에 흔적이 없더라도 새로 생성된 페이지가 검색 엔진 내 사이트 성능에 악영향을 줄 수 있다는 경고가 포함되어 있습니다. 즉, 메인 페이지가 안전하다고 해서 안심할 수 없다는 뜻입니다.
검색 결과에서 온 사람만 이상한 페이지로 리디렉션시키고, 직접 열면 리디렉션되지 않는 경우도 있다는 소문이 있습니다.
그리고 Google 의 AI 가 생성한 요약 또는 AI 모드에서 링크로 표시되는 조건은 '인덱스에 등록', '스니펫 표시', '기술적 요건 충족'입니다. 기본적으로는 '검색 정책을 준수한다'는 점도 언급하고 있습니다. Google 의 AI 기능은 일반적인 검색과 동일한 인덱스 및 정책 위에 작동합니다.
오해의 소지를 주지 않도록 작성하더라도, 구글은 가짜 페이지가 AI 에 의해 인용된다고 말하지 않습니다. 오히려 구글은 해킹된 콘텐츠를 검색 결과에서 제외하는 데 최선을 다한다고 설명하고 있습니다. 그럼에도 불구하고, 구글의 도메인에서 알려지지 않은 페이지가 인덱싱되는 것은 구글 검색과 AI 기능 모두에 공통된 기반이라는 이야기입니다.
일본어 사이트에는 '일본어 키워드 해킹'이라는 잘 알려진 기법이 있습니다. 구글의 web.dev 가이드 (최종 업데이트 2015 년) 에 따르면, 랜덤한 디렉토리에 자동 생성된 일본어 페이지를 만들어 위장 브랜드 스토어로 유인하는 방식입니다. 해커는 때때로 검색 콘솔의 소유자로 등록되기도 합니다. 이번 자료에는 PHP2Shell 이 이 기법을 사용했다는 보고는 없으나, 탐지 방법은 그대로 적용할 수 있습니다.
점검은 10 월 17 일부터 시작됩니다.
테네블은 아마존이 "최소 10 월 17 일부터" 조사를 시작할 것을 권고했다고 전했습니다. 관련 내용은 이 정도입니다.
검색 콘솔의 '보안 문제' - 검색 콘솔 소유자 및 사용자에게 알 수 없는 사람이 있는지, 구글에서 'site:본사 도메인'으로 검색했을 때 알 수 없는 페이지가 노출되지 않는지, URL 검사 시 사람과 구글에게 다른 내용이 노출되지 않는지, .htaccess 나 index.php, 알 수 없는 사이트맵
찾았다면 백업 후 삭제하고 검색 콘솔에서 심사 요청을 하세요. 심사에는 수일에서 수주까지 걸릴 수 있습니다.
마지막으로 회사명을 검색하고 AI 모드 등으로 회사에 대해 물어보세요. 어떤 결과가 나올지는 시도해 보지 않고는 알 수 없습니다.
예방은 '갱신'과 '연말'입니다.
지원 중인 시리즈는 수정판을 사용합니다. 8.1 이전에는 PHP 프로젝트에서 업데이트가 제공되지 않았으므로, 배포처의 수정 여부를 확인하거나 지원 중인 판으로 전환해야 합니다. 8.2 또한 2026 년 12 월 31 일까지 지원이 종료됩니다. 즉시 업데이트가 불가능한 경우의 임시 조치도 PHP 에서 제시하고 있지만, 개발자들이 "안전하지 않다"고 경고하고 있습니다.
요약하자면, 업데이트는 서버의 결함을, 점검은 인덱스에 있는 자체 정보를 정리합니다. 담당자나 도구가 다르므로 어느 한쪽만 끝내지 마십시오.
본 블로그에서는 각 위치별로 '누가 업데이트할지'를 명시하고 점검표를 정리했습니다.
참고해 주시면 기쁘며, 좋아요나 팔로우를 해 주시면 큰 힘이 됩니다. 원문을 바탕으로 AI 검색 발표를 확인하고, 일본어와 일본어권에서 어떤 수준까지 도달했는지 분석하는 글을 앞으로도 계속お届け하겠습니다.
메뉴메뉴는 본사를福岡에 두고, 사이트·브랜드·매장이 AI 검색에서 '선택받는 쪽'으로 자리 잡을 수 있도록 조사와 구현을 수행하고 있습니다. 서버 업데이트는 담당자의 업무이지만, 그 이후 검색 결과나 AI 의 답변에서 본사가 어떻게 노출되는지는 측정하지 않으면 알 수 없습니다. 본사의 모습을 숫자로 확인하고 싶거나, 앞으로 제작할 사이트를 처음부터 검색과 AI 가 읽을 수 있는 형태로 만들고 싶으시다면 언제든지 문의해 주세요.
#AI 검색 최적화 #LLMO #SEO 전략 #PHP #메뉴
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 20청크
원문 보기 | 출처: note.com