Certighost 심층 분석: AD CS chase의 신뢰 경계가 Domain Controller 인증서로 이어진 과정

공격자가 CA의 서명키 없이 DC 인증서에 도달한 방법

Certighost는 공격자가 CA의 서명키를 훔치지 않고도 CA 서명 Domain Controller 인증서에 도달할 수 있었던 AD CS 취약점이다. 요청자가 지정한 endpoint가 target DC의 objectSid와 dNSHostName을 돌려주면, 취약한 CA는 그 신원 정보를 인증서에 넣어 서명했고 PKINIT는 인증서를 DC의 Kerberos 신원으로 해석할 수 있었다. 핵심 실패는 암호가 아니라 CA가 신원 정보를 받아올 상대를 결정하는 신뢰 경계에 있었다.

작성: 아도스 통합보안팀

CA가 공격자가 운영하는 endpoint에 접속해 "이 principal은 누구인가"를 묻는다. endpoint는 자신이 아니라 target Domain Controller(DC)의 SID와 DNS identity를 돌려준다. CA는 이 값을 디렉터리의 정식 응답으로 받아 인증서에 넣고, 자신의 키로 서명한다. 그 인증서를 Kerberos Key Distribution Center(KDC)에 제시하면 PKINIT mapping을 거쳐 target DC account의 신원으로 이어질 수 있다.

Certighost의 이상한 점은 공격자가 CA의 private key를 탈취하거나 서명을 위조하지 않았다는 데 있다. 서명은 처음부터 끝까지 정상이다. 공격자가 바꾼 것은 CA가 누구를 신뢰해 신원 정보를 받아오는지였다. routing hint여야 할 요청 값이 directory identity의 authority를 고르는 입력이 되면서, 공격자가 제공한 objectSid와 dNSHostName이 CA가 보증한 DC 신원으로 굳어졌다.

Certighost의 핵심 경로. DCSync는 공개 PoC가 자동 수행하는 단계가 아니라 확보한 DC identity에서 이어질 수 있는 별도 downstream impact다.

Microsoft CNA는 CVE-2026-54121을 부적절한 권한 검증(CWE-285)으로 분류했고, CVE Record는 CVSS v3.1 기본 점수 8.8을 부여했다. 네트워크에서 낮은 권한으로 접근할 수 있고 사용자 상호작용이 필요하지 않다는 평가다. 다만 점수만으로 개별 환경의 공격 가능성을 판단할 수는 없다. Enterprise CA 구성, template enrollment permission, chase 활성 상태, network reachability와 PKINIT mapping 조건이 함께 맞아야 한다.

문제는 인증서를 발급받았다는 사실 자체가 아니다. 그 인증서가 Kerberos에서 누구로 해석되는지가 다음 단계다.

인증서 하나가 Kerberos의 DC 신원이 되는 이유

Active Directory Certificate Services(AD CS)는 Active Directory와 통합되는 Microsoft의 공개 키 기반구조다. Enterprise CA는 certificate template의 등록 권한과 용도를 확인하고 X.509 인증서를 발급한다. 인증서는 공개 키와 신원 정보를 묶으며, CA의 서명은 그 결합을 신뢰할 수 있다는 근거가 된다. 자세한 등록 동작과 protocol field는 Microsoft Open Specifications의 MS-WCCE에서 확인할 수 있다.

PKINIT(Public Key Cryptography for Initial Authentication in Kerberos)는 비밀번호 대신 공개 키 인증서를 사용해 Kerberos 초기 인증을 수행하는 확장이다. 클라이언트가 CA 서명 인증서를 KDC에 제시하면 KDC는 인증서의 identity material을 Active Directory account에 mapping한다. mapping에 성공하면 KDC는 그 account의 Ticket Granting Ticket(TGT)을 발급한다.

따라서 인증서는 단순한 TLS 파일이 아니다. 사용자 인증서가 사용자 account에 mapping되면 사용자 TGT가 나오고, DC computer account의 신원이 담긴 인증서가 해당 account에 강하게 mapping되면 DC의 Kerberos identity로 이어질 수 있다. DC는 Active Directory 복제를 수행하는 computer account이므로 이 identity의 권한 범위는 일반 member server와 다르다.

