Uncertainty creates ample room for speculation and malicious activity. Essential dos and don’ts until the official patch drops.

Two critical PHP core vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are set to be patched today. The PHP security team rates both CVSS v4.0 9.2, and researchers describe them as unauthenticated remote code execution. Beyond that, there’s very little anyone can say for sure yet.

Until 14:00 UTC, it’s all speculation

PHP has scheduled the emergency release for Wednesday, October 21, 2026, at 14:00 UTC (10:00 ET), and reserves the right to ship earlier if details go public or exploitation shows up in the wild (BleepingComputer).

The official advisory names no vulnerable function, no affected versions and no fixed releases. The CVE IDs, the “PHP 5 through 8” scope and the CVSS 10 figures all come from researchers and a leak, not from PHP.

Anything else outside of the official PHP release still theory.

One thing worth doing now: turn off uploads you don’t use

We don’t know whether file uploads are involved here. But if your PHP apps never accept uploads, there’s no reason to leave the handling enabled. Set this in php.ini, then reload PHP-FPM or your web server:

file_uploads = Off

It’s cheap, it shrinks your attack surface, and it’s good hygiene regardless of the CVEs dropping today.

Don’t go hunting for PoCs

A screenshot of an exploit tool called “PHP2Shell” has already leaked alongside the advisory (Sansec). Expect “exploits” and “scanners” for these CVEs to pop up on GitHub and Telegram before PHP publishes anything.

Skip them. Pre-disclosure PoCs for hyped bugs are a classic way to ship malware to security teams. These could easily be a waste of your time and give false confidence. Best practice is to wait for the official fix.

What’s next

Once PHP ships the patch, the OX research team will break it down from the official diff: what changed, which versions are affected, and how to tell if you’re exposed. Until then, line up your PHP runtime owners so you can patch the moment it lands.

Two critical vulnerabilities, CVE-2026-109618 & CVE-2026-109619, allow unauthenticated remote code execution RCE across nearly 2 million exposed PHP servers. Immediate upgrades to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 are required

TL;DR

On October 21, 2026, the PHP core team issued an out-of-band security release addressing two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619.

PHP is a widely used server-side language – the engine under WordPress, Magento, Drupal, Laravel and endless custom apps. The root cause is how PHP has historically reacted to running out of memory: it aborts the current work with a `longjmp` (`zend_bailout()`). When that abort happens inside engine code that is mid-operation – in particular the `session.upload_progress` handler, which decodes and rewrites a session during file-upload parsing, before the request’s script runs – it leaves PHP’s internal state inconsistent. The fix makes out-of-memory a recoverable condition instead of an abort, hardens the upload path to tolerate failed allocations, resets global state that startup code relies on, and prevents the upload-progress handler from invoking any class code while it decodes a session.

Fixed in 8.2.35, 8.3.36, 8.4.27, 8.5.12.

Impact

- ~2,000,000 internet-facing PHP servers run versions affected by CVE-2026-109618 and CVE-2026-109619.

- 99.99% of the PHP servers we could identify are unpatched.

- 1.37M (69%) run old PHP versions that will never get an official fix.

- 245 servers show a patched version so far.

Source: Shodan, Oct 21, 2026. This counts only servers that show their PHP version, so the real total is likely higher.

Why Are There Two CVEs?

Although both vulnerabilities stem from the same out-of-memory handling in PHP core, the vendor advisories split them into two independent defects:

- CVE-2026-109618 – RCE via OOM corruption: a use-after-free / memory-corruption flaw. PHP’s `longjmp` on out-of-memory leaves request memory in an invalid state before it is fully initialized, and request shutdown then reads or branches on it. The failing allocation need not be related to the corrupted memory.

- CVE-2026-109619 – RCE via stale global state: a use-after-free flaw. Worker-retained global state – session, error, object and extension state – points into a prior request’s freed memory and is accessed by early-running operations before the next request resets it.

Because each flaw is independently exploitable, two separate CVE identifiers were assigned.

Affected Products

- Product: PHP Core (ext/session, ext/standard)

- Affected Versions: All versions supporting session.upload_progress (PHP 5.4.0 through prior unpatched releases)

- Status: Fixed in 8.2.35, 8.3.36, 8.4.27, 8.5.12

Recommendations

- Immediate Upgrade: Apply the official vendor update to PHP version 8.2.35, 8.3.36, 8.4.27, 8.5.12.

- Access Control: Restrict or remove public access to unpatched PHP instances immediately.

- Caution with PoCs: Do not clone or execute unverified Proof-of-Concept (PoC) scripts or third-party patch scripts circulating on public repositories or social media.

Technical Deep Dive

The fix is a single commit, `01a40e89fb` (“Avoid state corruption via bailout”) by Arnaud Le Blanc and co-authors, closing GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). The PHP 8.2.35 changelog lists both under Core.

Root cause: out-of-memory was handled by `longjmp`

Before the fix, any allocation that crossed `memory_limit` ended in `zend_mm_safe_error()` (`Zend/zend_alloc.c`):

Because `zend_bailout()` never returns, the allocation call that triggered it – an `emalloc`, a hashtable resize, a string grow – does not return to its caller either. Any cleanup, pointer refresh, or state reset that was supposed to run after that allocation is skipped. For ordinary script code that is fine, since the request is ending anyway. It is not fine when the skipped code is engine internals that hold live pointers and have not finished updating their own bookkeeping.

