Cloud has transformed how organizations build, deploy, and scale applications. It has also changed what they expect from security.

Through our work with AWS, Google Cloud, and other hyperscaler partners, we’ve had the opportunity to learn from organizations operating some of the most modern and complex cloud environments. While every organization takes a different approach to cloud adoption, customers consistently highlight a common set of expectations that are shaping the future of cloud security. That work took two significant steps this year with the launch of Imperva for Google Cloud in April and Imperva for AWS in August, both designed to keep traffic inside the cloud provider’s own network while it is inspected.

To explore those expectations further, I spoke with Eyal Cohen, Manager of Product Management for Application Security, whose team works closely with our hyperscaler partners and customers.

“The biggest thing we’ve learned is that customers don’t think in terms of security products anymore. They think about how security fits into the way they build and operate in the cloud. If security creates friction, they’ll look for another way.”

Eyal Cohen, Manager of Product Management, Application Security

Working closely with hyperscale cloud providers isn’t just about expanding routes to market or supporting new deployment models. It provides valuable insights into how cloud teams operate, the challenges they face, and what they expect from the technologies they rely on every day.

Three of those expectations come up in nearly every conversation.

Lesson 1: Customers expect consistent security outcomes, regardless of where applications run

For years, security strategies often assumed that consistency came from standardization. If environments looked the same, security would be easier to manage. Modern cloud organizations have shown that assumption no longer holds.

Applications now run across different cloud providers, environments, private infrastructure, and on-premises systems. These choices are usually deliberate. Different teams, applications, and business requirements demand different architectures. Customers are not looking for identical environments. They are looking for confidence that security outcomes remain consistent across them.

Multi-cloud security is the practice of applying one set of policies, controls and visibility to applications spread across two or more cloud providers and, for most organizations, across hybrid cloud and on-premises infrastructure as well. The infrastructure is plural by design; the security outcome has to be singular.

The question is no longer whether every workload runs on the same platform. The question is whether organizations can achieve the same level of visibility, governance, protection, and risk management regardless of where workloads reside.

This expectation spans the entire organization. CISOs need a consistent view of risk across the business. Cloud architects need the flexibility to support different technology choices without creating fragmented security models. AppSec and SecOps teams need consistent policies, controls, and visibility across environments. DevOps teams need security that follows applications without introducing new processes every time infrastructure changes.

One of the clearest lessons we’ve learned from cloud customers is that architectural diversity is becoming normal. What matters is not where applications run, but whether organizations can deliver consistent security outcomes wherever they run. The infrastructure may vary. The security outcome should not.

This is the principle behind how Imperva builds for hyperscaler environments. The same Web Application Firewall, API Security and Advanced Bot Protection run from one platform across public cloud, private cloud, hybrid and on-premises environments. Imperva for AWS deploys inline with Amazon CloudFront in minutes, inspecting traffic inside AWS before it reaches origins such as an Application Load Balancer or EC2, with no architectural changes. Imperva for Google Cloud integrates directly with Google Cloud Load Balancers through Service Traffic Extension, with no DNS changes, SSL reconfigurations or routing modifications. One policy set and one console, whichever cloud the application runs in.

Lesson 2: Customers expect security to fit the way they already work

Security initiatives often struggle for a simple reason: they ask engineering and operations teams to change how they work. Modern cloud teams already use Kubernetes, Infrastructure-as-Code, CI/CD pipelines, cloud-native services, and automated workflows. If adopting a security solution means redesigning an application, disrupting a pipeline, or introducing a parallel set of manual processes, consistent adoption becomes much harder. It is the same disconnect we described in Securing Applications Anywhere: Breaking Down the Wall of Confusion.

The impact spreads across the organization: architects get more complexity, DevOps teams face disruption to established processes, and AppSec and SecOps teams gain another tool and workflow to manage. CISOs may invest in a capability that is never adopted broadly enough to deliver the intended reduction in risk.

Security cannot sit outside the cloud operating model. It must integrate with the architectures, services, and workflows customers already use. That applies to deployment as much as day-to-day operation. Infrastructure-as-Code and automation are now standard practices for many cloud teams. Security must become part of those repeatable processes rather than depend on separate, manual tasks.

The strongest security does not force teams to choose between protection and operational efficiency. It makes protection part of how they already work.

That is why Imperva treats automation as a first-class deployment path rather than an afterthought. Imperva’s Terraform provider lets teams define Cloud WAF protection as code alongside the rest of their infrastructure. Imperva for Google Cloud is API-first and integrates with Terraform and existing DevOps workflows. And Imperva Elastic WAF deploys on Kubernetes, so protection ships inside the CI/CD pipeline rather than around it.

Lesson 3: Customers expect security to be easy to adopt, operate, and scale

Effective protection remains fundamental, but customers increasingly evaluate security across the entire lifecycle: how easily it can be evaluated, purchased, deployed, operated and scaled as requirements evolve.

Every stakeholder experiences that friction differently. CISOs need confidence that security investments will be adopted broadly enough to deliver meaningful risk reduction. Cloud architects need solutions that integrate cleanly with existing environments rather than creating new technology silos. DevOps teams want deployment models that align with automation, Infrastructure-as-Code, and existing delivery pipelines. AppSec and SecOps teams need strong protection without adding significant operational overhead.

Cloud marketplaces are one example of how customer expectations are changing. They can simplify procurement and help align security investments with existing cloud commitments. However, customers increasingly expect simplicity across the entire journey, from evaluation and deployment through day-to-day operations and long-term scale.

Imperva for AWS is available on AWS Marketplace as a SaaS offering with pay-as-you-go pricing, and Imperva for Google Cloud is available through Google Cloud Marketplace, so both can be procured alongside existing cloud commitments. Each deploys in minutes without architectural changes and is managed from the same console as every other Imperva-protected application. That is what turns “easy to adopt, operate and scale” from a slogan into a deployment plan.

The same principle applies at every stage. Security that is difficult to evaluate, deploy, operate, or scale will struggle to gain traction, regardless of its technical capabilities. The solutions most likely to succeed are the ones that fit naturally into how organizations already work.

When friction prevents security from being adopted consistently, it becomes more than an operational challenge. It becomes a security challenge.

Looking ahead

The most important lesson from working with cloud customers hasn’t been about any individual product, feature, or integration. It’s been understanding how expectations are evolving.

Modern cloud organizations expect consistent security outcomes regardless of where applications run. They expect security to fit naturally into the architectures and operating models they’ve already built. And they increasingly expect experiences that make security easy to adopt, operate, and scale.

As cloud environments continue to evolve, our focus is on helping customers maintain consistent security outcomes without limiting how or where they choose to build. Security should adapt to the realities of modern cloud operations, not require organizations to adapt to security.

That means helping customers protect applications across diverse environments, integrate security into existing workflows, and reduce the friction that can slow adoption and innovation.

The lesson isn’t that every organization should follow the same cloud strategy. It’s that regardless of the platforms, architectures, or operating models they choose, security should help them achieve the outcomes they need with the flexibility they expect.

“The cloud journey is still evolving, and so is security. By working closely with leading cloud providers and listening to the organizations using them every day, we’re continually learning what it takes to deliver security that supports innovation rather than standing in its way.”

– Eyal Cohen

Find out more about Imperva for Google Cloud and Imperva for AWS. Read the launch announcements: Thales Introduces Imperva for Google Cloud and Thales Launches Imperva for AWS. Running on Azure, in a private cloud or on-premises? The same protection is available through Imperva Web Application Firewall.

Multi-Cloud Security FAQ

What is multi-cloud security?

Multi-cloud security is the practice of applying consistent protection, visibility and policy to applications and APIs that run across more than one cloud provider, and usually across hybrid and on-premises infrastructure as well. The goal is the same security outcome regardless of where a workload runs, rather than a separate toolset and policy for each environment.

What are the biggest multi-cloud security challenges?

The challenges customers raise most often are fragmented visibility (a different console and policy per cloud), inconsistent controls that leave gaps between environments, security that does not fit Infrastructure-as-Code and CI/CD workflows, and the operational overhead of evaluating, deploying and scaling a separate solution in each cloud.

How does Imperva deliver consistent security across AWS, Google Cloud and on-premises?

Imperva delivers WAF, API Security and bot protection from one platform and one console. Imperva for AWS inspects traffic inline with Amazon CloudFront, Imperva for Google Cloud integrates with Google Cloud Load Balancers through Service Traffic Extension, and the same protection is available for private cloud and on-premises applications, so one policy applies everywhere.

Can Imperva be purchased through cloud marketplaces?

Yes. Imperva for AWS is available on AWS Marketplace as a SaaS offering with pay-as-you-go pricing, and Imperva for Google Cloud is available through Google Cloud Marketplace, which helps align security purchases with existing cloud commitments.

The post Three Lessons Cloud Customers Have Taught Us About Multi-Cloud Security appeared first on Blog.

Following the public disclosure of PHP2Shell (CVE-2026-109618 and CVE-2026-109619), Imperva Threat Research observed a sharp increase in scanning and exploitation attempts across protected environments. What had been a small number of unsuccessful probes before disclosure quickly grew into widespread automated activity targeting sites across industries and regions. 

Before public disclosure, Imperva participated in the coordinated disclosure process with Wiz, OpenAI, and Calif. The researchers shared confidential vulnerability details, enabling us to assess existing protections, develop dedicated detection and mitigation rules, and prepare diagnostic testing against proof-of-concept exploits. 

Our involvement began with a confidential briefing from Wiz on October 12. We deployed dedicated monitoring rules that same day and refined them as our analysis progressed. When PHP announced the lifting of the embargo on October 21 at 13:38 UTC, Imperva immediately enabled the full set of PHP2Shell protection rules. Existing protections had already covered the early probing attempts. 

Below, we trace the disclosure and attack timeline, then examine the scale, targeting, and client behavior observed during the first 24 hours of activity. 

The First 24 Hours in Numbers 

During the first 24 hours of observed activity, Imperva recorded: 

• 482,342 requests 
• 122,311 attack sessions 
• 21,998 targeted sites
• 103 targeted countries 

The activity was broad but relatively shallow: each attack session contained approximately 3.9 requests, and targeted sites received an average of nearly 22 requests during the observation period. This pattern is consistent with opportunistic spray-and-pray scanning, in which attackers probe many sites for potentially vulnerable deployments. 

These figures describe observed traffic and targeting. They do not represent confirmed successful exploitation or compromised sites. 

How the Activity Developed 

The aggregate figures show the scale of targeting, while the hourly distribution shows how quickly activity intensified. The chart below traces observed request volumes alongside key disclosure and patch-release milestones. 

Figure 1: PHP2Shell-associated requests by hour, with disclosure and patch-release milestones. All times are UTC. 

Following the initial increase, request volume rose sharply and reached a pronounced peak before declining. Activity continued after the peak, with several smaller spikes during the remaining observation period. 

This pattern is consistent with an initial burst of automated scanning and exploitation attempts followed by continued activity at lower volumes. The timing alone does not establish what triggered each spike or whether the requests came from the same tools or actors.  

Targeting Concentrated in the United States 

Sites in the United States accounted for 64.5% of targeted sites, making it the clear center of the observed activity. Indonesia was the second-most targeted country, followed by Australia, Germany, and the Brazil. 

Despite this concentration, associated activity reached sites across 103 countries within 24 hours. The geographic distribution shows how quickly scanning and exploitation attempts spread beyond a single region once vulnerability details became public. 

These percentages reflect the distribution of targeted sites within Imperva’s observations. They do not, by themselves, establish a deliberate attacker preference for particular countries. 

Education and Financial Services Lead Industry Targeting 

