That would require a malware specifically tailored to target Qubes systems. But seems possible to me.
You can avoid this behaviour! See How to make any file persistent (bind-dirs) — Qubes OS Documentation. It will allow you to choose what directories are persistent via dom0 or your template.
However…
However, I would tend to think that, having bind-dirs configured or not does not make a great difference: as you probably know, the home folder of the AppVM is, by default, persistent between reboots too, thus, even without bind-dirs, a malware could implant itself under /home/user/..., and, say, autostart by adding smth like ./path/to/the/malware into your .bashrc.
The real vulnerability lies, in my eyes, in the persistence of the home folder (or any other), not in the existence of bind-dirs (that’s why should should use disposables everywhere you can).
Nonetheless, it is true that you actually need some persistence, for storing your files, gpg keys, etc. To tighten those loose ends, I can only redirect you toward the broad “hardening of qubes” topic; “qubes” here refers to individual qubes, not Qubes OS.
For instance, you could setup whitelisting of your files, redeploying some at each reboot…
Here are some links of interest (the second and third are not directly related, but are still nice to look at):
- GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup · GitHub (very nice)
- Acts at VM startup before private volume /rw mounts
- User: Protect /home desktop & shell startup executables
- Root: Quarantine all /rw configs & scripts, with whitelisting
- Organize configurations with named tags
- Deploy trusted custom files to /rw on each boot
- SHA256 hash checking against unwanted changes
- Provides rescue shell on error or request
- Works with template-based AppVMs, sys-net and sys-vpn
- My personal experience of attempt to harden qubes VM
- "Now You're Thinking with Qubes"