{"vulnerability": "CVE-2018-6574", "sightings": [{"uuid": "cb15d9b8-97fe-4069-a24c-bbe1a882fe26", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/PUKf0-PASCJRuF1Au3buYtrAber6R__9dLwnJgtfHs7Vf5Q", "content": "", "creation_timestamp": "2025-06-14T12:07:21.000000Z"}, {"uuid": "8f4cdb03-e3e0-4583-858f-124df3a02fff", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/17439", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aRCE\n\u63cf\u8ff0\uff1aOrangeBadge - Exercise CVE-2018-6574: go get RCE\nURL\uff1ahttps://github.com/elw0od/PentesterLab\n\n\u6807\u7b7e\uff1a#RCE", "creation_timestamp": "2025-03-07T13:26:51.000000Z"}, {"uuid": "bdedc6e5-07df-4c6e-a39a-ce06b59d8551", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/5730", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aRCE\n\u63cf\u8ff0\uff1aCVE-2018-6574: go get RCE\nURL\uff1ahttps://github.com/Ashved9/Orange\n\n\u6807\u7b7e\uff1a#RCE", "creation_timestamp": "2023-11-09T06:13:01.000000Z"}, {"uuid": "d6ab0737-716d-4ac8-a988-881f7be03826", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/42713", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aRCE\n\u63cf\u8ff0\uff1aGo get/CGO RCE\nURL\uff1ahttps://github.com/paulogmota/CVE-2018-6574\n\n\u6807\u7b7e\uff1a#RCE", "creation_timestamp": "2025-07-02T01:27:17.000000Z"}, {"uuid": "62f33185-8075-42fa-878e-720e11d67616", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/7330", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aRCE\n\u63cf\u8ff0\uff1aCVE-2018-6574-go-get-RCE\nURL\uff1ahttps://github.com/Dannners/CVE-2018-6574-go-get-RCE\n\n\u6807\u7b7e\uff1a#RCE", "creation_timestamp": "2024-05-17T17:31:33.000000Z"}, {"uuid": "b064d863-89e9-413b-9cb8-8a4f9e7c1ae7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/37718", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aRCE\n\u63cf\u8ff0\uff1aThis is the exploit of CVE-2018-6574: go get RCE\nURL\uff1ahttps://github.com/Saptaktdk/go-get-RCE\n\n\u6807\u7b7e\uff1a#RCE", "creation_timestamp": "2025-05-22T10:36:47.000000Z"}, {"uuid": "646027f1-5d67-4aca-97f9-cee7bddd015d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/RryRGftC0HBuQRcRJBlIa7r2xovkGS7oRhsxKZ_0aHvXPTQ", "content": "", "creation_timestamp": "2025-09-11T03:00:06.000000Z"}, {"uuid": "5e19ef42-d3fc-42e9-970c-3560aabce2f1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/PErUY-jHITMlah0KFWpBgwH1xvYx0Lxy2fdlWqetoLSdfaM", "content": "", "creation_timestamp": "2025-09-11T15:00:07.000000Z"}, {"uuid": "0cb49aa6-f65d-4d0f-85b0-e19bdafd74fe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/HAvHr06C9uMiXds-6AUbBvZZzx-nVsQbMYXyHXXUZMtfWgQ", "content": "", "creation_timestamp": "2025-08-14T21:00:06.000000Z"}, {"uuid": "d8d56424-6f8c-4556-952f-b1deb6e8b4b5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/uTSIu-zmHlu9mpemAuEbwTXGtJ_RO8kPkQ0vaHd8-RUFZeM", "content": "", "creation_timestamp": "2025-06-14T12:04:07.000000Z"}, {"uuid": "9b80ad3a-a0d6-4dc3-9bb8-822fd9c53bf6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/on538g36qvj43OTNOSb3Wq1FcgfNYqXmmz_5qAfFdKxGIIc", "content": "", "creation_timestamp": "2025-07-02T13:43:19.000000Z"}, {"uuid": "6552747b-5ef6-4d30-8a88-8ce70d411f42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://t.me/arpsyndicate/1832", "content": "#ExploitObserverAlert\n\nCVE-2018-6574\n\nDESCRIPTION: Exploit Observer has 123 entries related to CVE-2018-6574. Go before 1.8.7, Go 1.9.x before 1.9.4, and Go 1.10 pre-releases before Go 1.10rc2 allow \"go get\" remote command execution during source code build, by leveraging the gcc or clang plugin feature, because -fplugin= and -plugin= arguments were not blocked.\n\nFIRST-EPSS: 0.007250000\nNVD-IS: 5.9\nNVD-ES: 1.8", "creation_timestamp": "2023-12-16T14:57:09.000000Z"}, {"uuid": "f5ba6bd8-d7cd-4f56-b55f-6fc1197ffe34", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://t.me/arpsyndicate/38", "content": "#ExploitObserverAlert\n\nCVE-2018-6574\n\nDESCRIPTION: Exploit Observer has 121 entries related to CVE-2018-6574. Go before 1.8.7, Go 1.9.x before 1.9.4, and Go 1.10 pre-releases before Go 1.10rc2 allow \"go get\" remote command execution during source code build, by leveraging the gcc or clang plugin feature, because -fplugin= and -plugin= arguments were not blocked.\n\nFIRST-EPSS: 0.007090000\nNVD-IS: 5.9\nNVD-ES: 1.8", "creation_timestamp": "2023-11-10T01:09:41.000000Z"}, {"uuid": "28eb4463-dfcd-4e43-acf2-355f23bd19e4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://t.me/arpsyndicate/58", "content": "#ExploitObserverAlert\n\nCVE-2018-6574\n\nDESCRIPTION: Exploit Observer has 121 entries related to CVE-2018-6574. Go before 1.8.7, Go 1.9.x before 1.9.4, and Go 1.10 pre-releases before Go 1.10rc2 allow \"go get\" remote command execution during source code build, by leveraging the gcc or clang plugin feature, because -fplugin= and -plugin= arguments were not blocked.\n\nFIRST-EPSS: 0.007090000\nNVD-IS: 5.9\nNVD-ES: 1.8", "creation_timestamp": "2023-11-10T21:36:39.000000Z"}, {"uuid": "688f3518-0327-4343-b3e1-e2f446dda99c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://t.me/arpsyndicate/1657", "content": "#ExploitObserverAlert\n\nCVE-2018-6574\n\nDESCRIPTION: Exploit Observer has 123 entries related to CVE-2018-6574. Go before 1.8.7, Go 1.9.x before 1.9.4, and Go 1.10 pre-releases before Go 1.10rc2 allow \"go get\" remote command execution during source code build, by leveraging the gcc or clang plugin feature, because -fplugin= and -plugin= arguments were not blocked.\n\nFIRST-EPSS: 0.007250000\nNVD-IS: 5.9\nNVD-ES: 1.8", "creation_timestamp": "2023-12-10T16:40:21.000000Z"}, {"uuid": "43776793-99df-4295-a12e-f2489e7d6059", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/3MBTytBz7FAWoUgV2aTVPXaX-kfAuOLht6JlK6Rx_m9ll3c", "content": "", "creation_timestamp": "2025-03-07T22:00:06.000000Z"}, {"uuid": "62a25b69-ede2-488b-9426-92ec12b1743c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/lHKFDBRntVLEnzL4VqEuPiY-Vt8pAa9hTd9KwEhxy_XdixQ", "content": "", "creation_timestamp": "2026-08-31T00:00:46.206742Z"}, {"uuid": "2851338f-a746-47e1-b6ae-e466ae7e3399", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/lHKFDBRntVLEnzL4VqEuPiY-Vt8pAa9hTd9KwEhxy_XdixQ", "content": "", "creation_timestamp": "2026-08-29T23:00:12.373781Z"}, {"uuid": "bebbf742-b775-4172-ba83-884a0e874cc3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/0_ZePU3z1OawFEHN1iA2HBha57r29KdDO83DysbbQUG6xbo", "content": "", "creation_timestamp": "2026-09-02T01:00:17.341114Z"}, {"uuid": "6ba44e00-1bef-49a5-89dd-b2df299623a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://t.me/GithubRedTeam/92282", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #POC #CVE\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a CVE-2018-6574\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a f0nesec\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a Unknown\n\u2b50 Star\u6570\u91cf\uff1a 0  |  \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-07-07 02:59:39\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\nCVE-2018-6574 POC\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-07-13T22:00:10.528729Z"}, {"uuid": "b064a815-da0b-450e-b368-c35542b8e197", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/92282", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #POC #CVE\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a CVE-2018-6574\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a f0nesec\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a Unknown\n\u2b50 Star\u6570\u91cf\uff1a 0  |  \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-07-07 02:59:39\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\nCVE-2018-6574 POC\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-07-15T00:00:31.115784Z"}, {"uuid": "2f6d1a8c-7f38-4ea5-8c0c-111d19dd747a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://bsky.app/profile/golangoss.bsky.social/post/3mqzlwzn6wu2i", "content": "CVE-2018-6574 (\u2b50\ufe0f 0)\n\nA simple POC for CVE-2018-6574\n\n#go", "creation_timestamp": "2026-07-19T20:17:19.648112Z"}, {"uuid": "b078267e-b438-48e8-86d7-3815987cdc98", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "https://t.me/crackvaultde/1176", "content": "\ud83d\udce2  Deep Dive: CVE-2018-6574\n https://crack-vault.de/d/547", "creation_timestamp": "2026-07-20T21:00:05.520087Z"}, {"uuid": "6574ee7a-e039-4382-aeb3-dc5673aa55f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/GvfR5TiIz5AGTLxNK0NHF1rEL-rqaKshudCOKUMqTVI5bvk", "content": "", "creation_timestamp": "2026-09-02T16:00:04.220208Z"}, {"uuid": "b9c926dc-04ee-4347-9e8f-32575d4f7bc1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/0_ZePU3z1OawFEHN1iA2HBha57r29KdDO83DysbbQUG6xbo", "content": "", "creation_timestamp": "2026-09-03T00:00:38.508521Z"}, {"uuid": "d3bcc608-4edc-4704-bbc4-e782ac5b5939", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/GvfR5TiIz5AGTLxNK0NHF1rEL-rqaKshudCOKUMqTVI5bvk", "content": "", "creation_timestamp": "2026-09-03T00:00:42.414009Z"}, {"uuid": "8c43bd00-7db4-4861-b82d-91ef84036a49", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/h0XXwJ3P9wRAW-H1-g2zYYLVuo66b8VqhziVV9yVsv4x6n4", "content": "", "creation_timestamp": "2026-09-04T18:00:03.697723Z"}, {"uuid": "39ea5355-dcda-4d47-83a5-0cff5678c8eb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/lpcaxohlevWOQx_YAX_9XUMgFve84tVn0viR4d8tnkij6ww", "content": "", "creation_timestamp": "2026-09-04T18:00:03.874468Z"}, {"uuid": "f03b4f86-6db8-4f03-a3e5-a534ea53ce65", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/DGzHuk8RVb1b8Xt8T_i7JrWo03tk4z5tw950ouDC7Dv-DN4", "content": "", "creation_timestamp": "2026-09-04T18:00:04.353501Z"}, {"uuid": "642402fe-8d0e-458c-ac5a-550772ed5159", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/lpcaxohlevWOQx_YAX_9XUMgFve84tVn0viR4d8tnkij6ww", "content": "", "creation_timestamp": "2026-09-05T01:00:20.886194Z"}, {"uuid": "ceb21833-2234-458e-905b-18a9cdbd7abb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/DGzHuk8RVb1b8Xt8T_i7JrWo03tk4z5tw950ouDC7Dv-DN4", "content": "", "creation_timestamp": "2026-09-05T01:00:20.154946Z"}, {"uuid": "45301247-26a7-4398-8e11-8c08ba35c0b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/h0XXwJ3P9wRAW-H1-g2zYYLVuo66b8VqhziVV9yVsv4x6n4", "content": "", "creation_timestamp": "2026-09-05T01:00:21.314896Z"}, {"uuid": "93404989-cbcc-40ac-bb94-c4b57e1e9cfb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/szyQ0EKV_UVNdmkffaO0C1PUabx9T7Nbdd_Nvq3q85HonyM", "content": "", "creation_timestamp": "2026-09-06T08:00:05.797294Z"}, {"uuid": "28ef3f66-c70c-4e3b-addb-e6f302b35055", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/szyQ0EKV_UVNdmkffaO0C1PUabx9T7Nbdd_Nvq3q85HonyM", "content": "", "creation_timestamp": "2026-09-07T01:00:25.225151Z"}, {"uuid": "68c9c4fd-abf9-483e-ace1-88e2b689cb83", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "Telegram/r4oF1dd8S2eZHbzR9DOUSLFo4p2J6Y0ZlXzV9dEOlSgZGtc", "content": "", "creation_timestamp": "2026-09-09T04:00:36.624247Z"}, {"uuid": "da81e50c-0c7e-4715-91a1-16a329e6ea42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "published-proof-of-concept", "source": "Telegram/r4oF1dd8S2eZHbzR9DOUSLFo4p2J6Y0ZlXzV9dEOlSgZGtc", "content": "", "creation_timestamp": "2026-09-10T00:00:51.754349Z"}, {"uuid": "3f1988b4-a1a5-4c7e-92f6-01a75b38f6f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2018-6574", "type": "seen", "source": "https://gist.github.com/TotallyGamerJet/235fa442391db7a82353a1ff0d9e8cf0", "content": "# Background\n\nGo currently provides two mechanisms for interacting with code outside the Go toolchain:\n\n1. The [`cgo`](https://pkg.go.dev/cmd/cgo) tool, which enables calling C code and linking against C libraries.\n2. Platform-specific facilities such as [`syscall.SyscallN`](https://pkg.go.dev/syscall?GOOS=windows), which can invoke uintptr-sized-argument functions that follow the windows platform ABI.\n\nThese mechanisms leave a gap. Go has no general, compiler-supported way to call a function pointer that is only known at run time using the platform ABI.\n\nSeveral projects, including [purego](https://github.com/ebitengine/purego) and [goffi](https://github.com/go-webgpu/goffi), have demonstrated significant demand for this capability. These projects enable calling dynamically resolved functions without a C toolchain, but they rely on runtime tricks, reflection, and internal runtime behavior that is not part of Go's public API.\n\nThe Go runtime and linker already contain most of the machinery necessary to support foreign function calls. The runtime can safely transition between Go and foreign code through `runtime.cgocall`, the linker can import dynamic symbols through `cgo_import_dynamic`, and the compiler already supports multiple ABIs internally. The remaining missing piece is a toolchain-supported mechanism for invoking a *function pointer value* using the platform ABI. This proposal introduces such a mechanism.\n\n# Relationship to #81450\n\n[#81450 (`proposal: cmd/cgo: cgo without a C toolchain`)](https://github.com/golang/go/issues/81450) proposes checked-in binding files plus a C-ABI-aware `cmd/cgo` that emits Go and assembly trampolines, removing the C toolchain requirement for packages that bind to pre-built libraries.\n\n**This proposal is not an alternative to #81450. It is a design for the piece #81450 explicitly defers.**\n\n> ### Dynamic loading\n> In some use cases, a C shared library is loaded dynamically at runtime. [...] The binding mechanism will also support dynamically loaded functions, by generating type-safe Go wrappers and trampolines for dynamically resolved functions. [...] **We are still working on the details of how this will work and will share more in a separate document.**\n\nThis document is a concrete proposal for that separate document, written from the experience of maintaining [purego](https://github.com/ebitengine/purego), the library that several commenters on #81450 (pete-woods, sbinet, mostafa, eliottness) named as the thing they want replaced.\n\nThe two proposals differ along one axis, and that axis determines everything else:\n\n| | #81450 | This proposal |\n|---|---|---|\n| **What a declaration binds to** | a **symbol name**, resolved by the linker or loader | a **`uintptr` value**, read from a variable at call time |\n| **When the target is known** | development / link time | run time |\n| **Requires the library at build time** | yes, to name the symbol | no |\n| **Requires `import \"C\"`** | yes | no |\n| **Handles `GetProcAddress`-style APIs** | no | yes |\n| **Primary use case** | replace existing cgo packages | call things cgo cannot name |\n\n#81450's dynamic-loading sketch assumes \"the function names and signatures are often known statically at development time.\" That assumption holds for `dlopen(\"libfoo.so\")` + a fixed symbol list, and #81450 handles that case well. It does **not** hold for the large class of APIs whose entry points are values produced by other calls:\n\n* **Vulkan**: every function past `vkGetInstanceProcAddr` is obtained by calling `vkGetInstanceProcAddr`/`vkGetDeviceProcAddr`. There is no symbol to name, and per-device dispatch means the pointer legitimately differs between two live objects in the same process.\n* **OpenGL / EGL / GLX / WGL**: `glXGetProcAddress`, `wglGetProcAddress`, `eglGetProcAddress`. Same shape.\n* **Plugin and driver ABIs**: a struct of function pointers returned by an entry point, where the set of valid pointers depends on a version field.\n* **Objective-C / COM-style dispatch**: `objc_msgSend` variants and vtable slots selected at run time.\n* **Libraries resolved from a path computed at run time**, where the `.so` may not exist on the build machine at all.\n\nFor these, a symbol-binding mechanism does not help, no matter how good its ABI handling is. Something has to be able to say \"call *this pointer* with *this signature*.\" That is the whole content of this proposal.\n\nBecause the two mechanisms need identical machinery below the call site (C-ABI argument classification, trampoline generation, `runtime.cgocall` transition), they should share an implementation. The recommendation of this document is that whichever component #81450 lands its C ABI logic in, this feature is a second front end onto that same component. See [Implementation](#implementation).\n\n# Proposal\n\nIntroduce a directive that binds a bodyless Go function declaration to a function pointer stored in a `uintptr` variable, and calls it using the platform ABI. The spelling used throughout this document is:\n\n```\n//go:foreigncall fnvar [abi]\n```\n\nThe directive must be followed by a function declaration with no body. It specifies that calling the Go function calls the foreign function whose address is currently held in `fnvar`, using the ABI named, defaulting to `\"system\"`.\n\nFor example,\n\n```go\n//go:cgo_import_dynamic mypkg.putsPtr puts \"libc.so.6\"\nvar putsPtr uintptr\n\n//go:foreigncall putsPtr system\nfunc puts(s *byte) int32\n\nputs(&[]byte(\"hello from go\\x00\")[0])\n```\n\nThe interesting case is a pointer that does not exist until run time:\n\n```go\n//go:cgo_import_dynamic mypkg.vkGetInstanceProcAddrPtr vkGetInstanceProcAddr \"vulkan-1.dll\"\nvar vkGetInstanceProcAddrPtr uintptr\n\n//go:foreigncall vkGetInstanceProcAddrPtr\nfunc vkGetInstanceProcAddr(instance VkInstance, pName *byte) uintptr\n\nvar vkCreateInstancePtr = vkGetInstanceProcAddr(0, &[]byte(\"vkCreateInstance\\x00\")[0])\n\n//go:foreigncall vkCreateInstancePtr\nfunc vkCreateInstance(\n    pCreateInfo *VkInstanceCreateInfo,\n    pAllocator  *VkAllocationCallbacks,\n    pInstance   *VkInstance,\n) VkResult\n```\n\nThere is no symbol named `vkCreateInstance` to bind to. The loader never sees that name. It is a value returned by a call.\n\nAnd one for macOS,\n\n```go\n//go:cgo_import_dynamic _ _ \"/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation\"\n//go:cgo_import_dynamic mypkg.CFStringCreateWithCStringPtr CFStringCreateWithCString \"\"\nvar CFStringCreateWithCStringPtr uintptr\n\ntype CFAllocatorRef uintptr\ntype CFStringRef uintptr\ntype CFStringEncoding uint32\n\nconst kCFStringEncodingUTF8 CFStringEncoding = 0x08000100\nconst kCFAllocatorDefault CFAllocatorRef = 0\n\n//go:foreigncall CFStringCreateWithCStringPtr\nfunc CFStringCreateWithCString(\n    alloc CFAllocatorRef,\n    cStr *byte,\n    encoding CFStringEncoding,\n) CFStringRef\n\ncfStr := CFStringCreateWithCString(kCFAllocatorDefault, &[]byte(\"Hello from Go\\x00\")[0], kCFStringEncodingUTF8)\n```\n\nNote, these examples exclude proper pinning of arguments for brevity.\n\n### Unified spelling with #81450\n\nThe directive name is not load-bearing and this proposal does not insist on it. If #81450 lands `//cgo:binding`, this feature can be spelled as a variant of it so that there is one binding vocabulary rather than two:\n\n```go\n//cgo:binding C.dynamic vkCreateInstancePtr\nfunc vkCreateInstance(...) VkResult\n```\n\nThe only requirement is that *some* spelling exists whose right-hand side is a Go variable rather than a C symbol name. The author's preference is a `go:`-prefixed directive, because it lets a package use this feature without `import \"C\"`, which in turn means the file type-checks under `CGO_ENABLED=0` and needs no special handling in `go/types` or `gopls`. But that is a preference, not a requirement of the design.\n\n### Supported Types\n\nTo simplify ABI handling and ensure correctness, the initial implementation should support:\n\n*   **Fixed-size integers**: int8 (byte), int16, int32, int64, uint8, uint16, uint32, uint64\n*   **Floating point**: float32, float64\n*   **Pointer types**: unsafe.Pointer, uintptr, \\*T (treated as pointer)\n*   **Boolean**: bool, mapped to C's `_Bool` (C99 `` bool). `_Bool` is 1 byte on all initially supported platform ABIs, matching Go's own bool representation. Note this only covers true C99 `_Bool`; APIs that represent booleans as a wider integer typedef (e.g. Win32 `BOOL`, Vulkan `VkBool32`, both really `int`/`uint32`) should use the fixed-size integer types above instead of bool.\n\nIf a type is not supported or there is more than one return value, the compiler will error.\n\nIt purposely excludes structs, unions, complex numbers, variadics, slices, maps, channels and strings as they complicate the ABI and memory handling needed to correctly pass them into C. Struct and union support should follow #81450's answer rather than inventing a second one; see [Potential Future Work](#potential-future-work) and the union question raised by felixge on #81450, which applies identically here.\n\nCalls generated by this proposal follow the same pointer-safety rules as existing cgo calls ([Passing Pointers](https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers)). This proposal intentionally does not introduce new pointer semantics. Users familiar with cgo should expect the same safety guarantees and restrictions when calling foreign functions through this mechanism.\n\nIf the fnvar uintptr is 0 when the Go function is called, a recoverable runtime panic occurs. This is a meaningful improvement over the status quo: today a missing symbol in a dynamically resolved binding is a jump to address zero, which is a crash with no Go stack.\n\nThe optional ABI argument currently supports only the `\"system\"` ABI. The system ABI corresponds to the platform's native foreign-function calling convention (SysV on Unix-like amd64 systems, Microsoft x64 on Windows amd64, AAPCS64 on arm64).\n\nA temporary experiment flag such as `GOEXPERIMENT=foreigncall` may be used during development and evaluation of the feature. The experiment period would allow validation of ABI correctness across platforms and library author experience before committing to a stable directive.\n\nThe initial implementation would be supported on amd64 & arm64 for windows, linux and darwin as that covers the most popular platforms.\n\n# Rationale\n\n## Why a function pointer rather than a symbol\n\nThe indirection through a `uintptr` variable is the point of the proposal, not an inconvenience to be designed away.\n\nThere is no defined way in Go to cast a `uintptr` to a function of a given ABI. Binding to a variable supplies that missing operation in the one place where the toolchain can check the signature against the ABI and generate the correct call. A symbol-binding mechanism, which is what #81450 provides, cannot express a call whose target is computed, and so needs a separate solution anyway for the Vulkan/OpenGL/plugin class of API. Function-pointer binding supports both use cases with one implementation: symbols imported at link time through `cgo_import_dynamic`, symbols discovered through `dlopen`/`dlsym` or `GetProcAddress`, and pointers handed out by other foreign calls all land in a `uintptr` and are then called identically.\n\nIt is also the smaller feature. This proposal adds no new type, no new namespace, no new file format, and nothing the type checker must learn. A `//go:foreigncall` file is ordinary Go source.\n\n## Why this belongs in the toolchain rather than a library\n\nThis is the objection that closed [#77386](https://github.com/golang/go/issues/77386) in a day (\"this seems fine to exist as an external project\"), so it deserves a direct answer. purego *is* that external project, it has existed for years, and it is load-bearing for [Ebitengine](https://github.com/hajimehoshi/ebiten), [DataDog/go-libddwaf](https://github.com/DataDog/go-libddwaf), and others. It works. It should not have to.\n\nThe external implementation is only possible by doing things the Go project has said it intends to stop allowing:\n\n* It calls `runtime.cgocall` and friends through `go:linkname`. [#67401](https://github.com/golang/go/issues/67401) locked down future uses of linkname; purego survives on the grandfathered list, not on a guarantee.\n* That lockdown has already broken it once, in [#79702](https://github.com/golang/go/issues/79702) (`cmd/link: check linkname access to assembly symbols breaks purego`), and was resolved by widening an exception rather than by sanctioning the pattern.\n* It ships [`internal/fakecgo`](https://github.com/ebitengine/purego/tree/main/internal/fakecgo), a hand-written re-implementation of `runtime/cgo`'s thread setup in Go and assembly, precisely because `runtime/cgo` requires a C toolchain. #81450 proposes to rewrite `runtime/cgo` in Go and assembly, which makes fakecgo redundant, but only if there is a supported way to make the calls.\n* The remaining correctness gaps are runtime-internal and not fixable from outside; see [#80723](https://github.com/golang/go/issues/80723) (`SIGSEGV at process exit in cgo test binary with LockOSThread + purego cgocall`).\n* Every call goes through `reflect` to marshal arguments, which is both slow and a permanent tax that a compiler-generated trampoline does not pay.\n\nSo the honest framing is: the ecosystem has already voted for this feature and is paying for it in unsupported runtime coupling. #81450 removes that coupling for the static case. This proposal removes it for the dynamic case. If #81450 lands without a dynamic-pointer story, purego continues to exist and continues to linkname into the runtime, which is the outcome nobody wants.\n\n## Secondary benefits\n\nThe ease of cross compiling a pure Go program is one of the most popular things about Go, and today that ease is lost the moment a program touches C. The Go ecosystem is accustomed to doing work outside of the compiler to avoid slowing it down; that is why `go:generate` must be run manually, and the same can be true for interacting with C. Bindings can be generated by tools that actually parse C, such as [cc/v3](https://pkg.go.dev/modernc.org/cc/v3), with the cost paid once by the library maintainer rather than by every downstream user.\n\nBecause a `//go:foreigncall` file is entirely ordinary Go, LSP functionality keeps working. Tools give up on checking whether a `C.` symbol exists, since that would require invoking a C compiler. Here type checking is just type checking.\n\n# Non-Goals\n\nThis proposal intentionally does not attempt to:\n\n* **Replace or compete with #81450.** Packages that bind to a library present at build time should use #81450's binding files.\n* Parse C source files or headers\n* Replace cgo\n* Generate bindings automatically\n* Support callbacks from foreign code into Go\n* Support all C types\n* Support every platform ABI initially\n* Eliminate `runtime.cgocall`\n* Statically link C code into the Go binary\n\nRestricting the scope in this way allows the proposal to focus on the smallest feature necessary to support calls through a run-time function pointer.\n\n# Compatibility\n\nThis proposal is purely additive. It introduces a new directive and does not change the meaning of any existing Go program; code that does not use it is entirely unaffected. Compiler versions that don't recognize the directive treat it as an ordinary comment, the same as any other unrecognized `//go:` directive today.\n\nDuring development the feature would sit behind `GOEXPERIMENT=foreigncall` and so carries no compatibility obligations until promoted out of experimental status. Once promoted, `go vet` and `go/build`'s directive list would need to recognize it, but no existing syntax, semantics, or standard library API changes.\n\nThe Go 1 compatibility promise does not, and cannot, extend to the C ABI this proposal exposes. A `go:foreigncall` declaration is a contract between the Go signature and whatever function pointer fnvar holds at call time, and the toolchain has no way to verify that contract (see Drawbacks). That is a property of the feature rather than a compatibility break, and it is the same property #81450's hand-written and hand-edited binding files have. Keeping the Go declaration in sync with the real C signature remains the discipline cgo bindings already require.\n\n# Implementation\n\nMost of the pieces described in Background already exist and would be reused unchanged. The new work is:\n\n*   **Front end**: recognize the directive on a bodyless function declaration, validate that fnvar resolves to an in-scope package-level `uintptr` variable, validate that all parameter and return types are in the supported set, and error otherwise (unsupported type, more than one return value, or missing/invalid fnvar).\n*   **C ABI lowering**: for each supported ABI (initially just `\"system\"`), classify and place Go arguments into the target platform's calling-convention registers and stack slots (System V x86-64, Microsoft x64, AAPCS64), plus the corresponding return-value handling, with the call target loaded from fnvar rather than fixed at link time.\n*   **Call transition**: reuse `runtime.cgocall` unchanged for the G-to-M transition, `entersyscall`/`exitsyscall` scheduler accounting, and GC safepoint handling, exactly as cgo calls do today.\n*   **Linker**: no changes required; `cgo_import_dynamic` symbol resolution already exists and is reused as-is.\n*   **Tooling**: `go vet` should validate the directive the way it validates `go:linkname` today. `gopls`/`go/types` need no changes, since the declaration is ordinary Go syntax with no new type-level construct.\n\n### Where the ABI lowering lives\n\n#81450 lists \"Handle the C ABI in the Go compiler\" as a rejected alternative, preferring to keep that complexity in `cmd/cgo` and emit Go and assembly trampolines. **This proposal takes no position on that question and should be read as compatible with either answer.**\n\nThe difference between the two proposals is *what the call target is*, not *which binary computes the register classification*. If #81450 lands its ABI engine in `cmd/cgo`, this feature should be implemented as a second front end onto that engine: `cmd/cgo` reads the directive, emits the same style of trampoline, and the trampoline loads the target address from fnvar instead of referencing a symbol. Nothing in this document requires `cmd/compile` to learn the C ABI.\n\nGiven that, the incremental cost of this proposal on top of #81450 is small: an indirect call form in the trampoline generator, a nil check, and a second directive spelling. Platform-specific ABI classification, the largest and riskiest piece of work, is shared rather than duplicated.\n\n# Drawbacks and Tradeoffs\n\nEvery feature has a cost and this one is no different. It adds another way to call into C, which complicates the choice for users; the answer this proposal offers is a clear rule. If the library is there at build time and you can name the symbol, use #81450's bindings. If the address only exists at run time, use this.\n\nUnlike traditional cgo, which type-checks Go declarations against real C headers, this proposal has no way to verify that a declaration actually matches the signature of the C function behind fnvar. A mismatched argument count, type, or return type is not caught at compile time. Instead it corrupts registers or the stack at the call site and fails at run time, possibly silently. This is a strictly weaker safety guarantee than cgo provides today, traded for not requiring a C parser. It is the same tradeoff #81450 accepts for hand-written binding files, and the same mitigation applies: a generator can produce these declarations from real headers when a C toolchain is available, and a `go test`-time consistency check can verify them, exactly as #81450 proposes for its bindings.\n\nIt also does not support statically linking C into the Go binary. This means it is useful for libraries guaranteed to be present on the system, or requires distributors to bundle the shared library alongside the binary, which breaks Go's single-binary model. Several commenters on #81450 (RomainMuller, eliottness) asked for pre-built `.a` archives to be presentable to the internal linker; that is orthogonal to this proposal and would benefit both.\n\n# Potential Future Work\n\n### Support ABI-aware struct and union passing\n\nThe initial implementation excludes structs to keep the first cut small. Adding them brings parity with cgo. Structs would use `structs.HostLayout` to ensure memory aligns with the C side. Unions need care about register classification; see felixge's comment on #81450. This should adopt whatever representation #81450 settles on rather than inventing a parallel one.\n\n### Additional Platforms\n\nThe initial implementation is limited to windows, linux and darwin on amd64 and arm64. Once an initial implementation exists other operating systems and architectures can be added.\n\n### Additional ABIs\n\nMost obvious would be Windows' other ABI flavors: stdcall, cdecl, and fastcall. These would be limited to their respective GOOS/GOARCH pairs.\n\nAnother suggestion is a `\"raw\"` ABI, performing a direct call without `runtime.cgocall`: no stack growth checks, no scheduler coordination, no GC safepoints. This would only be allowed inside the runtime, for implementing `runtime/cgo` in pure Go. Note this overlaps with the long-standing request for a faster non-blocking C call ([#16051](https://github.com/golang/go/issues/16051), [#42469](https://github.com/golang/go/issues/42469)) but is deliberately scoped to the runtime here.\n\n### Port `runtime/cgo`\n\n#81450 proposes rewriting `runtime/cgo` in Go and assembly. This proposal does not require it, since it is already possible to implement outside the stdlib (see [`internal/fakecgo`](https://github.com/ebitengine/purego/tree/main/internal/fakecgo)), but that implementation exists only because there is no supported alternative, and it depends on runtime symbols that [#67401](https://github.com/golang/go/issues/67401) and [#79702](https://github.com/golang/go/issues/79702) show are not stable ground.\n\n### Return Errno\n\nIf the Go function returns an error in either the first or second return value, the C errno value should be returned in it. Doing this avoids a second jump into the C stack.\n\n### Callbacks\n\nSome APIs require passing a Go function into C. This proposal does not provide a way to obtain a function pointer matching the C ABI. purego handles this today via reflection; doing it in the toolchain would be both safer and faster. There is already a similar concept in `internal/abi`'s `FuncPCABI0` and `FuncPCABIInternal`, which return uintptrs to a function's ABI wrapper. Callbacks are needed by roughly the same set of APIs that need dynamic function pointers, so this is the most likely immediate follow-up.\n\n### Dynamically resolve variables\n\nIt would be useful to link to variables from shared libraries. Not required initially, since all symbols can be obtained through `dlsym`, which this proposal makes callable.\n\n### Bundling in C code\n\nA way to bundle pre-compiled C code would make it possible to use external C libraries in a single binary, and has been requested on #81450 by RomainMuller and eliottness, who currently work around its absence by embedding a `.so`, writing it to disk, and `dlopen`ing it.\n\nThis proposal does not include it, and the reason is not purely scope. Shipping pre-compiled code inside a module means `go get` distributes opaque native code as ordinary module content. That is already reachable today through `#cgo LDFLAGS: -L${SRCDIR}`, so it is not a new capability, but making it the ergonomic and toolchain-supported path inverts the current norm, in which a cgo package ships auditable C source alongside its bindings. It also sits awkwardly against the principle stated in CVE-2018-6574 ([#23672](https://github.com/golang/go/issues/23672)): \"Go get downloads and builds source code. It is not meant to execute arbitrary code.\"\n\nThe preference of this proposal is instead to port such code to Go and use the dynamic linking described here to reach genuine system libraries. If bundling is pursued, it deserves to be decided deliberately rather than arrived at as a consequence of dropping the C toolchain requirement.\n\n### Document the `cgo_import_dynamic` family\n\nAs eliottness noted on #81450, `//go:cgo_import_dynamic` and `//go:cgo_import_static` are undocumented and increasingly load-bearing. Both proposals would push more users toward them.\n\n* * *\n\n## Other Resources\n\nC compiler requirement leads to hacky solutions: [https://stoolap.io/blog/2026/04/08/calling-a-rust-library-from-go-with-cgo-disabled/](https://stoolap.io/blog/2026/04/08/calling-a-rust-library-from-go-with-cgo-disabled/)\n\n### Related Issues:\n\ncgo without a C toolchain (the companion proposal): [https://github.com/golang/go/issues/81450](https://github.com/golang/go/issues/81450)\n\noverhead of syscall package: [https://blog.kowalczyk.info/a-3g9f/optimizing-calling-windows-dll-functions-in-go.html](https://blog.kowalczyk.info/a-3g9f/optimizing-calling-windows-dll-functions-in-go.html)\n\nunsafe FFI calls: [https://github.com/golang/go/issues/42469](https://github.com/golang/go/issues/42469)\n\nfaster C-call mechanism: [https://github.com/golang/go/issues/16051](https://github.com/golang/go/issues/16051)\n\nproposal to export `cgo_import_static`: [https://github.com/golang/go/issues/75473](https://github.com/golang/go/issues/75473)\n\n> [cherrymui](https://github.com/cherrymui): I think there is a general demand for calling C functions in precompiled (static or dynamic) objects, which I think is definitely worth considering. But I think it needs a more complete solution, e.g. a general mechanism to call a C function. Also, on some platforms, it may require the program to be initialized in certain way, e.g. using pthread to create threads, instead of direct syscalls.\n\nruntime bug reachable only from outside the toolchain: [https://github.com/golang/go/issues/80723](https://github.com/golang/go/issues/80723)\n\nlinkname lockdown: [https://github.com/golang/go/issues/67401](https://github.com/golang/go/issues/67401), [https://github.com/golang/go/issues/79702](https://github.com/golang/go/issues/79702)\n\nwasm import global: [https://github.com/golang/go/issues/59149](https://github.com/golang/go/issues/59149)\n\nwasm import: [https://github.com/golang/go/issues/38248](https://github.com/golang/go/issues/38248)\n\ncode execution caused by Cgo: [https://github.com/golang/go/issues/23672](https://github.com/golang/go/issues/23672)\n", "creation_timestamp": "2026-09-18T14:21:47.678300Z"}]}