TL;DR:CVE-2026-75650, dubbed StyleSmuggler, is a critical vulnerability affecting Adobe Commerce and Magento Open Source. The vulnerability allows an unauthenticated attacker to inject malicious PHP code into Magento’s template system and achieve remote code execution. Adobe assigned the vulnerability a CVSS score of 10.0 and released an emergency hotfix after exploitation was observed in the wild. Imperva Cloud WAF and On-Prem WAF customers are protected against exploitation attempts associated with CVE-2026-75650.
Understanding the StyleSmuggler Vulnerability
StyleSmuggler is an improper neutralization vulnerability in Magento’s template engine. Attackers can abuse the processing of styles properties to smuggle malicious PHP code past existing safeguards and into content that Magento later renders.
The attack occurs in two stages. First, the attacker sends a crafted request that causes malicious PHP code to be stored within Magento-generated content, such as a failure report. The attacker then triggers application functionality that renders the poisoned content, including Magento’s standard failed-payment email process. When the template is rendered, the injected PHP executes on the server.
No authentication or user interaction is required. The recipient does not need to open the failed-payment email, and the attack can succeed even if the email is never delivered. Successful exploitation gives the attacker arbitrary code execution in the context of the Magento application, potentially enabling malware deployment, persistent access, credential theft, payment-data compromise, or further movement within the environment. The vulnerability affects supported versions across multiple Adobe Commerce and Magento Open Source branches, including systems that had received recent security patches.
Observed post-exploitation activity has included the deployment of persistent Linux backdoors disguised as legitimate processes such as kworker, fc-cache, and chronyd. Researchers have also identified a separate campaign using the vulnerability to install a PHP web shell, demonstrating that multiple threat actors are already attempting to operationalize StyleSmuggler.
What Imperva Has Seen So Far
Imperva has observed exploitation activity targeting websites across 15 countries, indicating that StyleSmuggler scanning and attack attempts are already geographically widespread. The United States accounts for 25% of targeted sites, followed by Mexico at 15.9%, Spain at 14%, and Singapore at 13.6%.
Retail websites represent the largest share of observed targets at 39.5%, consistent with Magento’s extensive use across ecommerce environments. Lifestyle sites account for another 19.5% of targets, followed by healthcare at 17.9%.
Attack traffic has primarily automated attacks. While client identifiers can be modified or spoofed, their prevalence is consistent with attackers using scripted tools to automate scanning and exploitation rather than interacting through conventional web browsers.
Imperva protections are actively identifying and blocking malicious requests associated with the StyleSmuggler attack chain before they can reach protected applications.
Conclusion
CVE-2026-75650 poses an immediate risk: it enables unauthenticated remote code execution, has already been weaponized, and can give attackers direct control over ecommerce servers. Adobe Commerce and Magento Open Source administrators should apply the VULN-39341 hotfix immediately and investigate potentially exposed systems for signs of compromise. As exploitation began before a patch was available, applying the hotfix does not remove malware or persistence mechanisms that may already be present.
Imperva Cloud WAF and On-Prem WAF customers are protected against exploitation attempts associated with StyleSmuggler. Imperva will continue monitoring the campaign as attackers refine their payloads and additional activity emerges.
Somewhere in your estate right now, a certificate is counting down to its expiry date. Today you probably know which one, because renewals still come around annually and someone owns the calendar. The industry is taking that comfort away: the CA/Browser Forum has voted to cut the maximum TLS certificate lifespan to 47 days by 2029, a decision we looked at in detail in our piece on shortened renewal periods. Renewals that happen once a year will soon happen every few weeks, and every manual touchpoint in that process becomes a potential outage. The math stops working.
The honest complication is that most enterprises do not live in a single-vendor world. You may run your own internal PKI. You may have standardized on a dedicated Certificate Lifecycle Management (CLM) platform. You may answer to compliance mandates that dictate exactly which Certificate Authority issues your certificates, and how. In those environments, visibility and control across every certificate matters as much as automating the renewals themselves. Until now, connecting those established workflows to Imperva meant manual effort, and manual effort is exactly what shrinking lifecycles no longer allow.
Today we are introducing the SSL Integration Center: an integration framework connecting Imperva Cloud WAF with leading Certificate Lifecycle Management platforms. It launches with its first supported integration, the DigiCert Trust Lifecycle Manager (TLM) Agent.
Your CLM stays in charge for certificate lifecycle management
The SSL Integration Center is not a new product or another console to learn. It is an integration framework, and the experience runs from the side you already live in: you configure the integration from within your CLM platform, and your CLM remains the place where certificates are managed. Once connected, two things happen from there. You can see all of your Imperva-managed domains and the SSL coverage status of each one, directly in your certificate workflow. And the complete certificate lifecycle cadence, issuance, renewal and deployment to Imperva, runs automatically under the policies your CLM already enforces. Imperva’s role is to integrate smoothly into the workflow you have, supplying application and SSL-coverage visibility and taking automated deployment off your hands. DigiCert is the first integration, and it sets the pattern for the CLM vendors that follow.
Thales-managed or customer-managed: your choice
Many organizations choose Thales-managed certificates because that removes the operational load of provisioning, renewal, monitoring and deployment in one move, and for them nothing changes. Others cannot adopt a fully managed approach: compliance requirements, PKI investments, established CLM platforms and governance policies often require a customer to keep control of their own certificate ecosystem. The Integration Center is built for that second group. You keep your CA, your CLM and your lifecycle processes, exactly where they run today, and Imperva plugs into them. Governance stays yours, and so does the console.
Starting with a leader: DigiCert Trust Lifecycle Manager
DigiCert TLM gives enterprises one place to discover, govern, automate and see certificates across cloud, hybrid and on-premises environments. It builds an organization-wide certificate inventory, enforces consistent cryptographic policy, and replaces surprise expirations with automated renewals. A useful way to think about the pairing: TLM is the system of record for your certificates, and the Integration Center is the delivery route into the applications Imperva protects.
With this integration, the DigiCert TLM Agent automates certificate issuance, renewal and deployment straight into Imperva. Under the hood, a post-enrollment script securely uploads the certificate chain and private key to Imperva through the Provisioning API, so a certificate governed in TLM arrives at your protected applications without anyone touching it. It runs on both Linux and Windows.
The value of that automation is documented. In a commissioned Total Economic Impact study, Forrester Consulting found organizations standardizing on DigiCert ONE, the platform behind Trust Lifecycle Manager, achieved 96% fewer outages from expired or misconfigured certificates, and a 312% return on investment over three years.
Source: The Total Economic Impact of DigiCert ONE (July 2025), a commissioned study conducted by Forrester Consulting on behalf of DigiCert. Results are based on a composite organization derived from customer interviews. Forrester does not endorse DigiCert or its offerings.
How the DigiCert TLM integration works
Govern in DigiCert TLM. Your certificate is issued and managed centrally, under the policies your organization already enforces.
Automate with the TLM Agent. A post-enrollment script runs on issuance or renewal and packages the certificate chain and private key.
Deploy through the Provisioning API. The script securely uploads the certificate to your Imperva cloud account and puts it to work protecting your applications. No manual upload. No missed renewal window.
What this means for your team
Continuous, compliant TLS protection. Issuance, renewal and deployment of custom certificates run without manual intervention, so your encryption stays current as lifecycles shrink.
Full bring-your-own-CA automation. If you use your own Certificate Authority and custom certificates, the entire lifecycle can now run end to end.
Fewer outages, less toil. Removing the manual steps removes the TLS outages that come from missed renewals, and frees your team from certificate babysitting.
Your Imperva estate, visible from your CLM. Once connected, your Imperva-managed domains and the SSL coverage status of each appear inside your certificate workflow, so DigiCert’s organisation-wide discovery and Imperva’s application coverage read as one picture, without switching consoles.
A certificate automation ecosystem that grows with you
Shorter certificate lifecycles are the new baseline, and they reward the organizations that automate. The SSL Integration Center makes that automation work on your terms: the CA you trust, the CLM platform you have standardized on, the compliance posture you are held to. It sits alongside Thales’s own SSL management capabilities, including certificate visibility, site coverage monitoring, notifications and real-time SSL health monitoring. DigiCert Trust Lifecycle Manager is the first integration and it will not be the last; each CLM vendor added becomes one more certificate workflow that arrives at your applications without a human in the renewal loop.
That certificate counting down in your estate? Under TLM and the Integration Center, its renewal has already happened by the time you would have thought to check.
It is also one thread in a wider fabric. Imperva integrates across the tools enterprises already run, from SIEM and ITSM platforms to API gateways, scanners and cloud providers, through the Imperva Technology Alliance Program. If your certificate stack is the workflow we meet today, the rest of your stack has a meeting point there too.
When the OWASP Top 10 for LLM Applications arrived, it did the industry a real service. It gave security teams a stable, vendor-neutral vocabulary for a threat surface that was moving too fast to describe. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling, unbounded consumption: five of those ten account for the bulk of what actually shows up in red-team exercises and public incidents.
Every framework earns its keep by naming what defenders are already fighting. Which is exactly why the next part matters: the next lists are not coming. They have already arrived. Most security programs simply have not caught up with them yet.
The three OWASP lists that now define AI security
Three published OWASP lists now cover the AI stack end to end. Together they are the checklist most security programs are not yet resourced against:
OWASP Top 10 for LLM Applications (2025) – the conversation layer. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption are the five that dominate real incidents.
OWASP Top 10 for Agentic Applications (2026) – the systems that act. Released 9 December 2025 by the OWASP GenAI Security Project. Ten risks, prefixed ASI, covering what happens when AI stops answering and starts doing.
OWASP MCP Top 10 (MCP01:2025-MCP10:2025) – the connective tissue. Currently in beta (Phase 3, beta release and pilot testing), covering the Model Context Protocol layer that wires assistants to real systems and data.
The OWASP agentic and MCP Top 10 lists are published. The budgets are not.
In December 2025, the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications (2026), covering the risks that appear when AI stops answering questions and starts taking actions: agent goal hijack (ASI01), tool misuse and exploitation (ASI02), identity and privilege abuse (ASI03), memory and context poisoning (ASI06), insecure inter-agent communication (ASI07) and rogue agents (ASI10).
Alongside it, OWASP’s MCP Top 10 project is codifying the risks of the Model Context Protocol, the standard that connects AI assistants to real systems and data. It is a young list, currently in beta – Phase 3, beta release and pilot testing, with entries carrying the MCP01:2025 through MCP10:2025 designation – and it is already one of the most useful documents in AI security, because it names the attack patterns defenders are meeting right now. Three of them deserve particular attention.
Command injection and execution (MCP05). An AI agent executes system commands built from untrusted input, without proper validation. An adversary who compromises the toolchain gets their work carried forward by the agent itself, with the agent’s legitimate permissions. The prompt was never touched. The model behaved exactly as designed. The compromise came in through the tools.
Tool poisoning (MCP03). The model is handed a list of tools it may call, and it trusts their definitions and their outputs. Poison either one and you have redirected the application’s behavior without a single suspicious token appearing in the conversation.
Insufficient authentication and authorization (MCP07). MCP servers, tools, and agents interacting without properly verifying identity or enforcing access controls. Who is allowed to call this tool? Which agent may delegate to which? In most environments today the answer is: whoever asks. That is not a vulnerability in a model. It is a missing identity layer for machines.
One more entry is worth a mention because it will sound familiar to anyone tracking shadow IT: shadow MCP servers (MCP09), the unapproved deployments running outside security governance, often on default credentials. The shadow AI problem now has an OWASP number. For the practical exposures behind these entries, see MCP Server Security: The Blind Spot in Your AI Stack.
None of these are theoretical. All of them get easier as organizations wire agents into more systems. And none of them have the household-name status that prompt injection now enjoys, which means the frameworks are ahead of most security programs’ resourcing. That is a new and uncomfortable position: the industry usually waits years for its threat lists. This time the lists arrived before the budgets.
History does not repeat, but it files tickets
We have watched this movie before. Monolithic applications got the OWASP Top 10. API-based applications got the API Security Top 10, because the attacks changed shape when the architecture did. AI applications and agents are the next architecture, and this time the pattern completed itself faster than ever: the LLM Top 10 for the conversation layer, the Agentic Top 10 for the systems that act, and the MCP Top 10 for the connective tissue between them.
So the catch-up question for security teams is no longer “what threats might emerge?” It is “which published OWASP entries is my program actually resourced against?” And the question for vendors sharpens the same way. Not “do you block prompt injection?” but “walk me through the MCP Top 10 and tell me what you see, and what you can control, beyond the prompt.”
The LLM Top 10 taught the industry to take AI threats seriously. The warm-up worked. The event has already started.
Frequently asked questions about the OWASP AI Top 10 lists
What is the OWASP LLM Top 10? The OWASP Top 10 for Large Language Model Applications is a vendor-neutral list of the ten most critical security risks in LLM-based applications, maintained by the OWASP GenAI Security Project. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption account for most of what shows up in red-team exercises and public incidents.
Is there an OWASP Top 10 for AI agents? Yes. The OWASP Top 10 for Agentic Applications (2026) was released on 9 December 2025. Its ten entries carry the ASI prefix and run from agent goal hijack (ASI01) to rogue agents (ASI10).
What is the OWASP MCP Top 10? A list codifying the security risks of the Model Context Protocol, the standard connecting AI assistants to real systems and data. Entries run MCP01:2025 to MCP10:2025 and include tool poisoning (MCP03), command injection and execution (MCP05), insufficient authentication and authorization (MCP07) and shadow MCP servers (MCP09). The project is in beta.
How many of the OWASP LLM Top 10 does Imperva address? Five out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption.
What should I ask an AI security vendor? Not “do you block prompt injection?” but “walk me through the MCP Top 10 and tell me what you see, and what you can control, beyond the prompt.”
Thales’s Imperva AI Application Security addresses five of the OWASP LLM Top 10 out of the box. We believe the industry’s next frameworks will be written about agents and toolchains. Thales announced the AI Security Fabric in December 2025, with an MCP security gateway and runtime access control for agentic AI interactions on the 2026 roadmap. Our white paper, Beyond the LLM Top 10, maps that terrain.
Every year, the security industry publishes benchmark reports built more or less the same way: pick a handful of common vulnerabilities, measure how often they show up, publish the percentages, and move on. We just finished our second year running one of those reports — and the most important thing we found wasn’t a percentage. It was a pattern hiding underneath all of them.
This is Imperva API Security’s 2026 Token & Authentication Risk Report: a year-over-year look at how organizations actually handle JSON Web Tokens (JWTs), Basic Authentication, and token lifecycles, based on real detection data — not survey answers — across 1,104 customer environments and 32,725 live API endpoints. Some of what we found is good news. Some of them should genuinely worry you. And one finding, buried in a few layers beneath the headline numbers, is the reason we think most organizations are fixing the wrong things first.
What We Measured, and Why It’s Worth Trusting
This is the second year of this benchmark, which matters more than it might seem. One year of data tells you what’s happening. Two years of consistent measurement tells you what’s changing — and change is where the real signal lives.
We tracked five risk categories, unchanged from last year’s methodology: whether JWTs contain sensitive data they shouldn’t, whether they’re signed with weak algorithms, whether they’re issued with excessively long lifespans, whether Basic Authentication with raw credentials is still in use, and whether tokens keep granting access after they should have expired. Every number below is a share of real detections, not a projection.
This post covers the headline findings. The full 2026 Token & Authentication Risk Report includes the complete year-over-year breakdown across all five categories, the reasoning behind each shift, and specific, practical recommendations for where security and engineering teams should focus first.
Get the Full Report
If there’s one thing worth taking from this report, it’s this: the next time your team finds one authentication issue on an endpoint, the right instinct isn’t relief that you caught it. It’s to ask what else is sitting there next to it — because in nearly 40% of the cases we looked at, the answer was something.
We think that’s the real story in this year’s data. The industry has gotten reasonably good at fixing the authentication problems that are legible — the ones a checklist can catch, the ones a single well-publicized recommendation can meaningfully move. It hasn’t gotten meaningfully better at the problems that require understanding how a system was actually built, which is exactly the category the two worsening risks, and the clustering pattern connecting them, fall into. A scanner can tell you a token is signed with a weak algorithm. It’s much worse at telling you that the same token is also carrying a customer’s date of birth.
“Did we pick a strong signing algorithm” is a yes-or-no question a scanner can answer in seconds. “What data did we decide to put inside this token, and did anyone revisit that decision when a new field got added eighteen months later” is not. “Are we still using Basic Auth” shows up on nearly every audit checklist in the industry. “Does every service that validates this token independently re-check its expiration or does one of them just trust the gateway” usually doesn’t, because answering it requires understanding how a system actually behaves, not just which protocol it uses.
Here’s the uncomfortable pattern sitting underneath all of the numbers above: the risks that improved this year are the ones that are easy to check. The risks that got worse are the ones that are hard to check. That’s not a coincidence — it’s a fairly accurate description of how security improvement actually happens inside most organizations.
What This Means for How We Approach Authentication
That’s the pattern that should reframe how this whole report gets read. If these risks were scattered at random, an endpoint like that would be a statistical fluke. Instead, the pattern repeats across nearly 40% of everything we measured. That’s not scattered. That’s systemic — and it means the standard response to finding one authentication issue, patching it and closing the ticket, is very likely leaving a second or third issue sitting untouched on the exact same endpoint.
At the extreme end, it’s worse than pairing. The single riskiest endpoint we found carried all five risk types at once: sensitive data in the token, a weak signing algorithm, an excessively long lifetime, Basic Authentication, and continued access after expiry. Endpoints like that usually aren’t the result of five separate, unrelated mistakes. More often, they’re a single legacy or lightly-used endpoint that never got touched when the rest of the environment moved to better practices — quietly running on old assumptions while everything around it improved.
Picture what that looks like in practice. An endpoint that embeds sensitive data inside its tokens — a risk present in essentially half of all detections — sitting on the same endpoint as an expired-token gap that lets access continue indefinitely, a risk that grew 70% this year. We can’t say how often that exact pairing occurs; our data tells us endpoints carry multiple risks, not which specific risks pair together most often. But it’s exactly the kind of compounding scenario nearly 40% of endpoints are positioned for — a token that doesn’t just leak once, but keeps leaking, because nothing in the system ever cuts it off.
We went endpoint by endpoint and asked a specific question — how often do these five risks appear together, on the same API, at the same time? The answer: 13,016 of the 32,725 endpoints we analyzed, nearly 40%, carried more than one authentication risk simultaneously. Not an edge case. Not occasional. Roughly two out of every five.
Here’s what we didn’t expect going in: authentication risk doesn’t usually show up alone.
The Finding That Changes the Story
We can’t say with certainty why either number moved the way it did — a mix of factors is plausible, including genuine changes in practice, improvements in our own detection, and shifts in which organizations were measured each year. What we can say is that the direction, for both, is the wrong one, two years running.
Expired-token access jumped from 5.0% to 8.5% — a 70% relative increase, the sharpest move of any category we track, in either direction. This one is arguably more alarming precisely because it’s the more mechanical risk to get right. Deciding what counts as “sensitive” involves judgment. Enforcing that a token stops working after its exp claim has passed does not. When it fails anyway, it’s usually because expiration was checked in one place — a central auth service — and never independently re-verified everywhere else the token gets used. Every other assumption a security team makes about tokens rests on expiration being the backstop. When that backstop doesn’t hold, everything built on top of it gets quietly weaker too.
Sensitive data inside tokens climbed to 49.8% of all detections, up from 46.0% last year — already the largest risk category in the study, now touching essentially half of everything we measured. That number deserves more alarm than it might get on first read: a JWT isn’t encrypted by default. It’s typically just base64-encoded, which is not the same thing — anyone who can see the token can read what’s inside it; no exploit required. A JWT doesn’t need to be “hacked” to leak data. It just needs to pass through an ordinary place in a modern stack: a log line capturing request headers, browser storage on a shared machine, a support ticket where a developer pastes a request for debugging. If the token carries a name, an email, an account number, every one of those mundane, everyday paths becomes a potential exposure event.
The two risk categories that got worse this year aren’t the ones with a tidy, well-known fix. They live in implementation details, and, not coincidentally, they’re the two with the most direct line to actual data exposure.
That’s a genuine win worth taking seriously. It’s also, as it turns out, the easy part.
These three have something in common: each map to a specific, well-publicized fix. Use a stronger algorithm. Migrate to OAuth2 or mTLS. Shorten your token lifetimes. None of that is a secret, and the data suggests teams that heard the advice actually acted on it.
Three of the five risks have improved. Weak signing algorithms dropped from 19.0% to 15.2% of detections — a 20% relative decline, the sharpest improvement in the study. Basic Authentication with raw credentials fell from 9.0% to 7.3%. Long-lived tokens eased slightly, from 21.0% to 19.2%.
Imperva Red Team uncovered CVE-2026-17106, a container-to-host arbitrary file-write vulnerability in Docker’s docker cp command. Docker later confirmed that the same CVE also affected sbx cp when copying files out of Docker Sandboxes. A malicious container or sandbox could exploit the copy process to create or overwrite files outside the destination selected by the user, potentially enabling code execution on the machine running the Docker CLI.
Through CVE-2026-17106, an attacker-controlled container could turn a routine file copy into two powerful outcomes:
Host file overwrite: creating or replacing any file writable by the user running docker cp, including shell configuration, executables, SSH configuration, source code, and persistence mechanisms.
Code execution: Executing attacker-controlled code as the logged-in user on macOS or, when docker cp runs with elevated privileges on Linux, achieving root code execution immediately after the command completes by overwriting the runc binary.
The exploit chains two weaknesses in Docker’s archive pipeline: a filesystem race that lets a running container produce an inconsistent tar archive, and an extraction flaw that allows the Docker CLI to follow a planted symlink outside the intended destination.
Together, these weaknesses turn the user’s own Docker CLI into a write primitive. The attacker controls the container and its files, the CLI supplies access to the host filesystem.
The docker cp command is routinely used to retrieve build artifacts, test results, logs, and forensic evidence from containers. This makes the vulnerability particularly relevant to CI systems, developer workstations, privileged automation, and incident-response workflows. In the last case, simply collecting evidence from a compromised container could activate the payload waiting inside it.
The impact also reaches AI-agent workflows. Docker Sandboxes uses sbx cp to move files between an isolated agent environment and the host. Docker Sandboxes 0.38.0, released August 6, identifies and fixes a “destination-escape flaw in sbx cp copy-out” under CVE-2026-17106. This means retrieving an artifact produced inside an untrusted or compromised coding-agent sandbox could expose the host to the same class of destination escape.
From a Simple Copy to a Host Write
The command that started this research could hardly look more ordinary:
docker cp container:/path/to/file.txt ./file.txt
The source is inside the container. The destination is chosen by the user. The expected security boundary seems obvious: Docker should write to ./file.txt and nowhere else.
But docker cp is not a direct filesystem-to-filesystem copy.
When copying from a container, the Docker daemon walks the container’s live filesystem and turns the selected path into a tar archive. The Docker CLI receives that archive and extracts it on the client machine.
This architecture creates a powerful connection between two security domains. The container controls the archive contents, while the local CLI performs the resulting filesystem operations with the permissions of the person or process that invoked docker cp.
For this design to remain safe, Docker needs to preserve two properties:
The daemon must produce a coherent archive from the container’s filesystem.
The CLI must confine every extracted object to the destination selected by the user.
We found a way to break both properties in the same copy operation.
Impact
The vulnerability provides an arbitrary file create or overwrite primitive within the permissions of the Docker CLI process.
The malicious container does not automatically inherit root privileges from dockerd, and exploitation requires a user or automated system to invoke docker cp against the attacker-controlled path.
But the final write occurs on the machine running the CLI, with the authority of that user-not with the permissions of the process inside the container.
We validated the exploit on Linux with Docker Engine 29.6.1 and on macOS with Docker Desktop 4.81.0 (232925).
Developer Compromise on macOS
Docker Desktop runs the daemon inside a Linux virtual machine, but a container-to-local docker cp operation is extracted by the CLI running on macOS.
This means the archive crosses the VM boundary before the vulnerable operation occurs. The symlink is followed by a process on the Mac, and its target is interpreted in the Mac’s filesystem namespace.
A malicious container could therefore target files such as shell startup scripts, user-level executables, SSH configuration, source trees, cloud configuration, or persistence mechanisms under ~/Library/LaunchAgents. Overwriting a shell startup file could execute the attacker’s code the next time the user opens a terminal.
The container does not need to escape the Docker Desktop VM directly. It convinces the local CLI to perform the write on its behalf.
Root Code Execution on Linux
On Linux, the daemon and CLI commonly run on the same host. The write still carries the CLI user’s permissions.
For an ordinary user, the attacker can reach files writable by that account. If an administrator, CI worker, or maintenance process invokes sudo docker cp, the operation can reach root-owned system paths.
In our proof of concept, we replaced /usr/bin/runc with a shell script. A later Docker lifecycle operation executed the replaced binary and created a marker file as root.
The exploit did not obtain root from the Docker daemon. The copy already had enough authority to replace runc, and the later execution converted that file write into root code execution.
The Archive That Described Two Filesystems
The first part of the chain was in the archive producer.
Both the Moby and Docker CLI source trees we reviewed used github.com/moby/go-archive v0.2.0. For a container-to-local copy, Moby’s containerArchivePath creates a tarballer and runs it inside the container filesystem:
Docker locks the container object while the archive is read, but that lock protects Docker’s internal state. It does not freeze processes running inside the container.
Those processes can continue renaming files, replacing directories, and creating symlinks while the daemon walks the source tree.
The tarballer performs that walk with filepath.WalkDir:
The same pathname now answers two different questions at two different times:
Traversal decision: is this entry a directory that WalkDir should enter?
Archive metadata: is this entry a file, directory, or symlink that should be written to the tar stream?
If the path changes between those observations, the two answers no longer need to agree.
Turning the Race into a Reliable Primitive
In our proof of concept, /watched/file.txt is intentionally deceptive. An LD_PRELOAD interposer makes it appear to be a regular file to processes inside the container by redirecting exact accesses to a hidden backing file, /watched/.file.txt.regular. The Docker daemon, however, sees the underlying file.txt path as a directory and can walk the attacker-controlled tree beneath it.
The walker initially sees the following directory:
After WalkDir records escape as a directory, the attacker moves it aside and replaces it with a staged symlink:
The switch requires only two rename operations, winning a filesystem race blindly would be unreliable, so we gave the container a clock.
Our proof of concept places a large file immediately before the pivot directory and monitors it with filesystem notifications. When the daemon opens that file, the attacker knows the walk has reached the right location. The large file widens the timing window, and the notification signals when to perform the two renames.
What begins as a race becomes a repeatable sequence.
After the switch, addTarFile sees a symlink and emits a symlink header for file.txt/escape. Control then returns to WalkDir, whose earlier directory entry still says that escape is a directory. The walker descends through the same pathname and adds a child beneath the symlink’s archive name.
The resulting tar stream contains two entries:
Each entry is understandable on its own. Together, they describe two different moments in the source filesystem: escape is represented as a symlink, while its child is represented as though escape were still a directory.
At this point, the container has produced an inconsistent archive. That alone should not be enough to write outside the destination. The client still controls extraction and can reject the dangerous sequence.
It did not.
The Extractor Checked One Path and Created Another
For a copy from a container, the Docker CLI eventually reaches archive.CopyTo:
The validation and the filesystem operation use different values.
The containment check validates targetPath, a path constructed with filepath.Join. The subsequent os.Symlink call receives the original hdr.Linkname from the archive.
For an extraction path of /safe/output/file.txt/escape and a link target of /usr/bin, the validation evaluates:
That constructed path appears to remain under /safe/output, so the check approves it. Docker then gives the original absolute target to the kernel:
The check approves one path. The filesystem creates another.
The same condition has an additional weakness: string prefixes do not represent path containment. A path such as /safe/output-elsewhere also begins with /safe/output. Our chain already had what it needed from the checked-value-versus-used-value mismatch.
The extractor then processes the child entry, file.txt/escape/runc.
Docker cleans the archive name, joins it to the destination, and checks for a lexical ../ escape, but the child entry contains no ../. As text, it remains beneath the destination.
The previous tar entry has changed what the pathname means on disk. Before creating the child, the vulnerable extractor does not re-establish confinement against the resolved target:
When the file is created, the kernel follows escape -> /usr/bin. The attacker’s bytes land at /usr/bin/runc on the Docker client rather than under /safe/output.
The full chain is:
WalkDir records escape as a directory.
The container replaces it with an absolute symlink.
addTarFile emits the symlink into the tar stream.
WalkDir descends using its earlier directory type and emits a child entry.
The CLI validates a constructed target but creates the original absolute symlink.
The CLI extracts the child through that symlink and writes outside the destination.
One stale directory entry and one ineffective containment check were enough to turn docker cp into a host write.
From Host Write to Host Compromise
At this point, the copy operation is no longer confined to the destination chosen by the user. The attacker-controlled container has gained a write primitive on the Docker client, with the permissions of the process running docker cp.
What happens next depends on those permissions. A copy launched by a developer could target user-writable startup files, shell configuration, source code, or persistence mechanisms. If the command runs as root, as is common in automation and some Linux environments, the same primitive could reach system executables and privileged configuration, turning the file write into root code execution.
The vulnerability simply prepares the malicious filesystem and waits. The trigger may be a developer retrieving a build artifact, a CI job collecting test results, or an incident responder copying evidence from a container they already suspect is compromised.
In each case, the operation intended to take data safely out of the container becomes the step that carries the attack back onto the host.
Mitigations
Users should upgrade to Docker Engine and CLI 29.7.2 or later, and Docker Desktop 4.86.0 or later.
Where upgrading is not immediately possible:
Avoid copying from running, untrusted, or compromised containers onto a sensitive client.
Stop the container before copying. Docker supports copying from a stopped container, preventing a live process from performing the race used in this chain.
Avoid sudo docker cp and root-run copy automation.
Run the Docker CLI with the least privilege required for the workflow.
Retrieve data from suspicious containers using a disposable account, VM, or similarly isolated environment.
Stopping the container blocks the producer race demonstrated here. It does not replace safe extraction: any archive originating from an untrusted source should still be treated as hostile input.
Conclusion
Container boundaries are not defined only by namespaces, virtual machines, or the Docker daemon. They also depend on the client-side tools that move data across those boundaries.
docker cp connects a live, attacker-controlled filesystem to an extractor running with the user’s authority. That design requires both sides of the pipeline to preserve a strict contract: the archive must be coherent, and every extracted object must remain inside the destination.
CVE-2026-17106 broke that contract. The daemon observed one pathname as two different objects, producing a symlink followed by its apparent child. The CLI then validated one path, created another, and allowed the child entry to cross onto the client filesystem.
The most important lesson is simple: archive extraction is a security boundary. Path normalization and string-prefix checks cannot enforce that boundary once symlinks and concurrent filesystem changes are involved. Filesystem operations must be rooted so that the kernel, not a string comparison, guarantees where the write can land.
We responsibly disclosed the vulnerability to Docker and delayed publication several times to align disclosure with a usable patch. We would like to thank Docker’s security and engineering teams for investigating the report, coordinating the CVE, and working through the regressions introduced by the initial fix.
Responsible Disclosure Timeline
April 11, 2026 – We reported the vulnerability to Docker with technical details and reproduction information.
April 14, 2026 – Docker acknowledged receipt and began reviewing the report.
April 15, 2026 – Docker confirmed the behavior as a valid finding and explained its assessment of the client-side privilege boundary.
July 10, 2026 – The initial 90-day disclosure period elapsed without a public patch. We requested a concrete remediation, advisory, and publication schedule.
July 14, 2026 – Docker described two remediation tracks: extraction-library hardening as the primary security fix and source-walk hardening as follow-up work. We agreed to delay publication while the fixes were prepared.
July 27, 2026 – Docker confirmed that the source-walk TOCTOU would not receive a separate CVE and would instead be addressed as defense-in-depth hardening.
July 30, 2026 – moby/go-archive v0.3.0 and Docker Engine/CLI 29.7.0 shipped the extraction fix.
July 31, 2026 – Docker reported significant functional regressions caused by the initial hardening and requested a final extension to August 10. Follow-up go-archive and Engine releases addressed the regressions.
August 1, 2026 – We agreed to extend coordinated disclosure to August 10.
August 6, 2026 – Docker Sandboxes 0.38.0 shipped a fix for a destination-escape flaw in sbx cp copy-out under CVE-2026-17106. Docker also confirmed that the Docker Desktop update remained scheduled for August 10.
August 10, 2026 – Docker releasedDocker Desktop 4.86.0, bundling Docker Engine 29.7.2 and delivering the corresponding Docker Desktop fix.
TL;DR: CVE-2026-64638, dubbed XSS2Shell, is a high-severity WordPress Core vulnerability that begins as a pre-authentication reflected XSS on the login screen and can be chained to PHP code execution when a logged-in administrator is successfully targeted. WordPress fixed the issue in 7.0.3 and backported the fix through maintained branches. Imperva Cloud WAF and On-Prem WAF customers are protected against this vulnerability.
On August 6, 2026, WordPress released version 7.0.3 with security fixes that include a pre-authentication reflected cross-site scripting vulnerability on the login screen with the potential to lead to PHP code execution. The issue is tracked as CVE-2026-64638 and is rated High severity with a CVSS score of 8.9.
About XSS2Shell
The vulnerability starts on the WordPress login page. When a login attempt uses an invalid username, WordPress includes that value in an error message returned to the browser. The security researchers found that the value is processed by multiple HTML sanitization components that do not interpret certain malformed markup in exactly the same way.
That parser disagreement can allow attacker-controlled HTML elements to survive the first sanitization step and later become active elements in the browser. On its own, this is not yet JavaScript execution, but the researchers showed how the injected elements can interact with JavaScript that WordPress already loads on the login page.
The result is reflected XSS in the security context of the affected WordPress site, without the attacker first needing a WordPress account.
From Reflected XSS to Server Compromise
The significance of XSS2Shell comes from the way several otherwise legitimate browser and WordPress features can be chained together. The researchers demonstrated that the XSS primitive can be used to trigger same-origin requests and interact with WordPress REST functionality. Against a logged-in administrator, the chain can then reach privileged WordPress capabilities and ultimately lead to PHP code execution on the server.
At a high level, the chain is: unauthenticated malicious input -> reflected XSS on the WordPress login page -> JavaScript execution in the WordPress origin -> abuse of a logged-in administrator session -> privileged WordPress actions -> PHP code execution.
An important distinction is that CVE-2026-64638 should not be described as a zero-interaction unauthenticated RCE. The official WordPress advisory states that escalation to RCE requires successful social engineering and explicit interaction by the target victim. In practice, the full chain targets a user who is already authenticated with sufficient WordPress privileges.
Why This Vulnerability Matters
It is in WordPress Core. The vulnerable behavior is part of WordPress itself rather than a third-party plugin or theme. No attacker account is required for the initial XSS. The vulnerability is reachable pre-authentication from the login screen. It demonstrates the risk of exploit chaining. What begins as a parsing inconsistency becomes significantly more serious when combined with browser behavior, WordPress JavaScript, REST functionality, and administrator capabilities. The potential impact is high. If the complete chain succeeds, an attacker can reach server-side PHP code execution, affecting confidentiality, integrity, and availability.
Affected WordPress Versions and Patch
WordPress states that the issue affects all versions of WordPress. Version 7.0.3 contains the fix, and WordPress has backported the security change through branches eligible for security fixes, currently down to the 4.7 branch. The corresponding patched releases include 6.9.6, 6.8.7, 6.7.6 and equivalent maintenance releases for older supported branches.
WordPress recommends that sites update immediately. Sites that support automatic background updates will begin receiving the security release automatically, but administrators should verify that the update completed successfully.
How Imperva Protects Customers
Imperva’s AI-powered security engine is designed to help protect customers against the next generation of AI-assisted attacks.
Rather than relying solely on known payloads or static signatures, Imperva uses strict protocol validation, behavioral analysis, anomaly detection, and continuous threat intelligence to detect and mitigate zero-day attacks and previously unseen malicious traffic patterns. This layered approach enables Imperva to respond rapidly when attackers or AI-driven research tools uncover novel techniques or new emerging threats, helping ensure customers remain protected even as zero-day discovery and exploitation become increasingly automated and fast-moving.
Imperva has since observed widespread activity targeting more than 11,000 distinct websites across 67 countries. Hundred thousands of requests were already recorded indicating broad, highly automated targeting rather than isolated attempts against a small number of organizations. More than 95% of the tools associated with this activity were written in Go, while over 75% of targeted websites were in the United States. Gaming was the most frequently targeted industry, accounting for 32% of observed sites, followed by education at 26% and financial services at 24%.
Recommended Actions
Update WordPress immediately. Sites on the 7.0 branch should update to WordPress 7.0.3 or later. Organizations on older maintained branches should install the corresponding patched maintenance release.
Verify automatic security updates. Do not assume the patch was applied successfully; confirm the running WordPress version on production systems.
Keep Imperva protections current. Cloud WAF customers receive managed security-rule updates. On-Prem WAF customers should maintain current product and security-content updates in accordance with Imperva guidance.
Review privileged accounts and credentials. Investigate unexpected administrator changes, application credentials, plugin installations, or other privileged actions on systems that remained vulnerable after disclosure.
Reduce administrator exposure to untrusted content. The full RCE chain requires interaction by a target victim, so administrators should avoid opening untrusted links while authenticated to sensitive WordPress environments.
AI-Assisted Vulnerability Discovery
XSS2Shell is also notable because of how the complete chain was developed. The security researchers state that they’ve used open-source AI models and a multi-agent research workflow, starting from earlier Same Origin Method Execution (SOME) research, and that the system took nearly four days to build the full chain.
The finding illustrates how AI-assisted security research can connect subtle behaviors across multiple layers of a complex application. For defenders, it reinforces the value of layered controls that can stop an exploit chain at more than one stage instead of relying only on a vulnerability-specific patch.
Bottom Line
CVE-2026-64638, or XSS2Shell, shows how a subtle parsing inconsistency in a widely deployed platform can become far more serious when chained with legitimate browser and application functionality. WordPress has released fixes, and administrators should patch immediately.
Imperva Cloud WAF and On-Prem WAF customers are protected against exploitation attempts associated with CVE-2026-64638. Existing XSS and application-security protections block the malicious input used to initiate the attack chain, and Imperva has further fortified mitigation after reviewing the newly disclosed techniques.
You cannot verify a vendor’s security claims from their own datasheet, including ours. That is why independent validation matters. In our recent guide to the best WAAP solutions (Best WAAP Solutions 2026: Enterprise Buyer Guide), we argued that every serious shortlist should include independent third-party testing across both web and API threats. SecureIQ Lab’s Cloud WAAP v5.0 CyberRisk Validation, published this week, delivers exactly that: twelve leading cloud WAAP platforms, 1,608 attack scenarios, and 1,487 false-positive traps, all run under identical, adversarial conditions, with every vendor’s results published in full.
This blog is the follow up to that buyer guide and explains what the new report says and how to read any benchmark.
Balancing security efficacy and false positives
A high security-efficacy score, on its own, is easy. Tune any WAF aggressively enough and it will stop every attack, along with a meaningful share of your customers. That is the trap: security efficacy and false positives pull against each other, and false positives are never a rounding error.
Every legitimate transaction blocked is lost revenue, an abandoned cart, a support ticket, a SOC triage, another tuning cycle, and operational cost on top of the license. At scale, teams respond to false-positive pain by loosening policies or dropping rules into detect-only mode. The efficacy number you thought you were buying quietly disappears in production.
The genuinely hard engineering problem, the one that determines your real protection and your real total cost of ownership, is holding maximum efficacy and near-zero false positives at the same time.
That is the equation to grade this report on. Imperva WAF and API Security was placed in the Leader category with a perfect 100% Complete Security Score, the only perfect score of the twelve vendors, across every tested category: all OWASP web test cases, all ten OWASP API categories on all five protocols, every bot, AI-assisted bot, and Layer 7 DoS scenario, every evasion vector, and the full vulnerability assessment.
Against 1,452 legitimate-transaction test cases mixed into live traffic, Imperva achieved that balance of maximum efficacy and zero false positives. No other vendor in the field held a perfect score on both sides of the equation. This evaluation validated protection you do not have to trade away to keep your customers moving.
API security matters: Imperva scored 20% above average
Most vendors now score well on classic web attacks. The OWASP WAF group average was 89.96%, and five vendors scored 99.5% or better. APIs are a different story. Across the OWASP API Security Top 10, tested over five protocols, published scores ranged from 45.5% to 100%, around a group average of 80.3%.
Imperva scored 100% on every API category and every protocol tested, including WebSockets, where the twelve-vendor group averaged just 48%. If your evaluation shortlist is driven by web-attack demos, the API results are where you should spend more time. That was one of the main recommendations in the WAAP buyer guide, and the new numbers reinforce it.
New in 5.0: AI security and compliance
The 5.0 methodology adds AI application security: 35 attack scenarios aligned with OWASP LLM01 (Prompt Injection) and LLM05 (Improper Output Handling), scored independently of the headline results. Here is the honest reading: nine of the twelve vendors, Imperva included, scored 100% on that attack set. Runtime LLM attack-blocking is already table stakes.
Where the field separates is operating AI protection at enterprise scale. SecureIQ Lab’s GenAI & LLM Operational Efficiency rating looks at the ability to deploy, govern, and observe AI protections in production. Scores ranged from 0% to 100%, around a 73% group average. Imperva was one of five vendors rated 100%.
The second new dimension is compliance. SecureIQ Lab ran a five-layer assessment across regulatory, data-protection, audit, governance, and AI frameworks (NIST, ISO/IEC 27001 and 42001, PCI DSS, GDPR, HIPAA, and more). Imperva’s 87% was the highest score of all twelve vendors, against a 63.95% group average, including 100% on the AI security layer.
If your security purchases have to survive an audit committee, which is true for most enterprises, this is the part of the report to share with your GRC team.
In summary:
100% OWASP LLM score: Imperva blocked all tested LLM01 and LLM05 attack scenarios.
Zero LLM false positives: legitimate AI interactions in the LLM test set were not blocked.
100% GenAI & LLM Operational Efficiency: Imperva scored 100% versus a 73% group average.
Operational readiness matters: the rating reflects capabilities such as vulnerability coverage, sensitive data protection, full-stack LLM observability, SDK-based guardrail integration, and system-prompt-based context guardrails.
AI protection cannot stop at attack blocking. As organizations bring LLM-backed applications into production, they also need visibility, guardrails, integration, and governance that teams can operate day to day.
Imperva’s AI results show both sides of that equation: tested protection against key LLM threats and validated operational readiness to help enterprises adopt AI more securely and manageably.
WAAP Operational Efficiency in Real Life
Operational efficiency determines how practical a WAAP will be for real-world application teams.
In the SecureIQ Lab Cloud WAAP 5.0 validation, Imperva achieved a 98.8% WAAP Operational Efficiency rating, outperforming the 94.1% group average while also delivering perfect security efficacy and 100% false positive avoidance.
That combination matters because modern security teams are not only judged by whether they stop attacks, but by whether they can do so without slowing deployments, creating unnecessary tuning work, or interrupting legitimate business traffic.
The nine operational security categories tested were:
Ease of deployment
Ease of management
Ease of risk management
Logging & auditing capabilities
Visibility & analytics
Support & documentation
API Gateway efficiency
Integration capabilities
Geolocation based security features
Imperva scored 98.8% against a 94.1% group average, with perfect scores in every category except API Gateway Efficiency (94.4%), where JWT validation has been identified as an improvement opportunity.
The operational results show strength across the day-to-day capabilities that determine whether a WAAP can be run confidently at an enterprise scale.
Imperva was rated 100% in ease of deployment, ease of management, ease of risk management, logging and auditing, visibility and analytics, support and documentation, integration capabilities, and geolocation-based security features.
These categories translate directly into practitioner outcomes: faster setup, simpler policy reuse, stronger role and user management, clearer threat analytics, easier SIEM and SOAR integration, more flexible logging, and better tools for reducing false-positive risk.
The only operational category below 100% was API Gateway Efficiency, where Imperva scored 94.4% against a roughly 95% group average, with JWT validation identified as an area for improvement.
The takeaway for buyers: operational efficiency is not a secondary metric. A WAAP that is difficult to deploy, difficult to tune, or noisy in production becomes an operational burden even if its detection rates look strong.
Imperva’s results show that protection can be both highly effective and highly manageable — giving security, application, and platform teams independent validation that they can strengthen defenses without adding unnecessary friction to the business.
In summary: Four rules for reading any WAAP benchmark
Read efficacy and false positives as one result, not two separate ones. A perfect block rate with a high false-positive rate does not deliver security. That combination is an outage generator with a dashboard, and its real-world efficacy will be tuned away within a quarter.
Go to the API results before the web results. Web scores tend to cluster near the top across the industry; API scores are where architecture differences show up.
Check which deployment model was tested. A SaaS cloud service and a self-managed virtual appliance are different operational propositions; the report calls out the model for each vendor.
Ask every shortlisted vendor for their current published results, and for the categories where they did not lead. A vendor who cannot name one has not read their own report or needs to check their points.
If you are still shaping a shortlist or building evaluation criteria, go back to the earlier Best WAAP solutions blog, Best WAAP Solutions 2026: Enterprise Buyer Guide. It is a practical playbook for what to look for in WAAP architecture, operations, and economics. SecureIQ Lab’s Cloud WAAP 5.0 results now give you independently validated numbers to plug into that playbook.
There is a moment every CISO is having right now, often without warning. A developer shows a working internal demo of an AI assistant trained on the company’s own documents. The product team is already planning a customer-facing version. The board has signed off on the budget. And somewhere in the middle of the meeting, a quiet question lands: what is securing this?
The honest answer, for most organizations today, is “nothing your existing stack was designed to do.”
This is not a critique of the security tools enterprises have spent years deploying. WAFs, EDRs, network firewalls, API gateways, identity platforms; these have evolved into a layered defense that genuinely works against the threats they were built for. But GenAI applications introduce a new attack surface that operates outside the boundary every one of those tools defends.
The problem is not that AI threats are more dangerous than traditional threats. The problem is that they are categorically different.
What is generative AI security?
Generative AI security is the practice of protecting LLM- and GenAI-powered applications at the AI interaction layer: the prompts going in, the model responses coming out, the conversation context in between, and the data and tools the model can reach. It is distinct from traditional application security because the attack payload is natural language, not a malformed request.
Why the old security playbook doesn’t cover generative AI?
Traditional security tools all share a common assumption: attacks come in the form of malformed inputs, malicious payloads, suspicious traffic patterns, or unauthorized access attempts. A WAF inspects HTTP headers, query strings, and request bodies for known patterns. An EDR watches for binaries behaving badly. An API gateway enforces schema and authentication.
An LLM-based application turns all of those assumptions on their head.
The payload in a prompt injection attack is grammatically correct English. The malicious code in a data leakage attack is a polite question. The denial of service pattern in an unbounded consumption attack is a perfectly legitimate looking conversation. The threats that matter to a GenAI application live at the level of the model’s logic, not at the level of the network or the HTTP request.
Even more critically, the security tools that protect the application surrounding the model have no visibility into what happens at the interface. The WAF sees the request to your AI endpoint. It does not see what the model does with that request. The API gateway authenticates the user. It does not understand whether the user is trying to convince the model to reveal its system prompt.
This is the gap that has emerged across enterprise security architectures over the last 18 months. It is not a minor blind spot. It is a category-level gap. Traditional security tools do not speak AI.
What AI-native security actually means?
When we talk about AI-native security at Imperva, we are not talking about adding AI features to a traditional security product. We are talking about a purpose-built control plane that understands prompts, model responses, conversation context, and usage patterns the way our WAF understands HTTP.
That distinction matters because AI security has to inspect the interaction itself. It has to understand what the user is asking for, how the model is likely to respond, whether sensitive data is being exposed, whether instructions are being manipulated, and whether usage patterns suggest abuse. This is inspection at the AI interaction layer rather than the network layer.
Thales’s Imperva AI Application Security is engineered specifically for the architecture of AI and agentic applications. It sits between your applications and the models they call, giving teams flexible deployment options rather than forcing a single architecture. Every input and every output is analyzed in real time, against multiple security guardrails, with adaptive risk scoring that distinguishes legitimate use from manipulation attempts.
Sensitive information disclosure through model outputs
System prompt leakage
Improper output handling
Unbounded consumption attacks that drive cost runaway and denial of service
And critically, it does not replace your existing WAAP. It extends it. AI Application Security plugs into the same unified Imperva platform that handles your WAF, API security, bot management, and DDoS protection. The same console, the same policy model, the same role-based access controls
The AI threat surface becomes one more dimension of the security posture your team already manages, rather than a new tool, a new vendor, and a new operational silo.
What generative AI security means for the next 12 months?
According to McKinsey’s State of AI survey (November 2025), 88% of organizations now use AI in at least one business function, up from 78% a year earlier. And in the 2026 Thales Data Threat Report, 61% of organizations named AI as their top data security risk, while the share carrying a dedicated AI security budget rose from 20% to 30%. As organizations move from simple chat experiences toward autonomous agents capable of taking actions, the need for AI-specific security controls becomes even more critical. The teams that get this right will not be the ones who deploy more security tools. They will be the ones who recognize that AI applications are a new class of asset and treat them with a control layer designed for what they actually are.
A WAF was the answer when applications moved from desktop to web. An API gateway was the answer when monoliths gave way to microservices. An AI Application Security layer is the answer for applications that no longer execute only predictable code, but interpret, generate, and increasingly act on language.
That is the new kind of security your AI deserves.
Frequently asked questions about generative AI security
What is the difference between AI security and generative AI security?
AI security is the broad category, covering everything from model theft to training-data poisoning. Generative AI security is the runtime subset: protecting live LLM and agentic applications from prompt injection, sensitive data disclosure, system prompt leakage, improper output handling and unbounded consumption.
Can a WAF stop prompt injection?
No. A WAF inspects HTTP headers, query strings and request bodies for known malicious patterns. A prompt injection payload is grammatically valid English inside a legitimate request, so it passes every WAF check. Stopping it requires inspection at the AI interaction layer, which is what an AI application security layer adds alongside the WAF.
Do I need to replace my existing security stack to secure AI?
No. AI application security extends the stack rather than replacing it. Imperva AI Application Security plugs into the same platform as the WAF, API security, bot management and DDoS protection, using the same console, policy model and role-based access controls.
Which OWASP LLM Top 10 risks does Imperva AI Application Security address?
Five of the ten out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling, and unbounded consumption.
Is generative AI security different for AI agents?
Yes. Agents take actions rather than only returning text, so a successful manipulation becomes an operational incident rather than a bad answer. See the companion post on agentic AI security below.
AI agents are rapidly becoming part of everyday development. They operate inside terminals, IDEs, and internal workflows, helping users write code, troubleshoot problems, and automate repetitive tasks. But their capabilities can extend far beyond what users see in the chat interface or terminal output. Agents may read files, execute commands, launch subprocesses, access credentials, call external tools, and transmit data to large language model providers.
The conversation that the user sees may therefore represent only a small part of what the agent is actually doing. Many of its actions take place quietly in the background, without being clearly presented to the user or the security team.
This creates a significant visibility challenge for security teams. Organizations may not know which AI-powered applications are active on developer machines, what those applications are doing, or whether their behavior aligns with company policies.
An agent does not need to be malicious to create risk. While trying to complete a task, it may interpret instructions too broadly and access information the user did not intend to expose or perform actions that extend beyond the original request.
The Endpoint Visibility Gap
Traditional endpoint security controls may capture individual parts of an agent’s activity without revealing their significance. An IDE or terminal process accessing a sensitive file, such as an .env file, may appear to be routine development activity. But if the process is controlled by an AI agent that has already communicated with an LLM provider, the same event has a very different security meaning. The developer may not have chosen to open the file at all. The agent may have accessed it autonomously while trying to complete a task.
Without connecting these events to the agent responsible for them, security teams may interpret autonomous agent behavior as ordinary user activity. This challenge is amplified by the fact that AI capabilities are not limited to a fixed set of recognizable applications. Traditional security controls can often map, classify, or restrict known software, but almost any Python script, IDE extension, command-line tool, or internal application can gain agentic capabilities by connecting to an LLM and acting on its responses. This makes application-based detection difficult. Blocking the underlying application or interpreter is usually not practical because the same software is also used for legitimate work.
As a result, application-based allowlists and blocklists cannot provide sufficient visibility or control on their own.
The real challenge is therefore not just detecting a process, file access event, command execution, or network connection. It’s determining whether that activity was initiated by the developer or autonomously by an AI agent.
From AI Discovery to Behavioral Understanding
Identifying an AI-enabled process is only the first step. Security teams must also understand how its behavior develops throughout the session.
After receiving instructions or model output, an agent may create child processes, execute shell commands, inspect local files, access sensitive directories, or initiate additional network connections. The sequence of these actions can reveal how the agent interpreted its task and whether its behavior moved beyond what the user expected.
This behavioral context becomes especially important during an investigation. A single command, file access event, or outbound connection may appear legitimate when viewed alone. When these events are connected chronologically, however, they may reveal a very different story: the agent encountered new input, changed its behavior, accessed a sensitive resource, and then attempted to communicate with an external destination.
The goal is not only to identify that an AI agent was active, but to reconstruct its activity and understand the relationship between the agent, its subprocesses, the resources it accessed, and the destinations it contacted.
Introducing ShadowAI-Watch
This is why we created ShadowAI-Watch, an open-source runtime discovery and behavioral monitoring tool for AI-powered applications and agents.
ShadowAI-Watch runs independently on the user’s machine and does not require changes to the monitored application. It provides a host-level view of AI agent activity by correlating processes with outbound LLM connections and tracing the actions that follow.
The tool is designed to identify custom AI agents, coding agents, browser agents, LLM-powered applications, and locally hosted models, including applications that may not have an obvious AI-related process name.
ShadowAI-Watch supports multiple privilege levels, ranging from a low-privileged user to full administrative access. With limited privileges, it inspects process information available through /proc to discover agentic applications. With elevated privileges, it enables its full eBPF-based monitoring mechanism, providing deeper and more precise visibility into process and system activity.
ShadowAI-Watch Workflow
ShadowAI-Watch runs locally on the user’s machine and continuously monitors outbound network activity across running processes. When a process connects to a known large language model provider, the tool identifies it as AI-related and traces the process tree to determine which application initiated the connection.
It then continues observing the session and correlates subsequent commands, child processes, file access, and network activity with the identified application.
Together, these events create a chronological record of the agent’s runtime activity and the sequence that led to each action.
These events are written to a JSON Lines audit file and displayed live in the terminal using color-coded output. The audit data can also be sent to a remote dashboard for visualization and risk analysis. This gives security teams both immediate visibility while the agent is operating and a structured audit trail that can be examined after the session.
The released repository includes the components responsible for generating logs and structured audit records. Organizations can use this data to build their own dashboards, monitoring workflows, or integrations based on their specific requirements.
ShadowAI-Watch workflow
Watching a Browser Agent Get Hijacked
The demo begins with a simple request: summarize a website by opening a URL and following the links it contains.
To the user, this looks like an ordinary browsing task. The BrowserUse agent opens the site, moves between pages, and gathers the information it needs. In the background, ShadowAI-Watch discovers the agent, identifies it as BrowserUse, and begins tracing its activity in real time.
At first, everything proceeds as expected.
Then the agent reaches a page containing an instruction that did not come from the user. It was placed there by an attacker and attempts to convince the agent to open an external URL and transmit session data to an attacker-controlled endpoint.
The agent follows the instruction.
From the developer’s perspective, the agent still appears to be navigating the website as requested. The malicious request is hidden within the normal browsing flow and could easily go unnoticed.
ShadowAI-Watch sees a different story.
It sees the agent reach the page containing the indirect prompt injection. It then observes the agent’s behavior change and detects its attempt to connect to a destination unrelated to the original task. Instead of treating the request as isolated browser traffic, ShadowAI-Watch links it to the active BrowserUse session and to the attacker-controlled content that preceded it.
What appeared to be routine browsing is revealed as an agent hijacking sequence: a legitimate task, exposure to a malicious instruction, a change in behavior, and an attempted transmission of sensitive data.
The video below shows that sequence unfolding in real time, from the discovery of the BrowserUse agent to the detection of the malicious outbound connection.
See ShadowAI-Watch at DEF CON 34
Our team will present ShadowAI-Watch in the AppSec Village Arsenal at DEF CON 34 during the session, “The Agent Asked. We Allowed. Now What?”
ShadowAI-Watch is available as an open-source project for Linux, with macOSsupport coming soon. Access the repository and learn how to get started here:https://github.com/ThalesGroup/shadowai-watch
TL;DR: Recent Portswigger research introduced novel HTTP desync techniques discovered through an AI-assisted research system called the HTTP Terminator. The findings expand the range of unusual HTTP behaviors that can cause front-end and back-end systems to interpret the same traffic differently. Imperva Cloud WAF and On-Prem WAF customers are protected against practical attack patterns described in the research. Imperva’s existing security engine already blocked malicious and ambiguous requests associated with desync attacks, and Imperva has further fortified the mitigation after reviewing the new techniques.
Understanding HTTP Desync Attacks
Modern web applications rarely receive requests directly from users. Traffic commonly passes through several components, such as a CDN, load balancer, reverse proxy, or WAF, before reaching the application server.
An HTTP desync vulnerability occurs when two of these components disagree about where one request ends and the next begins. A front-end system may treat a sequence of data as one complete request, while the back-end interprets part of the same data as the beginning of another request. This parsing difference can allow an attacker to smuggle traffic past front-end security controls.
Depending on the affected architecture, successful exploitation can lead to security-control bypasses, cache poisoning, access to restricted functionality, or response queue poisoning. In a response queue poisoning attack, a response intended for one user may be delivered to another, potentially exposing sensitive information.
HTTP/1.1 is particularly exposed to this class of problem because request boundaries can be represented in multiple ways, and products do not always handle malformed or unusual combinations consistently.
What’s HTTP Terminator?
The HTTP Terminator is an autonomous research system designed to generate, evaluate, and refine potential protocol attacks. Using small fragments of protocol specifications as inspiration, it generated about 30,000 unique desync vectors in testing and evaluated them against websites where testing was authorized through vulnerability disclosure or bug bounty programs.
The research ultimately demonstrated many novel desync triggers, one new desync pattern, and one new weaponization technique. It also introduced Shared-Parser Confusion, a broader attack concept that may extend beyond request smuggling.
New and Unexpected Desync Triggers
Traditional request-smuggling testing often focuses on conflicts involving the Content-Length and Transfer-Encoding headers. The new research shows that parsing differences can also be triggered by less obvious HTTP features, including unusual request methods, unexpected method-and-body combinations, uncommon transfer encodings, duplicate headers, and content types normally associated with responses.
One notable example involved the multipart/byteranges content type. According to the research, this behavior affected more than 200 websites in the authorized target set and appeared across multiple server implementations. The lesson for defenders is clear: protection cannot rely only on a short list of well-known request-smuggling payloads.
Dual Matching Content-Length Headers
Security controls commonly look for requests containing conflicting Content-Length values. The research showed that some systems can also behave unexpectedly when a request contains two matching Content-Length headers. Although the values appear consistent, components in the request chain may still process the duplicate headers differently and disagree about whether the request has a body or where it ends.
This pattern was exploitable in real deployments, including an environment where response queue poisoning exposed a long-lived API key. The underlying issue was later linked to a server misconfiguration.
The Dangling-Byte Technique
Response queue poisoning has often been unreliable because the front end may notice an unexpected extra response and close the connection before the attack succeeds. The dangling-byte technique improves reliability by sending an incomplete smuggled request that is missing one byte. The next legitimate request supplies that byte, completing the attacker’s request only after the victim’s traffic arrives.
In the tested scenarios, this removed a significant timing race and made response theft substantially more reliable on affected architectures.
Shared-Parser Confusion
The research also introduced Shared-Parser Confusion. Some implementations reuse parsing logic for both HTTP requests and HTTP responses. As a result, functionality intended for processing responses may accidentally be activated by attacker-controlled data inside a request.
This expands the potential attack surface beyond ordinary request-processing behavior. Response-specific headers, content types, and parser rules may also influence how a malicious request is interpreted.
How Imperva Protects Customers
Imperva’s AI powered security engine is designed to help protect customers against the next generation of AI-assisted attacks, including systems like HTTP Terminator that can generate and test large volumes of novel protocol variations. Rather than relying only on known payloads or static signatures, Imperva combines strict protocol validation, behavioral analysis, anomaly detection, and continuous threat intelligence to identify malicious or ambiguous traffic patterns at scale. This approach allows Imperva to respond quickly when attackers or AI-driven research tools uncover new ways to abuse protocol edge cases, helping ensure that customers remain protected even as attack discovery becomes more automated and faster-moving.
Imperva’s protection against HTTP desync attacks does not depend on one vulnerability-specific signature. Cloud WAF and On-Prem WAF use dedicated security rules and protocol-validation controls designed to identify malformed, conflicting, and ambiguous HTTP requests before they reach protected applications.
These protections cover behavior commonly associated with desync and request-smuggling attacks, including:
Invalid or ambiguous HTTP message framing
Redundant, duplicated, or conflicting request headers
Malformed protocol elements and abnormal request structure
Suspicious combinations of methods, headers, and message bodies
Attempts to embed an additional HTTP request within an existing request
Known request-smuggling and response queue poisoning patterns
Imperva’s analysis determined that existing protections were already blocking the primary practical attack patterns described in the HTTP Terminator research. Following a detailed review of the newly published vectors, Imperva also fortified its mitigation to provide additional coverage for the newly documented parsing variations.
Imperva telemetry shows that these protections are actively blocking real-world exploitation attempts, especially using desync techniques. Observed POST bodies include payloads characteristic of the HTTP Smuggler Burp Suite extension, with embedded or malformed request lines, randomized paths, and synthetic headers intended to reveal parsing discrepancies between front-end and back-end systems. Examples of blocked payloads include:
These requests are not normal application traffic. They are crafted probes designed to test whether components in an HTTP request chain disagree about request boundaries or interpret an embedded request differently. Imperva blocked these attempts before they reached protected applications, demonstrating that the threat is already being explored in the wild and that existing desync protections are providing practical coverage.
Cloud WAF customers receive managed protection updates as part of the service. On-Prem WAF customers should enable dedicated available controls such as Response Forking – HTTP Desync policy (if not enabled) to mitigate these attacks.
Recommended Best Practices
Imperva provides protection against the practical attack techniques described in the research, but organizations should also reduce the underlying risk within their application delivery architecture.
Keep infrastructure components updated. Apply vendor patches to web servers, reverse proxies, application delivery controllers, API gateways, CDNs, and load balancers.
Reject ambiguous HTTP requests. Do not forward requests containing duplicate framing headers, invalid transfer encodings, or malformed protocol syntax to backend systems.
Restrict unnecessary HTTP methods. Allow only the methods required by the application, and define which methods may legitimately contain a request body.
Prefer HTTP/2 or newer protocols upstream. Imperva Cloud WAF allows clients-to-WAF HTTP/2 support and also WAF-to-origin server HTTP/2 support.
On Prem WAF also supports HTTP/2 traffic inspection.
Conclusion
The HTTP Terminator research demonstrates both the continuing security challenges of HTTP/1.1 and the growing ability of AI-assisted systems to discover unexpected protocol behavior at scale.
It also highlights why defense against HTTP desync attacks must be based on strict protocol validation and broad behavioral coverage, not only signatures for previously published payloads.
Imperva Cloud WAF and WAF Gateway customers are protected against the practical desync techniques described in the research. Existing dedicated security rules were already blocking the associated malicious request patterns, and Imperva has further fortified these protections in response to the newly published findings.
Imperva Threat Research will continue monitoring this area and emerging HTTP parsing techniques to protect customers as the threat landscape evolves.
Short version: an MCP server is the tooling layer that lets an AI agent act on external systems. Hosted remotely, it is an API endpoint like any other — and it needs bot and WAF controls in front of it, API security on its own endpoints, and AI guardrails that inspect what the tools send back, not just what the user types in.
Not since the dot-com boom in the late 1990s has the world seen a more highly talked-about and sought-after tech revolution. Artificial Intelligence has entered every aspect of our lives – from building large scalable applications to your Monday morning Macchiato.
With this spread of wildly varying use cases, one thing became abundantly clear. Large Language Models have isolated context, which is limited to the training data and the inputs provided by a user. To expand this knowledge, we need to provide AI Agents with appropriate tooling to retrieve such information. A curl tool to view a webpage, a directory listing tool to retrieve files from a folder, or a git CLI tool to commit changes to a repo.
Humans need tools as well. We don’t sift through HTML code, read JSON responses or query API endpoints via the command line. Rather we rely on well-thought-out and structured UX components – icons, text fields, buttons, and checkboxes – all of which are wired into various functions and APIs in the backend.
AI Agents, however? They rely on different types of tools. Given that every single one of the billions of websites and applications on the Internet today works and operates differently, these tools need to cater to them. Sites have been built on everything ranging from PHP and ASP to Node and Express. The question becomes – how can I ensure my agent reliably interacts with each of these sites? You could argue that these days, most applications expose a lot of their functionality via APIs. And you would be right. While AI Agents can easily consume these APIs, it involves a few different steps –
read the API reference documentation
build a small handler to call this API, with appropriate context
build a small handler to parse the response
All these steps, every single time. Every site, every application, requiring its own “code” built by the AI Agent. With limited context windows and larger thinking models, this can get out of hand quickly – both in terms of token count and time taken – for every single user prompt.
What is an MCP Server?
Enter the MCP Server. An MCP server is a standardized service that exposes a defined set of tools, resources and prompts to an AI agent over the Model Context Protocol, so the agent can act on an external system without hand-written glue code for every API. Developed by Anthropic, the Model Context Protocol was built as an open-source standard for connecting AI Applications to external systems. It was released in November 2024 and contributed to the Linux Foundation’s Agentic AI Foundation in December 2025; by that point more than 10,000 MCP servers had been published. In essence, providing the AI Agent the right tools and resources, for each of these applications, to help abstract away the complexity of each of these interactions. Think of it as a USB-C port for your AI Agent – one connector, and every application on the other side just works!
What can MCP Servers allow your agent to do? The use cases are endless and constantly expanding every day – from searching and booking flights to reviewing stock prices and executing trades (this is not financial advice!). MCP Servers give your AI Agent the tools it needs to do more than just be your information chatbot.
MCP Server Security Risks: Where the Exposure Actually Is
But all this functionality exposes a glaringly obvious security blind spot. Who is protecting your MCP Server, which now has tools exposed to action any of these tasks? Who is governing what can be asked of your AI Agent which now has access to these tools? The security implications are massive.
This is not theoretical. Imperva’s threat research team documented a critical remote code execution flaw (CVE-2025-53967) in the widely used Framelink Figma MCP server — an open-source project with more than 10,000 GitHub stars — and OWASP’s Gen AI Security Project published A Practical Guide for Secure MCP Server Development in February 2026 because the same weaknesses keep recurring. The MCP specification’s own security guidance now names token passthrough, session hijacking, the confused deputy problem and SSRF as first-class MCP risks.
Local vs. remote MCP servers: two different risk profiles
Now, not every MCP Server carries the same exposure. Plenty of them run locally – a process on your laptop, talking to your agent over stdio, never touching a network. The risk there is real, but it’s a different conversation: credentials sitting in a config file, and how much that server is allowed to reach on your behalf. The moment an MCP Server goes remote though – hosted, over HTTP, serving agents across the Internet – it stops being a local utility and becomes what it always really was underneath: an API endpoint. Exposed, authenticated, and waiting to be probed. That’s the one you can put controls in front of.
This is where Thales’s focus has been for the past several months. For decades, Thales Imperva has been at the forefront of securing sites and applications, and with the evolution of applications and their users, we’ve enabled our solutions to cover these use cases and the complex threat landscape.
Automated traffic is the baseline condition here, not the exception. Imperva’s 2026 Bad Bot Report found that bots accounted for more than 53% of all web traffic in 2025, up from 51% the year before — and that 27% of bot attacks targeted API endpoints. A remote MCP server is an API endpoint, so it inherits that traffic profile the moment it goes live. Knowing which AI bots to allow and which to block is the first control, not the last.
The Thales Imperva Cloud WAF and Advanced Bot Protection provide visibility into automated traffic heading towards the MCP Server, preventing generally malicious bot traffic and more exploitative OWASP Top 10 attack classes like command injection and SQL injection.
Thales Imperva API Security ensures your MCP Server has its own endpoints secured against everything from simple schema exploitation to complex business logic attacks. (For the wider picture of agents as API consumers, see API security for AI agents.)
Finally, our AI Application Security puts in place guardrails that sit between the AI Agent and the model behind it, securing the workflow against LLM-specific attacks like prompt injection, system prompt leakage and jailbreak attempts. And critically for MCP – it inspects what comes back from the tools, not just what goes in. Today, most people worry about user prompts. Far fewer are watching the tool response. Because an instruction buried in a log entry or an incident description can quietly make its way into your Agent’s context and get read as a command rather than data. Your MCP Server is a perfect delivery mechanism for exactly that.
Thales Imperva MCP Server for Cloud WAF
At Thales, we have also been working on our own MCP Server behind the scenes.
What does this mean for you? Imagine a world where you no longer have to log into a console to analyze where last week’s attack traffic came from. No more manually putting together a monthly executive presentation on the state of your security posture.
The Thales Imperva MCP Server for Cloud WAF is in beta today, and for now, it’s read-only by design. Your agent can query, analyze and report across your estate. Need to see which sites have your “Block requests from South Africa” ACL policy enabled? Or what security rules are enabled for your production site? Just ask your Agent! No prior knowledge strictly necessary.
It’s open source and available on GitHub – pull the container, add your API credentials, and point your agent at it.
Having trouble remembering regex for your custom rules? Or finding yourself constantly making individual site changes? Tell us! Beta feedback is what shapes where this goes.
Frequently asked questions about MCP server security
What is MCP server security?
MCP server security is the set of controls that protect a Model Context Protocol server — and the AI agent calling it — from abuse. Because a remote MCP server is an authenticated HTTP endpoint that exposes tools capable of real actions, it needs the same protections as any production API, plus AI-specific guardrails on the prompts and tool responses flowing through it.
What are the main MCP server security risks?
The recurring ones are prompt injection delivered through tool responses rather than user input, tool poisoning, over-broad OAuth scopes and token passthrough, session hijacking, SSRF during metadata discovery, the confused deputy problem in MCP proxy servers, and ordinary application flaws such as the command-injection RCE found in the Framelink Figma MCP server. Excessive tool permissions amplify all of them.
Are local MCP servers safer than remote ones?
They carry a different risk profile, not a smaller one. A local MCP server talking to the agent over stdio never touches the network, so the exposure is credentials in a config file and how far that server can reach on your behalf. A remote MCP server served over HTTP is Internet-facing, which makes it probeable — and also makes it something you can put network and API controls in front of.
Can a WAF protect an MCP server?
Yes, for the endpoint layer. Once an MCP server is remote it is an HTTP API, so a WAF and bot protection stop automated probing and injection-class attacks before they reach it, and API security covers schema abuse and business-logic attacks on its endpoints. What a WAF cannot do alone is judge intent inside the model workflow — that needs AI guardrails inspecting prompts and tool responses.
What are MCP server security best practices?
Treat the server as a production API: authenticate every inbound request and never accept tokens that were not issued for your server, use least-privilege scopes and non-deterministic session IDs bound to the user, validate and allowlist outbound URLs, start read-only before enabling write operations, log every tool call, and inspect tool responses as untrusted input. OWASP’s secure MCP development guide and the MCP specification’s security best practices are the reference baselines.
Secure your MCP server with Thales Imperva
MCP is now an open standard under the Linux Foundation, and the number of exposed servers is only going up. The controls are the ones you already know — web application and API protection in front of the endpoint, API security on its schemas and business logic, and AI application security on the prompts and tool responses moving through it. See how Thales Imperva secures applications and APIs, and try the read-only Cloud WAF MCP Server beta on GitHub.
Many Australian businesses have moved their applications and data to cloud-native architectures for agility, scalability, and sovereignty. However, this move extends their attack surface beyond their typical security boundaries.
As evidenced by the Thales 2026 Data Threat Report, attackers increasingly target web applications and APIs with sophisticated methods that outpace the traditional protection built into cloud platforms. Security teams face intense pressure to deliver control and risk reduction, but this mandate creates frustration with DevOps teams, who push for speed and scale while leveraging the benefits of cloud-native tools.
The gap is best addressed by bringing the Thales enterprise-grade Imperva Web Application and API Protection (WAAP) solution directly into Australia’s Google Cloud infrastructure through a native integration. For Australian organisations running critical workloads in Google Cloud, this creates some important opportunities.
Data Sovereignty Is No Longer Just A Compliance Discussion
Organisations need confidence in where their data is stored, how it is processed, and who can access it.
For operators of critical infrastructure, the data itself is strategically significant. Data such ass traffic patterns, transaction flows, and operational telemetry from energy, financial, and health systems can reveal how essential services function, where dependencies lie, and how disruptions might be engineered. Losing visibility and control over where that data is processed and who can access it is a different order of risk. For businesses subject to SOCI Act, APRA CPS 234, or other government security mandates, controlling where data is stored and how it travels is essential for complying with Australian data sovereignty requirements.
Performance Matters When Security Becomes Part Of The Application Path
Security controls should not become a performance bottleneck. The conflict is tangible
While security teams want to ensure applications and APIs are protected with consistent security controls, visibility, compliance, and governance, DevSecOps teams want security that can be deployed quickly and integrated seamlessly into existing development workflows without creating operational overhead or slowing down application delivery.
This is one of the key reasons many organisations are showing strong interest in CI/CD-based onboarding models. Security teams prefer having the ability to deploy security controls without changing DNS records, modifying application architectures, or handing operational control of applications to another team or third-party provider.
Applications And APIs Have Become Primary Targets
A focus on websites is no longer enough for modern applications, as they depend on APIs, automation, third-party services, and machine-to-machine interactions that happen out of view of conventional monitoring. The threat actors understand this dependency and focus on the interfaces that run today’s digital services.
That is why WAAP has become such an important security category. Organisations need protection that addresses web application attacks, API abuse, automated bot activity, and Layer 7 denial-of-service attacks within a single security approach.
Imperva for Google Cloud delivers the same Imperva capabilities available through the broader cloud service, including Web Application Firewall (WAF) for cloud applications, API security, bot management, Layer 7 DDoS protection, and threat intelligence informed by global attack activity.
This is not a pared-down instance; Imperva for Google Cloud delivers the full WAAP stack locally, feature-for-feature, with the global service.
Built For Google Cloud Environments
Pressure on security teams to cut complexity is high. According to the Thales 2026 Data Threat Report, companies use 7 distinct data protection and monitoring solutions, yet visibility, staffing, and complexity remain major concerns for security teams.
As Imperva WAAP now operates within Google Cloud Australia, it makes perfect sense for solutions such as Google Cloud Load Balancing, Google Kubernetes Engine (GKE), Compute Engine, and other networking tools to work together with API security.
For cloud and platform teams, security can be deployed alongside applications rather than treated as a separate environment that requires its own operational model.
Security That Scales With Cloud Native Workloads
One of the reasons organisations move to cloud platforms is the ability to scale up or down. Security infrastructure should be able to do the same.
Regardless of whether a business is dealing with seasonal demand challenges, big public-facing platforms, high-volume APIs, or expanding digital services, the security layer must evolve with the applications and not require continuous redesign.
As more Australian organisations build cloud-native services, that expectation will become standard.
Organisations increasingly want security controls that operate where their applications operate. For businesses building on Google Cloud, keeping workloads within Australia is becoming a practical architectural decision rather than a future aspiration. By unifying Imperva’s proven application security leadership with Google Cloud’s high-performance infrastructure, organisations can eliminate the need to compromise between security and speed.
Get in contact with the local team and see how Imperva WAAP works in Google Cloud Australia.
How Thales is bringing active API protection to self-managed environments, without compromising digital sovereignty.
APIs Changed Faster Than Security Architectures
Organizations have invested heavily in discovering APIs, classifying sensitive data, and understanding API risk. That’s progress.
But visibility alone doesn’t stop attacks.
Attackers don’t wait for analysts to review dashboards. They exploit broken authorization, enumerate objects, abuse business logic, and exfiltrate data in minutes.
Knowing an attack happened is useful.
Stopping it is what matters.
How Has Sovereignty Introduced a New Challenge?
For organizations operating in finance, government, healthcare, defense, and critical infrastructure, API security has always carried another requirement.
Data cannot leave the environment.
API payloads often contain customer records, financial information, healthcare data, or classified information. Regulations and increasingly internal governance policies require that this information stays under organizational control.
That’s why many organizations choose self-managed API security.
Not because they dislike cloud. Because they cannot compromise sovereignty.
Digital sovereignty means retaining control over where sensitive data is processed, where security decisions are made, and who ultimately governs the infrastructure, protecting critical services.
That’s why Thales’s Self-Managed Imperva API Security was built, to give organizations the flexibility to deploy API security wherever their business, operational, or regulatory requirements demand, while keeping sensitive inspection and enforcement under their control.
Yet sovereignty has historically introduced an unintended compromise.
The Missing Piece: Detection Without Enforcement
Historically, this created an operational gap.
Security teams could discover APIs.
They could identify risky endpoints.
They could detect sophisticated attacks such as Broken Object Level Authorization (BOLA), one of the most critical risks identified in the OWASP API Security Top 10.
But detection alone doesn’t interrupt an attack.
When enforcement exists outside the API security workflow, response becomes another investigation, another ticket, another operational handoff. Every delay gives attackers more time to exploit vulnerable APIs and access sensitive information.
Security teams weren’t lacking visibility.
They were lacking immediate action.
For organizations operating entirely within sovereign environments, this challenge was even greater. Protecting sensitive data meant keeping security operations local—but that shouldn’t mean sacrificing the ability to actively stop attacks.
Modern security should never force organizations to choose between operational control and effective protection.
This isn’t simply feature parity. It’s an architectural parity.
Detection and enforcement can now operate together where the data already resides.
Closing the Last Mile of Sovereign API Security
Today, that trade-off disappeared.
With the latest enhancement to Thales’ Self-Managed Imperva API Security, organizations can now extend active API enforcement into self-managed deployments while maintaining complete control over where inspection, detection, and enforcement take place.
This is more than a new capability.
It represents an important step toward a sovereign-by-design security architecture—one where security adapts to the customer’s operational model instead of requiring the customer to adapt to the security platform.
Organizations no longer have to choose between maintaining sovereign control over sensitive API traffic and deploying modern API protection capable of responding to attacks in real time.
Detection and enforcement now work together, exactly where the data already resides.
One Protection Model. Any Deployment.
Modern enterprises rarely operate in a single environment.
Applications span public cloud, private cloud, Kubernetes clusters, on-premises data centers, and increasingly hybrid infrastructures.
Security shouldn’t become fragmented simply because deployments are.
Whether organizations deploy Imperva API Security through a cloud-managed service or a self-managed environment, they should expect the same security intelligence, consistent policy model, and comparable protection outcomes.
The deployment model changes.
The protection model doesn’t.
For organizations embracing digital sovereignty, that’s an important distinction. They can adopt the architecture that best aligns with their regulatory obligations and operational requirements while maintaining a consistent security posture across every environment.
Digital Sovereignty Requires Security That Adapts
The future of cybersecurity isn’t simply about moving more workloads to the cloud.
It’s about giving organizations the freedom to choose where their data lives, where security operates, and how trust is established.
That is the essence of digital sovereignty.
Modern security platforms must deliver the same level of protection regardless of deployment model, enabling organizations to protect critical assets without compromising regulatory compliance, operational resilience, or customer trust.
API security should be no exception.
With Self-Managed Imperva API Security enforcement, organizations can now:
Detect and stop critical API threats such as BOLA within the same sovereign environment.
Maintain complete control over sensitive API traffic and enforcement policies.
Apply a consistent protection model across cloud, hybrid, and self-managed deployments.
Reduce operational complexity while strengthening resilience against modern API threats.
The Future Is Sovereign by Design
Digital sovereignty is no longer simply a regulatory discussion.
It’s becoming a defining principle of modern cybersecurity architecture.
As organizations continue to modernize applications, embrace AI, and expand digital services, they need security platforms that protect innovation without requiring sensitive data to leave their control.
That’s the direction Thales has long championed: security that enables trust, resilience, and customer choice.
The latest Self-Managed Imperva API Security enhancement is another step toward that vision, bringing active API protection to organizations that require complete operational control, without compromising the security outcomes they expect.
Because the future of API security won’t be defined by where it runs.
It will be defined by where trust resides.
And increasingly, trust begins with keeping control of exactly where it belongs.
Download this guide to discover how Imperva protects production APIs without compromising data sovereignty.
TL;DR: A critical remote code execution vulnerability has been disclosed in FastJson, a widely used JSON processing library for Java. The vulnerability, assigned CVE-2026-16723 with a CVSS score of 9.0 (Critical), affects FastJson versions 1.2.68 through 1.2.83 under specific Spring Boot deployment conditions and can be exploited using malicious JSON without authentication, enabling AutoType, or relying on third-party gadget classes.
Imperva customers are protected against exploitation attempts associated with this vulnerability. Organizations using FastJson 1.x should enable SafeMode immediately and prioritize migration to FastJson 2.x.
About the FastJson Vulnerability
On July 21, 2026, the FastJson maintainers published a security advisory for a critical remote code execution vulnerability discovered by FearsOff Cybersecurity. FastJson is an open-source Java library originally developed by Alibaba for serializing Java objects into JSON and deserializing JSON into Java objects.
The vulnerability affects FastJson versions 1.2.68 through 1.2.83, including 1.2.83, the final release in the FastJson 1.x branch. It’s been assigned CVE-2026-16723, with a CVSS score of 9.0, or Critical. According to the official FastJson advisory, exploitation has been verified in Spring Boot applications deployed as executable fat JARs across Spring Boot 2.x, 3.x, and 4.x and JDK versions 8, 11, 17, and 21.
The issue is particularly dangerous because it is exploitable under FastJson’s default configuration. AutoType does not need to be enabled, and attackers do not need a suitable third-party gadget class to be present in the application’s classpath. Applications are potentially exposed when they process attacker-controlled JSON using common methods including JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class).
Specifying a target class during deserialization does not fully mitigate the vulnerability. An attacker may still be able to place a malicious payload inside a field typed as an Object or Map.
How the Vulnerability Works
FastJson supports polymorphic deserialization through the @type field, which identifies the Java class that should be instantiated from supplied JSON. Although FastJson 1.x disables AutoType by default and applies checks intended to prevent untrusted classes from being instantiated, the newly disclosed vulnerability exposes an alternate path through its internal type-resolution logic.
An attacker can submit specially crafted JSON containing a malicious @type value. During processing, FastJson may perform resource lookups based on the attacker-controlled class name. In affected Spring Boot fat-JAR deployments, an attacker can manipulate this behavior using nested JAR URLs, bypass FastJson’s normal type restrictions, and reach a code-execution path without supplying a conventional deserialization gadget.
This bypass is possible because FastJson 1.x can treat the presence of a @JSONType annotation as a trust signal during type resolution. The attacker-controlled resource lookup and annotation-based trust behavior combine to circumvent the protections normally associated with disabling AutoType.
Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code with the privileges of the affected Java application. This could lead to data theft, malware or webshell deployment, credential compromise, lateral movement, or complete takeover of the underlying server. Public proof-of-concept information is available, substantially increasing the likelihood of rapid exploitation.
FastJson 2.x is not affected. Its type-resolution architecture does not perform equivalent resource probing on user-controlled class names, does not use @JSONType as a trust signal, and uses an allowlist-first model for polymorphic type handling.
What We’re Seeing
So far, attacks exploiting this vulnerability are targeting a wide range of organizations, across Financial Services, Healthcare, Computing, Retail, Business, and other industries.
Attacks are currently almost entirely targeting US-based organizations, with a few attacks in Singapore and Canada, although this will likely continue to expand globally.
Most attacks are coming from browser impersonators, although tools written in Ruby and Go account for about 30% of all attacks collectively.
Mitigation and Protection
Imperva customers are protected against exploitation attempts associated with CVE-2026-16723. Imperva Cloud WAF and WAF Gateway inspect incoming HTTP requests and identify malicious JSON payloads, suspicious @type values, nested JAR URL patterns, and remote code execution techniques before they reach vulnerable applications.
Organizations should not rely on perimeter protection as a substitute for remediation. FastJson 1.x is no longer actively maintained, and no patched 1.x version has been released for this vulnerability. Organizations using an affected release should take the following actions:
Enable FastJson SafeMode immediately using the JVM option -DFastJson.parser.safeMode=true, the FastJson.parser.safeMode=true property, or ParserConfig.getGlobalInstance().setSafeMode(true).
Alternatively, use a FastJson noneautotype build, which removes the vulnerable AutoType-related code at compile time.
Inventory Java and Spring Boot applications for FastJson dependencies, including transitive dependencies.
Prioritize migration to FastJson 2.x after appropriate compatibility testing.
Review application and WAF logs for suspicious JSON requests containing @type fields or jar:http and jar:file URL patterns.
Investigate potentially affected systems for unexpected process execution, outbound connections, unauthorized file changes, webshells, or other indications of compromise.
Because exploitation requires no authentication, no user interaction, and no external gadget library, exposed applications running affected configurations should be treated as high-priority remediation targets. Imperva customers remain protected while organizations identify vulnerable deployments, enable SafeMode, and migrate away from FastJson 1.x.
TL;DR:A critical pre-authentication Remote Code Execution (RCE) vulnerability, dubbed “wp2shell” (CVE-2026-63030), has been identified in WordPress Core. This vulnerability allows an unauthenticated attacker to execute arbitrary code on a vulnerable WordPress installation without any preconditions, such as plugins or specific configurations. Given that WordPress powers over 500 million websites, this vulnerability poses a significant risk to the global web ecosystem.
Vulnerability Overview
The vulnerability exists within the WordPress REST API, specifically affecting the /wp-json/batch/v1 and ?rest_route=/batch/v1 endpoints. An unauthenticated attacker can exploit this endpoint to achieve RCE.
Affected WordPress Versions:
6.9.0 – 6.9.4 (Fixed in 6.9.5)
7.0.0 – 7.0.1 (Fixed in 7.0.2)
(Note: WordPress versions older than 6.9.0 are not affected by this specific vulnerability.)
Mitigation and Protection
Imperva customers with both Cloud WAF and WAF-GW deployments are protected against exploitation attempts associated with the “wp2shell” vulnerability. Cloud WAF automatically inspects and blocks requests targeting the vulnerable REST API endpoints at the edge, mitigating the risk before it reaches your backend services.
For organizations utilizing WAF-GW, we are providing policy updates to further harden protection. Administrators should apply the latest security policy updates to their WAF-GW environments to ensure these enhanced inspection capabilities are active. These updates provide another layer of defense, blocking the specific patterns associated with unauthorized batch API access before they can be processed by the WordPress core.
Recommended Best Practices
While Imperva provides protection at the edge, we strongly recommend that all WordPress administrators take the following steps:
Update Immediately: Ensure your WordPress installation is updated to the latest secure versions (6.9.5 or 7.0.2) as soon as possible. This is the only definitive way to resolve the underlying vulnerability.
Emergency Mitigation: If an immediate upgrade is not possible, you can temporarily mitigate the risk by blocking access to the affected REST API endpoints: • Block requests to the path: /wp-json/batch/v1 • Block requests containing the query parameter: rest_route=/batch/v1
Note: These mitigation measures may impact legitimate site functionality and should only be used as a temporary stopgap until you are able to perform the necessary software updates. For more technical details regarding the vulnerability discovery, please refer to the official research advisory from Searchlight Cyber.
In this article, we disclose our latest findings we made on Perforce protocol P4 (Helix Core) between command line client and server, and reveal how a threat actor could leverage it to conduct attacks.
This security issue affects P4 (Helix Core) before P4 (Helix Core) 2025.2 Patch 2, was patched and was attributed a CVSS score of 7.7 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L). See our recommendation section and the Perforce advisory for more information.
Perforce Helix Client
Perforce Helix Client is a version control system often used for large projects and teams that work with many files or large assets.
While Git and SVN are great for many projects, Perforce shines in environments with massive codebases or large binary files, like game development or VFX. It handles millions of files efficiently, lets teams lock files to prevent merge conflicts on non-text assets, and supports partial checkouts so developers don’t need the entire repository locally.
Architecture
Perforce operates on a centralized client-server architecture model, where the command-line client (p4) communicates directly with a centralized Perforce server responsible for managing the repository, metadata, and access controls. This communication can be established through Perforce’s native protocol (default port 1666) or wrapped into HTTPS to ensure encrypted data transmission.
p4 info: typically one of the first commands executed to verify server connectivity and retrieve essential information, including server version, root directory…
The p4 client command creates and manages workspace specifications, defining the local root directory, depot paths, and the client view mapping that determines file accessibility.
The p4 login command establishes authenticated sessions with the server, generating temporary tickets that allow subsequent commands to execute without re-entering credentials.
The p4 sync, add, submit, revert … commands enable developers to manage the lifecycle of files in their workspace (synchronization, modification, addition, submission, and undoing changes).
Eventually, whenever the P4CONFIG variable is set (usually .p4config), the client automatically loads configuration variables such as P4USER, P4PORT, P4CLIENT and P4PASSWD from the designated config file discovered in the current directory or home directory. This hierarchical configuration resolution applies within the scope of P4CLIENTPATH, allowing workspace-specific configurations to override global system settings.
Details
The Perforce client-server communication relies on a custom binary protocol, in which each message carries a set of parameters and a handler name designating the operation to be executed by the receiver. Multiple messages can be chained within a single exchange.
Fig. 2: Extract from a clear traffic dump of a p4 info request
This communication can be secured by SSL while the fingerprint of the server is added into a trust local file located at P4TRUST (itself defined in the p4 config file).
During our investigation, we recorded the server traffic of several sensitive responses (triggering SSO response, writing files with arbitrary content to arbitrary location, etc. ) and observed that no validation of server response exists in the client side:
No expiration timeout exists, as our recorded responses could work even days after they were generated.
No session id is used during a connection. Therefore, we recorded the traffic between our client and server; and used the exact same response bytes in the dockerized POC that we shared with Perforce security team.
The client doesn’t verify if the server response matches the request it initiated.
Beyond the risk of replay attacks, the last point makes the following scenario possible:
A threat actor shares the details of an unknown server to the victim.
Upon initial connection to the server, it immediately responds with an instruction to write a malicious line into a configuration file ( ~/.p4enviro or .p4config for instance). The expression, P4LOGINSSO=<malicious shell command>, will be executed by any new p4 command.
Indeed, the P4LOGINSSO environment variable is designed for SSO integrations: when set, the p4 client executes its value as a shell command to obtain authentication credentials.
Fig. 3: Illustration of the first attack scenario
Another scenario we presented was the following:
A threat actor shares a project including a hidden .p4config file with specially crafted P4PORT and P4LOGINSSO variables.
The victim executes any legitimate p4 command.
This command is sent to the malicious server defined in P4PORT that returns a “client-sso” instruction, immediately executed on the client side.
Fig. 4: Illustration of the second scenario
Post Exploitation
Once exploited, this flaw enables attackers to achieve arbitrary code execution under the victim’s user account: the same context in which the p4 command runs.
This grants full local control, allowing theft of sensitive data (e.g., source code, intellectual property, credentials), modification of files or configurations for persistence or further compromise, and disruption of workflows through file deletion or system resource exhaustion.
In environments handling high-value assets, such as game development studios, VFX pipelines, or large-scale software projects, the business impact can be substantial, including IP loss, production delays, and potential downstream effects on team collaboration or supply chain integrity.
Mitigation
Following the reception of our report, Perforce security team requested an embargo until the release of v2026.1 (May 2026) to give them time to patch this issue.
The fix introduced a built-in protection in the client that prevents syncing or submitting files matching Perforce configuration file names (.p4enviro, .p4config, etc.), regardless of workspace settings. The P4_SYSTEMIGNORE variable can be used to extend this list. However, this does not address the lack of binding between client requests and server responses, nor the absence of a replay timeout or session id.
Recommendations
Update your system to the latest available version.
Organizations using Perforce command line client should treat this issue seriously and adopt the following guidelines:
Prevent exchange of configuration files from unvetted sources.
Educate users on the dangers of connecting to unknown or shared Perforce endpoints and encourage verification of server authenticity before executing any commands.
Enforce encrypted connections to reduce exposure to man in the middle attacks.
Monitor for unusual p4 activity, including unexpected server connections or configuration sourcing.
Conclusion
This vulnerability in the Perforce Helix Client highlights how widely used version control systems can contain overlooked risks in their core client-server communication, assumptions that the server is always trustworthy or responses are inherently safe.
In environments with massive, distributed asset pipelines, such protocol-level gaps can quietly expose teams to compromise through everyday interactions like querying server info or loading shared configurations.
As development tools evolve toward greater automation, integration, and reliance on external or unvetted endpoints, these subtle trust boundaries deserve renewed scrutiny. This finding is a reminder that supply chain attacks do not require compromising a central registry: embedding a malicious configuration file in a shared project artifact could be sufficient to achieve code execution across an entire team.
Timeline
October 20 2025 – Disclosure sent to Perforce security team.
October 21 2025 – Report acknowledged by the Perforce security team.
March 9 2026 – Patch released for 2025.2 and backported to prior supported versions.
May 18 2026 – Release of 2026.1 and publication of the security advisory.
For years, the main goal of search was simple: to help users find links. A user searched, reviewed results, clicked a website, and consumed the content directly from the source.
But AI is changing that model. Increasingly, users ask AI assistants for answers instead of searching for websites. They seek summaries, recommendations, comparisons, troubleshooting advice and product guidance, often receiving a complete answer without ever visiting the original source site. This creates a new reality for website owners: your content may still influence the customer journey, even when the customer never reaches your website.
This shift is why AI bot traffic matters.
AI bots scan, fetch, and process web content so AI systems can answer questions, summarize pages, recommend vendors, and understand what your business does. Some of this traffic creates value. Some of it can create risk. The challenge is knowing the difference and building the right policy.
Quick answer: Not all AI bots should be treated the same. AI traffic falls into four main types: AI search bots that help your brand appear in AI answers, AI training bots that collect content to train models, AI fetch bots that retrieve a page on behalf of a user, and agentic AI systems that take actions such as logging in, querying inventory, or completing transactions. The right policy is not “allow all” or “block all”; it is to classify each AI bot, decide which to allow on which parts of your site, and inspect every request for malicious behavior. Imperva Advanced Bot Protection classifies AI traffic, while Imperva Web Application Firewall and DDoS Protection inspect and rate-limit it, so you stay visible to trusted AI while blocking abuse.
The new tension: visibility vs. protection
As the risk from AI-driven bots increases, many organizations are now facing a difficult question:
Should we allow AI bots to scan our website, or should we block them?
Blocking all AI bots may seem like the safest option, but it can also reduce your visibility in AI-generated experiences. If your public content is not accessible to the right AI systems, your brand may appear less often when users ask AI tools for recommendations or information.
On the other hand, allowing every AI bot creates business and security risks. AI bots may collect valuable content, increase traffic costs, overload servers, or access areas of the website that were never meant to be used by automated systems.
So, the right question is not “allow or block AI bots?”
The better question is:
Which AI bots should we allow, for what purpose, on which parts of the website, and under what protection?Not all AI bots are the same
The Rise of Agentic AI
The next wave of AI traffic will not come from crawlers alone. It will come from autonomous AI agents acting on behalf of users.
Agentic AI systems can browse websites, compare products, gather information, interact with APIs, complete forms, and execute multi-step workflows with limited human intervention.
Unlike traditional search crawlers, these agents actively interact with business logic. They can create accounts, query inventory, test workflows, retrieve pricing, and trigger application functions.
This creates a new challenge for security teams. The question is no longer simply whether an AI bot is legitimate. The question is whether the action being performed should be allowed.
As AI agents become more capable, organizations need controls that evaluate identity, intent, behavior, and access permissions simultaneously.
What Most Security Teams Cannot See
Imperva Advanced Bot Protection provides one of the industry’s most comprehensive AI traffic classification capabilities, enabling organizations to identify AI search bots, AI training bots, AI fetch bots, and emerging agentic AI systems. Security teams can then apply granular policies to allow, restrict, rate-limit, or block AI traffic based on business risk and application context.
As AI traffic becomes more diverse, organizations need visibility not only into which AI tools are accessing their applications, but also what those tools are doing, which business functions they are interacting with, and whether that activity aligns with organizational policy.
Effective control starts with understanding the different types of AI traffic and applying policies accordingly.
To create a good policy, you first need to understand the different types of AI bots.
1. AI search bots
AI search bots scan public websites so AI-powered search engines and answer engines can understand what content exists online.
These bots may help your business stay visible when users ask AI tools questions like “What is the best solution for…?” or “Which vendor supports…?”
You may want to allow these bots on public marketing pages, blogs, product pages, and documentation — especially content you want customers to discover.
2. AI training bots
Training bots collect public web content that may be used to train or improve AI models.
This is where the discussion becomes more nuanced. You may want your brand to appear in AI answers, but you may not want your full content, research, product information, or intellectual property used to train external models without control or compensation.
For many organizations, training bots require a stricter policy than search bots.
3. AI fetch bots
AI fetch bots usually act in response to a user request. For example, a user asks an AI assistant to summarize a specific URL, check a product page, or compare information from your site.
Because these requests are typically initiated on behalf of a user, they often represent legitimate business value. However, they can also be abused. An attacker may try to manipulate an AI assistant into sending suspicious payloads, scanning pages, or probing your application while hiding behind a legitimate AI fetcher.
That means fetch bots should not automatically be trusted. They should be allowed only with the same security inspection applied to any other request.
AI Is Not Only Changing Search. It Is Changing Attacks
AI is enabling attackers to create bots that learn from mitigation controls, adapt their tactics, and persistently probe applications in ways that were previously impractical at scale.
According to Imperva’s 2026 Bad Bot Report, the average number of AI-driven bot attacks has increased more than tenfold (12.5x) in 2025 compared to the previous year. This growth reflects a broader trend: the same technologies helping AI assistants understand websites can also help malicious actors understand application defenses, automate reconnaissance, and accelerate attack development.
Beyond increasing the scale and sophistication of bot attacks, AI is also lowering the barrier to entry for attackers. With the right prompts, common AI assistants can be weaponized to help identify weaknesses in web applications, generate attack payloads, automate vulnerability discovery, and assist with exploiting business logic flaws. While these tools have safeguards, they can still ramp up activities that traditionally required specialized security knowledge.
AI is also enabling attackers to coordinate large-scale campaigns more efficiently, combining reconnaissance, automation, and exploitation in ways that were previously more resource-intensive and time-consuming.
As a result, organizations must consider not only how AI systems access their applications, but also how AI may be used to automate, scale, and weaponize traditional web attacks.
What we see in real traffic
Thales’s threat research data shows that legitimate AI bots currently account for around 2% of total session traffic. The Bad Bot Report shows that within that AI bot traffic, 85% comes from AI crawlers and 15% comes from AI fetch bots. While AI traffic remains a relatively small proportion of overall web traffic today, its growth rate and increasing sophistication suggest it will become a much larger consideration for application owners over the coming years.
This matters because even legitimate AI bots can introduce operational, security, and business risks.
The main risks are:
Data scraping: AI bots may continuously collect proprietary content, product data, documentation, or intellectual property.
Unintentional overload:: AI bots can be aggressive. High-speed crawling may consume bandwidth, slow the application for real users, and increase infrastructure costs.
Abuse through AI fetch bots: because fetch bots act on user prompts, attackers may try to manipulate them into sending malicious requests or scanning for weaknesses while appearing to come from a legitimate AI source.
The good news is that classic application attacks from legitimate AI bots remain relatively low. Imperva’s findings show low levels of traditional attack vectors such as SQL injection, cross-site scripting, illegal resource access, backdoor attempts, and remote file inclusion. However, there are still real examples where AI fetch bots were manipulated into sending malicious payloads, including SQL injection-style input.
This is exactly why AI bot policy should never be based only on identity. Even a legitimate AI bot must still be inspected for malicious behavior.
Visibility Must Be Paired with Control
Visibility is only the first step. As AI traffic continues to grow, organizations need the ability to distinguish between beneficial AI activity and behavior that introduces operational, security, or business risk.
AI search bots, AI training bots, AI fetch bots, and agentic AI systems all require different treatment. The challenge is not simply identifying them. It is applying the right controls to the right AI traffic at the right time.
This is where advanced bot management becomes critical.
A safe AI bot policy should not be “allow everything”
Public content you want AI systems to understand
Examples: blogs, product pages, public documentation, company information, support articles, and thought leadership.
Content you may want to restrict
Examples: premium content, customer-only portals, pricing logic, internal search, account pages, sensitive documentation, APIs, and dynamic application flows.
Content that should never be accessed by bots
Examples: admin paths, login actions, checkout abuse paths, personal data, private files, and application endpoints that can trigger expensive actions.
Then decide which AI bot categories should be allowed in each zone.
A practical policy could look like this:
Bot type
Recommended approach
AI search bots
Allow on public content where visibility matters
AI training bots
Review carefully; block or limit where IP protection matters
AI fetch bots
Allow only with full security inspection and rate controls
Unknown AI bots
Treat as suspicious until verified
Aggressive crawlers
Rate-limit or block if they impact performance
How Thales helps you stay visible and protected
The goal is not to trust or distrust AI traffic. The goal is to understand it, classify it, and apply the appropriate controls. Thales helps organizations strike the right balance between AI visibility and application security by combining Imperva Advanced Bot Protection, Imperva Web Application Firewall, and Imperva DDoS Protection. Thales offers customers a number of different options for managing AI bot traffic without choosing between full exposure and full blocking.
Firstly, Thales’ core security protections, delivered through Imperva Web Application Firewall, inspect the request itself. Rules for SQL injection, cross-site scripting, illegal resource access, backdoors, and remote file inclusion do not depend only on who the client claims to be. If an AI bot is manipulated into sending a malicious request, Imperva WAF can still block that request out of the box.
Secondly, Imperva DDoS protection helps reduce the risk of aggressive AI crawling overwhelming the application or creating performance issues. This is important because even legitimate AI bots can generate high request volumes.
Thirdly, customers can choose their own policy. If they want to allow a specific AI bot, using Imperva Advanced Bot Protection, they can create an exception based on the bot’s Client App ID. If they want to block a specific AI bot completely, they can add it to a bad bots list in the Imperva portal.
Most importantly, even when a specific AI bot is excluded from bot protection rules, malicious requests from that bot are still inspected by Imperva’s core security rules. In other words, allowing an AI bot for visibility does not mean you are leaving your application unprotected.
Frequently Asked Questions
Should you block all AI bots?
Not usually. Blocking every AI bot can reduce your visibility in AI-generated answers and recommendations, while allowing all of them exposes you to scraping, infrastructure overload, and abuse. The safer approach is to classify AI bots and allow them selectively, by website zone, with security inspection applied to every request.
What are the main types of AI bots?
There are four: AI search bots (so AI answer engines can understand your public content), AI training bots (which collect content to train AI models), AI fetch bots (which retrieve a specific page on behalf of a user), and agentic AI systems (which take actions such as logging in, querying inventory, or completing transactions).
What is agentic AI, and why is it a security risk?
Agentic AI systems act on behalf of users, browsing sites, filling forms, querying APIs, and running multi-step workflows with limited human input. Because they interact directly with business logic, the key question shifts from “is this bot legitimate?” to “should this action be allowed?”
How much web traffic comes from bots?
According to Imperva’s 2026 Bad Bot Report, automated traffic accounted for more than 53% of all web traffic in 2025. Legitimate AI bots are a small share of that today, around 2% of session traffic in Imperva’s threat-research data, but their volume and sophistication are growing quickly.
Can AI fetch bots be trusted?
Usually, but not blindly. Fetch bots typically act on a real user’s request, so they often carry legitimate business value. However, they can be manipulated into sending malicious payloads, so they should be allowed only with the same security inspection applied to any other request.
Quick answer: No single tool secures an API. API security is a layered discipline. Secure-coding analyzers and SCA scanners catch code and dependency flaws; DAST tests running APIs; API gateways and IAM enforce authentication and rate limits; a WAF blocks known attack patterns; bot management stops automated abuse; and runtime API security adds continuous discovery and catches business-logic threats like BOLA that other tools miss. This guide maps these API security tools to seven risk domains so you can see your coverage—and your gaps.
APIs power mobile apps, partner integrations, cloud microservices, SaaS platforms, and AI services; they are the business.
According to Imperva’s State of API Security report, API traffic now accounts for over 71% of all web traffic. As APIs have exploded in number and importance, so has the challenge of securing them.
When organizations look for “API security,” they quickly face a confusing mix of tools:
Secure coding analyzers
Dependency scanners
CI/CD testing platforms
Network firewalls
Web application firewalls (WAF)
API gateways
Identity and access management (IAM) systems
Bot management platforms
Dedicated API security solutions
Each tool does protect APIs, but only in its own narrow way.
API security is not a single product. It is an architectural discipline that spans the entire API lifecycle: from design to code, deployment, runtime, and monitoring.
This blog cuts through the noise. It shows exactly which risks each security component addresses, and where the gaps remain, so you can build a complete, layered defense.
The API Risk Landscape
API risks don’t come from one place. They appear at every stage of the software lifecycle. Here are the seven core risk domains you must understand:
Why This Landscape Matters
Real breaches almost always happen when risks from multiple domains line up.
Example:
A valid token (authentication risk) + excessive data exposure (design risk) + an exposed endpoint (configuration risk) + automated enumeration (abuse risk) = a major breach.
No single tool covers every domain. That’s why a layered approach is essential.
Security Components in the API Security Stack
Enterprise API protection never comes from one product. It’s a combination of tools working in different layers. Here’s what each major component does:
Mapping Security Components to API Risk Domains
Here’s a clear, at-a-glance view of what each component covers:
Security Component
Design
Code
Supply Chain
Config
Auth
Abuse
Logic
SAST
SCA
DAST
WAF
API Gateway
IAM
Bot Manager
Runtime API Security
Legend
= Strong / primary coverage
= Partial or indirect coverage
= No meaningful coverage
What Runtime API Security delivers
Design: Detects undocumented APIs and excessive data exposure (but doesn’t fix the original spec).
Code: Spots exploit attempts in live traffic (but doesn’t scan source code).
Supply Chain: No visibility into libraries or CVEs.
Configuration: Identifies exposed or misbehaving endpoints.
Authentication & Access: Catches misuse and authorization anomalies.
Automation & Abuse: Detects patterns (often works alongside bot management).
Business Logic: This is its superpower, behavioral analysis, object-level authorization monitoring, and detection of low-and-slow attacks that no other tool sees.
Quick takeaway on Runtime API Security
It shines brightest in Business Logic (its real superpower) and gives helpful visibility across most other domains, but it still works best alongside the other tools. Solutions like Imperva API Security from Thales are built specifically for this layer.
Final Thought
Building Your Layered API Security Strategy
API security isn’t about buying one magic product. It’s about understanding the full risk picture and picking the right tool for each layer.
Next Steps
Map your current tools against the 7 risk domains using the matrix above.
Spot the gaps—especially in Business Logic & Behavioral Risks, where the most damaging attacks hide.
Layer specialized coverage where needed. Imperva offers a strong, integrated portfolio, including industry-leading Runtime API Security, WAF, Bot Management, and API Gateway capabilities, that helps close multiple gaps with one cohesive platform.
Take the next step today. Review your API inventory, run a quick gap analysis, or contact your security team / Imperva/Thales’s representative for a tailored assessment.
Organizations that treat API security as an architectural discipline, not a checkbox, are the ones that move fast and stay secure.
Frequently Asked Questions
What tools are used for API security?
There is no single API security tool. A complete stack layers several: secure-coding analyzers (SAST) and software composition analysis (SCA) for code and dependency flaws, DAST for testing running APIs, API gateways and IAM for authentication and rate limiting, a WAF for known attack patterns, bot management for automated abuse, and runtime API security for discovery and business-logic threats such as BOLA.
Is a WAF enough to secure APIs?
No. A WAF blocks known attack patterns at the edge, but it cannot see business-logic abuse like Broken Object Level Authorization (BOLA) and does not discover shadow or undocumented APIs. Imperva’s research notes that traditional tools such as a WAF struggle to detect API business-logic abuse, so runtime API security is needed alongside it.
What is runtime API security?
Runtime API security continuously discovers every API—including shadow and deprecated endpoints—monitors live traffic, and uses behavioral analysis and object-level authorization checks to catch business-logic attacks, including the low-and-slow threats other tools miss.
What are the main API security risks?
API risk spans seven domains across the lifecycle: design and specification, code-level, third-party and supply chain, deployment and configuration, authentication and access, automation and abuse, and business logic and behavioral risks. Most breaches happen when risks from several domains line up at once.
On May 24, 2026, Imperva observed exploitation attempts against Laravel Livewire applications, blocked by the Imperva Cloud WAF. What initially appeared to be unremarkable deserialization attack traffic turned out to be part of a large-scale credential theft operation exploiting CVE-2025-54068, a critical unauthenticated RCE vulnerability in Laravel Livewire v3 (versions up to v3.6.3).
The campaign, first documented here, has been running for several months, as evidenced by the large volume of stolen data. Recovery and analysis of the attacker’s exfiltration infrastructure revealed credentials harvested from 6,167 distinct applications spanning dozens of countries and sectors, from e-commerce and healthcare to financial services, education, and government. The attacker’s FTP server contained 1,851+ database dumps and 18+ email lists with over 26 million addresses, indicating the stolen credentials were being actively exploited. Attribution indicators throughout the malware and associated infrastructure point to an Indonesian-origin threat actor.
Attack Vectors and TTPs
Initial Access: CVE-2025-54068 Exploitation
CVE-2025-54068 is a critical vulnerability in Laravel Livewire v3 caused by improper validation of component property updates during the framework’s hydration process. When a Livewire component state is restored from a browser request, Livewire v3 (up to v3.6.3) fails to verify the integrity of the submitted data before deserializing it. An unauthenticated attacker can inject a malicious serialized PHP object into this request, triggering arbitrary code execution on deserialization.
The following HTTP request, reconstructed from our captured attack traffic, illustrates the exploitation:
For full technical details on this vulnerability, please see the disclosure here.
Payload Analysis
The exploitation requests we captured contained serialized PHP objects constructed using PHPGGC gadget chains. These chains abuse legitimate PHP classes already present in Laravel applications to achieve code execution during deserialization. The attacker’s payload executes the following command:
This fetches a shell script from the attacker’s C2 server and pipes it directly into bash, executing it in the background with all output suppressed.
Malware Analysis
The credential stealer deployed in this campaign is a 5,269-byte Bash shell script named shoc.enz (SHA256: 548c3672fd3201dab56f714fdd5812bb024980815b3a2b6299f0126bdf16fb3e). At the time of our analysis, this sample was not present in VirusTotal.
Execution Flow
The malware follows an eight-stage execution process:
Environment Setup: Creates a temporary working directory at /tmp/xxxxx
Process Check: Verifies no existing shoc.sh processes are running to prevent multiple instances
File Discovery: Recursively scans the entire filesystem for .env files using the find command
Credential Extraction: Parses discovered files for DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD, and APP_KEY values
Data Collection: Copies matching files to a staging directory with randomized filenames
Compression: Archives collected files using zip or tar.gz
Exfiltration: Uploads archives to three separate C2 channels
Cleanup: Deletes the local staging directory to remove forensic evidence
Exfiltration Infrastructure
The threat actor operates a redundant three-channel exfiltration system:
Channel
Endpoint
Purpose
Primary
FTP @ 47.129.100.149:21
Main credential storage
Secondary
api.telegram.org
Notifications and small file uploads
Tertiary
upload.gofile.io
Backup cloud storage
Our investigation confirmed active access to all three channels. The FTP server contained 7 directories of stolen data, including full database dumps such as FULL_DUMP_[REDACTED_IP]>_2026-04-29_0418.sql.gz. The GoFile account showed owner-level access with 11,179 files totalling 309.9 MB.
Attribution Indicators
Multiple indicators point to an Indonesian-origin threat actor: Indonesian-language comments in the malware source code, a timezone reference to Asia/Jakarta, and the Telegram handle @ashtarotz (“黐線佬 Wong Gen Deng”) linked to xantibot[.]pw, a domain that presents publicly as a legitimate anti-bot service while hosting the malware payload. Analysis of the domain, and telegram channel metadata also point to Indonesian origin.
The GoFile exfiltration account was registered to azrilsyahputra1337@gmail[.]com. Cross-referencing this address against public breach data reveals it appears in three separate historical breaches of BreachForums (November 2022, August 2025, and March 2026), placing the operator within underground breach communities over an extended period.
What Was Stolen: Analysis of the Recovered Data
Laravel applications store all sensitive configuration in a single .env file: database credentials, API keys, payment processor secrets, cloud access keys, and encryption keys. This makes the file an exceptionally high-value target. A single .env file can provide everything needed to access the application’s database, impersonate users, process payments, and access cloud infrastructure.
Analysis of the recovered collection revealed credentials from 6,167 distinct applications. Of 21,916 unique files analysed, 29% declared a production environment, though the true proportion is higher as many files labeled local contained live payment keys and real domain URLs.
The breakdown of exposed credentials:
Credential Type
Count
Database passwords (real, non-default)
14,566 (66.5%)
Production applications with DB credentials
5,784
Confirmed live Stripe secret keys (sk_live_)
188
Valid AWS IAM credentials (AKIA format)
381
JWT secrets
2,929
Google OAuth client secrets (GOCSPX-)
2,409
Filament admin panel passwords
2,232
SMTP passwords
7,176 (32.7%)
The FTP server contained over 1,850 full database dump files, confirming the stolen credentials were actively used to extract database contents.
Targeting
The campaign scanned for vulnerable Laravel installations indiscriminately, with victims spanning online gambling and betting (400+ platforms, predominantly Brazilian and Southeast Asian operators), e-commerce, healthcare, education, logistics, and financial services. Multiple confirmed .gov domains were present in the dataset, showing the scanner made no distinction between commercial and public-sector targets. Recognizable open-source Laravel applications were present in the dataset, including the invoicing platform Invoice Ninja, accounting software Akaunting, event ticketing platform Attendize, photo gallery Lychee, and restaurant management system TastyIgniter. Applications were registered across .com, .ru, .site, .online, .br, .tr, .id, .ke, and dozens of other TLDs. Any organization running unpatched Laravel Livewire v3 was a potential victim.
Conclusion and Recommendations
This campaign illustrates how straightforward credential theft, when combined with a high-impact vulnerability and automated scanning, can scale to thousands of victims in a short window. Recovery of the exfiltration infrastructure revealed credentials from over 6,000 distinct applications, including 188 live Stripe payment keys, 381 valid AWS IAM credentials, and database passwords for nearly 5,800 confirmed production systems. For many victims, the initial server compromise is only the beginning of the exposure.
We recommend the following actions for defenders:
Patch immediately: Update Laravel Livewire to version 3.6.4 or later to remediate CVE-2025-54068. This is the single most effective mitigation.
Block outbound FTP: Production web servers should not require outbound FTP access. Block port 21 egress and alert on any connection attempts to 47.129.100.149.
Monitor for suspicious API access: Alert on connections from web servers to api.telegram.org and upload.gofile.io, which are atypical for production Laravel applications.
If you believe your organization has been compromised, rotate all database credentials and Laravel APP_KEY values immediately, and review database access logs for unauthorized activity.
Imperva Threat Research continues to monitor this campaign. Imperva customers are fully protected against exploitation of CVE-2025-54068. Customers requiring further guidance on this vulnerability are encouraged to contact Imperva support.
Quick answer: On-premises API security keeps API discovery, detection, and enforcement inside your own perimeter instead of a third-party cloud—the model regulated industries need. Deploying it natively on Kubernetes (sidecar sensors → a discovery controller → an inline WAF gateway) makes it practical: continuous API discovery surfaces shadow and zombie endpoints, behavioral detection catches API-specific threats like BOLA, and the WAF blocks them in real time.
Most security teams already know they need API discovery, including east-west traffic between internal services. That conversation has largely won. The harder question is: where do you actually deploy your API security solution?
For organizations in regulated industries, such as banks, healthcare systems, defense contractors, the answer isn’t straightforward. Data sovereignty requirements, compliance mandates, and network restrictions often rule out cloud-hosted security services. Your APIs run on-prem, so your API security has to run there too.
I spent years in application security before moving into product management, and one pattern kept repeating. Security teams have traditionally relied on preproduction security scanning and testing, which works well for known endpoints but inherently misses runtime security abuses, the shadow APIs, the undocumented endpoints, the services that only reveal their risk under live traffic. The coverage gap wasn’t a technology problem it was a deployment problem. The security tooling wasn’t running where the APIs were running.
That’s the problem this article is about. Not whether you need API security, you do. But how and where you deploy it, so it covers your full environment and increasingly, the answer is Kubernetes.
The API Security Gap That Nobody Wants to Admit
Once you’ve decided to deploy on-prem, the first thing that becomes clear is just how much of your API footprint was previously unaccounted for.
In my experience working with customers, teams often start out believing they have around 50 or 60 API endpoints. Once automated discovery runs against live traffic, that number frequently jumps to 300+. It’s not that anything was done wrong — those extra 240+ endpoints simply weren’t in any documentation or Swagger file. They were built for legitimate reasons, serving real traffic in production, but had never gone through a formal security review.
The real value of discovery is surfacing these blind spots not to assign blame, but to give security teams complete visibility so they can protect the full attack surface, not just the parts they already knew about.
Why Deployment Location Changes Everything
When API security runs externally or as a periodic exercise, you’re dependent on someone compiling a list of endpoints before anything gets scanned. That’s not a people’s failure it’s an architectural one. The security tooling isn’t sitting where the traffic flows, so it can only see what it’s told about.
Engineers focus on what they’re actively building. The endpoint they created eight months ago for a partner POC that never went anywhere? It’s not on their radar. The internal debugging endpoint that was supposed to be temporary? Still running. The v1 of an API that was “replaced” by v2 but never actually decommissioned? Still accepting requests.
The security team scans what they’re given. The audit report comes back clean. And everyone moves on, not realizing that the scan only covers 30% of the actual attack surface.
WAFs Are Essential but They Need the Right Intelligence
WAFs are the enforcement backbone. They sit inline, they can block traffic, and they’re battle-tested. That’s exactly what you want to stop threats in real time. The challenge isn’t the WAF itself; it’s what the WAF knows about.
A WAF is incredibly effective when it knows what to look for and where to look. But traditional WAF deployments rely on rules and signatures of SQL injection patterns, XSS payloads, and malformed requests. API-specific threats like BOLA (Broken Object-Level Authorization) don’t match those patterns. An attacker changes an object’s ID to access someone else’s data, and the request looks perfectly normal. Well-formed, authenticated, and syntactically valid. The WAF has no reason to flag it because it doesn’t have the API-level context to know that request shouldn’t be accessing that resource.
That’s where a dedicated API security layer becomes the WAF’s force multiplier. It provides the discovery, the behavioral analysis, and the API-specific threat intelligence. The WAF provides inline enforcement. Together, they form a closed loop: the API security platform detects, the WAF gateway blocks. Neither is complete without the other.
And both can only protect what they can see, which brings us back to why continuous API discovery matters so much. If an endpoint was never registered and never put behind the WAF, it’s completely exposed. Discovery closes that gap.
The Compliance Clock Is Ticking
This used to be a “nice to have” conversation. It’s not anymore. PCI DSS 4.0.1 now requires continuous API security testing and maintained API inventories. (These PCI DSS 4.0.1 requirements became mandatory on March 31, 2025.) The EU Cyber Resilience Act mandates security testing throughout the development lifecycle. ISO 27001:2022 introduced new application-security controls—including secure coding (A.8.28) and application security requirements (A.8.26)—that apply directly to APIs. If you’re in a regulated industry running on-prem APIs and you don’t have dedicated API security, your next audit is going to be uncomfortable.
Built for Kubernetes Infrastructure
Modern application environments are increasingly standardizing Kubernetes. It’s where workloads run, where infrastructure teams are investing, and where operational tooling is already mature. Our on-prem API security solution is purpose-built to deploy natively on this infrastructure.
Because it runs on Kubernetes, it inherits the operational benefits that teams already rely on pod-level self-healing for high availability, Helm-based deployments for consistent upgrades, and native integration with existing monitoring stacks like Prometheus, Grafana, or the ELK stack. There’s no separate HA architecture to build, no custom upgrade orchestration to maintain, and no new observability tooling for your SREs to learn.
For teams already running Kubernetes, adding API security to the cluster is operationally familiar. It fits into the workflows, tooling, and processes your infrastructure team already uses every day
What the Architecture Actually Looks Like
Here’s how architecture works in practice.
Continuous API Discovery
API discovery works through our lightweight sensors, deployed as Kubernetes sidecars alongside your application pods. These sensors passively mirror API traffic without adding latency or altering request flows and send the metadata to the API Security controller. The controller analyzes this traffic and continuously builds a complete inventory of every API endpoint in your environment, including REST, GraphQL, gRPC, and SOAP.
Because discovery is based on live traffic observation through the sensors rather than static documentation or manual reporting, it surfaces everything shadow APIs that were never documented, zombie endpoints that were supposed to be decommissioned, and internal services that no one remembered to put through a security review.
In my experience working with customers, teams that expected 50 or 60 endpoints routinely discover 300+. The discovery phase alone just seeing what you actually have justified the deployment for a lot of organizations. It’s the difference between securing a fraction of your attack surface and securing all of it.
Classification and Risk Scoring
Not every API carries the same risk. A health-check endpoint and a payment processing API are in different universes from a security standpoint. The platform classifies APIs based on what data they handle PII, financial data, credentials, health records and assigns risk scores. This is what keeps security teams from drowning in alerts. You focus on the endpoints that matter most.
Detection
The API security platform builds behavioral baselines for API usage and flags deviations. BOLA patterns. Schema violations. Unusual request volumes. Credential stuffing. Authentication anomalies. This is the intelligence layer it understands API-specific threats that signature-based rules alone can’t catch. But intelligence without enforcement is just expensive monitoring. That’s where the WAF gateway comes in.
Enforcement – The Detection-to-Blocking Loop
This is where our solution stands apart. The API security controller detects threats. The WAF gateway enforces inline. It’s a closed loop detection that intelligence feeds directly to the gateway, and the gateway blocks in real time. Neither layer is effective alone. The controller without the gateway can only be alert. The gateway without the controller only has signatures and static rules to work with. Together, you get detection depth and enforcement power.
We are the only solution on the market capable of this level of fine-grained blocking. And by fine-grained, we mean something very specific.
Most competing approaches block at the IP level attacker identified; entire IP blocked. In any real environment, API consumers share IPs constantly. Corporate NAT gateways, CDN exit nodes, partner integrations behind shared proxies. Block one IP and you cut off every legitimate consumer behind that address.
Our enforcement goes well beyond endpoint-level blocking. When the controller detects a threat to say, a BOLA attack doesn’t just block the endpoint or the source IP. It pushes a targeted rule to the WAF gateway that blocks the specific request pattern and the specific token involved. That means a malicious actor session gets shut down while other users hitting the same endpoint from the same IP continue uninterrupted. The blocking is surgical scoped to the exact behavior and identity, not the network address or even the endpoint as a whole.
This might sound like a subtle technical distinction, but in production it changes everything. It’s the difference between a security tool your operations team is confident turning on and one they keep in monitor-only mode because they’re afraid of the blast radius.
The Conversations This Solves
I’m framing these as actual conversations because that’s how they come up in practice.
“We don’t know how many APIs we have.” This is the most common starting point, and continuous discovery closes the gap immediately. Every endpoint serving traffic gets catalogued and classified, whether it’s in your documentation or not.
“Our WAF handles API security.” Your WAF is the enforcement engine, and that’s exactly the role it should play. What it needs is the right intelligence to feed it. A dedicated API security layer provides continuous discovery, behavioral analysis, and API-specific threat detection and routes that intelligence to your WAF gateway for inline blocking. Think of it as upgrading your WAF’s awareness, not replacing it.
“We can’t send traffic to a third-party cloud.” Then don’t. On-prem deployment keeps everything in traffic analysis, detection, enforcement, and reporting inside your perimeter. This is usually a non-negotiable requirement, not a preference for organizations in regulated industries.
“We need to prove compliance and we’re running out of time.” Continuous monitoring produces always-current audit evidence. API inventories, risk classifications, threat logs, and remediation records. It replaces the scramble of point-in-time assessments. I’ve watched teams go from dreading audits to walking in with dashboards. It changes the dynamic completely.
“Dev ships new APIs every week. Security reviews quarterly.” That gap is where unprotected APIs live. Automated discovery closes it. New endpoints get monitored the moment they start serving traffic.
Deployment Is Not the Hard Part
I want to spend a minute on this because there’s a perception that on-prem API security deployment is a multi-week project. In my experience, for teams that already have Kubernetes running, it’s measured in hours.
The typical flow:
Create a namespace in your existing cluster to isolate the security workload.
Set up a Persistent Volume 128 GB is a common baseline. This uses whatever storage backend your cluster already supports.
Deploy via Helm. One command. Configuration goes in a values file. Most solutions follow this model because it’s what Kubernetes teams already know.
Configure traffic ingestion on how the platform gets visibility into API traffic varies by solution, but the goal is the same: continuous observation of every endpoint in your environment.
Integrate with your inline enforcement layer, typically your WAF or API gateway. This is what closes the detection-to-enforcement loop, so threats get blocked in real time, not just logged.
Upgrades are the same model. Helm upgrade, new chart version, done.
For a detailed step-by-step installation walkthrough, refer to our deployment guide (available to Imperva customers)
The hard part isn’t deployment. It’s usually an organizational conversation about whether to do it in the first place. Once that decision is made, the technical execution is straightforward.
Where This Is Heading
API-first architecture isn’t slowing down. If anything, the pace is accelerating in exactly the environments that have the strictest infrastructure constraints of financial services, healthcare, government, critical infrastructure. These organizations need API security that respects their boundaries, not one that asks them to relax those boundaries.
Kubernetes gives you the operational foundation. Purpose-built API security gives you visibility, detection, and enforcement. Together, they deliver a security posture that keeps up with how fast your team ships.
And it all runs inside your own perimeter. Which, for a lot of the teams I work with, is the only answer that matters.
API security has moved from “nice to have” to “audit requirement.” If your APIs run on-prem, your security needs to run there too. Kubernetes makes that operationally viable. The question isn’t whether to do it. It’s how soon.
Frequently Asked Questions
What is on-premises API security?
On-premises API security runs API discovery, threat detection, and enforcement inside your own data center or private cloud instead of sending traffic to a third-party SaaS. It keeps all API traffic, logs, and analysis within your network perimeter—often a hard requirement for banks, healthcare, government, and other regulated organizations with data-sovereignty and compliance constraints.
Can you run API security on Kubernetes?
Yes. A Kubernetes-native API security platform deploys as lightweight sidecar sensors next to your application pods, feeding mirrored traffic to a controller that builds a live API inventory across REST, GraphQL, gRPC, and SOAP. Because it runs on Kubernetes, it inherits pod-level high availability, Helm-based upgrades, and integration with monitoring stacks like Prometheus and Grafana—so adding it to an existing cluster typically takes hours, not weeks.
What is a shadow API?
A shadow API is an endpoint serving live traffic that is not in any documentation, Swagger file, or official inventory—often an old version, partner integration, or internal debugging endpoint that was never decommissioned. Continuous, traffic-based API discovery surfaces shadow (and “zombie”) APIs so security teams can protect the full attack surface, not just the endpoints they already know about.
Login
