GCVE-1988-2026-0484
Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
EPSS
VEX
Title
[0day-rubbish] Auerswald COMmander 6000 / 6000R 8.6D unauthenticated provisioning import zip-slip to root binary hijack and root code execution (9.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in Auerswald
COMmander 6000 and COMmander 6000R, firmware 8.6D build 128154, the
closed-source enterprise IP-PBX and unified-communications appliances from
Auerswald (Germany). Two unauthenticated HTTP requests, carrying no cookie and
no credential of any kind, yield uid=0(root) gid=0(root) groups=0(root) on an
appliance that holds extension credentials, SIP trunk credentials, call detail
records and voicemail for every user it serves.
Type and root cause. CWE-22, path traversal in the zip-slip form, inside a
root archive extraction; CWE-73, CWE-434, CWE-862 and CWE-250 contribute. The
finding is explicitly not classified as CWE-78, and this is worth stating
because it changes the fix: no command string is injected at either hop, and
every argument to every observed execve is either a compile-time constant or a
value that passed the product's own whitelist legitimately. Escaping and
character whitelisting are already implemented correctly in this product. The
missing controls are archive containment and route authorization, and a
command-injection patch would close nothing.
The chain has two hops and both are needed. Hop 1 is the write primitive: the
unauthenticated route /provisioning_data_import stores one multipart/form-data
part at /data/provisioning/import/<basename> and then spawns, as root,
posix_spawn("../minizip/miniunz", "-o", "-x", <zip>, "-d",
"/data/provisioning/import/")
captured verbatim from the syscall trace of the product's own process. Neither
the application nor the bundled extractor inspects archive entry names, so an
entry named ../../../opt/auerswald/hping2 escapes the extraction directory and
overwrites a root-owned mode-0755 binary with attacker bytes. Because the write
truncates an existing file, the original permission bits survive and the result
is immediately executable; there is no separate chmod primitive and none is
needed. The -o flag is what makes the replacement silent, converting the
extractor's refuse-to-clobber default into clobber-without-prompt. Hop 2 is the
consumer: a second unauthenticated request to /netdiagnostic_execute makes root
run
/bin/sh -c "/opt/auerswald/hping2 -1 -I eth0 -c 3 <target> -p <port>"
The diagnostics handler validates the target argument against the charset
0-9A-Za-z.-:/ and that whitelist works as intended; what it cannot protect is
the bytes sitting at a path that appears as a compile-time constant in the
command. The kernel honours the attacker's #!/bin/sh shebang, and the payload's
stdout is captured into the HTTP response body, so the result is read back
directly and no out-of-band channel is involved. Both handlers live in the
vendor's own in-house FastCGI application, a 3,498,560-byte binary started by
init as root behind a stock lighttpd 1.4.64 on an ARM32 glibc embedded Linux
userland, which never drops privilege. The rootfs contains no suid or sgid
binary at all, so there is no privilege boundary between the web application
and the operating system.
How confirmation works. Request 1 is a multipart POST whose part name is equal
to the filename. That is the vendor's own client contract, recovered from the
shipped JavaScript, which appends the file object to a FormData under the
file's own name; requests built the conventional way with a fixed field name
are rejected by the application's parser, and that failure is indistinguishable
from "the server filters uploads" unless the client is read. Request 2 is an
ordinary urlencoded diagnostics POST. The payload echoes a run-unique token
plus the uid and user name to stdout, which the handler returns in the response
body, and appends the output of id to a marker file under /data/log. The
published advisory prints the identity string and the landing paths but
deliberately not the per-run token or a marker filename from a specific run,
since both are artefacts of one execution on one testbed.
What was deliberately not reproduced. No persistence was installed. The same
write primitive reaches the init-respawned service scripts under
/opt/auerswald/scripts/run-*, the lighttpd configuration and the web document
root; those targets are named as statically available so that a defender can
scope an incident, and none was fired. No configuration database, certificate,
private key, credential or call record was read or removed, and no destructive,
encrypting or exfiltrating payload is published. One elegant approach was tried
and does not work, which is recorded here because it is a reproduction trap:
overwriting the extractor itself so that the next import request executes the
payload. The slip write happens inside the currently executing extractor
process, the target file ends up zero bytes long, and the next invocation fails
with ENOEXEC. The doctrine that follows is to never overwrite a binary that is
executing the write.
A correction to our own earlier reading of this chain, published because it was
wrong and a maintainer could otherwise chase it. During this work we
hypothesised that the rejections of conventionally built uploads were caused by
the web server not spooling request bodies to an upload directory, rather than
by the part name. That hypothesis is withdrawn. mod_fastcgi forwards the body
to the backend over the FastCGI STDIN stream whether or not it spools to disk,
the application parses that stream itself, and once the part name matched the
filename the bytes were stored correctly on the first attempt. Nothing about
the web server configuration was blocking the upload, and a change that added
an upload directory directive would not have altered the outcome.
Scoring. One score is published: 9.8 Critical,
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The Impact Sub-Score is
1 - 0.44^3 = 0.914816, Impact under Scope Unchanged is 6.42 * 0.914816 =
5.873119, Exploitability is 8.22 * 0.85 * 0.77 * 0.85 * 0.85 = 3.887043, and
the sum 9.760162 rounds up to 9.8 under the CVSS ceiling-to-tenth rule.
An alternative reading is argued in the advisory and not adopted as the
headline: Scope Changed. A network-facing management service yielding host-wide
root on an appliance that also holds call records, extension credentials and a
managed phone fleet is the kind of outcome Scope Changed was written to
express, and AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H computes to 10.0 - the
Scope-Changed impact term is 6.128026, exploitability is unchanged at
3.887043, the sum times 1.08 exceeds the maximum and is capped. We publish
Scope Unchanged because of one fact: the application is already uid 0 by
design, and the rootfs contains no suid or sgid binary because the vendor's
design never needed one, so there is no authority boundary between the web
component and the telephony component for the chain to cross. It exercises,
through a defect, an authority the vulnerable component already held.
Publishing 10.0 would attribute a boundary crossing this product's architecture
does not have, and would obscure the more useful message to the maintainer: the
privilege separation that would make Scope Unchanged the comfortable answer is
itself a fix worth making.
AC:L is a decision, not a default. There is no race, no timing window, no
memory-layout dependency, no on-path position, no brute force and no dependency
on the hardware abstraction layer, and the chain was demonstrated twice, in the
freshly initialised state and again in a tightened state described below. The
one non-obvious requirement, the part-name-equals-filename contract, is
attacker-side correctness recoverable from the vendor's own shipped client
rather than an environmental condition. Amplifier facts observed elsewhere in
the image - an empty root password field in /etc/passwd with no /etc/shadow in
this image, the telnet facility behind an AccessLevel 6 route, a site-wide
unsafe-inline CSP, an unenforced client certificate on the provisioning socket -
are kept out of the arithmetic and reported separately, because folding them in
would inflate the vector. No CVSS figure was recorded alongside the
verification, so there is no recorded number for this vector to disagree with.
Authentication: none, and that is proven rather than assumed. Both routes are
declared AccessLevel 2 in the product's own route table and both answered 200
to a request carrying no Cookie header and no Authorization header, not an
expired session but no session material at all. The route table in .data holds
750 named entries, and the product's gate - one session and credential
evaluator at 0x15958, which is the sole caller of the access check at 0xf5d68 -
covers the service-technician family (AccessLevel 4), the DAA/daemon family
(AccessLevel 6), the two packet-capture routes registered under those families
and one login route: twelve of 750. The remaining 738 answer 200 to a
cookie-less request, and more than forty of them were sampled during mapping,
each returning live configuration data or performing a state change. lighttpd
contributes nothing to authorization: its FastCGI configuration sends every URL
to the backend socket, and three probes with no referer, with the ip-editor
referer and with an unrelated referer produced no access difference.
The strongest internal evidence that this is a systemic coverage gap rather than
two unlucky omissions sits on a single shared handler. FUNC 0x3b018, which
streams a packet capture back to the caller, is registered three times under
three names: ethernettrace.pcap at declared level 2 answers 200, starts a root
tcpdump on eth0 with snaplen 9018 and streams the capture to the requesting
client, while servicetrace.pcap at level 4 and daemontools.pcap at level 6 both
answer 401. Same function address, same code, opposite outcome, so
authorization in this product is attached to route families rather than to the
operations those routes expose.
What was not broken is credited explicitly. The login route is fail-closed:
four password values across four parameter alias sets each produced an empty
cookie. The vendor service-technician challenge is not forgeable from the image
because verification is public-key only, against two DER SubjectPublicKeyInfo
blobs shipped in the firmware, and the device holds no private key; the
response space is also only 65536 wide with a four-attempt lockout, so it is
not brute-forceable either. The ForceAdmin and BEARER branches of the session
evaluator were not read instruction by instruction, so no claim is made about
them in either direction - unexamined is not disproved, and this chain does not
depend on them. The declared AccessLevel value in the route table is not the
enforced level, and the product's own data proves it: the DAA login route is
recorded at level 0 and answers 401. We do not claim that all 738 unguarded
routes are individually dangerous; we map the population and prove the two
members this chain needs.
Impact: complete control of a device that terminates and records every call it
serves. Root here means the SIP stack, the voicemail and voice-mail
distribution components, the DSP channel configuration, trunk configuration and
every extension the appliance serves, so calls can be placed, redirected,
recorded or dropped. The configuration database under /data/db/ carries fields
including cryptPasswd, passwd, passwdLdap, AdminPasswd, AdminPasswdHash,
passwordHash and remote_access_token; user certificate private keys sit under
/data/certs/user-certs; SIP trunk and gateway credentials live in the
provisioning data; and toll fraud is the standard real-world monetisation of
exactly this position, usually discovered on an invoice rather than through a
security alert. Call detail records, billing structures and voicemail content
for every user become readable - who called whom, when, for how long and at what
cost - which for an organisation whose calls carry customer, legal, medical or
financial content is a reportable data-breach event. The appliance auto-provisi
Severity
No CVSS data available.
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Auerswald | COMmander 6000 |
Affected:
unknown
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"product": "COMmander 6000",
"vendor": "Auerswald",
"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 Auerswald\nCOMmander 6000 and COMmander 6000R, firmware 8.6D build 128154, the\nclosed-source enterprise IP-PBX and unified-communications appliances from\nAuerswald (Germany). Two unauthenticated HTTP requests, carrying no cookie and\nno credential of any kind, yield uid=0(root) gid=0(root) groups=0(root) on an\nappliance that holds extension credentials, SIP trunk credentials, call detail\nrecords and voicemail for every user it serves.\n\nType and root cause. CWE-22, path traversal in the zip-slip form, inside a\nroot archive extraction; CWE-73, CWE-434, CWE-862 and CWE-250 contribute. The\nfinding is explicitly not classified as CWE-78, and this is worth stating\nbecause it changes the fix: no command string is injected at either hop, and\nevery argument to every observed execve is either a compile-time constant or a\nvalue that passed the product\u0027s own whitelist legitimately. Escaping and\ncharacter whitelisting are already implemented correctly in this product. The\nmissing controls are archive containment and route authorization, and a\ncommand-injection patch would close nothing.\n\nThe chain has two hops and both are needed. Hop 1 is the write primitive: the\nunauthenticated route /provisioning_data_import stores one multipart/form-data\npart at /data/provisioning/import/\u003cbasename\u003e and then spawns, as root,\n\n posix_spawn(\"../minizip/miniunz\", \"-o\", \"-x\", \u003czip\u003e, \"-d\",\n \"/data/provisioning/import/\")\n\ncaptured verbatim from the syscall trace of the product\u0027s own process. Neither\nthe application nor the bundled extractor inspects archive entry names, so an\nentry named ../../../opt/auerswald/hping2 escapes the extraction directory and\noverwrites a root-owned mode-0755 binary with attacker bytes. Because the write\ntruncates an existing file, the original permission bits survive and the result\nis immediately executable; there is no separate chmod primitive and none is\nneeded. The -o flag is what makes the replacement silent, converting the\nextractor\u0027s refuse-to-clobber default into clobber-without-prompt. Hop 2 is the\nconsumer: a second unauthenticated request to /netdiagnostic_execute makes root\nrun\n\n /bin/sh -c \"/opt/auerswald/hping2 -1 -I eth0 -c 3 \u003ctarget\u003e -p \u003cport\u003e\"\n\nThe diagnostics handler validates the target argument against the charset\n0-9A-Za-z.-:/ and that whitelist works as intended; what it cannot protect is\nthe bytes sitting at a path that appears as a compile-time constant in the\ncommand. The kernel honours the attacker\u0027s #!/bin/sh shebang, and the payload\u0027s\nstdout is captured into the HTTP response body, so the result is read back\ndirectly and no out-of-band channel is involved. Both handlers live in the\nvendor\u0027s own in-house FastCGI application, a 3,498,560-byte binary started by\ninit as root behind a stock lighttpd 1.4.64 on an ARM32 glibc embedded Linux\nuserland, which never drops privilege. The rootfs contains no suid or sgid\nbinary at all, so there is no privilege boundary between the web application\nand the operating system.\n\nHow confirmation works. Request 1 is a multipart POST whose part name is equal\nto the filename. That is the vendor\u0027s own client contract, recovered from the\nshipped JavaScript, which appends the file object to a FormData under the\nfile\u0027s own name; requests built the conventional way with a fixed field name\nare rejected by the application\u0027s parser, and that failure is indistinguishable\nfrom \"the server filters uploads\" unless the client is read. Request 2 is an\nordinary urlencoded diagnostics POST. The payload echoes a run-unique token\nplus the uid and user name to stdout, which the handler returns in the response\nbody, and appends the output of id to a marker file under /data/log. The\npublished advisory prints the identity string and the landing paths but\ndeliberately not the per-run token or a marker filename from a specific run,\nsince both are artefacts of one execution on one testbed.\n\nWhat was deliberately not reproduced. No persistence was installed. The same\nwrite primitive reaches the init-respawned service scripts under\n/opt/auerswald/scripts/run-*, the lighttpd configuration and the web document\nroot; those targets are named as statically available so that a defender can\nscope an incident, and none was fired. No configuration database, certificate,\nprivate key, credential or call record was read or removed, and no destructive,\nencrypting or exfiltrating payload is published. One elegant approach was tried\nand does not work, which is recorded here because it is a reproduction trap:\noverwriting the extractor itself so that the next import request executes the\npayload. The slip write happens inside the currently executing extractor\nprocess, the target file ends up zero bytes long, and the next invocation fails\nwith ENOEXEC. The doctrine that follows is to never overwrite a binary that is\nexecuting the write.\n\nA correction to our own earlier reading of this chain, published because it was\nwrong and a maintainer could otherwise chase it. During this work we\nhypothesised that the rejections of conventionally built uploads were caused by\nthe web server not spooling request bodies to an upload directory, rather than\nby the part name. That hypothesis is withdrawn. mod_fastcgi forwards the body\nto the backend over the FastCGI STDIN stream whether or not it spools to disk,\nthe application parses that stream itself, and once the part name matched the\nfilename the bytes were stored correctly on the first attempt. Nothing about\nthe web server configuration was blocking the upload, and a change that added\nan upload directory directive would not have altered the outcome.\n\nScoring. One score is published: 9.8 Critical,\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The Impact Sub-Score is\n1 - 0.44^3 = 0.914816, Impact under Scope Unchanged is 6.42 * 0.914816 =\n5.873119, Exploitability is 8.22 * 0.85 * 0.77 * 0.85 * 0.85 = 3.887043, and\nthe sum 9.760162 rounds up to 9.8 under the CVSS ceiling-to-tenth rule.\n\nAn alternative reading is argued in the advisory and not adopted as the\nheadline: Scope Changed. A network-facing management service yielding host-wide\nroot on an appliance that also holds call records, extension credentials and a\nmanaged phone fleet is the kind of outcome Scope Changed was written to\nexpress, and AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H computes to 10.0 - the\nScope-Changed impact term is 6.128026, exploitability is unchanged at\n3.887043, the sum times 1.08 exceeds the maximum and is capped. We publish\nScope Unchanged because of one fact: the application is already uid 0 by\ndesign, and the rootfs contains no suid or sgid binary because the vendor\u0027s\ndesign never needed one, so there is no authority boundary between the web\ncomponent and the telephony component for the chain to cross. It exercises,\nthrough a defect, an authority the vulnerable component already held.\nPublishing 10.0 would attribute a boundary crossing this product\u0027s architecture\ndoes not have, and would obscure the more useful message to the maintainer: the\nprivilege separation that would make Scope Unchanged the comfortable answer is\nitself a fix worth making.\n\nAC:L is a decision, not a default. There is no race, no timing window, no\nmemory-layout dependency, no on-path position, no brute force and no dependency\non the hardware abstraction layer, and the chain was demonstrated twice, in the\nfreshly initialised state and again in a tightened state described below. The\none non-obvious requirement, the part-name-equals-filename contract, is\nattacker-side correctness recoverable from the vendor\u0027s own shipped client\nrather than an environmental condition. Amplifier facts observed elsewhere in\nthe image - an empty root password field in /etc/passwd with no /etc/shadow in\nthis image, the telnet facility behind an AccessLevel 6 route, a site-wide\nunsafe-inline CSP, an unenforced client certificate on the provisioning socket -\nare kept out of the arithmetic and reported separately, because folding them in\nwould inflate the vector. No CVSS figure was recorded alongside the\nverification, so there is no recorded number for this vector to disagree with.\n\nAuthentication: none, and that is proven rather than assumed. Both routes are\ndeclared AccessLevel 2 in the product\u0027s own route table and both answered 200\nto a request carrying no Cookie header and no Authorization header, not an\nexpired session but no session material at all. The route table in .data holds\n750 named entries, and the product\u0027s gate - one session and credential\nevaluator at 0x15958, which is the sole caller of the access check at 0xf5d68 -\ncovers the service-technician family (AccessLevel 4), the DAA/daemon family\n(AccessLevel 6), the two packet-capture routes registered under those families\nand one login route: twelve of 750. The remaining 738 answer 200 to a\ncookie-less request, and more than forty of them were sampled during mapping,\neach returning live configuration data or performing a state change. lighttpd\ncontributes nothing to authorization: its FastCGI configuration sends every URL\nto the backend socket, and three probes with no referer, with the ip-editor\nreferer and with an unrelated referer produced no access difference.\n\nThe strongest internal evidence that this is a systemic coverage gap rather than\ntwo unlucky omissions sits on a single shared handler. FUNC 0x3b018, which\nstreams a packet capture back to the caller, is registered three times under\nthree names: ethernettrace.pcap at declared level 2 answers 200, starts a root\ntcpdump on eth0 with snaplen 9018 and streams the capture to the requesting\nclient, while servicetrace.pcap at level 4 and daemontools.pcap at level 6 both\nanswer 401. Same function address, same code, opposite outcome, so\nauthorization in this product is attached to route families rather than to the\noperations those routes expose.\n\nWhat was not broken is credited explicitly. The login route is fail-closed:\nfour password values across four parameter alias sets each produced an empty\ncookie. The vendor service-technician challenge is not forgeable from the image\nbecause verification is public-key only, against two DER SubjectPublicKeyInfo\nblobs shipped in the firmware, and the device holds no private key; the\nresponse space is also only 65536 wide with a four-attempt lockout, so it is\nnot brute-forceable either. The ForceAdmin and BEARER branches of the session\nevaluator were not read instruction by instruction, so no claim is made about\nthem in either direction - unexamined is not disproved, and this chain does not\ndepend on them. The declared AccessLevel value in the route table is not the\nenforced level, and the product\u0027s own data proves it: the DAA login route is\nrecorded at level 0 and answers 401. We do not claim that all 738 unguarded\nroutes are individually dangerous; we map the population and prove the two\nmembers this chain needs.\n\nImpact: complete control of a device that terminates and records every call it\nserves. Root here means the SIP stack, the voicemail and voice-mail\ndistribution components, the DSP channel configuration, trunk configuration and\nevery extension the appliance serves, so calls can be placed, redirected,\nrecorded or dropped. The configuration database under /data/db/ carries fields\nincluding cryptPasswd, passwd, passwdLdap, AdminPasswd, AdminPasswdHash,\npasswordHash and remote_access_token; user certificate private keys sit under\n/data/certs/user-certs; SIP trunk and gateway credentials live in the\nprovisioning data; and toll fraud is the standard real-world monetisation of\nexactly this position, usually discovered on an invoice rather than through a\nsecurity alert. Call detail records, billing structures and voicemail content\nfor every user become readable - who called whom, when, for how long and at what\ncost - which for an organisation whose calls carry customer, legal, medical or\nfinancial content is a reportable data-breach event. The appliance auto-provisi"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-250",
"description": "CWE-250",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-434",
"description": "CWE-434",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-73",
"description": "CWE-73",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-78",
"description": "CWE-78",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-862",
"description": "CWE-862",
"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/13"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Oct/13"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/auerswald-commander-provisioning-import-zip-slip-binary-hijack-root-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/13"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] Auerswald COMmander 6000 / 6000R 8.6D unauthenticated provisioning import zip-slip to root binary hijack and root code execution (9.8)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0484",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/13",
"automated": true,
"contentSha256": "90bd32a60dddb6a9db5288e380d35f5af6a5104470c7f965934f14043fbd4bcf",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/13",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-10-13T02:21:03Z"
}
}
]
}
},
"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-0484"
},
"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.