The activity reached organizations across a wide range of industries. Business accounted for the largest share of targeted sites at 34.3%, followed by Education and Financial Services. 

The distribution shows that targeting was not limited to sectors traditionally associated with high-value financial or government data. Instead, activity extended across industries likely to operate large or publicly accessible PHP environments. 

Automation Drives Early Activity 

The clients associated with the traffic further support an assessment of heavily automated activity. Almost half of the observed activity came from clients classified as browser impersonators, which present themselves as legitimate browsers. Most of the remaining activity was split between known bots and clients using the Go HTTP library. 

The prominence of browser impersonation suggests that many of the tools generating this traffic were designed to blend into normal web activity. At the same time, the substantial use of Go-based clients is consistent with purpose-built, high-speed tooling used to scan large numbers of targets. 

Imperva Customers Remain Protected 

As detailed in our initial analysis, Imperva Cloud WAF customers are protected against PHP2Shell out of the box. Elastic WAF customers receive protection following the applicable software update. WAF Gateway customers receive protection following the applicable software and ADC security-content updates. 

Existing protections covered the early unsuccessful probing attempts. Imperva also developed and refined dedicated PHP2Shell rules before public disclosure, enabling the full set immediately after the embargo was lifted. 

Organizations should apply the relevant PHP security updates to remediate affected deployments. WAF protections provide a compensating control while that remediation takes place. 

Imperva Threat Research continues to monitor PHP2Shell activity and refine protections as scanning tools, exploitation techniques, and attacker behavior evolve. These findings capture the first 24 hours of observed activity; the volume and distribution may change as further activity emerges. 

The post PHP2Shell: Early Attack Activity Through Imperva’s Lens appeared first on Blog.

Imperva Red Team demonstrated remote code execution against the official vulnerable Node.js build, then confirmed that the fixed release rejects the same Brotli input.

Executive summary

Node2Shell is Imperva Red Team’s name for our analysis of CVE-2026-111497, a High severity flaw in Node.js’s bundled Brotli decoder. Node.js says the out-of-bounds write can permit remote code execution and has released fixes for the 22.x, 24.x, and 26.x lines.

Our standalone proof of concept ran code carried in a Brotli response or request body inside applications using the official Node.js 24.22.0 Linux arm64 image. It needed no debugger or instrumented binary. The same inputs were rejected by 24.22.1. We tested Express 5.0.0–5.3.0 and body-parser 2.0.0–2.3.0, including the latest releases available at testing; execution took multiple attempts in our setup.

Imperva has added WAF rules for CVE-2026-111497. Customers should update affected Node.js deployments to a fixed release.

Overview

A Node.js service can encounter Brotli on either side of an HTTP exchange. It may consume a compressed response from another server, or use middleware to decode an incoming request body. Both operations can send untrusted data into the native decoder bundled with Node.js. That shared path is where CVE-2026-111497 lives.

We built a standalone proof of concept to see whether the flaw could lead to code execution in a Node.js application. In fresh containers running the official vulnerable Node.js image, the application ran code supplied with the Brotli data. We used a memory sanitizer separately to investigate the underlying bug and compared the results with the fixed release.

The Node.js project disclosed the issue on October 21, 2026. Its advisory credits Matteo Collina with reporting it and Antoine du Hamel with the fix. Our work is an independent validation of the impact and the released patch.

Impact: From a decoder error to code execution

In the working proof of concept, the test application had no code to create our marker file. After it received the Brotli data, the file appeared. Code carried in that data had run inside the target process. We reproduced this with the official Node.js 24.22.0 image in fresh Linux arm64 containers. The same inputs on Node.js 24.22.1 were rejected and created no marker.

We also investigated the cause. A source comparison showed that the vulnerable decoder could continue past an invalid stream condition. In a separate sanitizer test, decoding that condition caused an out-of-bounds write. The sanitizer helped explain the flaw; it was not needed for the code-execution proof.

We tested both a compressed response consumed by Node.js’s built-in fetch() and incoming Brotli bodies handled by configured request parsers. The table shows the Brotli-capable package ranges represented by our pinned endpoint tests:

Application path	Package range and tested configurations	Node.js 24.22.0	Node.js 24.22.1
Consumed HTTP response	Node.js built-in fetch()	Supplied code ran; marker created	Input rejected; no marker
Incoming request body	Express 5.0.0–5.3.0; tested 5.0.0 with body-parser 2.0.1, and 5.3.0 with body-parser 2.3.0	Supplied code ran with raw() and json() in both tested setups	Input rejected; no marker; server stayed running
Incoming request body	body-parser 2.0.0–2.3.0; tested 2.0.0 standalone and 2.0.1/2.3.0 through Express	Supplied code ran with raw() and json() in the tested setups	Input rejected; no marker; server stayed running

Express 5 documents Brotli decoding in its request-body parsers, and the body-parser release history records support beginning with 2.0.0. Express 5.3.0 and body-parser 2.3.0 were the latest releases when we tested on October 22, 2026. We reproduced execution at the listed versions; we did not individually test every intermediate release. The vulnerable code is in Node.js: these middleware versions identify paths that can invoke it. A bare Node.js HTTP server does not decode incoming Brotli bodies simply by receiving them.

The proof did not succeed on every attempt. Our results establish code execution for the tested Linux arm64 build and application setups, and show how the fixed build handled the same inputs. We did not test every Node.js build or application.

Technical deep dive: When invalid input looks incomplete

A Brotli stream describes the block types available as decoding progresses. Our test input reached a block transition that the stream’s own structure made impossible. In the vulnerable decoder, that condition could look like a request for more input. Processing continued with an invalid internal state.

Our separate sanitizer run showed that continuing from that state could write beyond an intended buffer. The upstream Brotli fix makes the decoder return a format error for the invalid transition and pass it to the caller. In our application tests, patched Node.js rejected the same inputs before code could run.

Two tested routes into the native decoder. The patched runtime stops at the invalid-format check.

The distinction matters for exposure. Express 5 and body-parser 2 can decompress incoming Brotli request bodies when their parsers are configured; they are routes into the vulnerable Node.js decoder, not the source of the flaw. On the response side, our test service consumed an external Brotli response with Node.js’s built-in fetch(). Both paths reach the same decoder.

What defenders should do

The priority is to replace affected Node.js runtimes. The project released fixes in 22.23.4, 24.22.1, and 26.12.1. Deploy these or newer fixed releases in each line, including in container images and other artifacts that bundle a Node binary. Move applications on unsupported Node.js lines to a supported release.

Then map where untrusted Brotli data reaches that runtime. Review compressed responses consumed by services and incoming request bodies inflated by configured middleware. Check the Node.js version inside each deployed image or host; a package inventory can miss an older runtime bundled in a container.

Where practical, temporarily limit untrusted Brotli traffic on affected paths while updates roll out. Test changes against the application’s normal traffic. Complete remediation requires updating Node.js.

Unexpected process exits during decompression and decoder errors may help prioritize investigation. Neither is a reliable stand-alone sign of exploitation; correlate them with the deployed runtime, application logs, and the source of the compressed data.

Imperva’s response and customer protection 

Imperva has added dedicated WAF rules in response to CVE-2026-111497 and validated them to detect and block the exploitation attempts we were able to reproduce. Customers should update affected Node.js deployments to a fixed release. The runtime update remediates the decoder flaw. 

Our tests covered both an incoming request parser and a consumed HTTP response. In both cases the affected code is the Node.js decoder, so the runtime update addresses the shared cause. 

Closing Thoughts 

Node2Shell and the recent PHP2Shell research highlight the risk hidden in the runtimes beneath everyday web applications. In PHP2Shell, researchers used AI to help uncover and exploit longstanding memory-safety flaws. Our Node2Shell tests demonstrated how untrusted compressed data could lead to code execution in an official Node.js build.  

AI can accelerate both vulnerability discovery and exploit development, helping researchers investigate flaws while lowering the time and effort attackers need to turn those flaws into working attacks. For defenders, that means less room to delay between disclosure and remediation. 

In our tests, the fixed Node.js release rejected the same inputs that achieved code execution on the vulnerable build. The immediate priority is to deploy that fix wherever applications decode untrusted Brotli data. The broader lesson is that patching speed must keep pace with the tools making exploitation faster. Web Application Firewalls can help bridge that gap through virtual patching, buying defenders critical time to deploy permanent fixes.

The post Node2Shell: From Brotli Data to Remote Code Execution appeared first on Blog.

A family of runtime memory safety vulnerabilities, with impacts ranging from worker crashes and data disclosure to pre-authentication remote code execution. 

Introduction 

Researchers from Wiz, OpenAI, and Calif jointly disclosed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), a set of memory safety vulnerabilities involving PHP’s session handling, OPcache class caching, and fatal-error backtrace generation. Successful exploitation can lead to full remote code execution in the affected PHP environment without authentication or user interaction. Other demonstrated effects include worker crashes, arbitrary file reads, and server-memory disclosure.  

When we think about memory-corruption vulnerabilities, we often picture bugs buried in complex application code. PHP2Shell is different: the vulnerabilities live in PHP’s own runtime, and several can be reached without the application itself doing anything wrong. In many cases, PHP2Shell exploits the timing of PHP’s response to memory exhaustion. Processing stops, but internal state is not always cleaned up consistently. Pointers or cache entries left behind can become accessible during subsequent processing, turning a failed operation into an opportunity for exploitation. In the session-related attacks the researchers demonstrated, an endpoint that does nothing more than echo “OK” can still be affected. The vulnerable processing happens before a single line of application code runs. 

PHP2Shell is believed to affect PHP versions dating back to PHP 5.4.0, although not every release has been individually tested and verified. With PHP used by over 69% of websites whose server-side programming language is known, the potential exposure is substantial. Organizations should consult the relevant security advisories for confirmed affected ranges and apply vendor-provided fixes as soon as possible. 

CVE Overview 

PHP2Shell encompasses two reported vulnerabilities involving PHP’s handling of abnormal request termination. Both are classified as CWE-824: Access of Uninitialized Pointer, carry a CVSS v4.0 score of 9.2 (Critical), and can lead to remote code execution without authentication or user interaction. 

CVE-2026-109618: Remote Code Execution via Memory Exhaustion 

PHP uses longjmp() to abort request processing when an out-of-memory (OOM) error occurs. Some execution contexts do not properly account for this interruption, leaving request memory in an uninitialized state. Subsequent request cleanup may read or branch on that memory. Multiple strategies for triggering memory exhaustion can consistently reach this condition and lead to remote code execution. 

Reported by: Calif, Wiz, OpenAI, and Quarkslab. 

CVE-2026-109619: Remote Code Execution via Fatal Errors 

PHP also uses longjmp() to abort request processing following fatal errors. Some execution contexts leave global state pointing to memory that is freed at the end of the request. Subsequent requests may read or branch on this invalid state, potentially leading to remote code execution through multiple triggering strategies. 

Reported by: Wiz, Calif, and OpenAI. 

It’s worth noting that the attack complexity in both vulnerabilities is high, which means that the attacker must overcome a built-in security protection for the exploit to work. Triggering the bug is much easier than turning it into code execution. Memory exhaustion can leave PHP holding a pointer to freed memory. A later request must reach the same Apache worker and place carefully shaped data into that freed space. If the timing or placement differs, the worker may crash or respond normally instead of executing a command. 

The Common Thread: Bailouts Leave Stale State 

PHP handles certain fatal conditions, including exceeding its configured memory_limit, through an internal mechanism known as a bailout. Rather than completing the current operation normally, PHP aborts it and transfers control to an error-handling boundary. 