H0j3n과 Aniq Fakhrul의 원문 revision은 공격자 endpoint가 반환한 objectSid와 dNSHostName이 인증서 identity에 영향을 주는 경로를 추적한다. objectSid는 AD security principal을 식별하는 SID이고, dNSHostName은 computer object의 DNS 이름이다. 취약한 흐름에서 CA는 두 값을 DC의 권위 있는 directory attribute처럼 소비했고, strong mapping SID와 DNS identity field가 들어간 인증서를 만들 수 있었다.

공격자는 CA의 trust chain을 위조하지 않았다. CA가 잘못 고른 신원을 정식 서명으로 고정했고, PKINIT가 그 결과를 Kerberos account로 해석했다. 그렇다면 CA는 왜 요청자가 정한 서버에 신원 정보를 물어보게 되었을까. 답은 AD CS의 원격 조회(chase) fallback에 있다.

문제의 시작인 AD CS chase와 `cdc`·`rmd`

CA가 모든 principal을 첫 LDAP lookup에서 찾는 것은 아니다. 서로 다른 DC나 directory context가 얽힌 등록에서는 요청자를 다시 찾기 위한 fallback이 필요하다. 연구자들이 chase라고 부른 경로는 첫 조회가 필요한 directory object를 해결하지 못했을 때 다른 DC를 따라가 principal lookup을 계속하기 위한 기능이다.

이 경로에는 두 request attribute가 관여한다. cdc(Client DC)는 CA가 접속할 host를 지정하고, rmd(Remote Domain)는 원격 directory에서 찾을 principal을 가리킨다. 두 값이 함께 들어오면 CA는 cdc host에 SMB와 LDAP로 접속하고 rmd에 해당하는 principal을 검색한다. 연구자의 packet capture와 PoC에서는 TCP 445의 SMB/LSA 경로와 TCP 389의 LDAP listener가 이 역할을 나눠 맡는다.

정상적인 trust relationship에서는 cdc가 신뢰할 수 있는 real Domain Controller를 가리킨다. network route와 directory authority가 같은 DC에 닿기 때문에 그 DC가 반환한 attribute를 AD가 관리하는 신원 정보로 취급할 수 있다. cdc는 조회 위치를 알려주는 routing hint이고, identity의 권위는 real AD directory에 남는다.

정상 흐름과 취약한 흐름은 CA가 directory authority를 어디에 두는지에서 갈린다. 요청자가 정한 network destination을 신원 권위로 승격한 것이 trust-boundary failure였다.

취약한 June 경로에는 cdc host가 실제 DC computer object인지 먼저 증명하는 단계가 없었다. network destination과 directory authority가 분리되지 않은 결과, 공격자가 정상 DC처럼 응답할 수만 있으면 CA가 그 endpoint의 directory data를 받아들였다.

CA가 공격자 endpoint를 directory authority로 받아들인 순간

공격자는 자신의 host를 cdc로 넣고 target DC의 DNS name을 rmd로 넣을 수 있었다. CA가 chase를 시작하면 requester-controlled endpoint로 SMB/LSA와 LDAP 연결이 향한다. rogue SMB/LSA service는 CA가 기대하는 domain authentication 흐름을 처리하고, rogue LDAP service는 rmd lookup에 대한 directory object를 반환한다.

반환되는 object는 rogue endpoint 자신의 신원이 아니다. 응답에는 target DC의 sAMAccountName, objectSid, dNSHostName이 들어간다. CA가 이 object를 인증서 subject를 구성할 directory record로 소비하면, 공격자가 공급한 target DC identity가 CA-signed certificate에 포함된다.

SMB나 LDAP를 사용했다는 사실만으로 취약점이 생긴 것은 아니다. 정상 AD 운영에서도 CA와 DC 사이의 protocol traffic은 필요하다. 실패 지점은 network path를 고르는 입력과 directory identity를 보증하는 authority를 같은 requester-controlled cdc에 맡긴 것이다. endpoint에 도달할 수 있다는 사실은 그 endpoint가 target DC의 신원을 말할 권한이 있다는 증명이 아니다.

이 차이는 탐지에서도 중요하다. 단순히 CA의 TCP 445 또는 389 egress만 차단 목록처럼 읽으면 정상 traffic과 공격을 구분하기 어렵다. Certighost는 CA가 평소 통신하지 않던 host로 나간 연결과, 그 직후 발급된 DC identity certificate를 하나의 chain으로 볼 때 비로소 선명해진다.

