DEV Community: kozhevniko

1,897,463 MongoDB services: how unauthenticated data stores became routine

kozhevniko — Tue, 06 Oct 2026 21:40:33 +0000

1,897,463 MongoDB services: how unauthenticated data stores became routine

The problem

MongoDB and Redis share a pattern: both were designed to run inside a trusted network, both became a common backend for quickly written applications, and both continue to appear at scale in exposure data. When authentication is optional in practice, it is often absent in production.

Method and scope

On 2026-09-30 (UTC) we queried ZoomEye for the MongoDB service fingerprint:

Query: service="mongodb"
Scope: all asset types, global
Matching assets: 1,897,463
Search link: https://www.zoomeye.ai/searchResult?q=c2VydmljZT0ibW9uZ29kYiI%3D We also attempted to scope exploitation history directly with a query for specific CVE identifiers. The queries vul.cve="CVE-2026-88771", vul.cve="CVE-2026-76461" and vul.cve="CVE-2026-94127" each returned zero matched assets. That result is reported here as a measurement limitation, not as evidence that those vulnerabilities are absent from the environment.

Why the count is a standing problem

A reachable database is different from a reachable web service. A web flaw usually requires a specific vulnerability to exist, while an unauthenticated data store requires only a connection. The reported outcome in these cases is rarely a single record; it is usually wholesale copying of a collection, often followed by a ransom note left in place of the data.
The pattern repeats because the convenient deployment habit is hard to break. A developer starts a container, connects from an application, and moves on. Authentication is deferred, binding is left at the default, and the firewall rule that was supposed to restrict access is created later or never. The service then stays reachable for years.

What to check

Confirm the bind address and enable authentication, then verify from outside the host that an unauthenticated connection is refused.
Restrict network access so that only application hosts can reach the database port.
Enable role-based access control and give each application only the privileges it needs.
Enable audit logging if the deployment supports it, and monitor for bulk read operations.
Verify that backups are current and that a restore has been tested, because the recovery path matters when data is copied or deleted.

Reading the measurement

1,897,463 counts services matching the MongoDB fingerprint. It cannot report whether authentication is enforced, because that would require an authenticated connection. The figure measures visibility, which is a proxy for the population that must be checked by its owners.

Limitations

Cloud providers, managed database services and private networks hide most production instances from external measurement. The zero results from the vulnerability queries also show that the platform's vulnerability index does not cover every recent CVE at the time of collection. Both points should be stated plainly when a number like this is cited internally.

References

MongoDB security checklists on authentication, authorization and network exposure.
ZoomEye queries service="mongodb" and the vulnerability identifier queries, collected 2026-09-30 UTC.

6,378,556 Hosts on Port 10250: The Cluster Node Interface That Assumes a Trusted Network

kozhevniko — Tue, 06 Oct 2026 14:20:31 +0000

6,378,556 Hosts on Port 10250: The Cluster Node Interface That Assumes a Trusted Network

Kubernetes distributes a control interface to every node in a cluster. The kubelet agent, which starts and manages containers on a host, exposes an HTTP API on port 10250 that the control plane uses to run commands, read logs and query node status. A query for port="10250" returned 6,378,556 matching assets on 23 September 2026.

Measurement scope

The query was executed once against the ZoomEye index on 23 September 2026: port="10250". It returned 6,378,556 matching assets. The unit is a listening service on that port at the recorded collection time, which includes cluster node interfaces and any other software bound to the same port.

Why a node interface is sensitive

The kubelet API is designed for the control plane. Its authentication and authorization behaviour is configurable, and a node configured to accept anonymous requests gives any client on the network the ability to perform the same operations the control plane performs: list pods, retrieve container logs, execute commands inside running containers and read the credentials that those containers are given.
That last capability matters most. Workloads in a cluster are commonly issued service account tokens and mounted secrets. A client that can execute inside a container inherits everything that container can reach, which often includes internal APIs, database credentials and cloud provider identity. The path from a node interface to an identity is short.
The component also sits outside what most teams monitor. The kubelet is not an application the team deployed, it is part of the platform, and its port is rarely in an application inventory. Cluster-level network policy tends to govern pod-to-pod traffic, while the node interface lives on the host network.

What 6,378,556 supports

The figure supports a scoping conclusion. A population of this size means that cluster node interfaces are reachable from untrusted networks in large numbers, and that automated scanning for this port will find candidates without any targeting decision on the attacker's part.
It also supports an inventory point. Port 10250 is registered to a specific purpose, and other software does bind it. A match count in the millions indicates broad exposure of whatever is listening, and the appropriate defensive response is to determine which of an organisation's own systems are in the set rather than to reason about the total.

