DEV Community: jeffrey

Auto-login plus CVE-2026-105740: the configuration that removes the only barrier in Langflow

jeffrey — Wed, 28 Oct 2026 09:24:34 +0000

Auto-login plus CVE-2026-105740: the configuration that removes the only barrier in Langflow

CVE-2026-105740 is an authenticated flaw, which puts the login path at the centre of its risk. The attackers recorded by Previdian tested that path first, and their order of operations shows which setting decides whether an exposed Langflow instance is a hard target or an open one.

The sequence operators used

Ryan Dewhurst of Previdian described one observed sequence to The Hacker News: the attacker checked the Langflow version, attempted /api/v1/auto_login, received a 403 because auto-login was disabled in the honeypot, then authenticated successfully with a common username and password. The resulting bearer token went directly to the MCP server configuration endpoint.
The sequence reads as a decision tree. Langflow version sets the payload. If /api/v1/auto_login answers, a session arrives without credentials and the attacker moves on to exploitation. If it does not, the attacker falls back to credential guessing, and a deployment with default or shared passwords hands over the same session.

What auto-login means in practice

LANGFLOW_AUTO_LOGIN controls whether the platform issues a session without an interactive login. It exists for local or demonstration use, where prompting for credentials on every start is friction. On an internet-reachable host it converts an anonymous request into the authenticated state the vulnerability requires.
The vendor reporting on this flaw recommends setting LANGFLOW_AUTO_LOGIN=false. That recommendation is not generic hardening language. It targets the specific step that the recorded operators attempted.

The second door: shared accounts

A disabled auto-login endpoint only helps if passwords hold. The honeypot sequence succeeded with \"a common username and password,\" meaning the operators carry a short list. Langflow installations that were deployed for an evaluation and never given unique credentials fall to that list.
LANGFLOW_SUPERUSER_PASSWORD appears in the command payloads the honeypot captured, next to LANGFLOW_SECRET_KEY. Both are secrets the platform itself holds, and both are useful to an attacker who has already run a command.

Exposure that is not about version numbers

An instance that is patched but still runs auto-login has a smaller problem than one that is unpatched. It has exposed the entire application, including flows, provider keys and stored MCP configuration, to anyone who can reach the port. That is a data exposure question separate from CVE-2026-105740.

Exposure context

A ZoomEye query on app=\"Langflow\" returned 19,181 matching assets when checked. The figure counts fingerprinted deployments, not vulnerable ones, and not ones with auto-login enabled. The vul.cve=\"CVE-2026-105740\" filter returned 0 indexed assets at the same time.

Checklist for the login path

Set LANGFLOW_AUTO_LOGIN=false on anything reachable beyond localhost.
Confirm /api/v1/auto_login returns an error rather than a session.
Replace shared and default credentials with unique ones.
Restrict account creation to administrators.
Rotate LANGFLOW_SECRET_KEY and the superuser password on any host that was exposed while unpatched.

References

Building a Timeline From Log Evidence: The ConnectWise Tenant Intrusion in Sequence

jeffrey — Wed, 28 Oct 2026 06:03:50 +0000

Building a Timeline From Log Evidence: The ConnectWise Tenant Intrusion in Sequence

Timelines assembled after an incident tend to acquire certainty they never had. A blog post says two and a half hours, a vendor statement says twelve hours, and by the third retelling the sequence is presented as a reconstruction of a single actor's movement.

For the ConnectWise Cloud Backup incident, the public evidence supports a narrower and more useful account. Here it is, ordered, with each element attributed and the gaps left visible.

The sequence as documented

13 to 14 October. Password spraying against four law firm tenants, and scripted sign-in attempts, originate from the address later associated with the tenant intrusion. Reported by Huntress. The investigator has not tied this phase to the same operator as what follows.

15 October. The ConnectWise Cloud Management application for Microsoft Teams adds itself to the Global Administrator role in one customer tenant. It then runs a Python script that creates new client secrets on an MSP management application and on Huntress's own application. This activity came from Microsoft's internal cloud network, roughly two and a half hours before the first sign-ins from the attacker address.

15 October, 06:13 to 08:34 UTC. Microsoft Graph tokens are obtained in customer tenants from 144.172.64[.]128. The actor moves through tenants in sorted GUID order, seconds apart, consistent with a script working from a prepared target list.

15 to 16 October. The Cloud Backup identity signs in to 162 Microsoft 365 tenants.

17 October. ConnectWise suspends Cloud Backup, roughly twelve hours after starting its investigation. Huntress reports sign-in activity from the attacker address in nearly 1,000 Entra tenants by this date, with more than 300 successful.

18 October. SaaS Security and Cloud Management are shut down as well, to implement mitigations.

What the ordering tells an investigator

The Global Administrator self-assignment preceded the first sign-ins from the attacker address, and it did not come from that address. Assembling a tenant timeline therefore requires two independent filters: one on the attacker address, and one on service principal sign-ins regardless of source address. A log review built only on the reported IP would miss the role change entirely.

The creation of new client secrets matters for a different reason. Secrets extend the window. An investigation that concludes when the vendor blocks the credential may still be inside the period during which a secondary credential remains valid, which is why the vendor's guidance asks partners to check for persistence rather than only for access.

The tenant iteration pattern

Sorted GUID order at a few seconds per tenant is not human behaviour. It indicates a prepared list and an automated loop, which in turn indicates that the actor knew which tenants held the application consent before starting. That is a reconnaissance finding, and it is the most transferable part of the timeline for defenders: the enumeration that made the intrusion efficient is the same enumeration a defender should perform on their own estate before it is done for them.

External context, dated

