Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit crafted JPEG to multimodal image path
-
DeliveryHeader declares oversized dimensions
-
ExploitBuffer size computed without upper bound
-
ExecutionDecoder requests multi-gigabyte allocation
-
ImpactMemory exhaustion denies service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | The application must expose a code path that passes attacker-supplied JPEG data into the llm-multimodal component's jpeg_turbo::decode_jpeg_rgb function (e.g. an image-ingestion or multimodal inference endpoint accepting uploaded images). Per the CVSS vector exploitation is remote, unauthenticated (PR:N), and needs no user interaction (UI:N) against default handling of such images. What LIMITS impact: the consequence is availability-only (VA:L / A:L) memory exhaustion - there is no code execution, data disclosure, or integrity impact - and the pure-Rust fallback decoder already enforced a 512 MiB cap, so only the libjpeg-turbo decode path (where dimensions up to 65500×65500, ~12 GiB, are accepted) is affected by the unbounded allocation. The attacker needs a reachable path that actually decodes the malicious image for the bug to trigger. |
| Impact | This is a medium-severity denial-of-service issue, not a high-priority emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 and shows the flaw is remotely reachable with low complexity and no authentication or user interaction, but the impact metrics are narrow: VC:N and VI:N (no confidentiality or integrity impact) with only VA:L (low availability impact) - consistent with CWE-789 uncontrolled memory allocation causing resource exhaustion rather than code execution or data leakage. The exploit-maturity signal E:P (proof-of-concept) aligns with the input, which shows a public PoC reference (a GitHub gist) that is NOT verified as working exploit code. There is no CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_month', indicating routine-priority patching rather than act_now/emergency. The one tension worth flagging: the input Tags include 'Information Disclosure', which directly contradicts the CVSS (VC:N) and the CWE (uncontrolled allocation) - this is a DoS/availability bug, not disclosure. Net: a legitimately remote-reachable DoS in a specific image-decoding path, but low real-world urgency given availability-only impact, an unverified PoC, no KEV, and an obscure product footprint. |
| Exploit ScenarioDerived | An attacker submits a crafted JPEG whose header declares enormous pixel dimensions to any feature of the application that feeds images into the llm-multimodal decoder (jpeg_turbo::decode_jpeg_rgb). Because the code computed the RGB buffer size (width × height × 3) with only overflow checking and no upper bound, the decoder attempts a multi-gigabyte allocation, exhausting memory and denying service. A public PoC reference (gist) exists but is not verified as working exploit code; exploitation is remote and requires no authentication per the CVSS vector. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 25, 2026
Memory exhaustion in the llm-multimodal component of smg 1.7.0 through 1.10.1 allows a remote, unauthenticated attacker to exhaust server memory by supplying a JPEG whose header declares enormous dimensions (libjpeg-turbo accepts up to 65500x65500, roughly 12 GiB of RGB output). The libjpeg-turbo path in crates/multimodal/src/jpeg_turbo.rs sizes the decoded buffer with an unchecked width x height x 3 multiplication and applies no ceiling, while the pure-Rust fallback decoder was already bounded at 512 MiB, so only the turbo decode path is exposed. Impact is availability-only (medium severity; no code execution, integrity or confidentiality effect), a public PoC reference exists but is not verified as working exploit code, and vendor fixes are available in 1.11.0. This is a medium-severity denial-of-service issue, not a high-priority emergency.
RemediationAI
Upgrade smg to 1.11.0, which caps the decoded RGB buffer at 512 MiB via MAX_DECODED_BYTES and the new rgb_buffer_len helper (release https://github.com/smg-project/smg/releases/tag/v1.11.0, fix commit 8f51b57e219a914089e345b704c3c8de37a3bb8e, PR https://github.com/smg-project/smg/pull/2569); patch references are tagged as available from the vendor, and applying the commit back-ports the same one-constant change. Where upgrading must wait, the practical compensating controls are: reject or downscale uploaded JPEGs before they reach the multimodal ingestion path (for example enforce a maximum pixel-dimension and file-size check at the API boundary), which stops the oversized allocation but requires the validation to live in front of every decode call site; or build without the native TurboJPEG feature so decoding falls back to the image crate path that already enforces the 512 MiB limit - at the cost of slower pure-Rust decoding. Generic upstream request-body size limits alone do not help, because a tiny crafted JPEG header can declare a ~12 GiB frame, so the dimension check must key on decoded dimensions rather than payload bytes.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
smg's multimodal crate decodes JPEG images through two back ends: a pure-Rust decoder from the image crate, which already enforces a 512 MiB decoded-size limit, and a TurboJPEG/libjpeg-turbo binding in crates/multimodal/src/jpeg_turbo.rs used when the native library is present. In decode_jpeg_rgb the RGB buffer length is computed as width * height * 3 using checked_mul, which only guards against integer overflow, not against plausible-but-huge values: a header declaring 65500x65500 pixels - the largest size libjpeg-turbo will accept - passes the overflow check and drives an allocation of about 12 GiB. This is CWE-789 (Memory Allocation with Excessive Size Value): the allocation size is derived directly from attacker-controlled input without a maximum bound. The upstream fix (PR 2569, commit 8f51b57e219a914089e345b704c3c8de37a3bb8e) introduces a MAX_DECODED_BYTES constant of 512 MiB - deliberately matching the image crate default so both decode paths behave identically - and a helper rgb_buffer_len that chains checked_mul and filters the result against that cap, returning None for oversized buffers; a unit test asserts that 1024x768 passes while 65500x65500 and usize overflow cases are rejected. The trigger is not described beyond 'manipulation of the image data leads to uncontrolled memory allocation'; the demonstrated condition is a JPEG with extreme declared dimensions reaching this decode function.
Know when Smg gets its next vulnerability
- 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
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P
Remote, unauthenticated, low-complexity submission of a crafted image (AV:N/AC:L/PR:N/UI:N); impact is confined to partial availability via memory exhaustion (C:N/I:N/A:L), matching the vendor's VA:L.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
2DescriptionCVE.org
A vulnerability was identified in smg-project smg 1.7.0/1.8.0/1.9.0/1.10.0/1.10.1. Affected is the function jpeg_turbo::decode_jpeg_rgb of the file crates/multimodal/src/jpeg_turbo.rs of the component llm-multimodal. The manipulation leads to uncontrolled memory allocation. The attack can be initiated remotely. The exploit is publicly available and might be used. Upgrading to version 1.11.0 is able to address this issue. The identifier of the patch is 8f51b57e219a914089e345b704c3c8de37a3bb8e. It is advisable to upgrade the affected component.
Threat Intelligence Overview
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.
EUVD-2026-109575
GHSA-55xq-367r-px8q
NVD
CVE.org
EPSS
VulDB
Exploit-DB