The problem arises when that bailout occurs after PHP has published a pointer or allocated a cache slot, but before the corresponding cleanup or completion bookkeeping runs. The result is a partially initialized, or stale, state that remains accessible after the operation has failed. 

In worker-based deployments, including Apache prefork environment, a process can serve multiple requests. A subsequent request reaching the same worker may therefore encounter a pointer to memory that an earlier request has already freed. 

The OPcache finding involves a related but distinct problem: an abandoned class-cache slot in shared memory. Worker-local state and shared-cache state have different lifetimes, so the conditions required to exploit each finding must be assessed separately. 

Reaching the Runtime Before Application Code Runs 

Three of the five demonstrated exploitation techniques use PHP’s session upload-progress feature as a remote trigger. 

This feature updates session state while PHP parses a multipart request body, before the application begins executing. Crafted multipart requests can therefore influence session processing and memory consumption during this pre-application phase. 

In these attacks, memory exhaustion interrupts session processing at a point where cleanup is incomplete. Later processing on the same worker encounters the stale state, resulting in a crash or memory disclosure. 

This explains why an application does not necessarily need to implement vulnerable business logic to be exposed. However, it does not mean every finding affects every PHP endpoint: enabled features, application behavior, worker routing, and deployment configuration still matter. 

Exploitation Techniques  

Session Decoder Use-After-Free 

The session decoder finding involves bookkeeping used during session unserialization. PHP makes that bookkeeping accessible through module globals, but memory exhaustion can interrupt processing before it is properly cleared. 

The attack first builds a large session through the upload-progress mechanism, then forces memory exhaustion during session decoding. Request cleanup frees the underlying memory while leaving stale bookkeeping accessible. 

A subsequent request reaching the same worker uses the dangling context, resulting in invalid memory access and a worker crash. 

OPcache Stale Class-Cache Pointer 

The OPcache finding affects the persistence of compiled class information into shared memory. A memory bailout at a particular point leaves an allocated but unpublished class-cache slot behind. 

The attack manipulates later cache reuse and places crafted structures in request memory. A stale class lookup then interprets attacker-controlled data as PHP internal structures, influencing class constant resolution. 

In an application flow, a file operation using the affected constant is redirected to an attacker-selected path. This produces an arbitrary file read within the worker process’s access permissions. 

The practical consequences depend on what that process can read. Application configuration files, database credentials, API keys, and other secrets may be exposed, but the finding does not automatically grant access to every file on the host. 

Stale Session Module-data Pointer – Use-After-Free  

This finding affects the session handler state referenced by PHP’s internal pointer. 

Memory exhaustion during session handling leaves the pointer referring to freed memory. A follow-up request on the same worker influences subsequent memory allocation, and PHP later dereferences the stale pointer. 

Such an attack can produce a worker crash, demonstrating that invalid session state can remain reachable across requests. 

Stale Session-ID Pointer – Memory Disclosure 

The session ID finding follows a similar pattern but produces information disclosure rather than a crash. 

After memory exhaustion leaves stale session ID state, attacker-influenced memory is interpreted as a string with an oversized length. PHP then returns the resulting value through a Set-Cookie: PHPSESSID response header. 

An attack can expose approximately 67 KB of process memory. Its contents depend on the worker’s state at the time of exploitation and may include internal runtime data or sensitive information processed by the application. 

Fatal-Error Backtrace – Use-After-Free 

With fatal-error backtraces enabled, a fatal error can trigger a use-after-free during backtrace generation. The effect is a worker crash. 

This finding should be distinguished from the session upload-progress attacks. It requires the relevant backtrace setting and a fatal-error trigger; it does not share the same remote prerequisites as the three session findings. 

From Memory Corruption to Remote Code Execution 

The overall impact of PHP2Shell extends beyond service disruption and data disclosure. Successful exploitation can lead to remote code execution in the affected PHP environment. 

The individual findings demonstrate different ways that invalid runtime state can be accessed or influenced. Their standalone effects should be distinguished from the complete code-execution outcome. 

Code execution occurs within the security context of the compromised process. It does not automatically imply root access, but it can allow an attacker to access application data, modify resources available to that process, and pursue further compromise. 

Mitigation and Detection 

Applying vendor-confirmed PHP fixes is the primary remediation. Organizations should consult the relevant security advisories for confirmed affected ranges, fixed releases, and vulnerability-specific guidance. 

Where patching is delayed, organizations should assess temporary exposure-reduction measures: 

• Disable relevant PHP features where practical. After compatibility and performance testing, consider applying the following settings in the active php.ini file. These temporary measures target features used by the demonstrated exploitation techniques and should not be treated as complete workarounds for either CVE.
  • opcache.enable = 0 
  • session.upload_progress.enabled = 0

These settings disable OPcache and session upload-progress tracking, respectively. Disabling session upload-progress tracking removes the described trigger for three of the five reported exploitation techniques. These measures do not replace patching or establish that the environment is fully protected. 

• Review fatal-error backtrace configuration. Assess whether the relevant setting is enabled and follow vulnerability-specific guidance. 
• Restrict exposure where practical. Limit access to affected services while remediation is evaluated and deployed. 
• Apply least privilege. Restrict the PHP process’s access to files, credentials, and connected services to reduce the consequences of compromise. 

Security teams should correlate suspicious request activity with PHP memory-exhaustion errors and worker crashes. Investigation leads include unusually large multipart payloads, excessive field counts, anomalous session-related parameters, and unexpectedly large PHPSESSID response values. 

If exploitation is suspected, incident response should assess possible code execution as well as data disclosure. Review unexpected child processes, application-file changes, persistence mechanisms, unusual outbound connections, and potential credential exposure. 

Imperva’s Response and Customer Protection 

The researchers shared vulnerability details confidentially with Imperva ahead of public disclosure, enabling Imperva to verify its protection and begin monitoring customer traffic before the announcement. During this pre-disclosure monitoring period, Imperva observed no traffic matching the monitored PHP2Shell exploit patterns. 

Imperva Web Application Firewall provides a compensating control by inspecting request and response patterns associated with the demonstrated exploits, including anomalous multipart payloads, repeated session-related fields, abnormal response headers and suspicious session upload-progress activity. 

Imperva WAF solutions provide a virtual patch to organizations – Cloud WAF customers are protected against this vulnerability out of the box. Elastic WAF customers receive the same protection following a software update. WAF Gateway customers are protected following a software update and an ADC security content update. 

For more details, refer to the relevant release notes: 

WAF GW RN V14.7 LTS: https://docs-cybersec.thalesgroup.com/bundle/v14.7-waf-release-notes/page/83979.htm 

WAF GW RN V15.5 LTS: https://docs-cybersec.thalesgroup.com/bundle/v15.5-waf-release-notes/page/87153.htm 

Elastic WAF 2.2.1 RN: https://docs-cybersec.thalesgroup.com/bundle/elastic-waf/page/v2-2-1.htm 

Imperva provides a testing page where customers can enter their URL to receive an initial assessment. The result is preliminary and may require further analysis to confirm exposure.

Imperva’s Threat Research team continues to monitor traffic to determine whether additional protections are needed. 

Conclusion 

PHP2Shell highlights how a runtime’s handling of exceptional conditions can become a security boundary failure. When processing stops at the wrong moment, stale pointers and incomplete cache state can remain accessible beyond the operation that created them. 

The resulting impacts range from worker crashes and sensitive data disclosure to pre-authentication remote code execution. Organizations should identify affected deployments, apply vendor-confirmed fixes, reduce unnecessary exposure, and investigate suspicious activity for signs of both data access and code execution. 

The post PHP2Shell: When PHP Runs Out of Memory at the Wrong Moment appeared first on Blog.

Atlassian has released an out-of-band security advisory for CVE-2026-21589, a critical arbitrary file access vulnerability affecting a broad range of its Data Center products. The flaw carries a CVSS 4.0 score of 9.3 and can be exploited remotely without authentication or user interaction. Because vulnerable functionality is shared across the Atlassian product ecosystem, every previous version of the affected products is impacted.

An attacker who knows the exact name and path of a file can use the vulnerability to read it from within the affected application’s web root. The issue does not provide directory-listing or file-enumeration capabilities, but many Atlassian deployments follow predictable directory structures. This can make sensitive configuration files practical targets even without prior access to the system.

Atlassian released fixed versions on October 5, 2026, and urged Data Center customers to patch immediately. Atlassian Cloud environments have already been patched, and Atlassian said its investigation had not identified evidence of exploitation affecting Cloud customers at the time of disclosure.

What Is CVE-2026-21589?

CVE-2026-21589 is an unauthenticated path traversal vulnerability in Atlassian’s web-resource handling. Research traced the flaw to the shared atlassian-plugins-webresource component. Vulnerable code converts double-colon sequences (::) into forward slashes when resolving requested resources. In affected routes, crafted traversal sequences can pass through path-processing logic and reach files within the application server’s web root.

The attack does not require a valid Atlassian account. A remote attacker can submit a specially crafted HTTP request to a vulnerable instance and retrieve a file if its location is known. The technique has been demonstrated against Jira, Confluence, and Bitbucket, with product-specific request paths leading to protected files under the applications’ WEB-INF directories.

The direct result is unauthorized file disclosure rather than remote code execution. However, the practical impact depends heavily on the files stored in the web root and the way Atlassian products are integrated. Configuration files may contain credentials, internal service locations, or other information that enables further compromise.

From File Read to Administrative Access

Atlassian’s documented Jira–Crowd configuration stores the Crowd application name, application password, and server URL in WEB-INF/classes/crowd.properties. In a vulnerable and permissively configured deployment, an attacker could use CVE-2026-21589 to retrieve this file and obtain the credentials used by Jira to communicate with Crowd. The researchers showed that those credentials could then be used to interact with Crowd’s user-management API, create a user, and add that account to the jira-administrators group.

This escalation path is configuration-dependent. Crowd can restrict access by source IP, which may make direct use of leaked credentials more difficult. Even so, the demonstrated chain shows why a file-read vulnerability can have consequences well beyond the disclosure of application files: secrets exposed from one Atlassian product may provide a path into the identity layer shared by the wider environment.

Affected Atlassian Products and Fixed Versions

All versions released before the following fixed versions are affected:

Product	Fixed versions
Bitbucket Data Center	9.4.26, 10.2.8, 10.5.1
Confluence Data Center	9.2.26, 10.2.19
Jira Service Management Data Center	5.12.40, 10.3.26, 11.3.12
Jira Software Data Center	9.12.40, 10.3.26, 11.3.12
Bamboo Data Center	10.2.24, 12.1.12
Crowd Data Center	6.3.7, 7.0.3, 7.1.7, 7.2.4
Crucible	4.9.15
Fisheye	4.9.15

Atlassian recommends upgrading to one of the listed fixed releases or a later version. Organizations should verify every node in a clustered deployment, as well as Bitbucket mirrors and mirror-farm nodes where applicable.

What Imperva Is Seeing

Imperva telemetry shows that detection activity associated with CVE-2026-21589 has been heavily concentrated among targets in Singapore, which accounted for 86.8% of observed activity.

The telecommunications and internet service provider sector was the primary target, accounting for 68% of observed activity. The concentration in telecommunications and ISP environments is notable because Atlassian products frequently support internal development, operations, and service-management workflows in large, interconnected organizations.

Mitigation and Detection

Patching is the primary remediation. Atlassian advises customers to upgrade each affected installation to a fixed version or the latest available release. If patching cannot be completed immediately, Atlassian recommends removing affected instances from public internet access until a patch or temporary mitigation is in place.

