A Wild Week in Cybersecurity: Why Our EU AI Chat Stayed Safe From Recent Breaches

tl;dr: This third week of October 2026 brought an extraordinary wave of security incidents across the tech industry, but DentroChat and your data are safe.

If you follow security news, this week feels like a flood. While minor advisories come out often, having this many foundational tools and cloud platforms exploited in a few days is, I’ll say it, WILD.

In less than a week, we had so many incidents:

The eMudhra Certificate Authority incident: 8 intermediate CA certificates under eMudhra’s emSign root were found to have very weak private keys. Because those keys could be reverse-engineered to intercept HTTPS traffic, major browsers had to block the certificates, eMudhra announced today that it is exiting the global SSL/TLS certificate business altogether (!), and emergency updates had to be shipped for uv, pip, Node.js, Bun, Go, and Rust (!) to remove the compromised CA from their bundled trust stores.
Critical CVEs in core internet software: Two unauthenticated remote code execution flaws were patched in PHP (CVE-2026-109618 and CVE-2026-109619), alongside a critical buffer overflow in Google Brotli (CVE-2026-111497), a maximum-severity unauthenticated RCE in GitLab (CVE-2026-110264), and the Linux kernel “PwnEscape” vulnerability (CVE-2026-99999).
The LiteLLM supply-chain compromise: Yesterday, on October 21, attackers compromised LiteLLM’s release pipeline (again) and pushed a backdoored version (v1.107.0) to PyPI and Docker Hub. Because the malicious package included a startup hook that ran automatically whenever Python started, it immediately harvested cloud credentials and API keys from affected servers.
Railway and Zeabur platform breaches: Zeabur announced that it is shutting down permanently after a second breach exposed 3.2 million environment-variable records from 321,000 user accounts. Yesterday, Railway also said that an attacker accessed and decrypted customer environment variables. The target were interestingly AI inference keys.
Major enterprise breaches: Attackers gained access to Microsoft 365 customer tenants using stolen ConnectWise (SkyKick) backup credentials, and Capcom had a breach affecting 11.7 million user accounts.

Is this a “Cyberpocalypse”, or is the internet’s immune system waking up?

Why are so many old bugs found at the same time in regular expression compilers, compression decoders, memory allocators, and cryptographic setups?

The answer is mostly that AI is now reading the world’s code. Security researchers and defenders (and attackers) are letting AI review the code of open-source libraries. The result is that many edge cases are found that human reviewers missed for 15 years. Even the weak eMudhra CA keys were apparently spotted with the help of AI.

Some commentators have called this week a “Cyberpocalypse.” However, our perspective is that the internet’s immune system is finally waking up and healing itself. Most of these bugs were already in production code for years, and discovering them means they finally get fixed.

Given that I wrote my bachelor’s thesis at TU Graz on the trust model and structural risks of Certificate Authorities all those years ago, watching the eMudhra situation cascade into uv, pip, Node.js, and Bun reminds me of why I chose it back then. On the internet, trust comes in many forms and is a highly complex system.

Where DentroChat stands on this week’s incidents

If you use DentroChat for your daily work and confidential documents, your conversations and files were not affected by any of these incidents. Because we keep our architecture lean, most of the affected software is not part of our stack, and we immediately patched what we use:

The uv, pip, Node.js, and Bun CA trust issue: Because command-line tools and runtimes bundle their own list of trusted Certificate Authorities, any tool that trusts the compromised eMudhra root cert had to be updated. DentroChat does not use uv or pip on its servers at all. However, our web application runs on Bun, so we updated our production containers to Bun 1.4.4 (alongside patched Debian system certificates), which completely removes the compromised eMudhra root.
LiteLLM (v1.107.0 malware): While we do route AI requests through a European inference gateway (Cortecs), we do not use the Python LiteLLM library or its Docker images anywhere in our stack.
Railway, Zeabur, and cloud deployment platforms: We do not host on multi-tenant developer PaaS wrappers like Railway or Zeabur, nor do we store customer data on US hyperscalers or Microsoft cloud tenants. As documented on our Subprocessors page, we manage our deployments using our own self-hosted Coolify instance which runs directly on our European servers. Therefore, no external PaaS vendor holds our environment variables or deployment secrets.
PHP, GitLab, and application dependencies: We do not run PHP or self-hosted GitLab. Furthermore, we audited and updated our entire application dependency tree across both our chat platform and website, and currently stand at zero known vulnerabilities.

