FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION.md

Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. Please note that while these registry settings would mitigate exploitation of this issue, it could affect regular functionality for certain use cases related to these applications.

MS Documentation for the referenced registry settings:

• https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330731(v=vs.85)#file-protocol-navigation (Thank you @johnmccash)

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION"
$applications = @("Excel.exe", "Graph.exe", "MSAccess.exe", "MSPub.exe", "PowerPnt.exe", "Visio.exe", "WinProj.exe", "WinWord.exe", "Wordpad.exe")

if (!(Test-Path -Path $registryPath)) {
    New-Item -Path $registryPath -Force | Out-Null
}
foreach ($app in $applications) {
    Set-ItemProperty -Path $registryPath -Name $app -Value 1 -Type DWord
}

I too am looking for a quick easy way to test this. I tried a shared .xlsm doc from onedrive and was able to execute a macro that had a child ping child process from explorer.exe and it was not blocked like I anticipated it would be.