For threat hunting, Atlassian recommends reviewing access logs for traversal sequences. Request lines should be URL-decoded up to two times before searching for .. adjacent to /, \, or ::. Security teams can also search decoded logs using the regular expression published in Atlassian’s advisory. Because exploitation requires a known path, requests referencing WEB-INF, web.xml, urlrewrite.xml, crowd.properties, or other sensitive application files warrant particular scrutiny.

Organizations using Crowd integrations should also consider the potential exposure of application credentials. If logs or other evidence indicate that a sensitive configuration file may have been retrieved, incident response should extend beyond patching the vulnerable Atlassian instance to include credential rotation, review of Crowd users and group memberships, and investigation of activity across connected products.

How Imperva Helps

Imperva Web Application Firewall helps identify and block malicious path-traversal requests before they reach vulnerable Atlassian applications. Its inspection of decoded and obfuscated request paths is relevant to CVE-2026-21589 because exploitation can use nonstandard separators and encoded traversal patterns to reach protected files.

Customers should still install Atlassian’s fixed releases as soon as possible. A WAF provides an important compensating control while upgrades are tested and deployed, but it does not replace remediation of the vulnerable software or investigation of possible earlier access.

Conclusion

CVE-2026-21589 combines a low-complexity, unauthenticated attack path with an unusually broad affected-product footprint. Although the immediate capability is limited to reading known files within the application web root, predictable file locations and shared credentials can turn that access into a much larger identity and administrative compromise.

While Imperva customers are protected out-of-the-box, all organizations running Atlassian Data Center products should treat the issue as an emergency: inventory affected installations, patch every node to a fixed release, apply Atlassian’s temporary mitigations where patching is delayed, and review historical access logs for traversal patterns and requests targeting sensitive configuration files.

The post CVE-2026-21589: Critical Pre-Authentication File Read Affects Atlassian Data Center Products appeared first on Blog.

Readiness is a visibility problem, and it’s one many organizations don’t know they have.

Most security controls tell you when they’re broken. A bad firewall rule lets traffic through that shouldn’t be there. An expired certificate generates alerts. A misconfigured WAF starts blocking legitimate users and someone notices pretty quickly.

DDoS protection is different. A service can be configured, licensed, and technically available, yet not actually be protecting your traffic. Worse, it often looks exactly the same as a fully functioning service until the moment an attack arrives.

That’s the challenge with DDoS readiness: confirming, continuously, that your traffic is actually flowing through your DDoS protection rather than assuming it is.

Attacks are loud. Protection gaps are silent.

DDoS readiness: why “protected” isn’t the same as “ready”

Ask an organization whether it’s protected from DDoS attacks and the answer is often based on two things:

• We have a DDoS protection service.
• It’s been configured.

Both may be true. Neither proves your traffic is actually protected. Readiness isn’t a checkbox. It’s an operational state that needs continuous validation. At Imperva, we view DDoS readiness through three simple questions:

1. Is traffic being advertised the way you expect?
2. Are the connections carrying protected traffic healthy?
3. Is traffic actually arriving where it should?

If you can’t answer all three, you’re making assumptions about your protection posture. That gap is behind many of the reasons DDoS protection fails just when it matters most.

This is different from DDoS testing. An attack simulation shows whether mitigation holds under load on the day you run it. Readiness monitoring answers a different question: whether the path to that mitigation is still intact today, and every day between tests. You need both.

1. Is your traffic being advertised correctly?

Whether you use always-on or on-demand protection, traffic has to be routed through the protection service, usually by advertising your network prefixes to it over BGP. Problems often emerge through gradual drift rather than obvious failures.

A prefix that should be advertised is no longer being announced. A routing change made during another project alters the traffic path. An on-demand configuration hasn’t been tested since the day it was set up. Nothing appears broken, no alarms sound, but traffic may no longer be following the path you think it is. And if an attack happens tomorrow, that’s the worst possible moment to discover it.

How to check: in Imperva DDoS Protection for Networks, the Connectivity dashboard shows the advertisement status of every protected prefix. Received means it reaches Imperva on at least two connections at two different PoPs. Received with issues flags problems such as a prefix advertised to a single PoP, or an on-demand prefix missing its no-export community. Not received means Imperva isn’t getting the advertisement at all. Status changes can be sent to you by email or to your SIEM.

2. Are your connections healthy?

Protecting traffic is only half the equation. Once traffic has been inspected and scrubbed, it still needs to reach your environment. The health of tunnels and connections plays a critical role in that process. A tunnel that’s technically up but suffering from packet loss, latency, or instability isn’t delivering the same outcome as a healthy connection.

Many organizations don’t discover these issues until traffic volumes increase or operational pressure rises. In other words, exactly when they need those connections most.

How to check: with performance monitoring enabled on a GRE tunnel connection, Imperva tracks latency, jitter and packet loss between its PoP and your network. You set the thresholds. When one is crossed, Imperva logs a “connection performance degraded” event and notifies you, with automated ping and traceroute results attached to the event.

3. Is traffic actually arriving?

This is often the most overlooked readiness check; many organizations monitor overall traffic levels and see healthy numbers across the environment. The dashboard looks green, total volume looks normal, but aggregate metrics can hide local problems.

A single point of presence (PoP) may receive significantly less traffic than expected because of routing changes, connection issues, or path degradation. In a global environment, that reduction might represent only a small percentage of total traffic and easily disappear into normal variation.

The dashboard stays green, while users in that region experience a very different reality. Monitoring expected traffic levels at the PoP level helps uncover these issues before they impact users or complicate response during an attack.

How to check: Imperva PoP Traffic Monitoring does exactly this. You set a minimum level of legitimate traffic for each protected network or IP (0–100 Mbps) and a minimum share of traffic for each PoP or group of PoPs. When traffic stays below a threshold for five minutes (the default), Imperva logs a “traffic dropped below threshold” event and notifies you.

Watch for too little, not just too much

Most DDoS detection systems are designed to identify excess: more traffic, more requests, more connections and more anomalies. The assumption is simple: when something goes wrong, volume increases, but readiness issues often present in the opposite way. Traffic stops arriving where expected, advertisements change, routes shift and connections degrade. But nothing spikes, nothing triggers traditional attack alerts.

The only signal is an absence. That’s why DDoS readiness requires a different mindset. Instead of asking:

“Is too much traffic arriving?”

you also need to ask:

“Is the expected traffic still arriving everywhere it should?”

That question can reveal problems long before an attacker does.

What changes when readiness becomes visible?

When readiness becomes visible, three things change. First, readiness becomes an operational consideration rather than an emergency discovery. Teams can identify issues during routine monitoring instead of during an active incident.

Second, on-demand protection becomes easier to validate. If attack-path activation is something you’ll depend on during a crisis, you need confidence that it will work before the crisis arrives. For on-demand ranges, Imperva also raises an event if flow monitoring data stops arriving, because DDoS detection for that range is inactive until it resumes.

Third, incident response improves. When an attack begins, teams aren’t wasting precious time figuring out whether protection was actually in place. They can focus immediately on responding to the threat.

The bottom line

Protection you can’t verify is protection you’re assuming.

That assumption can survive for months or even years because most days are quiet. Every uneventful day reinforces the belief that everything is working as expected. Then an attack arrives and turns that assumption into a test.

At Thales, we believe DDoS readiness is fundamentally a visibility problem. By continuously monitoring advertisement state, connection health, and traffic flow across locations, organizations can answer the critical question before an attacker forces it: is our DDoS protection actually on, everywhere it should be?

Discover how Thales Imperva DDoS Protection helps defend your applications and networks against increasingly sophisticated DDoS attacks while keeping critical services available.

DDoS readiness FAQ

What is DDoS readiness?

DDoS readiness is the verified, ongoing state in which your traffic is actually routed through, delivered by and arriving at your DDoS protection service, as opposed to a service that is only licensed and configured. It rests on three checks: route advertisement, connection health and traffic arrival at each PoP.

How can I tell if my DDoS protection is actually working?

Check three things continuously: that your prefixes are advertised to and received by the provider, that the tunnels or connections back to your network are healthy (latency, jitter, packet loss), and that expected traffic keeps reaching each PoP. Alert on drops, not just spikes.

How is DDoS readiness different from DDoS testing?

DDoS testing simulates an attack to check whether mitigation holds at one point in time. Readiness monitoring checks, every day, that the routing and connections mitigation depends on are still intact. One complements the other.

Does on-demand DDoS protection need readiness checks?

Yes, even more than always-on. On-demand protection only matters if activation works during an attack, so verify that your advertisements are correct (with Imperva, including the no-export community) and that flow monitoring data is still arriving. If it stops, attack detection for that range is inactive.

The post Is Your DDoS Protection Actually On? appeared first on Blog.

SQL parsers are critical components of the modern data stack. They validate queries before they reach the database, transpile between dialects, and lint codebases for style violations. Increasingly, they also power AI-driven SQL generation in LLM-integrated data tools. 

Our research focused on two popular Python-based parsers: SQLGlot and SQLFluff, both with around 10k GitHub stars each. These libraries sit at the foundation of the data ecosystem, trusted by thousands of projects, and we believe the underlying issues are relevant to other parsers and other programming languages as well. 

But these parsers carry a hidden flaw. They are highly susceptible to resource exhaustion from seemingly “simple,” syntactically valid SQL queries. Not injection. Not malformed input. Just normal-looking SQL that happens to be shaped in the wrong way. 

In this post, we describe our findings of new vulnerabilities stemming from two root causes: Recursive Stack Overflow and Parser AST Object-Inflation. We show how these flaws cascade into downstream applications, giving concrete examples from several major projects we found vulnerable, with many more still to be explored. We then explain the underlying mechanics and conclude with practical fix suggestions for both parser maintainers and application developers. We reported every issue to the respective maintainers and contributed to the fixes that now ship upstream; the SQLFluff findings were assigned CVE-2026-46373 and CVE-2026-46374. 

The First Clue: A Query That Crashes the Interpreter 

Our research began with a simple question: what happens when you feed a deeply nested query to a SQL parser? 

The answer: the Python interpreter crashes with a RecursionError. At higher concurrency, it segfaults. 

This isn’t a contrived edge case. The query is syntactically valid SQL. Any database would reject it for being absurd, but a parser’s job is to parse it – and both SQLGlot and SQLFluff attempt to do so without any depth limit. At 50+ levels of nesting, the recursive descent parser exhausts the call stack. 

The fix seems obvious in hindsight: enforce a maximum recursion depth (e.g., 30 levels) and abort gracefully. But neither parser does this. 

Going Wider: AST Object Inflation 

The recursion crash was just the beginning. As we explored further, we discovered a more insidious problem: AST amplification. 

SQL parsers work by converting raw SQL text into an Abstract Syntax Tree (AST) – a structured representation where each token (literal, identifier, operator, dot) becomes a Python object. These objects carry metadata: type information, position tracking, parent references. They’re heavyweight. 

The question became: what if we crafted a query that was short but produced an enormous number of AST nodes? 

The result was striking. In SQLGlot, a SQL string under 2MB in size demanded over 1.5GB of RAM to parse – roughly a 750x amplification ratio. SQLFluff showed the same pattern: at width=5000, it consumed over 1GB. 

This is the core vulnerability: each SQL token gets wrapped in a heavy Python object. A compact input with thousands of columns and deep expression chains generates millions of AST nodes, far exceeding what any reasonable container or server can handle. The process is killed by the OOM killer – or simply hangs until it starves out everything else on the machine. 

The Amplification Chain 

To see where the cost comes from, it helps to follow the input through each stage of parsing. The payload starts small, but every step multiplies it: tokenization splits the string into hundreds of thousands of pieces, AST construction wraps each one in a heavyweight Python object, and the resulting tree balloons into gigabytes of memory. The diagram below traces that roughly 750x expansion from a 2MB string to a 1.5GB+ footprint. 

