CVE-2026-21510: When the Prompt Doesn’t Show Up

CVE-2026-21510: When the Prompt Doesn’t Show Up What a Windows Shell Trust-Boundary Failure Means in Practice

1) Treat it as a trust-boundary failure, not “just another Patch Tuesday item”

NVD characterizes CVE-2026-21510 as a protection mechanism failure in Windows Shell that lets an attacker bypass a security feature. It carries a CVSS v3.1 base score of 8.8 (network-reachable, low complexity, no privileges required; user interaction remains).(NVD)

That’s already a serious profile. What pushes it into “drop everything” territory is the operational context:

Microsoft has flagged exploitation, and multiple Patch Tuesday roundups list it as actively exploited / zero-day class.(ブリーピングコンピューター)
CISA added it to the 既知のエクスプロイトされた脆弱性（KEV） catalog with a remediation due date of 2026-03-03 (a real prioritization lever inside organizations).(NVD)

ZDI’s Patch Tuesday review makes the defender-relevant point bluntly: even though Microsoft labels it as a “feature bypass,” in practical terms it’s close to one-click execution because the safety boundary you expect (SmartScreen / prompts) doesn’t reliably appear.(Zero Day Initiative)

Try One Click Hacking >>

2) The real damage: SmartScreen / MOTW / Shell prompts stop being a dependable line of defense

Most endpoint programs implicitly rely on a chain of friction:

MOTW (Zone.Identifier) signals “this came from the Internet.”
SmartScreen and shell prompts add “are you sure?” moments at the exact point users make mistakes.

For CVE-2026-21510, the “cost” of exploitation is lower because the user never gets the psychological speed bump.

Sophos quotes Microsoft’s description: an attacker could bypass SmartScreen and Shell prompts, allowing attacker-controlled content to execute without warning or user consent, and it affects all supported Windows (client and server).(sophos.com)

Rapid7 frames related risk in terms of trust markings and “Mark-of-the-Web” realities in enterprise pipelines (where tags can be lost through common workflows).(ラピッド7)

3) Likely delivery patterns: links and shortcuts are the cheap, scalable carrier

Across reporting, the recurring exploitation narrative is consistent: convince the user to open a malicious link or shortcut file (often discussed in the context of .lnk) and the normal warnings don’t show.(セキュリティ・ウィーク)

This doesn’t mean the CVE is the whole intrusion. It means it’s a reliability booster for initial access:

fewer user-reported “weird warning” moments
fewer early IR tickets
easier mass-targeting because “one click” is a scalable requirement

That is exactly why it shows up alongside other exploited February 2026 issues in major Patch Tuesday roundups.(ブリーピングコンピューター)

4) Related CVEs worth modeling alongside CVE-2026-21510

These aren’t filler. They’re how real-world attackers build chains: bypass → execute → escalate.

CVE	コンポーネント	クラス	なぜそれが重要なのか
CVE-2026-21510	Windows Shell	Security feature bypass (exploited)	Suppresses safety prompts, making initial access more reliable.(NVD)
CVE-2026-21513	MSHTML framework	Security feature bypass (exploited)	Often discussed in the same “file / shortcut / rendering” orbit during Feb 2026 Patch Tuesday.(ブリーピングコンピューター)
CVE-2026-21514	Microsoft Word	Security feature bypass (exploited)	Document open workflows remain a prime initial access vector.(セキュリティ・ウィーク)
CVE-2026-21519	デスクトップ・ウィンドウ・マネージャー	EoP (exploited)	Common post-compromise move to elevate privileges.(Tenable®)
CVE-2026-21525	RasMan	DoS (exploited)	Not always core, but exploited status signals attacker attention.(Tenable®)

CVE-2026-21510

One Click PoC >>

5) “Top CTR terms” in the wild: what people are actually clicking on

Publicly, you can’t see true Google CTR per query without owning the Search Console/ads data. But you 缶 infer what’s pulling clicks by looking at how the top security publishers frame the story.

For Feb 2026, the high-click intent cluster is consistent across BleepingComputer, Sophos, Rapid7, Tenable, CrowdStrike, SecurityWeek:

“actively exploited / zero-day”
“SmartScreen / security prompt bypass”
“Patch Tuesday fixes X zero-days”(ブリーピングコンピューター)

Those phrases match how engineers triage: Is it exploited? Does it hit endpoints? What do I patch first?

We’ve integrated that same intent into this piece, but kept it engineering-first: actionable detection, verification, and durable controls.

6) Prioritization: patching is necessary — “provable remediation” is the goal

Use a 3-signal triage triangle rather than CVSS alone:

Exploit reality (KEV + exploited in the wild + low-friction UI)(NVD)
Exposure (user populations with heavy external file flow: finance, sales, HR, support)
Ingress paths (Downloads, web cache, sync folders, VDI redirection, shared drives)

Your two audit-grade questions should be:

Can we 証明する our MOTW/SmartScreen trust chain still behaves correctly after patching?
If the prompt is bypassed, what second-line controls still prevent execution (ASR/WDAC/app control/EDR containment)?