Why `session.upload_progress` is the exposed surface

`session.upload_progress` is enabled by default. When a multipart POST carries a `PHPSESSID` field and a `PHP_SESSION_UPLOAD_PROGRESS` field, the multipart parser (`main/rfc1867.c`) drives a session callback for each upload event – and this runs before the request’s script is compiled, whether or not the page uses sessions.

On each progress tick the handler re-opens the session, decodes it, inserts a progress array, re-encodes the whole session and writes it back, while tracking parts of that array through raw pointers in its per-request state. Every one of those steps allocates, and the amounts are set entirely by the request: the number of upload parts, the length of each part’s field name and file name, and the `PHP_SESSION_UPLOAD_PROGRESS` value all feed the size of what gets allocated and re-encoded.

The authors’ own regression test, `tests/basic/oom_rfc1867_upload_progress.phpt`, documents the condition plainly – it posts uploads shaped to exhaust a small `memory_limit` from inside the handler, and the commit title says what used to go wrong when that happened. The comments in that test read like a catalogue of the inputs that drive the allocation:

The point is not a clever payload; it is that reaching the memory limit here required no authentication, no application cooperation, and no unusual configuration – just a sufficiently large or numerous set of upload parts.

What the patch changes

The fix hardens out-of-memory handling in four places:

1. Memory manager – a new fallible-allocation model (`femalloc` / `safe_ferealloc`, guarded by `ZEND_HAS_OOM()`) returns `NULL` on exhaustion instead of calling `zend_bailout()` – the “Replace bailout on OOM with UnwindExit” change – with a new `memory_hard_limit_percent` giving the recovery path headroom.

2. Multipart parser (`main/rfc1867.c`) – converted to those fallible allocations, checking for exhaustion (`goto oom`) rather than trusting each allocation to succeed.

3. Upload-progress handler – stops forcing the session active regardless of result (it now checks `php_session_initialize()` and returns cleanly on failure), and brackets the operation with a new `in_rfc1867_update` flag that drops the unserializer into an “incomplete classes only” mode, so decoding a session in that pre-script window resolves no classes and runs no autoloaders, `__wakeup()`, `__unserialize()` or destructors.

4. Globals – startup-accessed globals are reset properly, so an early unwind cannot leave the engine reading half-initialized state.

Proof of Concept

We validated the issue without weaponizing it. We built debug PHP from source for both the vulnerable (8.2.34) and patched (8.2.35) releases and ran two checks:

- Trigger: a single unauthenticated multipart upload, shaped to exhaust `memory_limit` from inside the `session.upload_progress` handler (the same inputs PHP’s own `oom_rfc1867_upload_progress` test uses), reaches the out-of-memory window with no authentication and no application cooperation.

- Patch check: running PHP’s own OOM regression tests – the ~77 `oom_*` tests that shipped with the fix – against each build, the patched 8.2.35 passes all of them while the unpatched 8.2.34 fails 7 (the upload-progress session decode, a delayed `__unserialize()`, shutdown-after-OOM, multipart header OOM, and more).

Finding If You’re Affected

- Run php -v on each host and image, and check phpinfo() for the web SAPI, which can differ from the CLI. Include images built outside standard pipelines.

- Check if your PHP servers are publicly facing

We created this tool to help you find if you’re affected.

Conclusions

Critical vulnerabilities in widespread core infrastructure represent an escalating operational risk—a challenge amplified by the speed at which AI models make vulnerability research and exploit generation faster and cheaper. When zero-days or unpatched flaws hit ubiquitous software like PHP, the gap between initial disclosure and effective remediation creates immediate, high-stakes turbulence for organizations worldwide.

The early leak of these PHP vulnerabilities triggered an all-too-familiar “information vacuum.” In the hours preceding official patches, security feeds on platforms like X and LinkedIn were flooded with half-tested mitigations, AI-hallucinated fixes, and dubious detection scripts. This environment creates two major risks:

- Social Engineering of Security Teams: Threat actors routinely exploit early panic by publishing fake PoC exploits, backdoor-laden detection scripts, or untested patches aimed directly at tricking security engineers into compromising their own networks.

- Operational Blind Spots: In the absence of confirmed technical vendor advisories, even well-intentioned community research remains speculative and can lead to ineffective mitigations or unnecessary service downtime.

When high-severity vulnerabilities leak without complete vendor details:

- Prioritize Isolation Over Quick Fixes: If an unpatched service is exposed and vendor guidance is pending, temporarily isolate or take sensitive instances offline rather than applying unverified community scripts.

- Rely Strictly on Official Sources: Trust only vendor-validated advisories, official core repository commits, and verified security advisories before applying fixes or changing system configurations.

- Audit Shadow Assets: Ensure your security operations team has full visibility into where vulnerable runtimes actually live within your infrastructure.

How OX Security Can Help

OX can find every PHP runtime across your container images and cloud workloads, including those deployed outside standard processes, so you know exactly what needs patching.

LiteLLM got hijacked again: the AI gateway used to route traffic to dozens of LLM providers shipped a credential stealer with remote access built in

Overview

On October 21, 2026, a malicious version of LiteLLM (version 1.107.0) was published to PyPI. LiteLLM is one of the most popular open source gateways for routing requests to LLM providers, which means it usually sits right next to an organization’s most valuable AI and cloud credentials.

