Search
Find a vulnerability
Search criteria
2 vulnerabilities by Cisco
GCVE-1988-2026-0280
Vulnerability from gna-1988 – Published: 2026-09-08 11:24 – Updated: 2026-09-09 10:11
VLAI
EPSS
VEX
Title
Cisco Catalyst SD-WAN C8000V Authenticated Heap Buffer Overflow
Summary
SUMMARY: an authenticated heap buffer overflow in cisco catalyst
c8000v sd-wan allows an attacker with low privileges to corrupt
process memory and achieve remote code execution by sending a crafted
message of type 0x0d (13) with device mode 5.
this was tested on 17.06.03 as it is the only image i had access to.
https://bst.cisco.com/quickview/bug/CSCwu48719
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S
===================== the vuln =====================
the core vuln is in vdaemon. vdaemon is the core control plane binary
used by catalyst to orchestrate stuff like secure tunneling and
joining new devices when they first are introduced to the sd-wan. thus
(again) its a juicy target to get initial access on.
the core vuln is at sub_2A4D0:
lea rdi, [r12+0F34h] ; peer struct
mov rbx, [rbp+src]
lea r15, [rbx+20h]
lea rsi, [rbx+24h]
mov edx, [rbx+20h]
call _memcpy
mov byte ptr [r14+rax+0F34h], 0 ; null term
the pseudocode, essenetially, is:
memcpy(&peer->f34h, msg->dat, msg->len);
peer->f34h[msg->len] = 0;
i assume you can see the major issue in here lol. we control the
length and src since we control the message. we get a heap buffer
overflow. in this case, we get two overflows:
; second overflow
lea rdi, [r12+0F86h]
lea rsi, [rbx+100h]
mov edx, [rbx+164h]
call _memcpy
mov byte ptr [r14+rax+0F86h], 0
this time to 0xf86 in peer.
peer is allocated in sub_21B20 once you xref it:
peer = (unsigned int *)((__int64 (__fastcall *)(__int64))g_mem)(0x1298);
so the peer struct is 4760 bytes large.
the peer struct looks like:
struct peer {
void *list_next;
void *list_prev;
uint8_t pad_10[16];
uint32_t peer_state;
uint32_t field_24;
uint8_t pad_28[14];
uint8_t flag_36;
uint8_t pad_37[101];
uint32_t msg_counter;
uint8_t pad_A0[232];
uint8_t addr_info[16];
uint8_t pad_198[161];
uint8_t tlv_block[128];
uint8_t pad_2B9[167];
uint8_t addr_data[56];
uint8_t field_398[24];
uint8_t pad_3B0[256];
void *conn_ptr;
struct timespec last_seen;
uint8_t pad_4C8[2668];
uint8_t vuln_buf_1[82]; // where we hit
uint8_t vuln_buf_2[106]; // where we hit again
uint8_t field_FF0[8];
char str_FF8[58];
uint8_t field_1032;
uint8_t pad_1033[12];
uint8_t field_103F;
uint8_t flag_1040;
uint8_t pad_1041[3];
uint32_t field_1044;
uint32_t field_1048;
uint8_t pad_104C[28];
void (*bev_ssl)(...); // funcptr HIT THIS HIT THIS
uint8_t pad_1070[48];
uint8_t field_10A0[128];
uint8_t field_1120[128];
char name1[41];
char name2[41];
uint8_t pad_11F2[14];
void *sub_obj;
uint8_t field_1208[144];
};
ideally, we could probably overflow the buffers to hit the function
ptr; put a stack pivot gadget then start ropping in the heap. later
versions of c8000v have pie + aslr obviously, so that would make
exploitation significantly harder but not impossible.
unforutnately the requirements to reach this heap bof mean that it
isnt preauth rce. youd still need a valid cert; but you could send a
message of type 13 (0x0D), or a REGISTER_TO_VMANAGE type, make the
device mode 5 (vManage device mode), then include your payload to hit
the sink.
_______________________________________________
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.
Assigner
References
6 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Cisco | Cisco Catalyst SD-WAN |
Affected:
unknown
|
Relationships
reference
GCVE-1988-2026-0280 (this record)
- possibly related CVE-2022-20775
{
"containers": {
"cna": {
"affected": [
{
"product": "Cisco Catalyst SD-WAN",
"vendor": "Cisco",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "evan"
}
],
"descriptions": [
{
"lang": "en",
"value": "SUMMARY: an authenticated heap buffer overflow in cisco catalyst\nc8000v sd-wan allows an attacker with low privileges to corrupt\nprocess memory and achieve remote code execution by sending a crafted\nmessage of type 0x0d (13) with device mode 5.\nthis was tested on 17.06.03 as it is the only image i had access to.\n\nhttps://bst.cisco.com/quickview/bug/CSCwu48719\n\nhttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S\n\n===================== the vuln =====================\n\nthe core vuln is in vdaemon. vdaemon is the core control plane binary\nused by catalyst to orchestrate stuff like secure tunneling and\njoining new devices when they first are introduced to the sd-wan. thus\n(again) its a juicy target to get initial access on.\n\nthe core vuln is at sub_2A4D0:\n\nlea rdi, [r12+0F34h] ; peer struct\nmov rbx, [rbp+src]\nlea r15, [rbx+20h]\nlea rsi, [rbx+24h]\nmov edx, [rbx+20h]\ncall _memcpy\nmov byte ptr [r14+rax+0F34h], 0 ; null term\n\n\nthe pseudocode, essenetially, is:\n\nmemcpy(\u0026peer-\u003ef34h, msg-\u003edat, msg-\u003elen);\npeer-\u003ef34h[msg-\u003elen] = 0;\n\ni assume you can see the major issue in here lol. we control the\nlength and src since we control the message. we get a heap buffer\noverflow. in this case, we get two overflows:\n\n; second overflow\nlea rdi, [r12+0F86h]\nlea rsi, [rbx+100h]\nmov edx, [rbx+164h]\ncall _memcpy\nmov byte ptr [r14+rax+0F86h], 0\n\nthis time to 0xf86 in peer.\n\npeer is allocated in sub_21B20 once you xref it:\n\n peer = (unsigned int *)((__int64 (__fastcall *)(__int64))g_mem)(0x1298);\n\nso the peer struct is 4760 bytes large.\n\nthe peer struct looks like:\n\nstruct peer {\n void *list_next;\n void *list_prev;\n uint8_t pad_10[16];\n uint32_t peer_state;\n uint32_t field_24;\n uint8_t pad_28[14];\n uint8_t flag_36;\n uint8_t pad_37[101];\n uint32_t msg_counter;\n uint8_t pad_A0[232];\n uint8_t addr_info[16];\n uint8_t pad_198[161];\n uint8_t tlv_block[128];\n uint8_t pad_2B9[167];\n uint8_t addr_data[56];\n uint8_t field_398[24];\n uint8_t pad_3B0[256];\n void *conn_ptr;\n struct timespec last_seen;\n uint8_t pad_4C8[2668];\n uint8_t vuln_buf_1[82]; // where we hit\n uint8_t vuln_buf_2[106]; // where we hit again\n uint8_t field_FF0[8];\n char str_FF8[58];\n uint8_t field_1032;\n uint8_t pad_1033[12];\n uint8_t field_103F;\n uint8_t flag_1040;\n uint8_t pad_1041[3];\n uint32_t field_1044;\n uint32_t field_1048;\n uint8_t pad_104C[28];\n void (*bev_ssl)(...); // funcptr HIT THIS HIT THIS\n uint8_t pad_1070[48];\n uint8_t field_10A0[128];\n uint8_t field_1120[128];\n char name1[41];\n char name2[41];\n uint8_t pad_11F2[14];\n void *sub_obj;\n uint8_t field_1208[144];\n};\n\nideally, we could probably overflow the buffers to hit the function\nptr; put a stack pivot gadget then start ropping in the heap. later\nversions of c8000v have pie + aslr obviously, so that would make\nexploitation significantly harder but not impossible.\n\nunforutnately the requirements to reach this heap bof mean that it\nisnt preauth rce. youd still need a valid cert; but you could send a\nmessage of type 13 (0x0D), or a REGISTER_TO_VMANAGE type, make the\ndevice mode 5 (vManage device mode), then include your payload to hit\nthe sink.\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-09T10:11:52Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/15"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/15"
},
{
"url": "https://bst.cisco.com/quickview/bug/CSCwu48719"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/15"
],
"discovery": "EXTERNAL"
},
"title": "Cisco Catalyst SD-WAN C8000V Authenticated Heap Buffer Overflow",
"x_gcve": [
{
"recordType": "reference",
"relationships": [
{
"destId": "CVE-2022-20775",
"type": "possibly_related"
}
],
"vulnId": "GCVE-1988-2026-0280",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/15",
"automated": true,
"contentSha256": "e5d5de9ca8d757d30bf04212990ac358c4d7b81fddaf34f8dc4596c3adf41025",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/15",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-06T14:08:27Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0280"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-08T11:24:56Z",
"dateUpdated": "2026-09-09T10:11:52Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0280"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0028
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-09 10:11
VLAI
EPSS
VEX
Title
Cisco Catalyst SD-WAN C8000V Authenticated Heap Buffer Overflow
Summary
SUMMARY: an authenticated heap buffer overflow in cisco catalyst
c8000v sd-wan allows an attacker with low privileges to corrupt
process memory and achieve remote code execution by sending a crafted
message of type 0x0d (13) with device mode 5.
this was tested on 17.06.03 as it is the only image i had access to.
https://bst.cisco.com/quickview/bug/CSCwu48719
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S
===================== the vuln =====================
the core vuln is in vdaemon. vdaemon is the core control plane binary
used by catalyst to orchestrate stuff like secure tunneling and
joining new devices when they first are introduced to the sd-wan. thus
(again) its a juicy target to get initial access on.
the core vuln is at sub_2A4D0:
lea rdi, [r12+0F34h] ; peer struct
mov rbx, [rbp+src]
lea r15, [rbx+20h]
lea rsi, [rbx+24h]
mov edx, [rbx+20h]
call _memcpy
mov byte ptr [r14+rax+0F34h], 0 ; null term
the pseudocode, essenetially, is:
memcpy(&peer->f34h, msg->dat, msg->len);
peer->f34h[msg->len] = 0;
i assume you can see the major issue in here lol. we control the
length and src since we control the message. we get a heap buffer
overflow. in this case, we get two overflows:
; second overflow
lea rdi, [r12+0F86h]
lea rsi, [rbx+100h]
mov edx, [rbx+164h]
call _memcpy
mov byte ptr [r14+rax+0F86h], 0
this time to 0xf86 in peer.
peer is allocated in sub_21B20 once you xref it:
peer = (unsigned int *)((__int64 (__fastcall *)(__int64))g_mem)(0x1298);
so the peer struct is 4760 bytes large.
the peer struct looks like:
struct peer {
void *list_next;
void *list_prev;
uint8_t pad_10[16];
uint32_t peer_state;
uint32_t field_24;
uint8_t pad_28[14];
uint8_t flag_36;
uint8_t pad_37[101];
uint32_t msg_counter;
uint8_t pad_A0[232];
uint8_t addr_info[16];
uint8_t pad_198[161];
uint8_t tlv_block[128];
uint8_t pad_2B9[167];
uint8_t addr_data[56];
uint8_t field_398[24];
uint8_t pad_3B0[256];
void *conn_ptr;
struct timespec last_seen;
uint8_t pad_4C8[2668];
uint8_t vuln_buf_1[82]; // where we hit
uint8_t vuln_buf_2[106]; // where we hit again
uint8_t field_FF0[8];
char str_FF8[58];
uint8_t field_1032;
uint8_t pad_1033[12];
uint8_t field_103F;
uint8_t flag_1040;
uint8_t pad_1041[3];
uint32_t field_1044;
uint32_t field_1048;
uint8_t pad_104C[28];
void (*bev_ssl)(...); // funcptr HIT THIS HIT THIS
uint8_t pad_1070[48];
uint8_t field_10A0[128];
uint8_t field_1120[128];
char name1[41];
char name2[41];
uint8_t pad_11F2[14];
void *sub_obj;
uint8_t field_1208[144];
};
ideally, we could probably overflow the buffers to hit the function
ptr; put a stack pivot gadget then start ropping in the heap. later
versions of c8000v have pie + aslr obviously, so that would make
exploitation significantly harder but not impossible.
unforutnately the requirements to reach this heap bof mean that it
isnt preauth rce. youd still need a valid cert; but you could send a
message of type 13 (0x0D), or a REGISTER_TO_VMANAGE type, make the
device mode 5 (vManage device mode), then include your payload to hit
the sink.
_______________________________________________
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.
Assigner
References
6 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Cisco | Cisco Catalyst SD-WAN |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Cisco Catalyst SD-WAN",
"vendor": "Cisco",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "evan"
}
],
"descriptions": [
{
"lang": "en",
"value": "SUMMARY: an authenticated heap buffer overflow in cisco catalyst\nc8000v sd-wan allows an attacker with low privileges to corrupt\nprocess memory and achieve remote code execution by sending a crafted\nmessage of type 0x0d (13) with device mode 5.\nthis was tested on 17.06.03 as it is the only image i had access to.\n\nhttps://bst.cisco.com/quickview/bug/CSCwu48719\n\nhttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S\n\n===================== the vuln =====================\n\nthe core vuln is in vdaemon. vdaemon is the core control plane binary\nused by catalyst to orchestrate stuff like secure tunneling and\njoining new devices when they first are introduced to the sd-wan. thus\n(again) its a juicy target to get initial access on.\n\nthe core vuln is at sub_2A4D0:\n\nlea rdi, [r12+0F34h] ; peer struct\nmov rbx, [rbp+src]\nlea r15, [rbx+20h]\nlea rsi, [rbx+24h]\nmov edx, [rbx+20h]\ncall _memcpy\nmov byte ptr [r14+rax+0F34h], 0 ; null term\n\n\nthe pseudocode, essenetially, is:\n\nmemcpy(\u0026peer-\u003ef34h, msg-\u003edat, msg-\u003elen);\npeer-\u003ef34h[msg-\u003elen] = 0;\n\ni assume you can see the major issue in here lol. we control the\nlength and src since we control the message. we get a heap buffer\noverflow. in this case, we get two overflows:\n\n; second overflow\nlea rdi, [r12+0F86h]\nlea rsi, [rbx+100h]\nmov edx, [rbx+164h]\ncall _memcpy\nmov byte ptr [r14+rax+0F86h], 0\n\nthis time to 0xf86 in peer.\n\npeer is allocated in sub_21B20 once you xref it:\n\n peer = (unsigned int *)((__int64 (__fastcall *)(__int64))g_mem)(0x1298);\n\nso the peer struct is 4760 bytes large.\n\nthe peer struct looks like:\n\nstruct peer {\n void *list_next;\n void *list_prev;\n uint8_t pad_10[16];\n uint32_t peer_state;\n uint32_t field_24;\n uint8_t pad_28[14];\n uint8_t flag_36;\n uint8_t pad_37[101];\n uint32_t msg_counter;\n uint8_t pad_A0[232];\n uint8_t addr_info[16];\n uint8_t pad_198[161];\n uint8_t tlv_block[128];\n uint8_t pad_2B9[167];\n uint8_t addr_data[56];\n uint8_t field_398[24];\n uint8_t pad_3B0[256];\n void *conn_ptr;\n struct timespec last_seen;\n uint8_t pad_4C8[2668];\n uint8_t vuln_buf_1[82]; // where we hit\n uint8_t vuln_buf_2[106]; // where we hit again\n uint8_t field_FF0[8];\n char str_FF8[58];\n uint8_t field_1032;\n uint8_t pad_1033[12];\n uint8_t field_103F;\n uint8_t flag_1040;\n uint8_t pad_1041[3];\n uint32_t field_1044;\n uint32_t field_1048;\n uint8_t pad_104C[28];\n void (*bev_ssl)(...); // funcptr HIT THIS HIT THIS\n uint8_t pad_1070[48];\n uint8_t field_10A0[128];\n uint8_t field_1120[128];\n char name1[41];\n char name2[41];\n uint8_t pad_11F2[14];\n void *sub_obj;\n uint8_t field_1208[144];\n};\n\nideally, we could probably overflow the buffers to hit the function\nptr; put a stack pivot gadget then start ropping in the heap. later\nversions of c8000v have pie + aslr obviously, so that would make\nexploitation significantly harder but not impossible.\n\nunforutnately the requirements to reach this heap bof mean that it\nisnt preauth rce. youd still need a valid cert; but you could send a\nmessage of type 13 (0x0D), or a REGISTER_TO_VMANAGE type, make the\ndevice mode 5 (vManage device mode), then include your payload to hit\nthe sink.\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-09T10:11:52Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/15"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/15"
},
{
"url": "https://bst.cisco.com/quickview/bug/CSCwu48719"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/15"
],
"discovery": "EXTERNAL"
},
"title": "Cisco Catalyst SD-WAN C8000V Authenticated Heap Buffer Overflow",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0028",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/15",
"automated": true,
"contentSha256": "e5d5de9ca8d757d30bf04212990ac358c4d7b81fddaf34f8dc4596c3adf41025",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/15",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-06T14:08:27Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:20Z",
"dateUpdated": "2026-09-09T10:11:52Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0028"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}