Two Old Flaws Attackers Are Scanning Right Now — Are You Exposed?

If you are running Spring Boot in production or managing physical servers with out-of-band management controllers, there are two scanning campaigns happening right now that you need to check against.

The first targets Java Spring Boot applications exposing the /actuator/heapdump endpoint. The second exploits a twenty-year-old IPMI 2.0 authentication weakness in Baseboard Management Controllers (BMCs). Both are well-known, both have been documented for years, and both are being actively probed on the public internet at this moment.

Spring Boot Heap Dump Scanning

The SANS Internet Storm Center reported on July 27, 2026 that attackers are actively scanning for Java Spring Boot applications with exposed /actuator/heapdump endpoints. The raw HTTP requests look like this:

GET /admin-api/actuator/heapdump HTTP/1.1
Host: target-ip
Authorization: Basic YWRtaW46YWRtaW4=

That Base64-encoded header decodes to admin:admin. The attack is not sophisticated: attackers try the default Spring Security credentials against a commonly-customised actuator base path. What makes it effective is how often it works.

Why a Heap Dump Matters

When a Spring Boot actuator heap dump endpoint responds, it returns a .hprof binary file — a full snapshot of the Java application’s heap memory at that instant. Heap dumps are the Java equivalent of a Linux core dump, and they contain everything the application had in memory at the time: database connection strings, API keys, cloud provider credentials, OAuth tokens, JWT signing secrets, session cookies, cached customer data, and encryption keys.

An attacker who downloads a heap dump does not need to maintain access to the server. They analyse it offline using standard Java memory analysis tools (Eclipse MAT, JProfiler, or simply strings) at their leisure, extracting credentials that often open doors far beyond the Spring Boot application itself — cloud consoles, Kubernetes clusters, CI/CD pipelines, internal APIs.

What to Check Right Now

# Check if heapdump is exposed from outside
curl -I https://your-server/actuator/heapdump
curl -I https://your-server/admin-api/actuator/heapdump

# List enabled actuator endpoints
curl https://your-server/actuator

# Test authentication is enforced
curl -u admin:admin https://your-server/admin-api/actuator/heapdump

The fact that attackers are probing customised base paths (/admin-api/actuator/heapdump rather than the default /actuator/heapdump) suggests they have moved beyond simple default-path scanning. They know that many organisations change the management context path in their configuration:

management:
  endpoints:
    web:
      base-path: /admin-api/actuator

If you use a custom actuator prefix, consider it already in attacker scanner databases.

IPMI / BMC Password Hash Exposure

Simultaneously, security researchers at Lava published findings on July 29, 2026 documenting that 24,650 out of 36,872 internet-exposed BMCs running IPMI 2.0 return password-derived authentication hashes before a login attempt. The vulnerability is CVE-2013-4786 — a twenty-year-old flaw in the IPMI 2.0 RAKP (Remote Authentication Key Exchange) protocol.

How It Works

During the IPMI 2.0 authentication handshake, a BMC sends back an HMAC-SHA1 value calculated from the user’s password and session-specific random values. This response is returned before the client authenticates. An unauthenticated remote party that can reach UDP port 623 can collect this hash, then test password guesses offline — without generating the failed-login noise that would normally alert an operator.

Of the 24,650 endpoints returning hashes:

• 6,240 (16.9%) accepted an empty username matching a weak password candidate
• 2,340 (6.3%) had a named account (ADMIN, root) whose password matched a common wordlist entry
• Supermicro systems — accounting for over 50% of the responding BMCs — use a ten-character uppercase factory password format (26¹⁰ keyspace), which is exhaustively crackable on modern GPU hardware in roughly one hour per response

Lava demonstrated this by recovering factory passwords from two Supermicro X13DEM servers at a US-based GPU provider, and cracking an HPE iLO 2.8-trillion-keyspace factory password in 32 seconds on a single eight-GPU node.

They also found an HPE iLO 4 login page already displaying a ransom note. The attack surface is not hypothetical — compromise is already happening.

Why BMC Compromise Is Worse Than You Think

A BMC operates independently of the host operating system. It can power-cycle the server, mount virtual media, access the remote console, read hardware sensors, update firmware — all without the OS knowing. A compromised BMC gives an attacker:

• Persistence below the operating system (survives OS reinstall, disk replacement)
• Access to shared out-of-band management networks where traffic is monitored less closely than production
• Lateral movement to other BMCs and management interfaces across the data centre

In AI infrastructure and GPU cloud environments, the risk is amplified. Shared management networks can span multiple customer tenancies, turning one compromised BMC into a path across tenant boundaries.

What to Check Right Now

# Check if UDP 623 is reachable from the internet
# (run from outside your network boundary)
nc -z -u your-server-ip 623

# Test IPMI cipher suite 0 (weak)
ipmitool -H your-server-ip -U admin -P '' raw 0x06 0x01

# Verify BMC is not accessible from public IPs
# Use an external scanning service or a host in a different network

The fix is straightforward: block UDP port 623 at the network edge, replace factory passwords during provisioning, restrict BMC access to a dedicated private management network behind a VPN or bastion host, and monitor the management plane separately from production workloads.

The Common Thread

Both campaigns share the same pattern: attackers are not discovering new vulnerabilities. They are exploiting configuration weaknesses in old, well-understood attack surfaces that organisations have deprioritised or forgotten.

Spring Boot actuator endpoints are debugging tools that should never be exposed to the internet with default credentials. IPMI was designed for trusted internal networks and should never be reachable from the public internet. Both have been documented for over a decade. Both are actively being scanned at scale right now.

Take twenty minutes today to check. The scans are already running.