I blogged about a similar situation years ago, when a page had granted edit permission to "all users" (including unauthenticated) and crawling by a search bot triggered the "delete" option in module menu.
you should check DNN and IIS logs to find hints, how the delete might.have happened.

Yes we are checking the logs. We havent found anything that indicated what happened. The weird thing is that the deleted modules are not in the recycle bin either.
Any other ideas what might have happened .? Its really alarming.

Are they still in the database tables? Has database been restored or rolled back? If it's on a VM, has the VM been restored to an earlier snapshot?

No, the modules (at least the one I checked) are absent from the database (at least when I look at the TabModules table) for that particular page's TabID. )

Were these modules "shared" instances?  Meaning, were they shared by another page that unknowingly were hosting the "parent" instance? 

I had the same issue once.
The customer had set edit permissions to all users. Then the Google bot came by and tried all links, including 'delete'...

Posted By Tycho de Waard (SU) on 1/25/2023 11:57 PM

I had the same issue once.
The customer had set edit permissions to all users. Then the Google bot came by and tried all links, including 'delete'...

Oh... I've never run into that before.  That's what Sebastian meant.  🤯 

 

https://www.dnnsoftware.c...shing-website-pages.

Mentioned SQL Script "adjustDNNPermission.SQL" is part of my TurboDNN Package, you may download from https://github.com/dnnwerk/dnnScript

In this case, those modules either need to somehow be recreated from the backup, or the back gets restored somewhere, and a person manually does this module-by-module.  :( 

(Because, if it's in the wild and in use by people, restoring and deploying a restored backup may no longer be an option.)