DEV Community: kozhevniko

Two and a Half Million Hosts Still Advertise PHP 7.4

kozhevniko — Wed, 28 Oct 2026 04:01:17 +0000

Two and a Half Million Hosts Still Advertise PHP 7.4

After the PHP2Shell disclosure in October 2026, the useful question stopped being "how many servers run PHP" and became "how many run a version that will never receive a fix". The index answers that more directly than most people expect, because a surprising number of servers still volunteer their version in a response header.

What the header reveals

Queries against the ZoomEye index on 28 October 2026:

app="PHP" returns 111,072,293 matches, and app="PHP" && port=443 returns 22,706,573.
http.header="X-Powered-By: PHP" returns 46,709,646.
http.header="X-Powered-By: PHP/7.4" returns 2,650,830.
http.header="X-Powered-By: PHP/8.1" returns 530,860.
http.header="X-Powered-By: PHP/8.2" returns 796,916. The version-specific counts are the most interesting numbers here, and they invert the intuition. PHP 7.4 and 8.1 are end-of-life branches. PHP 8.2 is a supported branch that received a fix. Yet 7.4 shows up more than three times as often as 8.2, and more than five times as often as 8.1.

What that ratio means and does not mean

X-Powered-By is optional. Production hardening guides have told people to remove it for a decade, and many have. So every number above is a floor, and the population that hides its version is invisible to this method entirely.
That biases the sample in a specific direction worth naming: servers that still emit a version header are, on average, less carefully hardened than the ones that do not. Which makes the 7.4-to-8.2 ratio a conservative signal. Among servers that reveal something at all, the ageing branch dominates.
This is the practical form of the finding in the PHP2Shell analysis: 8.1 and earlier received source patches but no official binaries, and 7.x and below received nothing. A host advertising 7.4 is not "behind on patching". It is on a branch where the concept of being caught up no longer exists.

The distribution that matters for planning

Site counts do not equal organisation counts. One hosting provider's shared platform can present hundreds of thousands of domains on a single kernel and a single runtime build. That is why app="PHP" at 111 million and X-Powered-By at 46 million describe different things: the first is largely a proxy for "a web service exists here", the second is a subset that discloses a runtime identity.
For an asset owner the useful query is local and much smaller. Take your own address space, request the headers, and count how many distinct runtime versions you actually serve. Most organisations discover more versions than they expected, because the estate accumulated through acquisitions, side projects, vendor appliances and forgotten internal tools, and each has its own runtime.
The number that should concern a reader is not two and a half million. It is the count of versions in their own estate that no one is responsible for upgrading.

What can be done for hosts that cannot be upgraded

The realistic options for an end-of-life PHP host are unchanged and unpopular: take it off the public internet, put it behind a proxy that terminates and inspects, or retire it. Vendor backports exist for specific platforms — cPanel and CloudLinux shipped fixes for their PHP packages — and those cover a meaningful share of shared hosting. They do not cover a custom build on a VM that someone set up in 2019.
The detection angle is worth restating because it is cheap. CrowdStrike's published analysis of PHP2Shell describes exploitation leaving no application-level trace: the worker survives, the server returns HTTP 200, and the only artefact is a memory-limit fatal error in the web server log. An environment that does not alert on that line has no visibility into this class of attack at all.

The uncomfortable generalisation

Any runtime that advertises its version on every response is telling an attacker where to start. That used to be treated as a low-severity information disclosure, worth a note in a hardening checklist and nothing more. In a period where a pre-authentication runtime flaw can be weaponised within hours of disclosure, a version banner is a targeting signal with real value.
Removing the header does not make anyone safer. Not knowing your own version distribution does make you slower, and slower is now the expensive position.

References

ZoomEye search, queries executed 28 October 2026: app="PHP" 111,072,293; app="PHP" && port=443 22,706,573; X-Powered-By: PHP 46,709,646; PHP/7.4 2,650,830; PHP/8.1 530,860; PHP/8.2 796,916: https://www.zoomeye.org
FreeBuf report on PHP2Shell exploitation and detection characteristics, including CrowdStrike observations (22 October 2026): https://m.freebuf.com/news/508109.html
Wikipedia, PHP2Shell, for affected branches and fixed versions: https://en.wikipedia.org/wiki/PHP2Shell

12,241 LXD Fingerprints, 15 for Incus, and the Same Question About Who Can Create a Container

kozhevniko — Wed, 28 Oct 2026 01:00:53 +0000

12,241 LXD Fingerprints, 15 for Incus, and the Same Question About Who Can Create a Container

Container and virtual machine control planes sit close to the metal. A user who can create an instance on the host is not a user of an application; they are a tenant of the infrastructure, with whatever the kernel will allow.
ZoomEye measurements collected on 28 October 2026 put this in proportion. app="LXD" returns 12,241, and app="LXD" && port="8443" returns 11,685, which tells you that most indexed LXD surfaces answer on the HTTPS port rather than elsewhere. title="LXD" returns 1,137. For Incus, the community fork, app="Incus" returns 15 and title="Incus" returns 359, with title="Incus" && port="8443" at 257.

Why the numbers diverge here

LXD and Incus are related codebases serving the same role, and the fingerprint results could hardly be more different. LXD has a widely deployed application signature, so the app count dominates. Incus, newer as an independent project, is better captured by its page title than by any app signature, which is why the title count is more than twenty times the app count.
This is a general lesson about measurement rather than a special fact about containers. A fingerprint is maintained, versioned and occasionally slow to recognise a fork. Reading only the app count for a younger project will systematically undercount it, and reading only the title count for a mature one will overcount it with documentation pages and mirrors.
Neither number, in either case, indicates whether the control plane enforces authentication.

What an exposed control plane means

The administrative surface of these tools is an API. Creating an instance is a POST. Attaching a device is a PUT. Executing a command inside a running container is a documented capability, because it is exactly how an operator troubleshoots. Every one of those operations is a legitimate feature, and each is a privilege that matters when the caller should not have it.
The consequence of an unauthenticated caller reaching that API is therefore not "a container appears". It is code execution on a host that is, by design, more privileged than the workloads it contains. Container escapes are a category of vulnerability precisely because that boundary is thin; an attacker who starts on the outside of it does not need to cross anything.
The 11,685 LXD assets answering on 8443 deserve a specific reading. That port is where the HTTPS API listens by default, so a large share of indexed LXD surfaces are presenting the administrative interface itself rather than a workload. Some of those will be labs, some will be development clusters, and some will be production hosts behind a firewall rule that was widened for a reason nobody recorded.