Search observations collected on 28 October 2026 do not extend the timeline but do frame the observable estate. domain="connectwise.com" returned 170 records; domain="connectwise.com" && country="US" returned 141; ip="144.172.64.128" returned 0, indicating no indexed host at that address at query time. The zero is consistent with an address used for authentication rather than for hosting a service, and it neither supports nor refutes the reported activity.

Gaps in the record

What the public evidence does not establish: whether any tenant data was copied; whether the two October phases share an operator; which organisations were among the 162 and the 300-plus; and how long any secondary credentials created during the intrusion remained valid in each tenant. ConnectWise has not published an estimated restoration timeline, and no source reviewed for this article provides a complete affected-tenant list.

Recording those gaps is not pedantry. A timeline that omits them invites decisions based on an assumed completeness that the record does not carry.

References

Huntress, "Vendor Credential Enables Unauthorized Access", https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
SecurityWeek, "ConnectWise Suspends Cloud Services in Response to Cyberattack", https://www.securityweek.com/connectwise-suspends-cloud-services-in-response-to-cyberattack/
ConnectWise status incident notice, https://status.connectwise.com/pages/incident/619cf82551fec9053d612f09/6ad263692dc48705ab3da2cb
ConnectWise trust advisories, https://www.connectwise.com/company/trust/advisories

Tokens Outlived Passwords, and Most Identity Programmes Did Not Notice

jeffrey — Wed, 28 Oct 2026 03:01:44 +0000

Tokens Outlived Passwords, and Most Identity Programmes Did Not Notice

NIST published the final version of Interagency Report 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse", on 15 September 2026, produced jointly with CISA and written for federal agencies and the cloud providers that serve them. It is a dense document about a shift that is easy to state and hard to operate: the credential that matters in a modern estate is usually not a password, and the controls built for passwords do not transfer.

What the report is actually about

The report treats tokens and assertions — SAML assertions, OIDC ID tokens, OAuth access tokens — as first-class security objects with their own lifecycle: issuance, transmission, use, verification, revocation. It catalogues five threat classes: forgery or tampering, redirection, replay, signing-key compromise, and token theft. Each has a different mitigation, and conflating them is a common source of misplaced confidence.
The signing-key class deserves separate attention. A stolen password affects one identity. A stolen token-signing key lets an attacker mint assertions that every relying party will accept, because the cryptography is genuinely valid. The report describes exactly that scenario: an actor using forged tokens derived from a single compromised commercial signing key, obtaining access to a mail system and taking tens of thousands of messages from one organisation. No amount of end-user awareness training addresses that failure mode.

Verification is more than a signature check

A recurring point in the report is that a valid signature establishes provenance, not authorisation. Verification should also test the audience, the scope, the lifetime, the unique identifier, the sender constraint, and the current access context. A token signed correctly for one service, replayed against another, passes a naive check.
Two mitigations are concrete. Sender-constrained tokens bind the credential to a client key — DPoP or mutual TLS both appear in the report — so a stolen token is useless without the corresponding private key. And backend-channel token transmission avoids placing assertions where the user agent and the browser can be induced to leak them; the front channel is convenient and exposes the token to exactly the environment the attacker already controls.
The report also addresses payload confidentiality. TLS protects the wire, not the token contents once they reach a party that logs them. Encrypting assertion payloads, via JWE or encrypted SAML assertions, limits the reconnaissance value of a token that leaks into a log aggregator.

The AI agent paragraph is short and important

NIST extends the recommendations to non-human identities, including AI agents, on the grounds that agents present signed tokens to reach systems, data, tools and APIs and therefore inherit the same obligations. The concrete advice is unremarkable in isolation and awkward in practice: shorter token lifetimes for workloads, resource scope limited to what the task needs, and sender binding where technically feasible.
The report is also candid about the limit — it does not attempt to solve agent identity management comprehensively, and defers broader IAM questions to future work. That honesty is more useful than a false framework. Teams deploying agents today are operating ahead of the guidance, which means they are also operating without an external check on their design.

PQC is a token-size problem before it is a cryptography problem

One section describes a practical consequence of post-quantum migration that is easy to miss. PQC public keys, signatures and ciphertexts are substantially larger than their elliptic-curve and RSA equivalents. In a JWT, that larger signature has to fit into an HTTP header or a cookie. Some will not. Hardware security modules may need firmware, product or architecture changes, and federations built on specific algorithms may not be able to accept the new ones without redesign.
The recommendation is to inventory where public-key cryptography sits in the token path now, and to evaluate whether the current transmission mechanism survives a PQC migration — before the migration is mandatory rather than during it.

What a defender should do on Monday

The report's structure maps cleanly onto a gap assessment:

Can you enumerate every issuer and signing key in your estate, and does each key have an owner, a rotation interval and a revocation path?
Is token verification checking audience and sender constraint, or only signature and expiry?
Do logs, CI/CD artefacts and build outputs contain tokens, and would you know if they did?
Do you have revocation working under load, or only documented?
Do non-human identities have lifetimes and scopes that reflect what they do, or the defaults that shipped with the platform? The shared responsibility section is worth reading with a contract in hand. Cloud providers own key custody, signing infrastructure and cryptographic hardware; customers own policy configuration, application access control, MFA settings, session management and monitoring. Most real incidents live in the seam between those two columns, which is why the report keeps returning to configuration review and continuous assessment rather than to algorithm choice.

References

NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, final, 15 September 2026: https://csrc.nist.gov/publications
NIST Computer Security Resource Center news listing for IR 8587 (September 2026): https://csrc.nist.gov/news
Analysis summarising IR 8587 scope, key management recommendations and AI agent coverage (Security Watch / secrss.com, October 2026): https://www.secrss.com/articles/94675
CISA landing page announcing the joint CISA-NIST report: https://www.cisa.gov/

