ZoomEye scan counts 917,080 exposed out-of-band management controllers on port 623

What the scan found

A single query against the ZoomEye internet-scan index for port 623 — the port used by IPMI, the protocol spoken by out-of-band management controllers — returned 917,080 matching assets on 23 September 2026. The figure and its analysis come from a dev.to post that examines what the number does, and does not, reveal about the exposure.

Each result represents a listening service on that port at the time ZoomEye collected the data. Port 623 is where baseboard management controllers embedded in servers, and comparable processors in storage and network equipment, accept remote management traffic.

A control point beneath the operating system

Out-of-band controllers exist so administrators can reach a machine when everything above them has broken: console access, power control and firmware updates that do not depend on the operating system. As the dev.to author notes, that same independence is what makes an exposed controller dangerous. Because the service runs below the operating system, host firewalls and OS-level access controls simply do not apply to it.

An attacker who seizes a controller can shut the machine down, attach virtual media to boot a different image, read host memory, or rewrite firmware where the operating system cannot see it. A hardened, fully patched operating system offers no protection for the component underneath it, and host-based monitoring typically has no visibility into controller activity. The only layer where real control exists is the network.

Hardware lifecycles compound the problem: equipment bought eight years ago can still carry its factory controller firmware even after several operating system reinstalls above it.

What the count cannot tell you

The post is deliberately cautious about the limits of the measurement. A port count cannot distinguish vendors, whose IPMI implementations differ in security posture and default behaviour. It says nothing about authentication: a controller with strong credentials and one still using vendor defaults look identical from the outside, even though the two situations carry very different risk. It reveals nothing about firmware age, and it cannot tell whether a controller sits on a dedicated management network or is reachable from an office subnet — positions with substantially different exposure.

A review sequence

The post proposes five steps for closing the gap:

• Enumerate the controllers themselves, which is a different question from what is in the asset register, since the component often belongs to facilities or hardware teams rather than the security function.
• Confirm that no management port is reachable from general-purpose networks; where remote access is genuinely needed, use a dedicated management network or a jump host with strong authentication.
• Change vendor default credentials, which the author calls the highest-value single action for this device class and one that costs an administrator minutes per host.
• Track controller firmware alongside operating system patch cycles, since the two update through separate processes and controllers frequently lag years behind.
• Retire controllers together with the hardware — a decommissioned server whose management controller still has power and a network connection remains a reachable system.

The post also points readers to CISA's Known Exploited Vulnerabilities Catalog as supporting reference material.

Why it matters

Nearly a million exposed management interfaces amount to a quantified attack surface that sits outside the usual security review agenda: the controller is not an application, runs no agent, and rarely has an owner inside the security team. A population this large means scanning for port 623 is routine, so attackers face no discovery burden in finding these devices. At the same time, the count's blind spots — authentication settings, firmware age, network position — mean an organisation cannot judge its own risk from outside data alone. The only dependable answer is an internal inventory of baseboard and service processors, and the scale of the exposure suggests most organisations have never built one.