{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-04-20T04:28:24.286","vulnerabilities":[{"cve":{"id":"CVE-2026-25998","sourceIdentifier":"security-advisories@github.com","published":"2026-02-19T17:24:50.127","lastModified":"2026-02-23T19:36:48.017","vulnStatus":"Analyzed","cveTags":[],"descriptions":[{"lang":"en","value":"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. 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."},{"lang":"es","value":"strongMan es una interfaz de gestión para strongSwan, una VPN de código abierto basada en IPsec. Al almacenar credenciales en la base de datos (claves privadas, secretos EAP), strongMan cifra los campos de la base de datos correspondientes. Hasta ahora utilizaba AES en modo CTR con una clave de base de datos global. Junto con un vector de inicialización (IV), se genera un flujo de claves para cifrar los datos en los campos de la base de datos. Pero debido a que strongMan no generaba IVs individuales, cada campo de la base de datos fue cifrado utilizando el mismo flujo de claves. Un atacante que tiene acceso a la base de datos puede usar esto para recuperar las credenciales cifradas. En particular, debido a que los certificados, que deben considerarse información pública, también son cifrados utilizando el mismo mecanismo, un atacante puede recuperar directamente una gran parte del flujo de claves, lo que les permite descifrar básicamente todos los demás secretos, especialmente las claves privadas ECDSA y los secretos EAP, que suelen ser mucho más cortos. La versión 0.2.0 soluciona el problema al cambiar al cifrado AES-GCM-SIV con un nonce aleatorio y una clave de cifrado derivada individualmente, utilizando HKDF, para cada valor cifrado. Se proporcionan migraciones de base de datos para volver a cifrar automáticamente todas las credenciales."}],"metrics":{"cvssMetricV40":[{"source":"security-advisories@github.com","type":"Secondary","cvssData":{"version":"4.0","vectorString":"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:X","baseScore":8.7,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"NONE","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"NONE","availabilityImpact":"NONE"},"exploitabilityScore":3.9,"impactScore":3.6}]},"weaknesses":[{"source":"security-advisories@github.com","type":"Primary","description":[{"lang":"en","value":"CWE-323"},{"lang":"en","value":"CWE-1204"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:a:strongswan:strongman:0.1.0:*:*:*:*:python:*:*","matchCriteriaId":"92188FAE-6D6C-483E-B5BD-4E0EE4743F6F"}]}]}],"references":[{"url":"https://github.com/strongswan/strongMan/security/advisories/GHSA-88w4-jv97-c8xr","source":"security-advisories@github.com","tags":["Vendor Advisory"]}]}}]}