The fake IT desk inside Teams: 400 incidents where a chat became remote access

jeffrey — Wed, 28 Oct 2026 00:00:41 +0000

The fake IT desk inside Teams: 400 incidents where a chat became remote access

Microsoft Teams external access is on by default. Any user in another Microsoft 365 tenant can find, chat with and call employees in your organisation, provided both tenants allow external access. Arctic Wolf examined more than 400 incidents in which attackers used that default to open a conversation as an IT support agent and finish with remote control of the victim's machine, in under 15 minutes from the first reply.

The research was published on October 26, 2026. The attackers often contacted several victims within a short window, which the researchers read as automation. Arctic Wolf did not identify the operators, but noted that external Teams chat as an initial access route has been used by ransomware groups including Black Basta.

The tenant is the disguise

Between 30 and 40 percent of the cases involved default onmicrosoft.com tenant domains. Those need no verification and can be provisioned in minutes. The attackers typically chose a tenant name built from a support, IT, admin, network or helpdesk word, sometimes with the number 365 appended, and paired it with a plausible first name so the sender appeared as "IT Service Desk - Liam" or similar.

In a small number of cases a real company name appeared in the sender's tenant name, which raises the cost of the decision for the recipient: the external tag is still there, but the name is familiar.

In a significant number of attacks the victim's mailbox was first flooded with hundreds of newsletter or subscription confirmations within minutes. That mail bombing gives the attacker a problem to solve. The Teams message arrives moments later, offering to fix the noise.

From chat to keyboard

Most cases moved to hands-on-keyboard access through remote monitoring and management tooling, most often Quick Assist, which ships with Windows and needs no installation. Where the attacker wanted persistence beyond the first call, the pivot went to a commercial RMM product such as AnyDesk or ScreenConnect.

From there, the observed chain is a PowerShell payload and lateral movement, in some cases toward ransomware deployment. In several incidents the user was talked through running a PowerShell command and launching a downloaded file.

The fifteen-minute figure is not the whole intrusion. It is the distance between the victim engaging with the message and the payload executing. A control that depends on a user pausing to think has to work inside that window, on a channel the user has no reason to distrust.

The controls that actually address the route

Arctic Wolf's recommendations map to distinct failure points, and they are worth reading as a sequence rather than a list.

External access is the route. In the Teams admin center under Users and External access, the setting to allow only specific external domains restricts chat to named partner domains. Blocking chat with unmanaged and Teams-consumer accounts, and disabling the option that lets unmanaged users start conversations with your people, closes the case where the sender has no managed tenant to check. Blocking federation with trial-only tenants removes the cheapest infrastructure an attacker can buy. Enabling the security team's ability to manage blocked domains gives responders a way to act during an incident instead of after it.

Quick Assist is the execution path. Restricting it to authorised IT roles, and blocking or uninstalling unsanctioned RMM tools, removes the tool the attacker asked the user to trust. This control is the one that survives a failed awareness programme, because it does not depend on the user recognising the pretext.

User reporting is the detection path. Microsoft's end-user reporting in Teams lets an employee report a suspicious message or an external user in two clicks. That matters most for the first contact, before any payload exists to detect.

What the external tag does not prove

A banner that says External tells the user that the sender is outside the tenant. It does not tell them the sender is not the IT department, because a tenant name and a display name are chosen by the attacker. Training that explains how real IT support contacts users, and what domain a message comes from, addresses the gap that the tag leaves open. Training alone does not, which is why the RMM restriction sits in front of it.

The scale in this research is the argument for treating chat as an ingress path. Four hundred incidents in a single vendor's customer base, with consistent tradecraft and short dwell time, is a campaign rather than a nuisance. Each of them started with a message that the platform was designed to deliver.

References

[1] Infosecurity Magazine, "Attackers Exploit Teams External Chat to Breach Organizations in Under 15 Minutes", October 27, 2026. https://www.infosecurity-magazine.com/news/exploit-teams-chat-breach/

CoAP: 2,188,380 answers for a protocol designed to be spoken to by anything

jeffrey — Tue, 27 Oct 2026 21:00:17 +0000

CoAP: 2,188,380 answers for a protocol designed to be spoken to by anything

A ZoomEye query for service="coap" returned 2,188,380 matches on 28 October 2026. CoAP is the Constrained Application Protocol, standardised as RFC 7252 in 2014, and it was built for devices that cannot afford TLS handshakes or verbose headers: sensors, meters, building controllers, industrial gateways. Every one of those 2.19 million answers is a UDP endpoint that will parse a request from whoever sends one.

What the query selects

service="coap" asks ZoomEye to report hosts where the probe recognised CoAP semantics rather than a bare port number. That distinction matters, because CoAP runs on UDP 5683 with no connection handshake and no banner. A port-only query on 5683 would count anything that happens to answer, including hosts that never speak the protocol. Recognising the protocol means the probe got a well-formed CoAP response: a version field, a token, a response code, options.

The single number above is also the only one this article will quote. CoAP has a second common deployment on 5684 where the same messages travel inside DTLS, and separating the two reliably depends on capturing a handshake that many constrained stacks will not complete for an unknown peer. Rather than publish a split that may reflect probe behaviour instead of deployment, the count stays whole.

The discovery resource is the interesting part

CoAP defines /.well-known/core (RFC 6690) as a discovery endpoint, and it is normally enabled. A GET to that path returns a link-format document listing every resource the device offers: /sensors/temp, /actuators/valve, /config/network, and often a writable /config or /reset. This is by design. CoRE Resource Directory exists precisely so clients can enumerate a device without being configured for it.

The security consequence is that enumeration needs no credential. A device that answers /.well-known/core to an arbitrary source has told that source its full interface list. Whether the individual resources then require authorisation is an application decision, and in the constrained world that decision is frequently that the network is trusted.