The review that matters

Confirm whether the API requires a client certificate or a trust token before it accepts a request. Both mechanisms exist in the documented feature set, and both are configuration rather than defaults that can be assumed.
Enumerate the projects and the users who can reach them. A single-user host is a different risk from a shared host with several tenants, and the difference lives in the permission model rather than in the network diagram.
Check the listening address. A control plane bound to a private interface with a VPN in front is in a different category from one bound to a public address with a password, and the two are frequently confused when the discussion turns to "is it exposed".
Finally, look at what the host can reach. A container host has network position, storage access and often credentials for the image registry it pulls from. The blast radius of a control plane compromise is defined by the host's own privileges, not by the containers it runs.

A modest number with a sharp edge

12,241 and 15 are small numbers next to the hundreds of thousands that a web framework produces. That is the right scale for infrastructure tooling: fewer deployments, each with more authority.
The appropriate response to a small count is not indifference. It is to notice that these are the systems where a single misconfiguration has the shortest path from "reachable" to "running code". The measurement is worth taking because it is cheap, and worth acting on because the alternative is trusting a network rule that nobody has read since it was written.

References

Incus documentation: https://linuxcontainers.org/incus/docs/main/
ZoomEye query app="LXD", 2026-10-28: https://www.zoomeye.ai/searchResult?q=YXBwPSJMWEQi
ZoomEye query app="Incus", 2026-10-28: https://www.zoomeye.ai/searchResult?q=YXBwPSJJbmN1cyI%3D Measurement notes: counts were collected on 28 October 2026 through the ZoomEye SDK. They describe indexed assets and do not indicate whether authentication is enforced on any control plane.

DreamHost reset every mailbox password, and could not reach the mailbox owners

kozhevniko — Tue, 27 Oct 2026 22:02:36 +0000

DreamHost reset every mailbox password, and could not reach the mailbox owners

DreamHost forced password resets for email and FTP/SFTP users after an incident that began with connectivity problems in its File Manager interface on October 23 and spread to other services. The company blocked access for all users until they completed a reset, described the step as a precaution, and sent recovery instructions in batches over the weekend. As of reporting, the incident was still active and File Manager remained unavailable.
The company serves over 400,000 customers in more than 100 countries and supports at least 1.5 million websites and applications, including 750,000 WordPress installations. Those numbers explain why a forced reset of this kind is a logistical event rather than a support ticket.

The instruction that reveals the threat model

DreamHost told affected account holders to review each email address for forwarding rules and to remove any forwarding destination they did not recognise.
That recommendation is the most informative sentence in the disclosure. A forwarding rule is a persistence mechanism that survives a password reset, needs no malware on the endpoint, and sends copies of inbound mail to an address the attacker controls. If the company is asking customers to look for unrecognised destinations, it is treating mailbox access as something an unauthorised party may have obtained. DreamHost has not said so directly; that remains an inference from its own guidance.
The second recommendation, to change reused passwords elsewhere if the DreamHost password was used on other services, follows the same logic from the credential side.

The structural problem with mailbox resets

DreamHost said it cannot contact individual mailbox or FTP users directly. Account owners must notify their users by phone, text or another channel, because the people whose passwords were reset may be unable to reach their email at all.
This is not a communications failure specific to one provider. A mailbox is the recovery channel for most other accounts. When the mailbox is the thing being reset, the recovery path for reaching its owner runs through the mailbox itself.
For an organisation with mailboxes at a hosting provider, the practical implication is that the account owner needs an out-of-band roster of who uses which mailbox. Without it, the owner is calling people one at a time to tell them their email is locked. With it, the reset is a list and a message on a channel the users can still reach.

What the incident record does not contain

BleepingComputer reported that it contacted DreamHost several times for the number of impacted accounts and whether files or messages were exposed, and had not received an answer at publication. Long-time customers complained about the lack of detail.
That gap matters for downstream decisions. An account owner deciding whether to notify their own customers has to know whether message contents were accessible or only the login credentials. Those are different incident classes with different obligations.
The measured response is to assume the wider case until the narrower one is confirmed, because the remediation cost of the wider case is a password reset that was already forced.

A workable response for hosting customers

Start with the forwarding rules, before anything else. They are the one persistence mechanism the provider explicitly named, and they are readable from the control panel by the account owner without vendor assistance.
Then enumerate the mailboxes the account owns. The list should include role mailboxes, aliases that forward to personal addresses, and mailboxes belonging to contractors who left. A reset campaign that misses a forwarding alias leaves the attacker with a working path.
Then check for mail clients and application passwords. A hosted mailbox often has several credentials: the web login, an IMAP password in a phone, and an application password used by a form or a scanner. Resetting the account password does not necessarily invalidate those, depending on how the provider implements application passwords.
Finally, tell the users on a channel that is not the mailbox. The provider cannot, so the account owner has to.

What to ask the vendor

Two questions are worth putting to any hosting provider after an incident of this shape. Which credentials were reset, and which were not? The answer determines whether the persistence path is closed. And does the reset invalidate sessions and application passwords, or only the primary password? The answer determines what still works for the attacker.
Neither question requires the provider to publish forensic detail. Both are answerable from the systems that performed the reset.

References

[1] BleepingComputer, "DreamHost forces password resets in ongoing \"incident\"", October 26, 2026. https://www.bleepingcomputer.com/news/security/dreamhost-forces-email-ftp-sftp-password-resets-in-ongoing-incident/

Gitea at 117,523 and n8n at 420,452: The Self-Hosted Layer That Holds Your Credentials

kozhevniko — Tue, 27 Oct 2026 19:00:27 +0000

Gitea at 117,523 and n8n at 420,452: The Self-Hosted Layer That Holds Your Credentials

