- GNA identifier
- GNA-1988 GCVE registry Recent publications
Recent vulnerabilities
387 GCVE records assigned by this organization as GNA-1988GCVE-1988-2026-0092
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[0day-rubbish] Scan2x ScanWebClient 2.3.3.0 (other versions with the same handler are likely affected) Pre-authentication RCE (unrestricted upload to executable webroot) (9.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in Scan2x ScanWebClient 2.3.3.0 (other versions with
the same handler are likely affected).
Type: Pre-authentication RCE (unrestricted upload to executable webroot) (CWE-434)
CVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Impact: Unauthenticated remote code execution on the scanning server as the IIS app-pool identity, exposing scanned
documents and the host.
Authentication: unauthenticated / pre-auth
Full technical analysis and a reproducible proof-of-concept:
https://0day-rubbish.com/blog/scan2x-unauth-upload-rce
Project archive (ongoing disclosure series):
https://github.com/Exploit-Garbage/0day-Rubbish
Vendor has been notified. CVE ID is pending.
--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Scan2x ScanWebClient |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Scan2x ScanWebClient",
"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 Scan2x ScanWebClient 2.3.3.0 (other versions with \nthe same handler are likely affected).\n\nType: Pre-authentication RCE (unrestricted upload to executable webroot) (CWE-434)\nCVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\nImpact: Unauthenticated remote code execution on the scanning server as the IIS app-pool identity, exposing scanned \ndocuments and the host.\nAuthentication: unauthenticated / pre-auth\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/scan2x-unauth-upload-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-434",
"description": "CWE-434",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/90"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/90"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/scan2x-unauth-upload-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/Aug/90"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] Scan2x ScanWebClient 2.3.3.0 (other versions with the same handler are likely affected) Pre-authentication RCE (unrestricted upload to executable webroot) (9.8)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0092",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/90",
"automated": true,
"contentSha256": "8febbc1210fd70dbcf779940c3969d92d1947c8ef5431383ef0a7c93e01c2565",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/90",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T15:27:58Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0092"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0091
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[0day-rubbish] VLink Virtual Matrix 6.60 (other versions with the same unquoted openssl command construction are likely affected) Authenticated RCE (OpenSSL argument injection to SYSTEM) (8.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in VLink Virtual Matrix 6.60 (other versions with the
same unquoted openssl command construction are likely affected).
Type: Authenticated RCE (OpenSSL argument injection to SYSTEM) (CWE-78)
CVSS: 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
Impact: Authenticated admin-to-SYSTEM remote code execution on the intercom server, compromising mission-critical
communications infrastructure.
Authentication: authenticated (requires valid session)
Full technical analysis and a reproducible proof-of-concept:
https://0day-rubbish.com/blog/rts-vlink-openssl-arginj-system-rce
Project archive (ongoing disclosure series):
https://github.com/Exploit-Garbage/0day-Rubbish
Vendor has been notified. CVE ID is pending.
--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | VLink Virtual Matrix |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "VLink Virtual Matrix",
"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 VLink Virtual Matrix 6.60 (other versions with the \nsame unquoted openssl command construction are likely affected).\n\nType: Authenticated RCE (OpenSSL argument injection to SYSTEM) (CWE-78)\nCVSS: 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)\nImpact: Authenticated admin-to-SYSTEM remote code execution on the intercom server, compromising mission-critical \ncommunications infrastructure.\nAuthentication: authenticated (requires valid session)\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/rts-vlink-openssl-arginj-system-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-78",
"description": "CWE-78",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/89"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/89"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/rts-vlink-openssl-arginj-system-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/Aug/89"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] VLink Virtual Matrix 6.60 (other versions with the same unquoted openssl command construction are likely affected) Authenticated RCE (OpenSSL argument injection to SYSTEM) (8.8)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0091",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/89",
"automated": true,
"contentSha256": "0a6c27f62ea0c791b498dc659fc72136a896e1c67d2f2fe67c9aa2f637df4978",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/89",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T15:27:45Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0091"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0090
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[0day-rubbish] NCache Enterprise 5.3.6 (other versions with the same default-disabled security and handler logic are likely affected) Pre-authentication RCE (missing auth + attacker assembly load) (9.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in NCache Enterprise 5.3.6 (other versions with the
same default-disabled security and handler logic are likely affected).
Type: Pre-authentication RCE (missing auth + attacker assembly load) (CWE-94)
CVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Impact: Unauthenticated remote code execution on the cache server as the ncache service user, exposing cached
application data and the host.
Authentication: unauthenticated / pre-auth
Full technical analysis and a reproducible proof-of-concept:
https://0day-rubbish.com/blog/ncache-enterprise-unauth-assembly-load-rce
Project archive (ongoing disclosure series):
https://github.com/Exploit-Garbage/0day-Rubbish
Vendor has been notified. CVE ID is pending.
--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | NCache Enterprise |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "NCache Enterprise",
"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 NCache Enterprise 5.3.6 (other versions with the \nsame default-disabled security and handler logic are likely affected).\n\nType: Pre-authentication RCE (missing auth + attacker assembly load) (CWE-94)\nCVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\nImpact: Unauthenticated remote code execution on the cache server as the ncache service user, exposing cached \napplication data and the host.\nAuthentication: unauthenticated / pre-auth\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/ncache-enterprise-unauth-assembly-load-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-94",
"description": "CWE-94",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/88"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/88"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/ncache-enterprise-unauth-assembly-load-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/Aug/88"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] NCache Enterprise 5.3.6 (other versions with the same default-disabled security and handler logic are likely affected) Pre-authentication RCE (missing auth + attacker assembly load) (9.8)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0090",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/88",
"automated": true,
"contentSha256": "1719e9c3a4af6db4761c511db2236f9e4f4906dca14b0a6f2cb708c29b387acc",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/88",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T15:27:31Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0090"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0088
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[0day-rubbish] Microsip 2026 (ASD data-service agent) 2026 Eval (other builds with the same backup-runner path handling are likely affected) Pre-authentication RCE (attacker-controlled binary path, LocalSystem) (9.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in Microsip 2026 (ASD data-service agent) 2026 Eval
(other builds with the same backup-runner path handling are likely affected).
Type: Pre-authentication RCE (attacker-controlled binary path, LocalSystem) (CWE-426)
CVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Impact: Unauthenticated remote code execution as LocalSystem on the ERP data-service host, compromising the business
database and administrative systems.
Authentication: unauthenticated / pre-auth
Full technical analysis and a reproducible proof-of-concept:
https://0day-rubbish.com/blog/microsip-asd-unc-binary-planting-rce
Project archive (ongoing disclosure series):
https://github.com/Exploit-Garbage/0day-Rubbish
Vendor has been notified. CVE ID is pending.
--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Microsip 2026 ASD |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Microsip 2026 ASD",
"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 Microsip 2026 (ASD data-service agent) 2026 Eval \n(other builds with the same backup-runner path handling are likely affected).\n\nType: Pre-authentication RCE (attacker-controlled binary path, LocalSystem) (CWE-426)\nCVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)\nImpact: Unauthenticated remote code execution as LocalSystem on the ERP data-service host, compromising the business \ndatabase and administrative systems.\nAuthentication: unauthenticated / pre-auth\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/microsip-asd-unc-binary-planting-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-426",
"description": "CWE-426",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/86"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/86"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/microsip-asd-unc-binary-planting-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/Aug/86"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] Microsip 2026 (ASD data-service agent) 2026 Eval (other builds with the same backup-runner path handling are likely affected) Pre-authentication RCE (attacker-controlled binary path, LocalSystem) (9.8)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0088",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/86",
"automated": true,
"contentSha256": "8e24660dcead360adbfd31759ae7384b4672afc478c0b8f95d794f1bd5ca8b0b",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/86",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T15:27:04Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0088"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0086
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[0day-rubbish] CFEngine Enterprise Nova Hub 3.27.1 (other versions with the same generateScriptFromTemplates quoting are likely affected) Authenticated RCE (command injection via VCS settings, root) (8.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in CFEngine Enterprise Nova Hub 3.27.1 (other
versions with the same generateScriptFromTemplates quoting are likely affected).
Type: Authenticated RCE (command injection via VCS settings, root) (CWE-78)
CVSS: 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
Impact: Authenticated admin-to-root full server takeover of the management hub that orchestrates the entire managed
fleet.
Authentication: authenticated (requires valid session)
Full technical analysis and a reproducible proof-of-concept:
https://0day-rubbish.com/blog/cfengine-nova-hub-vcs-settings-root-rce
Project archive (ongoing disclosure series):
https://github.com/Exploit-Garbage/0day-Rubbish
Vendor has been notified. CVE ID is pending.
--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | CFEngine Enterprise Nova |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "CFEngine Enterprise Nova",
"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 CFEngine Enterprise Nova Hub 3.27.1 (other \nversions with the same generateScriptFromTemplates quoting are likely affected).\n\nType: Authenticated RCE (command injection via VCS settings, root) (CWE-78)\nCVSS: 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)\nImpact: Authenticated admin-to-root full server takeover of the management hub that orchestrates the entire managed \nfleet.\nAuthentication: authenticated (requires valid session)\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/cfengine-nova-hub-vcs-settings-root-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-78",
"description": "CWE-78",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/84"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/84"
},
{
"url": "https://0day-rubbish.com"
},
{
"url": "https://0day-rubbish.com/blog/cfengine-nova-hub-vcs-settings-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/Aug/84"
],
"discovery": "EXTERNAL"
},
"title": "[0day-rubbish] CFEngine Enterprise Nova Hub 3.27.1 (other versions with the same generateScriptFromTemplates quoting are likely affected) Authenticated RCE (command injection via VCS settings, root) (8.8)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0086",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/84",
"automated": true,
"contentSha256": "afd7797ce410568a81edafb2a9e8ccca49a04e69aa6b91ba6cf87f70aabeb1a3",
"evidenceScore": 11,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/84",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T15:26:35Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0086"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0084
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[NotCVE-2026-0013] CHIRP Kenwood ITM Driver Eval Injection Allows Arbitrary Code Execution via Crafted Radio File
Summary
----------------------------------------------------------------------------
NotCVE Advisory — NotCVE-2026-0013
----------------------------------------------------------------------------
[-] Summary:
Eval injection in the Kenwood ITM file format driver of CHIRP, an
open-source application for programming amateur radios, allows an attacker
who can persuade a user to open a crafted radio file to execute arbitrary
Python code with the privileges of that user. The affected path is reached
through the ordinary File -> Open flow in a stock installation; no dialog or
confirmation precedes execution. CVSS:3.1 7.8
(AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).
[-] Affected:
CHIRP, chirp-next builds up to and including chirp-next-20260814.
Fixed in source at commit 39178db (2026-08-17); the researcher reports build
chirp-next-20260821 ships the fix.
[-] Technical Description:
ITMRadio._clean_tmode() in chirp/drivers/kenwood_itm.py read two CSV fields
from the file being opened and passed each one directly to Python's built-in
eval() (lines 66-67):
TXSIG, whose evaluated result was assigned to mem.rtone
RXSIG, whose evaluated result was assigned to mem.ctone
Both values are attacker-controlled strings retrieved verbatim from a row of
the opened file via generic_csv.get_datum_by_header(). The driver expected a
numeric CTCSS tone, but no type check, allowlist, or parsing step
constrained the input, so any Python expression placed in either field was
evaluated at file-load time. The commit message for the fix records the
assumption plainly: the squelch fields "were assumed to only be a float".
ITMRadio is decorated with @directory.register and declares VENDOR =
"Kenwood", MODEL = "ITM" and FILE_EXTENSION = "itm". The driver ships in the
stock distribution; no non-standard setting, plugin, or developer mode is
required.
The .itm extension is not offered by the Open dialog's default filter, so
that variant requires the victim to switch the filter to "All Files". The
researcher's second proof of concept carries the same CSV payload in a .img
file with a trailing CHIRP metadata blob naming vendor "Kenwood" and model
"ITM"; directory.get_radio_by_image() selects a driver by comparing that
embedded metadata against registered classes, which is consistent with a
.img file routing to this driver under the default filter.
The code runs in the CHIRP process with the victim user's privileges, before
any channel data is displayed. No elevation is involved; the impact is
bounded by what that user can reach.
The fix removes both eval() calls and replaces them with
kenwood_tone.parse_qtdqt() feeding chirp_common.split_tone_decode().
Weaknesses:
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code
('Eval Injection')
CAPEC-35: Leverage Executable Code in Non-Executable Files
CAPEC-242: Code Injection
Proof-of-concept files for both delivery variants are published in the
researcher's repository (see References).
[-] Timeline:
[17/08/2026] - Reported to the CHIRP maintainer; fixed the same day
(39178db).
[21/08/2026] - Build chirp-next-20260821 reported to ship the fix.
[21/08/2026] - No CVE assigned; NotCVE ID reserved instead.
[22/08/2026] - Published as NotCVE-2026-0013.
[-] Credit:
Discovered by Christopher Duram
(https://www.linkedin.com/in/christopherduram/).
[-] Full Details and Updates:
https://notcve.org/notcve/NotCVE-2026-0013
[-] References:
https://github.com/cduram/CHIRP-CodeExecution_via_Malicious_ImageFile
https://github.com/kk7ds/chirp/commit/39178dbfc4fece083ab9ed20286d6ae3a91a718e
https://github.com/kk7ds/chirp/blob/39178dbfc4fece083ab9ed20286d6ae3a91a718e~1/chirp/drivers/kenwood_itm.py
https://github.com/kk7ds/chirp/blob/master/chirp/drivers/kenwood_itm.py
https://github.com/kk7ds/chirp/blob/master/chirp/directory.py
[-] About NotCVE:
NotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to
vulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?
Request a NotCVE: https://notcve.org/form/ · Contributors:
https://notcve.org/hall/
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
14 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | CHIRP Kenwood ITM |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "CHIRP Kenwood ITM",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "advisories"
}
],
"descriptions": [
{
"lang": "en",
"value": "----------------------------------------------------------------------------\nNotCVE Advisory \u2014 NotCVE-2026-0013\n----------------------------------------------------------------------------\n\n[-] Summary:\nEval injection in the Kenwood ITM file format driver of CHIRP, an\nopen-source application for programming amateur radios, allows an attacker\nwho can persuade a user to open a crafted radio file to execute arbitrary\nPython code with the privileges of that user. The affected path is reached\nthrough the ordinary File -\u003e Open flow in a stock installation; no dialog or\nconfirmation precedes execution. CVSS:3.1 7.8\n(AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).\n\n[-] Affected:\nCHIRP, chirp-next builds up to and including chirp-next-20260814.\nFixed in source at commit 39178db (2026-08-17); the researcher reports build\nchirp-next-20260821 ships the fix.\n\n[-] Technical Description:\nITMRadio._clean_tmode() in chirp/drivers/kenwood_itm.py read two CSV fields\nfrom the file being opened and passed each one directly to Python\u0027s built-in\neval() (lines 66-67):\n\n TXSIG, whose evaluated result was assigned to mem.rtone\n RXSIG, whose evaluated result was assigned to mem.ctone\n\nBoth values are attacker-controlled strings retrieved verbatim from a row of\nthe opened file via generic_csv.get_datum_by_header(). The driver expected a\nnumeric CTCSS tone, but no type check, allowlist, or parsing step\nconstrained the input, so any Python expression placed in either field was\nevaluated at file-load time. The commit message for the fix records the\nassumption plainly: the squelch fields \"were assumed to only be a float\".\n\nITMRadio is decorated with @directory.register and declares VENDOR =\n\"Kenwood\", MODEL = \"ITM\" and FILE_EXTENSION = \"itm\". The driver ships in the\nstock distribution; no non-standard setting, plugin, or developer mode is\nrequired.\n\nThe .itm extension is not offered by the Open dialog\u0027s default filter, so\nthat variant requires the victim to switch the filter to \"All Files\". The\nresearcher\u0027s second proof of concept carries the same CSV payload in a .img\nfile with a trailing CHIRP metadata blob naming vendor \"Kenwood\" and model\n\"ITM\"; directory.get_radio_by_image() selects a driver by comparing that\nembedded metadata against registered classes, which is consistent with a\n.img file routing to this driver under the default filter.\n\nThe code runs in the CHIRP process with the victim user\u0027s privileges, before\nany channel data is displayed. No elevation is involved; the impact is\nbounded by what that user can reach.\n\nThe fix removes both eval() calls and replaces them with\nkenwood_tone.parse_qtdqt() feeding chirp_common.split_tone_decode().\n\nWeaknesses:\nCWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code\n (\u0027Eval Injection\u0027)\nCAPEC-35: Leverage Executable Code in Non-Executable Files\nCAPEC-242: Code Injection\n\nProof-of-concept files for both delivery variants are published in the\nresearcher\u0027s repository (see References).\n\n[-] Timeline:\n[17/08/2026] - Reported to the CHIRP maintainer; fixed the same day\n (39178db).\n[21/08/2026] - Build chirp-next-20260821 reported to ship the fix.\n[21/08/2026] - No CVE assigned; NotCVE ID reserved instead.\n[22/08/2026] - Published as NotCVE-2026-0013.\n\n[-] Credit:\nDiscovered by Christopher Duram\n(https://www.linkedin.com/in/christopherduram/).\n\n[-] Full Details and Updates:\nhttps://notcve.org/notcve/NotCVE-2026-0013\n\n[-] References:\nhttps://github.com/cduram/CHIRP-CodeExecution_via_Malicious_ImageFile\nhttps://github.com/kk7ds/chirp/commit/39178dbfc4fece083ab9ed20286d6ae3a91a718e\nhttps://github.com/kk7ds/chirp/blob/39178dbfc4fece083ab9ed20286d6ae3a91a718e~1/chirp/drivers/kenwood_itm.py\nhttps://github.com/kk7ds/chirp/blob/master/chirp/drivers/kenwood_itm.py\nhttps://github.com/kk7ds/chirp/blob/master/chirp/directory.py\n\n[-] About NotCVE:\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ \u00b7 Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-95",
"description": "CWE-95",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/114"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/114"
},
{
"url": "https://github.com/cduram/CHIRP-CodeExecution_via_Malicious_ImageFile"
},
{
"url": "https://github.com/kk7ds/chirp/blob/39178dbfc4fece083ab9ed20286d6ae3a91a718e~1/chirp/drivers/kenwood_itm.py"
},
{
"url": "https://github.com/kk7ds/chirp/blob/master/chirp/directory.py"
},
{
"url": "https://github.com/kk7ds/chirp/blob/master/chirp/drivers/kenwood_itm.py"
},
{
"url": "https://github.com/kk7ds/chirp/commit/39178dbfc4fece083ab9ed20286d6ae3a91a718e"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://notcve.org"
},
{
"url": "https://notcve.org/form/"
},
{
"url": "https://notcve.org/hall/"
},
{
"url": "https://notcve.org/notcve/NotCVE-2026-0013"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/christopherduram/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/114"
],
"discovery": "EXTERNAL"
},
"title": "[NotCVE-2026-0013] CHIRP Kenwood ITM Driver Eval Injection Allows Arbitrary Code Execution via Crafted Radio File",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0084",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/114",
"automated": true,
"contentSha256": "cc82dce2abcfc8aa298add650d69a778d4216f5c0cb2758f989edcf008cca081",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/114",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T11:50:49Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0084"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0081
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Escargot v4.3.0-214-gfaee4437 Unauthenticated Remote Debugger Allows Arbitrary JavaScript Evaluation and Local File Disclosure
Summary
An unauthenticated remote debugger vulnerability exists in Escargot
v4.3.0-214-gfaee4437 when the application is compiled with ESCARGOT_DEBUGGER
support and the debug server is enabled using --start-debug-server. The
debugger accepts client connections without authentication or authorization
and provides access to privileged debugger functionality.
An attacker capable of reaching the debugger interface can establish a
debugger session and evaluate JavaScript expressions within the target
runtime. Testing confirmed the vulnerability by executing
read("/etc/passwd") through the debugger and retrieving the contents of the
local file.
Technical Details
The vulnerability occurs because Escargot exposes remote debugger
HTTP/WebSocket endpoints without requiring authentication before
establishing a debugger session.
The exposed debugger routes include:
/escargot-debugger
/devtools/page/1
/json
/json/list
/json/version
Requests to the debugger WebSocket endpoints are routed to the WebSocket
handshake implementation. The handshake performs WebSocket protocol
negotiation but does not authenticate or authorize the connecting client
before providing access to debugger functionality.
Once connected, the debugger accepts evaluation commands that execute
JavaScript expressions within the target Escargot runtime.
The affected functionality is conditionally compiled with:
#ifdef ESCARGOT_DEBUGGER
and enabled at runtime using:
--start-debug-server
Root CauseNo authentication protecting the remote debugger No authorization
check before debugger access Network connectivity treated as sufficient
trust Privileged JavaScript evaluation exposed to debugger clients Debugger
helper functions expose local runtime resources
Impact
Unauthorized Debugger Access:
An unauthenticated client capable of reaching the debugger can
establish an interactive debugging session.
Arbitrary JavaScript Evaluation:
The connected client can submit JavaScript expressions for evaluation
within the target Escargot runtime.
Local File Disclosure:
Files accessible through exposed runtime helper functions can be
retrieved. Testing confirmed disclosure of /etc/passwd.
Runtime State Exposure:
An attacker may inspect interpreter state and interact with other
functionality exposed through the debugger.
The PoC demonstrates JavaScript evaluation and local file disclosure. It
does not, by itself, establish arbitrary operating-system command execution
or native code execution.
Proof of Concept
Start a debugger-enabled Escargot build with the remote debugger enabled
and connect using the debugger client.
The following debugger commands were used:
b /tmp/rdf.js:2
c
p read("/etc/passwd")
c
Output
Connecting to: localhost:6516
Connection created!!!
Stopped at /tmp/rdf.js:1
(escargot-debugger) b /tmp/rdf.js:2
Breakpoint 1 at /tmp/rdf.js:2
(escargot-debugger) c
Stopped at breakpoint:1 /tmp/rdf.js:2
(escargot-debugger) p read("/etc/passwd")
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
...
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
(escargot-debugger) c
Print: debugger file read probe complete
Connection closed.
Server-side output confirmed that the debugger was listening and accepted
the connection:
Waiting for client connection 0.0.0.0:6516
Connected from: 127.0.0.1
debugger file read probe complete
The returned data matched the contents of /etc/passwd, confirming that the
debugger accepted an unauthenticated session, evaluated the supplied
JavaScript expression, and returned local file contents to the debugger
client.
Ron Edgerson
Vulnerability Researcher & Exploit Developer
CVE Research | Binary Exploitation | Application & Systems Security
Responsible Disclosure • Proof-of-Concept Development
🌐 https://github.com/ob1sec
🔗 https://www.linkedin.com/in/ronedgerson1
<https://linkedin.com/in/yourhandle>
_______________________________________________
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
7 references
{
"containers": {
"cna": {
"affected": [
{
"product": "Escargot",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "An unauthenticated remote debugger vulnerability exists in Escargot\nv4.3.0-214-gfaee4437 when the application is compiled with ESCARGOT_DEBUGGER\nsupport and the debug server is enabled using --start-debug-server. The\ndebugger accepts client connections without authentication or authorization\nand provides access to privileged debugger functionality.\n\nAn attacker capable of reaching the debugger interface can establish a\ndebugger session and evaluate JavaScript expressions within the target\nruntime. Testing confirmed the vulnerability by executing\nread(\"/etc/passwd\") through the debugger and retrieving the contents of the\nlocal file.\n\nTechnical Details\n\nThe vulnerability occurs because Escargot exposes remote debugger\nHTTP/WebSocket endpoints without requiring authentication before\nestablishing a debugger session.\n\nThe exposed debugger routes include:\n\n/escargot-debugger\n/devtools/page/1\n/json\n/json/list\n/json/version\n\nRequests to the debugger WebSocket endpoints are routed to the WebSocket\nhandshake implementation. The handshake performs WebSocket protocol\nnegotiation but does not authenticate or authorize the connecting client\nbefore providing access to debugger functionality.\n\nOnce connected, the debugger accepts evaluation commands that execute\nJavaScript expressions within the target Escargot runtime.\n\nThe affected functionality is conditionally compiled with:\n\n#ifdef ESCARGOT_DEBUGGER\n\nand enabled at runtime using:\n\n--start-debug-server\n\nRoot CauseNo authentication protecting the remote debugger No authorization\ncheck before debugger access Network connectivity treated as sufficient\ntrust Privileged JavaScript evaluation exposed to debugger clients Debugger\nhelper functions expose local runtime resources\n\nImpact\n\nUnauthorized Debugger Access:\nAn unauthenticated client capable of reaching the debugger can\nestablish an interactive debugging session.\n\nArbitrary JavaScript Evaluation:\nThe connected client can submit JavaScript expressions for evaluation\nwithin the target Escargot runtime.\n\nLocal File Disclosure:\nFiles accessible through exposed runtime helper functions can be\nretrieved. Testing confirmed disclosure of /etc/passwd.\n\nRuntime State Exposure:\nAn attacker may inspect interpreter state and interact with other\nfunctionality exposed through the debugger.\n\nThe PoC demonstrates JavaScript evaluation and local file disclosure. It\ndoes not, by itself, establish arbitrary operating-system command execution\nor native code execution.\n\nProof of Concept\n\nStart a debugger-enabled Escargot build with the remote debugger enabled\nand connect using the debugger client.\n\nThe following debugger commands were used:\n\nb /tmp/rdf.js:2\nc\np read(\"/etc/passwd\")\nc\n\nOutput\n\nConnecting to: localhost:6516\nConnection created!!!\n\nStopped at /tmp/rdf.js:1\n\n(escargot-debugger) b /tmp/rdf.js:2\nBreakpoint 1 at /tmp/rdf.js:2\n\n(escargot-debugger) c\nStopped at breakpoint:1 /tmp/rdf.js:2\n\n(escargot-debugger) p read(\"/etc/passwd\")\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\n...\nnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin\nubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash\n\n(escargot-debugger) c\nPrint: debugger file read probe complete\nConnection closed.\n\nServer-side output confirmed that the debugger was listening and accepted\nthe connection:\n\nWaiting for client connection 0.0.0.0:6516\nConnected from: 127.0.0.1\n\ndebugger file read probe complete\n\nThe returned data matched the contents of /etc/passwd, confirming that the\ndebugger accepted an unauthenticated session, evaluated the supplied\nJavaScript expression, and returned local file contents to the debugger\nclient.\n\nRon Edgerson\nVulnerability Researcher \u0026 Exploit Developer\n\nCVE Research | Binary Exploitation | Application \u0026 Systems Security\nResponsible Disclosure \u2022 Proof-of-Concept Development\n\n\ud83c\udf10 https://github.com/ob1sec\n\ud83d\udd17 https://www.linkedin.com/in/ronedgerson1\n\u003chttps://linkedin.com/in/yourhandle\u003e\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-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/109"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/109"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/109"
],
"discovery": "EXTERNAL"
},
"title": "Escargot v4.3.0-214-gfaee4437 Unauthenticated Remote Debugger Allows Arbitrary JavaScript Evaluation and Local File Disclosure",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0081",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/109",
"automated": true,
"contentSha256": "28cd25d01ae4f1697daac4e44a6e8bccd50f4f79a2eb2e9f56308194335f7b3a",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/109",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T12:46:01Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0081"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0080
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Escargot v4.3.0-214-gfaee4437 OS Command Injection in Crash Handler via Unsanitized Executable Path
Summary
An OS command injection vulnerability exists in the Escargot
v4.3.0-214-gfaee4437 crash handler due to an executable/module path being
incorporated into an addr2line shell command without quoting or escaping.
The resulting command is executed using system(), causing shell
metacharacters contained within the path to be interpreted as command
syntax.
By launching Escargot using a crafted executable path containing shell
metacharacters and subsequently triggering the crash handler, arbitrary
shell commands can be executed with the privileges of the Escargot process.
Dynamic testing confirmed command execution by injecting a benign printf
command into the executable filename. Following a controlled crash, the
injected command executed and created a marker file containing
ESCARGOT_CMD_INJECTION_CONFIRMED.
Technical Details
During crash processing, Escargot generates symbolic stack-trace
information by constructing an addr2line command containing an
executable/module path obtained from the backtrace.
The affected code follows this pattern:
sprintf(
syscom,
"addr2line %s -e %s",
addr.c_str(),
modulePath.c_str());
system(syscom);
modulePath is inserted directly into the command string without shell
quoting, escaping, validation, or argument separation.
Because the resulting string is passed to system(), /bin/sh interprets
shell metacharacters contained within modulePath.
A path containing characters such as:
;
#
can therefore alter the structure of the intended addr2line command and
introduce additional shell commands.
Root Cause
Use of system() to invoke addr2line
Shell command constructed using sprintf()
Executable/module path inserted directly into command
No shell escaping or quoting
No validation of shell metacharacters
No argument separation
The fundamental issue is that a filesystem path is treated as part of a
shell command rather than as an opaque argument to the addr2line executable
Security Impact
An attacker capable of influencing the executable or module path processed
by the crash handler and causing the affected crash-handling path to
execute may run arbitrary operating-system commands with the privileges of
the Escargot process.
Potential impact includes:
Arbitrary OS Command Execution:
Injected shell commands execute in the context of the crashing process.
File Creation or Modification:
Commands can create or modify files accessible to the process.
Local Resource Access:
Injected commands inherit the filesystem and operating-system
permissions of the Escargot process.
Further Host Compromise:
Impact may increase depending on the privileges and execution
environment of the affected process.
The demonstrated PoC establishes command execution under conditions where
the executable path is attacker-controlled. It does not independently
establish that a remote attacker can control the executable/module path in
a standard Escargot deployment.
PoC Results
======================================================================
PoC: Shell Crash Handler Command Injection
======================================================================
[+] RESULT: VULNERABILITY CONFIRMED
[+] Command injection successfully triggered through the crash-handler
executable path.
[+] Injection Payload
printf${IFS}ESCARGOT_CMD_INJECTION_CONFIRMED>escargot_cmd_injection_proof
[+] Crafted Executable Path
/tmp/escargot-poc-bin/escargot;printf${IFS}ESCARGOT_CMD_INJECTION_CONFIRMED>escargot_cmd_injection_proof;#
[+] Crash Trigger
Signal: SIGABRT (6)
Return Code: -6
PID: 3988
[+] Arbitrary Command Execution Evidence
Proof File:
/work/escargot/security-poc/build-debugger-test/escargot_cmd_injection_proof
File Created: YES
File Contents:
ESCARGOT_CMD_INJECTION_CONFIRMED
[+] Exploitation Chain
1. Escargot is executed from a path containing shell metacharacters.
2. A controlled crash triggers the crash/signal handler.
3. The handler incorporates the executable path into a shell command.
4. Shell metacharacters in the executable path are interpreted.
5. The injected printf command executes.
6. A proof file containing the expected marker is created.
[+] Relevant Runtime Evidence
Waiting for client connection 0.0.0.0:6514
Connected from: 127.0.0.1
Assertion `false' failed.
Got signal 6, pid 3988
[bt] Execution path:
...
addr2line: '/tmp/escargot-poc-bin/escargot': No such file
[+] Verification
Expected marker: ESCARGOT_CMD_INJECTION_CONFIRMED
Observed marker: ESCARGOT_CMD_INJECTION_CONFIRMED
Ron Edgerson
Vulnerability Researcher & Exploit Developer
CVE Research | Binary Exploitation | Application & Systems Security
Responsible Disclosure • Proof-of-Concept Development
🌐 https://github.com/ob1sec
🔗 https://www.linkedin.com/in/ronedgerson1
<https://linkedin.com/in/yourhandle>
_______________________________________________
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
7 references
{
"containers": {
"cna": {
"affected": [
{
"product": "Escargot",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "An OS command injection vulnerability exists in the Escargot\nv4.3.0-214-gfaee4437 crash handler due to an executable/module path being\nincorporated into an addr2line shell command without quoting or escaping.\nThe resulting command is executed using system(), causing shell\nmetacharacters contained within the path to be interpreted as command\nsyntax.\n\nBy launching Escargot using a crafted executable path containing shell\nmetacharacters and subsequently triggering the crash handler, arbitrary\nshell commands can be executed with the privileges of the Escargot process.\n\nDynamic testing confirmed command execution by injecting a benign printf\ncommand into the executable filename. Following a controlled crash, the\ninjected command executed and created a marker file containing\nESCARGOT_CMD_INJECTION_CONFIRMED.\n\n\nTechnical Details\n\nDuring crash processing, Escargot generates symbolic stack-trace\ninformation by constructing an addr2line command containing an\nexecutable/module path obtained from the backtrace.\n\nThe affected code follows this pattern:\n\nsprintf(\n syscom,\n \"addr2line %s -e %s\",\n addr.c_str(),\n modulePath.c_str());\n\nsystem(syscom);\n\nmodulePath is inserted directly into the command string without shell\nquoting, escaping, validation, or argument separation.\n\nBecause the resulting string is passed to system(), /bin/sh interprets\nshell metacharacters contained within modulePath.\n\nA path containing characters such as:\n\n;\n\n\n#\n\ncan therefore alter the structure of the intended addr2line command and\nintroduce additional shell commands.\n\nRoot Cause\n\nUse of system() to invoke addr2line\nShell command constructed using sprintf()\nExecutable/module path inserted directly into command\nNo shell escaping or quoting\nNo validation of shell metacharacters\nNo argument separation\n\nThe fundamental issue is that a filesystem path is treated as part of a\nshell command rather than as an opaque argument to the addr2line executable\nSecurity Impact\n\nAn attacker capable of influencing the executable or module path processed\nby the crash handler and causing the affected crash-handling path to\nexecute may run arbitrary operating-system commands with the privileges of\nthe Escargot process.\n\nPotential impact includes:\n\nArbitrary OS Command Execution:\nInjected shell commands execute in the context of the crashing process.\n\nFile Creation or Modification:\nCommands can create or modify files accessible to the process.\n\nLocal Resource Access:\nInjected commands inherit the filesystem and operating-system\npermissions of the Escargot process.\n\nFurther Host Compromise:\nImpact may increase depending on the privileges and execution\nenvironment of the affected process.\n\nThe demonstrated PoC establishes command execution under conditions where\nthe executable path is attacker-controlled. It does not independently\nestablish that a remote attacker can control the executable/module path in\na standard Escargot deployment.\n\nPoC Results\n======================================================================\n PoC: Shell Crash Handler Command Injection\n======================================================================\n\n[+] RESULT: VULNERABILITY CONFIRMED\n\n[+] Command injection successfully triggered through the crash-handler\n executable path.\n\n[+] Injection Payload\n\nprintf${IFS}ESCARGOT_CMD_INJECTION_CONFIRMED\u003eescargot_cmd_injection_proof\n\n[+] Crafted Executable Path\n\n/tmp/escargot-poc-bin/escargot;printf${IFS}ESCARGOT_CMD_INJECTION_CONFIRMED\u003eescargot_cmd_injection_proof;#\n\n[+] Crash Trigger\n Signal: SIGABRT (6)\n Return Code: -6\n PID: 3988\n\n[+] Arbitrary Command Execution Evidence\n Proof File:\n\n/work/escargot/security-poc/build-debugger-test/escargot_cmd_injection_proof\n\n File Created: YES\n\n File Contents:\n ESCARGOT_CMD_INJECTION_CONFIRMED\n\n[+] Exploitation Chain\n 1. Escargot is executed from a path containing shell metacharacters.\n 2. A controlled crash triggers the crash/signal handler.\n 3. The handler incorporates the executable path into a shell command.\n 4. Shell metacharacters in the executable path are interpreted.\n 5. The injected printf command executes.\n 6. A proof file containing the expected marker is created.\n\n[+] Relevant Runtime Evidence\n\n Waiting for client connection 0.0.0.0:6514\n Connected from: 127.0.0.1\n\n Assertion `false\u0027 failed.\n Got signal 6, pid 3988\n\n [bt] Execution path:\n ...\n addr2line: \u0027/tmp/escargot-poc-bin/escargot\u0027: No such file\n\n[+] Verification\n Expected marker: ESCARGOT_CMD_INJECTION_CONFIRMED\n Observed marker: ESCARGOT_CMD_INJECTION_CONFIRMED\n\n\nRon Edgerson\nVulnerability Researcher \u0026 Exploit Developer\n\nCVE Research | Binary Exploitation | Application \u0026 Systems Security\nResponsible Disclosure \u2022 Proof-of-Concept Development\n\n\ud83c\udf10 https://github.com/ob1sec\n\ud83d\udd17 https://www.linkedin.com/in/ronedgerson1\n\u003chttps://linkedin.com/in/yourhandle\u003e\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-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/108"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/108"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/108"
],
"discovery": "EXTERNAL"
},
"title": "Escargot v4.3.0-214-gfaee4437 OS Command Injection in Crash Handler via Unsanitized Executable Path",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0080",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/108",
"automated": true,
"contentSha256": "1bb3c9a8c0d0644790e28a16fefc18c8d372406899013eaad89d9793831b8434",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/108",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T12:45:16Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0080"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0079
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Escargot v4.3.0-214-gfaee4437 Debugger WebSocket Off-by-One Stack Buffer Overflow
Summary
Escargot contains a remotely triggerable one-byte stack-based out-of-bounds
write in the WebSocket message handling logic used by the debugger.
When Escargot::DebuggerTcp::receive() receives a binary WebSocket payload
that completely fills the caller-provided stack buffer, the function
successfully copies the payload into the available buffer space but
subsequently appends an additional NUL byte without verifying that space
remains for the terminator.
A 125-byte binary WebSocket payload causes the debugger to write the
terminating NUL byte to buffer[125], immediately beyond the end of the
125-byte stack allocation.
A proof-of-concept client establishes a valid WebSocket connection to the
Escargot debugger endpoint and sends the boundary-sized binary frame.
AddressSanitizer consistently detects the resulting stack-buffer overflow
inside Escargot::DebuggerTcp::receive().
The vulnerability results in stack memory corruption and can remotely
terminate an Escargot process exposing the debugger interface. The current
proof of concept demonstrates reliable denial of service and memory
corruption but does not establish arbitrary code execution.
Vulnerable Code
The debugger decodes the incoming masked WebSocket payload directly into a
caller-provided buffer:
const uint8_t* source = mask_end;
uint8_t* buffer_end = buffer + m_payloadLength;
while (buffer < buffer_end) {
*buffer++ = *source++ ^ *mask++;
if (mask >= mask_end) {
mask -= 4;
}
}
*buffer_end = 0;
The payload copy itself does not exceed the destination when the payload
length exactly equals the destination capacity.
The vulnerability occurs immediately afterward:
*buffer_end = 0;
Because buffer_end is calculated as:
buffer + m_payloadLength
a payload that completely fills the destination causes buffer_end to point
exactly one byte beyond the allocated object.
The implementation does not receive or validate the destination buffer
capacity before performing this additional write.
Root Cause
The vulnerability is an off-by-one error caused by treating a fixed-size
binary buffer as though it always contains sufficient additional capacity
for a NUL terminator.
The affected caller uses a 125-byte stack buffer. With a 125-byte payload,
the copy operation occupies the complete valid range:
buffer[0] ... buffer[124]
After the copy completes:
buffer_end == &buffer[125];
The subsequent operation:
*buffer_end = 0;
is therefore equivalent to:
buffer[125] = '\0';
For a 125-byte allocation, index 125 is outside the object. Valid indexes
are only 0 through 124.
This results in a one-byte stack-based out-of-bounds write.
Proof of Concept
The PoC was executed against an AddressSanitizer-instrumented Escargot
build:
[*] Target binary :
/work/escargot/security-poc/build-debugger-asan/escargot
[*] Debugger URL :
ws://127.0.0.1:6611/escargot-debugger
[*] Payload :
125-byte binary frame
[*] Bug trigger :
DebuggerTcp::receive() writes NUL at buffer[payloadLength]
The client first performs a legitimate WebSocket handshake.
The Escargot debugger accepts the connection:
[+] WebSocket handshake accepted
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: voBbwZEm0j70WZ2O4Hx37ERFeqA=
This confirms that the PoC reaches the debugger through the expected
WebSocket protocol rather than invoking the vulnerable function directly.
The client then sends the boundary-sized binary frame:
[*] Sending binary frame:
opcode=0x2
payload_len=125
The test reports successful reproduction:
[+] Confirmed: True[*] Process return code: -6
The -6 return code corresponds to process termination through SIGABRT. In
this test configuration, the important evidence is not the return code
itself but the accompanying AddressSanitizer report identifying the invalid
stack write.
AddressSanitizer Evidence
AddressSanitizer reports a stack-buffer overflow directly within the
vulnerable receive function:
[evidence] SUMMARY: AddressSanitizer: stack-buffer-overflow
(/work/escargot/security-poc/build-debugger-asan/escargot+0x4fe03c)
(BuildId: 1545896c0ed347436f48a03cdab84e73c634fadd)
in Escargot::DebuggerTcp::receive(unsigned char*, unsigned long&)
The top of the stack trace identifies DebuggerTcp::receive() as the
location of the invalid memory access:
[evidence] #0 0xaaaadfd0e03c
in Escargot::DebuggerTcp::receive(unsigned char*, unsigned long&)
(/work/escargot/security-poc/build-debugger-asan/escargot+0x4fe03c)
[evidence] #1 0xaaaadfcfeb98
in Escargot::DebuggerEscargot::processEvents(
Escargot::ExecutionState*,
Escargot::Optional<Escargot::ByteCodeBlock*>,
bool
)
/work/escargot/src/debugger/DebuggerEscargot.cpp:767
Most importantly, AddressSanitizer identifies the precise stack object that
is exceeded:
[evidence] [800, 925) 'buffer' (line 762)
<== Memory access at offset 925 overflows this variable
The buffer object occupies stack offsets:
[800, 925)
This represents exactly:
925 - 800 = 125 bytes
The first byte outside the allocation is offset 925.
AddressSanitizer reports the invalid access at exactly that offset:
Memory access at offset 925 overflows this variable
The runtime evidence therefore precisely matches the source-level defect.
For a 125-byte buffer:
Stack object: [800, 925)
Buffer size: 125 bytes
Valid offsets: 800 through 924
Invalid write: 925
Overflow distance: 1 byte
Ron Edgerson
Vulnerability Researcher & Exploit Developer
CVE Research | Binary Exploitation | Application & Systems Security
Responsible Disclosure • Proof-of-Concept Development
🌐 https://github.com/ob1sec
🔗 https://www.linkedin.com/in/ronedgerson1
<https://linkedin.com/in/yourhandle>
_______________________________________________
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
7 references
{
"containers": {
"cna": {
"affected": [
{
"product": "Escargot",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "Escargot contains a remotely triggerable one-byte stack-based out-of-bounds\nwrite in the WebSocket message handling logic used by the debugger.\n\nWhen Escargot::DebuggerTcp::receive() receives a binary WebSocket payload\nthat completely fills the caller-provided stack buffer, the function\nsuccessfully copies the payload into the available buffer space but\nsubsequently appends an additional NUL byte without verifying that space\nremains for the terminator.\n\nA 125-byte binary WebSocket payload causes the debugger to write the\nterminating NUL byte to buffer[125], immediately beyond the end of the\n125-byte stack allocation.\n\nA proof-of-concept client establishes a valid WebSocket connection to the\nEscargot debugger endpoint and sends the boundary-sized binary frame.\nAddressSanitizer consistently detects the resulting stack-buffer overflow\ninside Escargot::DebuggerTcp::receive().\n\nThe vulnerability results in stack memory corruption and can remotely\nterminate an Escargot process exposing the debugger interface. The current\nproof of concept demonstrates reliable denial of service and memory\ncorruption but does not establish arbitrary code execution.\nVulnerable Code\n\nThe debugger decodes the incoming masked WebSocket payload directly into a\ncaller-provided buffer:\n\nconst uint8_t* source = mask_end;\nuint8_t* buffer_end = buffer + m_payloadLength;\n\nwhile (buffer \u003c buffer_end) {\n *buffer++ = *source++ ^ *mask++;\n\n if (mask \u003e= mask_end) {\n mask -= 4;\n }\n}\n\n*buffer_end = 0;\n\nThe payload copy itself does not exceed the destination when the payload\nlength exactly equals the destination capacity.\n\nThe vulnerability occurs immediately afterward:\n\n*buffer_end = 0;\n\nBecause buffer_end is calculated as:\n\nbuffer + m_payloadLength\n\na payload that completely fills the destination causes buffer_end to point\nexactly one byte beyond the allocated object.\n\nThe implementation does not receive or validate the destination buffer\ncapacity before performing this additional write.\nRoot Cause\n\nThe vulnerability is an off-by-one error caused by treating a fixed-size\nbinary buffer as though it always contains sufficient additional capacity\nfor a NUL terminator.\n\nThe affected caller uses a 125-byte stack buffer. With a 125-byte payload,\nthe copy operation occupies the complete valid range:\n\nbuffer[0] ... buffer[124]\n\nAfter the copy completes:\n\nbuffer_end == \u0026buffer[125];\n\nThe subsequent operation:\n\n*buffer_end = 0;\n\nis therefore equivalent to:\n\nbuffer[125] = \u0027\\0\u0027;\n\nFor a 125-byte allocation, index 125 is outside the object. Valid indexes\nare only 0 through 124.\n\nThis results in a one-byte stack-based out-of-bounds write.\nProof of Concept\n\nThe PoC was executed against an AddressSanitizer-instrumented Escargot\nbuild:\n\n[*] Target binary :\n /work/escargot/security-poc/build-debugger-asan/escargot\n[*] Debugger URL :\n ws://127.0.0.1:6611/escargot-debugger\n[*] Payload :\n 125-byte binary frame\n[*] Bug trigger :\n DebuggerTcp::receive() writes NUL at buffer[payloadLength]\n\nThe client first performs a legitimate WebSocket handshake.\n\nThe Escargot debugger accepts the connection:\n\n[+] WebSocket handshake accepted\n\nHTTP/1.1 101 Switching Protocols\nUpgrade: websocket\nConnection: Upgrade\nSec-WebSocket-Accept: voBbwZEm0j70WZ2O4Hx37ERFeqA=\n\nThis confirms that the PoC reaches the debugger through the expected\nWebSocket protocol rather than invoking the vulnerable function directly.\n\nThe client then sends the boundary-sized binary frame:\n\n[*] Sending binary frame:\n opcode=0x2\n payload_len=125\n\nThe test reports successful reproduction:\n\n[+] Confirmed: True[*] Process return code: -6\n\nThe -6 return code corresponds to process termination through SIGABRT. In\nthis test configuration, the important evidence is not the return code\nitself but the accompanying AddressSanitizer report identifying the invalid\nstack write.\nAddressSanitizer Evidence\n\nAddressSanitizer reports a stack-buffer overflow directly within the\nvulnerable receive function:\n\n[evidence] SUMMARY: AddressSanitizer: stack-buffer-overflow\n(/work/escargot/security-poc/build-debugger-asan/escargot+0x4fe03c)\n(BuildId: 1545896c0ed347436f48a03cdab84e73c634fadd)\nin Escargot::DebuggerTcp::receive(unsigned char*, unsigned long\u0026)\n\nThe top of the stack trace identifies DebuggerTcp::receive() as the\nlocation of the invalid memory access:\n\n[evidence] #0 0xaaaadfd0e03c\nin Escargot::DebuggerTcp::receive(unsigned char*, unsigned long\u0026)\n(/work/escargot/security-poc/build-debugger-asan/escargot+0x4fe03c)\n[evidence] #1 0xaaaadfcfeb98\nin Escargot::DebuggerEscargot::processEvents(\n Escargot::ExecutionState*,\n Escargot::Optional\u003cEscargot::ByteCodeBlock*\u003e,\n bool\n)\n/work/escargot/src/debugger/DebuggerEscargot.cpp:767\n\nMost importantly, AddressSanitizer identifies the precise stack object that\nis exceeded:\n\n[evidence] [800, 925) \u0027buffer\u0027 (line 762)\n \u003c== Memory access at offset 925 overflows this variable\n\nThe buffer object occupies stack offsets:\n\n[800, 925)\n\nThis represents exactly:\n\n925 - 800 = 125 bytes\n\nThe first byte outside the allocation is offset 925.\n\nAddressSanitizer reports the invalid access at exactly that offset:\n\nMemory access at offset 925 overflows this variable\n\nThe runtime evidence therefore precisely matches the source-level defect.\n\nFor a 125-byte buffer:\n\nStack object: [800, 925)\nBuffer size: 125 bytes\nValid offsets: 800 through 924\nInvalid write: 925\nOverflow distance: 1 byte\n\n\nRon Edgerson\nVulnerability Researcher \u0026 Exploit Developer\n\nCVE Research | Binary Exploitation | Application \u0026 Systems Security\nResponsible Disclosure \u2022 Proof-of-Concept Development\n\n\ud83c\udf10 https://github.com/ob1sec\n\ud83d\udd17 https://www.linkedin.com/in/ronedgerson1\n\u003chttps://linkedin.com/in/yourhandle\u003e\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-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/107"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/107"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/107"
],
"discovery": "EXTERNAL"
},
"title": "Escargot v4.3.0-214-gfaee4437 Debugger WebSocket Off-by-One Stack Buffer Overflow",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0079",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/107",
"automated": true,
"contentSha256": "6f519fea0759d29f0585a9df71b4ffec8f8b9e4a738c15c3324b929ad2764a89",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/107",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T12:44:45Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0079"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0075
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Chronicle Wire v2026.8 Arbitrary Class Instantiation During YAML Deserialization via Externally Controlled YAML Type Tags
Summary
Chronicle Wire permits YAML type tags supplied within serialized input to
influence Java class selection and object instantiation during untyped
deserialization.
When applications deserialize attacker-controlled or otherwise untrusted
YAML through APIs such as readObject() or object(Object.class), an
externally controlled YAML type tag can identify a Java class that
Chronicle Wire resolves through its configured ClassLookup.
When the default permissive class lookup is used and the supplied class can
be resolved, the resulting class can propagate through Chronicle Wire's
generic object deserialization path and ultimately reach
ObjectUtils.newInstance(clazz). Chronicle Wire can then invoke the selected
class's deserialization lifecycle, including readMarshallable() where
applicable.
The security-sensitive behavior is therefore not limited to ordinary data
binding. Externally supplied serialized data can influence *which Java
class is instantiated during deserialization*.
The accompanying proof of concept confirms that:
- An externally controlled YAML type tag selects the Java class
instantiated by readObject().
- The selected class's constructor is executed.
- A selected class's readMarshallable() implementation is automatically
invoked during deserialization.
- An existing third-party class already present on the runtime classpath
can be instantiated using a YAML type tag.
- Configuring a restrictive ClassLookup prevents the demonstrated
arbitrary class selection.
The practical security impact depends on the classes available on the
target application's classpath and whether untrusted YAML reaches an
affected untyped deserialization API. The PoC establishes the arbitrary
class-selection and instantiation primitive but does not claim universal
arbitrary code execution.
Vulnerability Details
Chronicle Wire supports YAML type tags capable of identifying Java classes
during deserialization.
For example:
!fully.qualified.ClassName
The parser does not treat this value solely as descriptive metadata. The
supplied class name is resolved using the wire's configured ClassLookup.
The default wire configuration initializes the lookup using the global
alias pool:
protected ClassLookup classLookup =
ClassAliasPool.CLASS_ALIASES;
When a YAML TAG token is encountered, the supplied type is resolved:
Class<?> typePrefix() {
...
return classLookup().forName(stringBuilder);
}
The class represented by the serialized YAML can therefore influence the
Java type selected during deserialization.
In affected object-reading paths, Chronicle Wire can subsequently
instantiate the resolved class:
Class<?> clazz = typePrefix();
if (clazz != object.getClass())
object = ObjectUtils.newInstance(clazz);
The externally selected type can also propagate into the generic object
deserialization path:
Object o = typePrefixOrObject(clazz);
...
t = Wires.object2(..., (Class) o);
Within Wires.object2(), the type supplied by serialized input can replace
the caller's original type under several conditions:
if (clazz == null
|| clazz.isAssignableFrom(clazz2)
|| ReadResolvable.class.isAssignableFrom(clazz2)
|| !ObjectUtils.isConcreteClass(clazz))
{
clazz = clazz2;
}
Chronicle Wire can then instantiate the selected class:
if (o == null)
o = ObjectUtils.newInstance(clazz);
and continue the object's deserialization lifecycle:
Wires.readMarshallable(
clazz,
o,
in.wireIn(),
true);
As a result, when permissive class resolution is available, externally
controlled YAML can influence both the class instantiated by Chronicle Wire
and the class-specific deserialization logic subsequently executed.
Root Cause
The root cause is the use of serialized YAML type information to select
Java classes during generic or untyped object deserialization without a
mandatory deny-by-default class allow-list.
Chronicle Wire resolves externally supplied YAML type tags through its
configured ClassLookup. When the default permissive lookup permits the
requested type, the resulting class can propagate into generic object
deserialization and reach ObjectUtils.newInstance().
The security boundary becomes particularly important when an application
performs operations such as:
TextWire.from(untrustedYaml).readObject();
or equivalent untyped deserialization.
In this situation, the application is not exclusively determining the Java
class being constructed. The serialized YAML participates in that decision.
A restrictive ClassLookup can prevent arbitrary class resolution, but such
a restriction is not inherent to the demonstrated default deserialization
path.
Proof of Concept Results
The security test suite successfully reproduced multiple independent paths
in which serialized type information caused Chronicle Wire to instantiate
classes selected through the supplied Wire/YAML data.
The tests completed successfully with no failures or errors:
[INFO] Running net.openhft.chronicle.wire.SecurityAdditionalPoCTest
[INFO] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS
Direct Tagged Class Instantiation
The PoC confirmed that Chronicle Wire resolves a supplied YAML type tag and
instantiates the corresponding Java class during deserialization.
Observed result:
WireObjectInput.readObject instantiated tagged class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$AdditionalTypedPathProbe
This confirms that the class encoded in serialized input is not merely
parsed as metadata. The resolved type reaches object construction and
results in an instance of the tagged class.
Map Value Type Instantiation
The same externally controlled type-selection behavior was reproduced while
deserializing a typed value contained within a map.
Observed result:
Map value read instantiated tagged class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$AdditionalTypedPathProbe
This demonstrates that the behavior is not limited to a single top-level
readObject() operation. Typed serialized values encountered within other
object-reading paths can also cause tagged classes to be instantiated.
File-Based Typed Deserialization
The PoC additionally confirmed arbitrary class instantiation when typed
serialized data is loaded from a caller-controlled file.
The test file contained:
!net.openhft.chronicle.wire.SecurityAdditionalPoCTest$FilePathProbe {
marker: from-file
}
The test output confirmed the exact payload written to the file:
WireType.fromFile payload written BEGIN
!net.openhft.chronicle.wire.SecurityAdditionalPoCTest$FilePathProbe {
marker: from-file }
WireType.fromFile payload written END
Chronicle Wire subsequently instantiated the class identified by the
serialized type tag:
WireType.fromFile instantiated tagged class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$FilePathProbe
This provides an additional concrete deserialization path where serialized
type information determines the Java class instantiated by Chronicle Wire.
Stream-Based File Deserialization
The same behavior was confirmed through the file-stream deserialization
path.
Observed result:
WireType.streamFromFile instantiated tagged class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$AdditionalTypedPathProbe
This demonstrates that externally supplied type information can reach class
instantiation through more than one Chronicle Wire input API.
Constructor and readMarshallable() Execution
The strongest lifecycle evidence was produced through a MethodReader typed
argument.
The serialized argument selected the following class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe
The test recorded both constructor and deserialization callback invocation:
MethodReader typed argument instantiated class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe
MethodReader typed argument constructor calls: 1
MethodReader typed argument readMarshallable calls: 1
This confirms that externally selected type information can result in more
than creation of an inert Java object.
For the selected class, Chronicle Wire caused:
-
the class to be resolved;
-
an instance to be constructed;
-
the constructor to execute; and
-
the class-specific readMarshallable() callback to execute.
The observed invocation counts were:
Constructor calls: 1
readMarshallable calls: 1
This provides direct evidence that class-specific executable lifecycle
behavior is reached as a consequence of serialized type selection.
Consolidated PoC Evidence
The test results demonstrate arbitrary class instantiation through several
Chronicle Wire deserialization paths:
-
WireObjectInput.readObject() instantiated an externally tagged class.
-
Map value deserialization instantiated an externally tagged class.
-
WireType.fromFile() instantiated the class identified by a YAML type tag
contained in a caller-controlled file.
-
WireType.streamFromFile() instantiated an externally tagged class.
-
MethodReader typed argument deserialization instantiated an externally
selected class.
-
Constructor execution was directly observed.
-
readMarshallable() execution was directly observed.
-
All 13 security tests completed without failure or error.
The most significant lifecycle result was:
MethodReader typed argument instantiated class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe
MethodReader typed argument constructor calls: 1
MethodReader typed argument readMarshallable calls: 1
Combined with the direct readObject(), map-value, fromFile(), and
streamFromFile() results, the PoC demonstrates that externally supplied
type information can influence Java class selection and cause the selected
class to be instantiated across multiple Chronicle Wire deserialization
surfaces.
The PoC does not rely solely on inspecting the source code or confirming
that a class name was successfully resolved. It observes actual object
construction and class-specific deserialization callback execution at
runtime.
PoC Conclusion
The test suite confirms the core security primitive described by this
finding: *serialized type information can control which Java class
Chronicle Wire instantiates during affected deserialization operations*.
The runtime evidence confirms both object construction and execution of
class-specific deserialization lifecycle behavior:
[CONFIRMED] Externally supplied type selected Java class
[CONFIRMED] Selected class instantiated
[CONFIRMED] Constructor executed
[CONFIRMED] readMarshallable() executed
[CONFIRMED] Typed class instantiated through readObject()
[CONFIRMED] Typed class instantiated through map value deserialization
[CONFIRMED] Typed class instantiated through WireType.fromFile()
[CONFIRMED] Typed class instantiated through WireType.streamFromFile()
[CONFIRMED] 13 security tests completed with 0 failures and 0 errors
These results establish the *arbitrary class selection and instantiation
primitive*. The ultimate security impact remains dependent on the classes
available on the target application's classpath and the trust boundary
through which serialized input reaches Chronicle Wire.
Ron Edgerson
Vulnerability Researcher & Exploit Developer
CVE Research | Binary Exploitation | Application & Systems Security
Responsible Disclosure • Proof-of-Concept Development
🌐 https://github.com/ob1sec
🔗 https://www.linkedin.com/in/ronedgerson1
<https://linkedin.com/in/yourhandle>
_______________________________________________
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
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Chronicle Wire |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Chronicle Wire",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "Chronicle Wire permits YAML type tags supplied within serialized input to\ninfluence Java class selection and object instantiation during untyped\ndeserialization.\n\nWhen applications deserialize attacker-controlled or otherwise untrusted\nYAML through APIs such as readObject() or object(Object.class), an\nexternally controlled YAML type tag can identify a Java class that\nChronicle Wire resolves through its configured ClassLookup.\n\nWhen the default permissive class lookup is used and the supplied class can\nbe resolved, the resulting class can propagate through Chronicle Wire\u0027s\ngeneric object deserialization path and ultimately reach\nObjectUtils.newInstance(clazz). Chronicle Wire can then invoke the selected\nclass\u0027s deserialization lifecycle, including readMarshallable() where\napplicable.\n\nThe security-sensitive behavior is therefore not limited to ordinary data\nbinding. Externally supplied serialized data can influence *which Java\nclass is instantiated during deserialization*.\n\nThe accompanying proof of concept confirms that:\n\n - An externally controlled YAML type tag selects the Java class\n instantiated by readObject().\n - The selected class\u0027s constructor is executed.\n - A selected class\u0027s readMarshallable() implementation is automatically\n invoked during deserialization.\n - An existing third-party class already present on the runtime classpath\n can be instantiated using a YAML type tag.\n - Configuring a restrictive ClassLookup prevents the demonstrated\n arbitrary class selection.\n\nThe practical security impact depends on the classes available on the\ntarget application\u0027s classpath and whether untrusted YAML reaches an\naffected untyped deserialization API. The PoC establishes the arbitrary\nclass-selection and instantiation primitive but does not claim universal\narbitrary code execution.\nVulnerability Details\n\nChronicle Wire supports YAML type tags capable of identifying Java classes\nduring deserialization.\n\nFor example:\n\n!fully.qualified.ClassName\n\nThe parser does not treat this value solely as descriptive metadata. The\nsupplied class name is resolved using the wire\u0027s configured ClassLookup.\n\nThe default wire configuration initializes the lookup using the global\nalias pool:\n\nprotected ClassLookup classLookup =\n ClassAliasPool.CLASS_ALIASES;\n\nWhen a YAML TAG token is encountered, the supplied type is resolved:\n\nClass\u003c?\u003e typePrefix() {\n ...\n return classLookup().forName(stringBuilder);\n}\n\nThe class represented by the serialized YAML can therefore influence the\nJava type selected during deserialization.\n\nIn affected object-reading paths, Chronicle Wire can subsequently\ninstantiate the resolved class:\n\nClass\u003c?\u003e clazz = typePrefix();\n\nif (clazz != object.getClass())\n object = ObjectUtils.newInstance(clazz);\n\nThe externally selected type can also propagate into the generic object\ndeserialization path:\n\nObject o = typePrefixOrObject(clazz);\n\n...\n\nt = Wires.object2(..., (Class) o);\n\nWithin Wires.object2(), the type supplied by serialized input can replace\nthe caller\u0027s original type under several conditions:\n\nif (clazz == null\n || clazz.isAssignableFrom(clazz2)\n || ReadResolvable.class.isAssignableFrom(clazz2)\n || !ObjectUtils.isConcreteClass(clazz))\n{\n clazz = clazz2;\n}\n\nChronicle Wire can then instantiate the selected class:\n\nif (o == null)\n o = ObjectUtils.newInstance(clazz);\n\nand continue the object\u0027s deserialization lifecycle:\n\nWires.readMarshallable(\n clazz,\n o,\n in.wireIn(),\n true);\n\nAs a result, when permissive class resolution is available, externally\ncontrolled YAML can influence both the class instantiated by Chronicle Wire\nand the class-specific deserialization logic subsequently executed.\nRoot Cause\n\nThe root cause is the use of serialized YAML type information to select\nJava classes during generic or untyped object deserialization without a\nmandatory deny-by-default class allow-list.\n\nChronicle Wire resolves externally supplied YAML type tags through its\nconfigured ClassLookup. When the default permissive lookup permits the\nrequested type, the resulting class can propagate into generic object\ndeserialization and reach ObjectUtils.newInstance().\n\nThe security boundary becomes particularly important when an application\nperforms operations such as:\n\nTextWire.from(untrustedYaml).readObject();\n\nor equivalent untyped deserialization.\n\nIn this situation, the application is not exclusively determining the Java\nclass being constructed. The serialized YAML participates in that decision.\n\nA restrictive ClassLookup can prevent arbitrary class resolution, but such\na restriction is not inherent to the demonstrated default deserialization\npath.\nProof of Concept Results\n\nThe security test suite successfully reproduced multiple independent paths\nin which serialized type information caused Chronicle Wire to instantiate\nclasses selected through the supplied Wire/YAML data.\n\nThe tests completed successfully with no failures or errors:\n\n[INFO] Running net.openhft.chronicle.wire.SecurityAdditionalPoCTest\n\n[INFO] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0\n\n[INFO] BUILD SUCCESS\n\nDirect Tagged Class Instantiation\n\nThe PoC confirmed that Chronicle Wire resolves a supplied YAML type tag and\ninstantiates the corresponding Java class during deserialization.\n\nObserved result:\n\nWireObjectInput.readObject instantiated tagged class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$AdditionalTypedPathProbe\n\nThis confirms that the class encoded in serialized input is not merely\nparsed as metadata. The resolved type reaches object construction and\nresults in an instance of the tagged class.\nMap Value Type Instantiation\n\nThe same externally controlled type-selection behavior was reproduced while\ndeserializing a typed value contained within a map.\n\nObserved result:\n\nMap value read instantiated tagged class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$AdditionalTypedPathProbe\n\nThis demonstrates that the behavior is not limited to a single top-level\nreadObject() operation. Typed serialized values encountered within other\nobject-reading paths can also cause tagged classes to be instantiated.\nFile-Based Typed Deserialization\n\nThe PoC additionally confirmed arbitrary class instantiation when typed\nserialized data is loaded from a caller-controlled file.\n\nThe test file contained:\n\n!net.openhft.chronicle.wire.SecurityAdditionalPoCTest$FilePathProbe {\n marker: from-file\n}\n\nThe test output confirmed the exact payload written to the file:\n\nWireType.fromFile payload written BEGIN\n!net.openhft.chronicle.wire.SecurityAdditionalPoCTest$FilePathProbe {\nmarker: from-file }\nWireType.fromFile payload written END\n\nChronicle Wire subsequently instantiated the class identified by the\nserialized type tag:\n\nWireType.fromFile instantiated tagged class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$FilePathProbe\n\nThis provides an additional concrete deserialization path where serialized\ntype information determines the Java class instantiated by Chronicle Wire.\nStream-Based File Deserialization\n\nThe same behavior was confirmed through the file-stream deserialization\npath.\n\nObserved result:\n\nWireType.streamFromFile instantiated tagged class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$AdditionalTypedPathProbe\n\nThis demonstrates that externally supplied type information can reach class\ninstantiation through more than one Chronicle Wire input API.\nConstructor and readMarshallable() Execution\n\nThe strongest lifecycle evidence was produced through a MethodReader typed\nargument.\n\nThe serialized argument selected the following class:\n\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe\n\nThe test recorded both constructor and deserialization callback invocation:\n\nMethodReader typed argument instantiated class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe\n\nMethodReader typed argument constructor calls: 1\nMethodReader typed argument readMarshallable calls: 1\n\nThis confirms that externally selected type information can result in more\nthan creation of an inert Java object.\n\nFor the selected class, Chronicle Wire caused:\n\n -\n\n the class to be resolved;\n -\n\n an instance to be constructed;\n -\n\n the constructor to execute; and\n -\n\n the class-specific readMarshallable() callback to execute.\n\nThe observed invocation counts were:\n\nConstructor calls: 1\nreadMarshallable calls: 1\n\nThis provides direct evidence that class-specific executable lifecycle\nbehavior is reached as a consequence of serialized type selection.\nConsolidated PoC Evidence\n\nThe test results demonstrate arbitrary class instantiation through several\nChronicle Wire deserialization paths:\n\n -\n\n WireObjectInput.readObject() instantiated an externally tagged class.\n -\n\n Map value deserialization instantiated an externally tagged class.\n -\n\n WireType.fromFile() instantiated the class identified by a YAML type tag\n contained in a caller-controlled file.\n -\n\n WireType.streamFromFile() instantiated an externally tagged class.\n -\n\n MethodReader typed argument deserialization instantiated an externally\n selected class.\n -\n\n Constructor execution was directly observed.\n -\n\n readMarshallable() execution was directly observed.\n -\n\n All 13 security tests completed without failure or error.\n\nThe most significant lifecycle result was:\n\nMethodReader typed argument instantiated class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe\n\nMethodReader typed argument constructor calls: 1\nMethodReader typed argument readMarshallable calls: 1\n\nCombined with the direct readObject(), map-value, fromFile(), and\nstreamFromFile() results, the PoC demonstrates that externally supplied\ntype information can influence Java class selection and cause the selected\nclass to be instantiated across multiple Chronicle Wire deserialization\nsurfaces.\n\nThe PoC does not rely solely on inspecting the source code or confirming\nthat a class name was successfully resolved. It observes actual object\nconstruction and class-specific deserialization callback execution at\nruntime.\nPoC Conclusion\n\nThe test suite confirms the core security primitive described by this\nfinding: *serialized type information can control which Java class\nChronicle Wire instantiates during affected deserialization operations*.\n\nThe runtime evidence confirms both object construction and execution of\nclass-specific deserialization lifecycle behavior:\n\n[CONFIRMED] Externally supplied type selected Java class\n[CONFIRMED] Selected class instantiated\n[CONFIRMED] Constructor executed\n[CONFIRMED] readMarshallable() executed\n[CONFIRMED] Typed class instantiated through readObject()\n[CONFIRMED] Typed class instantiated through map value deserialization\n[CONFIRMED] Typed class instantiated through WireType.fromFile()\n[CONFIRMED] Typed class instantiated through WireType.streamFromFile()\n[CONFIRMED] 13 security tests completed with 0 failures and 0 errors\n\nThese results establish the *arbitrary class selection and instantiation\nprimitive*. The ultimate security impact remains dependent on the classes\navailable on the target application\u0027s classpath and the trust boundary\nthrough which serialized input reaches Chronicle Wire.\n\nRon Edgerson\nVulnerability Researcher \u0026 Exploit Developer\n\nCVE Research | Binary Exploitation | Application \u0026 Systems Security\nResponsible Disclosure \u2022 Proof-of-Concept Development\n\n\ud83c\udf10 https://github.com/ob1sec\n\ud83d\udd17 https://www.linkedin.com/in/ronedgerson1\n\u003chttps://linkedin.com/in/yourhandle\u003e\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-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/103"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/103"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/103"
],
"discovery": "EXTERNAL"
},
"title": "Chronicle Wire v2026.8 Arbitrary Class Instantiation During YAML Deserialization via Externally Controlled YAML Type Tags",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0075",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/103",
"automated": true,
"contentSha256": "373857b24efd6a689043e6cf615e0c3a0a62392da12986dc20b6425ac929092f",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/103",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T12:42:32Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0075"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
displaying 361 - 370 publications in total 387