Two protocol properties that matter operationally

Multicast. CoAP is designed to be sent to a group address. A single request to a multicast group can be answered by every device in it. That is efficient for control systems and it is also a request amplifier, because the response is larger than the request. RFC 7252 discusses this and recommends restrictions; the recommendation only helps on devices whose implementation follows it.

No built-in authentication. CoAP itself carries no authentication. OSCORE (RFC 8613) provides object security at the application layer, and DTLS provides transport security. Both are optional, and both require provisioning: a device shipped with a PSK that nobody changed, or with OSCORE disabled because the installer could not get the master secret distributed, is a device that trusts its network.

Turning the number into a work list

Query your own address space rather than the internet at large. service="coap" && ip="10.0.0.0/8" in ZoomEye, or the equivalent in your asset inventory.
For each hit, fetch /.well-known/core. The list of resources tells you what the device exposes before you attempt anything else. Treat writable resources as the finding.
Check whether the same device answers on 5684 with DTLS. A device that only speaks plain 5683 on a routable network has no confidentiality for its commands.
Identify the vendor and firmware from the CoAP response options and any accompanying HTTP management interface, then look for the vendor guidance on OSCORE support and on disabling multicast responses.
If the device is a building or industrial controller, the owner of the physical process is the right person to decide on blocking, not the network team alone.

Why this belongs in an exposure conversation

The 2,188,380 figure is not a vulnerability count. It is a count of hosts that answered a protocol probe. What it establishes is that a large number of constrained devices are reachable at the network layer by something other than their intended client, and that the protocol they speak was designed for a closed network under a single administrative domain. Once those devices sit behind a router with a permissive rule, or on a flat enterprise VLAN, their discovery behaviour becomes an inventory tool for anyone who can reach them.

The practical question for a defender is not how many CoAP devices exist on the internet. It is how many of them are yours, what /.well-known/core says about each, and whether anything other than the intended collector can reach UDP 5683.

Sources

ZoomEye AI SDK query service="coap", page size 1, sub_type all, executed 28 October 2026 Beijing time: 2,188,380 matches.
RFC 7252, The Constrained Application Protocol, including its treatment of multicast amplification.
RFC 6690, CoRE Link Format, which defines /.well-known/core.
RFC 8613, Object Security for Constrained RESTful Environments (OSCORE).

An image library that shells out: the October 2026 Pillow fixes and the filename nobody validates

jeffrey — Tue, 27 Oct 2026 18:03:27 +0000

An image library that shells out: the October 2026 Pillow fixes and the filename nobody validates

Pillow is the image library most Python web applications end up using, whether the developer chose it or a framework did. It opens, converts, crops and re-encodes images. It also, for certain formats, delegates work to command-line tools. The October 2026 advisory covers several defects, and one of them is a reminder that "process this image" can become "run this command" when a filename reaches a subprocess.

What was disclosed

The published reporting identifies at least three items, addressed by upgrading to Pillow 13.0.0:

CVE-2026-112900, command execution through crafted filenames passed into the EPS handling path. Pillow's EPS support relies on external tools, and a filename that is not validated can be interpreted by the shell that invokes them.
CVE-2026-112393, a buffer overflow in compressed TIFF handling when the compressed image is written to memory rather than to disk. This is the pattern used by services that re-encode an upload and return the bytes.
A third flaw in the same release, described as long-standing, with the same general shape: image input that reaches memory the application did not intend it to reach. The distinction between the first two matters for exploitation. The command execution item needs a filename that an attacker can influence; the TIFF item needs an upload that passes through an in-memory conversion step. Both are common in exactly the applications that process user images at scale.

Why a filename becomes a command

EPS and PostScript are not raster formats. Rendering them requires an interpreter, and Pillow's approach has historically been to call out to Ghostscript. Once a library builds a command line, the question is how it quotes what it was given. A file called report.eps is safe. A file whose name contains shell metacharacters is not, if the name is concatenated into a command string.
The precondition is the interesting part. An application that writes uploads to a server-generated path and then opens that path is not exposed to the filename variant, because the attacker's chosen name never reaches the tool. An application that opens the uploaded file by its original name, or that passes a user-provided path into Pillow's save or open call, is. That difference is a code property, not a configuration setting, and it is invisible to a scanner that only reports the library version.
The TIFF item is the opposite. It does not care about names. It cares whether the compressed image data is written to a memory buffer, which is what happens when a service wants to return the re-encoded image without touching the disk.

Finding the exposure in a real codebase

Three greps cover most of the ground. First, calls that pass a user-derived string into an image open or save operation. Second, uses of the in-memory buffer pattern on compressed output. Third, any place where the application hands a filename to an external tool.
Then check the delegation policy. Pillow's EPS path can be restricted, and a service that does not accept PostScript has no reason to keep the capability. Removing an unused decoder is more durable than adding an input filter in front of it.
For the TIFF path, the mitigation short of upgrading is to bound the work: downscale before re-encoding, cap dimensions from the header before decoding, and run the conversion in a process with memory and CPU limits. None of that removes the bug, but it changes what a crafted file can achieve.

The upgrade itself

Pillow 13.0.0 is the fixed release for these items. The complication is that Pillow is frequently a transitive dependency, pulled in by a framework for thumbnail generation and never listed in the project's own requirements. The version that matters is the one the running process imports, so a check against the deployment environment beats a check against the lock file, particularly where an OS package provides Pillow alongside a virtual environment that has a different copy.
Applications that bundle Pillow inside a container image inherit the base image's version. Rebuilding on a patched base is part of the fix, and it is the step most likely to be missed when the application's own dependency file was updated.

A concluding rule for image handling

