netavark CVE-2025-8283
LOWCVSS VectorNVD
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Lifecycle Timeline
2DescriptionNVD
A vulnerability was found in the netavark package, a network stack for containers used with Podman. Due to dns.podman search domain being removed, netavark may return external servers if a valid A/AAAA record is sent as a response. When creating a container with a given name, this name will be used as the hostname for the container itself, as the podman's search domain is not added anymore the container is using the host's resolv.conf, and the DNS resolver will try to look into the search domains contained on it. If one of the domains contain a name with the same hostname as the running container, the connection will forward to unexpected external servers.
AnalysisAI
DNS resolve confusion in netavark, the Rust-based network stack for Podman containers, causes container name lookups to be forwarded to unexpected external DNS servers due to a regression that removed the dns.podman search domain. Affected deployments on Red Hat Enterprise Linux 8/9/10 and OpenShift Container Platform 4.0 running netavark < 1.15.1 are subject to misdirected container DNS resolution when host resolv.conf search domains contain a record matching a running container's hostname. The impact is limited to information disclosure (CVSS 3.7, Low), with no confirmed active exploitation and no public exploit identified at time of analysis.
Technical ContextAI
Netavark is a Rust-implemented network stack that manages networking for rootful Podman containers, including internal DNS resolution. Historically, netavark injected a 'dns.podman' search domain to scope container hostname resolution within the container network. A regression removed this search domain, causing the container to fall back to the host's /etc/resolv.conf for DNS resolution. CWE-15 (External Control of System or Configuration Setting) captures the root cause: an externally influenced configuration (the host's resolv.conf search domains) is now consulted where the internal search domain should take precedence. If the host's search domains include a domain with an A or AAAA record matching the container's hostname, the resolver satisfies the query using that external record rather than the expected internal container IP. Affected CPEs confirm the exposure spans cpe:2.3:a:redhat:openshift_container_platform:4.0, cpe:2.3:o:redhat:enterprise_linux:8.0, 9.0, and 10.0.
RemediationAI
The vendor-released patch is netavark v1.15.1, confirmed by the tagged GitHub release at https://github.com/containers/netavark/releases/tag/v1.15.1 and upstream fix commit 068abc869b736a03a947b5419c102da73830e882 (PR #1256). Upgrade netavark to 1.15.1 or later on all affected systems running RHEL 8/9/10 or OpenShift Container Platform 4.0. For Red Hat systems, monitor https://access.redhat.com/security/cve/CVE-2025-8283 for RPM package availability. As a compensating control prior to patching, administrators can audit the host's /etc/resolv.conf search domain list and remove or restrict entries that could resolve container hostnames externally - note that modifying resolv.conf may affect other host-level DNS resolution behavior and should be tested. Alternatively, avoid naming containers with hostnames that overlap with entries resolvable through the host's search domains. No significant side effects are anticipated from upgrading to 1.15.1, which is described as a regression fix restoring prior correct behavior.
Share
External POC / Exploit Code
Leaving vuln.today