Loading story…
OpenStack disclosed that Ironic Python Agent (IPA) versions 3.7.0 through 11.6.1 can unexpectedly fall back to multicast DNS (mDNS) when the agent boots without a valid API URL, allowing it in rare cases to discover and connect to an unintended Ironic API service on the local network. The issue primarily affects specialized bare-metal bootstrap workflows such as virtual media or USB-based provisioning, because standard Ironic-managed deployments normally provide a valid API URL and do not rely on discovery behavior.
To reduce the risk, OpenStack changed IPA so mDNS fallback is no longer automatic and must be explicitly enabled with settings such as ipa-api-url=mdns or ipa-use-mdns=True. Reporting on the disclosure also highlighted a separate July fix in the same component, where the ntp_server value could be inserted into a shell command without proper validation, creating a potential root-level command injection path during early boot; together, the issues underscore the security sensitivity of pre-OS provisioning paths. No CVE was assigned to the mDNS fallback issue, and operators were advised to verify that IPA boots are managed by Ironic and to review any environments that intentionally depend on mDNS before upgrading.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
On July 23, 2026, OpenStack fixed a separate Ironic Python Agent vulnerability in which the ntp_server setting was inserted into a shell command without proper validation, enabling root-privileged command injection during provisioning if an attacker controlled that value.
OpenStack published security notice OSSN-0104 warning that ironic-python-agent versions 3.7.0 through 11.6.1 could unexpectedly fall back to mDNS when booted without a valid API URL, potentially allowing the agent to be redirected to a different Ironic API service. The notice said no CVE was assigned and advised operators to ensure IPA boots are properly managed and explicitly enable mDNS only where needed.
OpenStack updated the 2026.2 development branch of ironic-python-agent so multicast DNS fallback no longer occurs automatically and instead requires explicit opt-in via settings such as ipa-api-url=mdns or ipa-use-mdns=True. The change was described as backwards incompatible and was not merged into stable branches.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
OpenStack disclosed **OSSA-2026-008** for a command injection vulnerability in **Ironic** IPMI console implementations, later assigned **`CVE-2026-42510`**. The flaw allows a project manager designated as a `node.owner` to inject arbitrary commands that are executed by an **Ironic conductor** when a console session is activated. The issue was reported by Dmitry Tantsur and Tuomo Tanskanen of the Metal3.io Security Team. The vulnerability affects specific Ironic versions only when the optional **`ipmitool-shellinabox`** or **`ipmitool-socat`** console interfaces are explicitly enabled through `enabled_console_interfaces`; OpenStack noted that console backends are disabled by default. Patches were released for maintained and some unmaintained branches, and OpenStack warned that **`ipmitool-shellinabox`** is already slated for removal because of security support concerns, urging security-sensitive operators to stop using it immediately.
Jun 29, 2026
Red Hat disclosed **CVE-2026-76578** (CVSS 9.8), a critical FreeIPA privilege-escalation flaw that lets an unauthenticated remote LDAP client create an attacker-controlled Kerberos principal and add it to the FreeIPA administrators group. The attack combines FreeIPA’s overly permissive self-service OTP token access-control rule with **CVE-2026-76560** in 389 Directory Server, where anonymous clients can satisfy an ownership check when an owner field is empty. Researchers reproduced the attack against a default FreeIPA deployment, producing reusable administrator Kerberos credentials; SID-enabled environments may also permit PAC-bearing tickets that expand access to HTTP and Dogtag services. RHEL 7, 8, 9, and 10 IPA/IdM components are affected. FreeIPA 4.13.4 addresses the FreeIPA-side issues, while Red Hat released RHEL 9 389 Directory Server updates through **RHSA-2026:64781**, including fixes for the anonymous LDAP authorization-control bypass, a SASL PLAIN privilege-escalation issue, a heap buffer overflow, and a pre-authentication NULL-pointer dereference. Organizations should urgently apply available updates; until all relevant packages are available, restrict LDAP ports 389 and 636 to trusted hosts and evaluate disabling anonymous LDAP binds. Red Hat reported no public evidence of active exploitation.
Sep 10, 2026
Red Hat disclosed **CVE-2026-11861**, a FreeIPA privilege-escalation flaw affecting deployments that maintain a trust relationship with **Active Directory**. In vulnerable environments, an authenticated AD user can impersonate a client name in a Kerberos **Ticket Granting Service (TGS)** request and bypass authentication to FreeIPA services because affected components trust the TGS `cname` field and do not properly verify **Privilege Attribute Certificate (PAC)** certificates. Red Hat said the issue can affect the FreeIPA portal, SMB server, LDAP directory, and likely other GSSAPI-enabled services, creating a path to privilege escalation inside the FreeIPA domain. The vendor assigned the bug a **CVSS 9.6** score but rated it **Moderate** because exploitation depends on uncommon prerequisites, including a configured FreeIPA-AD cross-realm trust, valid AD credentials, and an AD setup that allows a duplicate or conflicting **SPN** condition. Red Hat listed `ipa` packages in **RHEL 7, 8, 9, and 10** as affected, while noting that patched and modern Microsoft environments—including **Windows Server 2012 R2** with **MSKB-3070083** and newer defaults such as **Windows 11 22H2**—can block the attack path on the AD side. No mitigation meeting Red Hat Product Security criteria was available at publication time, and defenders were urged to review trust relationships, enforce SPN and UPN uniqueness, and monitor for vendor fixes.
Aug 22, 2026