Image processing is an input parsing problem in front of an execution problem. Treat uploaded files as untrusted binaries, generate your own filenames and paths, disable decoders you do not use, and run conversions with resources capped. None of those is specific to Pillow, and all of them reduce the value of the next library advisory in this category.

References

Pillow 13.0.0 release and security advisory covering CVE-2026-112900 and CVE-2026-112393
FreeBuf summary of the Pillow October 2026 fixes, including the EPS filename command execution path and the compressed TIFF in-memory overflow
51CTO security coverage of the same release

How many VMmanager panels are actually reachable from the internet

jeffrey — Tue, 27 Oct 2026 15:00:32 +0000

How many VMmanager panels are actually reachable from the internet

FirstVDS disclosed on 19 October 2026 that an intruder reached its virtualisation management system through a flaw in VMmanager 6 and copied customer data from virtual server disks. ISPsystem, the platform vendor, confirmed the next day that the incident involved "a vulnerability in one of the VMmanager 6 builds" and said security updates had been released. Neither statement names a CVE, an affected version range or an exploitation method.
An operator who runs the same platform therefore has to start with a narrower question: how many VMmanager management interfaces answer from the public internet at all. ZoomEye answers the reachability part of that question without needing a version fingerprint.

What the measurement shows

Queries run on 27 October 2026 returned these counts.
| Query | Matching assets |
| --- | --- |
| title="VMmanager" | 2,823 |
| http.body="VMmanager" | 3,350 |
| title="VMmanager" && port="443" | 1,592 |
| title="VMmanager" && is_domain=true | 84 |
The search link for the title query is https://www.zoomeye.ai/searchResult?q=dGl0bGU9IlZNbWFuYWdlciI%3D.

Reading the two totals

The global totals differ by 527 assets, and the difference tracks the matching field. A title match means the page title contains the product name, which is the usual case for a login screen that labels itself. A body match also catches pages where the name appears in a footer, a licence notice or a documentation block, which helps with installations that rebrand the interface. For inventory work the title query is the tighter signal.
Neither query proves that the asset is vulnerable to the flaw FirstVDS described. A title match identifies a page signature and nothing more. Confirming a build requires reading a version string from the application, which an external scan does not do here.

No application fingerprint exists

ZoomEye has no application fingerprint for this product. app="VMmanager" returns zero assets, while the title query returns 2,823. A team that only runs fingerprint queries will conclude the platform is invisible to internet measurement, which would be wrong. The interface is present; it has to be found by its page characteristics instead of a curated app label.
Version granularity is weaker still. title="VMmanager 6" matches two assets, so build-level distribution cannot be measured from titles. Any claim that a specific number of hosts run the affected build would be an invention.

What the count does not establish

2,823 assets are not 2,823 victims. The count describes interfaces that answer publicly, in the same way a count of exposed routers describes routers rather than compromised routers. Three limits matter here. The scan cannot see installations behind a VPN or an address allowlist. It cannot separate a production control panel from a staging copy. It cannot tell whether the operator applied the updates ISPsystem released.
What it can do is size the population that a targeted attacker could enumerate with the same query. That number is the one worth using when deciding how quickly to close an interface.

Checking your own estate

The useful comparison is between the global count and the assets you control. Pull the external addresses and hostnames your organisation owns, then run the same title and body queries against those ranges and domains. A panel that answers on a public address should either sit behind an allowlisted administration path or be removed from the public internet, which is what FirstVDS did when it disabled external access to its affected management system.
ISPsystem asked customers to block inbound and outbound connections to the platform and to the virtualisation nodes, to allow only trusted administrators and vendor support, and to limit SSH to trusted addresses. Those instructions describe a target state. The measurement above shows how many operators have not reached it yet.

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
ISPsystem, "Regarding an incident involving a vulnerability in one of the VMmanager 6 builds", 22 October 2026. https://www.ispsystem.com/news/update-for-vulnerability-incident
ZoomEye queries executed 27 October 2026. Counts are assets matching the stated query, not confirmed vulnerable hosts.

NGINX 1.30.6 and 1.31.7: Five Flaws, One Configuration Check

jeffrey — Tue, 27 Oct 2026 12:04:08 +0000

NGINX 1.30.6 and 1.31.7: Five Flaws, One Configuration Check

NGINX shipped 1.30.6 on the stable branch and 1.31.7 on mainline on 14 October 2026, closing five vulnerabilities at once. Three are memory-safety bugs that F5 scores 9.2 Critical under CVSS v4.0. A fourth lets an attacker forge a TLS session ticket and, in F5's assessment, potentially slip past client-certificate verification. The fifth lets an HTTP/3 client push bytes into a proxied request that no size check counted. NGINX itself rates all five medium, and neither the maintainers nor F5 reported exploitation as of 15 October.

The reason this release matters is not the count. It is that every one of the five requires a directive that an operator chose to enable. A default installation of the affected versions is not automatically exploitable by any of them, and a hardened configuration may already be immune. The useful work for most teams is therefore two-part: upgrade, and then confirm what your running configuration actually contains.

What the five flaws do

CVE-2026-15176 is a heap overflow in the request-handling path. A location that combines alias with a rewrite that changes the URI, plus anything that reads $request_filename in the window between the rewrite and the next location selection, can overflow a buffer. F5 credits the discovery to its own engineers. The affected range starts at 0.1.29, which makes this the flaw that has been present in essentially every NGINX release since May 2005.

CVE-2026-93479 is a second heap overflow, this one in string handling. A regex map whose captures are referenced by root or log_format before the map's output variable can overrun a buffer sized from a spilled length. The affected branches are 1.30.0 through 1.30.5 and 1.31.2 through 1.31.6, and the bug traces directly to the July patch for CVE-2026-42533.

