Critical IxChariot RCE: CVE-2026-49435

Keysight published a security advisory on 21 July 2026 for one critical and two high-severity vulnerabilities in the IxChariot product codebase. The most urgent issue, CVE-2026-49435, also affects Hawkeye and several Keysight network-probe products. The vendor says the issues may allow arbitrary code execution without user interaction or privileges and could result in full compromise of the target system.

Keysight says it is not currently aware of malicious exploitation. That sentence matters: the advisory supports an expedited update, but not a claim that this is an exploited zero-day. ANSSI disclosed the issues to Keysight on behalf of researcher Sébastien Charbonnier.

Affected and fixed versions

The vendor's matrix lists the following remediation boundaries for CVE-2026-49435:

IxChariot Endpoint: versions before 10.0.254 are affected; move to 10.0.254, released 30 April 2026, or later.
Hawkeye: versions before 6.0.7 are affected; move to 6.0.7, released 26 June 2026, or later.
IxProbe, IxTap, and IxByPass: versions before 3.13.0 are affected; move to 3.13.0, released 26 June 2026, or later.

The same advisory assigns CVE-2017-20242 and CVE-2017-20241 high severity for IxChariot Endpoint versions older than 9.5.102. Keysight says those two defects were fixed in 2017 during normal maintenance, when they were treated as functional bugs rather than security vulnerabilities. Updating to the current supported build addresses the modern critical boundary and avoids relying on an old intermediate release.

Why network-test infrastructure is easy to overlook

Performance-test endpoints and network probes often live outside the normal workstation and server patch process. They may be deployed in labs, branch locations, staging environments, appliance networks, or temporary test segments and then left running after the original project ends. Hawkeye and probe components may also be tracked by a network engineering team rather than endpoint or vulnerability management.

This organisational gap can be more important than a raw severity score. A scanner cannot remediate an installation that nobody owns, and a product inventory may list “Keysight” without the component or running version needed to match the advisory. Search licensing, downloads, container registries, deployment scripts, golden images, configuration systems, network diagrams, and procurement records as well as live network data.

Patch without breaking the measurement environment

Build the component map. Record each controller, endpoint, Hawkeye node, IxProbe, IxTap, and IxByPass instance, including operating system, location, owner, exposure, and installed version.
Confirm vendor support. Obtain the appropriate package through Keysight's approved channel and review compatibility, licence, topology, and sequencing requirements for the exact deployment.
Protect rollback data. Back up supported configuration, test definitions, credentials references, and integration settings. A rollback should restore service, not silently restore a vulnerable build to production.
Reduce reachability during the window. Restrict management and endpoint ports to required sources, remove direct public exposure, and disable dormant agents or probes. Segmentation reduces opportunity but does not replace the update.
Upgrade and verify. Confirm the running version after restart, controller-to-endpoint communication, scheduled tests, metrics, time synchronisation, API integrations, and alerting. Capture evidence from the product, not only the software-distribution console.

Check for compromise before closing the ticket

Keysight has not published a detailed exploit path in the advisory and does not report known malicious exploitation. Defenders should therefore avoid fabricating a signature. Review the vulnerable interval for abnormal connections to affected services, unexpected child processes, changed binaries or configuration, new persistence, unusual accounts, and outbound traffic inconsistent with test activity.

If evidence indicates code execution, isolate the affected system and preserve forensic material before rebuilding. Treat secrets, service credentials, tokens, and keys accessible to that host as potentially exposed, and rotate them from a known-clean environment. A successful upgrade does not remove access obtained before the fix.

The governance lesson for EU operators

Vulnerability management under NIS2-oriented programmes should cover the tools used to test and observe networks, not only business applications. For manufacturers and software teams preparing for Cyber Resilience Act obligations, the disclosure also illustrates why product inventories, supported-version policies, coordinated vulnerability handling, and clear remediation tables matter to customers.

For Romanian organisations, a defensible record would connect the vendor advisory to an internal asset search, exposure decision, named owner, change record, post-update validation, and documented incident assessment. “No affected asset found” is useful only when the search method and data sources are retained.