The key insight is that object inflation is the root cause. It isn’t about the input being “large”, it’s about the multiplicative cost of turning each token into a rich object. A 2MB string is a perfectly normal payload by any standard. But the parser amplifies it by orders of magnitude. 

The Cascade: From Parser to Platform – Examples 

A vulnerability in a parser library is concerning on its own. But parsers don’t exist in isolation, they’re embedded deep in application stacks. When the parser crashes, the application may crash with it. 

We traced this cascade through several major projects. 

Apache Superset: Complete Service Outage 

Apache Superset (~75k stars) uses SQLGlot under the hood. Its SQL Lab feature allows authenticated users to write and execute queries. 

The weakness lives in the pre-execution phase. When a user submits a query through SQL Lab, Superset hands the raw SQL to SQLGlot for parsing and validation before it ever reaches the database and before any complexity checks are applied. There is no limit on query size, nesting depth, or AST node count at this boundary. An authenticated user with ordinary SQL Lab access is enough; the query never has to run. 

Depending on the payload size, the attack produces two distinct denial-of-service states: 

• Memory exhaustion (OOM crash): Large payloads (roughly 5 MB and up) drive AST allocation past available system RAM. The worker is terminated with a SIGKILL and restarted, dropping in-flight requests. 
• CPU/thread exhaustion (zombie hang): Moderate payloads (around 1.5 MB) don’t trip the OOM killer but saturate CPU and hold the GIL, so parsing never completes. The GIL (Global Interpreter Lock) is a mutex in CPython that lets only one thread execute Python bytecode at a time; a thread stuck in a long, pure-Python parse keeps the lock and starves every other thread in the process. Every user sees persistent timeouts while the worker is pinned. 

The attack is simple: authenticate as a normal user, then send a batch of concurrent requests to /api/v1/sqllab/execute/, each carrying a payload built from a large number of columns of a deeply nested x=x=x… expression. The number of columns determines which failure mode you hit: 

• A wide payload (on the order of tens of thousands of columns) makes container memory climb steadily until the worker is killed within a few minutes, emitting the tell-tale log line: 

• [ERROR] Worker (pid:14) was sent SIGKILL! Perhaps out of memory? 

• A smaller payload hangs the server with consistent timeouts for all users without triggering the OOM killer. 

The exact thresholds depend on available memory – a 16 GB host behaves differently from a 4 GB container – but either way, a single authenticated user takes down SQL Lab, and the shared worker pool, for everyone. 

Dify: Plugin Framework Collapse 

Dify (~150k stars) Uses SQLGlot within its plugin ecosystem. We found two vulnerable plugins – db-client-node and dify-bigquery-plugin – and that the plugin framework’s architecture amplified the parser vulnerability into a system-wide failure. 

A large SQL payload (10,000 columns x 60 depth) executed through a workflow that triggers 5 concurrent database queries caused a 5GB RAM spike. This didn’t just kill the plugin – it destroyed the IPC bridge between Dify’s Go-based daemon and its Python workers. 

PluginDaemonInternalServerError: write |1: file already closed failed to write request 

The daemon lost track of healthy workers. The system entered a “Blackout” state for approximately 60 seconds, during which all tool calls across the entire framework returned errors – not just those involving the parser. 

SQLFluff Online: Backend Exhaustion via Missing Input Limit 

SQLFluff Online (source) exposes the parser through a web API. The frontend enforces a 3,000-character input limit. The backend does not. 

By sending a crafted payload directly to the /fluffed endpoint – bypassing the frontend – a single request consumed 2GB+ of RAM and saturated the CPU. The service locked up entirely. 

Pathway: OOM in the SQL Interface 

Pathway (~60k stars) uses SQLGlot internally and exposes a pw.sql interface that accepts user queries. We submitted a crafted query (10,000 columns x 70 depth) and watched memory grow unboundedly, consuming 8GB+ of RAM. The server was killed with OOMKilled: true and ExitCode: 137. Pathway produced no error or warning before the crash. 

The Bigger Picture: Parser Exhaustion 

The security community has spent decades hardening systems against SQL Injection, the manipulation of query structure to execute unauthorized commands. This is a different class of attack entirely. 

Parser Exhaustion doesn’t inject anything. It doesn’t exploit string concatenation or missing parameterization. The queries are syntactically valid. They would parse correctly on any SQL grammar. They just happen to be shaped in a way that overwhelms the parser’s resource consumption. 

This distinction matters because Parser Exhaustion bypasses many traditional defenses: 

• Parameterized queries aren’t relevant for generated queries, where the whole structure is dynamic 
• Input sanitization won’t catch it – there are no special characters to escape 
• WAFs typically look for injection patterns, not resource-exhausting shapes 

As the industry moves toward automated SQL generation and LLM-integrated data tools, this attack surface grows. LLMs can generate arbitrarily complex SQL. If that SQL passes through a parser – for validation, linting, or transpilation – the parser becomes an attack vector. Not because the SQL is malicious in the traditional sense, but because it’s expensive. 

The parser is no longer just a utility. It’s a trust boundary. 

Practical Mitigations 

The good news: these vulnerabilities are straightforward to mitigate. Simple limits on recursion depth and AST size can harden parsers against this entire class of attack. 

At the Parser Level

1. Recursion depth limit: abort parsing if nesting exceeds a threshold:

2. AST node limit: count nodes during construction and abort if a threshold is exceeded: 

We reported both issues to the maintainers of SQLGlot and SQLFluff and contributed to the fixes. SQLGlot now enforces a configurable recursion/complexity limit during parsing (merged ahead of the v30.5.0 release), and SQLFluff adopted comparable guards. If you depend on either library, upgrade to a patched version and keep the default limits enabled. 

At the Application Level 

The bad news: not all parsers support limits. If the parser you use enforces a recursion or node limit, enabling it is the best way to mitigate these vulnerabilities. If it doesn’t, defend at the application level: 

• Enforce input limits: reject queries before parsing based on cheap, pre-parse metrics: raw byte size, token count, nesting/parenthesis depth, and column count. These caps cost almost nothing to check and stop the pathological shapes before a single AST node is allocated. Apply them on the server, not just the client – the SQLFluff Online case shows that a frontend-only limit is trivially bypassed. 
• Set execution timeouts for parsing operations: don’t let a single query consume a worker indefinitely 
• Implement memory limits via container constraints (Docker –memory) to contain blast radius 
• Rate limit query submissions, especially in multi-tenant environments
• Isolate plugin execution: use network namespaces or sandboxed processes so a plugin crash doesn’t cascade 

Not Only SQL 

SQL parsers are not special. The root causes – unbounded recursion and object inflation – are properties of recursive-descent parsers in general. We found the same patterns in query languages built on entirely different grammars. 

Cypher (Neo4j) 

Neo4j’s Cypher query language (~17k stars) exhibits both failure modes: 

• Deep nesting: A query with ~1,500+ nested parentheses, lists, or maps causes the connection to hang for 240 seconds before timing out. 
• CPU exhaustion: Parsing exhibits quadratic time on long chains of AND/OR operators. A query with 30,000 chained operators takes 172+ seconds to parse, with a peak heap of ~1.3 GB and worker-thread starvation – a small input that pins a worker for minutes. 

GraphQL 

GraphQL (~20k stars) is the instructive counter-example: the spec supports a max_tokens limit, but whether it’s enforced by default varies by implementation. 

• graphql-java – ships a sensible default 15,000-token limit. But even that budget is enough for ~1,800 fragments (~50 KB) to saturate CPU for several minutes on every request. A default limit helps, but the threshold still has to be tuned to resource cost, not just token count. For further reading, see our write-up on remote DoS attacks against graphql-java. 
• graphql-js (no token limit by default) – a single unauthenticated POST expands a 6.9 MB payload into ~1.77 GB RSS (~256x amplification) and blocks the worker for ~14.6 s. Under –stack-size=65500 (common in production) it crashes outright. Confirmed against Apollo Server v5.5.1. 
• graphql-core (Python, no token limit by default) – ~7 MB expands to ~2 GB RSS (~276x amplification), blocking the worker for ~23.4 s. A payload under 1 KB triggers a RecursionError at depth ~300. 

The takeaway: this is a parser-design problem, not a SQL problem. Any parser that turns untrusted text into a rich object tree without bounding depth or node count is exposed. 

Conclusion 

We disclosed vulnerabilities in SQLGlot, SQLFluff (CVE-2026-46373, CVE-2026-46374), and several downstream applications – all stemming from the same root cause: parsers that trust their input to be reasonable. Beyond reporting, we worked with both maintainer teams and contributed to the fixes that now ship upstream, so every project depending on these libraries benefits by upgrading. The fixes themselves are straightforward: depth limits, node counting, input size validation. But the lesson is broader. 

Parsers have quietly become critical infrastructure. They’re embedded in data platforms, CI/CD pipelines, AI agents, and production workflows. Yet they’ve historically been treated as safe, deterministic utilities that “just work.” Our findings show that even syntactically correct queries can be weaponized to dismantle the systems that depend on them. 

As the industry moves toward automated SQL generation and LLM-integrated data tools, the parser is no longer a passive utility – it’s an active attack surface. Hardening it requires the same discipline we apply to any other trust boundary: validate input, limit resource consumption, and assume that anything coming from outside the system is potentially adversarial. 

It’s time to move beyond SQL Injection. Welcome to Parser Exhaustion. 

The post The Hidden DoS Vector in SQL Parsers appeared first on Blog.

Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCert’s 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.

The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.

Why TLS certificate lifespans are shrinking to 47 days

Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.

How to prepare for 47-day certificates: five things to do, in order

1. Inventory what you actually have. Every certificate, every domain, every site, and who renews it. Cloud WAF reports SSL coverage status for each protected site, so start with your public-facing estate. It is the part with a deadline attached and the part your customers meet first.
2. Automate domain validation now. Manual validation at a 10-day reuse window is not a process, it is a permanent job for somebody. Automatic CNAME validation makes ownership proof continuous, and it is the single change that turns the 2029 schedule from alarming to routine. The payoff starts now, not in 2029: Imperva already requires domain revalidation every 99 days for its managed certificates. We walked through the setup in Effortless certificate management with automated CNAME validation.
3. Find your non-SNI traffic before it finds you. Server Name Indication (SNI) is the TLS extension that tells the server which hostname a client is asking for. Clients that do not send it, usually older HTTP libraries, outdated monitoring tools and misconfigured internal services, cannot be served a site certificate (a site with non-SNI connections is not eligible for one), and they are rejected outright once a site moves to SNI-only mode. That is why this step comes before the next one. Non-SNI clients are also invisible unless you go looking. One custom rule with the filter hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.
4. Isolate the blast radius. A certificate shared across your whole estate means one renewal problem is everyone’s problem. Imperva site certificates give each site its own certificate, its own coverage status and up to 50 domains, so one team’s missed renewal does not become another team’s outage. New SNI-only sites have required site certificates since September 13, 2026, and Imperva recommends migrating existing SNI sites off shared account certificates by December 31, 2026, before automatic migration begins in Q1 2027.
5. Connect the certificate system you already run. If your certificates are governed in a Certificate Lifecycle Management (CLM) platform, the system that issues, tracks and renews certificates centrally, or in your own PKI, those renewals should reach your WAF without a person in between. The SSL Integration Center connects that workflow directly to Imperva Cloud WAF. DigiCert Trust Lifecycle Manager and Keyfactor Command are on the supported vendor list, with further CLM integrations in progress.

What Imperva is already doing: 90-day certificates and the R46 root

Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.

The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.

Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.

Frequently asked questions about 47-day certificates

