GCVE-1988-2026-0489
Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
EPSS
VEX
Title
[0day-rubbish] PacsOne Server 7.3.9 authenticated DICOMweb STOW-RS SOP Instance UID path traversal to www-data code execution on a PACS host (7.2)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in PacsOne
Server 7.3.9, Premium Edition, Linux x86-64 distribution, the closed-source
commercial PACS (medical imaging archive and DICOM server) from RainbowFish
Software, California, United States. The product combines a native C++ DICOM
and HL7 service with a PHP web interface of 204 endpoints running on MySQL
and Apache, fronted by a single Apache alias that maps /pacsone to the
product's php/ directory.
Type: path traversal on a file-write sink (CWE-22 primary; CWE-73 External
Control of File Name or Path and CWE-20 Improper Input Validation
contributing). The DICOMweb STOW-RS handler stowrs.php reads the SOP Instance
UID attribute (0008,0018) out of the posted DICOM object and uses it as the
storage filename. In import() in dicomweb.php, approximately lines
1391-1440, the construction is:
$uid = $rawTags->getAttr(0x00080018);
$dir = dirname($tempfile);
$newfile = $dir . "/" . $uid;
rename($tempfile, $newfile);
$dir is the per-day study directory under the configured archive root, from
getStowRsStoreDir() in database.php:1780; $tempfile is staged in that same
directory by DicomWebStow::__construct (dicomweb.php:1165), which reads the raw
body from php://input, splits it on the declared boundary and writes each
application/dicom part through tempnam() and file_put_contents(); and $uid is
the raw attribute value as it appeared on the wire: RawTags::getAttr()
(dicom.php:4516) returns it unfiltered, and the Explicit VR parser
parseDataExplicit() (dicom.php:4378) applies trim() only, which is VR padding
normalisation and not a security control. The presence checks in store()
(dicomweb.php:1592) verify only that
the SOP Class, SOP Instance, Study and Series Instance UIDs are non-empty,
which any non-empty string satisfies. There is no character whitelist, no
canonicalisation, no length bound and no containment check on this path, so a
SOP Instance UID of ../../../php/x.php moves the received object out of the
study directory and into the directory Apache serves through the /pacsone
alias. The 128-byte DICOM Part 10 preamble is never interpreted by the DICOM
parser, so it can carry a PHP marker script, and once the file is in the
served tree mod_php executes it under the web server identity.
The identity reached is uid=33(www-data) gid=33(www-data)
groups=33(www-data) - the Apache worker serving the request, confirmed by id,
whoami, a read of /etc/passwd, a marker write-and-read under /tmp, hostname
and uname. There is no child process and no identity change in this chain.
Root was not reached and is not claimed; no privilege escalation, no
container or host escape, and no contact with any other machine was
attempted.
The ordering inside import() decides both whether the write is usable and
whether a reproduction appears to work. rename() executes BEFORE the database
inserts, so no database-layer control - schema constraint, length limit,
uniqueness check - sits upstream of the damage, and the operation is not
transactional: the file lands even when the corresponding study record never
does. Each of the image, series, study and patient inserts is followed on
failure by unlink($newfile), so a minimal DICOM object writes the payload and
then deletes it, returning HTTP 409 with failure reason 272 (ProcessingFailure).
Making all four inserts succeed requires Patient Name (0010,0010), Patient ID
(0010,0020) and the pixel attributes (0028,xxxx). Anyone attempting a
reproduction without those attributes will watch the file disappear and may
conclude this is a false positive. It is not.
The root cause is an asymmetry rather than a general absence of input
validation. The product contains a UID validator, isUidValid(), and does call
it on the unauthenticated wadoAnonymized.php read path, where its character
whitelist blocks "/" and therefore blocks traversal. The store path that turns
a UID into a filename never calls it. Two details narrow where a fix has to
go: the server uses the dataset value and not the file meta header value, so
a validator bolted onto the meta header parse alone would miss this (the
verified object carried an ordinary dotted UID in (0002,0003) and the
traversal in (0008,0018)); and the parser is structurally lenient - it
accepted a (0028,xxxx) group emitted in non-ascending order - so leniency
cannot be relied on to reject malformed identifiers either.
How confirmation works. The STOW-RS JSON response echoes the identifier back,
so the outcome is machine-readable without any filesystem access: the nested
sequence carries (0008,1155) with the traversal string verbatim plus a
per-instance Retrieve URL in which it appears percent-encoded, a success
arrives as HTTP 200 and a failure as HTTP 409 with failure reason 272. That
makes the one deployment-variable quantity - how many ../ components separate
the study directory from a served directory - cheap to enumerate with clear
feedback and one request per guess, which is why Attack Complexity is rated
Low. Three components on the layout we configured; Setup.exe lets the
operator choose the archive directory, so another installation needs a
different count. The target directory has to satisfy only two conditions: the
web server user can write into it, and something served by the web server
executes files there. Relocating the archive outside the web tree is therefore
hardening rather than a fix. We did not reconcile this build's use of
(0008,1199) for the successful-store sequence against the DICOM PS3.18
STOW-RS response definition, and nothing in the finding depends on that tag
numbering. Execution is then confirmed by an unauthenticated GET for the
written file: the gate protects the store operation, not the file the store
operation created. The response body begins with the command's stdout and is
followed by the binary remainder of the DICOM object rendered as literal
output, which is itself evidence that the whole object, preamble included, was
written intact. The file on disk was 580 bytes - the size of the object sent -
owned by the web server identity at mode 0600. That mode is what tempnam()
creates and rename() preserved; it does not obstruct execution, because the
writer, the owner and the interpreter are the same uid.
What was deliberately not reproduced: the rename()/unlink() pairing on the
failure branch, which is argued from POSIX rename() atomic-replace semantics
and from the shipped code rather than exercised. Because unlink($newfile)
operates on the same attacker-chosen path, a deliberately failing store can
replace and then remove an existing file that the web server user can write.
The primitive is then not only "write an attacker-chosen file" but also
"replace and then delete a file whose name the attacker chooses, inside any
directory the web server user can write". No procedure for it is published and
the PoC refuses to target any path that already resolves. No denial-of-service
test was performed either.
Scoring. The published score is 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H.
PR:H is load-bearing: only an administrator-role account was demonstrated to
reach the DICOMweb STOW-RS route. hasaccess() in database.php:315 evaluates
isAdministrator() first, which returns true unconditionally for the
administrator group, and for everyone else selects the stowrs column of the
privilege table; the privilege table on the tested installation held exactly
one row, that administrator, with stowrs=1. No lower-privileged role was
demonstrated or documented to hold stowrs. The vector's arithmetic: ISS
0.914816, Impact(S:U) 5.873119, Exploitability 1.234708, unrounded base
7.107826, taken to 7.2 by the CVSS ceiling-to-tenth Roundup - which is why a
calculator reporting 7.1 is disagreeing with the rounding rule, not with the
score. For the record, no numeric CVSS value accompanied the verification
evidence gathered for this finding (that evidence recorded its type,
authentication requirement and achieved identity), so 7.2 is derived here from
the vector rather than copied from a recorded figure, and there is no
recorded-versus-computed discrepancy to correct.
One conditional reading is published alongside it and is never the headline.
In a deployment that grants the stowrs permission to a non-administrator
account - the realistic shapes being an acquisition device such as a modality
or scanner workstation, a partner PACS federated to the archive, or an imaging
application service account, all of which is what a DICOMweb store interface
exists to serve - the least privileged principal reaching the sink is a
low-privileged user and the honest rating for that deployment is 8.8 High,
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, Exploitability 2.835255 and
unrounded base 8.708373. We did not demonstrate that any non-administrator
account can be granted stowrs through the product and found no code path that
grants it to one, so this reading is conditional on a deployment state we did
not prove. An operator can establish which reading applies to them with one
query against the privilege table.
Two readings were considered and rejected, published with their arithmetic for
transparency. S:C would compute to 9.1 (Impact(S:C) 6.128026, Exploitability
2.286496, unrounded 9.087684) and is rejected: the PHP interpreter that
executes the payload is part of the same product serving the vulnerable
endpoint, on the same host, under the same service identity, and our traversal
target was inside the product's own served directory, so no second component
with an independent authorization boundary was crossed and no cross-account or
cross-machine outcome was demonstrated. A third argument for S:C is tempting
and still wrong in CVSS terms - that the victim of the confidentiality impact
is the patient whose imaging is stored, who is certainly not the principal
that authenticated - because scope concerns which component's authorization
boundary is crossed, not who suffers the consequence. The clinical weight of
that data is carried by the impact metrics, all three High. AC:H would compute
to 6.6 (unrounded 6.578666) and is rejected because the traversal depth is
discoverable with observable feedback at a cost of one request per guess. We
publish no PR:N vector: no unauthenticated path to this sink exists. The
bypass-file branch in the STOW-RS code path, which accepts fixed wado
credentials when a referenced file is present, is dead code on a default
installation because that file does not exist; we did not create it, we attach
no rating to a state the product does not ship, and we recommend the branch be
deleted.
Authentication: post-authentication, and the gate was tested by behaviour
rather than trusted from configuration. The performed negative control is a
persistence differential: two requests to the same endpoint with the same
account and the same object layout, differing only in whether Patient Name and
Patient ID were present. The incomplete object produced HTTP 409 and left
nothing in the served directory, having been removed by the failure branch's
unlink(); the complete object produced HTTP 200 and left a 580-byte file at
exactly the location the UID named. That establishes both that the file's
presence is a consequence of the store path completing and that its location
is the UID, since nothing else in the request specified a directory; it also
excludes mishandling of the temporary file, which tempnam() creates inside the
study directory and which would never appear in the served PHP tree on its
own. A third control comes from a sibling endpoint and was observed: UID-shaped
attacker input on the unauthenticated wadoAnonymized.php path passes through
isUidValid(), whose whitelist contains no "/", so the same input class validated
does not traverse and unvalidated does.
A fourth control is shipped but was not executed, and we say so plainly. The
published PoC carries a conforming-UID control mode that send
Severity
No CVSS data available.
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| unknown | PacsOne Server |
Affected:
unknown
|
guessed |
Relationships
analysis
GCVE-1988-2026-0489 (this record)
- possibly related CVE-2018-25124
{
"containers": {
"cna": {
"affected": [
{
"product": "PacsOne Server",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "disclosure via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "0day Rubbish Research Team is publicly disclosing a vulnerability in PacsOne\nServer 7.3.9, Premium Edition, Linux x86-64 distribution, the closed-source\ncommercial PACS (medical imaging archive and DICOM server) from RainbowFish\nSoftware, California, United States. The product combines a native C++ DICOM\nand HL7 service with a PHP web interface of 204 endpoints running on MySQL\nand Apache, fronted by a single Apache alias that maps /pacsone to the\nproduct\u0027s php/ directory.\n\nType: path traversal on a file-write sink (CWE-22 primary; CWE-73 External\nControl of File Name or Path and CWE-20 Improper Input Validation\ncontributing). The DICOMweb STOW-RS handler stowrs.php reads the SOP Instance\nUID attribute (0008,0018) out of the posted DICOM object and uses it as the\nstorage filename. In import() in dicomweb.php, approximately lines\n1391-1440, the construction is:\n\n $uid = $rawTags-\u003egetAttr(0x00080018);\n $dir = dirname($tempfile);\n $newfile = $dir . \"/\" . $uid;\n rename($tempfile, $newfile);\n\n$dir is the per-day study directory under the configured archive root, from\ngetStowRsStoreDir() in database.php:1780; $tempfile is staged in that same\ndirectory by DicomWebStow::__construct (dicomweb.php:1165), which reads the raw\nbody from php://input, splits it on the declared boundary and writes each\napplication/dicom part through tempnam() and file_put_contents(); and $uid is\nthe raw attribute value as it appeared on the wire: RawTags::getAttr()\n(dicom.php:4516) returns it unfiltered, and the Explicit VR parser\nparseDataExplicit() (dicom.php:4378) applies trim() only, which is VR padding\nnormalisation and not a security control. The presence checks in store()\n(dicomweb.php:1592) verify only that\nthe SOP Class, SOP Instance, Study and Series Instance UIDs are non-empty,\nwhich any non-empty string satisfies. There is no character whitelist, no\ncanonicalisation, no length bound and no containment check on this path, so a\nSOP Instance UID of ../../../php/x.php moves the received object out of the\nstudy directory and into the directory Apache serves through the /pacsone\nalias. The 128-byte DICOM Part 10 preamble is never interpreted by the DICOM\nparser, so it can carry a PHP marker script, and once the file is in the\nserved tree mod_php executes it under the web server identity.\n\nThe identity reached is uid=33(www-data) gid=33(www-data)\ngroups=33(www-data) - the Apache worker serving the request, confirmed by id,\nwhoami, a read of /etc/passwd, a marker write-and-read under /tmp, hostname\nand uname. There is no child process and no identity change in this chain.\nRoot was not reached and is not claimed; no privilege escalation, no\ncontainer or host escape, and no contact with any other machine was\nattempted.\n\nThe ordering inside import() decides both whether the write is usable and\nwhether a reproduction appears to work. rename() executes BEFORE the database\ninserts, so no database-layer control - schema constraint, length limit,\nuniqueness check - sits upstream of the damage, and the operation is not\ntransactional: the file lands even when the corresponding study record never\ndoes. Each of the image, series, study and patient inserts is followed on\nfailure by unlink($newfile), so a minimal DICOM object writes the payload and\nthen deletes it, returning HTTP 409 with failure reason 272 (ProcessingFailure).\nMaking all four inserts succeed requires Patient Name (0010,0010), Patient ID\n(0010,0020) and the pixel attributes (0028,xxxx). Anyone attempting a\nreproduction without those attributes will watch the file disappear and may\nconclude this is a false positive. It is not.\n\nThe root cause is an asymmetry rather than a general absence of input\nvalidation. The product contains a UID validator, isUidValid(), and does call\nit on the unauthenticated wadoAnonymized.php read path, where its character\nwhitelist blocks \"/\" and therefore blocks traversal. The store path that turns\na UID into a filename never calls it. Two details narrow where a fix has to\ngo: the server uses the dataset value and not the file meta header value, so\na validator bolted onto the meta header parse alone would miss this (the\nverified object carried an ordinary dotted UID in (0002,0003) and the\ntraversal in (0008,0018)); and the parser is structurally lenient - it\naccepted a (0028,xxxx) group emitted in non-ascending order - so leniency\ncannot be relied on to reject malformed identifiers either.\n\nHow confirmation works. The STOW-RS JSON response echoes the identifier back,\nso the outcome is machine-readable without any filesystem access: the nested\nsequence carries (0008,1155) with the traversal string verbatim plus a\nper-instance Retrieve URL in which it appears percent-encoded, a success\narrives as HTTP 200 and a failure as HTTP 409 with failure reason 272. That\nmakes the one deployment-variable quantity - how many ../ components separate\nthe study directory from a served directory - cheap to enumerate with clear\nfeedback and one request per guess, which is why Attack Complexity is rated\nLow. Three components on the layout we configured; Setup.exe lets the\noperator choose the archive directory, so another installation needs a\ndifferent count. The target directory has to satisfy only two conditions: the\nweb server user can write into it, and something served by the web server\nexecutes files there. Relocating the archive outside the web tree is therefore\nhardening rather than a fix. We did not reconcile this build\u0027s use of\n(0008,1199) for the successful-store sequence against the DICOM PS3.18\nSTOW-RS response definition, and nothing in the finding depends on that tag\nnumbering. Execution is then confirmed by an unauthenticated GET for the\nwritten file: the gate protects the store operation, not the file the store\noperation created. The response body begins with the command\u0027s stdout and is\nfollowed by the binary remainder of the DICOM object rendered as literal\noutput, which is itself evidence that the whole object, preamble included, was\nwritten intact. The file on disk was 580 bytes - the size of the object sent -\nowned by the web server identity at mode 0600. That mode is what tempnam()\ncreates and rename() preserved; it does not obstruct execution, because the\nwriter, the owner and the interpreter are the same uid.\n\nWhat was deliberately not reproduced: the rename()/unlink() pairing on the\nfailure branch, which is argued from POSIX rename() atomic-replace semantics\nand from the shipped code rather than exercised. Because unlink($newfile)\noperates on the same attacker-chosen path, a deliberately failing store can\nreplace and then remove an existing file that the web server user can write.\nThe primitive is then not only \"write an attacker-chosen file\" but also\n\"replace and then delete a file whose name the attacker chooses, inside any\ndirectory the web server user can write\". No procedure for it is published and\nthe PoC refuses to target any path that already resolves. No denial-of-service\ntest was performed either.\n\nScoring. The published score is 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H.\nPR:H is load-bearing: only an administrator-role account was demonstrated to\nreach the DICOMweb STOW-RS route. hasaccess() in database.php:315 evaluates\nisAdministrator() first, which returns true unconditionally for the\nadministrator group, and for everyone else selects the stowrs column of the\nprivilege table; the privilege table on the tested installation held exactly\none row, that administrator, with stowrs=1. No lower-privileged role was\ndemonstrated or documented to hold stowrs. The vector\u0027s arithmetic: ISS\n0.914816, Impact(S:U) 5.873119, Exploitability 1.234708, unrounded base\n7.107826, taken to 7.2 by the CVSS ceiling-to-tenth Roundup - which is why a\ncalculator reporting 7.1 is disagreeing with the rounding rule, not with the\nscore. For the record, no numeric CVSS value accompanied the verification\nevidence gathered for this finding (that evidence recorded its type,\nauthentication requirement and achieved identity), so 7.2 is derived here from\nthe vector rather than copied from a recorded figure, and there is no\nrecorded-versus-computed discrepancy to correct.\n\nOne conditional reading is published alongside it and is never the headline.\nIn a deployment that grants the stowrs permission to a non-administrator\naccount - the realistic shapes being an acquisition device such as a modality\nor scanner workstation, a partner PACS federated to the archive, or an imaging\napplication service account, all of which is what a DICOMweb store interface\nexists to serve - the least privileged principal reaching the sink is a\nlow-privileged user and the honest rating for that deployment is 8.8 High,\nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, Exploitability 2.835255 and\nunrounded base 8.708373. We did not demonstrate that any non-administrator\naccount can be granted stowrs through the product and found no code path that\ngrants it to one, so this reading is conditional on a deployment state we did\nnot prove. An operator can establish which reading applies to them with one\nquery against the privilege table.\n\nTwo readings were considered and rejected, published with their arithmetic for\ntransparency. S:C would compute to 9.1 (Impact(S:C) 6.128026, Exploitability\n2.286496, unrounded 9.087684) and is rejected: the PHP interpreter that\nexecutes the payload is part of the same product serving the vulnerable\nendpoint, on the same host, under the same service identity, and our traversal\ntarget was inside the product\u0027s own served directory, so no second component\nwith an independent authorization boundary was crossed and no cross-account or\ncross-machine outcome was demonstrated. A third argument for S:C is tempting\nand still wrong in CVSS terms - that the victim of the confidentiality impact\nis the patient whose imaging is stored, who is certainly not the principal\nthat authenticated - because scope concerns which component\u0027s authorization\nboundary is crossed, not who suffers the consequence. The clinical weight of\nthat data is carried by the impact metrics, all three High. AC:H would compute\nto 6.6 (unrounded 6.578666) and is rejected because the traversal depth is\ndiscoverable with observable feedback at a cost of one request per guess. We\npublish no PR:N vector: no unauthenticated path to this sink exists. The\nbypass-file branch in the STOW-RS code path, which accepts fixed wado\ncredentials when a referenced file is present, is dead code on a default\ninstallation because that file does not exist; we did not create it, we attach\nno rating to a state the product does not ship, and we recommend the branch be\ndeleted.\n\nAuthentication: post-authentication, and the gate was tested by behaviour\nrather than trusted from configuration. The performed negative control is a\npersistence differential: two requests to the same endpoint with the same\naccount and the same object layout, differing only in whether Patient Name and\nPatient ID were present. The incomplete object produced HTTP 409 and left\nnothing in the served directory, having been removed by the failure branch\u0027s\nunlink(); the complete object produced HTTP 200 and left a 580-byte file at\nexactly the location the UID named. That establishes both that the file\u0027s\npresence is a consequence of the store path completing and that its location\nis the UID, since nothing else in the request specified a directory; it also\nexcludes mishandling of the temporary file, which tempnam() creates inside the\nstudy directory and which would never appear in the served PHP tree on its\nown. A third control comes from a sibling endpoint and was observed: UID-shaped\nattacker input on the unauthenticated wadoAnonymized.php path passes through\nisUidValid(), whose whitelist contains no \"/\", so the same input class validated\ndoes not traverse and unvalidated does.\n\nA fourth control is shipped but was not executed, and we say so plainly. The\npublished PoC carries a conforming-UID control mode that send"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-22",
"description": "CWE-22",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-73",
"description": "CWE-73",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-02T07:30:02Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/18"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Oct/18"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/rainbowfish-pacsone-stowrs-sop-instance-uid-traversal-rce"
},
{
"url": "https://github.com/Exploit-Garbage/0day-Rubbish"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Oct/18"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] PacsOne Server 7.3.9 authenticated DICOMweb STOW-RS SOP Instance UID path traversal to www-data code execution on a PACS host (7.2)",
"x_gcve": [
{
"recordType": "analysis",
"relationships": [
{
"destId": "CVE-2018-25124",
"type": "possibly_related"
}
],
"vulnId": "GCVE-1988-2026-0489",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/18",
"automated": true,
"contentSha256": "7995b0839525b668ec4af50e8bce07a1e6503eae6d9016b9ed9fa9d6cf822398",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/18",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-10-13T02:22:16Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0489"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-11-02T07:30:02Z",
"dateUpdated": "2026-11-02T07:30:02Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0489"
},
"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
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.