The malware combines two threats in one package: an infostealer that harvests secrets from the machine, and a remote access trojan (RAT) that lets the attacker connect remotely and control the affected machine.

The malicious code was injected only into the “wheel” package, so reviewing the repository and the “clean source” would not have revealed anything wrong. The malware also contacts the URL litellm[.]dev, which is an attacker bought domain that could easily be seen as a legitimate domain instead.

This is the second time LiteLLM has been hijacked this year. In March, versions 1.82.7 and 1.82.8 were compromised in the TeamPCP campaign. This time the attacker used different tooling and infrastructure. PyPI has since quarantined the malicious release.

Compromised Packages

Who is affected

Anyone who installed or upgraded to litellm 1.107.0 from PyPI, on any operating system (macOS, Linux or Windows)

Impact

- The malware runs every time Python starts on an infected machine, even if the project never uses LiteLLM. Simply having the package installed is enough.

- Once running, it can steal LLM provider API keys, cloud credentials, environment variables, and the credentials stored in a LiteLLM proxy’s own database. The stolen data is sent to a lookalike domain built to blend in with legitimate LiteLLM traffic.

- The RAT component checks in with the attacker regularly, so a compromised machine can receive new malicious code at any time.

Recommended Actions

Immediate Actions:

- Check every environment, container and CI pipeline for litellm 1.107.0, and pin LiteLLM to the safe version 1.106.0.

- Treat any machine that installed 1.107.0 as fully compromised. Isolate it from the network before cleaning it up.

- Rotate every secret that machine could reach: LLM provider API keys, cloud credentials, database passwords, SSH keys and CI tokens.

- If you run a LiteLLM proxy, rotate the provider keys stored in its database as well.

Technical Analysis

The malware is heavily obfuscated with multi-stage layers of command execution, the first two files that run inside the WHL file are “cook.py” and “sitecustomize.py”.

“sitecustomize.py” contains a RAT behavior and isn’t obfuscated at all, while “cook.py” contains a base64 encoded script inside.

The malware contains a configuration to check every 1 hour the configuration from the remote server. Additionally, it reads the remote C2 server from a GitHub URL, and parses the IP address of the C2 from it – then starts the connection.

The malware executes code it receives from the get_running_loop function

All of the malicious C2 RAT logic sits inside the “sitecustomize.py” file.

The infostealer logic sits under “cook.py” after deobfuscation, where it targets mostly configurations, cookies, API keys and cloud data. Crypto-stealer behavior is absent from this malware, showing that the threat actors aim to steal personal and organizational data rather than being directly financially motivated.

Reading Google Chrome profile data

Directly accessing user passwords from the browser data

Reading command line history from both Mac, Linux and Windows, including Python history and others:

Targeting cloud platform keys such as AWS and Azure

Targeting GitHub credentials

Targeting AI tools such as Claude Code, GitHub Copilot, Cursor

The malware sends the stolen information to litellm[.]dev – which isn’t is an attacker bought domain, not a LiteLLM server.

Conclusions

Threat actors compromised LiteLLM once again, this time in a way that avoids detection by pushing the malicious code directly inside the wheel file, where many scanners and detection tools might miss it.

While this might look like “yet another PyPI malware”, hiding inside the wheel file is one of the new ways attackers use to stay hidden and bypass common detections, like in npm, whenever a new protection is added – such as blocking preinstall hooks, threat actors will go out of their ways to find new techniques to reach their goals and execute code without being detected.

If you’re yet to pin versions or add a time-based installation delay, this should be yet another wake up call to take the time and do so before it is too late. Once these passwords and credentials are out, remediation will take longer than it takes threat actors to get what they want.

How OX Can Help

litellm 1.107.0 is included in the OX Security malware database.

OX customers using VibeSec who try to install the malicious version will be blocked by the platform and pointed to a safe version.

OX customers pushing code with the malicious version as a dependency will also be blocked by the OX platform pipeline scan.

List of IOCs

- http://www[.]litellm[.]dev/healthcheck

- litellm[.]dev

- https://raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt

- XWiA8gZNa7NcX2XRoAEb

—–BEGIN PUBLIC KEY—–

MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvxRBQMVXDXVskKS47haU

PZZ9wdcZInzptCsemXSx/8GMLGdCvOk3oX57m8QYZpdiUfhoT+zSMzfo22UteQWp

2tumv3HXXMMYgXEy8NXLjt78v1ciZQAj3CTOihhpvnRJiSfkD7DWG2348awGLxbS

XULT7tLejuyR6oDMz9mTT6faytJTWZFg+W88JJNJ4m8TBXfjzgsqXU+/AWvEcKMF

1KpBwikJqC4mwXm3pXaNQbp/AFJnmb6jzs0D2xPEabx6/deqqnHTzvQj3U4nbSHL

QTub1blDqjAVe5elVg8d5X75volMNZ/LoCE14JuVql878yM3BZ/OSqLPhqq6cB6n

wJJkrgFCPZ0LGrh3Wpoiqweh47eKnZ0cIyRV8lrB3vWD6fsvewjUAbWYl8YxfalZ

LBBLGTClDR4nuFYSV27c/7O58sgbEnjm5PD64S5oa2fZwfXyMv4GfgRT9J8JJ08w