What the count cannot support

The count does not indicate the authentication mode of any individual node. A kubelet that requires authenticated requests and a kubelet that permits anonymous access both listen on the same port, and the difference between them determines the impact of the exposure.
It does not indicate authorization configuration. Even with authentication in place, a permissive authorization mode can allow authenticated requests far beyond what the cluster intends.
It does not distinguish cluster nodes from standalone container hosts that expose a compatible interface, nor from services unrelated to Kubernetes that happen to be bound to the port.
It does not measure exploitation. No claim about compromise follows from a port count, and none is made here.

A practical test, run from inside

The useful version of this measurement is performed by the cluster operator rather than against the internet. From a machine outside the cluster network, attempt an unauthenticated request to the node interface and observe whether the API answers with node or pod information. Where it does, the node is published beyond its trust boundary and the response itself is the evidence.
Alongside that test, three checks belong in the same review. Confirm that the node interface is reachable only from the control plane and from any monitoring systems that require it, using network controls rather than application configuration. Confirm that anonymous authentication is disabled and that the authorization mode is set to a restrictive option. Confirm that workload credentials are short-lived and scoped, so that a single container read does not yield standing access to everything the cluster touches.

References

ZoomEye port query port="10250", collected 23 September 2026: 6,378,556 matching assets
CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

GitOps control planes: the Argo CD exposure question

kozhevniko — Tue, 06 Oct 2026 12:20:31 +0000

GitOps control planes: the Argo CD exposure question

A GitOps controller holds the credentials that let it change a cluster. It reads from a repository and writes to a Kubernetes API, and it usually does so across several clusters at once. That combination makes the controller's own web interface and API a high-value target, and it explains why Argo CD's documentation devotes a full page to security considerations.

Context and method

Counts were collected through the ZoomEye SDK on 2026-09-26 UTC. Both queries returned the same total, which is informative on its own.

app="Argo CD": 61,983
title="Argo CD": 61,983 An identical result from a fingerprint query and a title query is unusual. It suggests the matching paths converged on the same set of responses rather than that the two independent methods agree by coincidence. The number should be treated as indicative of a widely deployed product that is easy to identify from its responses, and it is not a count of misconfigured installations.

What the controller can do

The controller stores connection details for the clusters it manages and the repository credentials it uses. Its interface shows the state of applications, and depending on permissions it can trigger a sync, which applies whatever is in the repository to the cluster. In the common single-sign-on deployment the front end delegates authentication to an identity provider, so the exposure question becomes whether that delegation is actually enforced on every path into the service, including the API and the CLI.

Configuration points that decide the exposure

The initial administrator account is a real credential that many deployments keep enabled after single sign-on is configured. Anonymous access is a documented setting and is enabled deliberately in some evaluations. TLS termination is often delegated to an ingress controller, and the ingress configuration decides whether the service is reachable besides the intended hostname. Repository credentials may be stored as cluster secrets or referenced from an external store, which changes what a cluster read yields.

Checks worth running

List the hostnames that resolve to the controller and request each of them, rather than testing only the documented one. Confirm that the initial admin account is disabled or its password rotated, and that anonymous access is off. Review the roles bound to the controller's service account, because those roles define what a sync can change. Check whether repository credentials are reachable from the controller's namespace, and whether an audit log records sync operations with an attributable identity.

References

Argo CD documentation, security considerations
Argo CD documentation, RBAC configuration and the default admin account
Argo CD documentation, private repository credential management

Group-IB's August 2026 APAC Ransomware Data: What 190 Incidents Actually Tell You

kozhevniko — Tue, 06 Oct 2026 09:40:31 +0000

Group-IB's August 2026 APAC Ransomware Data: What 190 Incidents Actually Tell You

Group-IB published ransomware tracking for the Asia-Pacific region covering August 2026. The recorded total was 190 incidents, a 26.7 percent increase month over month. The country distribution is instructive: India led with 32 incidents, Australia followed with 24, and Taiwan placed third with 20. Manufacturing was the most targeted sector with 38 incidents, and a single group, The Gentlemen, accounted for 37 of the incidents in the period.

Reading the numbers honestly

