DEV Community: jeffrey

CVE-2026-102795 in Apache Traffic Server: building a version inventory before you patch

jeffrey — Wed, 07 Oct 2026 08:00:33 +0000

CVE-2026-102795 in Apache Traffic Server: building a version inventory before you patch

Vulnerability overview

Apache Traffic Server is affected by CVE-2026-102795, an improper access control flaw that the Apache Software Foundation disclosed on 2 October 2026 as part of a batch of eight CVEs spanning three projects. The same advisory batch covered Apache OpenOffice and the Apache Directory LDAP API. Reporting on the batch places CVE-2026-102795 at the top of the severity table with a 9.3 CVSSv3 score, while the accompanying prose describes it as an improper access control issue rated 7.0 on CVSS 4.0. Both figures appear in the same secondary report, and NVD had not published an analysed record at the time of writing, so treat the precise score as unsettled rather than as an established fact.

What the flaw concerns

The published description states that a "SNI to Host header matching policy is not properly enforced". SNI, the Server Name Indication extension, travels in the TLS handshake and tells a listener which certificate and, by extension, which virtual service the client expects. The HTTP Host header carries a similar claim inside the request itself. Operators who run Traffic Server in front of multiple backends typically want those two values checked against each other so that a client cannot retrieve content through an unintended route. CVE-2026-102795 concerns a case where that enforcement does not hold as intended.
Apache has not published a step-by-step exploitation narrative in the material available so far, and no public proof-of-concept is confirmed. That makes the practical question narrower than it first appears: which of your properties relies on SNI and Host agreement for separation, and does that separation still hold after the upgrade?

Affected products and scope

The affected range is unusually clean to enumerate:

Apache Traffic Server 9.0.0 through 9.2.14
Apache Traffic Server 10.0.0 through 10.1.3 The fixed releases are 9.2.15 and 10.1.4. Administrators should note that a prior record, CVE-2026-41920, described the same access control weakness but listed an incorrect 9.x range and named 9.1.15 as the fix. Anyone who used that earlier record as the basis for a change ticket may have concluded they were already current. They were not.

Exposure context

A ZoomEye query for app="Apache Traffic Server" returned 311,469 matching assets on 3 October 2026. A separate query on vul.cve="CVE-2026-102795" returned 0, which is expected for a freshly published CVE that indexers have not yet correlated.
The product figure describes the size of the observable population. It does not mean that 311,469 systems are vulnerable, because it cannot distinguish a current build from an older one and cannot tell whether SNI and Host matching is part of any given deployment's design.

Remediation and validation

Upgrade to 9.2.15 or 10.1.4 and then confirm the change rather than assuming it. A useful check has three parts. First, verify the running build identifier through your normal configuration endpoint or package metadata. Second, if your deployment depends on SNI and Host agreement, reproduce the routing decision in a staging environment with both a matching and a deliberately mismatched pair. Third, keep the evidence attached to the change record, because the superseded CVE record makes "we already patched this" a plausible and incorrect conclusion for a reviewer to reach.

References

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

ZooKeeper Information Disclosure: Existence Watches Leak Restricted Znode Names

jeffrey — Wed, 07 Oct 2026 05:20:33 +0000

ZooKeeper Information Disclosure: Existence Watches Leak Restricted Znode Names

Summary

Among the four Apache ZooKeeper flaws fixed in September 2026, CVE-2026-59739 exposes information rather than allowing direct deletion. The bug sits in the watch management subsystem and resurfaces during client reconnection.

Background

An earlier patch intended to close a watch-management weakness. That fix proved incomplete. The incomplete patch is the root cause of the current issue.

Mechanism

Attackers register existence watches on paths that do not exist yet. When a client reconnects, the service returns watch-related data that reveals restricted znode names. The node payload itself stays protected, which is why this is an information disclosure and not a data breach of stored values.

What leaks and why it matters

Exposed paths frequently contain sensitive usernames and internal identifiers. Naming conventions in a ZooKeeper tree can reveal service topology, environment names or account references. That reconnaissance shortens the path to follow-on attacks, including the unauthenticated deletion path described in CVE-2026-79993.

Scope

Affected releases are ZooKeeper 3.8.0 through 3.8.6 and 3.9.0 through 3.9.5. Apache reported no confirmed exploitation and no public proof-of-concept.

Mitigation

Move to 3.8.7 or 3.9.6. Until then, limit who can reach port 2181 and treat znode naming as sensitive metadata. Operators should also watch for unusual watch registration against non-existent paths.

References

