Blog

What two weeks of attacks mean for enterprise AI

AI found decade-old bugs, attackers stole AI keys, and agents acted on their own. What it means for enterprise AI security, and what to ask your AI vendor.

In the last two weeks, AI found decade-old bugs in software much of the internet runs on, attackers went after AI provider keys, and AI agents did things nobody asked them to. Each one changes what you should expect from any AI vendor, including us.

Here is what happened, what it means, and where we stand.

AI found the bugs

Two of the most serious flaws this month were found with AI, not by attackers.

PHP2Shell. Two critical flaws in the core of PHP (CVE-2026-109618 and CVE-2026-109619) let an attacker run commands on any unpatched server. A researcher found them with an OpenAI model. Word leaked before the fix shipped on Oct 21, and attackers were already trying it.
Brotli. OpenAI’s own agents found a memory bug in Brotli, a compression library inside Node.js, Envoy and Python (CVE-2026-111497). A crafted compressed file could crash a service or run code on it. Node.js shipped fixes on Oct 21.

The PHP bug sat unnoticed for over a decade. AI found it in weeks, and attackers had it before most teams could patch. A patch cycle measured in weeks no longer fits.

Where we stand: the Leena AI platform does not use PHP.

The trust layer cracked

On Oct 17, a researcher found that eMudhra, a certificate authority, had generated eight intermediate keys so weakly they could be rebuilt from public certificates. Anyone holding them could issue a trusted HTTPS certificate for any website. Chrome blocked the keys and removes eMudhra’s emSign root from its trust store on Oct 27.

Few companies ask which certificate authority their vendors depend on. This is why it matters: one weak key breaks the padlock for everyone who trusts it.

Where we stand: none of our certificates chain to eMudhra, and our services no longer trust the affected root.

AI keys became the target

Attackers went after the keys that let software call AI models.

LiteLLM, a popular open-source proxy for AI models, had its release pipeline hijacked on Oct 21. For about two hours, the official package and Docker images carried malware that stole credentials every time Python started.
Railway, a cloud hosting platform, said attackers accessed customer environment variables and were after AI inference keys. Zeabur and OpenCode Console disclosed similar exposures of stored secrets and provider keys.

A stolen AI key gets resold or used to run models on someone else’s bill. A poisoned release reaches anyone who installs the latest version during the window.

Where we stand: every dependency and container image we run is pinned to an exact version, so nothing pulls a new release on its own. A poisoned release can’t reach production unless we choose it. None of our AI provider keys sit on the platforms that were breached.

Agents acted on their own

Some of the month’s incidents had no attacker at all.

OpenAI reported that GPT-6 agents switched off safety monitoring during routine internal work, and one then told its user it hadn’t.
India’s CERT-In warned that AI agents under test used leaked keys and broad cloud permissions to read confidential records.
In a UK AI Security Institute test with safeguards switched off, a Claude Mythos 5 agent sent a malicious pull request to a real GitHub project. It was rejected.

The lesson for anyone deploying agents: an agent can reach whatever its permissions allow, whatever it was asked to do. The control is the permission, not the prompt.

How we bound our agents: each request is tied to the employee who signed in through your identity provider. An agent can use only the actions your administrators turn on, and each integration runs under an account you create in your own system, with the role you choose. Form-based actions wait for the employee to confirm, and any process can require an approval before it changes a record. Each run stops after a fixed number of steps. The platform records every step in Run History, including who started the run, and your admins can export it. Any action or process can be switched off.

What to ask your AI vendor

Can you list every runtime and library in production today, and how fast would you know if one is hit?
How long does a critical fix take to reach production?
Do your builds pin exact versions, or pull the latest release?
Where do your AI provider keys live, and what can each one reach?
What can your agents do without a human approving it, and is every action logged?
Do your sub-processors meet the same bar?

How we’ll tell you

If a vulnerability or incident affects our platform or your data, we’ll tell you directly. We won’t publish a statement for every vulnerability that doesn’t touch us. Questions in the meantime: your account manager or security@leena.ai.