Two Flaws in Japan's NetKids iMark Network Monitor, and No Fixed Version Exists

Two vulnerabilities have been disclosed in NetKids iMark, a Japanese-made network monitoring tool. Published on August 5, 2026 through Japan's national vulnerability portal JVN (JVN#28045338), both let someone who can log in to the machine seize SYSTEM — the highest privilege level in Windows.

The conclusion first. Neither can be attacked over the internet. Nobody is walking in from outside, so this is not a case for stopping services tonight.

There is one awkward part, though. The affected range is "V5.2.5.0 and earlier" — which means the current shipping release is itself affected, and there is nothing to upgrade to. The developer, IST Inc., says a fix is in preparation, but it has not shipped. All that is available right now is the guidance in two documents the company published. This article works through what those documents actually ask you to do.

What NetKids iMark is, and where it runs

It is software that periodically checks whether the network gear and servers inside an organization are still healthy. It pings devices to see if they answer, watches CPU and disk headroom, confirms that web pages still load, and alerts staff when something looks wrong.

Its selling point is how little it asks for: install it on a Windows PC or server and it runs. No appliance, no Linux knowledge. The developer says that since its 1998 release it has accumulated more than 4,000 licenses over 20-plus years, with deployments in government agencies, financial institutions and educational organizations. Being domestically built, with Japanese-language support, is part of why it has stayed in use.

So this is the kind of story that is irrelevant if you have never heard of the product, and unambiguously yours if your organization runs it. If that rings a bell, read on.

Both flaws come down to substitution

The route is the same in both cases. An attacker places a file where the legitimate program expects to find one. The software loads it without question, and the planted code starts running at the highest privilege level.

* Severity on the left uses the newer CVSS v4.0 scale, on the right the older v3.0. The same flaw scores differently depending on the scale. Both carry AV:L — the notation for "only exploitable on the machine itself, not across the network."

CVE-2026-66344: a sloppy search for component files

Windows programs do not do everything themselves; they load shared component files called DLLs as needed. The order in which they look for those files matters. If a program checks its own folder first, then the moment someone drops a fake file with the right name into that folder, the game is over.

The developer's document states it plainly: the application searches the directory it sits in, and if a malicious DLL of the same name is placed there, unintended code may run. The classification is CWE-427 (uncontrolled search path element), a pattern long familiar in Windows software.

The real question is who can write into that folder. As the developer acknowledges, the install directory inherits its permissions from its parent, so depending on the environment ordinary users may well be able to drop files there. If that door is open, planting a fake component is not hard.

CVE-2026-66839: a sloppy service registration

This one is about how a background program — a Windows service — is registered. The service in question is nkmsgService, which handles notifications.

Windows records the location of a service's executable as a string. If that string is not wrapped in quotes, a space inside it can be read as a separator. For a path like C:\Program Files\Netkids\..., Windows may take "C:\Program" as the executable name. Plant a fake C:\Program.exe and it runs on the next start.

The classification is CWE-428 (unquoted search path or element), another recurring Windows pattern, and one that stems not from the program's logic but from how the installer wrote the registration. The developer's second document says the next release will register the path with quotes.

Who would go after this, and why

Neither flaw can be reached from outside, so the people who can use them are already inside the organization: a user with a restricted account, a contractor with temporary access to a machine, or an attacker who has already taken over one employee's PC through phishing. This is not a way in. It is the second move, made after getting in, to climb higher.

And what they do is small. Drop one file, then wait for the monitoring software to load it. Nothing dramatic. The instant it loads, the attacker's code is running as SYSTEM, and on that machine there is nothing left to stop them.

How much that costs you depends on what the monitoring software holds. A network monitor keeps an inventory of every device in the organization and the addresses they answer on. It often stores the shared secrets used to poll those devices (SNMP community strings) and credentials for management interfaces. The monitoring server is, in effect, both the map of the internal network and the key ring. Lose it and the attacker no longer has to work out where to go next. That is the single reason "not reachable over the network" does not make this harmless.

Are you affected?

The test is simple. If you run NetKids iMark V5, you are affected. JVN lists the range as "V5.2.5.0 and earlier," and the developer's release history shows V5.2.5.0 shipped on January 14, 2025 and is still the newest build. "And earlier" therefore covers everything, and there is no newer release to escape to.

Two things are worth checking first.

There is one more check people forget: installations nobody uses anymore. The machine where it was installed for a trial and left, the server whose owner changed and which nobody watches. In both documents the developer asks that, if you have stopped using the product, you uninstall it and delete the install folder by hand. An idle installation still carries the flaw as long as the folder and the service registration remain.

What to do now

There are two measures to take until a fix ships. Both are configuration changes; neither replaces any software. Here is what the developer's documents amount to.

Measure 1: tighten permissions on the install folder