Source control and workflow automation have something specific in common. Both are built to remember secrets on behalf of other systems, and both are frequently published to the internet so that distributed teams and webhooks can reach them.
ZoomEye measurements collected on 28 October 2026 show 117,523 assets matching app="Gitea", 420,452 matching app="n8n" and 401,268 matching title="n8n". Those are counts of indexed assets that identify with each product. They are not counts of exposed secrets, and the difference between the two is where the operational work sits.

What these two systems store

A Gitea instance holds repositories, and repositories hold whatever developers committed. It also holds deploy keys, webhook secrets, access tokens and, in many installations, the SSH keys used to push code. An n8n instance holds workflow definitions that connect to external services, which means API credentials for those services sit inside the workflow configuration.
Both products therefore concentrate value that has nothing to do with the application itself. Compromising either does not just yield a login; it yields the set of credentials the platform was trusted with. That is the reason a public instance deserves more scrutiny than the asset count suggests, and the reason the counts deserve less alarm than a headline would give them.

The settings that decide the outcome

Gitea publishes a configuration cheat sheet with a security section, and three of its entries describe the difference between a hardened instance and an open one.
INSTALL_LOCK controls access to the installation page; when set to true, that page is no longer reachable. An instance that was set up and never locked still presents its initial configuration screen, which is an unnecessary invitation.
SECRET_KEY is generated at random on every install and the documentation is emphatic about its importance: data encrypted with it, including two-factor secrets, cannot be decrypted if it is lost. A key that was copied between environments to make migration easier weakens that guarantee everywhere it was copied.
DISABLE_REGISTRATION defaults to true in the documented configuration, and when enabled only administrators can create accounts. The failure mode here is familiar: a registration page left open on an instance that was meant for a small team, discovered later when unfamiliar accounts appear in the user list.
For n8n, the relevant surface is the administrative one. The n8n documentation separates deployment and configuration from workflow building, and the configuration area includes instance owner management and user administration. An instance where every visitor can create an account, or where the owner account still uses the address set during setup, has delegated its credential custody to whoever finds it first.

Why the fingerprints differ so much from each other

Gitea at 117,523 and n8n at 420,452 is a wide spread for two self-hosted tools. Part of it reflects adoption: workflow automation spread quickly because it solves an immediately visible problem, while self-hosted Git appeals to organisations with a specific reason to keep code on their own hardware.
Part of it reflects deployment shape. An n8n instance has to be reachable by webhooks from external providers, which pushes it toward a public address. A Gitea instance can be reached through a VPN by its developers, which lets it stay private. The count is therefore shaped by architecture as much as by popularity.
For n8n the title match and the app match are close, 401,268 against 420,452, which suggests the fingerprint and the page title agree on most indexed assets. For Gitea there is no comparable second signal in this measurement, so the 117,523 figure should be treated as a floor rather than a census.

A review sequence that takes an hour

Confirm the version and the registration policy first. On Gitea, check INSTALL_LOCK, DISABLE_REGISTRATION and whether REQUIRE_SIGNIN_VIEW is set for instances that should not be browsable anonymously. On n8n, check whether user management is enabled and who holds the owner account.
Then enumerate what the instance can reach. For Gitea, list deploy keys and webhook targets; a stale key from a departed contractor is a finding that no scanner will report. For n8n, list the credentials attached to active workflows and confirm each one is still needed. Automation platforms accumulate connections because removing one risks breaking a process nobody remembers writing.
Finally, decide whether the instance should be public at all. A repository server that only serves a known set of developers does not need to answer the open internet, and an automation platform can often be reached through a reverse proxy that terminates at a smaller set of allowed paths.

What the numbers cannot tell you

Neither 117,523 nor 420,452 says anything about configuration. An instance counted under app="n8n" may enforce single sign-on, restrict registration to an allowlist of domains and log every login, or it may be a default installation that somebody started to evaluate in 2024 and never removed. The fingerprint identifies the software; only an internal check identifies the posture.
The other limitation is deduplication. A single organisation may publish several instances, and a hosting provider may run hundreds behind one domain pattern. Aggregate counts mix both, so a share-of-population argument built on them will be approximate.
What survives is the specific point. These two platforms are worth counting because of what they hold rather than because of how many there are, and the settings that decide whether the holding is safe are documented, named and checkable in a single session.

References

Gitea documentation, config cheat sheet, security section: https://docs.gitea.com/administration/config-cheat-sheet
n8n documentation: https://docs.n8n.io/
ZoomEye query app="Gitea", 2026-10-28: https://www.zoomeye.ai/searchResult?q=YXBwPSJHaXRlYSI%3D
ZoomEye query app="n8n", 2026-10-28: https://www.zoomeye.ai/searchResult?q=YXBwPSJuOG4i Measurement notes: counts were collected on 28 October 2026 through the ZoomEye SDK. Indexed-asset counts change as hosts appear, disappear or are reclassified, and they do not indicate vulnerability, misconfiguration or exposed credentials.

Verifying exposure to CVE-2026-6653 without guessing

kozhevniko — Tue, 27 Oct 2026 16:01:12 +0000

Verifying exposure to CVE-2026-6653 without guessing

An exposure number is only useful if the query behind it is honest about what it measures. For CVE-2026-6653 the honest reading starts with a narrow question: which services can be identified as carrying libxml2, and what would have to be true before any of them could be called vulnerable?

Start from the verified record

The CVE record states the flaw is a use-after-free in xmlParseInternalSubset, from GNOME libxml2 2.9.11 through versions before 2.11.0, triggered by maliciously crafted XML input with improper entity resolution handling. The solution is to upgrade to libxml2 2.11.0 or later.

That range matters for verification, because the library in a container image is frequently newer or older than the host's package manager suggests. Checking the actual shipped object, not the declared dependency, is the first reliable measurement.

Query the fingerprint, then stop

The verified ZoomEye product query is banner="libxml2". It returned 341 matching assets when it was checked on 2026-10-27. That is a fingerprint count: assets whose banners identify libxml2 or a service built on it. It is not a count of vulnerable installations, and treating it as one would overstate the finding in any report.

A CVE-scoped query for this defect returned no indexed results in the same session, which is typical for a recent identifier. Absence of a CVE-mapped result is a gap in indexing, not evidence of safety.

Turning the count into a defensible statement