Public ransomware counts measure one thing well and several things poorly. They measure claims, because they are built largely from leak-site monitoring. They do not measure the true incident rate, because many victims never appear on a leak site and many claims are exaggerated or duplicated.
That caveat does not make the data useless. It makes it a signal about attacker attention rather than a complete census. A month-over-month rise of 26.7 percent in recorded claims means more pressure on disclosed victims, and it means the groups producing those claims are active.

What the distribution suggests

The sector split matters more than the country split for most defenders. Manufacturing's lead is consistent with the pattern that has held for several quarters: production systems have availability requirements that make them hard to take offline, and operational technology boundaries are uneven. The concentration in a single group, 37 incidents from The Gentlemen, points to a disciplined operator running a repeatable playbook rather than a crowd of independent actors.

How to use this

Treat the report as a prioritization input, not a benchmark. If your organization sits in manufacturing, or in the countries at the top of the list, the relevant question is whether your identity controls, backup isolation and recovery testing would survive an operator running that playbook. Leak-site statistics will not answer that question. Your own tabletop exercise will.

References

Group-IB ransomware activity report for the Asia-Pacific region, August 2026

Detection and verification for CVE-2026-102795 in Apache Traffic Server

kozhevniko — Mon, 05 Oct 2026 23:20:30 +0000

Detection and verification for CVE-2026-102795 in Apache Traffic Server

Overview

CVE-2026-102795 is an improper access control flaw in Apache Traffic Server, published 2 October 2026. Apache Traffic Server 9.0.0 through 9.2.14 and 10.0.0 through 10.1.3 are affected. Fixed releases are 9.2.15 and 10.1.4. The advisory frames the issue as a SNI to Host header matching policy that does not behave as intended.

What defenders can actually verify

This is not a vulnerability that produces a distinctive log line, so detection starts with configuration and version truth rather than signature hunting.
Version truth. Enumerate every Traffic Server instance, including instances behind load balancers and instances in disaster-recovery sites that rarely carry traffic. Record the build string, not the package name.
Configuration truth. Identify which instances terminate TLS and route by hostname. For each, list the virtual hosts that are expected to serve content. An entry that nobody can justify is worth investigating.
Behaviour truth. In staging, issue two requests: one where the SNI and Host values match, and one where they deliberately do not. If the second request is served rather than refused, the deployment is relying on behaviour the fix is meant to change.

A note on absence of evidence

No exploitation in the wild has been reported for CVE-2026-102795, and there is no confirmed public proof of concept. The absence of exploitation reports is not evidence that exposure is theoretical, but neither does it justify describing the flaw as actively attacked. Both overstatement and dismissal are failures of the same kind: they substitute a conclusion for the available facts.

Affected products and scope

Branch	Affected	Fixed
9.x	9.0.0 - 9.2.14	9.2.15
10.x	10.0.0 - 10.1.4 and earlier	10.1.4

The earlier CVE-2026-41920 record gave the wrong 9.x range and pointed at 9.1.15; CVE-2026-102795 supersedes it.

Exposure context

ZoomEye measured 311,469 assets matching app="Apache Traffic Server" on 3 October 2026, with 0 for vul.cve="CVE-2026-102795". Use the first figure to size the inventory effort and the second to remind yourself that index coverage lags disclosure.

Remediation and validation steps

Upgrade to 9.2.15 or 10.1.4.
Confirm the running build identifier on every instance.
Re-run the staged matching and mismatching request pair and store the results.
Remove catch-all virtual hosts so an unexpected name fails closed.

References

SecurityOnline reporting on the Apache advisory batch, 3 October 2026
Apache Traffic Server download and release information

FusionAuth: 2,411 title matches on the authentication server that issues your tokens

kozhevniko — Mon, 05 Oct 2026 22:40:29 +0000

FusionAuth: 2,411 title matches on the authentication server that issues your tokens

An authentication server signs the tokens that applications accept as proof of identity. FusionAuth fills that role for many deployments, and a ZoomEye title search for title="FusionAuth" on 2026-10-01 returned 2,411 matches.

What the query measured

The figure is a title-field result. It counts pages that render the FusionAuth name in their HTML title, which includes the administrative interface, the login pages served for tenant applications, and documentation instances. It does not confirm a version or an installation, and it should be read as a population indicator.
Two thousand four hundred and eleven matches give an owner a list of manageable size. Reconciling it against a host inventory is a task of hours rather than weeks, which makes the query a practical inventory input rather than a research exercise.

The material the server holds