LYhY84j7kcMRLZaIWLjFWgDRNOVznmSGJqfMBC+rBjHtT+NAlGJQDRhu3ufOdWi/

5iCqZ2H4iyy2kfRfmeHJJvAhLqUip0RNRtFLF8igYorIMLPbPon/t853IV14CDpd

opXR2WQ3Ipvr6nlR6ZxwVvMERW7mBCsObJuSuSEjJSoPmXKOMqIKvuqdHE4FTOiF

j8VSOdZz6ncfk+oJtzh0cZ8CAwEAAQ==

—–END PUBLIC KEY—–

Three CVSS 9.2 vulnerabilities in the Python imaging library, allow remote code execution and heap corruption via a single malicious image upload

Overview

Three critical Pillow vulnerabilities (CVSS 9.2, disclosed 2026-10-19) let a crafted EPS, TIFF or JPEG file trigger command execution or heap corruption in any Python service that processes user-supplied images. All are fixed in Pillow 13.0.0. The excerpts below are from the vulnerable source.

Pillow is one of the most popular Python packages, and the most popular image processing library, with an estimated 436M monthly downloads.

What is Pillow?

Pillow is an image-processing library for Python – a maintained fork of the original PIL (Python Imaging Library). It opens, converts, resizes, thumbnails and saves images across dozens of formats (JPEG, PNG, TIFF, GIF, WebP, EPS and more), and is a near-ubiquitous dependency: web frameworks (Django/Flask image handling), thumbnail and avatar pipelines, document and PDF tooling, and most Python machine-learning and computer-vision stacks pull it in directly or transitively.

Because it routinely parses untrusted, user-supplied image bytes, a memory-safety or injection bug in Pillow is reachable from a plain file upload across a huge range of services.

Compromised Packages

CVE-2026-112900 – EPS argument injection -> RCE

Pillow renders EPS images by shelling out to Ghostscript. `EpsImagePlugin.Ghostscript` passes the caller-controlled input filename after `-f` without converting it to an absolute path, so a filename that starts with `-` is parsed by Ghostscript as an option. Combined with Ghostscript’s `@argfile` syntax (a leading `@` names a file whose contents become extra arguments) and control of that file, an attacker who controls the filename Pillow opens can inject Ghostscript options and run arbitrary commands – even under the default `-dSAFER`.

CVE-2026-112393 – TIFF write heap overflow (BytesIO)

When a compressed TIFF is saved to a file-like object with no real OS file descriptor (e.g. `io.BytesIO`), Pillow routes libtiff’s output through its `_tiffWriteProc` callback. The grow loop sizes the reallocation from `state->size` (the prior buffer size) instead of `state->loc` (the current write position), so for output larger than 64 KiB libtiff can seek past the buffer and `_TIFFmemcpy` writes at `state->loc` beyond the allocation – a heap overflow, plus disclosure of stale heap bytes in the unwritten alignment gaps. Saving to a real file path (which has a `fileno()`) is not affected.

CVE-2026-112403 – JPEG draft/thumbnail heap overflow

Pillow’s JPEG decoder writes a full-width scanline into `state->buffer`, which is sized from the tile / draft extents (the unpacker), not from the JPEG header. An attacker who feeds a crafted 8-bit lossless (SOF3) JPEG to an application that requests downscaling via `draft()` or `thumbnail()` makes libjpeg produce lines wider than the buffer, overflowing the heap – crash, and potentially code execution. Newer libjpeg-turbo builds accept the malformed input that older libjpeg-turbo 2.x / IJG builds reject.

Recommendations

- Upgrade now. `pip install -U “Pillow>=13.0.0″` and rebuild any wheels, containers or base images that vendor it. This is the only complete fix for all three CVEs.

- Reduce the image attack surface. Accept only the formats you actually need; never pass an attacker-controlled filename to `Image.open()` for EPS, and keep the Ghostscript (`gs`) binary off hosts that process untrusted uploads (CVE-2026-112900 is only reachable when `gs` is present). Treat `draft()` / `thumbnail()` on untrusted JPEGs and TIFF saves to in-memory buffers as the sensitive paths.

On October 21, 2026, Node.js shipped security releases across all supported lines fixing a high-severity out-of-bounds write in the bundled Brotli decoder. A Node.js process that decompresses attacker-controlled Brotli data — including Brotli-encoded HTTP responses it fetches — can be driven to write past the end of its buffer, leaking memory or executing code with the process’s privileges.

What is Node.js?

Node.js is a widely used server-side JavaScript runtime that powers a large share of web backends, APIs, build tooling and serverless functions. It bundles Google’s Brotli library (`deps/brotli`) to back its built-in `zlib` Brotli support — `zlib.brotliDecompress()` / `brotliDecompressSync()`, streaming Brotli, and the transparent decoding of Brotli-encoded HTTP bodies (`Content-Encoding: br`).

Because decompressing untrusted Brotli is common (fetched HTTP responses, uploaded or proxied payloads), a decoder memory-safety bug is reachable from ordinary traffic across a huge range of services, and a WAF does not mitigate it.

Affected versions

CVE-2026-111497 – Brotli decoder out-of-bounds write -> RCE