신뢰 경계의 실패를 실제 credential로 바꾸려면 몇 단계가 더 필요하다. 공개 PoC는 준비한 principal과 rogue service를 CA chase에 결합해 그 경로를 구체적으로 보여준다.

공개 PoC가 보여주는 실제 공격 chain

공개 PoC의 분석 기준 commit은 crafted request 하나만 보내고 끝나지 않는다. 낮은 권한 domain account로 AD 정보를 수집하고 CA와 target DC를 찾은 뒤, machine account를 준비해 rogue SMB/LSA와 rogue LDAP service를 띄운다. 이어 cdc와 rmd가 포함된 certificate enrollment request를 제출한다.

CA가 chase callback을 보내면 공격자 service는 target DC의 directory identity를 응답한다. CA가 서명한 target DC certificate가 돌아오면 PoC는 PKINIT를 수행하고, Kerberos credential cache와 target account NT hash를 얻는 단계까지 자동화한다. 이 범위는 certificate enrollment → PKINIT → credential cache → target account NT hash다.

실선은 공개 PoC가 자동화한 경로다. DCSync는 DC identity가 가진 replication rights에서 이어질 수 있는 possible downstream impact로 분리했다.

DCSync 요청은 공개 PoC의 자동화 범위에 포함되지 않는다. 원문은 확보한 DC identity가 가진 directory replication rights로 이어질 수 있는 후속 impact로 DCSync를 제시한다. 즉 PoC가 자동으로 얻는 마지막 결과는 target account NT hash이며, DCSync는 그 신원을 이용해 별도로 수행할 수 있는 downstream activity다.

이 구분이 impact를 약화하는 것은 아니다. DC computer account는 Active Directory 복제를 수행해야 하므로 directory replication 권한을 가진다. target DC의 Kerberos identity를 확보한 공격자가 후속 DCSync 계열 요청을 수행하면 krbtgt를 포함한 domain secret에 접근할 수 있고, 장기적인 Kerberos 위조나 추가 credential 탈취로 범위를 넓힐 수 있다. 다만 가능한 후속 impact와 PoC가 실제로 자동화한 동작은 같은 문장으로 합쳐서는 안 된다.

PoC가 machine account를 준비하는 이유도 이 chain 안에서 봐야 한다. rogue endpoint는 단순한 anonymous listener가 아니라 CA가 기대하는 domain authentication을 처리할 principal이 필요하다. machine account는 그 통신을 성립시키는 준비 수단이고, target DC의 identity를 rogue LDAP 응답에 넣는 동작과 결합된다.

`ms-DS-MachineAccountQuota`가 담당한 공격 준비 단계

연구자 lab은 기본 ms-DS-MachineAccountQuota 값 10을 사용했다. 이 attribute는 일반 domain user가 domain에 만들 수 있는 computer account 수를 제한한다. 새 machine account는 AD가 인정하는 security principal이므로 rogue endpoint가 CA와 통신할 때 필요한 domain authentication의 발판이 된다. PoC의 SMB/LSA service는 real DC의 Netlogon을 이용해 authentication challenge를 처리하면서, directory lookup에는 target DC identity를 돌려준다.

ms-DS-MachineAccountQuota=10 자체가 Certighost 취약점은 아니다. 값을 0으로 낮추면 일반 사용자가 새 computer account를 만드는 경로는 줄지만, 공격자가 이미 제어하는 computer principal을 재사용할 가능성은 남는다. delegated computer creation 권한이나 기존 machine credential도 별도로 점검해야 한다.

따라서 ms-DS-MachineAccountQuota=0은 공격 준비를 어렵게 하는 보조 통제다. CA가 requester-controlled endpoint를 directory authority로 신뢰하는 근본 원인을 고치지 않으며, 보안 업데이트를 대체하지 못한다. 이 distinction은 실제 환경의 전제조건을 평가할 때도 유지해야 한다.

PoC가 어떻게 취약 경로를 활용했는지 확인했다면, 이제 certpdef.dll 내부에서 어떤 authenticity guard가 빠져 있었는지 볼 수 있다.

June build에서 가능했던 직접 chase

연구자들은 AD CS Certificate Policy Enterprise module인 certpdef.dll의 June build와 July build를 비교했다. 취약한 integration point는 CRequestInstance::_LoadPrincipalObject다. June 경로에서 이 함수는 polGetRequestAttribute("cdc")로 request attribute를 읽고, chase가 활성화된 CRequestInstance::_GetDSObject에 requester-controlled target을 넘긴다.

