EUVD-2026-85909
GHSA-3qj9-89fg-m5cw
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft YAML with huge empty-line block scalar
-
DeliverySubmit to app parsing with libfyaml
-
Exploitalloca() called per line in fy_atom_iter_format loop
-
ExecutionCumulative stack growth exceeds limit
-
ImpactSIGSEGV crashes parsing process (DoS)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires that an application built against libfyaml 0.9.6 parses an attacker-influenced YAML document containing a literal or folded block scalar with a large run of empty (blank) lines - the exact input pattern that drives the per-line alloca() growth in fy_atom_iter_format(). No authentication, privileges, or special library configuration are needed (PR:N), but exploitation depends on the consuming application actually accepting untrusted YAML as input (UI:R); deployments that parse only trusted, local configuration files are not practically exposed, and the impact is limited to crashing the single parsing process. |
| Impact | This is a genuine but low-priority denial-of-service issue. The signals are internally consistent and point to modest real-world risk: EPSS is 0.15% (4th percentile), there is no CISA KEV listing, and no public exploit code is referenced - only the upstream fix commits and the GitHub issue (#315). The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 6.5) is coherent with the description: no confidentiality or integrity impact, availability-only, and UI:R reflects that a victim application must be induced to parse an attacker-supplied YAML document. The impact is bounded to a crash (SIGSEGV) of the single process performing the parse - there is no scope change (S:U) and no memory-corruption/code-execution primitive, since the fix simply moves an in-loop alloca() buffer to the heap. The one nuance worth verifying is attack vector: AV:N is only realistic when the consuming application ingests untrusted YAML from a network source; for tools that parse only local/trusted config files the practical vector is local and the severity drops. No conflicting data was found - the CVSS, EPSS, and root-cause evidence all agree this is a low-severity availability bug. |
| Exploit ScenarioDerived | An attacker submits a YAML document containing a literal or folded block scalar with a very long run of empty lines to an application that parses untrusted input with libfyaml 0.9.6. As fy_atom_iter_format() processes each pending line break it calls alloca() again inside the per-line loop without releasing prior allocations, so stack usage grows cumulatively until it exceeds the process stack limit and the parser crashes with SIGSEGV. No public exploit code is identified, but the upstream regression test (block_scalar_many_empty_lines, 4096 empty lines) effectively demonstrates the trigger. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
Stack exhaustion in libfyaml 0.9.6 allows a crafted YAML document to crash the process that parses it, producing a denial of service. When fy_atom_iter_format() formats a literal or folded block scalar containing a long run of blank lines, it repeatedly calls alloca() inside a per-line loop; because alloca() memory is only reclaimed when the function returns, the stack grows cumulatively until the process stack limit is exceeded and SIGSEGV occurs. Exploitation is unauthenticated but requires user/application interaction (UI:R) - the target application must actually parse attacker-influenced YAML - and impact is limited to the single parsing process. No public exploit code has been identified at time of analysis, EPSS is low at 0.15% (4th percentile), and the upstream project has published fixing commits referenced from issue #315.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply the fixes in libfyaml commits 20502068902d58c076da873117985798df2c7e74 and 93741a7c9331da9da65ef7a25f2d7d6a817a1c29 (referenced from https://github.com/pantoniou/libfyaml/issues/315), which replace the in-loop alloca() with a 16-entry in-place array plus realloc()-backed heap growth, or upgrade to a downstream release that incorporates them. If rebuilding is not immediately possible, the most effective compensating control is to bound what reaches the parser: enforce a maximum size and a maximum number of consecutive blank lines on any YAML input accepted from untrusted sources before it is handed to libfyaml, rejecting oversized documents at the application boundary - the trade-off is that legitimate large documents with long block scalars will also be refused, so the limit must be tuned to real workloads. Running the parsing step in a separate, short-lived child process with a reduced stack limit (for example ulimit -s) or inside a memory- and stack-capped sandbox will convert the SIGSEGV into an isolated child failure rather than a service crash, at the cost of added process-management overhead and possible loss of the in-flight request. Where untrusted YAML parsing is not actually needed, disable that input path entirely or restrict it to trusted, locally authored configuration files; note that the crash affects only the parsing process, so no data loss or code execution follows the exception. Monitor the vendor repository and your distribution's advisory channel for a tagged release containing the fix, since no fixed version number is confirmed in the available data.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
libfyaml is a C library for parsing and emitting YAML, and the flaw lives in src/lib/fy-atom.c in fy_atom_iter_format(), the routine that renders scalar atoms (including literal '|' and folded '>' block scalars) back into text. The function maintains a dynamically sized array of pending line-break records, and the vulnerable code grew that array with alloca(sizeof(*pending_lb) * pending_lb_size * 2) from inside a per-line loop that runs once for each empty line in the block scalar. alloca() allocates from the current stack frame and is not released until the enclosing function returns, so each iteration permanently consumed stack rather than reusing a single allocation - an unbounded resource consumption pattern classified as CWE-770 (Allocation of Resources Without Limits or Throttling). A sufficiently long run of blank lines therefore grows the stack past the process limit and triggers SIGSEGV during parsing. The upstream fix removes alloca() from the loop, starting with a 16-entry in-place array and switching to a heap buffer via realloc() when the array outgrows it, freeing the heap block before the function exits; the accompanying regression test (test/libfyaml-test-core.c, block_scalar_many_empty_lines) uses 4096 empty lines, well past the 16-entry in-place threshold, confirming the growth path. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H reflects a network-reachable, low-complexity, unauthenticated input-triggered crash with high availability impact confined to the vulnerable component (S:U) and no confidentiality or integrity effect.
Know when the next one hits your stack
- 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
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Availability-only crash of the parsing process (A:H, C:N/I:N, S:U); network-reachable via untrusted YAML but requires the app to ingest the document (UI:R), no auth (PR:N).
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
2DescriptionCVE.org
libfyaml 0.9.6 contains a stack exhaustion vulnerability in fy_atom_iter_format(). When processing a specially crafted YAML document containing a very large literal or folded block scalar, the function repeatedly grows an internal buffer using alloca() inside a loop. The allocated stack memory is not released until the function returns, causing cumulative stack growth that can exceed the process stack limit and result in SIGSEGV and denial of service.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
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
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Exploit-DB