When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.

How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.

Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.

What happens to clients that don’t support SNI?
A client that doesn’t send SNI can’t be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.

The post 47-Day Certificates Are Coming: Five Things to Do Before They Arrive appeared first on Blog.

Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.

Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.

What shipped: hybrid post-quantum TLS on every Cloud WAF site

Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your users’ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography can’t wait; this post is the update now that both legs are covered.

The second leg: post-quantum TLS from Imperva to your origin

A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the user’s browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin can’t negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.

The honest scope: what hybrid key agreement covers

Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NIST’s ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.

What to do about harvest now, decrypt later

• Nothing, for the client leg. It is already on.
• Check your origin stack for hybrid key-agreement support, and switch on the second leg when it does. That means OpenSSL 3.5 or later. New sites have PQC to origin on by default; existing sites need it switched on once, in the Cloud Security Console or through the API.
• Put one line in your next security review: sessions through Cloud WAF are quantum-safe by default. Boards like sentences that end.

Detail, including how to test PQC and how to switch it on for your origin, is in the Post-Quantum Cryptography (PQC) Support documentation.

The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.

Harvest now, decrypt later: FAQ

What is a harvest now, decrypt later (HNDL) attack?

An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.

Is Imperva Cloud WAF traffic protected against harvest now, decrypt later?

Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.

What is X25519MLKEM768?

It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.

What happens if a client or origin doesn’t support post-quantum TLS?

The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.

The post Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing appeared first on Blog.

Executive Summary 

Imperva Threat Research identified a series of remote denial‑of‑service vulnerabilities in GraphQL Java, one of the most widely used libraries for GraphQL in the Java ecosystem. 

In this blog, we’ll deep dive into these vulnerabilities, analyze their impact, and provide recommendations to protect your environment. If your endpoints are protected by Imperva Web Application Firewall, your systems are already protected against these threats.  

Introduction 

GraphQL Java is the engine beneath Spring for GraphQL, Netflix DGS, and Atlassian’s own products. With over one million downloads per month and ten years of production use, it is a natural choice for any team building a GraphQL API on the JVM. 

Over the last few years, multiple types of DoS attacks have been identified across GraphQL implementations. These vulnerabilities can lead to either denial of service or, in cloud-billed environments, excessive cost consumption. In response, the industry converged on a set of protective controls, like depth limiting, query complexity budgets, and field count caps. Apollo added query cost analysis and depth limiting, GitHub meters its public GraphQL API by computed node cost, and GraphQL Java also introduced additional controls. 

However, these enhancements can leave blind spots earlier in the pipeline, before the server has even understood the request. 

The DoS attack we found live in the first half of the pipeline, where the query is parsed and validated, and therefore independent from the schema, the resolvers, and any backend logic.  

They were reported under GHSA-7p4r-9rcc-8vhv (still as draft) and fixed in versions 24.4, 25.1, and 26.1. Several products embedding the library were affected, including Adobe Experience Manager (AEM), Atlassian Confluence, and HAPI FHIR server, a widely used open-source implementation of the HL7 FHIR healthcare interoperability standard. 

Request Processing 

Fig. 1: GraphQL Processing High Level Pipeline 

GraphQL was built around a simple idea: “GraphQL queries mirror their response.” In other words, the client describes exactly the data it needs, while the server determines how to retrieve and resolve that data. The query is then sent to a GraphQL endpoint, where it goes through a series of processing steps before the response is returned: 

• HTTP Request: The server receives the GraphQL query. 
• Lexing: The query is broken down into tokens. 
• Parsing: The tokens are turned into an Abstract Syntax Tree (AST) representing the query structure. 
• Validation: The query is checked against the GraphQL schema and its rules. 
• Execution: GraphQL invokes the appropriate resolvers to retrieve the requested data. 
• JSON Response: The results are assembled and returned to the client. 

The distinction between these stages matters. A request can be rejected before execution because its syntax is invalid or because it does not match the schema. Only after passing these checks does GraphQL reach the resolvers, where the application and its underlying data sources are accessed. 

For security research, this pipeline provides a useful way to understand the attack surface. Each stage processes attacker-controlled input in a different way, making it important to understand not only what GraphQL does, but also when and where it does it. 

Parsing and Validation: A Closer Look 

Before a server decides what data to return, it must first decide whether the request makes sense. Parsing breaks the raw query text into an Abstract Syntax Tree. This involves: 

• Resolving string literals: block strings go through a dedicated normalization routine that strips leading and trailing blank lines. 
• Constructing AST nodes for every value encountered: numeric literals are converted to BigInteger or BigDecimal at this point. 

Validation walks the AST and checks it against the schema. This involves: 

• Field and type checks: do the requested fields exist? Do the argument types match? 
• Fragment validation: named fragments must not form cycles, directly or transitively 
• Limit enforcement: in GraphQL Java 26.0, maxDepth and maxFieldsCount are checked here. 

Fragment Cycle Detection 

Validation is where fragment cycle detection takes place. Named fragments are GraphQL’s reuse mechanism. Instead of repeating the same selection set in multiple places, a client defines it once and references it with a spread: 

Fig. 2: Named Fragments in GraphQL 

Fragments can themselves spread other fragments. The spec allows arbitrary nesting, but it forbids cycles: if A spreads B and B spreads A, resolving either one requires resolving the other first. The execution engine would recurse indefinitely. The same applies to indirect cycles across any number of fragments. 

This check happens during validation, after parsing has produced the AST and before execution starts. At this point the server has a complete map of every named fragment in the document and every spread reference between them.  

Cycle detection is pretty straightforward: for each fragment, follow its spread references transitively and check whether any path leads back to the starting node. If it does, the document is rejected with a validation error and execution never starts. 

ValidateNoFragmentCycles is called once per FragmentDefinition in the document. Each call starts with a fresh HashMap. 

For each fragment, it calls buildTransitiveSpreads, a depth-first traversal that follows every spread reference outward, building up the set of fragments reachable from the starting node.  

The traversal tracks its current path in an ArrayList, and at each step calls ArrayList.contains to check whether the next node has already been visited.  

Worst Case Scenario 

We considered a document with the following chain of d fragments: 

Fig. 3: Malicious Payload Structure 

For each fragment, ValidateNoFragmentCycles starts a new traversal with a fresh HashMap. Since the traversal follows the entire chain, and ArrayList.contains iterates over the path of fragments visited so far, the cost of a single validation is O(d²).  

Fig. 4: Processing of the First Fragment 

Since this happens for all fragments, the overall complexity is O(d³), where d is the number of fragments in the document. Within the default 15,000-token limit, a single payload can contain up to around 1,800 fragments (~50 KB), which is sufficient to saturate a CPU core for several minutes at every request. 

Why existing GraphQL protections may not help 

Traditional GraphQL protections such as depth limits and field-count limits operate during validation. However, this attack specifically targets the validation step itself. Therefore, it hits before the protections can prevent the attack. 

Following the reception of our report, graphql-java released a patch that introduces memoization. Once a fragment has been explored, it is marked as done and never re-traversed again. The same malicious payload is processed in a few milliseconds instead. 

This finding was the most impactful, but it wasn’t the only one. 

Additional Remote DoS Vulnerabilities 

We identified the same underlying idea as one of the attack vectors previously identified in React Server Components (BigInt values, CVE-2026-23864), and another vector involving block string normalization routine, more impactful. Both fixed in 24.4, 25.1 and 26.1. 

HAPI FHIR Use Case 

HAPI FHIR is a Java server designed to store and serve medical data (patients, prescriptions, lab results) using the FHIR healthcare standard. Like many modern APIs, it exposes a GraphQL endpoint that clients can use to query this data.  

Internally, HAPI handles GraphQL requests with its own parser, written specifically for FHIR, which knows how to resolve medical resources. But when a client asks for introspection (a standard GraphQL feature that returns the full list of available queries and types) HAPI delegates directly to graphql-java.  

However, it’s possible to bypass HAPI’s custom FHIR resolver and route a non-introspection query straight to graphql-java. 

This delegation is triggered by a simple string check: it relies on the presence of the string `__schema` in the body.  

Therefore, simply starting the request with the following pattern (see Fig 5.) was enough. 

Fig. 5: bypass HAPI’s custom FHIR GraphQL resolver 

Tested on a fresh c7i.2xlarge instance, with the latest HAPI server with graphql enabled, a single request took 150 seconds of validation. A single wave of multiple small requests could lock the server entirely for several minutes and pin all 8 CPU cores at 100% for more than an hour. 

In this application, this attack vector could represent an alternative avenue for a threat actor lacking authorization to exfiltrate patient data (as HAPI’s authorization model governs GraphQL endpoint access and data read permissions independently), and still willing to cause impact. 

The attack surface is further widened by HAPI’s default CORS configuration (allows any origin, Access-Control-Allow-Origin: *). In environments where no additional network controls are in place, this means the attack could be triggered from a browser: a healthcare worker opening a malicious link while connected to the internal network is sufficient to take down the FHIR server for everyone. 

Who is Affected? 

An application is potentially exposed when: 

• It uses an affected version of GraphQL Java;  
• It accepts attacker-controlled GraphQL documents;  
• The GraphQL endpoint is remotely reachable;  
• No upstream control blocks the malicious request.  

Remediation 

The fixes are available in GraphQL Java versions 24.4, 25.1, and 26.1 via PRs #4440, #4441. 

For environments where an immediate upgrade is not possible: 

• Restrict access to affected GraphQL endpoints to authenticated or otherwise trusted clients where the application permits it. 
• Apply rate limiting and concurrency limits to restrict the number of GraphQL requests that can be processed simultaneously. 
• Monitor CPU utilization and GraphQL request latency for unusual increases that may indicate resource-exhaustion attempts. 

If your endpoints are protected by Imperva Web Application Firewall, your systems are already protected against these threats. 

Conclusion 

As AI accelerates vulnerability discovery and exploitation, threat actors can increasingly scan a target environment in real time, identify weaknesses across its technology stack, and rapidly turn those findings into attacks. This reduces the time organizations must detect and remediate newly exposed vulnerabilities, making proactive and continuously enforced security controls increasingly important. 

Affected organizations should upgrade to a fixed release as soon as possible. Until patches can be applied, additional controls at the application and network layers can help reduce exposure and limit the impact of potential attacks. 

Imperva customers are protected against exploitation of these vulnerabilities. Imperva Threat Research will continue to monitor this threat and work to ensure that customers remain protected against emerging attack techniques targeting GraphQL and other widely deployed technologies. 

Timeline 

August 11 – We reported the security issue to GraphQL Java. 

August 19 – Report Acknowledged. 

August 23 – Fix released in versions 24.4, 25.1 and 26.1. 

The post New Remote DoS Attacks Against GraphQL Java appeared first on Blog.

Introduction 

AI-assisted development has crossed a threshold. The question is no longer whether your IDE communicates with an AI, it’s how deeply that AI is now wired into your local environment. The Model Context Protocol (MCP) is one of the plumbing behind this shift: a JSON-RPC-based protocol that lets AI assistants invoke tools running on your machine. From setting a breakpoint, to running tests, or launching a debugger… all from a chat window. 

DebugMCP is one of the extensions leading that charge. Published by Microsoft on GitHub, it exposes a local MCP server that gives any compatible AI agent (GitHub Copilot, Cline, Cursor, Codex, Windsurf, and others) direct control over the VS Code debugger. The value proposition is compelling: instead of pasting stack traces into a chat window and waiting for a suggestion, an AI agent can set breakpoints, step through code, inspect variables, and evaluate expressions autonomously.  