CVE-2026-97205 is a use-after-free in worker processes. It needs aio enabled together with SSI pages that use include virtual commands, where included requests can run in parallel. Each pending asynchronous operation increments an 8-bit counter without a bound; at 256 pending operations the counter wraps to zero and the request can be freed while those operations still reference its memory.

CVE-2026-95101 is a parser bug in HTTP/3. One field did two jobs, holding both the remaining length of an unknown frame being skipped and the DATA byte count to pass through as request body. When an unknown frame arrived split across two reads, the leftover count was treated as body and forwarded to the backend outside the client_max_body_size check. It requires HTTP/3 plus proxy_request_buffering left at its default of on.

CVE-2026-97629 is the TLS problem. Since 1.23.2, an ssl_session_cache shared:... directive without ssl_session_ticket_key makes NGINX generate and rotate ticket keys itself. Each worker keeps three key slots; rotation copied only two, so the third held whatever was previously in memory. A ticket naming that slot could be verified with uninitialized key material, which is what F5 describes as a forged session, achieved in a non-deterministic manner beyond the attacker's control and usable to bypass client-certificate checks.

Affected scope

Stable and mainline are the only branches NGINX still patches. The published ranges mean that a server sitting on an older branch, including 1.28, stays inside an affected range indefinitely, and that a distribution package is only fixed if the distribution backported the patches. NGINX Plus customers, and users of F5's Ingress Controller, Gateway Fabric, Instance Manager and WAF products, need to read the separate F5 advisories, several of which listed no fixed build as of 15 October.

Remediation

The direct fix is 1.30.6 on stable or 1.31.7 on mainline.

Where an upgrade has to wait, each flaw has a targeted workaround: avoid alias in a location that rewrites, or stop reading $request_filename there; use named captures and keep them inside the block containing the regex match; disable aio or stop serving SSI pages; set proxy_request_buffering off; and either remove the shared session cache directive or supply keys explicitly with ssl_session_ticket_key, noting that servers with ssl_session_tickets off were never affected.

Self-check

Print the running configuration with nginx -T and search it for the five triggers: alias beside a rewrite in the same location, a regex map used by root or log_format, aio together with ssi, a listen line carrying quic, and ssl_session_cache shared without ssl_session_ticket_key. Any hit is a configuration worth reviewing before the release window closes.

Sources

NGINX security advisories: https://nginx.org/en/security_advisories.html
F5 advisory K000162416 (alias): https://my.f5.com/manage/s/article/K000162416
F5 advisory K000162607 (map): https://my.f5.com/manage/s/article/K000162607
F5 advisory K000162608 (AIO/SSI): https://my.f5.com/manage/s/article/K000162608
F5 advisory K000162613 (HTTP/3): https://my.f5.com/manage/s/article/K000162613
F5 advisory K000162606 (TLS tickets): https://my.f5.com/manage/s/article/K000162606
NGINX downloads: https://nginx.org/en/download.html

Patched in August, Exploited in October: The Plex KEV Deadline and What Patch Governance Missed

jeffrey — Tue, 27 Oct 2026 08:43:27 +0000

Patched in August, Exploited in October: The Plex KEV Deadline and What Patch Governance Missed

The most uncomfortable fact about the Plex2Shell campaign is the calendar. Plex Media Server 1.43.3.10861, the release that fixes the four-vulnerability chain, shipped on 3 August 2026. Exploitation was observed from mid-October, and CISA added all four identifiers to the Known Exploited Vulnerabilities catalogue on 20 October 2026 with a remediation deadline of 3 November 2026.
Two months of available fix, and enough unpatched internet-facing installations to justify automated attacks. That gap is not a Plex problem. It is a patch governance problem wearing a media server costume.

What was actually fixed

The chain consists of CVE-2026-96652 (unauthenticated SSRF in playback timeline handling, CVSS 5.3), CVE-2026-96654 (improper neutralization of encoded URI schemes leading to owner token disclosure, 6.9), CVE-2026-96655 (authenticated transcode-path SSRF, 5.3) and CVE-2026-96656 (external control of file name or path, 8.6). Chained, they produce unauthenticated remote code execution. The final flaw is the one that turns a download into a loaded executable.
Individually, none of the first three would justify emergency change control. A 5.3 SSRF in a media player is the sort of finding that sits in a backlog behind higher-rated items. This is the recurring lesson of vulnerability chains: severity scoring is applied per identifier, while exploitation is applied to the composition.

Why the August release did not reach the exposed population

Three mechanisms explain the gap, and each has a governance counterpart.
The first is that the vulnerable population is largely outside formal change management. Domestic Plex installations, departmental media servers for lobby screens or training libraries, and hobbyist deployments on VPS instances do not receive patch reports. They update when prompted or when something breaks.
The second is that remote access configuration outlives the decision that created it. Plex's remote access feature will attempt automatic router configuration via UPnP or NAT-PMP. The inbound rule it creates is invisible to the person who toggled the setting and absent from any asset register. Removing reachability therefore requires action that no patch pipeline performs.
The third is that "fixed version available" is not a control. Governance frameworks tend to measure patch latency in days since vendor release. They rarely measure whether the asset was ever discovered. An unknown media server has infinite patch latency by definition.

What the KEV listing changes, and what it does not

For US federal civilian agencies, the 3 November 2026 deadline converts the issue from discretionary to mandatory, with CISA's authority behind it. For everyone else, the listing is a credible signal that exploitation is real rather than theoretical, which is often the argument that finally moves a change board.
What it does not do is find the asset. An organisation that cannot enumerate its Plex deployments cannot demonstrate compliance with a deadline it cannot measure. The listing also does not change the technical requirement: removing internet reachability, upgrading past 1.43.3.10861, and treating previously exposed hosts as potentially compromised.