FusionAuth stores user records, application registrations, signing keys and the configuration for the identity providers it federates with. Its documentation covers tenants, applications, API keys, and the way signing keys are generated and rotated.
Key material is the important part. A signing key that is reachable by an unauthorised party allows tokens to be forged for any application that trusts the server, and the tokens are accepted without further checks by design. The same applies to the API keys that administrative clients use.

The checks that follow from 2,411

The review is familiar to anyone who has audited an identity server. Is the administrative interface reachable from outside the perimeter, and does it require multi-factor authentication? Are the API keys scoped, rotated and stored outside the application configuration? Is the login page for each tenant exposed only where it needs to be?
Reviewing the list also involves a question that the count cannot answer: whether any of the matches belong to the organisation without being in its inventory. Measurement finds services that documentation misses, and identity servers are the ones where that gap matters most.

Implications

Identity servers are configured once and then depended upon for everything else. The count sets the population, and the configuration review decides whether the dependency is a controlled one.

References

ZoomEye query for title="FusionAuth": https://www.zoomeye.ai/searchResult?q=dGl0bGU9IkZ1c2lvbkF1dGgi
FusionAuth documentation: https://fusionauth.io/docs/
FusionAuth source repository: https://github.com/FusionAuth/fusionauth-containers

CVE-2026-80097: The Authenticator App Is a Credential Store, Not Just a Prompt

kozhevniko — Mon, 05 Oct 2026 21:20:30 +0000

CVE-2026-80097: The Authenticator App Is a Credential Store, Not Just a Prompt

Microsoft Authenticator was the control most organisations reached for once they moved past SMS codes. CVE-2026-80097 concerns improper authentication in that app, and it is worth reading carefully rather than filing under "mobile bug".

What the record says

NVD describes CVE-2026-80097 as improper authentication in Microsoft Authenticator allowing an unauthorized attacker to elevate privileges locally. The weakness is CWE-287, and the CVSS base score is 8.6. It was published on 8 September 2026, and Microsoft's update guide is the vendor reference.
The important qualifiers are "locally" and "elevate privileges". This is not a remote takeover of the vault. It is a flaw in the authentication logic of a component the organisation has designated as the thing that proves identity.

Why an authenticator app is not just a second factor

Microsoft Authenticator holds far more than one-time codes. It stores passwordless credentials, push notification registrations, account metadata for every identity the user has linked, and it acts as a broker for sign-ins through the Microsoft identity platform. On a shared or supervised device it can span multiple accounts.
The app's own authentication boundary is therefore a security control in its own right. If an attacker already has a foothold on the device, the question is whether reaching the app's internal state requires anything more than what that foothold provides. A local elevation in a credential-bearing app changes the answer, and it changes it for every account the app can act for.

The small, boring mitigations that work

Enforce device passcodes and biometrics on any device that holds an authenticator app, and require re-authentication at the OS level rather than inside the app alone. The app's own lock screen is a convenience feature; the platform lock is the control.
Keep number matching enabled rather than simple approve/deny. Number matching does not fix this flaw, but it is the control that removes the entire class of MFA fatigue attacks, and it costs nothing.
Limit how many accounts a single device holds. A personal phone carrying one corporate identity is a smaller blast radius than a tablet signed into six tenants.
Then check for rooted and jailbroken devices among the population that holds authenticator registrations. Local privilege escalation flaws are worth materially more on a device whose platform integrity is already broken.

Patch management for an app nobody counts

Mobile applications sit outside most software inventory, which is the awkward part. The practical approach is to use whatever device management is in place to report installed application versions on managed devices, and to close the gap by policy on unmanaged ones: require that the app be updated within a defined window, and treat out-of-date authenticator builds the same way as an unpatched VPN client.

References

NVD record for CVE-2026-80097: https://nvd.nist.gov/vuln/detail/CVE-2026-80097
Microsoft update guide entry: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097

Container Registries and Orchestration: 57,017 Harbor and 78,059 Consul Fingerprints

kozhevniko — Mon, 05 Oct 2026 14:00:29 +0000

Container Registries and Orchestration: 57,017 Harbor and 78,059 Consul Fingerprints

Two sides of the same deployment

Container registries distribute images to the hosts that run them. Service discovery and configuration systems tell those hosts where everything else is. Together they describe an application platform's internal map, and their internet exposure is worth measuring separately because each exposes a different capability.

The measurements

Queried on 25 September 2026 through the ZoomEye SDK with application fingerprints: app="Harbor" returned 57,017 matching assets, app="Consul" returned 78,059, and app="Docker Registry" returned 1. Counts represent fingerprint matches in ZoomEye's index at query time.