Critical Apache ZooKeeper Vulnerabilities Patched in Update (SecurityOnline): https://securityonline.info/apache-zookeeper-vulnerabilities-fixed/
Apache ZooKeeper security advisories: https://zookeeper.apache.org/security.html

CVE-2026-95675: Unauthenticated Root Command Injection in D-Link DAP-1360 Firmware

jeffrey — Wed, 07 Oct 2026 04:20:33 +0000

CVE-2026-95675: Unauthenticated Root Command Injection in D-Link DAP-1360 Firmware

Vulnerability overview

CVE-2026-95675 is a critical OS command injection flaw in the web management interface of the D-Link DAP-1360, a long-retired wireless access point and range extender. The vulnerability is rated Critical, with a reported CVSS v3 score of 9.8. Public technical analysis and working exploit code are available. D-Link has confirmed that it will not release a fix.

Mechanism and exploitation conditions

The defect lives in the device's web server binary rather than in a plugin or optional service. The network diagnostic handler behind apply.cgi reads a value from the ipv4 ping parameter, formats it into a system ping command, and hands the resulting string to the command interpreter without sanitising it.
Because the string is never escaped, an attacker can append shell metacharacters. The interpreter then treats the trailing text as additional commands. The endpoint performs no authentication check, so no credentials, session, or prior access to the administrative UI is required. Commands execute with root privileges, which is the highest privilege level on the appliance.

Impact

Successful exploitation gives an unauthenticated remote attacker full command execution as root through the management interface. From there an attacker can read and rewrite device configuration, alter routing or wireless settings, and install a persistent foothold that survives reboots. A compromised access point is an attractive pivot point: it sits inside the network perimeter, it is usually trusted, and it is rarely monitored as closely as a server.

Affected products and scope

All hardware revisions of the D-Link DAP-1360 running firmware version 6.14 and earlier are affected. D-Link formally retired the DAP-1360 product family in August 2020, and the vendor states that all firmware development for the product has ceased. There will be no patched release.

Exposure context

A ZoomEye search for the product fingerprint app="D-Link DAP-1360" returned 423 matching instances worldwide at the time of writing. A CVE-scoped query, vul.cve="CVE-2026-95675", returned no indexed assets, which is expected for a freshly assigned identifier. The product fingerprint therefore gives the more useful exposure estimate, and it only counts assets that still answer with a recognisable DAP-1360 signature; devices hidden behind firewalls or with a modified management banner are not represented.

Remediation and mitigations

There is no firmware fix and none is planned. The only complete remediation is replacement with supported hardware.
Where replacement cannot happen immediately, apply compensating controls: block access to the device's web management interface from untrusted networks, place the management UI on a dedicated VLAN restricted to trusted administrators, and treat any DAP-1360 as a potentially compromised asset if it has ever been reachable from an untrusted network. Inventory the installed base, confirm which units still carry firmware 6.14 or older, and prioritise their removal.

References

D-Link DAP-1360 vulnerability details and PoC
D-Link product security advisory for the retired DAP-1360 family

426,677 titles against 12,055 fingerprints: locating the Tenda gateways behind CVE-2026-104610

jeffrey — Wed, 07 Oct 2026 03:00:32 +0000

426,677 titles against 12,055 fingerprints: locating the Tenda gateways behind CVE-2026-104610

CVE-2026-104610 affects the Tenda HG7, HG9 and HG10 fibre gateways. Finding them from outside is harder than the headline severity suggests, because the obvious query and the accurate query return very different populations.

What we measured

Two queries were run against ZoomEye on 2026-10-04 (UTC), both at sub_type=all with a page size of one:

title="Tenda" returned 426,677 matching services.
app="Tenda" returned 12,055 matching services. The first number counts anything whose HTML title contains the vendor name. That includes the vendor's product pages, reseller listings, documentation mirrors, and the router interfaces themselves. The second number is the application fingerprint the platform assigns to Tenda devices. For an inventory of devices, the fingerprint is the closer estimate, and 12,055 is the defensible figure.

Why the title match is the wrong query

Title-based searches on a consumer networking brand are noisy by construction. A page titled "Tenda N300 Wireless Router" is a shop page. A device interface is usually titled with a generic login string or a model number rather than the brand. The title query therefore over-counts non-devices and under-counts real ones, sometimes in the same result set.
The honest conclusion is that neither query identifies which gateways are affected models. The HG7, HG9 and HG10 are carrier-supplied fibre terminals, and a carrier-grade deployment rarely advertises a marketing title. The device may answer HTTP with a minimal page and a firmware string, which is what the application fingerprint is built from.
That is a general lesson about exposure measurement: for consumer and carrier equipment, the relationship between searchable metadata and the affected population is weak. The measurement describes discoverability, not deployment.