Brotli can split literals, commands and distances into block types and switch between them mid-stream. `DecodeBlockTypeAndLength` returned a `BROTLI_BOOL`, overloading `BROTLI_FALSE` to mean both “invalid stream” (only one block type, so a block switch is illegal) and “needs more input.”

The block-switch callers treated that `BROTLI_FALSE` as recoverable – and `DecodeLiteralBlockSwitch` discarded the result entirely – so a malformed block switch did not stop decoding: the decoder continued with invalid state and wrote out of bounds.

Recommendations

- Upgrade now. Node.js 22.23.4 / 24.22.1 / 26.12.1. End-of-life lines (25.x, 23.x, = 20.x) get no fix – move to a supported line.

- Treat Brotli decompression of untrusted input as the sensitive path. Anything that calls `zlib.brotliDecompress(Sync)` on attacker data, or fetches Brotli-encoded responses (sends `Accept-Encoding: br`), including indirectly through libraries.

- Be wary of PoCs and “patch” scripts. Do not clone or run unverified exploit or patch scripts from public repos or social media; trust the Node.js advisory and the official releases.

OX Security tracked over 2.2 million publicly exposed PHP instances following disclosure. Within 24 hours, only 14,151 affected systems visible on Shodan had been patched. The rate at which critical vulnerabilities are discovered continues to outpace our ability to remediate them at scale

Overview

On October 21, PHP released emergency fixes for PHP2Shell, two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — that allow unauthenticated remote code execution in the PHP engine itself.

Governments and security agencies around the world urged organizations to patch immediately. Some took systems offline. But 24 hours later, our data shows just how slowly that remediation is actually happening.

OX Security tracked more than 2.2 million publicly visible PHP instances through Shodan over the 24 hours following disclosure. Of the 1,974,890 measurable instances running versions in the affected range after 24 hours, just 14,151 were showing one of the newly patched PHP versions.

That’s 0.7% patched.

Put another way, 99.3% were still not showing a patched PHP version 24 hours after emergency fixes became available.

And while patching accelerated over the course of the day, it barely dented the affected population. At our initial measurement, only 245 instances were showing a patched version. Twelve hours later, that number had risen to 4,519. After 24 hours, it reached 14,151.

We also broke the data down across popular PHP-based technologies including WordPress, phpMyAdmin, Drupal and Laravel. The pattern was consistent: Roughly 99% of the affected hosts we could measure were still not showing a patched PHP version.

The findings illustrate the challenge facing defenders as critical vulnerabilities and attacks happen faster than many organizations can remediate them. Even after an emergency patch, worldwide warnings and extraordinary attention, the overwhelming majority of the affected systems we could measure remained unpatched 24 hours later.

Methodology and limitations: OX Security queried Shodan over the 24 hours following disclosure. PHP versions were identified from version information exposed publicly by indexed hosts, including headers such as X-Powered-By. Hosts that do not expose their PHP version cannot be classified using this methodology and are not included in our affected-versus-patched calculations. Because Shodan is a continuously changing index, changes in the total number of indexed hosts should not on their own be interpreted as evidence that systems were patched, isolated or taken offline.

For a flaw of this severity, standard emergency playbooks dictate a ‘drop-everything’ response where patching and validation should take no more than an hour. Yet 24 hours later, 99.3% of affected systems remain unpatched. This gap highlights a dangerous disconnect: while deployment itself takes minutes, operational fear of breaking live production systems, complex dependencies, and delayed approvals still outweigh immediate security threats in the real world.

How Many PHP Instances Were Secured?

At our initial assessment, Shodan showed 2,224,364 publicly visible PHP instances. Of the instances whose versions we could classify, 1,991,515 were running versions in the affected range, while just 245 were showing one of the newly patched releases.

Around 233K instances contained an earlier version not vulnerable to PHP2Shell (PHP 5.3 and older). 

Twelve hours later, we identified 4,519 patched instances.

After 24 hours, that number had risen to 14,151 — just 0.72% of the measurable affected population.

What About PHP-Based Websites?

The same pattern appears across widely used PHP-based technologies, including WordPress, phpMyAdmin, Drupal, Laravel, Joomla, cPanel and Magento.

Among the affected hosts whose PHP versions we could identify through Shodan, roughly 99% were still not showing a patched PHP version after 24 hours.

The data covers only publicly indexed hosts that expose enough PHP version information for us to classify them, so it should not be read as an estimate of the total vulnerable population for any individual technology.

Conclusions

PHP2Shell triggered emergency patches, government warnings, and worldwide attention. Yet 24 hours later, 99.3% of the affected PHP instances we could measure were still not showing a patched version.

That gap matters beyond PHP.

Security teams are already dealing with a constant stream of critical vulnerabilities, active exploitation and software supply chain attacks. PHP2Shell arrived as organizations were also responding to incidents such as the LiteLLM compromise. When multiple emergency-grade issues arrive at once, the challenge is no longer simply knowing that something is critical. It is knowing what is exposed, what can actually be exploited, what matters most and what needs to be fixed first.

AI makes that problem harder. It is accelerating vulnerability research and making it easier to find and develop exploits for flaws buried in mature software. But organizations still have to identify affected systems, determine exposure, test updates, prioritize remediation and deploy fixes across real production environments.

We are getting faster at finding critical vulnerabilities than we are at removing them from the internet.

