A steady stream of new security vulnerabilities – what does this mean for Vertec?

One (for me at least) somewhat unexpected side effect of the AI revolution is that by 2026, security vulnerabilities are appearing at ever shorter intervals. This is especially true in open source products, which for many years were assumed to be more secure due to the wide availability of the source code. Now we are realizing that this may well be true, but AI systems can also systematically scan the source code for vulnerabilities. As long as these are companies like OpenAI or Anthropic that handle the findings responsibly, this is desirable and good – but the attackers can access the same means to devise attack scenarios for vulnerabilities they find.

What does this mean for Vertec?

A look at the current support cases shows that in the last ten days alone we were confronted with three serious security vulnerabilities (PHP, Google Brotli, Linux Kernel), which also affect presumably very secure systems (Linux) and vendors (Google).

Our approach is always the same:

1. We learn about new vulnerabilities from online media. Heise Security is one of the first places to look in German-speaking countries, but you also quickly learn about serious security vulnerabilities on LinkedIn.
2. We immediately analyze the possible impact on the Vertec software and the infrastructure we operate. The overview of our “information security assets” that we have through the ISO 27001 certification helps us with this. For example, it is obvious that the Vertec standard software does not rely on PHP, but what about surrounding software, partly produced and operated by third parties? It turned out that the Vertec Forum, which is built on software from Woltlab, actually relies on PHP. The vendor promptly patched their software as soon as the patch was available.
3. If a component that we are using is affected (such as the current severe vulnerability in the Linux kernel, CVE-2026-98432), we assess the possible impacts and discuss measures. From the available information, it can be concluded that, firstly, there are no ongoing attacks and, secondly, an attack scenario requires a setting that we have not set (MPTCP). Because this is very unlikely to be exploited, we have refrained from taking dramatic measures, such as shutting down all cloud services. Something that, by the way, was done by many during the “PHP crisis” on October 21, 2026.
4. The implementation. Of course, this depends heavily on the affected system and whether it is our own or third-party software. In the case of our own software, detected vulnerabilities are fixed with a next minor release. In the case of the current Linux bug, we wait for a patch for our Ubuntu distribution and install it as soon as possible.

We regularly have our own software tested externally and then process the findings. We do this especially for all new features with an external exposure (2026 these were e.g. Python 3, the new web services, and the OAuth login for the MCP server). We work closely with the company avantguard. Two years ago, their CEO, Jann Lemm, spoke at the Vertec User Conference.