What the number is good for

The 12,055 figure is still useful, for a specific purpose. It establishes that a meaningful population of Tenda-fingerprinted assets is reachable from the internet, which is the precondition for remote exploitation of CVE-2026-104610. It also sets an expectation for the scale of any coordinated response: this is not a handful of devices.
For an operator, the productive version of the exercise is to combine the fingerprint with a scope filter. Adding a country, org or cidr term restricts the same dork to the ranges you care about, and the resulting count is an exposure number for a real estate rather than for the internet. That is the form in which the measurement supports a decision.

From exposure to remediation

The remediation path for CVE-2026-104610 does not depend on the count. Where a vulnerable HG7, HG9 or HG10 is reachable on its management interface from the WAN side, that exposure should be closed first, because the exploit is public and needs no authentication. Restricting management to an administrative VLAN and removing the WAN-side listener are controls that work whether or not Tenda has shipped a fix.
Detection is available in the interim. Requests to /boaform/formLoopBack with an unusually long Ethtype value are distinctive, and an alert on that pattern costs little to add.
The measurement closes one gap and leaves the important one open: knowing that Tenda devices are on the internet does not tell you which are the affected models. That answer comes from the carrier or from the device itself, and it is the step no external index can perform.

References

1,316,357 GitLab Matches and 456,436 Title Matches: Sizing a Self-Managed Code Host

jeffrey — Tue, 06 Oct 2026 15:40:32 +0000

1,316,357 GitLab Matches and 456,436 Title Matches: Sizing a Self-Managed Code Host

A self-managed code host is one of the few systems in an enterprise that holds both the source code and the credentials to deploy it. That combination makes its exposure profile worth understanding in detail, and it makes the choice of query unusually consequential.

The context

CVE-2026-85706 is a path traversal vulnerability in GitLab CE and EE that allows unauthenticated arbitrary file reads through the commits API, with a CVSS score of 10.0. Reporting described real exploitation to steal configuration files and SSH keys. CISA added it to KEV on 11 September 2026 with a federal remediation deadline of 14 September.

The affected versions span several release trains: before 19.1.8, before 19.2.6 and before 19.3.2. A related issue, CVE-2026-87719, is an insecure deserialization flaw that can leak search configuration and credentials.

What the queries return

Query	Matches
`app="GitLab"`	1,316,357
`title="GitLab"`	456,436

The fingerprint count is roughly three times the title count. That ratio is informative. It suggests that a substantial share of GitLab deployments do not present the product name in the page title, which is consistent with organisations applying their own branding to self-managed instances.

For exposure assessment, the fingerprint query is the appropriate baseline. The title query undercounts by a wide margin.

Why a code host is a high-value target

The reason GitLab appears repeatedly in incident reporting is not that it is unusually vulnerable. It is what it holds. A self-managed GitLab instance typically stores:

Source code for internal and customer projects.
CI/CD variables and secrets, which often include deployment credentials for production systems.
SSH private keys and deploy tokens.
Database credentials and API tokens.

A single unauthenticated file read can therefore expose material that grants access well beyond the code host itself. That is why the observed exploitation focused on configuration files and SSH keys rather than on source code.

Reading the exposure count

A figure above one million requires the same qualifications as the other products in this series, with one addition specific to GitLab:

The fingerprint covers both CE and EE. Community and Enterprise editions share the fingerprint but differ in feature set and support.
Version is not part of the query. The affected ranges are specific to several release trains, and patched instances remain fingerprinted.
Public instances are a subset. Many GitLab deployments are internal-only, reachable through a VPN or a corporate network. A fingerprinted instance is not necessarily internet-reachable for the specific API path.
Some matches are mirrors and public repositories. GitLab.com itself and public project mirrors contribute to the count.

Detection guidance from the reporting

The observed exploitation used the commits API. A specific detection approach was published: search for HTTP POST requests to paths matching the projects repository commits endpoint that include a file.path parameter. That is a narrow, actionable signature rather than a generic anomaly.

A practical method

Use the fingerprint query as the baseline. app="GitLab" is the meaningful signal.
Verify version on instances you own against the fixed releases for each affected train.
Search logs for the specific request pattern. The file.path parameter on the commits endpoint is the signature.
Rotate what a file read would expose. SSH keys, CI/CD variables, deploy tokens and database credentials.
Consider whether self-managed GitLab belongs on the public internet. For most organisations, the answer is that it does not, and the fix is a network control rather than a patch.