PHP2Shell may be an early indication of what that imbalance looks like at scale. If AI continues to accelerate vulnerability discovery, defenders will need to get better not only at patching quickly, but at understanding their attack surface, reducing unnecessary internet exposure and functionality, monitoring for exploitation, and prioritizing the vulnerabilities that create the greatest actual risk.

Finding vulnerabilities faster is only an advantage if defenders can fix them fast enough to keep up.

5 days after emergency fixes shipped, 93.6% of measurable PHP instances are still exposed

On October 21, the PHP project shipped emergency releases for PHP2Shell, a pair of critical flaws (CVE-2026-109618 and CVE-2026-109619) that give an unauthenticated attacker remote code execution inside the PHP engine itself. Security agencies issued urgent advisories, and some organizations pulled systems offline while they worked out their exposure.

In our first report, we found that 99.3% of the PHP instances we could measure were still unpatched after 24 hours. We kept watching. As of October 26, five days after disclosure, the picture has barely shifted – 93.6% still exposed. That’s roughly 15 out of every 16 hosts we can measure.

Approximately 1.33 million affected hosts run end-of-life PHP branches that no longer receive official fixes. For these systems, remediation may require a version update as well.

What we Measured

OX Security ran repeated Shodan queries from the first evening after disclosure through October 26, 2026. We classified each host by the PHP version it advertises publicly.

Hosts that hide their PHP version cannot be classified and are left out of every affected-versus-patched figure in this post.

Day by day: how far did patching get?

Our first scan, on the evening of October 21, found 2,224,364 PHP instances on Shodan. Of the 1,991,515 we could place in the affected range, only 245 were already on a fixed release. Five days later, that number is 127,430. That’s progress – a slow one.

No segment we measured has patched even a quarter of its affected hosts.

Conclusion: we missed the opportunity to get patches out the door

Remediation is too slow, while everyone panics about PHP CVEs, remediation isn’t in panic state, it barely crawls, with more headlines than fixed instances in the wild.

PHP2Shell is one of the most covered vulnerabilities of the year, and five days after the fix shipped, 93.6% of measurable instances are still exposed.

While everyone were looking at the “Steal My Bitcoin” challenge – giving a reward in the form of Crypto for whoever successfully exploits their PHP vulnerable site, we missed the opportunity to actually get our patches out the door – and now, when exploits are out there, proven in the wild and not just a speculation – we’ve left our most precious assets exposed for the next hacker to take advantage of.

TL;DR

- Security tool sprawl is the build-up of overlapping security tools that report the same risks separately and leave gaps between them.

- Consolidating static application security testing (SAST), software composition analysis (SCA), and cloud-native application protection platforms (CNAPPs) means mapping what each tool covers, unifying findings in one shared context from code to runtime, and retiring a tool only once its coverage is proven elsewhere.

- Sprawl costs application security (AppSec) programs in three ways: duplicate alerts for the same issue, coverage gaps at the seams between tools, and context lost between code and cloud.

- SAST, SCA, and CNAPP overlap where the pipeline meets the cloud, through infrastructure-as-code (IaC) and container image scanning, and stay distinct at the layer each one reads.

- The number of AppSec tools an enterprise needs is set by coverage layers, not a headcount: one source of findings per layer, and one place where those findings correlate.

- A phased plan of inventory, map, unify, and retire consolidates without losing coverage, provided a parallel run proves parity before any tool is switched off.

- Consolidating to cut license spend, or onto a loosely coupled portfolio of acquired products, trades one sprawl problem for another.

What Is Security Tool Sprawl?

Security tool sprawl is the accumulation of security tools bought to fill one gap at a time, each with its own console, policy set, and finding format, until their coverage overlaps in some places and leaves gaps in others. The result is more findings, more consoles, and less certainty about what is actually covered.

In application security (AppSec), the pattern is familiar. Static application security testing (SAST) covers first-party code, software composition analysis (SCA) covers open-source dependencies, and a cloud-native application protection platform (CNAPP) covers cloud posture and running workloads. Secrets detection, infrastructure-as-code (IaC) scanning, container scanning, and API discovery tools sit beside them, often owned by different teams. Each new category adds another tool unless an existing platform absorbs it. AI security posture management (AI-SPM) is the latest example, and it poses the same choice between one more point tool and a move to an AI-native platform.

What Does Tool Sprawl Cost an AppSec Program?

Most security leaders already suspect they have too many tools. In 2025 research by Barracuda and Vanson Bourne covering 2,000 senior security decision-makers, 65% said they have too many security tools or vendors, and 53% said their tools can’t be integrated. Those figures cover security tooling as a whole. For AppSec teams, the cost of sprawl shows up in three specific places.

#1. Alert Duplication

One vulnerable open-source package can surface three times: as an SCA finding in the repository, as a container image finding in the registry, and as a runtime finding in the CNAPP. Each arrives with its own severity score, its own owner, and its own ticket. Triage time goes to reconciling the same issue three times over, and fixes stall while teams work out whether three tickets describe one problem or three.

#2. Coverage Gaps

Tool scopes are drawn by vendors, not by risk. IaC templates can fall between a code scanner that ignores them and a CNAPP configured only for live cloud accounts. Secrets may be left to developer-side tooling that security never sees, and APIs may go uninventoried because no tool owns them. Every tool reports clean on its own scope, and nothing reports on the seams.