This addresses the DLL issue (CVE-2026-66344). The goal is to leave nobody able to plant a file. Right-click the install folder, open Properties, and look at the Security tab. The example the developer gives is removing the "Authenticated Users" group — a group meaning "everyone who can log in." If it has write access, any ordinary user can drop a file there.

This is where most people get stuck: trying to remove it produces an error about inheriting permissions from the parent. Folder permissions cascade down, so the entry cannot be removed in place. Cancel out, open Advanced, click Disable inheritance, and choose "Convert inherited permissions into explicit permissions on this object." When every entry in the "Inherited from" column reads "None," it worked, and the removal will go through.

One caution: do not strip the read and execute rights the product needs to run. The developer says to keep those as your operations require. What you are removing is write, modify and delete — not the ability to read and run.

Measure 2: put quotes around the service registration

This addresses the service issue (CVE-2026-66839). The order of shutdown matters. The notification console (nkmsgClient.exe) blocks the service from stopping, so close it first via File → Exit Application in its menu. If you do not want monitoring to pause, you can leave iMarkGUI and nkimarkService_V5 running. Be aware, though, that no notifications go out while you work, so anything that breaks in that window will go unannounced.

Once stopped, wrap the registered path in quotes. The developer offers two routes: edit ImagePath under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\nkmsgService in the registry editor, or open an administrator command prompt and reset it with sc config. If editing the registry makes you nervous, the second route is harder to get wrong.

Afterwards, open the properties for nkmsgService in the Windows services console and confirm with your own eyes that the path is quoted. Then restart what you stopped and, finally, test that notifications actually fire. You changed settings; the job is not done until you have proven things still work.

Is anyone exploiting this?

There are no reports of exploitation. Neither the developer's documents nor the JVN entry mentions any incident or observed attack. Neither flaw appears in the U.S. CISA catalog of vulnerabilities known to be exploited (KEV).

No proof-of-concept code has been published either. That matters less than usual here, because neither technique is novel. Plant a fake DLL; plant a fake executable. The method is common knowledge, and the only variable is whether there is somewhere to plant it. Which is exactly why the remedy reduces to closing that spot.

Note also that although these carry the IDs CVE-2026-66344 and CVE-2026-66839, as of August 5 neither is yet listed in the U.S. National Vulnerability Database. IDs assigned in Japan take time to propagate to international databases. If your internal scanner does not flag them, that may only mean they have not been registered yet — do not treat a search on the ID as proof that you are unaffected.

The finder is Kazuma Matsumoto of GMO Cybersecurity by Ierae. The report went to the developer and was published through JVN via IPA's reporting scheme, following Japan's coordination process. That the developer had two guidance documents ready on the same day is what that coordination working looks like.

One loose end

Of the two documents the developer published, the one covering the service issue closes with "JVN reference: JVN#12859106." As of this writing, that page cannot be found — the URL returns a 404. The other document points to JVN#28045338, and that page carries both CVE IDs.

A plan to publish the two separately that ended up merged into one would explain it, but we have not confirmed that, so we are not asserting it. In practice nothing is lost: JVN#28045338 covers both. We mention it only in case someone looks up the number printed in the document and is puzzled to find nothing there.

Summary

Two vulnerabilities in the Japanese network monitoring tool NetKids iMark were disclosed on August 5, 2026. In both, someone who can log in to the machine plants a file and takes the highest privilege level in Windows; neither works over the internet. The affected range is V5.2.5.0 and earlier — which includes the current shipping build, and no fixed version exists yet. The developer says the next minor release will address them.

Until then there are two measures: tighten permissions on the install folder, and put quotes around the service registration. Both are settings work, not upgrades. If you have an installation you no longer use, uninstalling it and deleting the folder is the cleanest answer.

One closing thought. These two belong to a family that keeps turning up in Windows business software, domestic and foreign alike. Look around and you will find other services registered without quotes, other install folders anyone can write to. While you are in there, it is worth casting the same eye over your other background services. Vulnerabilities in software built for the Japanese market tend to wait a long time for any English or even Japanese write-up — a posting tool used on personal sites showed the same gap. Whether you can act on the day of disclosure comes down to how quickly this kind of information reaches you.

Sources

• ▸ JVN#28045338 - Multiple vulnerabilities in NetKids iMark (published August 5, 2026)
• ▸ IST Inc. - Guidance on DLL loading and install-folder permissions (PDF, Japanese)
• ▸ IST Inc. - Guidance on the unquoted service executable path (PDF, Japanese)
• ▸ IST Inc. - NetKids iMark product page (over 4,000 licenses)
• ▸ IST Inc. - NetKids iMark release history (latest V5.2.5.0, January 14, 2025)
• ▸ MITRE - CWE-427: Uncontrolled Search Path Element
• ▸ MITRE - CWE-428: Unquoted Search Path or Element
• ▸ IPA - Vulnerability reporting scheme (Japan)