The general point

For a system that holds deployment credentials, the exposure count is a proxy for something else: the number of places where a single unauthenticated request could yield the keys to production. That framing is more useful than the raw number, because it points at the control that actually reduces the risk, which is removing the instance from the public internet rather than waiting for a patch window.

References

ZoomEye search results for app="GitLab" (1,316,357) and title="GitLab" (456,436), collected 23 September 2026
GitLab security advisory for CVE-2026-85706 and CVE-2026-87719
NVD entries for both CVEs
CISA Known Exploited Vulnerabilities Catalog, GitLab entry added 11 September 2026

Audiobookshelf: no app fingerprint and 13,963 title matches

jeffrey — Tue, 06 Oct 2026 13:00:31 +0000

Audiobookshelf: no app fingerprint and 13,963 title matches

A self-hosted media server usually sits on a home network, which is exactly what makes its internet-reachable instances interesting. Audiobookshelf serves audiobooks and podcasts, and the index identifies it by page title while finding nothing by application signature.

What the queries measured

Two queries were run against the ZoomEye index on 5 October 2026, scoped to all asset types.
Search query: app="Audiobookshelf". Result: 0 matching assets.
Comparison query: title="Audiobookshelf". Result: 13,963 matching assets.

Reading a one-sided result

A single figure with no fingerprint counterpart is a weaker measurement than a pair, and the weakness should be stated rather than smoothed over. The title count covers assets whose page carries the product name. It includes running instances, and it includes pages that reference the product.
The population is large enough to suggest that a meaningful share of these assets are real deployments. A media server that is reachable from the internet is usually one that was set up for personal use and published so it can be reached from outside the home.

What an instance holds

Audiobookshelf stores a library, user accounts and, in a typical configuration, the details needed to reach the storage behind it. The interface is the control surface. Authentication is the only layer between a public address and both the library and the accounts.
Two configuration patterns produce most of the exposure. A container with a published port on a host with a public address, and a reverse proxy that was added to make remote access work and was never scoped to the accounts that should have it.

What an operator can do next

Compare the count against the hosts the organisation manages. A media server is rarely in a corporate asset inventory, which is the reason to check for one rather than assume it is absent.
Where remote access is a requirement, the useful check is which accounts exist and whether any of them were created for a purpose that no longer applies. A server with one live account and five forgotten ones has five ways in.

Limitations

The figure describes indexed assets on one day and cannot separate a running server from a page that mentions one. It does not identify versions, authentication methods or owner intent. A count this size is an inventory prompt, not a finding.

References

[1] Audiobookshelf. https://www.audiobookshelf.org/
[2] Audiobookshelf source repository. https://github.com/advplyr/audiobookshelf
[3] ZoomEye. https://www.zoomeye.ai/

1538 Jenkins, 169 Harbor and 32 SonarQube Results: The Build Chain Has a Public Address

jeffrey — Tue, 06 Oct 2026 07:40:32 +0000

1538 Jenkins, 169 Harbor and 32 SonarQube Results: The Build Chain Has a Public Address

Build and release tooling holds the credentials that deploy to production. It is also frequently reachable from the internet, because it was stood up quickly for a project and never moved behind the perimeter. A ZoomEye query set collected on 22 September 2026 returned:

Query	Total results
`app:"Jenkins"`	1,538
`app:"Harbor"`	169
`app:"SonarQube"`	32
`app:"Portainer"`	943,412
`app:"Grafana"`	603,672

Portainer and Grafana are included for scale comparison. The build-chain tools are the smaller numbers, and the smaller numbers are the ones that hold deployment credentials.

Why the build chain is a high-value target

A CI server is not a normal application. It has, by design, the ability to execute code, to read source repositories, to access artefact registries, and to deploy to production environments. Compromising a CI server is not a step toward production access; it is production access.

The credential set on a CI server typically includes:

Source control tokens with write access
Registry credentials for pushing images
Cloud provider credentials for deployment
Signing keys for artefacts
Secrets injected into build jobs

Each of these is a credential that the CI server must hold to do its job. That is the reason the CI server is a target rather than an application with a bug.

Jenkins: the largest count and the broadest surface

Jenkins is the most widely deployed open-source automation server, and the indexed count of 1,538 reflects that. Jenkins is also extensible through plugins, and the plugin ecosystem is where most of its vulnerabilities have appeared.

The exposure pattern for Jenkins is usually an instance reachable on the internet with the web UI available. Depending on configuration, that may expose job names, build logs, and in some cases the script console. Build logs are an underrated disclosure: they frequently contain environment variables, tokens echoed by a build step, and internal hostnames.

The controls are network placement and authentication. Jenkins should be behind a VPN or an access proxy, and the anonymous read permission should be disabled unless there is a specific reason to allow it.

Harbor: the registry that holds your images

Harbor is a container registry. The indexed count of 169 is small, and the consequence of exposure is direct: a reachable registry with weak credentials allows an attacker to pull private images, which reveals application internals, embedded secrets and the deployment topology.

A registry also allows pushing. An attacker who can push to a registry that your cluster pulls from has a supply chain path that does not require compromising the build system at all.

The controls are authentication, project-level access control, and network placement. A registry should not be reachable from the internet, and image signing with admission enforcement converts a push into a blocked deployment.

SonarQube: the smallest count and the most sensitive content

SonarQube performs static analysis and stores the results. The indexed count of 32 is the smallest in this set, and the content is among the most sensitive: source code, findings that describe exploitable weaknesses, and in some configurations the source of every project in the organisation.

A reachable SonarQube instance with default administrative credentials is a source code disclosure. The historical pattern of default credentials on first install makes this a configuration issue rather than an exploit.

The controls are the same as for the others: network placement, changed default credentials, and authentication on the API.

Reading the scale comparison

The Portainer and Grafana counts are two orders of magnitude larger than the build-chain tools. That is not a statement that Portainer is more important. It reflects that both products are widely deployed as management or monitoring interfaces, often on internet-facing hosts, and both respond to a simple HTTP probe.

The comparison is useful for one purpose: it shows that the build-chain counts are not large because the index is small. The index covers these services. The build-chain tools are simply less often exposed, and where they are exposed, the consequences are more direct.

What to check in your own estate

Query your own netblocks for the build-chain products by name. app: queries identify the product rather than just the port.
Check anonymous access. Jenkins anonymous read and SonarQube public project visibility are the two settings that turn reachability into disclosure.
Check default credentials. Harbor and SonarQube have both had first-install defaults.
Check what the tool can reach. A CI server's outbound access to production is the blast radius.
Check build log retention. Logs that contain tokens should be treated as secrets.

Limitations

These figures are a snapshot collected on 22 September 2026. An app: query depends on the product's fingerprint being detectable, which varies with version, theme customisation and reverse proxy configuration. The counts are lower bounds for the deployed population, not complete inventories.

A reachable instance is not a compromised instance. The measurement establishes exposure; confirming the impact requires checking the specific configuration.

References

ZoomEye, cyberspace search engine. Query set: app:"Jenkins", app:"Harbor", app:"SonarQube", app:"Portainer", app:"Grafana"; collected 22 September 2026.
Jenkins, Securing Jenkins.
Harbor, Security documentation.
SonarSource, SonarQube security documentation.
NIST, SP 800-204C: Implementation of DevSecOps for a Microservices-based Application System.

Why Port 2375 Alone Overstates the Docker Problem

jeffrey — Tue, 06 Oct 2026 05:00:31 +0000

Why Port 2375 Alone Overstates the Docker Problem

The CARBONATO advisory names TCP port 2375 as the typical way into an exposed Docker host. That detail is operationally useful, and it is easy to over-read. If a team treats "port 2375 is open" as equivalent to "Docker Remote API is exposed without authentication", it will over-count its own risk and misallocate response effort.
A measurement makes the gap concrete. Querying ZoomEye for port 2375 on 30 September 2026 returned 1,437,638 assets. Querying the Docker application fingerprint on that same port returned 1,032.

port="2375"                                   -> 1,437,638
app="Docker" && port="2375"                   ->     1,032

That gap spans three orders of magnitude. It is the distance between a port number and a product identity.
The reason is straightforward. Ports are conventions. Docker's Remote API uses 2375 by default, but nothing reserves the number. Other software listens there, and a port-only query cannot separate a Docker daemon from any other service that happens to bind the same value. ZoomEye's application fingerprint adds the identification step: it classifies the service behind the port, so the result describes Docker assets rather than traffic on a number.
The next layer is subtler still. Within the Docker population, several fingerprints produce different populations:

app="Docker"                        -> 13,246
app="Docker" && service="http"      ->  9,477
http.header.server="Docker"         -> 59,902
banner="Docker"                     -> 354,334
app="Docker" && port="2375"         ->  1,032

Each line maps to a different asset relationship. app="Docker" describes assets ZoomEye identifies as Docker regardless of how they are reached. http.header.server="Docker" describes responses whose Server header names Docker, a weaker and broader signal. banner="Docker" matches banner text and pulls in the widest set. Only the last line constrains both product and the specific exposure path the advisory describes.
None of this makes a port query useless. When the incident itself is about an exposed service, a port query documents the size of the listen surface, and that is a legitimate thing to report. The number becomes misleading when it is presented as a count of vulnerable Docker hosts.
The practical rule is to label the query. "1,437,638 assets respond on port 2375" is accurate. "1,437,638 Docker hosts are exposed" is not. Run the fingerprint query alongside the port query and report both.
ZoomEye supports that comparison because it exposes product and header fields next to port fields, so the same interface can answer the narrow and broad versions of the question. The search below runs the narrow one.
ZoomEye counts describe observed exposure at the time of the query. They do not confirm that any asset accepts unauthenticated API calls, and they do not confirm compromise.

References

CSA / SingCERT, "Advisory on CARBONATO Botnet Campaign Targeting Exposed Docker Daemons", 30 September 2026: https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-012
Docker, "Protect the Docker daemon socket": https://docs.docker.com/engine/security/protect-access/
ZoomEye queries executed 2026-09-30 between 17:16:57Z and 17:18:17Z, sub_type=all; counts as listed above.

29,151,855 Matches on Port 5060: The Signalling Layer Nobody Maps

jeffrey — Tue, 06 Oct 2026 04:00:30 +0000

29,151,855 Matches on Port 5060: The Signalling Layer Nobody Maps

Session Initiation Protocol is how voice and video calls are set up, and port 5060 is where that signalling lives. A ZoomEye query for port="5060" returned 29,151,855 matches, and at that size the question worth asking is what the number actually contains.

The measurement

The query port="5060" was executed on 25 September 2026 with sub_type=all and pagesize 1. The result was 29,151,855 total matches. As before, the number is a match total rather than a sample of live call servers.

Why a large number here means something specific

Port assignment is not random. 5060 is defined for SIP, and it is overwhelmingly used for SIP and for services that look like SIP to a scanner. When a port-mapped query returns tens of millions of matches, the honest interpretation is that a very large amount of internet-facing infrastructure answers on a port that the voice industry reserved for call setup.
That matters, because SIP sits in an unusual trust position. It is the control plane for real-time communications, it is frequently deployed by teams outside the security function, and it is exposed outbound as well as inbound because remote workers and carriers need to reach it.

The parsing surface, not the port

A raw port match is the weakest kind of external evidence. It does not distinguish a SIP registrar from a random service that happens to bind 5060, and it does not tell you which vendor implementation is behind the port.
The better version of the question is what a specific vendor's voice platform looks like from outside, because then the answer describes a product population. A product fingerprint query, confirmed against a small probe before being trusted, gives a population whose patch status you can reason about. A port query gives a population whose patch status you cannot reason about.

What to do with 29 million

Treat the number as a signal about the industry rather than about your estate. Then reduce it to your own context.
Inventory the voice infrastructure that is externally reachable, and separate what must be published from what was published for a project that ended. Session border controllers, conference bridges, and unified communications edge roles are the components that legitimately need external presence; softphone provisioning servers usually do not.
Apply transport security where the platform supports it, and require TLS on the signalling path rather than leaving cleartext SIP on 5060. Then filter at the border: carriers and remote endpoints can be restricted to known networks far more often than teams assume.

References

ZoomEye search for port="5060": https://www.zoomeye.ai/
RFC 3261, SIP: https://www.rfc-editor.org/rfc/rfc3261

Citrix NetScaler CVE-2026-88771 and CVE-2026-88772: two edge RCE flaws attacked before a fix existed

jeffrey — Tue, 06 Oct 2026 02:40:37 +0000

Citrix NetScaler CVE-2026-88771 and CVE-2026-88772: two edge RCE flaws attacked before a fix existed

Citrix published fixes for two NetScaler flaws on 2026-09-27 after watchTowr reported unpatched remote code execution bugs under active exploitation. Both flaws are rated 9.5 under CVSS v4.

The two vulnerabilities

CVE-2026-88771 is improper input validation that lets an unauthenticated attacker run arbitrary commands. Citrix states that it affects all NetScaler ADC and NetScaler Gateway deployments on the affected versions, with no additional feature required.
CVE-2026-88772 is a memory overflow that can lead to remote code execution or denial of service. It affects appliances with DTLS enabled. DTLS is on by default for VPN virtual servers, so a NetScaler Gateway is affected unless DTLS was explicitly turned off.