We identified and reported a critical security issue in version 1.1.4. A remote attacker who tricked a developer into visiting a malicious webpage could achieve arbitrary code execution on that developer’s machine, in the background, without any further user interaction (drive by).  

Following our report, the maintainers patched DebugMCP via commit 86776b2m. The fix was silently shipped (no version bump, no advisory) and is included in version 1.2.0 and later. We are publishing this report following the 90-day disclosure period. 

We recommend updating to the latest available version. 

Scope 

The exploitability of this weakness was amplified by the context in which the software evolves.  

Indeed, we’re talking about an opensource MCP server hosted on GitHub, that can be used as a standalone server. But this MCP server is also exposed as an extension in VSCode Marketplace, installable with a single click both in local endpoints, and in shared servers via systems like Github CodeSpaces, OpenVSCode Server, etc. 

From this single installation click, the server is automatically started and listening on port 3001 without authentication, opening the door to RCE. 

First, we’ll explore how this issue could be exploited from a surrounding compromised device, and we’ll then demonstrate how DNS rebinding could be exploited to trigger RCE via simply having a victim browse to a malicious site. 

Root Cause 

DNS Rebinding 

DNS Rebinding is a recurrent risk issue when it comes to MCP servers’ development (See our previous blogpost: Another Critical RCE Discovered in a Popular MCP Server).   

At the end of 2025, probably following a series of vulnerabilities identified in multiple MCP servers, Anthropic added an additional layer of security to prevent this risk (CVE-2025-66414) that adds a default security layer in most MCP server cases.  

Version 1.24.0 of modelcontextprotocol introduces createMcpExpressApp, a preconfigured express server instance that automatically registers validateHostHeader and validateOriginHeader. Together, these functions prevent the risk of DNS rebinding.  

However, the library still relies on maintainers to use header validation middleware functions in case of custom express configuration. And in the case of DebugMCP, this is lacking. 

That was the first node of our attack chain. 

Combined with the lack of host and origin definition and validation, the custom express server defined (identical to CVE-2025-53967), exposed the MCP tools far beyond the intended reach.  

But independently from the broad network exposure, an LLM could be tricked via indirect prompt injection to access a file outside VSCode workspace trust, and the fix produced by the maintainers doesn’t answer this question.

Uncontrolled File Path 

To further explore the attack chain, let’s review the tools exposed. 

The README lists the available tools, including: 

• start_debugging: launches a debugging session for a given file path 
• get_debugger_state: returns the current state of an active debugging session 
• add_breakpoint / remove_breakpoint: manage breakpoints 
• step_over / step_into / step_out: stepping controls 
• get_variables: inspect local variables in the current stack frame 
• evaluate_expression: evaluate an arbitrary expression in the debugger context 
• continue_execution: resume execution

From reading the tool definitions, start_debugging jumped out immediately since it accepted a fileFullPath argument and instructs VS Code to launch a debugger session for that file. That’s a file execution primitive. 

But to obtain an efficient RCE chain, a few more steps were required. 

The UNC Path Primitive 

At first glance, because the vulnerability requires knowing the full path of an executable on the victim’s machine, it seems difficult to weaponize reliably in the wild. 

However, on Windows, the Universal Naming Convention (UNC) path format allows programs to reference files on network shares using paths of the form: 

\\SERVER\SHARE\path\to\file 

This feature enabled us to make DebugMCP pass the path to VS Code’s debugging infrastructure, which passed it to the Python launcher, which reached out to the attacker’s SMB share and loaded the file. The file executed under the victim’s user context. 

Fig. 1: SMB endpoint to fetch payload 

The proof-of-concept payload was intentionally benign: 

import os
os.system(“calc.exe”) 

After a few seconds, Calculator opened. The attacker’s code was running on the victim’s machine via a single HTTP request. 

At this point we had a working local exploit, if we could send one HTTP request to port 3001 with an attacker-controlled UNC path and get code execution.  

The remaining question was how to deliver that request from a remote attacker’s position to a victim’s localhost, across the same-origin policy that is supposed to make this impossible. 

Stateless MCP session 

One part of the answer lies in the MCP itself. You can find a detailed introduction to the protocol here. 

What matters here is one implementation detail that significantly reduced the attack complexity. 

MCP over HTTP is built on JSON-RPC 2.0. The protocol specification describes a lifecycle: a client must send an initialize request, receive the server’s capability response, then send an initialized notification (only after this handshake can tool calls be made). This sequence implies a minimum of two round-trips before any tool is invoked, and it gives a server the opportunity to establish authenticated session state. 

The MCP TypeScript SDK’s StreamableHTTPServerTransport enforces this lifecycle through a validateSession function called on every non-initialize request. The enforcement is conditional: 

Fig. 2: Stateless MCP mode 

When sessionIdGenerator is undefined, validateSession returns immediately without checking anything. The entire initialization lifecycle is bypassed. In DebugMCP v1.1.4, the transport was explicitly configured in stateless mode.  

The consequence for the attack chain is direct: a single no-cors HTTP request was sufficient to trigger the attack. 

Browser Local Network Protections 

However, there was a last ingredient we needed to incorporate to obtain a frictionless exploit. 

Indeed, Local Network Access’s aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user’s local network. 

Combined with the same-origin policy (that prevents a piece of JavaScript from one domain  and make cors requests to a different one and get the response), in modern browsers, there is a good chance a warning popup would be displayed and halt the execution of the malicious content if a threat actor tries to scan the local network.  

But DNS rebinding is a technique that can potentially circumvent this boundary by exploiting the way browsers cache DNS records. And as we explained earlier, DebugMCP doesn’t include MCP default mitigation added by Anthropic against this risk. 

Here is the attack flow: 

Fig. 3: Attack Flow 

The sequence unfolds in six steps: 

Step 1: Victim visits the page. The attacker’s domain resolves to the attacker’s public IP (Phase 1 DNS). The browser loads the initial page content.  

Step 2: DNS Rebinding. The domain was registered with a very short TTL: 1 to 2 seconds. Firefox enforces an internal minimum cache duration of ~60 seconds regardless of the declared TTL, so the page polls in a JavaScript loop until the entry expires and Firefox re-resolves the name: at which point the attacker’s DNS server returns 127.0.0.1. 

Step 3: Local Network Access. The attacker’s JavaScript, issues a fetch to http://evil.attacker.com:3001/mcp?transport=streamable_http. The browser considers this request same-origin and sends it. The DNS entry now points to 127.0.0.1, so the request arrives at the victim’s local DebugMCP server. 

Step 4: DebugMCP Execution. The request reaches the Microsoft DebugMCP server running locally on the victim’s machine. DebugMCP processes the request and triggers its Python launcher, which is responsible for starting the debugging workflow. 

Step 5: Malicious Payload Download. The Python launcher connects to a publicly accessible SMB share controlled by the attacker and downloads the malicious Python script onto the victim’s machine. 

Step 6: Code Execution. The launcher passes the downloaded script to the start_debugging() function. DebugMCP then executes the attacker-controlled payload, ultimately giving the attacker code execution on the victim’s machine. 

Demonstration 

Although the exploit triggers error messages in the VS Code console, the payload is still successfully executed. We used Firefox version 150.0.3, the latest at the time of our research. 

Note: After the research, Firefox enforced a Local Network Access Protections (version 153). This prevents the a request originating from a domain associated with a public IP to reach more private address networks. This recent feature, currently existing in Chrome and Firefox, isn’t yet generalized to all browsers.  

Impact 

The target is a developer. That means the compromised machine holds live credentials, source code, and trusted access to internal infrastructure. 

In practice: AWS keys, SSH keys, GitHub tokens in VS Code’s secret storage, active cloud CLI sessions, VPN tunnels open to the internal network, and push access to production branches would be likely available: a payload that runs as the developer inherits all of it silently. 

The delivery requires no interaction beyond visiting a page, it’s a drive-by attack. 

Recommendations 

Developers using this tool should update to the latest available version. The fix ships after 1.1.4 (version 1.2.0 and later).  

In addition, it’s recommended to regularly audit which servers are listening on loopback. 

Use authentication in your MCP servers and enforce governance to control which MCP server is running in your network and be able to remove it if necessary. 

Regarding MCP development more specifically: 

Use middleware that enforce validation (like createMcpExpressApp Since SDK v1.23.0). 

Validate file path inputs. Reject UNC paths and remote schemes before passing any path to an execution primitive. 

Disclosure Timeline 

• May 19: Issue reported to Microsoft  

• May 24: Fix shipped in commit 86776b2, released as version 1.2.0 

• September 25: Public disclosure (this blogpost) 

Conclusion 

AI-assisted development is quietly rewriting the developer machine’s threat model. To give an agent useful capabilities, extensions expose local servers, wire in execution primitives, and grant broad access to the filesystem and the debugger.  

Each of these is a reasonable engineering decision on its own. Together, they turn the workstation into a dense collection of automation endpoints, and those same endpoints, built to be driven by a trusted agent, are equally drivable by an attacker who reaches them. The productivity story and the attack surface story are the same story. 

Developer environments are where source code, signing keys, pipeline credentials, and cloud sessions converge; compromising one is often a shorter path to production than attacking production directly.  

This vulnerability was not sophisticated. The techniques here are not new; what’s new is the rate at which capable, unvetted local servers are being deployed onto high-value machines, and the growing ability of AI agents to discover and chain weaknesses autonomously. 

The post From Debugging to Code Execution: RCE in Microsoft DevLabs’ DebugMCP? appeared first on Blog.

This is Post 4 of a four-part series:
Post 1: Agentic AI Security: The Chatbot Era Is Over
Post 2: Generative AI Security: Why AI Needs a New Kind of Security
Post 3: The OWASP LLM Top 10 Was the Warm-Up: What Comes Next

The 2026 edition of the the OWASP Top 10 for LLM Applications, published by the OWASP GenAI Security Project on August 3, 2026, is easy to skim past. No entry was dropped and no new category was introduced, so at a glance it can read as housekeeping. It is worth a closer look than that. Eight of the ten entries changed position, and one was renamed and widened in scope, which changes what it asks of the teams working against it.

When a framework adds or drops entries, it is usually telling you the threat surface itself has changed. This edition did something more specific. The categories held, but their order was substantially revised and one of them grew, which suggests the original naming was sound while the relative priority had drifted from what teams were meeting in production. Read the movements together and a pattern shows up.

The short version: the OWASP Top 10 for LLM Applications 2026 kept all ten categories but moved eight of them. Excessive Agency climbed from LLM06 to LLM03, Unbounded Consumption from LLM10 to LLM06 and Misinformation from LLM09 to LLM07, while Improper Output Handling fell from LLM05 to LLM10. System Prompt Leakage was renamed Hidden Context Exposure and broadened to cover everything an application places in front of the model without the user seeing it.

What changed in the OWASP LLM Top 10 2026

The table below sets the 2026 order against the 2025 one, listed by 2026 rank.

2025 rank	Entry	2026 rank	Movement
LLM01	Prompt Injection	LLM01	No change
LLM02	Sensitive Information Disclosure	LLM02	No change
LLM06	Excessive Agency	LLM03	Up 3
LLM03	Supply Chain	LLM04	Down 1
LLM04	Data and Model Poisoning	LLM05	Down 1
LLM10	Unbounded Consumption	LLM06	Up 4
LLM09	Misinformation	LLM07	Up 2
LLM07	Hidden Context Exposure	LLM08	Down 1, renamed and widened from System Prompt Leakage
LLM08	Vector and Embedding Weaknesses	LLM09	Down 1
LLM05	Improper Output Handling	LLM10	Down 5

Prompt Injection and Sensitive Information Disclosure held first and second, which surprised nobody. Every other entry sits somewhere new, and the rest of this piece is about why the direction of those moves matters more than the individual rankings.