7) Validation you can defend: check trust markings, not just “patch installed”

7.1 MOTW (Zone.Identifier) inventory in common ingress folders

# Inventory suspicious files lacking MOTW (Zone.Identifier) in common ingress folders
$paths = @(
  "$env:USERPROFILE\\Downloads",
  "$env:USERPROFILE\\Desktop",
  "$env:USERPROFILE\\Documents"
)

$exts = @("exe","dll","js","vbs","ps1","cmd","bat","lnk","url","hta","msi","iso","img","zip")

$results = foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem -Path $p -Recurse -File -ErrorAction SilentlyContinue |
      Where-Object { $exts -contains $_.Extension.TrimStart(".").ToLower() } |
      ForEach-Object {
        $zone = Get-Content -Path ($_.FullName + ":Zone.Identifier") -ErrorAction SilentlyContinue
        [PSCustomObject]@{
          Path = $_.FullName
          Extension = $_.Extension
          HasMOTW = [bool]$zone
          ZoneId = ($zone | Select-String "ZoneId" | ForEach-Object { $_.ToString() }) -join ";"
          LastWriteTime = $_.LastWriteTime
        }
      }
  }
}

$results | Sort-Object HasMOTW, LastWriteTime -Descending | Select-Object -First 200

Rapid7’s Patch Tuesday write-up explicitly situates the month’s risk around exploitation signals and MOTW realities in enterprise workflows (where “marking” can be lost).(ラピッド7)

CVE-2026-21510

Try AI Hacker Tool >>

8) Detection engineering: build reusable “LNK/Explorer execution-chain” primitives

8.1 Sigma template

title: Suspicious Child Process Spawned by Explorer After LNK Open
id: 3b1d2a52-6b9b-4cc1-9b5e-21510-template
status: experimental
description: Detects suspicious process execution spawned by explorer.exe that often follows malicious LNK execution chains (SmartScreen / prompt bypass context).
references:
  - <https://nvd.nist.gov/vuln/detail/CVE-2026-21510>
  - <https://www.cisa.gov/known-exploited-vulnerabilities-catalog>
author: detection-engineering
date: 2026/02/16
logsource:
  product: windows
  service: sysmon
detection:
  selection_parent:
    ParentImage|endswith: '\\explorer.exe'
  selection_suspicious_child:
    Image|endswith:
      - '\\powershell.exe'
      - '\\pwsh.exe'
      - '\\cmd.exe'
      - '\\wscript.exe'
      - '\\cscript.exe'
      - '\\mshta.exe'
      - '\\rundll32.exe'
      - '\\regsvr32.exe'
      - '\\bitsadmin.exe'
  selection_user_paths:
    CommandLine|contains:
      - '\\Users\\'
      - '\\Downloads\\'
      - '\\AppData\\Local\\Temp\\'
  condition: selection_parent and selection_suspicious_child and selection_user_paths
falsepositives:
  - Rare: legitimate scripting from Downloads
level: high
tags:
  - attack.initial_access
  - attack.execution

This is durable because it doesn’t depend on a specific exploit; CVE-2026-21510 simply makes the chain more reliable.(Zero Day Initiative)

8.2 Microsoft Defender KQL hunting examples

// Explorer spawning script interpreters or LOLBins from user-writable paths
DeviceProcessEvents
| where InitiatingProcessFileName =~ "explorer.exe"
| where FileName in~ ("powershell.exe","pwsh.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe")
| where ProcessCommandLine has_any ("\\\\Users\\\\", "\\\\Downloads\\\\", "\\\\AppData\\\\Local\\\\Temp\\\\")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, FolderPath, InitiatingProcessCommandLine
| order by Timestamp desc

// LNK files created in common ingress folders
DeviceFileEvents
| where FileName endswith ".lnk"
| where FolderPath has_any ("\\\\Downloads\\\\", "\\\\Desktop\\\\", "\\\\AppData\\\\Local\\\\Temp\\\\", "\\\\INetCache\\\\")
| project Timestamp, DeviceName, AccountName, ActionType, FolderPath, FileName, SHA256
| order by Timestamp desc

The emphasis on links/shortcuts is consistent across Patch Tuesday reporting.(セキュリティ・ウィーク)

AIペンテストツールを試す

9) Hardening: assume prompts can fail, and design for “execution still blocked”

Start with the highest ROI moves:

strengthen ASR / script control for high-risk user groups
block high-risk interpreters/LOLBins from user-writable paths
raise EDR severity on “Downloads → Explorer → script/LOLBins” chains

Think of it as building a second line behind SmartScreen/MOTW, not replacing them.

For teams pushing “provable remediation,” the pain is rarely understanding the CVE — it’s turning validation into repeatable evidence. Platforms like Penligent (AI-driven pentest + verification workflows) can help operationalize that: standardize environment baselines, validation steps, and evidence capture so “we fixed it” becomes a defensible artifact, not a hope.

Also, the difference between “feature bypass” and “effectively one-click execution” changes how you prioritize. ZDI explicitly calls out that practical classification gap.(Zero Day Initiative)