One defensible sentence is enough for most reports: 341 fingerprinted libxml2 assets appear in internet-wide scan data, the affected version range is 2.9.11 before 2.11.0, and confirmation requires a host-side version check.

That phrasing keeps three things separate: what the scan data shows, what the vulnerability record says, and what has been confirmed on a specific system. Mixing them turns exposure figures into claims nobody can defend later.

Maintainer checklist

Continue by listing every service that parses XML from an untrusted source, checking the shipped libxml2 version in each deployment artefact, and scheduling the upgrade to 2.11.0 or the vendor backport. CERT-Bund's product references for Red Hat Enterprise Linux, Rocky Linux, Oracle Linux, Amazon Linux 2, IBM Security Verify Access and IBM Power HMC show the breadth of the backport work.

Search dork: banner="libxml2"

ZoomEye search link: https://www.zoomeye.ai/searchResult?q=YmFubmVyPSJsaWJ4bWwyIg%3D%3D

Why Internet-Facing Media Servers Stay Vulnerable: Plex Exposure in Numbers and Practice

kozhevniko — Tue, 27 Oct 2026 13:00:19 +0000

Why Internet-Facing Media Servers Stay Vulnerable: Plex Exposure in Numbers and Practice

Patch a media server and the household notices nothing. Break remote playback while tuning a firewall and the complaints arrive within minutes. That asymmetry explains a stubborn pattern in exposure data: media servers stay reachable long after the vulnerabilities that threaten them have publicly documented fixes.
CVE-2026-96656, an external control of file name or path flaw in Plex Media Server before 1.43.3.10861, is the concrete case here. It is the file-write stage of the exploit chain publicly called Plex2Shell, chained with CVE-2026-96652, CVE-2026-96654 and CVE-2026-96655 to achieve unauthenticated remote code execution. The vulnerability is patched. Reporting from boredhackerblog and Ars Technica describes active exploitation in October 2026, and CISA added the four identifiers to its Known Exploited Vulnerabilities catalog on 20 October 2026. The only remaining variable is how many deployments were never updated.

What the measurement actually shows

For this article, ZoomEye was queried with three product-oriented fingerprints. product="Plex Media Server" returned 508,009 assets, app="Plex" returned 508,033, and app="Plex Media Server" returned 507,974. A CVE-scoped filter, vul.cve="CVE-2026-96656", returned zero.
Those numbers deserve precise reading. They count internet-reachable assets matching Plex fingerprints, not vulnerable installations and not compromised hosts. The zero CVE count is a statement about ZoomEye's CVE indexing for a newly assigned identifier, not evidence that exposure is low. Anyone quoting "half a million vulnerable servers" from these results is overstating the data; anyone concluding "fewer than expected" from the zero is misreading it.
What the figures do establish is scale. Roughly half a million Plex-fingerprinted services are visible from the public internet. The exploit chain requires only that a fraction of them run a build older than August 2026.

Why Plex specifically accumulates exposure

Three product properties interact badly.
First, remote access is a headline feature. Plex documents an "Enable Remote Access" flow that will attempt automatic router configuration through UPnP or NAT-PMP. The user toggles a setting, the router opens a port, and the resulting inbound rule is forgotten. Nobody writes a change record for it.
Second, the deployment context is domestic. Media servers live on consumer routers, NAS appliances and small VPS instances without central inventory, endpoint detection or maintenance windows. Updates happen when a user notices a prompt or a playback problem, not on a schedule.
Third, the failure mode of exposure is invisible. A compromised media server still streams video. Mining payloads may slow the machine, but users blame transcoding. A proxy backdoor generates outbound traffic that home routers do not report. Nothing in the interface says "you are hosting someone else's attack infrastructure."

The exposure-management translation

The practical question is not how many Plex servers exist, but which ones an organisation is responsible for. Four checks turn the exposure number into a decision:

Inventory by product, not by port. Query asset fingerprints for the product and compare against the configuration management database. Instances that appear in the query but not in the inventory are shadow deployments.
Test reachability from outside. Port 32400 reachable from the internet, whether by direct forward or by UPnP, is the condition the chain needs.
Verify version. A build below 1.43.3.10861 is affected regardless of how private the deployment feels.
Check egress. A media server has no legitimate reason to open long-lived connections to unfamiliar hosts or to saturate CPU outside playback windows. For home users the equivalent is simpler: disable automatic port mapping unless remote access is genuinely needed, forward a non-default port if it is, and keep Plex current.

Where the vulnerability sits in the chain

CVE-2026-96656 is rated 8.6 for a reason. File-write primitives are often dismissed as post-authentication housekeeping, but here the write target is a directory the application loads executable content from. An attacker who influences the path does not need memory corruption or a second bug to gain execution; they need the application to reload its codec libraries. Combined with the token disclosure in CVE-2026-96654 and the request primitives in CVE-2026-96652 and CVE-2026-96655, the write becomes the terminal step that converts a well-behaved media service into an attacker-controlled process.

Remediation

Upgrade to 1.43.3.10861 or later and confirm the version in the web interface rather than trusting an update prompt. Remove public reachability where remote access is not required. Treat previously exposed hosts as suspect: review the Codecs directory, inspect running processes, audit outbound connections, and rotate account sessions. For organisational deployments, add media-server fingerprints to continuous external attack surface monitoring so the next chain is caught by inventory rather than by incident response.

References

CVE-2026-96656 record, CVE.org.
Plex Media Server security release thread, forums.plex.tv.
Plex support documentation, Remote Streaming and remote access configuration.
Ars Technica, reporting on exploitation of the Plex vulnerabilities, October 2026.
CISA Known Exploited Vulnerabilities catalog, October 2026 additions.
ZoomEye queries executed for this article: product="Plex Media Server" (508,009), app="Plex" (508,033), app="Plex Media Server" (507,974), vul.cve="CVE-2026-96656" (0).

CVE-2026-95101: How HTTP/3 Request Smuggling Slipped Past client_max_body_size

kozhevniko — Tue, 27 Oct 2026 09:41:19 +0000

CVE-2026-95101: How HTTP/3 Request Smuggling Slipped Past client_max_body_size

