Skip to content
Log inStart free trial

GHSA-x4rx-4gw3-53p4 CVE-2025-54388 GO-2025-3830

Moby firewalld reload makes published container ports accessible from remote hosts

Medium Go
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.27%
Chance of exploitation in the next 30 days. Higher than 18.51% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-909 Missing Initialization of Resource
Fix
28.3.3
Upgrade github.com/docker/docker to this version or later

Description

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.

Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.

Impact

The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".

When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that prevent packets arriving on a host interface from reaching container addresses are not re-created.

Once these rules have been removed, a remote host configured with a route to a Docker bridge network can access published ports, even when those ports were only published to a loopback address. Unpublished ports remain inaccessible.

For example, following a firewalld reload on a Docker host with address 192.168.0.10 and a bridge network with subnet 172.17.0.0/16, running the following command on another host in the local network will give it access to published ports on container addresses in that network: ip route add 172.17.0.0/16 via 192.168.0.10.

Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.

Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.

Patches

Moby releases older than 28.2.0 are not affected. A fix is available in moby release 28.3.3.

Workarounds

After reloading firewalld, either:

  • Restart the docker daemon,
  • Re-create bridge networks, or
  • Use rootless mode.

References

https://firewalld.org/ https://firewalld.org/documentation/howto/reload-firewalld.html

Affected versions

Go

PackageVulnerableFixed in
github.com/docker/docker
>= 28.2.0, < 28.3.3
28.3.3
github.com/docker/docker
>= 28.2.0+incompatible, < 28.3.3+incompatible
28.3.3+incompatible

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/docker/docker Go → 28.3.3

go
go get github.com/docker/docker@v28.3.3 && go mod tidy

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

Attack vector
Adjacent
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
Passive
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
Low
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
Low
Integrity (subsequent systems)
Low
Availability (subsequent systems)
None

CVSS 3.1 4.6

CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Attack vector
Adjacent
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
None

Weakness

CWE-909: Missing Initialization of Resource

The product does not initialize a critical resource.

How to prevent it
  • Implementation: Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all specified steps.
  • Implementation: Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization.
  • Implementation: Avoid race conditions (CWE-362) during initialization routines.
  • Build and Compilation: Run or compile your product with settings that generate warnings about uninitialized variables or data.

References

Advisories

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rg2x-37c3-w2rh
Docker: Race condition in docker cp allows bind mount redirection to host path
High Also affects github.com/docker/docker
GHSA-vp62-88p7-qqf5
Docker: Race condition in docker cp allows creation of arbitrary empty files on the host via symlink swap
Medium Also affects github.com/docker/docker
GHSA-x86f-5xw2-fm2r
Docker: `PUT /containers/{id}/archive` executes container binary on the host
High Also affects github.com/docker/docker
GO-2026-4887
Moby has AuthZ plugin bypass when provided oversized request bodies
High Also affects github.com/docker/docker
GHSA-pxq6-2prw-chj9
Moby has an Off-by-one error in its plugin privilege validation
High Also affects github.com/docker/docker
GHSA-4vq8-7jfc-9cvp
Moby firewalld reload removes bridge network isolation
Medium Also affects github.com/docker/docker
GHSA-v23v-6jw2-98fq
Authz zero length regression
Critical Also affects github.com/docker/docker
GHSA-xmmx-7jpf-fx42
Moby (Docker Engine) is vulnerable to Ambiguous OCI manifest parsing
Low Also affects github.com/docker/docker
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor