DEV Community: facilishz

What CVE-2026-95675 Teaches About End-of-Life Wireless Hardware

facilishz — Thu, 15 Oct 2026 03:41:05 +0000

What CVE-2026-95675 Teaches About End-of-Life Wireless Hardware

Setting

CVE-2026-95675 is a critical, unauthenticated command injection in the D-Link DAP-1360, a wireless access point and range extender that the vendor retired in August 2020. The flaw grants root-level command execution through the web management interface. There is no fix and none will be produced.

The technical detail

The web server binary behind apply.cgi handles network diagnostics by reading the ipv4 ping parameter and formatting it into a system ping command. The composed string reaches the command interpreter without sanitisation. Shell metacharacters in the parameter therefore become commands, executed as root, with no authentication required. Firmware 6.14 and earlier is affected across all hardware revisions.

Why wireless hardware ages badly

Wireless access points and range extenders are often the last devices to be refreshed. They are cheap, they are physically distributed, and they keep working long after they leave support. That makes them ideal long-term residents of a network and poor candidates for the kind of continuous patching that servers receive. By the time a critical flaw appears, the installed base is undocumented and the vendor has moved on.

Exposure

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.

Practical lessons

Track end-of-life dates as part of procurement, not as an afterthought. Maintain inventory coverage for small network hardware, because the DAP-1360 lesson is that these devices accumulate invisibly. Assume that retired hardware will eventually receive a public exploit, and plan replacement on that basis rather than waiting for a trigger.

Immediate actions

Replace affected units. In the interim, isolate their management interfaces and rotate any credentials stored on them.

References

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

P4 Search shipped a default service token: inside CVE-2026-100103

facilishz — Thu, 15 Oct 2026 01:00:43 +0000

P4 Search shipped a default service token: inside CVE-2026-100103

Summary

Perforce published P4 Search 2026.4.2 on 5 October 2026, closing six security defects in the search service that runs in front of Perforce P4, the source control platform formerly known as Helix Core. The release carries three critical ratings, one high and two medium. The top score belongs to CVE-2026-100103, rated 10.0 under CVSS 4.0, and it exists because the official container images reset the service authentication token to a publicly documented default value. Perforce reports no exploitation in the wild and no public proof of concept.

What the defect is

P4 Search guards privileged calls with a service authentication token. In the affected container images, startup overwrites that token with a fixed default that also appears in public material. Anyone who can reach the service on the network can offer a credential they already possess and receive the highest application privilege the service exposes. There is no parsing bug, no memory corruption and no race to win. The control simply begins in the wrong state.

Why a default credential is not a minor oversight

Exploitation normally requires an attacker to find a weakness and then build a reliable way to reach it. A published default token removes that work. The remaining requirement is network reachability, which is common for an internal search endpoint that developers query from workstations and build agents. That combination explains the 10.0 score: the confidentiality, integrity and availability consequences are complete, and the attack needs no specialised skill.

The rest of the release

The patch set is broader than one flaw. CVE-2026-100102, rated 9.5, exposes an unauthenticated Java Debug Wire Protocol interface in the same images, and reaching it allows execution of arbitrary code as the P4 Search service account. CVE-2026-103510, again 9.5, is a fail-open condition in which a blank service token grants full privileges to unauthenticated callers. CVE-2026-103507, at 7.5, lets a token holder write arbitrary files through the logging configuration path, which can be turned into code execution. CVE-2026-103511, at 5.1, allows file writes through the extension installer, and CVE-2026-103512, at 5.3, lets a stolen P4 Server ticket bypass host-based restrictions by spoofing a client address.

Affected versions and scope

All six defects affect P4 Search 2026.4.1 and earlier. The two most severe issues apply to the official container images, which is where the default token and the debug interface come from. The file-write and ticket-binding flaws apply more widely, including to deployments that already use a non-default token.

Exposure measured with ZoomEye

On 6 October 2026 a ZoomEye query for the Perforce application fingerprint returned 139 matching assets, and a title-based query returned 263. These numbers describe systems that identify themselves as Perforce infrastructure. They are not confirmed P4 Search installations and not confirmed vulnerable hosts, so they act as a scale indicator rather than an infection count.

Remediation

Upgrade P4 Search to 2026.4.2 and rebuild container deployments from the patched image instead of patching in place. Replace the service token with a strong, unique value and rotate it after the upgrade. Keep P4 Search off the public internet, block the debug port at the container and host firewall, and review P4 Server tickets for signs of misuse. Teams that must keep an older build online in the short term should treat the search service as untrusted and isolate it from the P4 Server network path.

References

SecurityOnline report on the six P4 Search vulnerabilities (collected source).
ZoomEye search for app="Perforce" and title="Perforce", recorded 6 October 2026.

Scoping Estonia’s Public-Sector Attack Surface After September’s DDoS Wave

facilishz — Thu, 15 Oct 2026 00:20:43 +0000

Scoping Estonia’s Public-Sector Attack Surface After September’s DDoS Wave

In September 2026, Estonia’s state information system authority, the Riigi Infosüsteemi Amet (RIA), recorded 964 cyber incidents with an impact. Among them were distributed denial-of-service attacks against the websites of banking, healthcare, energy, transport and water organisations, government agencies and political parties. A separate burst hit the national authentication service with more than 86 million requests, over a hundred times the normal load.