Timeline

watchTowr said on 2026-09-26 that it was responding to reports of unpatched NetScaler RCE issues and called the information credible. It later said the two flaws were found during forensic investigations. Citrix did not state whether its two flaws are the ones watchTowr described, but they match that account. Administrators on r/Citrix reported being told to shut down NetScalers immediately.
Citrix said exploits of CVE-2026-88771 and CVE-2026-88772 on unmitigated deployments had been observed. It did not say how widely the flaws were exploited, by whom, or since when. Both flaws were therefore used before any public fix existed.

Affected versions and fixes

Appliances on 14.1-73.32 and 13.1-63.21, the builds that fixed the August authentication bypass CVE-2026-19490, are inside the affected range and need the new update. Fixed releases are:

NetScaler ADC and NetScaler Gateway 14.1-73.37 and later
NetScaler ADC and NetScaler Gateway 13.1-64.23 and later 13.1 releases
NetScaler ADC 14.1-FIPS 14.1-73.37 and later 14.1-FIPS releases
NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.279 and later releases The 13.1 fix arrived after that branch reached End of Maintenance on 2026-09-15.

What a defender should do

NetScaler ADC and Gateway sit at the edge, handling VPN, remote access, load balancing, and authentication. The bulletin lists no workaround and no indicators of compromise for the two exploited flaws. Because exploitation preceded disclosure, patching restores safety but does not show whether an attacker already established access. Teams should preserve authentication and VPN logs before applying changes, then hunt for anomalous command execution and outbound connections.

Exposure context

ZoomEye returned 239,277 matches for app="Citrix NetScaler" on 2026-09-30 (UTC). The figure counts assets that match the fingerprint, not confirmed vulnerable appliances, and the affected configuration still has to be verified per device.

References

Citrix NetScaler security bulletin covering the September 2026 releases.
watchTowr reports on unpatched NetScaler RCE activity.
The Hacker News coverage of the confirmed exploitation.

603,475 Grafana and 77,968 Kibana Instances: Measuring the Observability Layer's Public Surface

jeffrey — Mon, 05 Oct 2026 15:20:29 +0000

603,475 Grafana and 77,968 Kibana Instances: Measuring the Observability Layer's Public Surface

Observability platforms sit in an unusual position. They are not production services, but they hold the credentials, query results and topology data that describe production. Grafana, Kibana and Prometheus are common in that role, and all three can be reached from the public internet.

ZoomEye data collected on 20 September 2026 shows how much of that layer is visible.

Query	Exact count
`app:"Grafana"`	603,475
`app:"Kibana"`	77,968
`app:"Prometheus"`	248
`app:"Zabbix"`	150
`app:"RabbitMQ"`	227
`app:"Kafka"`	165
`app:"OpenSearch"`	571

Why the two large numbers need a caveat

The Grafana and Kibana counts are large enough that they should be read as fingerprint match counts rather than counts of live, reachable dashboards. Grafana and Kibana are both widely embedded and widely referenced, and a fingerprint can match assets, headers or pages associated with the product beyond a running instance.

That does not make the numbers useless. It makes them a starting point for a narrower query. Combining the application filter with a network filter, or with a port filter, produces a result set that can be attributed to a specific environment. The global count establishes that the product surface is large; the scoped query establishes whether any of it is yours.

What the smaller counts describe

Prometheus, Zabbix, RabbitMQ, Kafka and OpenSearch return counts in the hundreds, which makes them easier to reason about.

Prometheus is a metrics store and query engine. An exposed Prometheus endpoint often has no authentication by default, which makes it a direct information disclosure path. The count of 248 reachable services is small enough for an operator to check against their own inventory.

Zabbix is a monitoring platform with a web interface and an agent protocol. An exposed Zabbix frontend is an authentication surface, and the count of 150 describes how many answer publicly.

RabbitMQ and Kafka are messaging systems. Their counts of 227 and 165 describe brokers that answer from a public address. A message broker carries the data that applications exchange, and access to it is often equivalent to access to those applications.

OpenSearch is a search and analytics engine derived from Elasticsearch. The count of 571 describes reachable services, and an exposed search engine is a data exposure path in the same way a database is.

Why observability is a credential problem

A dashboard is only as sensitive as the data sources behind it. Grafana and Kibana connect to databases, log stores and metrics systems using stored credentials. An attacker who reaches a dashboard with weak or default authentication inherits those connections.

