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.