CVE-2026-99009 (GCVE-0-2026-99009)
Vulnerability from cvelistv5 – Published: 2026-10-23 12:20 – Updated: 2026-10-23 12:20
VLAI
EPSS
VEX
Title
Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
Summary
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
An RFCOMM connect() issued while a BR/EDR link is being authenticated
makes lockdep report a circular dependency, and the reported cycle is a
real AB/BA between rfcomm_mutex and hdev->lock.
rfcomm_security_cfm() is called from the HCI event path, which already
holds hdev->lock:
hci_rx_work()
hci_event_packet()
hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]
while an RFCOMM connect() from userspace takes the same two locks the
other way round:
rfcomm_sock_connect()
rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open()
rfcomm_session_create()
kernel_connect()
l2cap_sock_connect()
l2cap_chan_connect() [hdev->lock]
WARNING: possible circular locking dependency detected
kworker/u131:1/1128 is trying to acquire lock:
rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
but task is already holding lock:
hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0
Chain exists of:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback
the same way.
Both orders have to be seen in the same boot, which is why a BR/EDR
connection alone is not enough to show it: a session set up by the
remote side is created by rfcomm_accept_connection() in krfcommd, which
calls kernel_accept() and never takes hdev->lock under rfcomm_mutex.
Connecting a device that authenticates and encrypts the link and then
calling connect() on an RFCOMM socket towards any address - the connect
does not have to succeed, the order is recorded before the page timeout
- reports it every time.
Only the session socket has to be connected with the lock held, and it
does not: nothing else can see the socket before it is put on the
session list. So connect it first and take rfcomm_mutex afterwards,
which removes the rfcomm_mutex -> hdev->lock order for good, rather
than keeping the HCI event path out of rfcomm_mutex.
rfcomm_session_create() becomes rfcomm_session_connect(), which returns
the connected socket without touching the session list, and
rfcomm_dlc_open() adds the session once it holds the lock again. If
another opener added a session for the same pair while this socket was
connecting, that session is used and this socket is dropped.
__rfcomm_dlc_open() now takes the session it should use, and its state
check runs after the lock is re-acquired, so a DLC that was opened or
closed in the meantime is still handled.
Over an existing ACL link the connection can complete before the
session reaches the list, and the wakeup from the socket callback is
then lost, so krfcommd is woken once the session is visible.
Connecting without the lock opens a window in which the socket can be
closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds
nothing to do and returns without touching it, and rfcomm_dlc_open()
would then attach a DLC whose owner is gone. rfcomm_dlc_close() now
marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the
mark once it holds rfcomm_mutex again and drops the socket instead of
attaching the DLC. The mark is cleared when an open starts, so a DLC
that is reused is not affected. This covers both callers of
rfcomm_dlc_open(), the socket and the tty layer.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
82425b14f0fb22e46cfddc56d6465570f5ed0ce6 , < 4dc3d5a004b8fd59f3c905631dbb18cb601b1b41
(git)
Affected: 1b7841ffad08e911e8c4b9470f3fa08423568940 , < d2206e8c78be69d21d4f5343c3e99fbaeef41cbb (git) Affected: 946d76db77ee5f922968ce558629ae47b381e3fc , < cc7732b8549ecb6f02457edeb8db1f6d255e381c (git) Affected: fbf7961964a6e93360179f64712320ae9a1e9577 , < f492de11b325446b0b11bc2eb86e1f546eaa61b6 (git) Affected: 759c185d0bbdb131357408f50b8735e04ed3caff , < ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c (git) Affected: 62ce8b33eb238cf18c15207332fbdc26d858f592 (git) Affected: 3873f3449701b3dc98cba577923be6493598e7a1 (git) Affected: 7ded3264106418c6456ccceaafd9fda596ce12c3 (git) Affected: 5.10.270 , < 5.11 (semver) Affected: 5.15.221 , < 5.16 (semver) Affected: 6.1.188 , < 6.2 (semver) |
guessed | |
| Linux | Linux |
Affected:
6.6.157 , < 6.6.160
(semver)
Affected: 6.12.109 , < 6.12.114 (semver) Affected: 6.18.50 , < 6.18.58 (semver) Affected: 7.2.4 , < 7.2.11 (semver) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/bluetooth/rfcomm.h",
"net/bluetooth/rfcomm/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4dc3d5a004b8fd59f3c905631dbb18cb601b1b41",
"status": "affected",
"version": "82425b14f0fb22e46cfddc56d6465570f5ed0ce6",
"versionType": "git"
},
{
"lessThan": "d2206e8c78be69d21d4f5343c3e99fbaeef41cbb",
"status": "affected",
"version": "1b7841ffad08e911e8c4b9470f3fa08423568940",
"versionType": "git"
},
{
"lessThan": "cc7732b8549ecb6f02457edeb8db1f6d255e381c",
"status": "affected",
"version": "946d76db77ee5f922968ce558629ae47b381e3fc",
"versionType": "git"
},
{
"lessThan": "f492de11b325446b0b11bc2eb86e1f546eaa61b6",
"status": "affected",
"version": "fbf7961964a6e93360179f64712320ae9a1e9577",
"versionType": "git"
},
{
"lessThan": "ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c",
"status": "affected",
"version": "759c185d0bbdb131357408f50b8735e04ed3caff",
"versionType": "git"
},
{
"status": "affected",
"version": "62ce8b33eb238cf18c15207332fbdc26d858f592",
"versionType": "git"
},
{
"status": "affected",
"version": "3873f3449701b3dc98cba577923be6493598e7a1",
"versionType": "git"
},
{
"status": "affected",
"version": "7ded3264106418c6456ccceaafd9fda596ce12c3",
"versionType": "git"
},
{
"lessThan": "5.11",
"status": "affected",
"version": "5.10.270",
"versionType": "semver"
},
{
"lessThan": "5.16",
"status": "affected",
"version": "5.15.221",
"versionType": "semver"
},
{
"lessThan": "6.2",
"status": "affected",
"version": "6.1.188",
"versionType": "semver"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/bluetooth/rfcomm.h",
"net/bluetooth/rfcomm/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6.6.160",
"status": "affected",
"version": "6.6.157",
"versionType": "semver"
},
{
"lessThan": "6.12.114",
"status": "affected",
"version": "6.12.109",
"versionType": "semver"
},
{
"lessThan": "6.18.58",
"status": "affected",
"version": "6.18.50",
"versionType": "semver"
},
{
"lessThan": "7.2.11",
"status": "affected",
"version": "7.2.4",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.160",
"versionStartIncluding": "6.6.157",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.114",
"versionStartIncluding": "6.12.109",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.58",
"versionStartIncluding": "6.18.50",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2.11",
"versionStartIncluding": "7.2.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.10.270",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.15.221",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.1.188",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: connect the session socket without rfcomm_mutex\n\nAn RFCOMM connect() issued while a BR/EDR link is being authenticated\nmakes lockdep report a circular dependency, and the reported cycle is a\nreal AB/BA between rfcomm_mutex and hdev-\u003elock.\n\nrfcomm_security_cfm() is called from the HCI event path, which already\nholds hdev-\u003elock:\n\n hci_rx_work()\n hci_event_packet()\n hci_cc_read_enc_key_size() [hdev-\u003elock]\n hci_encrypt_cfm() [hci_cb_list_lock]\n rfcomm_security_cfm() [rfcomm_mutex]\n\nwhile an RFCOMM connect() from userspace takes the same two locks the\nother way round:\n\n rfcomm_sock_connect()\n rfcomm_dlc_open() [rfcomm_mutex]\n __rfcomm_dlc_open()\n rfcomm_session_create()\n kernel_connect()\n l2cap_sock_connect()\n l2cap_chan_connect() [hdev-\u003elock]\n\n WARNING: possible circular locking dependency detected\n kworker/u131:1/1128 is trying to acquire lock:\n rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]\n but task is already holding lock:\n hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0\n Chain exists of:\n rfcomm_mutex --\u003e \u0026hdev-\u003elock --\u003e hci_cb_list_lock\n\nhci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback\nthe same way.\n\nBoth orders have to be seen in the same boot, which is why a BR/EDR\nconnection alone is not enough to show it: a session set up by the\nremote side is created by rfcomm_accept_connection() in krfcommd, which\ncalls kernel_accept() and never takes hdev-\u003elock under rfcomm_mutex.\nConnecting a device that authenticates and encrypts the link and then\ncalling connect() on an RFCOMM socket towards any address - the connect\ndoes not have to succeed, the order is recorded before the page timeout\n- reports it every time.\n\nOnly the session socket has to be connected with the lock held, and it\ndoes not: nothing else can see the socket before it is put on the\nsession list. So connect it first and take rfcomm_mutex afterwards,\nwhich removes the rfcomm_mutex -\u003e hdev-\u003elock order for good, rather\nthan keeping the HCI event path out of rfcomm_mutex.\n\nrfcomm_session_create() becomes rfcomm_session_connect(), which returns\nthe connected socket without touching the session list, and\nrfcomm_dlc_open() adds the session once it holds the lock again. If\nanother opener added a session for the same pair while this socket was\nconnecting, that session is used and this socket is dropped.\n__rfcomm_dlc_open() now takes the session it should use, and its state\ncheck runs after the lock is re-acquired, so a DLC that was opened or\nclosed in the meantime is still handled.\n\nOver an existing ACL link the connection can complete before the\nsession reaches the list, and the wakeup from the socket callback is\nthen lost, so krfcommd is woken once the session is visible.\n\nConnecting without the lock opens a window in which the socket can be\nclosed. The DLC is not on a session yet, so rfcomm_dlc_close() finds\nnothing to do and returns without touching it, and rfcomm_dlc_open()\nwould then attach a DLC whose owner is gone. rfcomm_dlc_close() now\nmarks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the\nmark once it holds rfcomm_mutex again and drops the socket instead of\nattaching the DLC. The mark is cleared when an open starts, so a DLC\nthat is reused is not affected. This covers both callers of\nrfcomm_dlc_open(), the socket and the tty layer."
}
],
"providerMetadata": {
"dateUpdated": "2026-10-23T12:20:34.301Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4dc3d5a004b8fd59f3c905631dbb18cb601b1b41"
},
{
"url": "https://git.kernel.org/stable/c/d2206e8c78be69d21d4f5343c3e99fbaeef41cbb"
},
{
"url": "https://git.kernel.org/stable/c/cc7732b8549ecb6f02457edeb8db1f6d255e381c"
},
{
"url": "https://git.kernel.org/stable/c/f492de11b325446b0b11bc2eb86e1f546eaa61b6"
},
{
"url": "https://git.kernel.org/stable/c/ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c"
}
],
"title": "Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-99009",
"datePublished": "2026-10-23T12:20:34.301Z",
"dateReserved": "2026-09-25T10:25:14.385Z",
"dateUpdated": "2026-10-23T12:20:34.301Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-99009",
"date": "2026-10-24",
"epss": "0.00209",
"percentile": "0.10472"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/bluetooth/rfcomm.h",
"net/bluetooth/rfcomm/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4dc3d5a004b8fd59f3c905631dbb18cb601b1b41",
"status": "affected",
"version": "82425b14f0fb22e46cfddc56d6465570f5ed0ce6",
"versionType": "git"
},
{
"lessThan": "d2206e8c78be69d21d4f5343c3e99fbaeef41cbb",
"status": "affected",
"version": "1b7841ffad08e911e8c4b9470f3fa08423568940",
"versionType": "git"
},
{
"lessThan": "cc7732b8549ecb6f02457edeb8db1f6d255e381c",
"status": "affected",
"version": "946d76db77ee5f922968ce558629ae47b381e3fc",
"versionType": "git"
},
{
"lessThan": "f492de11b325446b0b11bc2eb86e1f546eaa61b6",
"status": "affected",
"version": "fbf7961964a6e93360179f64712320ae9a1e9577",
"versionType": "git"
},
{
"lessThan": "ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c",
"status": "affected",
"version": "759c185d0bbdb131357408f50b8735e04ed3caff",
"versionType": "git"
},
{
"status": "affected",
"version": "62ce8b33eb238cf18c15207332fbdc26d858f592",
"versionType": "git"
},
{
"status": "affected",
"version": "3873f3449701b3dc98cba577923be6493598e7a1",
"versionType": "git"
},
{
"status": "affected",
"version": "7ded3264106418c6456ccceaafd9fda596ce12c3",
"versionType": "git"
},
{
"lessThan": "5.11",
"status": "affected",
"version": "5.10.270",
"versionType": "semver"
},
{
"lessThan": "5.16",
"status": "affected",
"version": "5.15.221",
"versionType": "semver"
},
{
"lessThan": "6.2",
"status": "affected",
"version": "6.1.188",
"versionType": "semver"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/bluetooth/rfcomm.h",
"net/bluetooth/rfcomm/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6.6.160",
"status": "affected",
"version": "6.6.157",
"versionType": "semver"
},
{
"lessThan": "6.12.114",
"status": "affected",
"version": "6.12.109",
"versionType": "semver"
},
{
"lessThan": "6.18.58",
"status": "affected",
"version": "6.18.50",
"versionType": "semver"
},
{
"lessThan": "7.2.11",
"status": "affected",
"version": "7.2.4",
"versionType": "semver"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: connect the session socket without rfcomm_mutex\n\nAn RFCOMM connect() issued while a BR/EDR link is being authenticated\nmakes lockdep report a circular dependency, and the reported cycle is a\nreal AB/BA between rfcomm_mutex and hdev-\u003elock.\n\nrfcomm_security_cfm() is called from the HCI event path, which already\nholds hdev-\u003elock:\n\n hci_rx_work()\n hci_event_packet()\n hci_cc_read_enc_key_size() [hdev-\u003elock]\n hci_encrypt_cfm() [hci_cb_list_lock]\n rfcomm_security_cfm() [rfcomm_mutex]\n\nwhile an RFCOMM connect() from userspace takes the same two locks the\nother way round:\n\n rfcomm_sock_connect()\n rfcomm_dlc_open() [rfcomm_mutex]\n __rfcomm_dlc_open()\n rfcomm_session_create()\n kernel_connect()\n l2cap_sock_connect()\n l2cap_chan_connect() [hdev-\u003elock]\n\n WARNING: possible circular locking dependency detected\n kworker/u131:1/1128 is trying to acquire lock:\n rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]\n but task is already holding lock:\n hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0\n Chain exists of:\n rfcomm_mutex --\u003e \u0026hdev-\u003elock --\u003e hci_cb_list_lock\n\nhci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback\nthe same way.\n\nBoth orders have to be seen in the same boot, which is why a BR/EDR\nconnection alone is not enough to show it: a session set up by the\nremote side is created by rfcomm_accept_connection() in krfcommd, which\ncalls kernel_accept() and never takes hdev-\u003elock under rfcomm_mutex.\nConnecting a device that authenticates and encrypts the link and then\ncalling connect() on an RFCOMM socket towards any address - the connect\ndoes not have to succeed, the order is recorded before the page timeout\n- reports it every time.\n\nOnly the session socket has to be connected with the lock held, and it\ndoes not: nothing else can see the socket before it is put on the\nsession list. So connect it first and take rfcomm_mutex afterwards,\nwhich removes the rfcomm_mutex -\u003e hdev-\u003elock order for good, rather\nthan keeping the HCI event path out of rfcomm_mutex.\n\nrfcomm_session_create() becomes rfcomm_session_connect(), which returns\nthe connected socket without touching the session list, and\nrfcomm_dlc_open() adds the session once it holds the lock again. If\nanother opener added a session for the same pair while this socket was\nconnecting, that session is used and this socket is dropped.\n__rfcomm_dlc_open() now takes the session it should use, and its state\ncheck runs after the lock is re-acquired, so a DLC that was opened or\nclosed in the meantime is still handled.\n\nOver an existing ACL link the connection can complete before the\nsession reaches the list, and the wakeup from the socket callback is\nthen lost, so krfcommd is woken once the session is visible.\n\nConnecting without the lock opens a window in which the socket can be\nclosed. The DLC is not on a session yet, so rfcomm_dlc_close() finds\nnothing to do and returns without touching it, and rfcomm_dlc_open()\nwould then attach a DLC whose owner is gone. rfcomm_dlc_close() now\nmarks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the\nmark once it holds rfcomm_mutex again and drops the socket instead of\nattaching the DLC. The mark is cleared when an open starts, so a DLC\nthat is reused is not affected. This covers both callers of\nrfcomm_dlc_open(), the socket and the tty layer."
}
],
"id": "CVE-2026-99009",
"lastModified": "2026-10-23T13:17:23.470",
"metrics": {},
"published": "2026-10-23T13:17:23.470",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4dc3d5a004b8fd59f3c905631dbb18cb601b1b41"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cc7732b8549ecb6f02457edeb8db1f6d255e381c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d2206e8c78be69d21d4f5343c3e99fbaeef41cbb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f492de11b325446b0b11bc2eb86e1f546eaa61b6"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
}
}
}
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.