What each exposure leaks

A reachable container registry is a distribution point. If an attacker can push to it, every host that pulls from it receives the attacker's image. If they can only read from it, the registry still discloses which images the organisation runs, including internal-only components whose names and versions are otherwise not published.
A reachable service discovery or configuration system is a map. Consul, for example, can expose the service catalogue, health status, and in some configurations the key-value store used for dynamic configuration. That is a reconnaissance advantage that does not require exploiting anything: it tells the attacker what exists and often where it runs.
The Docker Registry count of 1 is a reminder that fingerprint naming is inconsistent across products. The official registry image presents itself in ways that the fingerprint may not match reliably, so a count of 1 should be read as a fingerprint limitation rather than as evidence that one registry is exposed.

Why the registry number deserves attention

The Harbor count is the one to act on. The same September 2026 exploitation cluster that included artifact repositories also demonstrated that the default configuration of a software distribution system can be an authentication bypass. A registry with an administrative interface reachable from the internet inherits the same risk category, and unlike an application server it can be used to distribute code to production.

Practical checks

Restrict registry and service catalogue APIs to the networks that need them, and require authenticated, scoped tokens for pulls rather than anonymous access.
Enable and verify content signing or provenance so that a pushed image can be attributed, since detection of a malicious push depends on being able to tell legitimate images from new ones.
Review the key-value store for secrets placed there for dynamic configuration, and rotate anything that was reachable during a suspected exposure window.

Limitations

Fingerprint counts depend on how services present themselves and undercount deployments behind proxies or authentication gateways. Harbor saw a significant share of its deployments moved behind corporate identity providers after earlier advisories, which the count does not distinguish. All figures are single-date observations.

References

ZoomEye search, executed 25 September 2026: app="Harbor" returned 57,017 matching assets; app="Consul" returned 78,059; app="Docker Registry" returned 1 (SDK, sub_type=all, total count)
CISA Known Exploited Vulnerabilities catalog, September 2026 additions referenced for context: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
MITRE ATT&CK T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190

Drupal Contributed Modules: 36 CVEs in One September 2026 Advisory Batch

kozhevniko — Mon, 05 Oct 2026 12:00:31 +0000

Drupal Contributed Modules: 36 CVEs in One September 2026 Advisory Batch

What the advisory says

CERT-BUND published advisory WID-SEC-2026-3554 on 23 September 2026 and rated it high risk. The record collects 36 CVE identifiers, from CVE-2026-96355 through CVE-2026-96398, against contributed Drupal projects rather than Drupal core.
The affected projects are Webform, Webform REST, Cloud, Project Browser, Commerce Decoupled Checkout, Mermaid Diagram Field, CookieCuttr, REST & JSON API Authentication, Stop administrator login, Tawk.to Live chat application, Editoria11y Accessibility Checker, AI CKEditor, Combined image style, CSS Usage Analyzer, Smart Content and Diba carousel slider.
The advisory describes consequences that span remote code execution, privilege escalation, security control bypass, data manipulation and disclosure, and cross-site scripting. That breadth matters for triage: an operator cannot assume a single exploit class and a single detection rule will cover the batch.

Why contributed modules drive the risk

Drupal core receives focused security attention and a predictable release rhythm. Contributed projects do not. They are maintained by volunteers and small vendors, they carry their own release schedules, and many sites enable a dozen or more of them. A site that patches core promptly can still run an outdated contributed module for months.
The batch also shows how a maintenance wave produces a cluster of identifiers at once. Nineteen projects published fixes on the same day, and the structured record points to 36 separate Drupal security advisories, sa-contrib-2026-154 through sa-contrib-2026-191. Operators who only watch Drupal core announcements will miss all of them.

Exposure context

A ZoomEye query on the product fingerprint returned 436,286 matching Drupal assets at the time of writing. The figure describes Drupal deployments in the index, not deployments that carry a vulnerable contributed module. Publicly reachable Drupal sites remain the pool from which an attacker has to find one that runs an unpatched extension.

What to do first

Inventory the contributed projects on every Drupal site you run, then compare each version against the fixed releases. Build the comparison from the advisory rather than from memory, because several projects shipped two fixed branches.
Stop at the highest-value targets. A module that handles authentication or API access deserves attention before a presentation-layer module, even though both appear in the same advisory.

Patch and verify

Deploy the fixed versions, then confirm the running code changed. Drupal caches aggressively, and a stale container image or an unapplied update hook leaves the vulnerable code in place while the version string looks correct.
Check the advisory pages for each project you use. Where a vendor describes a configuration that avoids the flaw, apply it until the update lands in production.

