A group of Microsoft Products and technologies used for sharing and managing content, knowledge, and applications.
We had the same issue in my office. Anything uploaded prior to 9/10/24 still works, but anything after that date is forcing a download. I have been working with Microsoft engineers on this issue. We took logs, tried tests in multiple tenants, and with different settings. After their investigation, they came back with the following reply. Below is a copy/paste of the response.
ASPX pages will only render if custom scripting is allowed on the Site and was allowed at the time of upload and was uploaded by an account that has 'addandcustomizepages' permissions. If custom scripting is not allowed, or the account does not have that permission, the ASPX page is marked NoExecute. Even if the scripting is then allowed and the permission assigned, you will still not be able to open that until it has been reuploaded, as it was marked NoExecute due to custom scripting not being allowed/ the permission of the uploader to use custom scripting, which comes from the 'addandcustomizepages' permissions.
We had custom scripting disabled in our tenant prior to 9/10, so we didn't think that was the issue, but after testing we did confirm that when we met BOTH conditions (permission granted to uploading person, and custom scripts enabled at time of upload), we were able to successfully render the ASPX file. Even after custom scripts were turned back off, that ASPX file was still working.
My assumption (not confirmed by MS) is that there was some change during the security updates on the 10th that caused some kind of enforcement that was being missed prior to the update.