- Yes, because a database by nature has far more attack-vectors as compared to a filesystem. There are more vulnerabilities, ways to pass malicious code, and heavier maintenance.
- There are roughly speaking (not checked against the core repo) 1-3 bugfix patches a month, a minor patch every 1-2 months, and a major patch every year or so. This is as expected with a live and developing CMS, but thankfully there are far fewer major or minor changes as compared with other CMS' - which tend to break functionality across the board.
- There have been no specific reports of hackers, to my knowledge, only of suspected system flaws. That said, no part of the Grav ecosystems' accessible interfaces have been stress-tested, at least to my knowledge.
- There are various measures which prevent the execution of code, but the main prohibitor is simplicity: The integrity of files are far easier to ensure than integrated systems, and apart from plugins which expose parts of the installation, the only way to altar the site is through access to the server or some yet unexposed exploit.
5 . As said, there might be, but none seem to have surfaced. Inherent to Grav's architecture there are very few ways to do so, because there are currently few ways to direct input into the system, nor is there an integrated API.
It is important to note that the best security against attacks is the work you do: Only deploy via secure channels (SFTP, Git), keep many backups (or just deploy from Git), do not install insecure extensions. The latter is mostly ensured by Grav, which reviews plugins submitted to the GPM (Grav Package Manager), but an additional layer of security would come from not installing the Admin-plugin directly on the site you are developing - but indirectly, so data flows securely to the site, but only content, not other settings.
There are various workflows which will greatly enhance security and integrity, outlined on these forums and in the docs, but anything beyond the basic Core + Admin installation requires that you weigh the added security against ease-of-use for clients. Some setups are heavier, and arguably far superior, but require more technical know-how from your part (not necessarily the client).