Metrics and logs also describe the environment. A Prometheus instance reveals service names, host names, versions and request patterns. A log store reveals error messages that frequently contain tokens, internal URLs and stack traces. This is reconnaissance that does not require exploiting a vulnerability.

Messaging systems sit between the observability layer and production. A broker that is reachable and unauthenticated gives an attacker the ability to read or inject messages, which is a path to the applications on both ends.

What to do with the measurement

Scope the queries to your own address space and treat the result as an inventory task. For each match, decide whether the service should be reachable from outside the expected network. Dashboards, metrics endpoints and message brokers generally should not be.

Where a service must be reachable, check the authentication configuration. Prometheus and several metrics exporters ship without authentication by default, so the presence of a login page is not a safe assumption. Put the service behind a reverse proxy that enforces authentication, or restrict access by network policy.

Rotate the credentials the dashboard holds. If a dashboard was reachable, the data source credentials it stored should be treated as exposed.

Re-run the queries after remediation to confirm the change. A service that stops appearing in a scoped result is a verified improvement.

Limitations

These counts describe fingerprint matches, not confirmed vulnerable or unauthenticated instances. The Grafana and Kibana figures in particular should be treated as match counts. Version detection and direct inspection are required before any host is classified as misconfigured. All figures are a snapshot from 20 September 2026.

References

ZoomEye queries app:"Grafana" (603,475), app:"Kibana" (77,968), app:"OpenSearch" (571), app:"Prometheus" (248), app:"RabbitMQ" (227), app:"Kafka" (165) and app:"Zabbix" (150), collected 20 September 2026.
Grafana, Kibana, Prometheus, Zabbix, RabbitMQ, Kafka and OpenSearch product documentation for service roles and default authentication behaviour.

CVE-2026-70585: A Use-After-Free in the Windows NFS Client Stack

jeffrey — Mon, 05 Oct 2026 12:40:29 +0000

CVE-2026-70585: A Use-After-Free in the Windows NFS Client Stack

Windows can mount NFS shares as a client, and that capability pulls a remote procedure call parser into the kernel's network path. CVE-2026-70585 is a use-after-free in that parser, and it is a good example of a low CVSS score attached to a high-consequence code path.

What the record says

NVD describes CVE-2026-70585 as a use-after-free in Windows Services for NFS ONCRPC XDR Driver allowing an authorized attacker to execute code locally. The weakness is CWE-416 and the CVSS base score is 7.0. It was published on 8 September 2026.

Why the score and the description diverge from intuition

The word "locally" in the description does not mean the attacker is sitting at the console. It means the code path is reachable from the local system's network stack after a share is mounted, which in practice means an attacker who controls the NFS server can influence what the client parses.
That scenario is the one worth taking seriously. The NFS server that a Windows host mounts might be an internal file server, a NAS appliance, a lab system, or a partner's storage. Any of those can be compromised, misconfigured, or simply hostile. When the client's XDR parser mishandles a response, the client's kernel is the thing that fails.

The parsing problem, stated plainly

External Data Representation is a serialization format, and a decoder for it must make length and type decisions on the basis of bytes that came over the wire. A use-after-free in that decoder means the code touched a data structure after something else had already released it, the conventional recipe for attacker-influenced memory reuse.
The reason this sits at 7.0 rather than higher is the metrics: the attacker needs a position that lets them answer as the NFS server, and the outcome is described as local code execution. Both of those constraints are real. Neither of them makes the bug harmless in an environment where NFS mounts are common and the storage tier is not treated as a trust boundary.

Handling

Apply the September 2026 updates to any Windows host with the NFS client feature installed. Check first: the feature is often a leftover from a migration project rather than a deliberate design decision, and removing the client from hosts that do not need it eliminates the surface.
Where NFS mounts are required, pin them to specific servers rather than accepting mounts from arbitrary addresses, and treat the storage network as a security zone with its own access control. A file server that answers NFS requests to a broad address range is a server that can decide what a Windows kernel parses.
Finally, consider whether the Windows-to-NFS path needs to exist at all. SMB is the native protocol for Windows clients, and every protocol removed from the client stack is a parser that can no longer be attacked.

References

NVD record for CVE-2026-70585: https://nvd.nist.gov/vuln/detail/CVE-2026-70585
Microsoft update guide entry: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70585
Microsoft September 2026 release notes: https://msrc.microsoft.com/update-guide/releaseNote/2026-Sep