Security updates for a self-built AI stack: what is involved

Which layers need security updates?

Layer	Examples	What to bear in mind
Operating system	Linux distribution	distribution updates, plan reboots
GPU drivers	the vendor’s drivers and compute libraries	versions must match the model software
Containers and orchestration	Docker, Kubernetes	their own security advisories, rebuild images
Model software	vLLM, Ollama and similar	frequent releases, interface often without its own sign-in
Interface	Open WebUI, LibreChat and similar	rapid release cycle, vulnerabilities in people’s browsers
Databases and search	PostgreSQL, search index	updates with data migration, back up first
Libraries	Python packages and their dependencies	often hundreds, manageable only with tools
Model files	models from public repositories	check origin, prefer formats without executable code

The layers depend on one another. An update to the model software may require a newer driver, a new driver a new operating system. That is why every update includes a test of how everything works together.

How often are there critical vulnerabilities in AI software?

More often than you would expect from young projects. Three examples from public sources:

• Ollama: in 2024, Wiz Research found a vulnerability (CVE-2024-37032) through which attackers could overwrite files on the server and thus execute code; fixed from version 0.1.34. Wiz pointed out that the Ollama interface has no sign-in by default.
• vLLM: in 2025, several vulnerabilities were published, including ones rated critical in features for running across several servers (such as CVE-2025-32444) and one in which program code was loaded from an external repository even though this was switched off (CVE-2025-66448).
• Open WebUI: in 2025, several vulnerabilities were fixed through which injected code could run in people’s browsers.

Cisco Talos showed in September 2025 how many installations are reachable without protection: a search found over 1,100 Ollama servers that could be reached from the internet without sign-in. This is not an argument against these projects; they usually fix vulnerabilities quickly. It shows that the operator also has to apply the updates.

What does a process for security updates look like?

1. Know your inventory: a list of all parts with their versions, ideally as a software bill of materials (SBOM), generated automatically.
2. Follow advisories: subscribe to the security advisories of the projects on GitHub, the distribution and the GPU vendor; tools match the inventory against known vulnerabilities (CVE).
3. Assess: is the affected feature active and reachable in your setup? How severe is the vulnerability?
4. Test: apply the update in a test environment, check sign-in, answers and connections.
5. Apply: in the maintenance window or, for critical vulnerabilities, immediately, with a backup beforehand.
6. Be able to roll back: if an update fails, the previous state must be restorable.
7. Document: what was applied and when, for audit and auditors.

The BSI (German Federal Office for Information Security) describes requirements for this process in the IT-Grundschutz module OPS.1.1.3 Patch and change management. NIS2 explicitly counts vulnerability handling among the obligations of entities in scope (Art. 21(2)(e)).

What helps in addition to updates?

• Nothing exposed to the network: model interfaces reachable only internally, access only via the interface with sign-in.
• Few features: switch off what is not needed, for example running across several servers or external connections in the interface.
• Fixed versions: no automatic updates from the internet in production, but vetted, pinned versions.
• Responsibility with cover: patch management is an ongoing task. See bus factor.

How does this work with basebox?

Updates and security patches are included in the licence. Every release goes through checks of its dependencies for known vulnerabilities (CVE) and a static code analysis; if there is a known vulnerability, the release fails. Every release comes with a software bill of materials (SBOM) and release notes, and you are informed by email. In the cloud, basebox applies updates, urgent security updates also outside the maintenance window. On the server, nothing installs itself automatically: without an operations contract, you apply updates and check urgent security updates without delay, without an internet connection as an offline package via your internal repository. On request, we operate your server remotely. The images are not yet signed; signing is in preparation. Until then, image digests prove that they are unchanged.

Note: Examples of vulnerabilities according to the sources cited, as of 11 October 2026. Current advisories can be found on the projects’ pages.