NGINX 1.30.6 and 1.31.7 close a parser bug that turned one variable into two jobs. CVE-2026-95101 lets an HTTP/3 client inject extra bytes into a proxied request, or deliver a body larger than client_max_body_size allows, by exploiting how unknown QUIC frames are skipped.

The mechanism

The HTTP/3 parser in NGINX tracks the remaining length of an unknown frame it is skipping. It also tracks how many DATA bytes to pass to the backend as request body. One field was used for both.

When an unknown frame arrived split across two reads, the leftover skip count from the first read was not cleared before the second read interpreted the field as a body count. The parser then treated the remainder of an unknown frame as DATA and forwarded it to the upstream. Because the bytes never passed through the body-size accounting, client_max_body_size never saw them.

F5 scores the flaw 6.9, the lowest of the five in this release, and credits Hansol Lee of GOTROOT.

Exploitation conditions

Two conditions must both hold. The server must terminate HTTP/3, which in NGINX means a listen directive carrying quic. And proxy_request_buffering must be left at its default of on, which is what causes NGINX to buffer and forward the request body rather than stream it through unchanged.

The affected range is 1.25.0 through 1.31.6, which tracks the maturity of the HTTP/3 implementation rather than the older TLS and rewrite code paths.

Why this is a smuggling class bug

The consequence is that the request the backend receives is not the request the client sent, as measured by NGINX's own accounting. Extra bytes appended to a proxied request are the definition of request smuggling, and smuggling desynchronises the front end from the back end.

A backend that applies its own limits, or that parses the body differently from NGINX, will act on a request NGINX never validated. On a typical deployment where NGINX fronts an application server, that is enough to reach endpoints the operator believed were protected by the front-end size limit.

The 6.9 score reflects the narrower precondition set: HTTP/3 is not ubiquitous, and a deployment without a QUIC listener is untouched. Where HTTP/3 is enabled, the flaw is a genuine front-end bypass rather than a simple denial of service.

Affected products and scope

NGINX open source from 1.25.0 through 1.31.6 is affected when HTTP/3 is enabled. F5's product advisories cover NGINX Plus and related F5 products separately, and several of those listed no fixed build as of 15 October, so Plus customers should read the F5 advisory rather than assume the open-source release date applies to them.

Remediation

Upgrade to 1.30.6 or 1.31.7.

Where an upgrade has to wait, F5's workaround is proxy_request_buffering off. With buffering disabled, NGINX streams the body instead of building a buffered copy from the miscounted DATA bytes, which removes the path that carried the injected content. The tradeoff is real: streaming changes how the upstream sees slow clients, so a team should test the change against its timeouts before rolling it out.

Disabling HTTP/3 entirely also removes the exposure, at the cost of losing QUIC benefits. For internal services where HTTP/3 was enabled speculatively, turning it off until the upgrade lands is the simplest decision.

Checking a server

Run nginx -T and search for listen lines containing quic. For each, check the value of proxy_request_buffering on the locations that proxy to a backend. A QUIC listener with default buffering is the exposed combination.

This is one of the few flaws in the October release where the condition is partly on by default, which means version alone is a stronger signal here than for the memory-safety bugs: an affected version with HTTP/3 enabled and default buffering is exposed, regardless of what other directives the configuration uses.

Sources

NGINX security advisories: https://nginx.org/en/security_advisories.html
F5 advisory K000162613: https://my.f5.com/manage/s/article/K000162613
HTTP/3 parser fix commit: https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64
proxy_request_buffering documentation: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering
NGINX download page: https://nginx.org/en/download.html

When the hosting provider becomes the trust anchor

kozhevniko — Tue, 27 Oct 2026 06:00:39 +0000

When the hosting provider becomes the trust anchor

A customer renting a virtual server delegates the layer below the operating system to the provider. The FirstVDS incident reported on 19 October 2026 shows what that delegation costs when the delegated layer is breached: passwords, cloud credentials and wallets were copied from customer disks without the virtual machines themselves being compromised.
The interesting design question is not how the intruder entered VMmanager 6. It is why a hosting customer had cloud credentials and wallet keys sitting on a disk that someone else's management plane could mount.

What the provider controls

The provider controls the hypervisor, the storage backend and the management platform that ties them together. It also controls the audit trail for operations at that layer, which decides whether a disk attach is visible to anyone. None of these are usually in the customer's contract in specific terms.
A customer can influence them at three points: the choice of provider, the contract terms covering management-plane access, and the architecture of the workload itself. The third point is the only one fully under the customer's control, and it is the one most often skipped.

Designing for a management plane you do not own

The principle that follows from this incident is that a server disk should not hold anything whose disclosure is unrecoverable. Private keys for cryptocurrency wallets fit that description exactly, because a copied key cannot be revoked. Cloud API keys fit it partly, because they can be revoked if the owner learns quickly enough.
Credentials that must be present on the host can be narrowed in scope and lifetime. Short-lived tokens issued to the workload, scoped to a single resource, limit what a copied disk yields after the token expires. Secrets that cannot be narrowed, such as long-lived wallet keys, belong on hardware the customer physically controls or in a signing service that never exports the key.

What the contract should cover

Three clauses are worth negotiating. The first is notification: what the provider commits to disclose, to whom, and in what timeframe, when the management plane is breached. FirstVDS notified customers and told the recipients to assume their data had been stolen, which is the right instruction and also an admission that per-tenant scoping was impossible.
The second is audit visibility: whether the customer can obtain records of management actions affecting their instance, including disk-level operations. The third is isolation: whether the management plane is reachable from the tenant network or from the public internet at all.

The vendor side of the same question

ISPsystem, the platform vendor, published interim guidance on 20 October asking customers to block inbound and outbound connections to the platform and to the virtualisation nodes, to restrict SSH to trusted addresses and to rotate all passwords. That guidance is aimed at operators, and it works only if operators pass the relevant parts down to their own customers.
A hosting provider that quietly applies the patch and says nothing leaves its tenants holding compromised credentials. Telling tenants which secrets were exposed, at the granularity the provider actually has, is the part of incident response that determines the outcome for them.

Measuring the population that faces this

