CVE-2026-25998
Strongswan Strongman 0.1.0
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-25998 is a high-severity Reusing a Nonce, Key Pair in Encryption (CWE-323) vulnerability in Strongswan Strongman. Its CVSS base score is 8.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Weaken Encryption (T1600); ranked at the 23th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
strongMan, a management interface for strongSwan—an open-source IPsec-based VPN—contains a vulnerability in its credential storage mechanism (CVE-2026-25998). The affected component encrypts database fields storing private keys and EAP secrets using AES in CTR mode with a global database key and a fixed initialization vector (IV), resulting in the same key stream for every field. This reuse allows an attacker with database access to recover the key stream by exploiting publicly known certificates stored in the database, enabling decryption of other secrets.
An attacker who gains read access to the strongMan database can exploit this flaw without privileges (per CVSS 7.5: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). By analyzing encrypted certificates—which are public information—the attacker obtains a significant portion of the key stream. This directly facilitates decryption of shorter secrets, such as ECDSA private keys and EAP secrets, compromising VPN authentication and encryption capabilities.
The strongMan GitHub security advisory recommends upgrading to version 0.2.0, which addresses the issue by adopting AES-GCM-SIV encryption with a random nonce and an individually derived encryption key per value using HKDF. Database migrations are included to automatically re-encrypt all existing credentials. Details are available at https://github.com/strongswan/strongMan/security/advisories/GHSA-88w4-jv97-c8xr.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-8439
Vulnerability Data
strongMan is a management interface for strongSwan, an OpenSource IPsec-based VPN. When storing credentials in the database (private keys, EAP secrets), strongMan encrypts the corresponding database fields. So far it used AES in CTR mode with a global database key.…
more
Together with an initialization vector (IV), a key stream is generated to encrypt the data in the database fields. But because strongMan did not generate individual IVs, every database field was encrypted using the same key stream. An attacker that has access to the database can use this to recover the encrypted credentials. In particular, because certificates, which have to be considered public information, are also encrypted using the same mechanism, an attacker can directly recover a large chunk of the key stream, which allows them to decrypt basically all other secrets especially ECDSA private keys and EAP secrets, which are usually a lot shorter. Version 0.2.0 fixes the issue by switching to AES-GCM-SIV encryption with a random nonce and an individually derived encryption key, using HKDF, for each encrypted value. Database migrations are provided to automatically re-encrypt all credentials.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 6 hardening rules · 3 OS baselines
V6.8.3V11.6.1V11.3.4
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover nonce reuse through static analysis, fuzzing, or known-answer tests.
Engineering principles include correct use of cryptographic primitives such as unique nonces per key.
Selecting and implementing appropriate cryptographic algorithms and modes reduces nonce-reuse exposure.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent nonce/key reuse errors in cryptographic implementations.
Proper encryption of data-at-rest requires cryptographically sound IV generation.
Proper encryption of data-in-transit requires cryptographically sound IV generation.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Mandates proper cryptographic key and nonce management, directly preventing nonce/key-pair reuse.
Security testing can detect nonce reuse, yet the control addresses many other issues beyond this CWE.
Secure SDLC processes can embed cryptographic standards and reviews that catch weak IV generation.
Application security requirements can specify cryptographic standards including IV uniqueness and unpredictability.
Secure-coding rules can require unique nonces, but the control is broader than this single weakness.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (1 rule)
- V-248524 OL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-1204
RHEL 7 (1 rule)
- V-204497 The Red Hat Enterprise Linux operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-1204
RHEL 8 (1 rule)
- V-230223 RHEL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-1204