References

CERT-BUND advisory WID-SEC-2026-3554, published 23 September 2026
CERT-BUND structured advisory record, including the product version list and referenced Drupal advisories sa-contrib-2026-154 to sa-contrib-2026-191
ZoomEye exposure query app="Drupal", executed 24 September 2026, exact count 436286

Jupyter Notebooks on the Open Internet: 408,240 Body Matches

kozhevniko — Mon, 05 Oct 2026 09:20:32 +0000

Jupyter Notebooks on the Open Internet: 408,240 Body Matches

Jupyter is infrastructure that teams deploy and then rarely revisit. ZoomEye indexes the service side of those deployments, and the observed population is large enough that the exposure question is worth stating with the measurement attached rather than with an adjective.

What was measured

ZoomEye was queried for Jupyter pages. The query http.body="Jupyter" returned 408,240 matches. The measurement was taken on 2026-10-04 (UTC) with the SDK sub_type set to all, which covers device and domain assets in one scope. A second, narrower fingerprint was collected. The query title="Jupyter" returned 149,922 matches, which shows how much a result depends on the field chosen rather than on the asset population itself. The number is an index count of matching assets, not a count of vulnerable or misconfigured systems.

Why the number is not the finding

A port answer or a product fingerprint tells you that something is speaking the protocol. It does not tell you whether authentication is enabled, whether the instance is a lab that will be deleted tomorrow, or whether the service is reachable from the public internet by design.
A notebook server is an execution environment with a browser front end. A body-content query returns 408,240 matches, and the operational question is how many of them accept a request without a token.

What the exposure actually means

The practical reading of a count this size is that the service is common, that scanning tools find it cheaply, and that the security of each instance depends on configuration decisions made by the operator rather than on the protocol. Attackers do not need to enumerate the whole population; they need the subset that answers without credentials, and that subset is discovered by probing rather than by counting.
Jupyter has supported tokens and password authentication for years, and the classic failure is a server started with authentication disabled or bound to all interfaces during debugging and never stopped. Execution in a notebook reaches the host through the functions the kernel can call, which makes an unauthenticated notebook server equivalent to remote code execution.

How to use this measurement

The verification step is to request the server root without a token and see whether a kernel list is returned. The configuration step is to keep the server on localhost behind an SSH tunnel, or to place authentication in front of it. Version control history, environment variables and the notebook files themselves frequently contain credentials that the server will display to whoever asks.
ZoomEye is useful here because it reports what the internet can see rather than what the configuration was intended to be. That gap, between intent and observation, is where this class of exposure lives.

References

Jupyter documentation: Running a public notebook server: https://jupyter-notebook.readthedocs.io/en/stable/public_server.html
Jupyter Server documentation: Security: https://jupyter-server.readthedocs.io/en/latest/operators/security.html
ZoomEye search for the primary query, measured 2026-10-04 (UTC), sub_type=all: 408,240 matches

Why vul.cve Returns Zero for CVE-2026-96365: Reading Exposure Data Honestly

kozhevniko — Sun, 04 Oct 2026 23:00:29 +0000

Why vul.cve Returns Zero for CVE-2026-96365: Reading Exposure Data Honestly

Vulnerability overview

CVE-2026-96365 is one of 36 identifiers in CERT-BUND advisory WID-SEC-2026-3554, published 23 September 2026 and rated high risk. The advisory covers 16 contributed Drupal projects, with identifiers running from CVE-2026-96355 to CVE-2026-96398. Interpretation starts with the two ZoomEye results collected for this article.

Mechanism and exploitation conditions

The public record describes remote exploitation in five outcome classes: arbitrary code execution, extended privileges, bypass of security measures, data manipulation or disclosure, and cross-site scripting. It does not publish the defect behind each identifier, and that gap carries into external scanning. A scanner indexes what a service presents; a flaw in a contributed module may not present anything distinct enough to fingerprint.

Impact

CERT-BUND scores probability and damage at 4 out of 4, with a CVSS v3.1 base score of 9.8 and a temporal score of 8.5. The scanning gap does not reduce that severity. It only means external data cannot substitute for internal assessment.

Affected products and scope