June / vulnerable path

polGetRequestAttribute("cdc", &target)
        |
        v
CRequestInstance::_GetDSObject(policy, chase=1, target)
        |
        v
remote directory object
        |
        v
certificate identity material

CRequestInstance::_GetDSObject는 directory lookup sink 역할을 한다. 그러나 June 흐름에서는 target이 real AD DC object를 가리키는지 확인하는 authenticity guard가 이 호출 앞에 없었다. domain principal처럼 응답하는 requester-controlled endpoint가 chase target이 될 수 있었고, 그 endpoint가 반환한 object가 certificate identity material로 흘렀다.

CRequestInstance::_GetObjectSID는 원래 SID retrieval path에 참여한다. 하지만 공격자 endpoint가 돌려준 object를 real AD가 알고 있는 DC identity에 다시 묶어 검증하는 July의 SID comparison은 June 경로에 없었다. 이 때문에 network routing hint와 directory authority 사이의 간극을 메울 수 없었다.

July 수정은 chase 기능 전체를 삭제하지 않았다. 대신 _GetDSObject 앞에서 target을 검증하고, 조회 뒤에 SID를 재검증해 trust anchor를 Active Directory로 되돌렸다.

July patch가 되돌린 신뢰 경계

July build의 CRequestInstance::_LoadPrincipalObject는 Feature_3185813818 servicing gate를 확인한다. 보호 경로가 활성화되면 CRequestInstance::_ValidateChaseTargetIsDC를 먼저 호출하며, 검증을 통과한 cdc만 CRequestInstance::_GetDSObject(..., chase=1, validated_cdc)로 전달한다. 조회가 끝난 뒤에는 CRequestInstance::_GetObjectSID 경로에서 resolved object의 SID를 다시 비교한다.

July 보호 경로는 trust anchor를 requester-controlled endpoint에서 real AD가 검증한 Domain Controller object로 옮겼다. 선행 target validation과 후행 SID comparison이 같은 경계를 양쪽에서 고정한다.

CRequestInstance::_ValidateChaseTargetIsDC는 먼저 target의 형태를 검사한다. 빈 값과 260자를 넘는 값을 거부하고 IPv4·IPv6 literal을 차단한다. LDAP filter slot을 공격자가 바꾸지 못하도록 (, ), *, [, \, ] 문자도 거부한다. 이 검사는 malformed host와 filter manipulation을 줄이지만, 핵심은 다음 real AD lookup이다.

보호 경로는 real Active Directory에 다음 의미의 filter를 질의한다.

(&(objectCategory=computer)
  (dNSHostName=<cdc>)
  (userAccountControl:1.2.840.113556.1.4.803:=8192))

8192는 SERVER_TRUST_ACCOUNT bit다. 따라서 결과는 cdc와 DNS 이름이 같고 DC trust account로 표시된 computer object여야 한다. 검색 결과가 없으면 CRequestInstance::_ExtractBaseDNForDCSearch가 추출한 base DN으로 한 번 더 찾는다. 결과가 정확히 하나가 아니면 request는 error path로 이동한다.

검증된 host에 대해 chase를 수행한 뒤에도 보호는 끝나지 않는다. _GetDSObject가 해결한 object의 SID를 CRequestInstance::_GetObjectSID로 가져와 expected DC SID와 비교한다. hostname validation은 callback destination을 real DC object에 묶고, SID comparison은 remote lookup 결과가 다른 object로 치환되는 것을 막는다.

연구자 분석에는 feature gate가 비활성화된 legacy branch도 patched binary에 남아 있다고 적혀 있다. 이 관찰을 임의의 registry toggle이나 공개된 우회로 확대 해석해서는 안 된다. 운영 관점에서는 binary 파일의 존재만 확인하지 말고 지원되는 cumulative update와 servicing 상태가 실제 보호 경로를 활성화한 정상 build인지 검증해야 한다.

이제 patch의 의미는 분명하다. June에는 "domain principal처럼 응답한 host"가 chase target으로 충분했지만, July에는 real AD가 cdc를 Domain Controller object로 확인하고 resolved SID까지 일치해야 한다. 남은 문제는 어느 환경에서 이 취약 경로와 공격 준비 조건이 함께 성립하는지다.

