VulnCheck added this to its KEV catalog on 2026-09-03 and BleepingComputer reported in-the-wild attacks on 2026-09-04, so teams still running an affected 14.1 or 13.1 build on an internet-facing Gateway or ADC risk unauthenticated compromise of the appliance.
An authentication bypass in NetScaler ADC and NetScaler Gateway lets an unauthenticated remote attacker reach protected functionality over the network with no user interaction (CVSS 4.0 9.3, AV:N/PR:N/UI:N). Citrix tracks the fix in advisory CTX696939; the Canadian Centre for Cyber Security issued alert AL26-019 covering it alongside CVE-2026-19489.
Affected: NetScaler ADC 14.1 builds up to and including 14.1-73.32; NetScaler ADC 13.1 builds up to and including 13.1-63.21; NetScaler Gateway 14.1 builds up to and including 14.1-73.32; NetScaler Gateway 13.1 builds up to and including 13.1-63.21
How to Test
Record the running build of every NetScaler ADC and Gateway instance and compare it against the affected ranges (14.1 through 73.32, 13.1 through 63.21); any appliance in range that is reachable from the internet should be treated as exposed. Review Gateway and authentication logs and active session tables for sessions established without a corresponding successful login, and follow the detection guidance in alert AL26-019.
How to Patch
Upgrade 14.1 appliances to a build later than 14.1-73.32 and 13.1 appliances to a build later than 13.1-63.21 as published in Citrix advisory CTX696939, upgrading HA pairs and cluster nodes together. Until upgraded, restrict internet access to the Gateway and management interfaces where operationally possible, and terminate existing sessions after patching so any session created via the bypass is invalidated.
VulnCheck added this CVE to its known-exploited catalog on 2026-09-04 with public exploit code already available, and anyone still running an M300 with its web backend reachable by untrusted clients is handing out a root shell on the device.
The smacfilter_conf handler in the M300 (hardware model MT02) commuos web backend passes the name, enable, and mac GET parameters unsanitized through sprintf() into uci shell commands run by doSystemCmdComlib(), so anyone who can reach the device's web interface can run arbitrary commands as root. No firmware fix or vendor advisory exists.
Affected: Shenzhen Aitemi M300 Wi-Fi Repeater (hardware model MT02), all known firmware
How to Test
Identify any M300 repeaters (hardware model MT02) on your network. Review the device's web backend for requests to the smacfilter_conf handler whose name, enable, or mac parameters contain semicolons or other shell metacharacters; the public repository at github.com/IEATASICS/m300-repeater-bugs describes the request pattern. Treat unexpected configuration changes, new processes, or altered uci settings as signs of compromise.
How to Mitigate
No vendor fix or advisory is available and affected firmware versions are not enumerated. Move the repeater onto an isolated network segment, ensure its web management interface is not reachable from untrusted Wi-Fi clients or the internet, and plan to replace the device. If compromise is suspected, factory reset it and reconfigure with new credentials.
VulnCheck added this flaw to its known-exploited catalog on 2026-09-03, two days after fixes shipped, and The Hacker News reports it chains with CVE-2026-63219 into unauthenticated remote code execution, so unpatched public geoportal backends are exposed to takeover of the GeoNetwork host.
GeoNetwork configures its Saxon XSLT processor without FEATURE_SECURE_PROCESSING and without disabling ALLOW_EXTERNAL_FUNCTIONS, so any stylesheet it loads can call java.lang.Runtime.exec() or ProcessBuilder and run arbitrary commands as the GeoNetwork process user. On its own this needs a user privileged enough to upload a formatter, but chained with CVE-2026-63219 it becomes unauthenticated remote code execution.
Affected: geonetwork core-geonetwork >= 4.3.0, < 4.4.12; geonetwork core-geonetwork < 4.2.17
How to Test
Confirm the installed GeoNetwork version; anything below 4.4.12 on the 4.3/4.4 line or below 4.2.17 on the 4.2 line is vulnerable. Review the formatter directory and admin audit trail for recently uploaded or modified .xsl files you did not create, and check the host for unexpected child processes or shells spawned under the GeoNetwork service account.
How to Patch
Upgrade to GeoNetwork 4.4.12 or 4.2.17 (see the 4.4.12 and 4.2.17 change logs and GitHub advisories GHSA-x898-729x-cc3r and GHSA-mh22-prqr-vf42), which enable secure processing and disable Java extension functions in the Saxon XSLT processor. If you cannot upgrade immediately, restrict formatter upload to trusted administrators, remove untrusted custom formatters, and limit internet exposure of the catalog until patched.
Google shipped Chrome 152.0.7977.82 on September 3 for a V8 type confusion bug it says is exploited in the wild, and CISA added it to KEV on September 4; unpatched browsers can be compromised by simply visiting a crafted page.
A type confusion flaw in V8, Chromium's JavaScript and WebAssembly engine, lets a remote attacker execute arbitrary code inside the renderer sandbox when a user visits a crafted HTML page. It affects Google Chrome before 152.0.7977.82 and other Chromium-based browsers such as Microsoft Edge and Opera.
Affected: Google Chrome < 152.0.7977.82; Chromium-based browsers (Microsoft Edge, Opera and others) built on the affected V8
How to Test
Confirm the installed Chrome build is 152.0.7977.82 or later via the browser's About page or your endpoint management inventory; for managed fleets, report on any endpoints still on Chrome 151 or earlier 152 builds, and check that Edge, Opera and other Chromium-based browsers have received a build incorporating the V8 fix.
How to Patch
Update Google Chrome to 152.0.7977.82 or later and relaunch the browser so the new version takes effect; for managed fleets, force the stable-channel update and require relaunch. Update Microsoft Edge, Opera and other Chromium-based browsers as soon as their vendors publish releases containing the V8 fix.