CVE-2026-105105: AIT-Core Fix and Analysis
CVE-2026-105105 is a critical missing-authentication vulnerability in NASA-AMMOS AIT-Core’s ait-server ZeroMQ broker. Affected deployments through version 3.1.1 may allow unauthenticated attackers with network access to inject commands or read telemetry. Upgrade to AIT-Core 3.1.2 and restrict TCP ports 5559 and 5560 to trusted networks.
TL;DR - CVE-2026-105105 affects AIT-Core’s
ait-serverZeroMQ broker. - Affected deployments through 3.1.1 may permit unauthenticated command injection or telemetry access. - Upgrade to 3.1.2 and immediately restrict TCP 5559 and 5560 to trusted networks. - Active exploitation and a verified public proof of concept were not confirmed in the supplied research.
Are You Affected?
CVE-2026-105105 affects the NASA-AMMOS AIT-Core project, specifically the ait.core.server telemetry and command broker commonly deployed as ait-server. The affected range is AIT-Core through version 3.1.1, including 3.1.1. The stated fixed version is AIT-Core 3.1.2.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-105105 |
| CVSS base score | 9.8 Critical |
| CVSS vector | Not returned in the supplied NVD data; verify the authoritative NVD record before publication or risk scoring |
| Attack vector | Network-reachable ZeroMQ broker |
| Authentication required | None, according to the NVD description |
| Affected product | NASA-AMMOS AIT-Core ait.core.server / ait-server |
| Affected versions | Through 3.1.1, including 3.1.1 |
| Fixed version | 3.1.2 |
| Patch available | Yes |
| Relevant services | TCP 5559 and TCP 5560 |
A deployment is especially exposed when the broker uses the shipped default bind behavior, which binds its XSUB and XPUB sockets to all network interfaces. Network reachability is required: an attacker must be able to connect to the relevant ZeroMQ services. A system bound only to loopback or isolated behind a properly restrictive firewall has a substantially smaller exposure window, but it should still be upgraded.
Asset owners should search package inventories, Python virtual environments, deployment manifests, container images, and service definitions for AIT-Core or ait-server. Identify systems that expose TCP 5559 or 5560 as well. Treat any internet-facing, partner-facing, or broadly routable instance as urgent until its exposure has been disproved.
For broader software inventory and dependency-management considerations, see this guide to software composition analysis tools.
Analyst’s Take: Network reachability is the key triage question, but it does not replace patching. First identify exposed listeners and restrict access to approved ground-segment or management networks, then move the deployment to 3.1.2.
The Fix, If You’re in a Hurry
Upgrade AIT-Core to 3.1.2 or later after confirming compatibility with the mission or ground-segment deployment. The supplied vulnerability information identifies 3.1.2 as the version that changes the default ZeroMQ bind addresses to loopback. An upgrade may not correct separately maintained configuration files or deployment overrides, so check those independently.
For a Python installation managed with pip, an example upgrade command is:
python -m pip install --upgrade "ait-core==3.1.2"
python -m pip show ait-core
Use the package and environment management process approved for the deployment. If AIT-Core is installed from a source checkout, container image, or internal artifact repository, update that source to the project’s 3.1.2 release or a later verified release rather than mixing system and virtual-environment packages.
Until the upgrade is complete, restrict both broker ports to trusted ground-segment or management networks. Do not expose them directly to the public internet or to an untrusted mission-partner network. A temporary Linux firewall control can be applied as follows, replacing the example CIDR with the approved broker clients:
sudo iptables -A INPUT -p tcp -m multiport --dports 5559,5560 \
-s 192.0.2.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp -m multiport --dports 5559,5560 \
-j DROP
This is a compensating control, not a patch. Preserve the rule through the host’s standard firewall management system and validate that required command, telemetry, and monitoring paths still work. Where operationally possible, bind the broker to loopback or a dedicated internal interface and use a controlled relay instead of permitting broad access to the ZeroMQ sockets.
Technical Notes
The supplied research does not provide an authoritative AIT-Core configuration schema or a confirmed option name for every deployment. Do not copy an unverified configuration key into production. Inspect the active service definition, rendered configuration, and process arguments to determine whether the XSUB and XPUB endpoints bind to 0.0.0.0, ::, or another non-loopback address:
sudo ss -ltnp | grep -E ':(5559|5560)\b'
ps auxww | grep -E '[a]it-server|[a]it\.core\.server'
How This Vulnerability Works
The root cause is CWE-306, Missing Authentication for Critical Function. The AIT-Core ait-server ZeroMQ broker exposes XSUB and XPUB sockets without authentication or transport security by default. When those sockets are bound to all network interfaces, any host with network access to the broker can attempt to use its publish or subscribe functions without first proving its identity.
The two relevant paths have different security consequences:
- On TCP port 5559, an attacker may publish messages to internal topics, including the
__commands__topic. - With the shipped default configuration, command messages can pass through
command_streamand be emitted through the command-uplink UDP path. - On TCP port 5560, an attacker may subscribe to command and telemetry traffic on the ground bus.
This creates both integrity and confidentiality risks. A malicious publisher could inject forged command data, while a subscriber could capture command or telemetry traffic. Crafted or excessive traffic could also disrupt the command-and-telemetry bus. The precise operational impact depends on downstream validation, routing, authorization controls, and the deployment’s network topology; the vulnerability description does not establish that every deployment will accept every injected message.
An attacker does not need a user account according to the NVD description. The flaw is not automatically exploitable from anywhere, however. The attacker must obtain network-level reachability to the affected ZeroMQ service, and the deployment must expose a vulnerable bind and routing configuration.
Severity, Explained
The reported CVSS base score is 9.8, Critical. That score indicates a vulnerability with severe potential impact and low exploitation friction under the scoring model. The supplied NVD tool output did not include the complete CVSS vector, so the individual component values should not be presented as confirmed until they are verified directly in the authoritative NVD record.
The available facts explain why the score is serious: the broker is network reachable in affected configurations, authentication is not required, and successful abuse may affect confidentiality, integrity, and availability. Command injection in particular can create safety and mission consequences that are disproportionate to the underlying software component’s size.
Technical Notes
Before publishing a compliance report or calculating environmental risk, retrieve the vector from the NVD record and preserve the record version and assessment date:
curl -sS 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-105105' \
| jq '.vulnerabilities[0].cve.metrics'
If the vector is absent from the response available to your tooling, record the confirmed base score as 9.8 and mark the component-level vector as unverified. Do not infer individual CVSS metrics solely from the score.
Is It Being Exploited?
Based on the supplied research, active exploitation in the wild is not confirmed. CVE-2026-105105 is not listed in the CISA Known Exploited Vulnerabilities catalog, and no verified evidence of ransomware use or an active campaign was identified at the assessment date of 2026-10-03.
A verified public proof of concept was not identified in the retrieved sources. The NVD references a GitHub page associated with Mothra-1, but that reference alone does not establish that a working exploit, proof of concept, or exploitation evidence exists. Defenders should not treat that page as confirmation without independently validating the code and its behavior.
The absence of a public PoC or KEV listing does not mean exploitation is impossible. The attack path uses standard network services and does not require authentication, so exposed systems should be treated as high risk while public exploitation status remains unknown. The social and GitHub mention counts in this article reflect the supplied research snapshot, not a guarantee that no discussion exists elsewhere.
For additional vulnerability-monitoring context, review the August 2026 security digest.
Detecting It in Your Environment
Start with network exposure. Identify hosts listening on TCP 5559 or 5560, then compare the source addresses of connections with the approved ground-segment architecture. Unexpected connections from user networks, cloud ranges, partner networks, or the public internet deserve investigation. A listener alone does not prove exploitation, but it confirms that the host may be reachable.
Review application, host, firewall, and network telemetry for unauthorized publishers and subscribers. Useful indicators include:
- Unexpected TCP sessions to either port
- Repeated short-lived connections
- Connections from previously unseen addresses
- Traffic during maintenance windows
- Command or telemetry activity that cannot be reconciled with an authorized ground system
Because ZeroMQ traffic may be framed and application-specific, port telemetry can identify exposure and suspicious access without reliably decoding message intent.
For general-purpose administrator or analyst workstations involved in the investigation, endpoint malware scanning can provide an additional defensive check through Malwarebytes. This does not replace network monitoring, application review, or mission-system incident response.
Technical Notes
A quick live capture for connection and traffic review is:
sudo tcpdump -ni any \
'tcp port 5559 or tcp port 5560'
For Zeek deployments, a practical first-pass query against connection logs is:
zeek-cut ts id.orig_h id.orig_p id.resp_h id.resp_p \
< conn.log \
| awk '$4 == 5559 || $4 == 5560'
A SIEM-style detection can alert on any connection to the broker ports from outside the approved network:
destination.port IN (5559, 5560)
AND NOT source.ip IN approved_ground_segment_ranges
If command-bus application logs expose topic names, search for unexpected use of __commands__, unexpected publisher identities, and command traffic from hosts not present in the mission access list. Do not assume that the absence of a topic string in firewall or flow logs means no command injection occurred; network metadata may not expose ZeroMQ topic contents.
After identifying exposure, preserve relevant packet captures, firewall records, process arguments, service configuration, and package metadata. Determine whether unauthorized clients connected, whether command or telemetry volume changed, and whether downstream command-uplink systems received unexpected messages. If compromise cannot be ruled out, follow the organization’s incident response process and consider rotating credentials or trust material associated with adjacent systems, even though this vulnerability itself does not require authentication.
Recommended Response Checklist
- Inventory AIT-Core and
ait-serverinstallations. - Identify hosts listening on TCP 5559 or 5560.
- Determine whether the broker is bound to a loopback, dedicated internal, or broadly routable interface.
- Restrict access to approved ground-segment or management networks.
- Upgrade AIT-Core to version 3.1.2 or later.
- Review firewall, service, container, and deployment overrides.
- Search network and application telemetry for unauthorized clients.
- Preserve evidence if unexpected connections or command activity are found.
- Validate command, telemetry, and monitoring functions after remediation.
- Continue monitoring NVD, project advisories, CISA, and internal threat-intelligence sources for updates.
References and Further Reading
The primary technical record is the NVD entry for CVE-2026-105105. Use it to verify the current CVSS vector, affected-product metadata, and any subsequent updates. NVD data can change after initial publication, so record the retrieval date when using it for risk decisions.
Project context and remediation information are available from the NASA-AMMOS/AIT-Core repository. The project’s security advisory pages include GHSA-ccw5-g774-3683 and the GHSA-3j6g-pxmx-58qg advisory reference. Verify that the advisory identifiers and release guidance correspond to CVE-2026-105105 before using them as the sole basis for remediation.
For exploitation-status checks, consult the CISA Known Exploited Vulnerabilities Catalog. As of the assessment date supplied for this article, the CVE was not listed. Organizations should continue monitoring NVD, the project repository, vendor or mission-segment advisories, threat-intelligence feeds, and their own network telemetry because catalog status and exploitation evidence can change after publication.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.