This is less a wide-open front door than a pile of old keys, most of which do not fit this lock
Tenable plugin 76345 flags HP System Management Homepage (SMH) 7.3.2 and earlier on Linux/Windows for multiple bundled OpenSSL issues: CVE-2010-5298, CVE-2014-0076, CVE-2014-0195, CVE-2014-0198, CVE-2014-0221, CVE-2014-0224, and CVE-2014-3470. HPE fixed this line in SMH 7.3.3.1, with 7.2.4.1 only for the Windows 2003 branch; HPE also noted Linux x86 7.3.3.1 still ships OpenSSL 1.0.0d, but said the practical CVE-2014-0224 risk depends on what it talks to.
The vendor/plugin MEDIUM call is not outrageous, but for patch triage across a big estate it is still too hot. Most of the scary CVEs in this bundle are not reachable through normal SMH use: the best technical RCE candidate is DTLS-only (CVE-2014-0195), two bugs need DTLS client mode (CVE-2014-0221) or anonymous ECDH client use (CVE-2014-3470), two require SSL_MODE_RELEASE_BUFFERS enabled, which OpenSSL says is not the default and not common, and the remaining notable issue (CVE-2014-0224) is a man-in-the-middle condition that needs both ends vulnerable. On a management page typically reached by standard admin browsers over an internal network, that is a narrow, high-friction chain.
4 steps from start to impact.
Find exposed SMH on 2381/tcp
https://host:2381. Commodity recon with nmap, masscan, or passive exposure platforms can find it if you left it reachable beyond an admin segment.- SMH installed and running
- Port
2381/tcpreachable from the attacker's network position - Firewall/VPN policy does not isolate the interface
- SMH is a legacy server-management interface, not a mass-market internet app
- Many enterprises keep it on server VLANs, OOB/admin networks, or behind VPN
- A lot of estates have already retired SMH in favor of iLO/other tooling
76345 is remote and banner-based; local version validation via smhlogreader -version is authoritative.Try the obvious OpenSSL RCE path and hit a protocol mismatch
CVE-2014-0195, is the OpenSSL DTLS fragment overflow. An operator could reach for Metasploit or private frameworks, but that path requires the target to use DTLS, while SMH is normally an HTTPS/TLS service, so the exploit chain usually dies right there.- Target service must actually negotiate DTLS, not plain TLS
- Attacker can deliver crafted DTLS handshake fragments to the vulnerable process
- SMH's normal exposure is HTTPS on
2381, not DTLS - No evidence in the vendor docs that the SMH web interface runs DTLS in normal deployments
- This is the biggest downward pressure on the whole finding
Fall back to CVE-2014-0224 and require a real MITM
CVE-2014-0224), using tools such as bettercap, mitmproxy, or the old ssllabs/openssl-ccs-cve-2014-0224 tester. But the attacker must sit in-path between the admin and SMH, and the OpenSSL advisory says the attack only works between a vulnerable client and a vulnerable server.- Attacker already controls routing, switching, Wi-Fi, or another network choke point
- The administrator is using a vulnerable OpenSSL-based client to connect
- The SMH server is one of the vulnerable OpenSSL builds
- Requiring on-path position means this is usually post-initial-access or insider territory
- Typical Windows admin browsers of that era did not rely on OpenSSL in the same way
- Even where the server is vulnerable, the client-side prerequisite sharply narrows the population
Abuse impact is usually session tamper or nuisance, not clean host takeover
- Successful MITM or another narrow OpenSSL precondition is met
- Attacker can meaningfully interact with an admin session or upstream peer
- No strong evidence of modern in-the-wild exploitation against SMH specifically
- No KEV signal found for the bundled component CVEs used here
- Blast radius is bounded by a legacy management interface, not a core identity or edge platform
The supporting signals.
| In-the-wild status | I found no direct evidence of current campaigns targeting HP SMH for this plugin. I also found no CISA KEV listing for the main bundled OpenSSL CVEs used to justify this plugin, based on the current CISA KEV catalog search results. |
|---|---|
| Public PoC / weaponization | Yes, but mostly for the underlying OpenSSL CVEs, not for HP SMH specifically. Tenable says the plugin is exploitable with Core Impact; public references also exist for CVE-2014-0224 (for example ssllabs/openssl-ccs-cve-2014-0224) and SANS noted a Metasploit module for CVE-2014-0195. |
| EPSS | The underlying CVEs carry high EPSS on Tenable's CVE pages: CVE-2014-3470 shows 0.91395, and CVE-2014-0195 is listed by OpenCVE at 0.92751. That says attackers like old OpenSSL bugs in general; it does not mean this SMH deployment is on an easy path. |
| KEV status | Not observed in KEV for the component-level OpenSSL CVEs relevant here, using the current CISA KEV catalog. Confidence here is medium because CISA's public site is catalog-oriented rather than plugin-oriented. |
| CVSS vector reality check | Tenable scores the plugin from CVE-2014-0195 at CVSSv2 6.8 AV:N/AC:M/Au:N/C:P/I:P/A:P. In practice, that overstates real enterprise risk for SMH because the top-impact path assumes DTLS exposure, which does not map cleanly to a normal SMH HTTPS deployment. |
| Affected versions | HPE bulletin HPSBMU03051 says HP System Management Homepage 7.3.2 and earlier for Linux and Windows are impacted. |
| Fixed versions | HPE fixed with SMH 7.3.3.1 for Linux/Windows and 7.2.4.1 for the Windows 2003-only branch. Important caveat: HPE says Linux x86 7.3.3.1 still contains OpenSSL 1.0.0d and relies on peer updates for the CVE-2014-0224 corner case. |
| Exposure / scanning context | SMH is normally exposed on 2381/tcp. HPE's own docs tell admins to browse to https://hostname:2381, and public port references identify 2381 with HP Insight/SMH. That means exposure is easy to inventory internally, but broad internet exposure is usually a configuration mistake, not the default enterprise posture. |
| Disclosure timeline | OpenSSL published the component advisory on 2014-06-05. HPE published bulletin HPSBMU03051 on 2014-06-23 and updated it on 2014-07-03. |
| Researchers / reporters | CVE-2014-0224 was credited by OpenSSL to KIKUCHI Masashi (Lepidum); CVE-2014-0195 was reported via HP ZDI by Jüri Aedla. The HPE bulletin source is the HP Software Security Response Team. |
noisgate verdict.
The decisive factor is protocol and position friction: the best-impact bugs in this bundle need DTLS, client mode, MITM, or non-default OpenSSL options, which means the real attack path on a standard SMH HTTPS deployment is thin. This is a legacy management-plane hygiene problem, not a broadly reliable remote-compromise primitive.
Why this verdict
- DTLS kills the scariest path: the plugin's CVSS baseline is anchored to
CVE-2014-0195, but that bug is DTLS-only. SMH is normally an HTTPS web service on2381, so the headline RCE path does not map to the common deployment. - Best remaining path needs attacker-in-the-middle:
CVE-2014-0224is the residual concern, but OpenSSL says the attack requires a vulnerable client and server plus a real MITM position. That implies prior network foothold, local segment control, or insider access. - Other bundled CVEs are edge-case noise here:
CVE-2014-0221is DTLS client-only,CVE-2014-3470hits TLS clients using anonymous ECDH,CVE-2014-0198andCVE-2010-5298requireSSL_MODE_RELEASE_BUFFERS, andCVE-2014-0076is a cache side-channel. Each prerequisite further narrows the exposed population.
Why not higher?
There is no clean evidence here of a reliable unauthenticated remote exploit against the normal SMH web service. The plugin is mostly inheriting risk from the bundled OpenSSL version, while the actual SMH attack surface removes or sharply constrains the most severe exploit chains.
Why not lower?
I did not drop this to IGNORE because SMH is still a server-management interface, and if it is exposed on a flat admin network or externally, even a MITM-oriented flaw matters more than it would on a random desktop app. Also, some estates really did leave legacy HP management services reachable on 2381, so there is still meaningful hygiene value in fixing or retiring it.
What to do — in priority order.
- Restrict
2381/tcpand2301/tcp— Allow access only from dedicated admin jump hosts or management VLANs. For aLOWverdict there is no SLA; treat as backlog hygiene, but if any SMH instance is internet-reachable or broadly reachable from user networks, cut exposure immediately because segmentation removes the only realistic remote path. - Retire unused SMH — If the host no longer needs HP SMH, disable or remove it instead of carrying a dead management surface forever. For
LOW, this is backlog hygiene with no fixed SLA, but it usually buys down more risk than patching a legacy console you never use. - Verify admin path — Confirm whether admins access SMH only from modern browsers and over controlled paths such as VPN or jump boxes. For
LOW, there is no mitigation SLA, but validating the admin path is the fastest way to prove theCVE-2014-0224MITM scenario is non-viable in your environment. - Inventory and patch on touch — Use Nessus plus local
smhlogreader -versionchecks to inventory versions, then patch or retire during the next planned maintenance affecting those servers. ForLOW, this is backlog hygiene, not an emergency patch cycle.
- A generic EDR/AV agent does not materially reduce the main risk here, because the relevant paths are network protocol flaws and MITM conditions, not malware execution on the host.
- A password rotation-only response misses the point. The meaningful residual risk is transport/session tampering on a reachable management interface, not stolen local credentials from the OpenSSL bundle itself.
- Blindly chasing the CVSS headline from the bundled library does not help prioritization; the library bug list is broader than the attack surface actually exposed by SMH.
Crowdsourced verification payload.
Run this on the target host or from an auditor workstation with network reachability to the SMH port. Invoke it as python3 check_hpsmh_76345.py --host server01 --port 2381 or locally as python3 check_hpsmh_76345.py; it needs only normal user rights for a remote banner check, but local smhlogreader execution may require the binary to be present in the product install path.
#!/usr/bin/env python3
# check_hpsmh_76345.py
# Verify exposure for Tenable plugin 76345 (HP SMH bundled OpenSSL issues)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import argparse
import os
import platform
import re
import socket
import ssl
import subprocess
import sys
from typing import Optional, Tuple
def parse_ver(v: str):
nums = re.findall(r'\d+', v)
return tuple(int(x) for x in nums[:4])
def cmp_ver(a: Tuple[int, ...], b: Tuple[int, ...]) -> int:
maxlen = max(len(a), len(b))
a = a + (0,) * (maxlen - len(a))
b = b + (0,) * (maxlen - len(b))
return (a > b) - (a < b)
def classify_smh_version(v: str) -> str:
# HPE fixed branch points cited by the bulletin:
# - 7.3.3.1 fixed for Linux/Windows
# - 7.2.4.1 fixed for Windows 2003 branch only
try:
pv = parse_ver(v)
except Exception:
return 'UNKNOWN'
if cmp_ver(pv, parse_ver('7.3.3.1')) >= 0:
return 'PATCHED'
if cmp_ver(pv, parse_ver('7.2.4.1')) >= 0 and cmp_ver(pv, parse_ver('7.3.0.0')) < 0:
return 'PATCHED'
if cmp_ver(pv, parse_ver('7.3.2.0')) <= 0:
return 'VULNERABLE'
return 'UNKNOWN'
def run_cmd(path: str) -> Optional[str]:
if not os.path.exists(path):
return None
try:
proc = subprocess.run([path, '-version'], capture_output=True, text=True, timeout=10)
out = (proc.stdout or '') + '\n' + (proc.stderr or '')
return out.strip()
except Exception:
return None
def local_smh_version() -> Optional[str]:
candidates = []
if platform.system().lower().startswith('win'):
candidates = [
r'C:\hp\hpsmh\bin\smhlogreader.exe',
r'C:\hp\hpsmh\bin\smhlogreader'
]
else:
candidates = [
'/opt/hp/hpsmh/bin/smhlogreader',
'/opt/hpsmh/bin/smhlogreader'
]
for c in candidates:
out = run_cmd(c)
if out:
m = re.search(r'(\d+\.\d+\.\d+(?:\.\d+)?)', out)
if m:
return m.group(1)
return None
def remote_banner(host: str, port: int, timeout: int = 5) -> Tuple[Optional[str], Optional[str]]:
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
try:
with socket.create_connection((host, port), timeout=timeout) as sock:
with ctx.wrap_socket(sock, server_hostname=host) as ssock:
req = f'HEAD / HTTP/1.0\r\nHost: {host}\r\n\r\n'.encode()
ssock.sendall(req)
data = ssock.recv(4096).decode(errors='ignore')
m = re.search(r'^Server:\s*(.+)$', data, re.I | re.M)
banner = m.group(1).strip() if m else None
vm = re.search(r'System Management Homepage/(\d+\.\d+\.\d+(?:\.\d+)?)', data, re.I)
version = vm.group(1) if vm else None
return banner, version
except Exception:
return None, None
def main():
ap = argparse.ArgumentParser(description='Check HP SMH version for Tenable plugin 76345')
ap.add_argument('--host', default='127.0.0.1', help='Target host for HTTPS banner check (default: 127.0.0.1)')
ap.add_argument('--port', type=int, default=2381, help='Target HTTPS port (default: 2381)')
args = ap.parse_args()
local_ver = local_smh_version()
if local_ver:
status = classify_smh_version(local_ver)
print(f'LOCAL_VERSION={local_ver}')
print(status)
sys.exit({'PATCHED': 0, 'VULNERABLE': 1}.get(status, 2))
banner, remote_ver = remote_banner(args.host, args.port)
if banner:
print(f'SERVER_BANNER={banner}')
if remote_ver:
status = classify_smh_version(remote_ver)
print(f'REMOTE_VERSION={remote_ver}')
print(status)
sys.exit({'PATCHED': 0, 'VULNERABLE': 1}.get(status, 2))
print('UNKNOWN')
print('No local smhlogreader found and no parsable remote SMH banner retrieved.')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
2381/2301 outside admin networks; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene, but any internet-exposed instance should be segmented or retired the same day because exposure is the only thing making this interesting. Then patch to 7.3.3.1 or retire SMH during the next maintenance touch on those servers, with extra care around the Windows 2003 7.2.4.1 branch and the Linux x86 7.3.3.1 caveat noted by HPE.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.