실제 환경에서 공격이 성립하는 조건

Microsoft CNA가 공개한 fixed build 경계는 Windows Server 2012 6.2.9200.26226, Server 2012 R2 6.3.9600.23291, Server 2016 10.0.14393.9339, Server 2019 10.0.17763.9020, Server 2022 10.0.20348.5386, Server 2025 10.0.26100.33158이다. Server Core installation도 해당 항목에 포함된다. 제품별 영향과 servicing 정보는 MSRC Security Update Guide와 CVE Services CNA JSON record를 함께 대조해야 한다.

예를 들어 Server 2022의 July cumulative update KB5099540은 OS build 20348.5386을, Server 2016의 KB5099535는 14393.9339를 제공한다. HA나 계층형 PKI에서는 각 issuing CA의 OS version, cumulative update, restart 상태를 따로 확인해야 한다.

취약 build만으로 PoC chain 전체가 자동 성립하지는 않는다. AD CS Enterprise CA가 있어야 하고 공격자가 유효한 domain principal로 인증할 수 있어야 한다. 사용할 수 있는 certificate template과 enrollment permission, chase fallback, CA에서 attacker endpoint까지의 SMB/LDAP reachability, machine principal 준비 방법도 맞아야 한다.

인증서 쪽 조건도 환경에 좌우된다. request-supplied SAN을 허용하는 ESC6 구성에서는 target DC DNS name을 SAN에 맞춰야 PKINIT의 client-name mismatch를 피할 수 있다. 반대로 AD에서 subject를 만드는 template은 request SAN을 무시한다. forest functional level, KDC의 certificate-to-account mapping, template behavior를 실제 구성에서 확인해야 한다.

연구자 lab은 Windows Server 2016 이상 forest functional level, default Machine certificate template와 ACL, 기본 machine-account quota, 접근 가능한 Enterprise CA를 사용했다. 이 결과를 "낮은 권한 계정 하나만 있으면 모든 AD가 장악된다"고 일반화할 수 없는 이유다. 인터넷에 CA web enrollment endpoint가 보이지 않는다는 사실도 안전의 증거가 아니다. 핵심 traffic은 domain 내부의 CA, attacker-controlled endpoint, DC/KDC 사이에서 흐른다.

위험 지표도 기술적 impact와 분리해 읽어야 한다. FIRST EPSS API의 2026년 8월 13일 값은 0.01052(1.052%), percentile은 0.6131이었다. CISA KEV catalog의 2026년 8월 11일 공개본에는 CVE-2026-54121이 없었다. 낮은 EPSS와 KEV 미등재는 공개 PoC가 보여준 domain impact를 부정하지 않으며 실제 악용이 없다는 증거도 아니다.

환경 조건을 확인한 뒤에는 개별 event보다 chain의 모양을 찾아야 한다. Certighost의 각 단계는 따로 보면 정상 관리 행위와 닮아 있기 때문이다.

방어자가 공격 chain에서 관찰할 지점

Certighost는 단일 event ID로 탐지하기 어렵다. computer account 생성, certificate enrollment, CA chase callback, DC certificate issuance, PKINIT와 replication은 서로 다른 log source에 남는다. Microsoft Defender 탐지 가이드도 endpoint, identity와 certificate telemetry를 함께 보는 접근을 제시한다.

단일 indicator보다 시간순 correlation이 중요하다. 정상 DC certificate renewal은 requester, source host와 CA callback destination이 예상 범위에 머무는 반면, 공격 chain은 낮은 권한 principal과 비정상 CA egress가 같은 발급 기록에 수렴한다.

machine account creation만으로는 충분한 signal이 아니다. ms-DS-MachineAccountQuota가 기본값인 환경에서 정상적인 computer join도 같은 event를 만들 수 있다. 생성 주체가 낮은 권한 사용자였는지, 직후 certificate enrollment가 있었는지, 새 principal과 연결된 host로 CA가 TCP 445·389 연결을 열었는지를 함께 봐야 한다.

CA database와 Certificate Services audit에는 request attribute, template, requester, issued subject·SAN, serial number를 보존해야 한다. DC의 SID나 DNS identity와 연결되는 certificate가 일반 machine account의 request 뒤에 발급됐다면 우선 조사 대상이다. 정상 DC certificate renewal과 구분할 때는 requester, template, source host, 발급 주기와 CA callback destination을 기존 baseline과 비교한다.