#3. Context Loss

Each tool sees one layer. A cloud finding without its source code can’t be routed to the developer who owns the fix, and a code finding without runtime context can’t be ranked by whether the code is deployed, exposed, or reachable. Cloud findings that lack source-code context get patched in place or parked, while code findings are prioritized on severity alone. Both teams end up working from partial evidence.

Where SAST, SCA and CNAPP Overlap, and Where They Don’t

SAST, SCA, and CNAPP overlap where the pipeline meets the cloud, and stay distinct at the layer each one reads. SAST alone reads first-party logic, SCA alone tracks dependency versions and licenses, and a CNAPP alone sees what is deployed and running.

What Each Category Covers

The Open Worldwide Application Security Project (OWASP) describes SAST as source code analysis that finds security flaws in source or compiled code, and notes that it is frequently unable to find configuration issues because they are not represented in the code. OWASP defines SCA as the process of automating application security for third-party and open-source components, including their licensing. For CNAPPs, Gartner’s mandatory features include auditing cloud configuration and identity permissions, visibility into the runtime state of workloads, and, at a minimum, IaC scanning and container registry scanning.

That last requirement is where a CNAPP reaches back into the pipeline that code security tools already cover. Dynamic and interactive application security testing (DAST and IAST) sit beside SAST as separate testing methods with their own coverage.

Vendors Are Converging From Both Sides

Category lines are blurring from both directions. CNAPP vendors now sell SAST, AppSec vendors partner with CNAPP vendors to bring runtime context into their findings, and vendors that began in open-source dependency scanning now sell SAST alongside SCA. Category labels no longer predict which tool covers what, which makes overlap harder to see from a procurement list.

One CVE, Four Detection Points

OX’s writeup of NGINX Rift (CVE-2026-42945), an NGINX vulnerability disclosed in May 2026, shows what useful overlap looks like. OX describes finding the same vulnerability at four points between the prompt and runtime:

- At the Prompt: OX VibeSec stops an AI coding assistant from suggesting or installing vulnerable NGINX versions before the code is written.

- In the Repository: OX Code finds vulnerable NGINX versions pinned in Dockerfiles, Helm charts, Terraform modules, Kubernetes manifests, and other IaC, including in container layers.

- In the Running Environment: OX Cloud inventories cloud workloads, fingerprints the NGINX version on each, and confirms which vulnerable instances are loaded and exposed to the internet.

- Through Exploitation: OX Agentic Pentester runs a specific attack sequence against the exposed instance to produce a reproducible proof of exploit.

Overlap across lifecycle stages is useful coverage when the four detections resolve to one issue with one owner. It becomes noise when four tools file four tickets.

How Many AppSec Tools Does an Enterprise Actually Need?

There is no correct number of tools. The count that matters is one source of findings for each coverage layer, and one place where those findings correlate.

NIST’s Secure Software Development Framework (SSDF), SP 800-218, is a practical way to define those layers, because it names practices rather than products:

- PW.4, Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality: Includes verifying that acquired third-party and open-source components meet security requirements, the work SCA serves.

- PW.7, Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: The work SAST serves.

- PW.8, Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: The work dynamic testing serves.

- RV.1, Identify and Confirm Vulnerabilities on an Ongoing Basis: Depends on findings from every layer once software is released.

The SSDF names tools only as examples, so it describes what must be covered rather than what must be bought. It also stops at development: cloud posture and runtime sit outside its scope, and that is the CNAPP’s layer (for how the framework applies in practice, see what the SSDF asks of AppSec teams). An enterprise therefore needs coverage for first-party code, dependencies, executable testing, cloud posture, and runtime, plus one place where findings from all of them correlate. Whether that takes five tools or one platform depends on whether those findings share context.

How to Reduce Application Security Tool Sprawl: A Phased Consolidation Plan

Consolidation works best as four phases run in order, with coverage verified before anything is switched off. The pressure behind it is broad: in Cisco’s 2025 Cybersecurity Readiness Index, a double-blind survey of 8,000 security and business leaders in 30 markets, more than 77% of organizations reported complex security infrastructures, dominated by more than ten point solutions, that impede their ability to respond to threats. Because tools are retired against their contract renewal dates, expect the work to span several renewal cycles rather than a single quarter.

Inventory

Start with a complete list of every security tool in use: who owns it, when its contract renews, which repositories, pipelines, and cloud accounts it covers, and who acts on its findings. Include the shadow tools bought by individual teams, since they often cover ground the central program assumes is uncovered, or duplicate what it already runs.

Map

Plot each tool against the coverage layers above and mark three things: layers covered twice, layers covered by nothing, and findings that duplicate across tools. The map sets the order of everything that follows. Gaps are closed first, and duplicated layers become the candidates for retirement.

Unify

Bring findings from the remaining tools into one platform that correlates them across code, pipeline, cloud, and runtime, so that a single issue carries its source, its deployment, and its reachability.

Norwalk, Conn. —

Xerox today announced it has been positioned as a Leader in Quocirca’s 2026 Automation & AI, Cloud & Technology assessment, which evaluates vendor capability across Automation & AI, Cloud, and Technology Ecosystems.

