로그인하지 않은 공격자가 SharePoint 사용자로 가장할 수 있는 취약점
CVE-2026-55040은 Microsoft SharePoint Server의 인증 처리 과정에서 발생하는 보안 기능 우회(Security Feature Bypass) 취약점입니다.
이 취약점은 단순한 권한 설정 오류가 아니며,SharePoint가 서비스 간 인증에 사용하는 JWT(JSON Web Token) 검증 파이프라인의 여러 검증 절차가 제대로 연결되지 않은 것이 핵심 원인입니다.
Microsoft가 제공한 CVSS 3.1 점수는 9.1 Critical이고, 공격 조건은 AV:N/AC:L/PR:N/UI:N입니다.
네트워크를 통해 접근할 수 있으며 사전 계정이나 사용자 클릭이 필요하지 않습니다. 기밀성과 무결성 영향도 역시 High로 분류됩니다.
Rapid7은 2026년 8월 11일 공개한 상세 기술 분석에서 CVE-2026-55040을 이용해 SharePoint 사용자 또는 관리자 신원으로 인증을 우회할 수 있음을 확인했습니다. 별도의 RCE 취약점인 CVE-2026-63520과 결합하면 비인증 원격 코드 실행 체인을 구성할 수 있음도 밝혔습니다.
이 글에서는 공격용 PoC나 재현 코드는 제외하고, CVE-2026-55040의 기술적 발생 원인과 영향도, SharePoint 버전 확인 방법, 실무 패치 절차를 살펴봅니다.
1. CVE-2026-55040 기술적 발생 원인
SharePoint의 JWT 인증 구조
SharePoint는 서비스 간 통신(S2S, Server-to-Server)에서 JWT 기반 인증을 사용합니다.
Rapid7 분석에 따르면 해당 인증 과정은 대략 다음과 같습니다.
외부 요청
↓
Bearer JWT
↓
SharePoint JWT 파싱
↓
Actor Token 검증
↓
인증서 / Issuer 확인
↓
사용자 Identity 생성
↓
SharePoint 권한 적용문제 1. JWT 서명이 필수 조건으로 강제되지 않음
JWT는 일반적으로 서버가 토큰의 전자서명(Signature)을 검증해 변조 여부를 확인합니다.
하지만 취약한 SharePoint 인증 처리에는 외부 토큰을 검증할 때 서명된 토큰을 반드시 요구하도록 강제하는 설정이 비활성화된 상태가 있었습니다.
쉽게 말하면 정상 흐름은 다음과 같아야 합니다.
정상적인 처리
JWT 수신
→ 서명 존재 확인
→ 암호학적 서명 검증
→ 신뢰할 수 있는 경우만 사용자 생성그러나 취약한 흐름에서는 서명 검증이 강제되지 않은 토큰이 일부 단계를 거쳐 다음 검증 단계까지 진행할 수 있었습니다.
Rapid7은 이를 JWT 검증 파이프라인의 가장 기본적인 문제 가운데 하나로 분석했습니다.
문제 2. Actor Token의 인증서를 찾지만 실제 서명 검증이 부족
SharePoint S2S 인증에서는 일반 사용자 정보를 담는 토큰 외에 호출 애플리케이션의 신원을 나타내는 Actor Token도 함께 처리합니다.
이때 SharePoint는 토큰에 포함된 인증서 식별 정보를 바탕으로 신뢰할 수 있는 인증서를 찾습니다.
하지만 인증서를 찾는 것과 그 인증서로 토큰의 서명이 실제로 만들어졌는지 검증하는 일은 전혀 다릅니다.
예를 들어 인증서 A가 존재한다는 사실만 확인했다고 해서,
“이 JWT가 인증서 A의 개인키로 실제 서명됐다”
라고 판단해서는 안 됩니다.
Rapid7 분석에서는 SharePoint가 Actor Token에 연결할 인증서를 선택하지만,
특정 처리 흐름에서는 그 인증서를 이용한 암호학적 JWT 서명 검증이 이루어지지 않는 문제가 확인됐습니다.
문제 3. Issuer 검증 과정의 허용 로직
JWT에서 Issuer(발급자) 확인도 중요한 보안 요소입니다.
서명이 정상이어도 신뢰하지 않는 시스템이 발급한 토큰이라면 인증을 허용하면 안 됩니다.
그런데 취약한 SharePoint 코드에는 특정 인증서가 등록된 Trusted Security Token Service와 일치하지 않을 때 무조건 거부하는 대신, 일부 조건에서는 검증을 통과시키는 흐름이 있었습니다.
Rapid7은 이 로직이 앞 단계의 인증서 처리 문제와 결합되면서 신뢰 경계를 무너뜨릴 수 있었다고 분석했습니다.
문제 4. “서명이 존재한다”와 “서명이 유효하다”를 혼동
보안 시스템에서는 다음 두 가지가 완전히 다릅니다.
Signature 값이 존재한다
≠
Signature가 암호학적으로 유효하다취약한 처리 흐름은 일부 과정에서 서명 데이터가 비어 있지 않은지만 확인했을 뿐,
해당 값이 실제 RSA 등의 암호학적 서명으로 유효한지는 확인하지 않았습니다.
결국 CVE-2026-55040은 하나의 단순한 if문 실수라기보다 서명 요구 → 인증서 확인 → Issuer 검증 → 최종 서명 확인으로 이어지는 인증 체인의 단계들이 충분히 강하게 연결되지 않아 발생한 취약점으로 보는 편이 맞습니다.
2. 공격에 성공하면 어떤 일이 발생할까?
Rapid7에 따르면 공격자는 취약한 SharePoint Server에서 인증을 우회해 특정 SharePoint 사용자 신원으로 동작할 수 있습니다.
다만 가장하려는 사용자의 SID 또는 UPN 등 대상 사용자를 식별할 정보가 필요합니다.
일반 사용자를 가장하면 해당 사용자의 SharePoint 권한을 얻고, 관리자 계정을 가장할 수 있다면 관리자 수준의 작업까지 영향이 확대될 수 있습니다.
CVE-2026-55040 자체는 인증 우회 취약점이지만, 문제는 그 이후입니다.
CVE-2026-55040
인증 우회
↓
SharePoint 인증 영역 접근
↓
추가 취약점 접근 가능
↓
권한 확대 / 데이터 접근 / RCE 가능성Rapid7은 실제 연구 과정에서 CVE-2026-55040과 별도의 CVE-2026-63520 SharePoint RCE 취약점을 연결해 비인증 원격 코드 실행이 가능한 체인을 구성했다고 밝혔습니다. CVE-2026-63520은 2026년 8월 11일 Microsoft 업데이트에서 수정됐습니다.
따라서 **”CVE-2026-55040은 코드 실행 취약점이 아니니까 급하지 않다”**고 판단해서는 안 됩니다.
인증 우회는 이후의 인증된 공격 영역을 외부 공격자에게 열어줄 수 있기 때문입니다.
3. 내 SharePoint 서버가 영향받는지 확인하는 방법
NVD에 등록된 Microsoft의 영향 제품과 CVE-2026-55040 수정 기준은 다음과 같습니다.
| 제품 | 취약한 버전 | CVE 수정 기준 |
|---|---|---|
| SharePoint Enterprise Server 2016 | 16.0.5561.1001 미만 | 16.0.5561.1001 |
| SharePoint Server 2019 | 16.0.10417.20175 미만 | 16.0.10417.20175 |
| SharePoint Server Subscription Edition | 16.0.19725.20434 미만 | 16.0.19725.20434 |
공개된 CVE 영향 제품 목록에는 온프레미스 SharePoint Server 2016, 2019 및 Subscription Edition이 등록돼 있습니다. SharePoint Online은 이 목록에 포함되어 있지 않습니다.
Step 1. SharePoint Farm Build 확인
SharePoint Management Shell을 관리자 권한으로 실행합니다.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
(Get-SPFarm).BuildVersion예를 들어 SharePoint Server 2019에서 결과가 CVE 수정 기준인 16.0.10417.20175보다 낮다면 CVE-2026-55040 패치 적용 여부를 즉시 확인해야 합니다.
Farm에 등록된 서버도 함께 확인합니다.
Get-SPServer |
Select-Object Address, Role, Status다중 서버 Farm에서는 한 대만 업데이트하고 끝내서는 안 됩니다. Web Front End와 Application Server 등 Farm을 구성하는 모든 서버의 패치 상태를 확인해야 합니다.
Step 2. 중앙 관리에서 패치 상태 확인
SharePoint Central Administration에서 다음 메뉴를 확인합니다.
Central Administration
→ Upgrade and Migration
→ Check product and patch installation status업데이트 후에는 다음 항목도 확인하는 것이 좋습니다.
Central Administration
→ Upgrade and Migration
→ Check upgrade statusMicrosoft의 SharePoint 업데이트 지침도 Farm 전체 서버에 업데이트를 배포한 뒤 SharePoint Products Configuration Wizard를 실행하고 업그레이드 완료 여부를 확인하도록 안내합니다.
4. CVE-2026-55040 실전 패치 방법
Step 1. 최소한 2026년 7월 보안 수정 이상 적용
CVE-2026-55040을 직접 수정한 최초 업데이트는 다음과 같습니다.
| 제품 | CVE-2026-55040 수정 KB |
|---|---|
| SharePoint Server 2016 | KB5002891 |
| SharePoint Server 2019 | KB5002883 |
| SharePoint Server Subscription Edition | KB5002882 |
하지만 2026년 8월 현재라면 여기서 멈추지 않는 것이 좋습니다.
Microsoft는 2026년 8월 11일 새로운 SharePoint 보안 업데이트를 공개했고,
이 업데이트들은 위의 7월 패키지를 대체합니다. CVE-2026-55040과 체인될 수 있었던 CVE-2026-63520 RCE도 함께 대응합니다.
2026년 8월 13일 기준 적용 우선순위는 다음과 같습니다.
| SharePoint 제품 | 최신 보안 업데이트 |
|---|---|
| SharePoint Server 2016 | KB5002905 |
| SharePoint Server 2019 | KB5002894 |
| SharePoint Server Subscription Edition | KB5002893 |
SharePoint Server 2019의 KB5002894는 이전 KB5002883을 대체하며 패키지 빌드는 16.0.10417.20198입니다.
Subscription Edition의 KB5002893도 KB5002882를 대체하고 빌드는 16.0.19725.20522입니다.
새 패치를 계획하는 환경이라면 CVE의 최소 수정 빌드만 맞추기보다 현재 제공되는 최신 보안 업데이트를 적용하는 편이 안전합니다.
Step 2. 패치 파일 설치만 하고 끝내지 말 것
SharePoint 패치는 일반 Windows 업데이트와 달리 실행 파일 설치 후 Farm 구성 업그레이드 과정까지 완료해야 합니다.
Microsoft의 권장 업데이트 절차를 단순화하면 다음과 같습니다.
1. Farm 및 데이터베이스 백업
↓
2. 로드밸런서에서 대상 서버 제외
↓
3. 모든 SharePoint 서버에 보안 업데이트 설치
↓
4. 재부팅 필요 여부 확인
↓
5. SharePoint Products Configuration Wizard 실행
↓
6. 모든 Farm 서버에서 업그레이드 완료
↓
7. Central Administration에서 상태 확인
↓
8. 서비스 및 사이트 기능 테스트여러 WFE 서버가 있는 Farm에서는 일부 서버만 패치된 상태로 장시간 운영하지 않는 것이 좋습니다.
Microsoft도 모든 서버에 업데이트를 설치하고 Configuration Wizard를 순서대로 실행해 데이터베이스와 Farm 구성 요소의 build-to-build upgrade를 완료하도록 안내합니다.
Step 3. 패치 이후 Database Upgrade 상태 확인
SharePoint Management Shell에서 다음과 같이 확인할 수 있습니다.
Get-SPDatabase |
Select-Object Name, TypeName, NeedsUpgradeNeedsUpgrade가 남아 있다면 패치 실행 파일만 설치되고 Farm 업그레이드 과정이 제대로 끝나지 않았는지 더 확인해야 합니다.
중앙 관리의 Check upgrade status와 함께 업그레이드 로그도 확인합니다.
SharePoint 2016/2019/Subscription Edition의 업데이트 로그는 일반적으로 다음 경로에서 확인할 수 있습니다. Microsoft도 업데이트 후 해당 로그의 오류와 경고를 검토하도록 안내합니다.
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\16\LOGS대표적인 파일 이름은 다음과 같습니다.
Upgrade-YYYYMMDD-HHMMSS-SSS.log
Upgrade-YYYYMMDD-HHMMSS-SSS-error.log5. 당장 패치가 어렵다면 어떻게 해야 할까?
CVE-2026-55040은 네트워크에서 인증 없이 접근 가능한 취약점이므로 인터넷에 직접 노출된 SharePoint 서버는 우선순위를 높여야 합니다.
CVSS 벡터도 네트워크 공격, 낮은 공격 복잡도, 권한 불필요로 평가돼 있습니다.
패치를 즉시 적용하기 어렵다면 임시로 다음 방어를 고려할 수 있습니다.
- 인터넷에서 SharePoint에 직접 접근할 필요가 없다면 외부 접근 차단
- VPN 또는 Zero Trust Access 등을 통해 허용된 사용자만 SharePoint에 접근하도록 제한
- Reverse Proxy/WAF에서 SharePoint 접근 소스 제한
- 관리자 페이지와 관리용 인터페이스 외부 노출 최소화
- SharePoint/IIS 로그에서 비정상적인 인증 요청과 예상하지 못한 사용자 활동 확인
- SharePoint 서비스 계정 및 관리자 계정의 권한 최소화
- EDR을 통해 IIS Worker Process와 SharePoint 관련 프로세스의 비정상 자식 프로세스 생성 감시
다만 이러한 조치는 패치를 대체하지 않습니다.
인증 검증 로직 자체에 문제가 있으므로 방화벽 규칙 하나나 특정 URL 차단만으로 취약점이 근본적으로 수정되지는 않습니다.
6. JWT 취약점에서 관리자들이 놓치기 쉬운 부분
이 취약점은 JWT 보안에서 중요한 점을 보여줍니다.
“JWT를 파싱했다”와 “JWT를 검증했다”는 같은 의미가 아닙니다.
보안상 정상적인 JWT 검증에서는 최소한 다음 요소가 서로 연결돼 있어야 합니다.
JWT 구조 확인
↓
서명 알고리즘 정책 확인
↓
암호학적 서명 검증
↓
Issuer 검증
↓
Audience 검증
↓
토큰 유효기간 검증
↓
사용자 Identity 생성이 중 한 단계라도 다른 검증 과정과 분리돼 있으면 공격자가 인증 로직의 빈틈을 이용할 가능성이 생깁니다.
CVE-2026-55040이 좋은 사례인 이유는 각각의 검증 코드가 존재하는 것처럼 보여도 전체 파이프라인 차원에서는 신뢰 관계를 보장하지 못했다는 점입니다. Rapid7은 실제로 네 가지 약점이 결합되면서 최종 인증 우회로 이어진다고 분석했습니다.
7. 실무 점검 체크리스트
| 점검 항목 | 확인 내용 |
|---|---|
| CVE | CVE-2026-55040 |
| 제품 | Microsoft SharePoint Server |
| 취약점 유형 | Security Feature Bypass / Weak Authentication |
| CWE | CWE-1390 |
| CVSS | 9.1 Critical |
| 공격 경로 | Network |
| 사전 인증 | 필요 없음 |
| 사용자 동작 | 필요 없음 |
| 기술적 원인 | JWT 서명·인증서·Issuer 검증 파이프라인 문제 |
| 최초 패치 | 2026년 7월 14일 |
| 권장 대응 | 2026년 8월 최신 SharePoint 보안 업데이트 적용 |
| 추가 위험 | CVE-2026-63520과 결합한 비인증 RCE 체인 가능 |
| 패치 후 확인 | Farm Build + Patch Status + PSConfig/Upgrade Status |
8. FAQ
Q. SharePoint 사이트가 사내에서만 열리면 패치하지 않아도 될까?
그렇지 않습니다.
외부 인터넷 공격 가능성은 낮아지지만 사내 PC 침해, VPN 계정 탈취, 내부망 침투 등의 상황에서는 공격자가 SharePoint에 접근할 수 있습니다.
외부 노출 차단은 공격 표면을 줄이는 보조책이고 공식 보안 업데이트가 근본적인 대응책입니다.
Q. CVE-2026-55040 자체가 RCE 취약점인가?
아닙니다.
CVE-2026-55040 자체는 SharePoint JWT 인증 우회 취약점입니다.
다만 Rapid7은 별도의 SharePoint RCE인 CVE-2026-63520과 연결해 비인증 RCE 체인을 구성할 수 있음을 공개했습니다. CVE-2026-63520은 2026년 8월 보안 업데이트에서 수정됐습니다.
따라서 두 취약점을 함께 고려하면 7월 업데이트만 적용된 서버도 8월 최신 SharePoint 보안 업데이트까지 적용하는 것이 중요합니다.
Q. 7월 KB가 설치돼 있으면 CVE-2026-55040은 해결된 것 아닌가?
CVE-2026-55040 자체의 수정은 7월 업데이트에 포함됐습니다.
하지만 2026년 8월에는 CVE-2026-63520을 비롯한 추가 SharePoint 취약점에 대한 보안 업데이트가 발표됐으며 Microsoft의 8월 패키지는 이전 7월 보안 업데이트를 대체합니다.
따라서 현재 신규 점검을 하는 관리자라면 “CVE-2026-55040 최소 패치 여부”뿐 아니라 “최신 SharePoint 보안 업데이트까지 적용됐는가”를 확인하는 것이 더 실무적입니다.
마무리
CVE-2026-55040은 JWT를 사용하는 시스템에서 왜 서명 검증과 신뢰 체인 전체를 확인해야 하는지 보여주는 사례입니다.
SharePoint는 인증서 정보, Issuer, Actor Token 등 여러 요소를 확인했지만 일부 처리 흐름에서 암호학적 서명 검증과 신뢰 검증이 충분히 연결되지 않았습니다. 그 결과 여러 약점이 결합되면서 인증되지 않은 공격자가 SharePoint 사용자 신원을 가장할 가능성이 생겼습니다.
관리자는 다음 순서로 대응하면 됩니다.
SharePoint 제품/버전 확인
↓
Farm Build 확인
↓
최신 2026년 8월 보안 업데이트 적용
↓
Farm 전체 서버 패치 확인
↓
PSConfig / Configuration Wizard 완료
↓
Upgrade Status 및 로그 확인
↓
외부 노출 및 관리자 권한 재점검특히 패치 파일을 설치했다는 사실만으로 대응이 끝났다고 판단하지 말고, Farm 전체의 패치 상태와 SharePoint 구성 업그레이드까지 확인해야 합니다.