The macOS Installer copies files into the desired "/Applications/<app>" or other path as described in the .pkg configuration files. These files are readable/writable by the user installing the application by default. It's not uncommon for installers (particularly those that require elevated permissions) to operate on files in these locations prior to finishing the installation. The most common use-case for this is to copy LaunchDaemons to the correct location or perform other privileged actions during a postinstall script.
It is possible for files in the applications directory to be modified prior to the postinstall script accessing them. In many cases, the postinstall script is used to implement stricter permissions on files of this nature. There is a small window of time between the copying of application files to the "/Applications/<app>" folder and the running of a postinstall script where a malicious actor could modify files that are later used at a higher privilege level. In many instances we've observed this happening in, overwriting these files generally results in local privilege escalation.
This issue is something that can be addressed by individual developers by validating the integrity of files during the installation process. This could, however, also be addressed within Installer itself by using stricter file ownerships and permissions. For example, when installing an application that requires elevated privileges to install (such as Microsoft Teams), the files extracted and moved to "/Applications/<app>" could be made to be owned by root initially rather than relying on the postinstall script to modify these permissions manually. This would greatly enhance the security posture of Installer.
Please note that this issue is very similar to an issue reported in July 2020 by NCC Group: https://research.nccgroup.com/2020/07/02/technical-advisory-macos-installer-local-root-privilege-escalation-cve-2020-9817/.