CVE-2025-25566: SoftEtherVPN · Memory Leak
Source CVE Database V5
Not known to be exploited · CVSS 5.6 Medium.
Data as of 26 Oct 2026, 09:15 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 24% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 12 Mar 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
1. Monitor memory usage of SoftEtherVPN instances closely, especially on Unix/Linux systems, to detect abnormal increases that may indicate exploitation of the memory leak. 2. Limit exposure of the SoftEtherVPN command-line tools to untrusted users or networks, as the vulnerability is triggered via command-line operations. 3. Implement strict network segmentation and firewall rules to restrict access to VPN management interfaces. 4. 5. Employ resource limits (e.g., cgroups or ulimit on Linux) to constrain memory usage of the VPN process, preventing system-wide impact from leaks. 6. Consider alternative VPN solutions or versions if the risk is unacceptable and no timely patch is available. 7. Conduct penetration testing and vulnerability assessments focusing on VPN infrastructure to identify potential exploitation paths. 8. Maintain incident response readiness to quickly address any denial of service or service degradation events related to VPN availability.
Description
Memory Leak vulnerability in SoftEtherVPN 5.02.5187 allows an attacker to cause a denial of service via the UnixMemoryAlloc function. NOTE: the Supplier disputes this because the behavior is limited to a single allocation of a few hundred bytes with a command-line tool.