AI’s enormous potential and rapid evolution often place it on a pedestal, setting it apart from other forms of software. That mindset extends to security, and there is a common assumption that AI risks are somehow different from those associated with traditional applications.
Organisations deploying AI-native platforms look for AI-specific threats
in the form of novel attack classes. But while AI may be shifting paradigms and processes across industries, it is still just as vulnerable to common software flaws as a word processor or messaging app.
When our Unit 515 research team examined WeKnora, Tencent’s open-source LLM-powered document-understanding platform, they found exactly the same classes of failure that practitioners have dealt with for years.
The novel threat in AI security isn’t the flaws and exploits themselves, but how AI functionality has changed the path to exploitation, and the operational impact waiting at the other end.
Old bugs, new consequences
The perception that AI platforms carry a different class of risk isn’t hard to explain. These are technically complex systems, with a lot happening under the hood that many security teams don’t fully understand. That perceived complexity creates a tendency for security researchers to hunt for vulnerabilities that match it.
Yet as we’ve found, it’s the same fundamental security flaws at play. For example, delving into WeKnora, one of the most significant findings was CVE-2026-30860, which affected its AI database query capability. Natural-language requests are translated into SQL and executed against a connected PostgreSQL backend, and the validation logic designed to enforce a defensive boundary was incomplete enough to bypass.
The specific CVE is new, and its interaction with the AI system is interesting, but at its heart, the flaw is still just SQL injection, a tactic that has been around for decades.
Likewise, CVE-2026-30861 exposed a command injection vulnerability in MCP Studio configuration handling, and CVE-2026-30858 was DNS rebinding enabling SSRF. Both are well-understood problem classes appearing in a new context.
WeKnora is just one recent example, of course, and issues like these are common across AI solutions. They have different architectures and different threat models, but the same fundamental classes of failure.
How AI workflows change the stakes
If the vulnerability classes are familiar, why does it matter that they’re appearing in AI platforms? Because AI-driven workflows fundamentally change what those vulnerabilities are worth to an attacker.
Traditionally, reaching privileged backend systems required chaining vulnerabilities together manually – a time-consuming process that demanded skill and created opportunities for detection.
But AI-driven workflows shorten that distance considerably. The model can unintentionally become part of the orchestration layer, interacting with databases, APIs, tools, and automated actions in ways that collapse what was previously a multi-step attack into something far more direct.
Once AI platforms are connected to execution surfaces, attackers naturally shift towards manipulating workflows and model behaviour, not just infrastructure. That creates a much larger and more dynamic attack surface than most conventional applications present.
Looking back at WeKnora, CVE-2026-30856 illustrates this issue. In combination with indirect prompt injection, ambiguous naming in the MCP client can lead to tool-execution hijacking. Again, the vulnerability class is familiar, but now the exploitation path runs straight through the AI layer.
Finally, many people still think of LLMs as unpredictable chat systems and even treat that unpredictability as an informal safety net. But attackers can often make model behaviour far more reliable through careful prompt construction and workflow manipulation.
What defenders need to do differently
The answer isn’t a new security discipline; it’s applying the existing one properly.
My biggest advice is to avoid treating AI deployments as isolated experiments outside normal security practices. Start with strong identity controls, least-privilege access, segmentation, logging, and human approval around sensitive actions. Build visibility before enabling high levels of automation. AI platforms still need the same security engineering and testing rigour we expect from every other enterprise application, if not more.
Good practice around software bill of materials (SBOM) is another fundamental that needs to be strictly enforced for AI deployment. AI platforms have complex dependency chains, and most organisations don’tfully understand what they’ve introduced into their environments. There is typically a dense combination of models, plugins, orchestration frameworks, vector databases, APIs, containers, and open-source libraries.
A mature SBOM capability gives teams continuous visibility into what components exist, where vulnerabilities may have been introduced, and how exposure propagates across the platform before issues can be exploited. For the many organisations that have already deployed AI without that foundation, SBOM review is a natural starting point for remediation. This can then be built into vulnerability scanning, dynamic and static analysis, and third-party penetration testing to fully understand the threats and weaknesses at play.
AI security can’t afford to focus on novel threats
The question organisations should be asking isn’t whether their AI platform has AI-specific vulnerabilities, but whether they’ve applied the same rigour to that platform as they would to any other production system. For most security teams, the answer is probably no, because the perceived novelty of AI has created a blind spot where basic security discipline has been allowed to lapse.
Attackers aren’t waiting for AI-specific exploits. They’re walking through the same doors that have always been open, but they’re finding them faster, and the workflows on the other side are making the impact considerably harder to contain.