A governance pattern that would have caught this

The chain rewards a specific control loop:

Discover by fingerprint, not by trust. External attack surface monitoring that queries product signatures rather than relying on the asset database finds the department server nobody registered.
Treat exposed consumer-grade services as production risk. A media server that shares a network with business systems has that network's blast radius, whatever the business case for it was.
Score chains, not just identifiers. When several moderate findings touch the same product and the same exposure path, evaluate the composition. CVE-2026-96656's 8.6 only matters in the context of the three stages that precede it.
Verify remediation from the outside. Closing a ticket on "upgraded" leaves the network path untested. A reachability check from an external vantage point takes minutes and catches the UPnP rule nobody documented.

Exposure context

ZoomEye queries executed for this article returned 508,009 matches for product="Plex Media Server", 508,033 for app="Plex" and 507,974 for app="Plex Media Server". The CVE-scoped filter vul.cve="CVE-2026-96656" returned zero, which reflects indexing of a newly published identifier rather than an absence of exposure. The asset counts describe internet-facing services matching Plex fingerprints, not confirmed vulnerable installations.

Remediation

Upgrade to 1.43.3.10861 or later. Disable automatic port mapping and close any forwarded port that is not required. If remote access is a genuine requirement, put it behind an authenticated proxy or VPN rather than exposing Plex directly. Then verify from outside that the service is no longer reachable, and record the date. If the host was exposed before patching, treat compromise as an open question requiring evidence rather than an assumption either way.

References

CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656 records, CVE.org.
Plex Media Server security release thread, forums.plex.tv.
CISA Known Exploited Vulnerabilities catalog, entries added 20 October 2026.
Ars Technica, reporting on exploitation of the Plex chain, October 2026.
Plex support documentation on remote access and UPnP/NAT-PMP behaviour.

CVE-2026-6653 is an SBOM problem before it is a patch problem

jeffrey — Tue, 27 Oct 2026 05:02:04 +0000

CVE-2026-6653 is an SBOM problem before it is a patch problem

The advisory for CVE-2026-6653 lists libxml2 2.9.11 through versions before 2.11.0 as affected and names 2.11.0 as the fixed release. Reading that as a single package upgrade is the fastest way to leave the vulnerability in production, because most systems do not track libxml2 as a first-class dependency.

Where the library hides

libxml2 is a C library consumed by language runtimes, document converters, configuration parsers and management appliances. In a containerised estate it can appear three times in one request path: in the base image, in a runtime bundled with an application server, and in a statically linked tool invoked by a batch job.

An inventory that queries the package manager only reports the first layer. The CVE record's repo field points at the GNOME libxml2 project, which is accurate for upstream but not for the artefact actually deployed.

What the scoring record tells an inventory owner

NVD scores the flaw 9.8 under CVSS 3.1 with low attack complexity and no privileges required. The CNA record scores 7.0 under CVSS 4.0, marks attack complexity high, and states proof-of-concept maturity with a denial-of-service impact via crafted XML. CISA's SSVC decision points record exploitation as none, automatable as no and technical impact as partial.

The disagreement is a signal about assumptions, not about presence. A component inventory can confirm presence without resolving the scoring debate, and that is the step worth doing first.

Building the affected list

Start from the products CERT-Bund already references: Red Hat Enterprise Linux, Rocky Linux, Oracle Linux, Amazon Linux 2, IBM Security Verify Access and IBM Power Hardware Management Console. Each has a vendor build that carries the backport, and each has an owning team in most organisations.

Then enumerate the software that embeds libxml2 without naming it in a top-level dependency manifest. Document conversion pipelines are the usual offenders because they parse untrusted input by design.

Confirming exposure honestly

ZoomEye's verified product query banner="libxml2" returned 341 matching assets on 2026-10-27. The result identifies fingerprinted assets and says nothing about their installed version, so it belongs in the scoping section of an inventory, not the findings section.

Search dork: banner="libxml2"

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

Checking a Plex Media Server for compromise after the 1.43.3 fixes

jeffrey — Tue, 27 Oct 2026 02:02:02 +0000

Checking a Plex Media Server for compromise after the 1.43.3 fixes

Plex's own wording sets the tone. If a server runs a build older than 1.43.3.10861 and was reachable from the internet, the vendor says to assume it may be compromised. That sentence is unusual in a security notice and it changes the job from patching to triage.

Why the vendor says assume compromised

The four CVEs fixed in 1.43.3 chain into remote code execution without authentication. CVE-2026-96652 provides an unauthenticated SSRF through the player timeline, CVE-2026-96654 reaches internal agent functions over loopback, CVE-2026-96655 discloses the owner's admin token, and CVE-2026-96656 writes files the service executes at startup. A public proof of concept appeared on 2026-10-16, and Plex reports widespread attacks on unpatched internet-facing servers afterwards, with compromised hosts used for cryptocurrency mining and proxy software.

Nothing in that sequence leaves a clean log line by default, which is why the vendor points at artefacts rather than at a single request.

First question: which build is running

Open Plex Web, go to Settings, then General, and read the version. Anything below 1.43.3.10861 is in scope for the chain. NAS packages are the usual laggard: Plex notes that vendor stores such as QNAP may not have the update immediately and that manual installation of the package may be required. Plex Desktop 1.115.0 ships separately from the server.

Artefacts to inspect on the host

Three checks cover most of what the advisory describes.

Processes started by Plex Media Server that you do not recognise. Plex names myawesomeproxy, mylovelyminer and x12345 as examples seen in the wild. The list is not exhaustive, so treat any unexplained child process of the Plex service as suspicious.