후속 단계에서는 새 certificate를 이용한 PKINIT와 target DC account의 TGT 발급을 찾는다. 이어 그 identity가 평소 replication partner가 아닌 host에서 directory replication request를 보내는지 확인한다. 이 단계에 도달했다면 단순한 발급 오류가 아니라 domain secret 노출 가능성이 있는 incident로 다뤄야 한다.

machine principal 준비, 비정상 CA SMB/LDAP egress, DC certificate issuance, PKINIT와 replication activity가 짧은 시간 안에 이어지면 개별 event의 오탐 가능성을 크게 줄일 수 있다. 탐지의 목적은 Figure의 모든 지점을 각각 경보로 만드는 것이 아니라, 서로 다른 telemetry가 같은 principal·certificate·시간축에 수렴하도록 만드는 데 있다.

관찰 지점을 정했다면 대응 순서도 trust boundary를 직접 고치는 조치부터 시작해야 한다.

패치와 운영 통제의 우선순위

가장 먼저 할 일은 CA host에 2026년 7월 또는 그 이후의 보안 업데이트를 적용하는 것이다. 다음으로 실제 OS build가 CNA의 fixed build 경계 이상인지 확인한다. update 설치 기록이나 certpdef.dll 파일 하나만으로 끝내지 말고, 모든 issuing CA의 cumulative update와 restart 상태를 검증해야 한다. patch가 requester-controlled endpoint에서 AD-validated Domain Controller로 trust anchor를 옮기는 primary remediation이다.

patch를 즉시 적용할 수 없는 환경에 한해 연구자 원문이 제시한 chase disable hot fix를 임시로 검토할 수 있다.

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

이 조치는 연구자 lab에서만 확인됐으며 legitimate cross-DC enrollment를 실패시킬 수 있다. staging CA에서 enrollment dependency를 확인한 뒤 제한적으로 사용해야 한다. July update를 대신하는 영구 대책으로 취급해서는 안 된다.

그 다음은 exposure와 공격 준비 경로를 줄이는 운영 통제다. certificate template enrollment ACL과 computer object 생성 권한을 업무상 필요한 principal로 제한한다. ms-DS-MachineAccountQuota를 낮추는 조치는 도움이 되지만 기존 computer principal과 delegated creation rights를 함께 보지 않으면 불완전하다.

CA의 SMB·LDAP egress는 알려진 DC와 필요한 directory service로 제한하는 방향이 바람직하다. 바로 차단하기 전에 정상 enrollment와 cross-DC lookup 경로를 식별하고, 예외는 destination과 protocol 단위로 좁게 유지한다. 이 통제는 비정상 callback을 막거나 가시화할 수 있지만 vulnerable binary를 그대로 두는 이유가 되어서는 안 된다.

침해가 의심되면 발급 certificate의 serial, request record와 CA database를 확보하고 revoke만으로 조사를 끝내지 않는다. CA log, DC security log, KDC telemetry, directory change와 network flow를 같은 timeline에 보존한다. replication 단계가 확인되면 domain secret이 이미 노출됐을 수 있으므로 krbtgt를 포함한 credential rotation 범위를 incident-response 절차에 따라 결정해야 한다.

Certighost가 드러낸 것은 certificate template misconfiguration만이 아니다. CA가 directory identity를 가져오는 경로 자체가 authentication boundary다. July 변경은 cdc를 real DC에 묶고 resolved SID를 다시 확인함으로써, 그 경계를 request parameter에서 Active Directory의 DC object로 되돌렸다.

참고 자료

• H0j3n·Aniq Fakhrul, Certighost 원문 분석 revision d9d7f21
• Aniq Fakhrul, CVE-2026-54121 공개 PoC commit 34d3067
• Microsoft Security Update Guide: CVE-2026-54121
• CVE.org: CVE-2026-54121
• CVE Services CNA JSON record
• Microsoft Open Specifications: MS-WCCE
• Microsoft Defender: Detecting CVE-2026-54121
• Microsoft Support: KB5099540, Windows Server 2022 build 20348.5386
• Microsoft Support: KB5099535, Windows Server 2016 build 14393.9339
• FIRST EPSS API: CVE-2026-54121
• CISA Known Exploited Vulnerabilities Catalog

---