"로그인했다고 하니까 믿었습니다" — 소셜 로그인 플러그인 3종의 같은 구멍

“로그인했다고 하니까 믿었습니다” — 소셜 로그인 플러그인 3종의 같은 구멍

분류: CVE · 웹·서버 · 인증우회(Auth Bypass) · CVE-2026-77000 (외 77001·77002) · [표준]

덱. 2026년 8월 20일, 워드프레스 소셜 로그인 플러그인 세 개가 같은 날 나란히 “인증 우회” 취약점(전부 CVSS 9.8 치명적)으로 공개됐습니다(WPScan advisory 기준, NVD 등재는 8월 22일). 결함의 이름은 조금씩 다르지만 뿌리는 하나입니다 — 바깥 신원 서버(구글·페이스북 같은 IdP)가 정말로 로그인을 끝냈는지 서버가 확인하지 않았다는 것. 그래서 아무 인증 없는 공격자가 이메일 한 줄만 넣거나, 심지어 아무것도 모른 채로 관리자 세션을 손에 넣습니다.

개요

세 취약점(CVE-2026-77000·77001·77002)은 모두 무인증 인증 우회입니다. CVSS 3.1 점수는 셋 다 만점에 가까운 9.8(치명적), 벡터도 동일하게 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 네트워크 너머에서, 권한도 사용자 조작도 필요 없이, 기밀성·무결성·가용성을 모두 완전히 무너뜨린다는 뜻입니다. 분류는 셋 다 CWE-287(부적절한 인증)입니다.

세 플러그인은 만든 회사도 UX도 제각각입니다. 하나는 SNS 계정 로그인 버튼(WP Social Media Login), 하나는 소셜 로그인·공유 버튼에 분석 기능을 붙인 것(SoClever), 하나는 셀카(얼굴 인식)로 로그인한다는 물건(SmilePass Selfie Login)입니다. 그런데 결과는 똑같습니다 — 관리자로 로그인됩니다. 개별 CVE 하나를 뜯어보는 대신, 이 글은 “왜 이 실수가 플러그인마다 판박이처럼 반복되는가”를 봅니다.

세 건 모두 발견자는 Khaled Alenazi(Nxploited)이고 advisory 호스트는 WPScan(Automattic)입니다. WPScan advisory 공개는 2026-08-20, NVD 등재는 2026-08-22이며 NVD 상태는 Deferred입니다.

기술 배경 (30초)

“소셜 로그인”은 편의 기능입니다. 사용자가 비밀번호를 새로 만들지 않고 구글·페이스북 같은 신원 서버(IdP, Identity Provider) 계정으로 사이트에 들어오게 해 줍니다. 제대로 된 흐름은 대략 이렇습니다.

  1. 사용자가 “구글로 로그인” 버튼을 누른다.
  2. 구글이 사용자를 인증하고, “이 사람이 맞다”는 서명된 증표(토큰/코드)를 돌려준다.
  3. 워드프레스 쪽 플러그인이 그 증표를 IdP에 되물어(또는 서명을 검증해) 진짜인지 확인한 뒤, 그제서야 해당 이메일의 계정으로 세션을 발급한다.

핵심은 3번입니다. 편의를 붙이는 대가로, 서버는 “바깥에서 넘어온 로그인 주장”을 반드시 자기 손으로 다시 검증해야 합니다. 세 플러그인이 놓친 게 정확히 이 지점입니다.

CVE 분석 요약

셋을 나란히 놓으면 “같은 실수의 세 가지 정도(程度)“가 보입니다. WPScan advisory 원문에 근거해, 각 건이 검증의 어느 단계를 건너뛰었는지로 정리합니다.

  • CVE-2026-77000 — WP Social Media Login (≤1.0.6): 신원 확인 자체를 안 함. 플러그인이 방문자를 인증하기 전에 소셜 로그인이 실제로 IdP에서 완료됐는지 검증하지 않습니다. 그래서 무인증 공격자가 원하는 사용자의 이메일 주소만 넣으면 그 사용자(관리자 포함)로 로그인됩니다. “이 이메일로 소셜 로그인 성공했다”는 주장을 서버가 그냥 믿는 셈입니다. advisory에 따르면 이 결함은 트위터 로그인 흐름에서 확인됐고, 해당 이메일의 계정이 없으면 사이트의 가입 제한 설정과 무관하게 새 계정을 만들어 버립니다(영향 범위는 단일 사이트 설치).

  • CVE-2026-77001 — Social Login & Sharing … By SoClever (≤1.2.0): 문지기가 아예 없음. 공개적으로 접근 가능한 로그인 처리부 하나에 인증·인가·논스(nonce, 요청 위조 방지 토큰) 검사가 전혀 없습니다. 무인증 공격자가 그 처리부를 그대로 호출해 임의 사용자의 유효 세션을 얻습니다. advisory에 따르면 기본 설정에서는 계정 정보를 하나도 몰라도 사이트의 최초 관리자 계정 세션이 나옵니다. 77000이 “이메일이라도 필요”했다면, 이쪽은 그마저도 필요 없습니다.

  • CVE-2026-77002 — SmilePass Selfie Login (≤1.0.2): 서버 검증 없이 클라이언트 말만 믿음. 플러그인이 인증하라고 넘겨받은 신원에 대해 서버 측 검증을 전혀 하지 않아, 무인증 사용자가 등록된 임의 계정(관리자 포함)으로 로그인합니다. “얼굴 인식”이라는 화려한 겉모습과 무관하게, 판정을 서버가 아니라 넘어온 데이터에 맡긴 같은 구멍입니다.

세 건의 공통 골격을 개념 코드로 단순화하면 이렇습니다.

