CVE-2025-8696: ISC Stork · Excessive Memory Allocation
Affects ISC StorkSource CVE Database V5
Not known to be exploited · CVSS 7.5 High.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 39% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 10 Sep 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
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| ISC Stork | Affected
| Fixed in– |
AI-suggested
Organizations should implement strict input validation and size limits on data accepted by the Stork UI to prevent excessive memory allocation requests. Network-level controls such as rate limiting, web application firewalls (WAFs), and anomaly detection can help identify and block abnormal traffic patterns targeting the Stork interface. Segmentation of the Stork server from general user networks reduces exposure to unauthenticated attackers. Monitoring system resource usage and setting alerts for unusual spikes in memory or disk consumption can provide early warning of exploitation attempts. Until official patches are released, consider deploying temporary mitigations such as disabling or restricting access to the Stork UI from untrusted networks. Regularly review and update incident response plans to address potential denial of service scenarios involving critical monitoring infrastructure. Engage with ISC for updates on patches and apply them promptly once available.
Description
If an unauthenticated user sends a large amount of data to the Stork UI, it may cause memory and disk use problems for the system running the Stork server. This issue affects Stork versions 1.0.0 through 2.3.0.