How we architect DentroChat to keep your data safe

Because AI-assisted code auditing will continue to uncover new CVEs in open-source software, third-party packages will never be “bug-free”. Therefore, we designed DentroChat with strict isolation so that a flaw in one component can’t compromise your data or our servers.

1. Code execution in a network-free WebAssembly sandbox

This year, a viral security report showed that OpenAI agents broke out of their sandbox in an internal evaluation. That breakout was possible because the agents were running inside a Linux container that still had network access to an internal package-registry proxy, and the agent exploited a zero-day bug in that proxy to reach the internet.

With DentroChat, that attack path does not exist (as of now), because we do not run user code inside a Linux container with a shell or a package installer. Instead, when you upload a spreadsheet or ask DentroChat to run Python analysis, the code runs inside an isolated WebAssembly (WASM) sandbox:

Every supported Python library for data analysis and document creation is pre-bundled at build time, so nothing is ever fetched from PyPI or an internal package proxy at runtime.
Before any Python is run, all outbound network APIs, dynamic library loaders, and host filesystem bridges are severed and deleted from the runtime.
Even if a Python library ever contained a supply-chain backdoor like LiteLLM’s startup script, the WebAssembly sandbox has no network connection to send data out and no access to server environment variables or other users’ files. Once your chart or document is returned, the temporary workspace is wiped clean again.

2. A 7-day cooldown against supply-chain attacks

The LiteLLM attack worked because:

the malicious package version is published via PyPi
automated build pipelines around the world immediately installed it
after 2 hours security researchers figured out something is wrong
by this time, the malicious code could already exploit many systems

To prevent this so called “supply chain attack”, our package manager enforces a strict 7-day minimum release age alongside frozen lockfiles. A newly published open-source package version must survive a full week of public scrutiny before our build pipeline allows it to be installed. Unless of course we manually audit and pin a specific security patch such as today’s runtime update…

3. Why we block internal network access when the AI visits websites

When you ask DentroChat to read a webpage or fetch a public dataset from an open-data API, our server fetches that URL on your behalf. Without strict network boundaries, a malicious website could hide instructions on the page that trick the AI into requesting internal server addresses (such as 127.0.0.1 or internal Docker network ports) instead of a public website. That technique, so called Server-Side Request Forgery (SSRF), could expose internal services running on the server itself.

Therefore, our outbound network fetcher resolves DNS before connecting, blocks all private, loopback, and internal IP ranges, and pins the verified IP address on every redirect hop. Even if a webpage tries to trick the model or uses DNS rebinding to switch a domain’s IP address to 127.0.0.1 at the last millisecond, the connection is refused before it touches our internal network.

4. Self-managed encryption at rest on Hetzner in Europe

All DentroChat application servers, databases, and self-hosted tools run on Hetzner in Germany, while encrypted backups and pseudonymised server logs are stored at Scaleway in France, all under EU jurisdiction and outside of the US CLOUD Act. You can inspect our full infrastructure setup at any time on our Subprocessors page.

All data is protected with encryption in transit and encryption at rest. Technical detail that often gets overlooked: most servers at hosting providers (also Hetzner) do not encrypt your disks at rest at all. That’s why we configure and manage encryption at rest ourselves. This secure infrastructure setup pairs well with our general privacy controls:

Zero training on your conversations or files
Automatic chat deletion you control
Discreet Chat mode when you want a conversation excluded from AI memory

Staying vigilant

Good security is never finished.

Especially now because both researchers and attackers can find zero-day vulnerabilities with AI faster than ever before. While we are thankful that our architecture kept DentroChat completely protected from this week’s wave of incidents, we are staying vigilant.

We are actively evaluating how we can further shorten our response time for future zero-day exploits, harden our server boundaries, and keep your data safe no matter how crazy the next week in cybersecurity will be. Thank you for being part of DentroChat!