Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify target using default self-signed cert
-
DeliveryObtain predictable default certificate key
-
ExploitForge signed admin JWT token
-
ExecutionReplay token to bypass login
-
ImpactGain administrative access and reconfigure service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Key management, no hard-coded keys
|
| Exploitation Conditions | Exploitation is possible ONLY when the web interface still uses the shipped default self-signed SSL certificate, because that certificate's key is reused to sign the JWT access tokens that authenticate sessions (CWE-321). This is reflected by the CVSS 4.0 AT:P metric. The primary limiting factor is deployment configuration: any environment that has replaced the default certificate with a custom/CA-issued certificate is not vulnerable, as the signing key would then be unknown to the attacker. No user interaction or prior authentication is required (PR:N/UI:N). Impact is further bounded - the attacker obtains administrative/configuration control (e.g., changing service settings, requesting log collection) but, per the vendor, cannot access device credentials or customer data. |
| Impact | This is a genuine high-priority issue rather than a CVSS-inflated one, but its exploitability is gated by a single configuration precondition. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:H/VI:H/VA:N, score 9.1) describes a remote, unauthenticated authentication bypass with high confidentiality and integrity impact but no availability impact - consistent with CWE-321 (use of a hard-coded/shared cryptographic key), since the default self-signed SSL certificate acts as a predictable signing key for JWT access tokens. The AT:P (Attack Requirements: Present) metric is the critical nuance: exploitation only works while the product still uses its shipped default self-signed certificate, so any deployment that replaced the certificate with a custom CA-issued one is not affected. No EPSS score was provided in the input, and the CVE is NOT listed in CISA KEV and has no public exploit code referenced, so there is no evidence of active or at-scale exploitation. The impact is also self-limited by the vendor's own statement that device credentials and customer data cannot be reached - the attacker gains administrative/configuration control, not direct data exfiltration, which tempers the VC:H rating somewhat. Net: credible and serious for organizations running default certificates, but the single-condition gate plus absence of exploitation signals places it below actively-exploited internet-facing flaws in triage order. |
| Exploit ScenarioDerived | An organization deploys the Hitachi Vantara web interface without replacing the shipped default self-signed SSL certificate. Because that certificate's key also signs the JWT access tokens, a remote attacker who possesses or derives the predictable default key forges a valid admin JWT and bypasses login entirely, then reconfigures the service or triggers log collection. No public exploit code is referenced at time of analysis, and exploitation requires the default certificate to still be in place (CVSS AT:P). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Unauthenticated remote attackers can mint valid JWT access tokens - and thereby log in as an administrator - on affected Hitachi Vantara deployments by abusing the private key shipped inside the product's default self-signed SSL certificate (CWE-321, hard-coded cryptographic key). Exploitation is gated by a single configuration precondition: the web interface must still be running the out-of-the-box default certificate whose key material is reused to sign session JWTs, which is why the vendor's CVSS 4.0 vector carries AT:P (attack requirements present) even though no authentication or user interaction is needed (PR:N/UI:N). Impact is bounded to administrative/configuration control such as changing service settings or requesting log collection - the vendor states device credentials and customer data are not reachable - and no public exploit was identified at time of analysis (the issue is not in CISA KEV).
RemediationAI
The decisive fix is to stop using the shipped default self-signed certificate: install a custom or CA-issued certificate in the web interface, which replaces the reused private key and invalidates any token signed with the known default key - this is the only mitigation that removes the root cause, but it requires a certificate/key installation step on every deployment and may briefly interrupt or restart the management interface. Note that simply re-issuing a new self-signed certificate generated from the same default key material is insufficient; the key itself must be new, and any JWTs issued before the change should be treated as suspect and sessions invalidated. The provided data does not include a vendor-published fixed version or remediated build, so no exact patch level can be cited; consult the Hitachi Vantara advisory referenced above for the official remediation and any available firmware or software update. Until the certificate can be replaced, restrict reachability of the management interface to a trusted management VLAN, VPN, or allowlisted administrative hosts via firewall/ACL rules, and monitor for anomalous administrative operations such as unexpected service reconfiguration or unsolicited log-collection requests - the trade-off is reduced administrative convenience and the need to keep an out-of-band access path, and this compensating control reduces exposure but does not eliminate the ability to forge tokens on a host that is still reachable and still using the default key.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability class is CWE-321 (Use of Hard-coded Cryptographic Key). The product's web interface signs its JWT session tokens with the private key of its TLS certificate; the same self-signed certificate is shipped identically on every deployment, so its private key is effectively public knowledge. Anyone who extracts that key from a default installation can construct JWTs with arbitrary claims - including administrative identity - that the server will accept as authentic, because it has no way to distinguish a token it signed from one forged with the shared key (the CVSS 4.0 VC:H/VI:H metrics reflect full loss of confidentiality and integrity within the vulnerable component, while the AT:P metric captures the prerequisite of the un-replaced default certificate). The assessed CVSS 3.1 equivalent is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, i.e., network-reachable and high-impact but only under that specific deployment configuration, and any host that has been re-keyed with a custom or CA-issued certificate is not exploitable because the attacker's copy of the default key would no longer validate.
Know when Hitachi Vantara gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Remote and unauthenticated (AV:N/PR:N/UI:N) but gated by the default-certificate precondition, mapping the 4.0 AT:P to AC:H; admin control gives C:H/I:H, no availability impact (A:N).
Primary rating from Vendor (hitachivantara).
CVSS VectorVendor: hitachivantara
DescriptionCVE.org
When the default self-signed certificate is used, an attacker could gain administrative access to the application.
The SSL certificate for the web interface is used to sign JWT access tokens that are used to validate that the user is logged in. When the default SSL certificate is used, an attacker could have the capability to sign JWT access tokens and bypass login.
An attacker could gain administrative access to the application and perform actions like configuring the service or requesting log collection. Device credentials and customer data cannot be accessed with this vulnerability.
Executive ViewAI
Hitachi Vantara deployments that still use the factory-default self-signed SSL certificate are exposed to unauthenticated attackers who can mint administrator-level JWT tokens, enabling unauthorized changes to service configurations or log collection. With no vendor-released patch identified at time of analysis and the vulnerability rated critical, leadership should treat this as a high-priority operational risk requiring immediate certificate remediation. Organizations that have already replaced default certificates are not affected, making detection and replacement the fastest path to risk reduction.
No public exploit identified at time of analysis. No vendor-released patch identified at time of analysis. Interim mitigations: replace the default self-signed SSL certificate with a unique certificate and regenerate JWT signing keys; restrict management interface access to trusted networks; monitor for unauthorized configuration changes or anomalous JWT issuance.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Hitachi Vantara
View allExternal XML entity resolution in Hitachi Vantara Pentaho Data Integration & Analytics lets an authenticated, low-privil
An authenticated administrator on Hitachi Vantara can retrieve password reset codes for arbitrary users through a privil
Script execution in Hitachi Vantara Pentaho Data Integration & Analytics allows an authenticated data-source administrat
Missing ACL enforcement on Hitachi Vantara Pentaho Data Integration & Analytics API endpoints allows authenticated low-p
Plaintext credential exposure in Hitachi Vantara Pentaho Data Integration & Analytics allows authenticated network users
EUVD-2026-101706
GHSA-3vfx-rq2g-mprf
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB