CMS such as Typo3, Drupal, WordPress or Joomla work according to the same principle: All functions are programmed in a script language – for the four candidates mentioned, this is PHP. These PHP functions analyze the request sent by the user to the CMS web server via his web browser. From this, other PHP functions try to create a suitable answer in the form of an HTML document. To do this, PHP accesses the data in a database – the CMS mentioned are usually MySQL or MariaDB. Alternatively, other SQLite, PostgreSQL, OracleSQL or MS-SQL can also be used. Templates or instructions on the structure, appearance and content of individual websites lie dormant in the database. PHP combines all of this and creates an HTML document from it, which it transfers to the web server (Apache, Nginx, IIS etc.). This delivers the dynamically generated page to the browser.
Sounds unnecessarily complicated, especially for blogs and the like. In addition, the CMS are prone to errors and common vulnerabilities and exposures (CVE). At Drupal there have been a total of 200 CVEs since 2002, at Typo3 since 2005 193, and the popular WordPress has had a whopping 331 CVEs since 2004 – that’s around 20 on average documented security gaps per year (2019: 23, 2020: 21).
Attackers can, for example, smuggle in malicious code via security gaps, which is then delivered by the web server to its own readers and customers. In the worst case, the system and with it the entire server can be compromised and get into the hands of cyber criminals. They can then change, delete or even upload their own (illegal) content. As with any software, CMS also deliver automatic updates as a countermeasure. In doing so, however, they always run after the gaps due to their principle. There can only be a fix if a hole has been identified beforehand. If you take a closer look at the log files of your CMS, you will quickly find that there are already massive attacks on this vulnerability shortly before an update. The attacks are also automated and come from organized networks worldwide and script-controlled. It is almost impossible for the normal CMS operator to proactively defend themselves against these attacks. If you are not an experienced administrator yourself, you should rely on a service provider who hosts WordPress or one of the other CMS preinstalled. Here you can assume reasonably quick response times in the event of problems and do not have to be permanently on the lookout yourself. But of course that costs money.