The affected projects and their fixed releases are Webform 6.2.12 and 6.3.1, Webform REST 4.2.1, Cloud 7.0.1, Project Browser 2.0.3 and 2.1.5, Commerce Decoupled Checkout 1.8.0, Mermaid Diagram Field 1.0.9, CookieCuttr 2.0.3, REST & JSON API Authentication 3.2.0, Stop administrator login 1.6, Tawk.to Live chat application 3.0.4, Editoria11y Accessibility Checker 2.2.23 and 3.0.9, AI CKEditor 1.4.3, Combined image style 1.0.7, CSS Usage Analyzer 1.0.2, Smart Content 3.2.1, and Diba carousel slider 3.0.2.

Exposure context

Two queries were run on 27 September 2026. The product query app="Drupal" returned 436403 indexed assets. The vulnerability query vul.cve="CVE-2026-96365" returned 0. The second result means the identifier is not indexed as an exposed service, which is expected for a freshly assigned CVE. Neither count identifies hosts running an affected module, and no count should be read as a victim tally.

Remediation and mitigations

Use the product count to size the population to review and the module list to scope what to check. Patch each affected module to the fixed release for its branch. Keep the two evidence types separate in reporting: what the internet shows about Drupal deployments, and what the inventory shows about modules you run.

References

CERT-BUND advisory WID-SEC-2026-3554, published 23 September 2026: https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-3554
CERT-BUND structured record for WID-SEC-2026-3554, 16 projects and 19 fixed releases: https://wid.cert-bund.de/content/public/content/3f0df5d6-5291-41b3-92f2-0c016281c91f
ZoomEye search app="Drupal", executed 27 September 2026, exact count 436403: https://www.zoomeye.ai/searchResult?q=YXBwPSJEcnVwYWwi

Triage Order After a Credential-Exposure Advisory: What to Fix First on Fortinet Edge Devices

kozhevniko — Sun, 04 Oct 2026 22:00:28 +0000

Triage Order After a Credential-Exposure Advisory: What to Fix First on Fortinet Edge Devices

On 18 June 2026, the Australian Cyber Security Centre (ACSC) published an alert titled "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways" [1]. The alert is aimed at all Australians and Australian organisations that use Fortinet devices, and it describes a malicious campaign that is reported to be widespread, largely using exposed credentials and credential-based attacks against Fortinet firewalls and VPN gateways. The ACSC states that this activity can lead to potential compromise and further credential exposure.

The advisory is explicit about the consequence it is concerned with: leveraging these credentials could enable a malicious actor's remote access to the devices and connected networks, as well as allow changes to various settings, including security controls [1]. That is the risk model. It is not a story about a newly disclosed software vulnerability being exploited. The ACSC describes credential-based attacks against internet-facing edge devices. The alert does not name a CVE, does not publish an affected version list, and does not state how many devices or organisations were affected [1]. Those omissions matter for triage, because they mean the scope of the event cannot be bounded from the advisory alone.

The alert's mitigation advice is a list: rotate all admin and VPN credentials immediately; ensure devices are patched against older-firmware vulnerabilities; restrict management interface exposure so that firewall admin and management interfaces are not internet accessible unless necessary; enforce MFA on all external interfaces; store credentials with PBKDF2 hashing, logging back in to admin accounts after updating so that encryption changes to PBKDF2; and examine authentication and access logs for abnormal logins or changes [1]. An update to the alert notes that Fortinet released a blog post and additional guidance, and directs affected organisations to review and monitor that post [1][2].

Read as a checklist, that list invites parallel execution. Read as a risk-sequencing problem, it implies an order. The four main workstreams - credential rotation, firmware currency, management-plane restriction, and MFA enforcement - have different effort profiles, different operational risk, and different dependencies. Running them in the wrong order can either waste effort or create new exposure.

Why the order is not arbitrary

Credential rotation is the only control on the list that directly addresses the reported attack path. If credentials are the vector, then changing them removes the vector for the accounts that are changed. It is also the control with the shortest time-to-effect and, in most environments, the lowest dependency on change windows. That combination argues for doing it first, and the ACSC says to do it immediately [1].

The caveat is that rotation is only durable if the other controls follow. Rotating a credential on a device whose management interface is internet-accessible and whose MFA is absent simply resets the clock. The new credential is exposed to the same collection path as the old one. This is why rotation first does not mean rotation alone.

Firmware currency is the next consideration, but it is not the same kind of control. The advisory asks organisations to ensure devices are patched against older-firmware vulnerabilities [1]. That is a general hardening step, not a response to a named vulnerability in this campaign, because no CVE is named. Patching is higher effort and higher risk than rotation: it can require maintenance windows, it can interrupt VPN service, and it can introduce regressions. It should be planned and executed deliberately, not rushed into the same window as credential rotation unless the environment is small and the change is well understood.