The exposure measurement is crude but useful for scale. On 27 October 2026, ZoomEye matched 2,823 interfaces for title="VMmanager", with 1,035 in Russia and 1,788 elsewhere. That suggests a large number of businesses depend on the same delegated trust model, in many jurisdictions, and that a customer wanting audit visibility is asking for something unusual rather than standard.

References

The Record, "Hackers steal customer data from major Russian hosting provider FirstVDS", 19 October 2026. https://therecord.media/russia-cyberattack-firstvds-cloud
ISPsystem, "Security Incident Involving a Vulnerability in a VMmanager 6 Build", 20 October 2026. https://www.ispsystem.com/news/vulnerability-incident
ZoomEye queries executed 27 October 2026. Counts describe reachable management interfaces, not confirmed vulnerable installations.

A password you cannot change: CVE-2026-114119 and the hardcoded SQL Server administrator in Bp Premier

kozhevniko — Tue, 27 Oct 2026 03:02:28 +0000

A password you cannot change: CVE-2026-114119 and the hardcoded SQL Server administrator in Bp Premier

Most hardcoded-credential advisories describe a key that the vendor rotates in an update. CVE-2026-114119, published on 21 October 2026 for Best Practice Software's Bp Premier before 1.14.1.1128, describes something less tractable: a Microsoft SQL Server administrative password that is shared across all installations and that, according to the record, cannot be changed without breaking the application. That detail changes the remediation conversation from "patch and rotate" to something closer to network architecture.

What the record states

The NVD entry says Bp Premier before 1.14.1.1128 uses a hardcoded Microsoft SQL Server administrative password shared across all installations and not changeable without breaking the application. An attacker with network access to the database instance can authenticate as sysadmin, bypass application authentication, and execute operating system commands as SYSTEM.
Three facts follow directly, and each one carries its own consequence:

The credential is the same everywhere, so the population of affected deployments is the population of installations, not the subset that was misconfigured.
The password cannot be rotated by the customer, so a change to the credential requires a vendor release.
The privilege level is sysadmin on SQL Server, which is a path to operating-system command execution, not just to the application's data. The record references a GCVE entry from the Australian CI-ISAC vulnerability database and the Bp Premier Oxford SP1 release notes. Bp Premier is clinical practice management software used in Australian general practice, which is relevant to the impact assessment rather than to the technical mechanism.

Why "cannot be changed" is the important phrase

An embedded credential in an installer is a common finding. What usually limits the damage is that the operator is expected to change it, and auditors can check whether they did. The advisory removes that mitigation: rotation is not a documented operational step because the application depends on the value.
Two control surfaces remain.

Network reachability to the database port. If nothing on the network except the application server can reach the SQL Server listener, the shared credential cannot be used from elsewhere. This is the control that matters, and it has to be enforced on the host firewall and the network segment, not on the application's own login form.
The vendor's replacement mechanism. A fixed build at 1.14.1.1128 or later implies the vendor changed something. Whether the new design removes the static credential, rotates it per installation, or merely changes the value is not stated in the advisory, and it should be confirmed with the vendor before assuming the underlying class of risk is gone.

The clinical context is not decoration

It would be easy to file this under "medical software, handled by someone else". The data behind that SQL Server instance is a practice management database: patient demographic records, appointment history, billing and Medicare claim data, and correspondence. The Australian context adds a specific reporting regime; a sysadmin-level compromise of that instance is a notifiable event under the Privacy Act 1988 (Cth) and the Notifiable Data Breaches scheme if it results in unauthorised access to personal information. This article does not assess whether a specific incident is notifiable, because that depends on facts a CVE record cannot supply.
The practical consequence is that the investigation burden is higher than the technical one. A shared credential means you cannot prove non-use from authentication logs alone if the attacker's access looked like the application's access.

Verification for a practice or a managed service provider

Build check. Confirm Bp Premier is at 1.14.1.1128 or later. The release notes describe Oxford SP1 at 1.14.1.1129, so the fixed line is present in the SP1 train.
Port exposure. From a workstation that should not have database access, attempt a TCP connection to the SQL Server port on the Bp Premier server. A successful connection is the finding; no credential should be sent in this test.
Firewall rule review. The rule should permit the application server and the backup system and nothing else. A rule scoped to "the clinic subnet" includes every workstation and every unpatched printer with a management interface.
Local firewall on the server. Confirm the Windows firewall profile is active and does not include an allow-any rule for the SQL Server port. This matters when the network rule is managed by someone else.
Managed service providers. If a third party hosts the instance, ask for the same three facts in writing: build, network path, and whether they have any monitoring that would distinguish an interactive sysadmin login from the application's own service account.

What to ask the vendor

Two questions are worth putting in writing rather than inferring. First, whether the fixed build removes the static credential or replaces it with a different static value, since the two answers imply different long-term risk. Second, whether the vendor can detect an administrative login that did not come from the application, which determines whether an affected practice could ever confirm non-exploitation.
Neither question is answerable from the advisory, and both change what a practice should do next week.

Limits

This article does not assert exploitation in the wild, does not describe the credential, and does not claim that a fixed build eliminates every related risk. The CVSS information in the record is as published; the severity of a database-credential exposure is highly dependent on network position, which the advisory cannot assess. The clinical and regulatory context is provided as background for prioritisation, not as a legal determination.

References

NVD record for CVE-2026-114119: https://nvd.nist.gov/vuln/detail/CVE-2026-114119
VulnCheck advisory: Best Practice Software Bp Premier hardcoded SQL Server administrative credential: https://www.vulncheck.com/advisories/best-practice-software-bp-premier-before-1.14.1.1128-hardcoded-sql-server-administrative-credential
GCVE-123-2026-0001 record, Australian CI-ISAC: https://def.ci-isac.org.au/vuln/records/GCVE-123-2026-0001.json
Bp Premier Oxford SP1 release notes: https://kb.bestpracticesoftware.com/bppremier/oxford/WhatsNew/BpPremier_OxfordSP1_ReleaseNotes.htm

Hunting CVE-2026-111497: what a Brotli decoder crash looks like in production telemetry

kozhevniko — Tue, 27 Oct 2026 00:01:03 +0000

Hunting CVE-2026-111497: what a Brotli decoder crash looks like in production telemetry

Detection work for a decoder bug starts with an uncomfortable admission: if CVE-2026-111497 is exploited successfully, the most likely observable event is a process that dies, and most organisations already have thousands of those.

