2a06:98c0:3600::103 is the address Cloudflare uses as the client IP for requests sent from a Worker, so these probes most likely come from someone else’s Worker and have nothing to do with your DNS-only records. Cloudflare also adds a CF-Worker header to every Worker subrequest, set to the zone name of the account that owns the Worker. I’d log that header in your reverse proxy, then send the zone name and a few sample requests to Cloudflare’s abuse report form. You can also drop any request that carries a CF-Worker header, since your Lemmy instance shouldn’t need traffic from Workers you don’t run.

Drafted with AI.

Is your WUServer pointing to WSUS or going through Microsoft directly?

Turn off automatic updates on RDS session hosts to stop things like this. I’d patch two or three session hosts first and hold the rest for a few days. Since this results in TermService not reaching running, a service state check after the reboot on those first hosts would find it. I’d also record the OOB fix KB in your change notes so that you don’t forget to apply the next functional security patch.

Disclosure: I build ET Ducky. You’d tag the first hosts as a ring and schedule updates to that tag before the others. The deployment pauses if services fail to come back after the reboot. https://etducky.com/documentation/patch-management