Excessive Agency and Unbounded Consumption: the climbers describe applications, not models

The two biggest climbers are the same kind of risk wearing different clothes. Excessive Agency is about what an application is permitted to do once a model is driving it: which tools it can call, which systems it can reach, how far one decision can travel before a human sees it. Unbounded Consumption is about what happens when that same application meets traffic engineered to abuse it, producing no malware and no traditional indicators, just an enormous bill. Neither is a property of the model. Both are properties of an application in production.

The biggest faller makes the same argument from the other end. Improper Output Handling dropped five places, and not because it stopped happening. It fell because it is the entry the industry already knew how to answer. Rendering untrusted output safely, refusing to execute what came back from an untrusted source, treating downstream consumers as a boundary: application security teams have been practicing that discipline for twenty years. The skill transferred. The novelty did not survive contact with people who already had the muscle.

Setting the renamed entry aside, the three entries that each slipped a place have something in common too. Supply Chain, Data and Model Poisoning, and Vector and Embedding Weaknesses are all risks you address before the application serves its first request, in procurement, in the training pipeline, in how the knowledge base was assembled and secured. They did not become less serious. They became less urgent relative to the things that only exist once the system is live.

Misinformation climbing two places fits once you ask who pays for it. A model that invents a refund policy is a quality problem in a lab and a liability problem in production, and a Canadian tribunal has already held Air Canada responsible for what its chatbot told a customer (Moffatt v. Air Canada, 2024). That entry did not move because models got worse. It moved because the consequences arrived.

Read together: the entries that climbed are the ones that only exist while the application is running. The entries that fell are handled before deployment, or handled by controls the industry already had.

From System Prompt Leakage to Hidden Context Exposure: the rename nobody is discussing

System Prompt Leakage became Hidden Context Exposure, and it is the most consequential edit in the document.

A system prompt is one specific thing: the instruction block sitting at the top of a conversation, defining the model’s role and its rules. Hidden context is everything else the application quietly places in front of the model without the user ever seeing it. Retrieved documents. Tool definitions. Prior turns held in memory. Configuration a developer assumed was private because no interface displays it.

The rename takes the entry from one field to an entire supply of runtime input, and it lands the same point the reordering makes. What the application feeds the model has become the attack surface. That is a materially bigger claim than the 2025 wording made, and any content or tooling still describing this entry as system prompt protection is now describing a fraction of it.

How to read an OWASP LLM Top 10 coverage claim, including ours

A reordering like this produces a wave of updated coverage claims, and some of them will describe protection across the whole list. Those claims are worth examining rather than accepting, and one question does most of the work: which control fires, inline, at runtime, for this specific entry?

Ask it of the entries that just fell. A poisoned model dependency arrives before a single request is served. At the moment of compromise there is no traffic to inspect, no prompt to score, no response to hold. Something does address that risk, but that something is a procurement process, a posture scan or a signed build pipeline. The same is true of a poorly governed vector store. These are real controls and they matter; they are simply not the same category of thing as a runtime control, and they usually sit with a different team and a different budget.

This is not a criticism of any product. It is the shape of the problem. Runtime protection covers runtime problems. When you meet a claim spanning all ten entries, the useful follow-up is to ask which of the ten are covered by inline enforcement, which by a scanner, which by a partner integration, and which by a policy document, and then to decide whether that composition is what you thought you were buying. A vendor who can answer that cleanly is telling you something about how they think. So is one who cannot.

Apply the same question to us. We would rather you did.

Where we stand against the 2026 order

Thales Imperva AI Application Security addresses five entries with runtime enforcement. In 2026 numbering, they are Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), Unbounded Consumption (LLM06), Hidden Context Exposure (LLM08) and Improper Output Handling (LLM10).

Two of those five moved this year, and the moves cut in opposite directions. Unbounded Consumption climbed four places, which raises the profile of a control we already ship. Improper Output Handling fell five, which lowers the profile of another one we already ship. Reporting the first without the second would be the kind of selective reading this piece is arguing against.

Two of those five are also where our next work lands, and they are connected. Hidden Context Exposure now covers tool definitions, and Excessive Agency is the question of what an application is permitted to do once a model is driving it. We are adding tool call guardrails that check whether the specific tool being called is permitted, and the tool definitions themselves are what we look at next. Today we detect and monitor tool calls. Checking them against what is allowed is the step after that, and it is better to say so plainly than to let a coverage table imply it already exists.

The other five entries need different tools, and we would rather name them than imply otherwise. Supply Chain and Data and Model Poisoning are build-time and procurement problems. Vector and Embedding Weaknesses belongs with the data security controls sitting in front of the retrieval pipeline. Misinformation is evaluation and grounding work. Excessive Agency is the one to watch: it is the entry moving fastest toward runtime, it is where the agentic controls across this whole category are heading, and at number three it is now the highest-ranked risk that most security programs have no inline answer for at all.

The list caught up with agentic AI

In a recent piece we argued that the LLM Top 10 had been the warm-up, and that the frameworks describing agentic and MCP risk had already been published while most security programs were still resourcing against the first list. The 2026 edition is that argument told from inside the framework itself.

Excessive Agency at number three is an agentic risk sitting near the top of an LLM list. Hidden Context Exposure is the retrieval and tool layer being named as attack surface. Neither entry is about a model producing text. Both are about a system taking action on the strength of what it was fed. The list has started describing applications that act, which is the same shift the newer frameworks were built for.

A practical exercise for this quarter: take the four entries that moved most, and for each one write down which control in your own environment would fire while the attack was in progress, not after it appeared in a report. The gaps in that list are what the 2026 reordering is pointing at.

Thales’s Imperva AI Application Security is purpose-built runtime protection for AI applications, agents, and the ecosystems behind them, deployable in-app, at the Imperva edge, or via API, standalone or as part of Imperva’s unified application security platform. Our white paper, Beyond the LLM Top 10, maps the agentic and MCP threat surface against the published frameworks.

Frequently asked questions about the OWASP LLM Top 10 2026

What changed in the OWASP Top 10 for LLM Applications 2026?

The 2026 edition, published by the OWASP GenAI Security Project on August 3, 2026, added and removed no categories. Eight of the ten entries changed position: Excessive Agency rose from LLM06 to LLM03, Unbounded Consumption from LLM10 to LLM06 and Misinformation from LLM09 to LLM07, while Improper Output Handling fell from LLM05 to LLM10. Prompt Injection (LLM01) and Sensitive Information Disclosure (LLM02) held their places, and System Prompt Leakage was renamed Hidden Context Exposure.

What is Hidden Context Exposure in the OWASP LLM Top 10?

Hidden Context Exposure (LLM08 in 2026) replaces System Prompt Leakage (LLM07 in 2025). It widens the entry from the system prompt alone to everything an application places in front of the model without the user seeing it: retrieved documents, tool definitions, prior turns held in memory and configuration a developer assumed was private.

Why did Excessive Agency move up to LLM03?

Excessive Agency describes what an application is permitted to do once a model is driving it: which tools it can call, which systems it can reach and how far one decision can travel before a human sees it. It climbed three places, from LLM06 to LLM03, as agentic applications that take actions moved into production.

Which OWASP LLM Top 10 risks can runtime protection address?

Runtime controls act on live traffic: prompts, responses and tool calls. Supply Chain and Data and Model Poisoning are build-time and procurement problems, Vector and Embedding Weaknesses belongs with data security controls in front of the retrieval pipeline, and Misinformation is evaluation and grounding work. When a vendor claims coverage of all ten entries, ask which are covered by inline enforcement, which by a scanner, which by a partner integration and which by a policy document.

Read more in our white paper: Beyond the LLM Top 10.

The post OWASP LLM Top 10 2026: Every Move Points the Same Direction appeared first on Blog.

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. 

The post Imperva Customers Protected Against StyleSmuggler (CVE-2026-75650) in Adobe Commerce and Magento Open Source appeared first on Blog.

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.

Get started with the SSL Integration Center

If you are a Thales Imperva Cloud WAF customer using DigiCert Trust Lifecycle Manager, you can configure the integration from your TLM console today. For step-by-step setup, see the Imperva documentation on integrating custom certificates and the DigiCert + Imperva integration overview.

The post Bring Your Own CA: Introducing the Thales Imperva SSL Integration Center, Featuring DigiCert Trust Lifecycle Manager appeared first on Blog.

This is Post 3 of a four-part series:
Post 1: Agentic AI Security: The Chatbot Era Is Over
Post 2: Generative AI Security: Why AI Needs a New Kind of Security
Post 4: OWASP LLM Top 10 2026: Every Move Points the Same Direction

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.

The post The OWASP LLM Top 10 Was the Warm-Up: What Comes Next appeared first on Blog.

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.

The post Imperva API Security Token & Authentication Risk Report: Nearly 40% of APIs Face Multiple Authentication Risks appeared first on Blog.

Download the 2026 Token & Authentication Risk Report →

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:

1. The daemon must produce a coherent archive from the container’s filesystem.
2. 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:

Source: Moby containerArchivePath, Docker Engine 29.6.1, lines 76–82.

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:

Source: moby/go-archive v0.2.0 archive walk, lines 691–802.

WalkDir reads a directory entry and records its type. If the entry is a directory, the walker plans to descend into it.

The callback then passes the pathname to addTarFile, which looks it up again with Lstat to create the tar header:

Source: moby/go-archive v0.2.0 addTarFile, lines 295–317.

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:

Source: moby/go-archive v0.2.0 CopyTo, lines 418–437.

Neither option confines traversal through an intermediate symlink. The vulnerable symlink handling attempted to perform its own containment check:

Source: moby/go-archive v0.2.0 symlink extraction, lines 480–492.

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:

Source: moby/go-archive v0.2.0 addTarFile, lines 295–317.

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:

1. WalkDir records escape as a directory.
2. The container replaces it with an absolute symlink.
3. addTarFile emits the symlink into the tar stream.
4. WalkDir descends using its earlier directory type and emits a child entry.
5. The CLI validates a constructed target but creates the original absolute symlink.
6. 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 24, 2026 – Docker provided CVE-2026-17106 / GHSA-hfg8-hc9c-6c3h and targeted an August 3 coordinated release.

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 released Docker Desktop 4.86.0, bundling Docker Engine 29.7.2 and delivering the corresponding Docker Desktop fix.

The post CopyEscape: Taking Over Docker Hosts with docker cp appeared first on Blog.

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. 

The post Imperva Customers Protected Against XSS2Shell (CVE-2026-64638) in WordPress Core appeared first on Blog.

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:

1. Ease of deployment
2. Ease of management
3. Ease of risk management
4. Logging & auditing capabilities
5. Visibility & analytics
6. Support & documentation
7. API Gateway efficiency
8. Integration capabilities
9. 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.

The full report and methodology are public.

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.

Source for all figures: SecureIQ Lab Cloud WAAP CyberRisk Validation v5.0, 2026 (AMTSO-certified). Placements and competitor scores from the published comparative report.

The post What SecureIQLab Cloud WAAP 5.0 means for your application security appeared first on Blog.

This is Post 2 of a three-part series. Start with Post 1: Agentic AI Security: The Chatbot Era Is Over, then continue to Post 3: OWASP LLM Top 10: What Comes Next – Agentic & MCP.

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.

Concretely, it addresses five of the OWASP Top 10 LLM threats:

• Prompt injection and jailbreaking 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.

Read more in our white paper: Beyond the LLM Top 10.

Ready to see what AI-native security looks like in practice? Talk to your Thales representative or visit imperva.com to explore AI Application Security.

The post Why Generative AI Needs a New Kind of Security appeared first on Blog.