The mechanics that shape the signal

The bundled Brotli decoder treats an invalid block switch as a temporary need for more input rather than a permanent format error. A caller feeding the stream keeps appending bytes into an eight-byte internal buffer, and the write eventually runs past its end. The advisory lists three consequences: a crash, disclosure of process memory, and remote code execution.
Each consequence produces a different telemetry shape, and only one of them is loud.

Crash-driven signals

A malformed Brotli stream sent to an endpoint that inflates request bodies can terminate the worker. In a Node.js service the usual fingerprints are an uncaught native failure that bypasses the framework's error handler, an exit code inconsistent with ordinary application errors, and a restart loop concentrated on one route.
Useful pivots are the request log line immediately before the crash, the Content-Encoding value on that request, and the client address. A single malformed body producing one crash is a bug report. Repeated malformed bodies from one source against the same route is a probe.

Memory disclosure signals

Disclosure is harder to see because it arrives as normal-looking output. If an attacker can read past the buffer, the leaked bytes appear in a response the application happily returns: a parsing error message containing garbage, a decoded string with unexpected binary, a field that should have contained JSON.
Detection here is largely anomaly work. Look for responses whose decoded content fails validation in a way that includes high-entropy byte sequences, and for endpoints that return decoder diagnostics to clients at all. An application that echoes internal exception text is handing over a channel for anything the decoder leaks.

Execution signals

Remote code execution would look like a process doing something it never did before: an outbound connection from a service that only talks to its database, a child process spawned from a decoding worker, a file written outside the working directory.
These are generic signals, and they only help when the surrounding baseline is good enough to notice the deviation. That is a reason to build the detection story before the incident rather than during it.

The telemetry that has to exist first

Three fields carry most of the value and are frequently missing.
Compression method per request. An HTTP log that records content length but not Content-Encoding cannot separate a Brotli endpoint from a JSON one.
Decoder failure reason. The application should log that decompression failed and why, without echoing the payload.
Runtime version per instance. A hunt that cannot distinguish patched from unpatched processes produces noise on both sides.

What to query this week

Start with a simple inventory question: which services accept compressed request bodies and which of them run a Node.js runtime line below the fixed release. Then add the crash correlation: process exits within a short window after a request carrying Brotli content, grouped by route and client.
Neither query proves exploitation. Together they turn a theoretical advisory into a short list of places worth watching.
The defect was reported by Khai Tran and Sylvie Mayer of OpenAI Codex Security and fixed by mcollina and aduh95. For defenders, the lesson is that memory-safety bugs in parsers are decided as much by logging design as by patch timing.

References

From loopback to owner token: the middle of the Plex Media Server chain

kozhevniko — Mon, 26 Oct 2026 21:02:33 +0000

From loopback to owner token: the middle of the Plex Media Server chain

Two of the four Plex Media Server CVEs fixed in 1.43.3.10861 do the quiet work. CVE-2026-96654 opens internal agent functions to a request that came from outside. CVE-2026-96655 turns that into the server owner's administrative token. Neither scores above medium.

CVE-2026-96654: what searchOne does with a URL

The NVD record describes incorrect neutralization of URL values in searchOne, which allows an attacker to call other plugins' functions and supply their own parameters. Plex summarizes the impact as access to internal agent functions over the loopback interface.

Both descriptions point at the same design. Plex agents expose local HTTP surfaces that the server queries on behalf of clients. A parameter that selects the destination or the function is supposed to be constrained by the server. When it is not, a caller can address an agent function the client was never meant to reach and pass arguments of its own choosing.

The score is 6.5 on CVSS 3.1, with a network attack vector, low complexity and no privileges required. CISA lists it in the Known Exploited Vulnerabilities catalog from 2026-10-20, with a due date of 2026-10-23.

CVE-2026-96655: the token rather than the address

CVE-2026-96655 lives in /video/:/transcode/universal. NVD says the path parameter allows an authenticated user to request arbitrary internal or external addresses. Plex describes the outcome differently and more seriously: disclosure of the server owner's admin token.

That difference matters. An SSRF that returns a body tells you about internal services. An SSRF that returns an owner token gives you control of the server. The token authorises library changes, user management, remote access configuration and the transcoder preference that the fourth CVE needs.

Its score is 4.3 on CVSS 3.1. CISA lists it with a due date of 2026-11-03.

How the middle joins the ends

The chain only works as an order. CVE-2026-96652 provides an unauthenticated request primitive through /player/timeline, accepting any X-Plex-Token value. That primitive lets the attacker reach the agent surface that CVE-2026-96654 exposes, which in turn reaches the transcode path parameter that CVE-2026-96655 leaks a token from. With the owner token in hand, CVE-2026-96656 writes to the Codecs directory, and the service runs the result at its next start.

Plex states the assembled outcome plainly: chained together, the four issues let an unauthenticated remote attacker run code with the privileges of the Plex Media Server process. The vulnerability was already being exploited when the vendor updated the advisory.

Why these two are the hardest to detect

The first and last steps leave obvious traces. An external request to /player/timeline stands out in a web server log, and a new shared object in the Codecs folder stands out in a file listing.

The middle steps look like normal Plex behaviour. The server itself queries its agents over loopback all day. Transcode requests are routine. A log that records the request but not the parameters of an internal agent call will not show the difference between a legitimate plugin lookup and an attacker-directed one.

That is the practical reason to look at consequences rather than at individual requests: unfamiliar shared objects, unexplained child processes such as myawesomeproxy, mylovelyminer or x12345, outbound connections to proxystream.st, and sustained CPU use while nothing is playing.

Containment between the halves

Disabling remote access under Settings, then Remote Access, removes the internet path for the first CVE. Avoiding direct forwarding of port 32400 has the same effect. Neither step closes the flaws, and Plex does not present them as fixes.

A reverse proxy that authenticates every request before forwarding to Plex narrows the population that can reach /player/timeline, which interrupts the first link. It does not help if the attacker already holds a token.

Rotating the owner token is the control that addresses CVE-2026-96655 after exposure. In Plex that means signing out all devices and changing the account password, which the vendor recommends as part of remediation for a suspect server.