Unfamiliar .so or .dll files in the Plex Codecs folder. This is the payload location for CVE-2026-96656, because the server runs shared objects from that directory at startup without signature, execute bit or symbol checks. Record hashes and timestamps before deleting anything.

Outbound connections to proxystream.st and sustained high CPU use while nothing is playing. The first suggests the proxy role the advisory describes, the second the miner role.

Configuration drift that signals tampering

Read Preferences.xml and compare transcoder options with your own documentation. The write primitive in CVE-2026-96656 works because TranscoderH264Options is appended verbatim to the x264 option string on every transcode, so a preference you never set is evidence of administrative access you did not grant. The same file can show remote access settings enabled after your last review.

Scope what the service account could reach

The advisory asks operators to treat anything the Plex service account could reach as potentially exposed. In practice that means mounted SMB or NFS shares, credentials stored on the same host or VM, and any bookmark or token sitting in the Plex data directory. Inventory those before rebuilding, because the rebuild destroys the evidence you would need to answer questions about lateral movement.

Rebuild instead of cleaning

Plex recommends rebuilding from a clean installation rather than reusing the old data directory. A defensible order of operations:

Snapshot the host for later analysis if policy allows.
Copy Preferences.xml and a listing of Codecs files to a safe location.
Build a new server on a clean host or a fresh VM.
Restore media libraries only, not application state.
Sign out all devices in Plex account settings and change the Plex password.
Rotate every credential that was stored on the compromised host.

Rebooting without those steps leaves the loader in place. The malicious shared object persists on disk and returns at the next start.

Reducing the next window

Turn off remote access under Settings, then Remote Access, if nobody uses it. Avoid forwarding port 32400 directly, which Plex recommends as a standing measure. A reverse proxy that enforces authentication in front of the Plex web UI does not fix the four CVEs, but it narrows the population that can reach the vulnerable endpoints while a patch window is open.

What the CISA deadlines imply

CISA added all four identifiers to the Known Exploited Vulnerabilities catalog on 2026-10-20. The due dates split the chain: 2026-10-23 for CVE-2026-96656 and CVE-2026-96654, and 2026-11-03 for CVE-2026-96652 and CVE-2026-96655. CVE-2026-96656 also carries a forensic triage requirement, which fits an issue whose payload sits in a directory you can inspect.

Exposure context

A ZoomEye query for app="Plex Media Server" returned 507,974 matching assets when this article was prepared, while vul.cve="CVE-2026-96654" returned 0. The product count describes internet-facing Plex installations, not hosts confirmed vulnerable or compromised, and it says nothing about patch level.

References

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

First 24 hours with CVE-2026-111497: an incident-response runbook for Node.js fleets

jeffrey — Mon, 26 Oct 2026 23:00:46 +0000

First 24 hours with CVE-2026-111497: an incident-response runbook for Node.js fleets

The alert has arrived, the severity is 9.8 in one source and high in another, and the change freeze is real. What follows is a defensible sequence for the first day, built around the facts in the Node.js advisory rather than around the score.

Hour one: decide reachability, not severity

The defect is a Brotli decoder out-of-bounds write reachable through node:zlib. The precondition is that an affected application decompresses attacker-controlled Brotli data. So the first hour produces one artifact: a list of services that inflate Brotli input from an untrusted source.
Ask each service owner three questions. Does the service accept Content-Encoding: br or call the Brotli decoder on external data. Is the runtime on line 22.x, 24.x or 26.x below the fixed release. What would an attacker gain from code execution in that process.
Services that answer the first question with no are closed for this CVE with a documented reason. That is not a shortcut; it is the same logic the advisory uses.

Hour two to six: patch the reachable set

Fixed releases are 22.23.4 for line 22.x, 24.22.1 for line 24.x and 26.12.1 for line 26.x. End-of-life branches will not receive a fix and should be treated as permanently affected.
Two traps appear here regularly. A container rebuilt on an unchanged base image can still ship the vulnerable decoder, so the verification step has to read the runtime version from the running process. And a vendored Brotli library needs its own update: the CVE record names 1.0.3 through 1.2.0 in c/dec/decode.c, fixed in 1.0.10, 1.1.1 and 1.2.1.

Hour six to twelve: interim controls where patching waits

Where a reachable service cannot be patched immediately, three controls reduce the blast radius without pretending to fix the bug.
Reject Brotli request bodies on endpoints that never needed them, at the edge if possible.
Cap compressed and expanded size before inflation, so a malformed stream cannot push the decoder through repeated continuation rounds.
Move inflation into a worker with no database credentials and no outbound network access, converting a potential code execution into a restart.
None of these is a substitute for the upgrade, and none should be recorded as remediation.

Hour twelve to twenty-four: check for prior exploitation

Because the crash consequence is the loudest, review process exits that followed requests carrying compressed bodies. Where Content-Encoding is not logged, that query cannot be written, which is itself a finding to fix.
For memory disclosure, look for decoder error paths that return internal detail to clients. For code execution, look for outbound connections or child processes from decoding workers. Absence of evidence here is not evidence of absence, and the runbook should say so.

What the advisory adds beyond the CVE

The same October 21, 2026 release fixes nine other issues across the runtime, including DNS name truncation, three TLS hostname verification bypasses and a keep-alive response ordering flaw. Ship them together. A hotfix that patches only the Brotli identifier will leave a fleet with an inconsistent version baseline and a second change window nobody planned.

Close-out criteria

An incident can be closed when every reachable service runs a fixed release, every vendored decoder meets the version floor, image rebuilds are verified from inside the process, and the remaining services have a documented reason for being out of scope.
The defect was reported by Khai Tran and Sylvie Mayer of OpenAI Codex Security and fixed by mcollina and aduh95. For responders, the useful discipline is to write the reachability list before touching the patch queue.