The Leader position reflects the breadth and maturity of the Xerox integrated portfolio, bringing together Automation and AI, Cloud, and ecosystem‑driven services to deliver tangible outcomes for clients. Building on a long heritage of simplifying work and modernizing workflows, Xerox now applies AI as a foundational capability across its offerings. This includes predictive maintenance, workflow automation, intelligent document processing, and production optimization, supported by cloud platforms and partner ecosystems to scale securely across distributed environments.

The ACT assessment recognizes vendors that demonstrate the strategic vision, execution strength, and integration required to move beyond standalone technologies and support enterprise‑wide transformation. Recognition in the Leader category underscores the evolution of Xerox into a services‑led, software‑enabled technology partner, helping organizations reduce complexity and adapt to changing work models.

“Xerox distinguishes itself in the ACT landscape through the depth, integration, and operational maturity of its automation, AI, and cloud capabilities,” said Louella Fernandes, CEO of Quocirca. “With intelligence embedded across devices, platforms, and services, reinforced by a strong technology ecosystem and growing IT services portfolio, Xerox exemplifies what we expect from ACT Leaders: a clear strategic vision, proven global execution, and the ability to act as a true pacesetter for customer transformation and innovation.”

The recognition also reflects the continued growth of Digital Services and Xerox IT Solutions, alongside progress integrating Lexmark, strengthening the ability of Xerox to deliver higher value, recurring digital and IT services at scale.

“This recognition reflects the progress we’ve made integrating AI, automation, cloud, and IT into a more connected platform that helps clients simplify operations and adapt more quickly to changing business demands,” said Munu Gandhi, president of Xerox IT Solutions and chief technology officer at Xerox. “As we continue to scale the business, we remain focused on delivering practical innovation, operational excellence, and long-term value for our clients.”

For more information, visit www.xerox.com.

About Xerox Holdings Corporation (NASDAQ: XRX)

Xerox has been redefining the workplace experience for over a century. As a services-led, software-enabled company, we power today’s hybrid workplace through advanced print, digital, and AI-driven technologies. In 2025, Xerox acquired Lexmark, expanding our global footprint, strengthening service capabilities, and equipping us to deliver an even broader portfolio of workplace technologies to our clients. Today, we continue our legacy of innovation to deliver client-centric, digitally driven solutions that meet the needs of a global, distributed workforce. Whether in offices, classrooms, or hospitals, we help our clients thrive in a constantly evolving business landscape.

Norwalk, Conn. —

Xerox today introduced the Xerox® C240/C245, Xerox® C255a, and Xerox® C300/C303a/C305ae color printers and multifunction printers, the first hardware offerings launched under the unified Xerox brand following the company's integration with Lexmark.

Xerox now operates as a single technology company spanning print, IT infrastructure and intelligent digital services. The updated Xerox brand identity, including the refreshed logo, reflects the next phase of transformation into a stronger, more competitive technology company. The combined portfolio reflects capabilities from both organizations, and the Xerox C240/C245, Xerox C255a, and Xerox C300/C303a/C305ae are the first products to bring that combined portfolio to market.

"The integration of Xerox and Lexmark has expanded what we can deliver, and these products reflect that directly," said Jacques-Edouard Gueden, chief revenue officer at Xerox. "This product line gives our clients in the small workgroup segment a reliable, straightforward solution built on the combined resources of both companies, and our channel partners a stronger portfolio to sell."

Designed for Small Workgroups and Hybrid Environments

The A4 small workgroup segment represents a growing area of demand, driven by the expansion of hybrid work and the need for print solutions that can be deployed without dedicated IT support. The Xerox C240/C245, Xerox C255a, and Xerox C300/C303a/C305ae address that need directly with a compact footprint, simplified setup and built-in security.

Key capabilities include:

- Ease of use: Intuitive interfaces, simplified setup and support for the Xerox® Easy Assist App and Xerox® Print and Scan Experience App help users install, manage, print and scan with ease. No IT support required.

- Performance: The Xerox C240/C245 and Xerox C255a, are designed for reliable, consistent everyday use, while the Xerox C300/C303a/C305ae are also designed to support a broader range of small workgroup needs, including more demanding environments

- Security: Built-in security features help protect devices, documents, and network access, with integrated post-quantum cryptography (PQC) support for future-ready protection against evolving cyber threats.

- Compact design: Space-efficient form factors suited for small offices and shared workspaces

- Sustainability: Energy-efficient operation and more than 50% post-consumer recycled plastic content aligned with Xerox commitment to responsible innovation

The Xerox C240/C245, Xerox C255a, and Xerox C300/C303a/C305ae are now shipping in North America, Western Europe, Australia, and New Zealand. Availability in additional regions will be announced as the global rollout continues. Learn more at xerox.com.

About Xerox Holdings Corporation (NASDAQ: XRX)

Xerox is a global technology company with more than 120 years of innovation leadership. We design, manufacture, deliver, and support print, IT, and digital services for nearly 200,000 clients worldwide. Our integrated, AI-powered portfolio includes managed and production print, document management, workflow automation, cybersecurity, cloud managed services, IT infrastructure, and collaboration technology. Serving clients from growing SMBs to 90 percent of the Fortune 500, Xerox supports leading healthcare, government, financial services, education, legal, retail, and commercial organizations. Through direct sales and a global network of channel partners, we deliver the technology, expertise, and support organizations need to operate efficiently, securely, and at scale.

-XXX-