Has anyone else seen a massive spike today in “Suspicious Process - Shim Install” alerts in InsightIDR?
We manage multiple unrelated InsightIDR tenants and, since August 27, 2026, we have started receiving hundreds of these detections across different customer environments.
Everything we have checked so far looks like legitimate Windows activity:
sdbinst.exe is running from C:\Windows\System32
User is NT AUTHORITY\SYSTEM
Parent is rundll32.exe
Parent command line references PcaSvc.dll,PcaPatchSdbTask
SDB path is C:\Windows\appcompat\cloudsdb\apppatch.sdb
Same SHA256 seen across multiple endpoints: 3b05a3ebf55b8847191fcb61f6dc4d3b14f2ca82eaf9329cd66812dbfa0508bd
Rapid7 reputation shows Known / Threat level None / Very High reliability / 0 of 36 engines
Binary version seen: 10.0.26100.9168
At this point this looks much more like legitimate Windows Application Compatibility activity triggering a generic shim-install detection than actual persistence activity.
Is anyone else seeing the same flood of alerts across their tenants?
Also, has Rapid7 confirmed whether this is a known issue or whether the detection logic recently changed?
We obviously do not want to globally suppress sdbinst.exe, since malicious shim installation is a valid technique, but the exact PcaPatchSdbTask -> sdbinst.exe -> cloudsdb\apppatch.sdb chain appears to be generating a huge amount of benign noise.
Interested to know whether others are seeing exactly the same thing and how you are handling the exception.
Yes, the same happened for us the last 2 hours. We are still investigating, but we have already opened a support ticket with Rapid7 since it indeed looks like legitimate Windows system maintenance.
We are seeing the same activity in our managed tenants as well and also waiting for a response from Rapid7 about that.
The rule does not indicate a recent change in the logic, but simillar issue occured before as well when they changed a logic of a rule and triggered legitimate activity with it.
Review the logst from the past 7-14 days and group them by process name, cmd_line and parent process.exe. If you get a match of the query you can apply temporary exception for the parent process, not the sdbinst.exe until the R7 fix this.
Our Detection team for SIEM has investigated and resolved the issue.
The spike in "Suspicious Process - Shim Install" alerts was caused by legitimate Windows activity and should no longer occur. If you applied any temporary exceptions for this activity, you can safely remove them.
If you continue to see unexpected alerts related to this detection, please open a Support case so we can assist. Thanks
We've had the same problem; within a 2-hour span we received alerts with the same subject, 'Suspicious Process - shim Install.' Thanks for the clarification.
Rapid7 Support has replied to my case and confirmed that the spike in “Suspicious Process - Shim Install” alerts was caused by legitimate Windows Application Compatibility activity triggering the detection rule.
They also confirmed that the detection logic has now been updated in production to exclude the benign pattern, so the false positives should stop.
However, they have not provided any real technical detail on the root cause — for example, whether this was triggered by a recent Windows update, a change in Windows Application Compatibility behavior, a change in Rapid7 detection logic, or a combination of these factors.
I have asked support for more information because we need to explain to our customers not only that it was a false positive, but also why it suddenly started happening across multiple unrelated tenants.
If anyone has received a more detailed explanation from Rapid7, or has identified the underlying Windows change that triggered this, I would be very interested in the details.
After further research the activity is the Windows Program Compatibility Assistant (PCA) service (PcaSvc) performing routine maintenance via its scheduled task PcaPatchSdbTask.
This task invokes rundll32.exe with PcaSvc.dll,PcaPatchSdbTask, which in turn runs sdbinst.exe -q to install or update cloud-delivered application compatibility fix databases (apppatch.sdb) from C:\Windows\appcompat\cloudsdb\.
This is a standard Windows mechanism and Microsoft maintains compatibility shim databases that allow older or incompatible applications to run on newer Windows versions.
These databases can be delivered independently of Windows Update via a cloud sync mechanism, meaning they can arrive at any time without a corresponding KB installation.
Microsoft pushed an updated cloud-delivered compatibility database on or around August 27, which triggered the PcaPatchSdbTask across all endpoints receiving the update. Notably, the August 2026 Patch Tuesday update (KB5121003, released August 11) introduced known gaming compatibility issues on Windows 11 24H2/25H2 (Build 26100.9168 / 26200.9168).
It is plausible that Microsoft deployed an out-of-band compatibility fix database via the cloud delivery channel to address these issues, which would explain the timing gap and why the PcaPatchSdbTask fired broadly across environments.
This is consistent with how the PCA cloud delivery system works: it operates independently of the standard Windows Update cadence and can push database updates at any time.
Our Detection team has updated the rule to exclude this specific benign pattern.
Thank you so much for digging into this! I was so relieved to find this post after our EDR generated numerous alerts for this exact event. Case closed!