The version check that ends the discussion

Open Plex Web, go to Settings, then General, and read the version. 1.43.3.10861 and later contain the fixes. Below that, the middle of the chain is reachable to the extent that the first step is.

Exposure context

A ZoomEye query for app="Plex Media Server" returned 507,974 matching assets when this article was prepared, and vul.cve="CVE-2026-96654" returned 0. The product count measures internet-facing installations, not hosts with exposed agent surfaces or leaked tokens.

References

CVE-2026-96654 record: https://nvd.nist.gov/vuln/detail/CVE-2026-96654
CVE-2026-96655 record: https://nvd.nist.gov/vuln/detail/CVE-2026-96655
Plex security notice: https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
CVE-2026-96652 record: https://nvd.nist.gov/vuln/detail/CVE-2026-96652
CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-96655

10,146 Cockpit title matches and 6,767 fingerprints: why the console with a 9.8 injection flaw looks smaller than it is

kozhevniko — Mon, 26 Oct 2026 18:00:19 +0000

10,146 Cockpit title matches and 6,767 fingerprints: why the console with a 9.8 injection flaw looks smaller than it is

CVE-2026-4631 is a command injection in Cockpit's remote login feature. NVD describes user-supplied hostnames and usernames reaching the SSH client without validation or sanitisation, so a single HTTP request to the login endpoint can inject SSH options or shell commands and execute code on the Cockpit host without valid credentials. The score is 9.8 under CVSS 3.1. For anyone running a Linux estate, the practical question is whether a management console is exposed, and exposure data for this product reads oddly at first glance.

The measurement

Two ZoomEye queries on 27 October 2026, sub_type=all, pagesize=1:
| Query | Role | Matched total |
| --- | --- | ---: |
| app="Cockpit" | application fingerprint | 6,767 |
| title="Cockpit" | page-title text match | 10,146 |
No CVE filter was applied. Neither figure describes a host confirmed vulnerable to CVE-2026-4631.

The title count is larger, and the reason matters

For most product measurements in this series the title count sat below the fingerprint count. Here it sits above by half again, and the explanation is a reminder that product names live in more than one context.
Cockpit is the name of a Linux server administration console, and it is also a word used in aviation, in software projects, and in ordinary page text. A title query matching the string will gather pages that have nothing to do with the console. On a base of ten thousand, a few hundred false positives move the ratio, and the overlap between the two populations is what a defender actually needs.
The fingerprint side has its own limit in the other direction. Cockpit is frequently reached through an SSH tunnel or a VPN rather than published on a public address, because its design intent is local administration. Those instances are not observable from outside at all, so the 6,767 figure describes only the subset someone chose to expose.
The pair therefore brackets the truth from two sides: the title query overcounts by including unrelated pages, and both queries undercount by missing tunnel-only deployments. Neither number is a population estimate for exposed consoles, and neither is a count of vulnerable ones.

Why a six-thousand-scale population still justifies work

The scale is small, and the impact per host is high. A compromised Cockpit console is not a compromised web application. Cockpit manages systemd services, storage, networking and containers, and the process that parses the request is the process with that authority. The CVE does not require an authenticated session, so reachability is the only precondition.
That combination changes the planning arithmetic. Six thousand fingerprints across an internet-scale collection implies a modest number of organisations that have deliberately published a management console, and each of those has a single bug away from root-equivalent control on a host. A small population with a large per-host impact deserves a targeted search rather than a mention in a weekly digest.
The specific search is cheap. Cockpit conventionally listens on port 9090. A query scoped to your own address space for that port, plus a certificate-name query for hosts issued certificates under an administrative naming convention, produces a short list in minutes. This is the rare exposure question where a port-scoped search is appropriate, because the default port is the deployment convention rather than an arbitrary choice.

The configuration question that removes risk

Before patching, answer whether the remote login feature is used. The vulnerability is in that feature specifically, and an estate that only uses Cockpit for local service management can disable it. Removing a feature that carries a 9.8 injection flaw is a legitimate remediation, and it is faster than a package rollout across heterogeneous distributions.
The second configuration question is whether the console is reachable from an untrusted network. The default deployment posture is local administration, and instances behind a VPN or an SSH tunnel are not reachable by an unauthenticated attacker on the internet. If a console was published for a support session and the firewall rule outlived the session, that is the finding, and it is a firewall finding rather than a patching one.

Detection on a host that never logged a login

Because a single crafted request executes the attack, the application's own audit trail may contain no authentication event at all. Detection has to come from three other places.
The web server access log for the Cockpit listener, filtered on the login endpoint, searching for shell metacharacters, -o option sequences, and their encoded forms. The request path is recorded even when the request is malicious.
The process tree, for shells spawned as children of the Cockpit process, which should not happen under normal operation.
The persistence locations a console compromise would touch: authorised keys for root, sudoers entries, new systemd units, and cron definitions created after the exposure began.
Post-patch the same three checks apply, because a package upgrade does not remove an authorised key or a systemd unit. Nor does it invalidate a session cookie that an administrator's browser held when the console was compromised, which is why a session invalidation step belongs in the response even though it feels redundant after a patch.

What the numbers cannot support

One claim the data does not support is a count of vulnerable hosts, because the affected version range is not observable from a banner and the feature may be disabled. A second is a conclusion about Linux estates in general, because tunnel-only deployments are invisible to both queries. A third is that a low count means low priority, which would misread the impact per host.
What the pair of numbers does support is a statement about detection bias: for a product with a common English name, a title query overcounts, and for a product designed to be tunnelled, both queries undercount. Knowing the direction of both errors is what makes a measurement usable.

Limitations

Counts come from a single session on 27 October 2026 with combined IPv4, IPv6, and domain scope. Collection coverage changes over time and the totals are not reproducible. No matched records were sampled, so the false-positive share of the title population is unquantified. Nothing here establishes the version, feature configuration, or patch state of any matched host.

References

NVD, CVE-2026-4631, https://nvd.nist.gov/vuln/detail/CVE-2026-4631
Cisco Talos vulnerability reports, https://www.talosintelligence.com/vulnerability_reports
Cockpit project documentation, https://cockpit-project.org/
ZoomEye search, https://www.zoomeye.ai/