Management-plane restriction is the control that changes the attack surface rather than the credential. If the admin interface is not reachable from the internet, credential-based attacks against that interface lose their transport. The ACSC frames this as a conditional: management interfaces should not be internet accessible unless necessary [1]. The word "unless" is doing real work. Some organisations have a genuine operational need for remote management, and for them the answer is not to remove access but to constrain it - source restrictions, jump hosts, or a VPN that is itself protected by MFA. This work is often slower than rotation because it touches network architecture and change control, but it is more durable than rotation alone.

MFA enforcement on all external interfaces is the control that raises the cost of a stolen credential. It is listed separately from management-plane restriction, and it applies to external interfaces generally, not only to admin access [1]. MFA is high-value but also high-friction: it depends on identity infrastructure, it can break service accounts and automation, and it requires enrolment and support. In a triage order, MFA is the control that should be sequenced after the immediate exposure is reduced, because it is the one most likely to be rolled back under pressure if it is rushed.

PBKDF2 hashing and log review sit at different points again. The PBKDF2 instruction is specific: store credentials with PBKDF2 hashing, and log back in to admin accounts after updating so that encryption changes to PBKDF2 [1]. That is a configuration change with a verification step, and it belongs with the credential workstream rather than as a separate project. Log review is detective rather than preventive, and it should start early and continue, because it is how an organisation learns whether the preventive controls are holding.

A defensible sequence

The order that follows from the advisory's own framing is: rotate, then reduce exposure, then raise authentication cost, then patch on a planned cycle, with log review running throughout. Rotation first because it is immediate and directly relevant. Management-plane restriction next because it removes the transport for the reported attack. MFA next because it protects the credentials that remain in use. Firmware currency on a planned schedule because it is a general hardening measure and carries the most operational risk. PBKDF2 and log review woven into the credential and detection workstreams respectively.

This is a sequence, not a schedule. The point is dependency and risk, not elapsed time. An organisation with a small number of devices and a maintenance window available may compress the sequence. An organisation with a large estate and complex change control may run management-plane restriction in parallel with rotation for different device groups. What the advisory argues against is treating the list as unordered, because the controls are not interchangeable.

Using ZoomEye to scope the estate

Triage needs an inventory. The ACSC alert does not provide an affected version list or a victim count, so an organisation cannot use the advisory to determine whether it is in scope [1]. It has to determine that from its own asset data.

ZoomEye can be used here as an asset-identification and exposure-review input, not as a compromise detector. A query for app="FortiGate" returned an exact count of 983996 internet-observable assets, observed on 2026-09-23 [3]. That figure is the number of internet-observable assets matching that query. It is not a count of compromised devices, not a count of vulnerable devices, and not a count of victims. ZoomEye does not detect compromise, and nothing in this article should be read as claiming that it does.

What the figure is useful for is measurement hygiene and jurisdiction scoping. It establishes the scale of internet-observable FortiGate presence as a population, which is a denominator against which an organisation can compare its own externally visible footprint. If an organisation runs the same query restricted to its own address space, or reviews its own external attack surface, it can identify which of its devices are observable from the internet at all. That is the first question in management-plane restriction: which management interfaces are reachable? The ZoomEye count does not answer that question for a specific organisation, but it frames why the question matters at population scale.

The same query can support continuous monitoring. Re-running an exposure query over time and comparing results is a way to detect changes in what is observable, which is relevant to the management-plane restriction workstream. Again, this is exposure review, not compromise detection.

What the evidence does not establish

The advisory is a reported campaign, not a completed incident report. It does not name a CVE, does not list affected versions, and does not give a victim count [1]. The ZoomEye figure is an observation of internet-observable assets, not an incident metric [3]. Any triage plan built on this evidence should be explicit about those limits. The controls are defensible because they reduce credential-based risk generally, not because they map to a published indicator set.

References

[1] ACSC, "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways", published 2026-06-18T07:18:43Z, updated 22/06/2026. https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/reported-widespread-credential-exposure-affecting-fortinet-firewalls-and-vpn-gateways

[2] Fortinet PSIRT blog, "Analysis of reported credential compromise of FortiGate devices". https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

[3] ZoomEye query app="FortiGate", exact_count=983996, observed 2026-09-23T17:14-17:15Z. https://www.zoomeye.org/searchResult?q=app%3D%22FortiGate%22