// 개념용 단순화 — 실제 소스/페이로드 아님
function social_login_handler(request):
    email = request["email"]         // 바깥에서 넘어온 "주장"
    // (빠진 단계) IdP에 이 로그인이 진짜인지 검증 X
    // (빠진 단계) nonce / 권한 검사 X
    user = find_user_by(email)        // 있으면 그 사람으로
    set_session(user)                 // 관리자여도 그대로 세션 발급

개념용 단순화 — 실제 소스/페이로드 아님. 실제 함수명·파일명은 확인하지 않았습니다.

빠진 것은 화려한 방어가 아니라 “넘어온 신원을 서버가 다시 확인한다”는 한 줄입니다. IdP 검증(77000·77002)이든, 논스·권한 검사(77001)든, 결국 같은 문장의 다른 표현입니다 — 신뢰 경계를 넘어온 입력을 검증 없이 신뢰했다.

공격 시나리오 · 영향도 + 대응방안

시나리오(개념). ① 무인증 공격자가 취약한 로그인 처리부에 요청을 보냅니다. → ② (플러그인에 따라) 이메일 파라미터를 넣거나, 아무 정보 없이 그대로 호출합니다. → ③ 서버가 IdP 검증·논스·권한 확인을 건너뛴 채 세션을 발급합니다. → ④ 공격자가 관리자 세션을 획득합니다. 어느 단계에도 인증 관문이 없어 익명 공격자가 곧장 도달합니다. (작동하는 요청·페이로드는 싣지 않습니다.)

영향도. 무인증 관리자 계정 탈취. 관리자 권한을 얻으면 워드프레스 특성상 플러그인/테마 편집을 통한 코드 실행, 콘텐츠 위·변조, 사용자 데이터 접근으로 이어질 수 있습니다(합리적으로 예상되는 후속 영향 — 세 advisory가 명시한 확정 범위는 “관리자 세션 획득”까지입니다). 노출 조건은 “해당 플러그인을 취약 버전으로 설치·활성화”이며, 특히 77001은 기본 설정만으로도 노출됩니다.

대응방안.

  1. 근본 — 즉시 비활성화 또는 제거. 세 플러그인 모두 공개 시점 기준 공식 패치가 존재하지 않습니다(WPScan advisory 3건 전부 “No known fix”). 따라서 “안전 버전으로 업데이트”는 현시점 가능한 처방이 아니며, 취약 버전을 쓰는 사이트는 해당 플러그인을 비활성화(가능하면 완전 제거) 하는 것이 유일한 근본 대응입니다. 소셜 로그인은 편의 기능이라 꺼도 서비스 본체는 유지됩니다.
  2. 완화(제거가 당장 어려울 때). 취약한 로그인 처리 엔드포인트로의 접근을 웹 방화벽/서버 규칙으로 제한하고, 관리자 계정에 2단계 인증을 걸어 세션 탈취만으로 실권을 못 쥐게 방어 심도를 더합니다. 다만 이는 임시 완화일 뿐, 근본 대응(비활성화·제거)을 대체하지 않습니다.
  3. 탐지 관점. 소셜 로그인 처리 엔드포인트로 들어온 요청 중 정상 IdP 리다이렉트 흐름을 거치지 않은 직접 호출, 그리고 관리자 계정의 예상치 못한 신규 로그인 세션을 로그에서 살핍니다. 짧은 시간 다수 이메일을 시도하는 패턴도 신호입니다.
  4. 패치 감시. 세 플러그인 모두 아직 무패치이므로, 각 WPScan advisory와 wordpress.org 플러그인 페이지에서 fixed 버전 출시 여부를 계속 확인해 패치가 나오면 즉시 적용합니다.

결론

한 줄 요약. 소셜 로그인은 “인증을 남에게 맡기는” 기능이지만, 맡긴 결과가 진짜인지 확인하는 책임까지 남에게 넘길 수는 없습니다. 세 플러그인은 그 마지막 한 걸음을 나란히 빼먹었습니다.

이 부류가 반복되는 이유는 분명합니다. “소셜 로그인”은 겉으로 로그인 UX를 붙이는 일처럼 보이지만, 속은 신뢰 경계를 넘어온 신원 주장을 서버가 검증하는 보안 작업입니다. 편의 기능이라는 겉모습이 “검증”이라는 알맹이를 가리는 순간, 개발자는 이메일을 받아 계정을 찾는 데까지만 신경 쓰고 “이 로그인이 진짜인가”라는 질문을 건너뜁니다. 이번 세 틈은 각각 패치되겠지만, 똑같은 사고방식은 다음 소셜 로그인·SSO·OAuth 연동에서 또 나타납니다 — 그래서 우리는 개별 CVE가 아니라 “바깥의 주장을 서버가 검증했는가”라는 방법을 남깁니다.

References / 참고자료

  1. WPScan(Automattic) — 이 글이 재구성한 원 분석 3건. 발견자: Khaled Alenazi(Nxploited). 세 건 모두 advisory 공개일 2026-08-20, fixed 버전 “No known fix”(무패치).
  2. NVD — CVE-2026-77000 · CVE-2026-77001 · CVE-2026-77002. CVSS 9.8 / CWE-287 근거(NVD 등재 2026-08-22, 상태 Deferred).
  3. infiltr8 Lab, “서버가 ‘믿을 만한 데이터’라고 착각하는 순간 — React2Shell” — “시스템이 바깥 입력을 자기 것처럼 믿었다”는 같은 뿌리를 다룬 우리 글.

이 글은 위 WPScan 원 분석 3건을 우리 관점에서 다시 쓰고 논평을 더한 것입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 작동하는 익스플로잇/페이로드는 싣지 않았습니다. 플러그인 소스코드는 직접 확인하지 않았고, 코드 예시는 개념 설명용입니다. 자세한 내용은 원문 advisory를 참고하세요.