That summary is short. The work it implies is not. When availability incidents arrive in clusters, the first useful question is not who did it but what is actually reachable from outside. An incident report tells you what was attacked. It rarely tells you how much of your organisation was visible in the first place.

The problem with incident-led inventory

Most teams learn the shape of their external estate during the incident. A service goes down, engineers trace it, and someone discovers that a forgotten hostname still resolves, that a test instance shares a production certificate, or that a partner portal sits on infrastructure nobody has reviewed in two years.

September’s Estonian incidents fit that pattern. The reported targets span sectors that share very little infrastructure but a great deal of public exposure. Websites for health, energy and transport organisations are not one system. They are many, operated by different bodies, with different maintenance cycles and different tolerances for downtime.

Scoping that estate is a measurement problem before it is a defence problem. You cannot prioritise what you have not enumerated.

What an external measurement shows

A cyberspace search engine such as ZoomEye indexes internet-visible assets: hosts, services, certificates, banners and page titles. Querying by country and industry gives a rough, reproducible picture of how much public-sector infrastructure is externally observable.

For Estonia, a query for government-industry assets returns 263 matching observations.

country="EE" && industry="government"
Exposure: 263 matching assets (ZoomEye, 2026-10-14 UTC, sub_type=all)

That figure is a count of indexed matches, not a list of victims. It says nothing about whether any of those assets was attacked, vulnerable or misconfigured. What it does say is that the country’s government-sector footprint is large enough to be enumerated externally, and small enough to be reviewed deliberately.

Broadening the lens makes the scale clearer. Estonian domain assets serving HTTPS return 21,335 observations. Assets answering on port 443, including hosts without a matching domain record, return 135,740.

country="EE" && service="https" && is_domain=true
Exposure: 21,335 domain assets

country="EE" && port="443"
Exposure: 135,740 assets

The gap between those two numbers is itself informative. A large share of externally visible Estonian TLS endpoints are not tied to a discoverable domain. Those are the assets that tend to be missing from internal inventories, because inventories are usually built from domain and certificate records.

Turning a count into a worklist

A count is only the first step. The useful output of an external measurement is a comparison: what is visible outside against what is known inside.

For a public-sector organisation, that comparison usually surfaces three categories of asset. The first is expected and documented — the services the organisation knows about and maintains. The second is expected but undocumented — systems that exist in spreadsheets rather than in configuration management. The third is unexpected, and this is where measurement earns its place: hosts that resolve, respond, and have no owner.

The third category deserves priority, not because it is necessarily vulnerable, but because it cannot be defended by process. No patch cycle covers a host nobody knows exists.

Practical scoping steps

A defensible external scoping exercise for a public-sector body looks roughly like this.

Fix the scope. Choose the country, industry, organisation or ASN boundaries you can justify, and record them. A query without a recorded scope cannot be repeated or audited.
Capture the baseline once. Record the query, the date and the count. The value of a baseline comes from comparison, not from the first reading.
Attribute every match. For each externally visible asset, identify an internal owner. Unattributed assets move to the top of the worklist.
Separate exposure from vulnerability. An observable host is not a compromised host. Keep the two questions distinct or the worklist becomes unusable.
Re-measure on a schedule. Monthly comparison catches new hosts faster than annual audits.

Reading the September numbers honestly

The temptation after a DDoS wave is to treat every number as evidence of weakness. The 86 million requests against the national authentication service is a measure of attack volume, not of defensive failure; RIA reported that the service continued to function with short delays. The 263 government-industry matches are a measure of visibility, not of exposure to that specific attack.

What the numbers do support is a narrower and more useful claim. Estonia maintains a substantial, externally observable public-sector attack surface, and the September incidents show that parts of it are attractive targets. That combination is enough to justify routine external measurement as part of operational hygiene, without overstating what any single figure proves.

Where ZoomEye fits

ZoomEye is built for this kind of enumeration. It indexes asset attributes that matter for scoping — country, industry, service, port, certificate content and page titles — and it returns counts that can be compared over time.

For an organisation that has just been through an availability incident, that capability translates into a concrete question: which of the assets visible today were visible last month, and which of them have an owner?

Answering that is not a substitute for incident response. It is the groundwork that makes the next response faster.

References

Riigi Infosüsteemi Amet, “September küberruumis: andmelekked ja häired riigi e-teenustes”, https://ria.ee/uudised/september-kuberruumis-andmelekked-ja-haired-riigi-e-teenustes
ZoomEye, https://www.zoomeye.ai/

ZoomEye Query Notes

All counts were collected on 2026-10-14 UTC with sub_type=all. Queries and results:

Query	Matching assets
`country="EE" && industry="government"`	263
`country="EE" && service="https" && is_domain=true`	21,335
`country="EE" && port="443"`	135,740

Matches are internet-visible observations at query time. They are not confirmed vulnerable, exploited or compromised systems, and the counts are not additive.

Why I Dig Into Cybersecurity and Hands-On Tech

facilishz — Wed, 14 Oct 2026 07:32:36 +0000

This is my first entry. I’ve long been drawn to IT and cybersecurity, spending much of my free time tinkering with networks and systems. I don’t just study theory; I like to set up test environments, trace traffic, and see how different components interact under the hood. Every small experiment teaches me something new about how digital systems operate.

I plan to use this space to document my hands-on work. Expect technical notes, troubleshooting stories, and observations from my lab setups. Some projects will succeed, others will break entirely — and those failures are often the most valuable lessons.

My goal is simple: keep learning, keep experimenting, and share what I find along the way.