{"vulnerability": "cve-2024-3094", "sightings": [{"uuid": "b5cf792e-e308-43ec-af2f-97d1e2fe40bf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "MISP/8111c62a-47ac-4afb-847a-479fd973078b", "content": "", "creation_timestamp": "2024-04-02T07:00:59.000000Z"}, {"uuid": "d8f41f9b-ae14-4465-b5c9-ea18f2d4cf87", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/csapidus.bsky.social/post/3lfz34wd4k22y", "content": "", "creation_timestamp": "2025-01-18T10:13:05.082422Z"}, {"uuid": "c87a6ac6-38f1-4f3c-80c5-c597db1d06a3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/letspartytilldawn.bsky.social/post/3lpwaprsvd223", "content": "", "creation_timestamp": "2025-05-24T13:27:02.343342Z"}, {"uuid": "233fe7db-82e7-479e-9c27-25e98a2c6146", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3lpxm5jn2ab2u", "content": "", "creation_timestamp": "2025-05-25T02:24:14.562279Z"}, {"uuid": "0d5f3689-5040-4a03-8458-32194b5ff8fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/csse-bot.bsky.social/post/3lnmkcizfvz26", "content": "", "creation_timestamp": "2025-04-25T06:01:33.421446Z"}, {"uuid": "291b05d1-0611-470a-839d-491231489339", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/it-finanzmagazin.de/post/3m3s2alfctn2k", "content": "", "creation_timestamp": "2025-10-22T14:22:50.646124Z"}, {"uuid": "28cfb24b-b6f6-4cdf-9966-d123244cf5aa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://www.cert.at/de/warnungen/2024/3/kritische-sicherheitslucke-in-fedora-41-und-fedora-rawhide-bibliothek-xz", "content": "", "creation_timestamp": "2024-03-29T17:57:26.000000Z"}, {"uuid": "463607f8-6673-4057-ab17-a81171bad2e2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/lexi-the-cute/44b0b59f5315ebad317277de6cbe55e6", "content": "", "creation_timestamp": "2025-09-10T14:17:30.000000Z"}, {"uuid": "e2df7321-041b-42b5-bfc2-6933ff87be9b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/shiojiri.com/post/3lwblixndfc2m", "content": "", "creation_timestamp": "2025-08-13T10:10:33.876842Z"}, {"uuid": "41707758-6615-4b83-8f96-9a34e9734074", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://poliverso.org/objects/0477a01e-4a87de48-69348e6082c43caf", "content": "", "creation_timestamp": "2025-08-14T08:12:43.164640Z"}, {"uuid": "9cfa212e-6d93-4230-ae0e-157e50dd46c1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/ianzhang22/3ac8d3ab09ee9dacca7e45cc5444d0c1", "content": "", "creation_timestamp": "2025-10-08T04:18:38.000000Z"}, {"uuid": "e5c88f13-c87a-40fb-908f-60878edf1bb2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/ianzhang22/092b17ffecea4e530e0e67401b9ecaff", "content": "", "creation_timestamp": "2025-10-08T04:18:37.000000Z"}, {"uuid": "a5ae1b67-e967-4223-a34f-0d1147ae082a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/kubesploit.io/post/3m2hos4fmvn2x", "content": "", "creation_timestamp": "2025-10-05T18:06:04.492685Z"}, {"uuid": "725d64de-2404-4728-9c05-2a88c19ba731", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/mrmps/37e0bfc1524af08c45deece8c02b46de", "content": "", "creation_timestamp": "2025-08-27T18:26:43.000000Z"}, {"uuid": "d3b1c301-5541-4fc3-b9dd-a777317d8865", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "MISP/d17bd6ef-d68b-317b-ac33-cdbc44c5fc57", "content": "", "creation_timestamp": "2025-08-31T03:13:10.000000Z"}, {"uuid": "909cb6f4-c341-4c1f-9a59-4517c5d1c735", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "MISP/ab0b745f-bbd5-338e-8b92-97dd0c757e9d", "content": "", "creation_timestamp": "2025-08-31T03:01:26.000000Z"}, {"uuid": "df7650f7-8aca-4007-8626-4cd12be4325e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/kubesploit.io/post/3ly4asl3b7j25", "content": "", "creation_timestamp": "2025-09-05T18:06:07.329515Z"}, {"uuid": "65f169db-f0f5-45a2-b240-af7a31ac57bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/metamaterialsuit/289ddb625cda77c9e033a04403635813", "content": "", "creation_timestamp": "2026-02-24T09:29:31.000000Z"}, {"uuid": "83540c1b-d844-44c9-938c-c566acf53807", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/jonathan-gruber-1/05724c8f2229fceca85cb5694e67abbd", "content": "", "creation_timestamp": "2026-02-13T10:12:10.000000Z"}, {"uuid": "86403174-caa8-48ec-9f81-30fcb6803b4b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/shtofadhor/cf6606152780d998ca8bf4d288fd4b0d", "content": "", "creation_timestamp": "2026-03-04T21:29:29.000000Z"}, {"uuid": "0c4b16e8-9816-411d-a2b1-b1d88e00b827", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/LHMisme420/2bd47337cd83094069095001ba9aa654", "content": "", "creation_timestamp": "2026-02-23T16:54:31.000000Z"}, {"uuid": "2e55b385-9f29-4d1e-a3d8-dca4542aecc0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/getter-io/d49377af2b569344979d3e9954c49911", "content": "", "creation_timestamp": "2025-12-27T16:55:08.000000Z"}, {"uuid": "3ce8a22c-c942-4bf2-a67e-aeeb71a23013", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/aprosdoketon.bsky.social/post/3mfhpyw7sck22", "content": "", "creation_timestamp": "2026-02-22T18:04:53.346618Z"}, {"uuid": "3a2285f6-f2e7-480f-97fa-de3954fe016f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/meetmarvelous/4917e8dfaf0fb2c6559ae1fafa216ccc", "content": "", "creation_timestamp": "2026-02-09T11:38:08.000000Z"}, {"uuid": "9513f818-f2dd-4d8d-8262-c37c7ab33acd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/pigondrugs.bsky.social/post/3me4uktveqz2p", "content": "", "creation_timestamp": "2026-02-05T17:02:02.924519Z"}, {"uuid": "59cec124-dbd1-4bc5-8964-6dfb8ba4377f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/thecybermind.co/post/3micp2gzmg72r", "content": "", "creation_timestamp": "2026-03-30T22:20:09.541383Z"}, {"uuid": "f31ac5d4-adce-4893-bd06-dbea2496a8a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/DanielGillespie278/81f3fae3dccb6fe8f8c15e890f6a4b06", "content": "", "creation_timestamp": "2026-03-13T00:54:34.000000Z"}, {"uuid": "269dc69e-b04c-4c49-99fc-81610df794b1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://www.govcert.gov.hk/en/alerts_detail.php?id=1260", "content": "", "creation_timestamp": "2024-04-02T04:00:00.000000Z"}, {"uuid": "3b2eb411-b392-4432-a7da-928778c5e806", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://bsky.app/profile/linuxtoday.bsky.social/post/3mi2k4rc74o2x", "content": "", "creation_timestamp": "2026-03-27T16:30:39.378334Z"}, {"uuid": "2c6a996d-2e4d-41f7-ab28-fb167d0a1dbe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/thedailytechfeed.com/post/3mi5bk57nst24", "content": "", "creation_timestamp": "2026-03-28T18:35:04.132794Z"}, {"uuid": "917b792d-1ae2-4f6a-8f61-eb1296452d15", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/alon710/2199c611ce8981e883f1ab541a397899", "content": "", "creation_timestamp": "2026-01-24T21:30:42.000000Z"}, {"uuid": "5b73843d-b4d2-438d-8d97-3e263279d638", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/alon710/3ba3aa2b7b17166a424b900a6c87a11f", "content": "", "creation_timestamp": "2026-01-24T21:30:41.000000Z"}, {"uuid": "a3ac15d0-88e6-45d8-ad18-46a253145c94", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/alon710/0cf14b18a242bc246ba0f89df0d4e9e3", "content": "", "creation_timestamp": "2026-01-24T22:42:43.000000Z"}, {"uuid": "facf8a43-b110-4765-8642-38288bfbc391", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/hiboma/8ac6a8d6a5b013096f344ca21ca08aca", "content": "", "creation_timestamp": "2026-04-01T05:00:10.000000Z"}, {"uuid": "ceeaf3db-c08d-4ab0-806a-3710a988be3d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://swecyb.com/ap/users/116080658609901341/statuses/116330885891185549", "content": "", "creation_timestamp": "2026-04-01T19:11:05.761053Z"}, {"uuid": "cd29cfa9-e6c6-4bf7-8153-ee9e89e70fe2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/7598", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aBasic POC to test CVE-2024-3094\nURL\uff1ahttps://github.com/shefirot/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-06-11T08:43:37.000000Z"}, {"uuid": "66848027-b5c7-4144-8598-c5210f029f30", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/7883", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aGNU IFUNC is the real culprit behind CVE-2024-3094\nURL\uff1ahttps://github.com/robertdfrench/ifuncd-up\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-07-05T18:40:25.000000Z"}, {"uuid": "5eecb50d-a051-41f3-9fb6-c01f213b2aab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/7897", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aWhy GNU IFUNC is the real culprit behind CVE-2024-3094\nURL\uff1ahttps://github.com/T0X1Cx/CVE-2024-34361-Exploit\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-07-07T21:24:29.000000Z"}, {"uuid": "4f6f46b8-2ebd-43fd-b9bc-4317d09abb70", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/8023", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aWhy GNU IFUNC is the real culprit behind CVE-2024-3094\nURL\uff1ahttps://github.com/TAM-K592/CVE-2024-40725-CVE-2024-40898\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-07-19T03:58:31.000000Z"}, {"uuid": "8da8cf46-1728-4ae3-8f54-15eafcdcc74a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/J5Evx8c6q8Iv1XCy46HNHVVg1axdXdjkMA5XVqtOSTRQIfc", "content": "", "creation_timestamp": "2024-03-30T07:32:09.000000Z"}, {"uuid": "8d39d472-c16c-426c-ad1b-f4f65c1bdbeb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/9273", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCVE-2024-3094 (XZ Backdoor) Tools\nURL\uff1ahttps://github.com/XiaomingX/cve-2024-3094-xz-backdoor\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-12-01T05:24:28.000000Z"}, {"uuid": "90954516-f1e0-4f04-97fc-8a20a044e4b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/TbyvnvMJG36HRPFkPQ_0bqUyF7XZabxxdc_yuEfCHFJjcrI", "content": "", "creation_timestamp": "2025-06-19T21:00:05.000000Z"}, {"uuid": "20da1f68-7a88-4bc3-bede-348a5c40725e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/n5hiS3qEoaYgDdE6GkLH0TTaANyby0B2Nr1lHoCe0gHcQSc", "content": "", "creation_timestamp": "2025-06-22T03:00:06.000000Z"}, {"uuid": "1fb82fe3-6475-456f-8712-0f82436879e3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/8057", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aGNU IFUNC is the real culprit behind CVE-2024-3094\nURL\uff1ahttps://github.com/higorcamposs/zabbix-security-advisories-cve-database\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-07-23T04:09:22.000000Z"}, {"uuid": "01e96b9e-b64c-4d28-bbca-c879b92d8a02", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cKure/12677", "content": "\u25a0\u25a0\u25a1\u25a1\u25a1 Illustration for XZ outbreak (CVE-2024-3094 Supply-Chain Attack)", "creation_timestamp": "2024-04-05T14:05:30.000000Z"}, {"uuid": "efa8c956-6832-484e-a511-9c6bd1b0e56e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cKure/12639", "content": "\u25a0\u25a0\u25a0\u25a0\u25a1 Supply-Chain attack: Red Hat on Friday released an \"urgent security alert\" warning that two versions of a popular data compression library called XZ Utils (previously LZMA Utils) have been backdoored with malicious code designed to allow unauthorized remote access.\n\nThe software supply chain compromise, tracked as CVE-2024-3094, has a CVSS score of 10.0, indicating maximum severity. It impacts XZ Utils versions 5.6.0 (released February 24) and 5.6.1 (released March 9).\n\nhttps://thehackernews.com/2024/03/urgent-secret-backdoor-found-in-xz.html", "creation_timestamp": "2024-03-31T09:30:33.000000Z"}, {"uuid": "df451a6c-78d0-4c0f-98c2-fea041b9ee52", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/9274", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCVE-2024-3094 (XZ Backdoor) Tools\nURL\uff1ahttps://github.com/XiaomingX/cve-2024-3094-xz-backdoor-exploit\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-12-01T05:33:23.000000Z"}, {"uuid": "d8dd62da-8d6a-42b2-8b76-811bb98209ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/cOH3TDAW9T1B751QlDH2fXF_IvZ7hUNNyUk6t4txO43Ixoo", "content": "", "creation_timestamp": "2025-10-16T15:00:11.000000Z"}, {"uuid": "501cd221-0f55-47c0-8fd0-ced6c4b1bf5c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6890", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aK8S and Docker Vulnerability Check for CVE-2024-3094\nURL\uff1ahttps://github.com/teyhouse/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-30T18:46:45.000000Z"}, {"uuid": "466b483c-2283-4777-9bdc-f61732fdfd0c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6888", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aHistory of commits related to the xz backdoor Discovered On March 29, 2024: CVE-2024-3094.\nURL\uff1ahttps://github.com/emirkmo/xz-backdoor-github\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-30T10:54:30.000000Z"}, {"uuid": "0811da04-3af2-4d3d-b8e1-9e6bdddbb755", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6934", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aThis is an container environment running CVE-2024-3094 sshd backdoor instance, working with https://github.com/amlweems/xzbot project. IT IS NOT Docker, just implemented by chroot.\nURL\uff1ahttps://github.com/MagpieRYL/CVE-2024-3094-backdoor-env-container\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-03T10:55:34.000000Z"}, {"uuid": "76710357-cd65-4954-b6fe-3e5a484ffae5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/H97MW8DcOQ0HQ2edqbF4Ukf6930T9O-KaahGicp1PWMI3n4", "content": "", "creation_timestamp": "2025-11-05T15:00:12.000000Z"}, {"uuid": "41635cb0-b0e5-4721-801b-0cfddb2f05de", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/_uEPSzFNr6HqJN1CCE1x2MfixnAoe1zyVBXupCwzjdQjfEc", "content": "", "creation_timestamp": "2026-04-09T21:00:05.000000Z"}, {"uuid": "12928481-720e-44e5-a4e5-9ee7335fde98", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/itsec_news/4252", "content": "\u200b\u26a1\ufe0f10 \u0438\u0437 10: \u0412 Linux \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d \u0432\u0441\u0442\u0440\u043e\u0435\u043d\u043d\u044b\u0439 \u0431\u0435\u043a\u0434\u043e\u0440 (CVE-2024-3094)\n\n\ud83d\udcac\u0412 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0439 \u0443\u0442\u0438\u043b\u0438\u0442\u0435 \u0434\u043b\u044f \u0441\u0436\u0430\u0442\u0438\u044f xz, \u0448\u0438\u0440\u043e\u043a\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u043e\u0439 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux, \u0431\u044b\u043b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d \u0441\u043a\u0440\u044b\u0442\u044b\u0439 \u0431\u0435\u043a\u0434\u043e\u0440. \u042d\u0442\u043e\u0442 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0439 \u043a\u043e\u0434, \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u043d\u044b\u0439 \u0432 \u043f\u0430\u043a\u0435\u0442 \u0443\u0442\u0438\u043b\u0438\u0442\u044b, \u0441\u043e\u0437\u0434\u0430\u0435\u0442 \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0443\u0433\u0440\u043e\u0437\u0443 \u0434\u043b\u044f \u0446\u0435\u043f\u043e\u0447\u043a\u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a, \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044f \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0430\u043c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043d\u0435\u0441\u0430\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0441\u043b\u0443\u0436\u0431\u0430\u043c SSH.\n\u0418\u043d\u0436\u0435\u043d\u0435\u0440-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442 \u0438\u0437 Microsoft \u0410\u043d\u0434\u0440\u0435\u0441 \u0424\u0440\u043e\u0443\u043d\u0434 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b \u0431\u044d\u043a\u0434\u043e\u0440 \u0438 \u0441\u043e\u043e\u0431\u0449\u0438\u043b \u043e \u043d\u0435\u043c \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Openwall, \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0449\u0443\u044e\u0441\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u043e\u0439 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux, \u0432 \u043f\u044f\u0442\u043d\u0438\u0446\u0443 \u0443\u0442\u0440\u043e\u043c. \u0412\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 .m4 \u0444\u0430\u0439\u043b\u044b, \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0435 \u0432 \u0430\u0440\u0445\u0438\u0432\u044b xz \u0432\u0435\u0440\u0441\u0438\u0438 5.6.0, \u0432\u044b\u043f\u0443\u0449\u0435\u043d\u043d\u043e\u0439 24 \u0444\u0435\u0432\u0440\u0430\u043b\u044f, \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u043b\u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u0438 automake \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0438 \u0441\u0436\u0430\u0442\u0438\u044f liblzma, \u043c\u043e\u0434\u0438\u0444\u0438\u0446\u0438\u0440\u0443\u044e\u0449\u0438\u0435 \u0435\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 \u0434\u043b\u044f \u043d\u0435\u0441\u0430\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u0430.\n\n\u042d\u0442\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0432 liblzma \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0435\u0442\u0430\u0446\u0438\u0438 sshd \u0438\u0437-\u0437\u0430 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u043c\u043d\u043e\u0433\u0438\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u044b Linux \u0432\u043a\u043b\u044e\u0447\u0430\u044e\u0442 \u0432 \u0441\u0435\u0431\u044f libsystemd. \u042d\u0442\u043e\u0442 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442, \u043e\u0442\u0432\u0435\u0447\u0430\u044e\u0449\u0438\u0439 \u0437\u0430 \u0430\u043a\u0442\u0438\u0432\u0430\u0446\u0438\u044e \u0443\u0432\u0435\u0434\u043e\u043c\u043b\u0435\u043d\u0438\u0439 systemd, \u043e\u0441\u043d\u043e\u0432\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0430 liblzma, \u0447\u0442\u043e \u0434\u0435\u043b\u0430\u0435\u0442 \u0435\u0433\u043e \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u044d\u043b\u0435\u043c\u0435\u043d\u0442\u043e\u043c \u0432 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 OpenSSH.\n\n\u0414\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b .m4 \u0431\u044b\u043b\u0438 \u0441\u0438\u043b\u044c\u043d\u043e \u043e\u0431\u0444\u0443\u0441\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u044b, \u043e\u0447\u0435\u0432\u0438\u0434\u043d\u043e, \u0447\u0442\u043e\u0431\u044b \u0441\u043a\u0440\u044b\u0442\u044c \u0438\u0445 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u0443\u044e \u0444\u0443\u043d\u043a\u0446\u0438\u044e, \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0444\u0430\u0439\u043b\u044b \u0431\u044b\u043b\u0438 \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u044b \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u044b\u043b \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u043c \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0430 xz \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 \u0434\u0432\u0443\u0445 \u043b\u0435\u0442.\n\n\u00ab\u0418\u0441\u0445\u043e\u0434\u044f \u0438\u0437 \u043d\u0430\u0431\u043b\u044e\u0434\u0430\u0435\u043c\u043e\u0439 \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438 \u043d\u0430 \u043f\u0440\u043e\u0442\u044f\u0436\u0435\u043d\u0438\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043d\u0435\u0434\u0435\u043b\u044c, \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u044c, \u0447\u0442\u043e \u043b\u0438\u0431\u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0431\u044b\u043b \u043d\u0435\u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e \u0432\u043e\u0432\u043b\u0435\u0447\u0435\u043d \u0432 \u0437\u043b\u043e\u043d\u0430\u043c\u0435\u0440\u0435\u043d\u043d\u0443\u044e \u0434\u0435\u044f\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c, \u043b\u0438\u0431\u043e \u0435\u0433\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043f\u043e\u0434\u0432\u0435\u0440\u0433\u043b\u0430\u0441\u044c \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u043c\u0443 \u043d\u0430\u0440\u0443\u0448\u0435\u043d\u0438\u044e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438. \u041e\u0434\u043d\u0430\u043a\u043e \u0432\u0442\u043e\u0440\u043e\u0439 \u0432\u0430\u0440\u0438\u0430\u043d\u0442 \u043a\u0430\u0436\u0435\u0442\u0441\u044f \u043c\u0435\u043d\u0435\u0435 \u0432\u0435\u0440\u043e\u044f\u0442\u043d\u044b\u043c, \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u044f \u0435\u0433\u043e \u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0432 \u0441\u043f\u0438\u0441\u043a\u0430\u0445 \u0440\u0430\u0441\u0441\u044b\u043b\u043a\u0438 \u043f\u043e \u043f\u043e\u0432\u043e\u0434\u0443 \u0443\u043f\u043e\u043c\u044f\u043d\u0443\u0442\u044b\u0445 \u00ab\u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0439\u00bb \u2014 \u0441\u043e\u043e\u0431\u0449\u0430\u0435\u0442 \u0424\u0440\u043e\u0439\u043d\u0434 \u0432 \u0441\u0432\u043e\u0435\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435, \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0438\u0440\u0443\u044f \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0432 \u0432\u0435\u0440\u0441\u0438\u0438 xz 5.6.1. \u042d\u0442\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043f\u0440\u0435\u0434\u043d\u0430\u0437\u043d\u0430\u0447\u0435\u043d\u043d\u044b\u0435 \u0434\u043b\u044f \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u043e\u0448\u0438\u0431\u043e\u043a valgrind \u0438 \u043f\u0440\u0435\u0434\u043e\u0442\u0432\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u0441\u0431\u043e\u0435\u0432, \u043f\u043e \u0432\u0441\u0435\u0439 \u0432\u0438\u0434\u0438\u043c\u043e\u0441\u0442\u0438, \u0431\u044b\u043b\u0438 \u0432\u044b\u0437\u0432\u0430\u043d\u044b \u0432\u0441\u0442\u0440\u043e\u0435\u043d\u043d\u044b\u043c \u0431\u044d\u043a\u0434\u043e\u0440\u043e\u043c.\n\n\u0410\u0433\u0435\u043d\u0442\u0441\u0442\u0432\u043e \u043a\u0438\u0431\u0435\u0440\u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043d\u043e\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0421\u0428\u0410 (CISA) \u0432\u044b\u043f\u0443\u0441\u0442\u0438\u043b\u043e \u043f\u0440\u0435\u0434\u0443\u043f\u0440\u0435\u0436\u0434\u0435\u043d\u0438\u0435 \u043e\u0431 \u044d\u0442\u043e\u0439 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043e\u0442\u0441\u043b\u0435\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043a\u0430\u043a CVE-2024-3094 \u0438 \u0438\u043c\u0435\u0435\u0442 \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u0439 \u0431\u0430\u043b\u043b CVSS 10, \u043f\u0440\u0435\u0434\u0443\u043f\u0440\u0435\u0436\u0434\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u0438 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043e \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442\u043a\u0430\u0442\u0438\u0442\u044c\u0441\u044f \u043a \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 xz, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a \u0432\u0435\u0440\u0441\u0438\u0438 5.4.6.\n\u0424\u0440\u043e\u0439\u043d\u0434 \u043e\u0442\u043c\u0435\u0442\u0438\u043b, \u0447\u0442\u043e \u0432\u0435\u0440\u0441\u0438\u0438 xz 5.6.0 \u0438 5.6.1 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u0438 \u0448\u0438\u0440\u043e\u043a\u043e \u0438\u043d\u0442\u0435\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u044b \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u043c\u0438 Linux, \u0430 \u0442\u0430\u043c, \u0433\u0434\u0435 \u043e\u043d\u0438 \u0431\u044b\u043b\u0438 \u0438\u043d\u0442\u0435\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u044b, \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0432\u0430\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u0432\u0435\u0440\u0441\u0438\u044f\u0445.\n\nRed Hat \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043b \u0441\u0440\u043e\u0447\u043d\u043e\u0435 \u043f\u0440\u0435\u0434\u0443\u043f\u0440\u0435\u0436\u0434\u0435\u043d\u0438\u0435 \u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432 \u043f\u044f\u0442\u043d\u0438\u0446\u0443, \u043f\u0440\u0438\u0437\u044b\u0432\u0430\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043d\u0435\u043c\u0435\u0434\u043b\u0435\u043d\u043d\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0442\u0438\u0442\u044c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u043b\u044e\u0431\u044b\u0445 \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u043e\u0432 Fedora Rawhide \u0438\u0437-\u0437\u0430 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0443\u0433\u0440\u043e\u0437\u044b \u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0435\u0442\u0430\u0446\u0438\u0438 \u0447\u0435\u0440\u0435\u0437 xz. \u0412 \u043f\u0440\u0435\u0434\u0443\u043f\u0440\u0435\u0436\u0434\u0435\u043d\u0438\u0438 \u0442\u0430\u043a\u0436\u0435 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f\u043c \u043e\u0442\u043a\u0430\u0442\u0438\u0442\u044c Fedora Linux 40 \u043a \u0432\u0435\u0440\u0441\u0438\u0438, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0435\u0439 xz 5.4.\n\n\u0424\u0440\u043e\u0439\u043d\u0434 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b \u0431\u044d\u043a\u0434\u043e\u0440 \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0439 \u043d\u0435\u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 Debian. \u0421\u043e\u0432\u0435\u0442 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 Debian \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0434\u0438\u043b \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0439 \u0443\u0442\u0438\u043b\u0438\u0442\u044b \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435, \u043d\u0435\u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u0435 \u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u044b\u043f\u0443\u0441\u043a\u0438 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430. \u0412 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0435 \u0443\u043a\u0430\u0437\u0430\u043d\u043e, \u0447\u0442\u043e \u0432\u0435\u0440\u0441\u0438\u044f \u043f\u0430\u043a\u0435\u0442\u0430 \u0431\u044b\u043b\u0430 \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0435\u043d\u0430 \u043a 5.4.5 \u0441 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0435\u0439 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f\u043c \u043d\u0435\u0437\u0430\u043c\u0435\u0434\u043b\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043e\u0431\u043d\u043e\u0432\u0438\u0442\u044c\u0441\u044f. \u041f\u043e \u043f\u0440\u0435\u0434\u0432\u0430\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u043c \u0434\u0430\u043d\u043d\u044b\u043c, \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u0435 \u0432\u044b\u043f\u0443\u0441\u043a\u0438 Debian \u043d\u0435 \u043f\u043e\u0441\u0442\u0440\u0430\u0434\u0430\u043b\u0438.\nCVE-2024-3094 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 \u0438 \u043d\u0430 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 HomeBrew \u0434\u043b\u044f macOS. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u043e, \u0447\u0442\u043e Kali Linux \u2014 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432 \u043e\u0442 OffSec \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0442\u0435\u0441\u0442\u043e\u0432 \u043d\u0430 \u043f\u0440\u043e\u043d\u0438\u043a\u043d\u043e\u0432\u0435\u043d\u0438\u0435 \u2014 \u0442\u043e\u0436\u0435 \u043f\u043e\u0434\u0432\u0435\u0440\u0433\u0441\u044f \u0432\u043e\u0437\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044e \u044d\u0442\u043e\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0441 26 \u043f\u043e 29 \u043c\u0430\u0440\u0442\u0430\n\n\ud83d\udd14 ITsec NEWS", "creation_timestamp": "2024-03-30T15:17:29.000000Z"}, {"uuid": "c4e99ff2-4a42-445b-94af-7c893d3642c4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6884", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aScript to detect CVE-2024-3094.\nURL\uff1ahttps://github.com/bioless/xz_cve-2024-3094_detection\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-29T23:21:51.000000Z"}, {"uuid": "8db187f8-0532-4658-ac9d-d8aa6e649566", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6883", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aVerify that your XZ Utils version is not vulnerable to CVE-2024-3094\nURL\uff1ahttps://github.com/lypd0/CVE-2024-3094-Vulnerabity-Checker\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-29T21:14:08.000000Z"}, {"uuid": "d2f096ff-384c-4b1f-b7a7-0196f35f9482", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6882", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aQuick and dirty PoC for checking whether a vulnerable version of xz-utils is installed (CVE-2024-3094)\nURL\uff1ahttps://github.com/FabioBaroni/CVE-2024-3094-checker\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-29T20:31:04.000000Z"}, {"uuid": "587f78ce-f6a5-41b9-8ed9-73942c48bb1e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6881", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aInformation for CVE-2024-3094\nURL\uff1ahttps://github.com/byinarie/CVE-2024-3094-info\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-29T17:08:40.000000Z"}, {"uuid": "18484990-06b3-4514-831b-c4a25df17551", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6885", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aBash script and 1-liner to validate if a system is running a vulnerable version of \\\"xz\\\" as per CVE-2024-3094\nURL\uff1ahttps://github.com/Hacker-Hermanos/CVE-2024-3094_xz_check\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-30T00:01:58.000000Z"}, {"uuid": "9bbdb1de-9a0e-4219-a634-facee5dd7284", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6896", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aA script to detect if xz is vulnerable - CVE-2024-3094\nURL\uff1ahttps://github.com/Yuma-Tsushima07/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-31T11:13:50.000000Z"}, {"uuid": "75fef00d-075e-4fe3-ad37-ae97ee202884", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6893", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCVE-2024-3094\nURL\uff1ahttps://github.com/isuruwa/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-31T05:35:03.000000Z"}, {"uuid": "77be5031-f9f3-41b1-a403-0b9e0e439175", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6892", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aAn ssh honeypot with the XZ backdoor. CVE-2024-3094\nURL\uff1ahttps://github.com/lockness-Ko/xz-vulnerable-honeypot\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-30T22:10:38.000000Z"}, {"uuid": "245f2b15-6202-4fdc-95d2-be76f948b712", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6891", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aK8S and Docker Vulnerability Check for CVE-2024-3094\nURL\uff1ahttps://github.com/alokemajumder/CVE-2024-3094-Vulnerability-Checker-Fixer\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-30T19:26:05.000000Z"}, {"uuid": "d79be7ef-f789-404d-b64e-df2de5d295f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6903", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCVE-2024-3094\nURL\uff1ahttps://github.com/mesutgungor/xz-backdoor-vulnerability\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-01T09:12:06.000000Z"}, {"uuid": "c87d7dcc-ade3-45c1-86e0-ec1109243788", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6900", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aXZ-Utils\u5de5\u5177\u5e93\u6076\u610f\u540e\u95e8\u690d\u5165\u6f0f\u6d1e(CVE-2024-3094)\nURL\uff1ahttps://github.com/MrBUGLF/XZ-Utils_CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-01T01:57:37.000000Z"}, {"uuid": "78b112bf-92f4-4c3d-8690-bd04cafec660", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6914", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aScript en bash para revisar si tienes la vulnerabilidad CVE-2024-3094.\nURL\uff1ahttps://github.com/hackingetico21/revisaxzutils\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T01:24:43.000000Z"}, {"uuid": "45fb37b0-2f59-46cc-8ad8-db579b8e933f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6910", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1anotes, honeypot, and exploit demo for the xz backdoor (CVE-2024-3094)\nURL\uff1ahttps://github.com/amlweems/xzbot\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-01T16:47:02.000000Z"}, {"uuid": "62da47fb-1a02-460e-ba94-94ca9a1f9bdb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6909", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aChecker - CVE-2024-3094\nURL\uff1ahttps://github.com/gustavorobertux/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-01T15:23:16.000000Z"}, {"uuid": "26296491-eadc-4afa-bb08-5f7c5f3db40d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6906", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aObsidian notes about CVE-2024-3094\nURL\uff1ahttps://github.com/reuteras/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-01T12:42:11.000000Z"}, {"uuid": "7207cc68-9895-481e-b3c8-c8df6d8b9379", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6921", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCVE-2024-3094 - Checker (fix for arch etc)\nURL\uff1ahttps://github.com/pentestfunctions/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T09:00:58.000000Z"}, {"uuid": "7eacd799-f922-4953-a1dc-7ffae11ebd18", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6916", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aDetectar CVE-2024-3094\nURL\uff1ahttps://github.com/ScrimForever/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T03:38:15.000000Z"}, {"uuid": "40fb6303-f507-4189-9d7d-e6fbdde6b866", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6915", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCVE-2024-3094 XZ Backdoor Detector\nURL\uff1ahttps://github.com/devjanger/CVE-2024-3094-XZ-Backdoor-Detector\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T01:58:02.000000Z"}, {"uuid": "42399c16-1bd3-4331-a689-9894021a679e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6926", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aOur current information about the CVE-2024-3094 backdoor.\nURL\uff1ahttps://github.com/CyberGuard-Foundation/CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T23:16:35.000000Z"}, {"uuid": "96681b1b-0f38-4fdf-a5b7-d7da49f22451", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6925", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aapocalypxze: xz backdoor (2024) AKA CVE-2024-3094 related links\nURL\uff1ahttps://github.com/przemoc/xz-backdoor-links\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T20:19:55.000000Z"}, {"uuid": "ba82c526-b4ac-49c4-9e32-22cdf184bbcb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6924", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aDockerfile and Kubernetes manifests for reproduce CVE-2024-3094\nURL\uff1ahttps://github.com/r0binak/xzk8s\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-02T20:10:59.000000Z"}, {"uuid": "78732365-17a0-4fde-a91a-9049b8f98de8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6936", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aVerify if your installed version of xz-utils is vulnerable to CVE-2024-3094 backdoor\nURL\uff1ahttps://github.com/Bella-Bc/xz-backdoor-CVE-2024-3094-Check\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-03T13:11:50.000000Z"}, {"uuid": "b9361ab5-7dbf-4d54-8dee-6d487efe3f72", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6932", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aCollection of Detection, Fix, and exploit for CVE-2024-3094 \nURL\uff1ahttps://github.com/Security-Phoenix-demo/CVE-2024-3094-fix-exploits\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-03T07:57:12.000000Z"}, {"uuid": "b09700ac-1c25-44c8-8f27-439888f3e0db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6942", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aScans liblzma from xu-utils for backdoor (CVE-2024-3094)\nURL\uff1ahttps://github.com/weltregie/liblzma-scan\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-04T11:34:02.000000Z"}, {"uuid": "2a262589-78b7-4e35-b942-c5c105c400c6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6940", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aOur current information about the CVE-2024-3094 backdoor.\nURL\uff1ahttps://github.com/iheb2b/CVE-2024-3094-Checker\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-03T22:20:58.000000Z"}, {"uuid": "25ea484c-829c-4e7d-9f74-3660a11d3478", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6946", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aAn Ansible playbook to check and remediate CVE-2024-3094 (XZ Backdoor)\nURL\uff1ahttps://github.com/crfearnworks/ansible-CVE-2024-3094\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-04T14:40:34.000000Z"}, {"uuid": "0ccfa5e6-c580-4fe5-be3b-3e9d4beb0eef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6950", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aAn Ansible Role that installs the xz backdoor (CVE-2024-3094) on a Debian host and optionally installs the xzbot tool.\nURL\uff1ahttps://github.com/badsectorlabs/ludus_xz_backdoor\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-05T02:00:12.000000Z"}, {"uuid": "da52b5d8-9db6-4806-bbf1-5f58ae292bc9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6957", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aScan for files containing the signature from the `xz` backdoor (CVE-2024-3094)\nURL\uff1ahttps://github.com/Juul/xz-backdoor-scan\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-06T06:32:27.000000Z"}, {"uuid": "be1ee942-92e1-48de-9482-67af06107f55", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/7106", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aXZ Utils CVE-2024-3094 POC for Kubernetes\nURL\uff1ahttps://github.com/neuralinhibitor/xzwhy\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-18T13:10:43.000000Z"}, {"uuid": "7b7da82b-54db-4f42-b92d-4158d0daaffc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/RedPillDealer4833/138288", "content": "Someone should find that guy!\nhttps://www.armosec.io/blog/cve-2024-3094-kubernetes/", "creation_timestamp": "2024-04-01T23:20:35.000000Z"}, {"uuid": "dae9b8d3-3a4f-40ef-b28e-608861ca4fec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/iDpciKSSZoAuKLzHCBxsxmN8Po66tQiLuLn1GSrxH7iP_5o", "content": "", "creation_timestamp": "2026-04-23T21:00:04.000000Z"}, {"uuid": "8c1913a5-5db5-4cbd-a125-f6c04441e9b7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/By3side/349", "content": "\u0411\u044d\u043a\u0434\u043e\u0440 \u0432 XZ Utils \n\n\u0412\u0447\u0435\u0440\u0430 \u0431\u044b\u043b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d \u0431\u0435\u043a\u0434\u043e\u0440 (CVE-2024-3094) \u0432 \u0443\u0442\u0438\u043b\u0438\u0442\u0435 XZ \u0432 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0435 liblzma \u043f\u0440\u0435\u0434\u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u043e\u0439 \u0432\u043e \u043c\u043d\u043e\u0433\u0438\u0445  Linux - \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445.\n\n\u0412\u0441\u0435 \u0443 \u043a\u043e\u0433\u043e \u0441\u0442\u043e\u0438\u0442 \u0443\u044f\u0437\u0432\u0438\u043c\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f - \u0441\u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0435\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u044b, \u0442\u0430\u043a\u043e\u0439 \u043c\u0430\u0441\u0441\u043e\u0432\u043e\u0439 \u0438 \u0443\u0441\u043f\u0435\u0448\u043d\u043e\u0439 \u0430\u0442\u0430\u043a\u0438 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a \u043d\u0435 \u0431\u044b\u043b\u043e \u043e\u0447\u0435\u043d\u044c \u0434\u0430\u0432\u043d\u043e!\n\n\u041a\u0440\u0430\u0442\u043a\u043e:\n- \u0412\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 5.6.0 \u0438 5.6.1.\n- \u0415\u0441\u043b\u0438 \u043e\u043d\u0438 \u0443 \u0432\u0430\u0441 \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0430, \u0441\u0440\u043e\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u0443\u0441\u0442\u0430\u043d\u0430\u0432\u043b\u0438\u0432\u0430\u0439\u0442\u0435 \u043f\u0440\u043e\u0448\u043b\u0443\u044e \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0438 \u0441\u0447\u0438\u0442\u0430\u0439\u0442\u0435 \u0447\u0442\u043e \u0432\u044b \u0443\u0436\u0435 \u0432\u0437\u043b\u043e\u043c\u0430\u043d\u044b. \n- \u041c\u0435\u043d\u044f\u0439\u0442\u0435 \u043f\u0430\u0440\u043e\u043b\u0438, \u043f\u0440\u043e\u0432\u0435\u0440\u044f\u0439\u0442\u0435 cron, \u0441\u043c\u043e\u0442\u0440\u0438\u0442\u0435 \u043b\u043e\u0433\u0438, \u0438\u0449\u0438\u0442\u0435 \u0441\u043b\u0435\u0434\u044b \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432.\n\n\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u044b\u0439 FAQ \u043e\u0442 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Tenable \u043f\u0440\u0438\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u044e \u0432 \u0432\u0438\u0434\u0435 \u0441\u043a\u0440\u0438\u043d\u0448\u043e\u0442\u043e\u0432, \u0442.\u043a. \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435 \u0435\u0433\u043e \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0441 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 IP \u043d\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0441\u044f.\n\n\u041d\u043e\u0432\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u043d\u0435 \u0432\u0441\u0435\u0433\u0434\u0430 \u0441\u0430\u043c\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u0430\u044f. \u041e\u043f\u0435\u043d\u0441\u043e\u0440\u0441 \u043d\u0435 \u0433\u0430\u0440\u0430\u043d\u0442\u0438\u044f \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u0431\u0435\u043a\u0434\u043e\u0440\u043e\u0432, \u0442\u0430\u043a\u043e\u0432\u0430 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u044c.", "creation_timestamp": "2024-03-30T11:59:39.000000Z"}, {"uuid": "ba3c7159-e585-4fa0-b00f-f48aeb72104f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/Yz_0I0Fxhv491-raEl6MFGybyjENBbF5tAsDbTjDjAX0wLY", "content": "", "creation_timestamp": "2025-10-22T21:00:04.000000Z"}, {"uuid": "9a29f5e0-7c0f-4827-9bbd-e884c618c58b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/k65Luaba8Fo3blOkMXIMaYfKgMppZ09_hRCYJGbV4Az32CA", "content": "", "creation_timestamp": "2025-10-16T21:00:05.000000Z"}, {"uuid": "a9be8e02-25c4-44bd-ab33-c537aaf088e1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/tech_b0lt_Genona/4385", "content": "\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u043d\u0435\u0441\u043a\u0443\u0447\u043d\u044b\u043c XZ\n\n\u041f\u043e\u043b\u043d\u0430\u044f \u0440\u0435\u0442\u0440\u043e\u0441\u043f\u0435\u043a\u0442\u0438\u0432\u0430 \u043f\u0440\u043e\u0434\u0432\u0438\u0436\u0435\u043d\u0438\u044f \u0431\u044d\u043a\u0434\u043e\u0440\u0430 \u0432 \u043f\u0430\u043a\u0435\u0442 xz \u0441\u043e \u0432\u0441\u0435\u043c\u0438 \u0441\u0441\u044b\u043b\u043a\u0430\u043c\u0438 \u0438 \u0442.\u0434., \u0442\u0430\u043c \u0442\u0435\u043a\u0441\u0442\u0430 \u043c\u043d\u043e\u0433\u043e, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043d\u0435 \u0441\u0442\u0430\u043b \u0441\u044e\u0434\u0430 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u0442\u044c (\u0432\u0442\u044b\u043a\u043d\u0443\u043b \u0434\u043e\u043c\u0435\u043d .me, \u0434\u043e\u043b\u0436\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0432\u043d\u0435 \u0420\u0424)\nhttps://www.opennet.me/opennews/art.shtml?num=60880\n+\nFAQ on the xz-utils backdoor\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\n+\n\u0414\u043e\u0448\u043b\u043e \u0443\u0436\u0435 \u0438 \u0434\u043e CISA\n\nReported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094\nhttps://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094", "creation_timestamp": "2024-03-30T16:49:14.000000Z"}, {"uuid": "419cafde-9808-4c30-b23a-b3a3ea29a8c9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/E2S7IdFkTtFoLBM7WX7LHdK6NnluTQpvrIlBfsXs1ueBQY4", "content": "", "creation_timestamp": "2025-09-12T09:00:05.000000Z"}, {"uuid": "330e5adb-d99d-4ac3-aa8f-2946a641254d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/NinjaSec/201", "content": "\ud83d\udd27 CVE Exploitation Tools (2024\u20132025)\n\n1. CVE-2024-25600 \u2013 WordPress Bricks Builder RCE\n\n2. CVE-2024-24919 \u2013 Check Point Security Gateway RCE\n\n3. CVE-2024-29025 \u2013 Netty HttpPostRequestDecoder DoS\n\n4. CVE-2024-21525 \u2013 node-twain Buffer Overflow\n\n5. CVE-2024-3094 \u2013 XZ Backdoor Detector\n\n6. CVE-2024-21515 \u2013 OpenCart Reflected XSS\n\n7. CVE-2024-21552 \u2013 SuperAGI Arbitrary Code Execution\n\n8. CVE-2024-56249 \u2013 WordPress WPMasterToolKit Arbitrary File Upload\n\n9. CVE-2024-24919 \u2013 Check Point VPN Exploit\n\n10. CVE-2024-24919 \u2013 Python Exploit Script\n\nPython script to exploit CVE-2024-24919 vulnerability.\n\nGitHub: LucasKatashi/CVE-2024-24919\n\n11. CVE-2024-24919 \u2013 Exploit PoC\n\nProof-of-Concept for exploiting CVE-2024-24919.\n\nGitHub: seed1337/CVE-2024-24919-POC\n\n12. CVE-2024-24919 \u2013 Check Point Remote Access VPN Exploit\n\nScripts to exploit CVE-2024-24919 in Check Point VPNs.\n\nGitHub: Praison001/CVE-2024-24919-Check-Point-Remote-Access-VPN\n\n13. CVE-2024-25600 \u2013 Alternate Exploit Script\n\nAnother implementation to exploit Bricks Builder RCE.\n\nGitHub: meli0dasH4ck3r/cve-2024-25600\n\n14. CVE-2024-25600 \u2013 Exploit Script\n\nPython script to exploit Bricks Builder RCE vulnerability.\n\nGitHub: K3ysTr0K3R/CVE-2024-25600-EXPLOIT \n\n\n\ud83d\udd27 CVE Exploitation Tools & Frameworks\n\n1. trickest/cve\n\n\ud83d\udd17 https://github.com/trickest/cve\n\n2. PayloadsAllTheThings \u2013 CVE Exploits\n\n\ud83d\udd17 https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/CVE%20Exploits/README.md\n\n3. qazbnm456/awesome-cve-poc\n\n\ud83d\udd17 https://github.com/qazbnm456/awesome-cve-poc\n\n4. intel/cve-bin-tool\n\n\ud83d\udd17 https://github.com/intel/cve-bin-tool\n\n5. cve-search/cve-search\nN\n\n\ud83d\udd17 https://github.com/cve-search/cve-search\n\n6. vertoforce/CVE-Enrichment\n\n\ud83d\udd17 https://github.com/vertoforce/CVE-Enrichment\n\n7. TURROKS/CVE_Prioritizer\n\n\ud83d\udd17 https://github.com/TURROKS/CVE_Prioritizer\n\n8. clearlinux/cve-check-tool\n\n\ud83d\udd17 https://github.com/clearlinux/cve-check-tool\n\n9. cddmp/cvecheck\n\n\ud83d\udd17 https://github.com/cddmp/cvecheck\n\n10. center-for-threat-informed-defense/attack_to_cve\n\nMaps MITRE ATT&CK techniques to CVEs to characterize vulnerability impacts.\n\n\ud83d\udd17 https://github.com/center-for-threat-informed-defense/attack_to_cve\n\n\n\ud83e\uddea Specific CVE Exploit Tools\n\n11. CVE-2024-25600 Exploit Tool\n\nDesigned to exploit a vulnerability in the Bricks Builder plugin for WordPress.\n\n\ud83d\udd17 https://github.com/Chocapikk/CVE-2024-25600\n\n12. RevoltSecurities/CVE-2024-24919\n\nTool to detect and exploit CVE-2024-24919 vulnerability.\n\n\ud83d\udd17 https://github.com/RevoltSecurities/CVE-2024-24919\n\n13. ROCA Detection Tool\n\nDetects RSA keys vulnerable to the ROCA vulnerability (CVE-2017-15361).\n\n\ud83d\udd17 https://github.com/crocs-muni/roca\n\n\ud83d\udee0\ufe0f Additional Tools & Resources\n\n14. Goby\n\nA network security assessment tool that can scan for vulnerabilities and map attack surfaces.\n\n\ud83d\udd17 https://github.com/gobysec/Goby\n\n15. awesome-pentestu\n\nA curated list of penetration testing resources, including tools for CVE exploitation.\n\n\ud83d\udd17 https://github.com/enaqx/awesome-pentest\n\n16. awesome-bugbounty-tools\n\nA collection of tools useful for bug bounty hunting, some of which relate to CVE exploitation.\n\n\ud83d\udd17 https://github.com/vavkamil/awesome-bugbounty-tools\n\n17. cyberguideme/Tools\n\nA repository of various cybersecurity tools, including those for exploiting known vulnerabilities.\n\n\ud83d\udd17 https://github.com/cyberguideme/Tools\n\n\n#GrayHats", "creation_timestamp": "2025-04-18T19:33:22.000000Z"}, {"uuid": "29d61e65-a228-4919-ac87-ba3d9c3c0e2f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/BleepingComputer/19717", "content": "\u200aNew XZ backdoor scanner detects implant in any Linux binary\n\nFirmware security firm Binarly has released a free online scanner to detect Linux executables impacted by the XZ Utils supply chain attack, tracked as CVE-2024-3094. [...]\n\nhttps://www.bleepingcomputer.com/news/security/new-xz-backdoor-scanner-detects-implant-in-any-linux-binary/", "creation_timestamp": "2024-04-02T18:52:26.000000Z"}, {"uuid": "b2489edc-2aaf-4b18-b227-34dc089f13ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/hackyourmom/12367", "content": "\ud83d\udd0d \u0414\u043e\u0441\u043b\u0456\u0434\u043d\u0438\u043a\u0438 \u0432\u0438\u044f\u0432\u0438\u043b\u0438 \u043f\u043e\u043d\u0430\u0434 35 Docker Hub-\u043e\u0431\u0440\u0430\u0437\u0456\u0432, \u0437\u0430\u0440\u0430\u0436\u0435\u043d\u0438\u0445 XZ Utils-\u0431\u0435\u043a\u0434\u043e\u0440\u043e\u043c (CVE-2024-3094), \u0432\u043a\u043b\u044e\u0447\u043d\u043e \u0437 1\ufe0f\u20e32\ufe0f\u20e3 \u043e\u0444\u0456\u0446\u0456\u0439\u043d\u0438\u043c\u0438 Debian-\u043e\u0431\u0440\u0430\u0437\u0430\u043c\u0438. \u0428\u043a\u0456\u0434\u043b\u0438\u0432\u0438\u0439 \u043a\u043e\u0434 \u0443 \u0431\u0456\u0431\u043b\u0456\u043e\u0442\u0435\u0446\u0456 liblzma/so \u0434\u043e\u0437\u0432\u043e\u043b\u044f\u0454 \u043e\u0431\u0445\u0456\u0434 \u0430\u0432\u0442\u0435\u043d\u0442\u0438\u0444\u0456\u043a\u0430\u0446\u0456\u0457 \u0442\u0430 \u0432\u0438\u043a\u043e\u043d\u0430\u043d\u043d\u044f \u043a\u043e\u043c\u0430\u043d\u0434 \u0432\u0456\u0434 \u0456\u043c\u0435\u043d\u0456 root \u0447\u0435\u0440\u0435\u0437 SSH \ud83d\udc7e\ud83e\udd14 #cybernews", "creation_timestamp": "2025-08-13T15:29:28.000000Z"}, {"uuid": "70f983ef-3a35-4659-ba6f-f179eab95005", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/poxek/3852", "content": "\ud83d\ude08 [ Kali Linux @kalilinux ]\n\nThe xz package, starting from version 5.6.0 to 5.6.1, was found to contain a backdoor. The impact of this vulnerability affected Kali between March 26th to March 29th. If you updated your Kali installation on or after March 26th, it is crucial to apply the latest updates today:\n\nsudo apt update && sudo apt install --only-upgrade liblzma5\n\n\ud83d\udd17 https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/\n\ud83d\udd17 https://www.openwall.com/lists/oss-security/2024/03/29/4\n\ud83d\udd17 https://threadreaderapp.com/thread/1773786266074513523.html\n\n\ud83d\udc25 [ tweet ]\n\n\u26a0\ufe0f UPDATE ASAP \u26a0\ufe0f", "creation_timestamp": "2024-03-30T07:10:54.000000Z"}, {"uuid": "ffd55d49-447d-4942-ab59-54bd75d90237", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/road_to_oscp/307", "content": "[ XZ backdoor - CVE-2024-3094 ]\n\n! Backdoor in upstream xz/liblzma leading to SSH server compromise !\n\nCheck:\nxz --version\n\n5.6.0 & 5.6.1 \u2014 v u l n e r a b l e\n\nUpdate:\nsudo apt update && sudo apt install --only-upgrade liblzma5\n\nSummary:\nhttps://boehs.org/node/everything-i-know-about-the-xz-backdoor\n\nHow it all started (email): \nhttps://www.openwall.com/lists/oss-security/2024/03/29/4\n\nGitHub Thread:\nhttps://web.archive.org/web/20240329223553/https://github.com/tukaani-project/xz/issues/92\n\nMessage from Kali Linux team:\nhttps://twitter.com/kalilinux/status/1773786266074513523\nThe xz package, starting from version 5.6.0 to 5.6.1, was found to contain a backdoor. The impact of this vulnerability affected Kali between March 26th to March 29th. If you updated your Kali installation on or after March 26th, it is crucial to apply the latest updates today.\n\nNote that (almost) all Linux distros could be affected!\nFor example, Fedora \u2014 Red Hat warned users to immediately stop using systems running Fedora development and experimental versions:\nhttps://www.bleepingcomputer.com/news/security/red-hat-warns-of-backdoor-in-xz-tools-used-by-most-linux-distros\n\nNews:\nhttps://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor\n\nAnd from CISA:\nhttps://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094\n\nSo... JiaT75 made 750 commits in 2 years and finally backdoored XZ...", "creation_timestamp": "2024-03-30T13:40:51.000000Z"}, {"uuid": "af918347-30bd-4937-a669-3cc96fffe469", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6897", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aAnsible playbook for patching CVE-2024-3094\nURL\uff1ahttps://github.com/Simplifi-ED/CVE-2024-3094-patcher\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-03-31T14:11:39.000000Z"}, {"uuid": "2e5418ef-27ad-4b7b-9ef0-f20e649a8eaf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/GithubRedTeam/6939", "content": "GitHub\u76d1\u63a7\u6d88\u606f\u63d0\u9192\uff01\uff01\uff01 \n\n\u66f4\u65b0\u4e86\uff1aCVE-2024\n\u63cf\u8ff0\uff1aThe repository consists of a checker file that confirms if your xz version and xz-utils package is vulnerable to CVE-2024-3094.\nURL\uff1ahttps://github.com/TheTorjanCaptain/CVE-2024-3094-Checker\n\n\u6807\u7b7e\uff1a#CVE-2024", "creation_timestamp": "2024-04-03T19:15:56.000000Z"}, {"uuid": "364d511c-be8b-4af9-96b0-4417708af884", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/ptescalator/240", "content": "\u0427\u0442\u043e \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u043e \u0441 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c\u044e OpenSSH \u0432 2024 \u0433\u043e\u0434\u0443 \ud83d\udeaa\n\n\u0412\u0437\u0433\u043b\u044f\u043d\u0435\u043c \u043d\u0430 \u0442\u0430\u0439\u043c\u043b\u0430\u0439\u043d:\n\n\u2022 \u0412\u0435\u0441\u043d\u0430. \u0411\u044d\u043a\u0434\u043e\u0440 \u0432 xz-utils (CVE-2024-3094). \u0412 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u0435 \u0435\u0433\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044f \u0431\u044b\u043b\u0438 \u0441\u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0435\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0441 systemd, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0432 OpenSSH \u0435\u0441\u0442\u044c \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u044c liblzma, \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0430\u044f \u0432 \u043d\u0435\u043c \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u0438 \u0441\u0430\u043c\u0438\u043c OpenSSH \u043d\u0430\u043f\u0440\u044f\u043c\u0443\u044e \u043d\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u0430\u044f (\u0442\u043e \u0435\u0441\u0442\u044c \u0441\u043a\u043e\u0440\u0435\u0435 \u0440\u0435\u0447\u044c \u043e\u0431 \u0430\u0442\u0430\u043a\u0435 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a \u044d\u0442\u0438\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432, \u0430 \u043d\u0435 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e \u043d\u0430 OpenSSH).\n\n\u2022 \u0418\u044e\u043b\u044c. \u041a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043e\u043f\u0430\u0441\u043d\u0430\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u00ab\u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f \u0433\u043e\u043d\u043a\u0438\u00bb \u0434\u043b\u044f \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 \u0431\u0430\u0437\u0435 glibc, \u043f\u043e\u043b\u0443\u0447\u0438\u0432\u0448\u0430\u044f \u043d\u0430\u0437\u0432\u0430\u043d\u0438\u0435 regreSSHion (CVE-2024-6387) \u0438 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0449\u0430\u044f \u0441\u043e\u0431\u043e\u0439 \u043f\u0435\u0440\u0435\u0440\u043e\u0436\u0434\u0435\u043d\u043d\u0443\u044e CVE-2006-5051.\n\n\u2022 \u0412\u0441\u0435 \u0442\u043e\u0442 \u0436\u0435 \u0438\u044e\u043b\u044c. \u041e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u0430 \u0441\u0445\u043e\u0436\u0430\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430, \u043f\u043e\u043b\u0443\u0447\u0438\u0432\u0448\u0430\u044f \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440 CVE-2024-6409.\n\n\u2022 \u0410\u0432\u0433\u0443\u0441\u0442. \u0415\u0449\u0435 \u043e\u0434\u043d\u0430, \u0443\u0436\u0435 \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u0447\u043d\u0430\u044f \u0434\u043b\u044f FreeBSD, CVE-2024-7589.\n\n\u2754 \u0427\u0442\u043e \u044d\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 \u0431\u044b\u043b\u043e\n\n\u0418\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0443\u0442\u0432\u0435\u0440\u0436\u0434\u0430\u044e\u0442, \u0447\u0442\u043e \u0443\u0441\u043f\u0435\u0448\u043d\u0430\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u00ab\u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0439 \u0433\u043e\u043d\u043a\u0438\u00bb \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c RCE \u043d\u0430 \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445. \u0411\u043e\u043b\u0435\u0435 \u0442\u043e\u0433\u043e, regreSSHion \u2014 \u0433\u043b\u0430\u0432\u043d\u044b\u0439 \u0431\u0430\u0433 (\u0437\u0430\u0442\u0440\u0430\u0433\u0438\u0432\u0430\u0435\u0442 \u043f\u0440\u0438\u0432\u0438\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 sshd) \u2014 \u0441\u0442\u0430\u0432\u0438\u0442 \u043f\u043e\u0434 \u0443\u0433\u0440\u043e\u0437\u0443 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0430 SSH-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0441 glibc. \u042d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u043d\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u043e\u0441\u043e\u0431\u043e\u0439 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u0430 (\u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0430\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u0430 \u0438 \u0434\u043b\u044f \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 \u043f\u043e \u0443\u043c\u043e\u043b\u0447\u0430\u043d\u0438\u044e). \u041d\u043e \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u043f\u0443\u0431\u043b\u0438\u0447\u043d\u043e\u0433\u043e PoC \u043d\u0435\u0442 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440.\n\n\u041c\u044b \u0440\u0435\u0448\u0438\u043b\u0438 \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f, \u0442\u0430\u043a \u043b\u0438 \u043e\u043f\u0430\u0441\u043d\u044b \u044d\u0442\u0438 \u00ab\u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f \u0433\u043e\u043d\u043a\u0438\u00bb \u0438 \u043a\u0430\u043a\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u044b \u0432 sshd \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u044b \u043d\u0435 \u0434\u043e\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u044d\u0442\u043e\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0438\u043b\u0438 \u0445\u043e\u0442\u044f \u0431\u044b \u0443\u043c\u0435\u043d\u044c\u0448\u0438\u0442\u044c \u0443\u0449\u0435\u0440\u0431 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e\u0439 \u0430\u0442\u0430\u043a\u0438. \u041f\u043e\u043f\u0443\u0442\u043d\u043e \u043f\u0440\u043e\u0432\u0435\u043b\u0438 \u043e\u0431\u0437\u043e\u0440 \u0438 \u043e\u0441\u0442\u0430\u043b\u044c\u043d\u044b\u0445 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 OpenSSH \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0435\u0433\u043e \u0433\u043e\u0434\u0430.\n\n\ud83d\udd23 \u0418 \u0442\u0435\u043f\u0435\u0440\u044c \u0432\u0441\u0435 \u044d\u0442\u043e \u0441 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0431\u0430\u0437\u043e\u0439 \u0438 \u044d\u043a\u0441\u043a\u0443\u0440\u0441\u043e\u043c \u043d\u0430 30 \u0441\u0435\u043a\u0443\u043d\u0434 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e \u0432 \u043d\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u0433\u0435 \u043d\u0430 \u0425\u0430\u0431\u0440\u0435. Enjoy!\n\n#CVE #escvr\n@ptescalator", "creation_timestamp": "2025-01-30T08:33:54.000000Z"}, {"uuid": "7b75ad20-6665-42ac-8758-291e09bbfddd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/2lW_VAPY7dTgBAMOHqmOlsHgXjuPlUYLIzJwxlW1R5vFC24", "content": "", "creation_timestamp": "2025-06-27T21:00:04.000000Z"}, {"uuid": "7beacd47-5f5f-4a60-91e6-7a6cd4e34629", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/S3luyvJ2R7xCTSLpSlkUyEdAxTgE_nQEIWaJA9giiuBhhRI", "content": "", "creation_timestamp": "2025-06-03T15:00:07.000000Z"}, {"uuid": "e97dcda9-f728-450e-9e96-9c1b3e7a7408", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/Russian_OSINT/5662", "content": "\ud83d\ude01 GNOME \u0444\u043e\u0440\u0441\u0438\u0440\u0443\u0435\u0442 \u0431\u043e\u043b\u0435\u0435 \u0442\u0435\u0441\u043d\u0443\u044e \u0438\u043d\u0442\u0435\u0433\u0440\u0430\u0446\u0438\u044e \u0441 systemd\n\n\u041e\u0434\u0438\u043d \u0438\u0437 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 GNOME \u0410\u0434\u0440\u0438\u0430\u043d \u0412\u043e\u0432\u043a (Adrian Vovk) \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u0443 \u0441\u0435\u0431\u044f \u0432 \u0431\u043b\u043e\u0433\u0435 \u043e \u043f\u043b\u0430\u043d\u0430\u0445 \u0431\u043e\u043b\u0435\u0435 \u0442\u0435\u0441\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0433\u0440\u0430\u0446\u0438\u0438 \u043e\u043a\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0433\u043e \u0441\u0442\u043e\u043b\u0430 GNOME \u0441 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u043e\u043c systemd.\n\n\u0415\u0441\u043b\u0438 \u0440\u0430\u043d\u044c\u0448\u0435 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u044c \u0431\u044b\u043b\u0430 \u043d\u0435\u0444\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0438 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u043b\u0430 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0430\u043d\u0430\u043b\u043e\u0433\u0438 \u0434\u043b\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432, \u0442\u043e \u0442\u0435\u043f\u0435\u0440\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0437\u0430\u0442\u0440\u043e\u043d\u0443\u0442 \u044f\u0434\u0440\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u041c\u0435\u043d\u0435\u0434\u0436\u0435\u0440 \u0432\u0445\u043e\u0434\u0430 GDM \u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440 \u0441\u0435\u0441\u0441\u0438\u0439 gnome-session \u043f\u043e\u043b\u0443\u0447\u0430\u0442 \u043f\u0440\u044f\u043c\u044b\u0435 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442 systemd-userdb \u0438 \u0434\u0440\u0443\u0433\u0438\u0445 \u0435\u0433\u043e \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u043e\u0432.\n\n\u041e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u0430\u044f \u043f\u043e\u0437\u0438\u0446\u0438\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e\u043c, \u0437\u0432\u0443\u0447\u0438\u0442 \u043f\u0440\u0430\u0433\u043c\u0430\u0442\u0438\u0447\u043d\u043e: \u043e\u0442\u043a\u0430\u0437 \u043e\u0442 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u043c\u0438\u043d\u043e\u0440\u0438\u0442\u0430\u0440\u043d\u044b\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0441\u043a\u043e\u043d\u0446\u0435\u043d\u0442\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u043d\u0430 \u0435\u0434\u0438\u043d\u043e\u043c, \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u0441\u0442\u0435\u043a\u0435, \u043f\u043e\u0432\u044b\u0448\u0430\u044f \u0435\u0433\u043e \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c. \n\n\u041e\u0434\u043d\u0430\u043a\u043e \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u043a\u0438\u0431\u0435\u0440\u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438, \u043d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u0443\u044e \u043b\u043e\u0433\u0438\u043a\u0443, \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0432 \u043d\u0435\u0441\u0435\u0442 \u0432 \u0441\u0435\u0431\u0435 \u0440\u044f\u0434 \u0444\u0443\u043d\u0434\u0430\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0445 \u0440\u0438\u0441\u043a\u043e\u0432. \n\n\u041a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0442\u043e\u0440\u044b \u0432\u044b\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043c\u043d\u0435\u043d\u0438\u0435, \u0447\u0442\u043e c \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u0433\u043b\u043e\u0431\u0430\u043b\u044c\u043d\u043e\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u044d\u043a\u043e\u0441\u0438\u0441\u0442\u0435\u043c\u044b Linux, \"\u0433\u043d\u043e\u043c\u044b\" \u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u0443\u044e\u0442 \u0440\u0438\u0441\u043a\u0438. \u041d\u0435\u0434\u0430\u0432\u043d\u0438\u0439 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442 \u0441 \u0431\u044d\u043a\u0434\u043e\u0440\u043e\u043c XZ Utils (CVE-2024-3094). \u0410\u0442\u0430\u043a\u0430 \u0431\u044b\u043b\u0430 \u043d\u0430\u0446\u0435\u043b\u0435\u043d\u0430 \u043d\u0430 liblzma, \u043e\u0442 \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 libsystemd, \u0438 \u0447\u0443\u0442\u044c \u043d\u0435 \u043f\u0440\u0438\u0432\u0435\u043b\u0430 \u043a \u0433\u043b\u043e\u0431\u0430\u043b\u044c\u043d\u043e\u0439 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u0435.\n\n\u0413\u043b\u0430\u0432\u043d\u044b\u0439 \u0440\u0438\u0441\u043a \u0437\u0430\u043a\u043b\u044e\u0447\u0430\u0435\u0442\u0441\u044f \u0432 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u043e\u043d\u043e\u043a\u0443\u043b\u044c\u0442\u0443\u0440\u044b \u0438 \u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u0441\u0435\u0445 \u0443\u0433\u0440\u043e\u0437 \u0432 \u043e\u0434\u043d\u043e\u0439 \u0442\u043e\u0447\u043a\u0435. systemd \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043a\u0430\u043a PID 1 \u2014 \u0441\u0430\u043c\u044b\u0439 \u043f\u0440\u0438\u0432\u0438\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0435. \u041a\u043e\u043d\u0442\u0440\u043e\u043b\u044c \u043d\u0430\u0434 \u043d\u0438\u043c \u043e\u0437\u043d\u0430\u0447\u0430\u0435\u0442 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c \u043d\u0430\u0434 \u0432\u0441\u0435\u043c. \u0420\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0435 systemd \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u043a\u043b\u044e\u0447\u0435\u0432\u044b\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 \u0443\u0436\u0435 \u0441\u043e\u0437\u0434\u0430\u043b\u043e \u043e\u043f\u0430\u0441\u043d\u0443\u044e \u043c\u043e\u043d\u043e\u043f\u043e\u043b\u0438\u044e, \u0430 \u0436\u0435\u0441\u0442\u043a\u0430\u044f \u043f\u0440\u0438\u0432\u044f\u0437\u043a\u0430 GNOME \u043e\u043a\u043e\u043d\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0435\u0451 \u0446\u0435\u043c\u0435\u043d\u0442\u0438\u0440\u0443\u0435\u0442. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 (Fedora, Debian, Ubuntu, Arch) \u043f\u0440\u0438\u043d\u044f\u043b\u0438 systemd \u043a\u0430\u043a \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442 \u043f\u043e \u0443\u043c\u043e\u043b\u0447\u0430\u043d\u0438\u044e. \n\n\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 systemd \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0432\u0435\u043b\u0430\u0441\u044c \u0438 \u0441\u043f\u043e\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043b\u0430\u0441\u044c Red Hat (\u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043a\u0443\u043f\u0438\u043b\u0430 IBM). \u041a\u043b\u044e\u0447\u0435\u0432\u044b\u0435 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u041b\u0435\u043d\u043d\u0430\u0440\u0442\u0430 \u041f\u043e\u0442\u0442\u0435\u0440\u0438\u043d\u0433\u0430, \u0431\u044b\u043b\u0438 \u0438\u0445 \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c\u0438. \u0421\u0435\u0439\u0447\u0430\u0441 \u041f\u043e\u0442\u0442\u0435\u0440\u0438\u043d\u0433 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0432 Microsoft.\n\n\u041f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0432\u0438\u0434\u044f\u0442 \u0432 \u043d\u043e\u0432\u043e\u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0443 IBM/\ud83c\udfa9 Red Hat \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u044c \u043f\u043e\u043b\u043d\u044b\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c \u043d\u0430\u0434 \u044d\u043a\u043e\u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 Linux, \u043f\u0440\u0435\u0432\u0440\u0430\u0442\u0438\u0432 \u0435\u0451 \u0432 \u043f\u043e\u0434\u043e\u0431\u0438\u0435 Windows.\n\n\u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u043c \u043f\u0440\u0438\u0434\u0451\u0442\u0441\u044f \u043e\u0442\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u043e\u0442 GNOME. \u041b\u0438\u0431\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043a\u043e\u0441\u0442\u044b\u043b\u0438 (\u043a\u0430\u043a elogind), \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0441\u0435\u0433\u0434\u0430 \u0431\u0443\u0434\u0443\u0442 \u043c\u0435\u043d\u0435\u0435 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u043c\u0438.\n\n\u0421\u043e\u0433\u043b\u0430\u0441\u043d\u043e \u0444\u0443\u043d\u0434\u0430\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u043c \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0430\u043c \u0444\u0438\u043b\u043e\u0441\u043e\u0444\u0438\u0438 Unix \u0438 Linux, \u0430\u0440\u0433\u0443\u043c\u0435\u043d\u0442 \"\u043d\u0435 \u043d\u0440\u0430\u0432\u0438\u0442\u0441\u044f \u2014 \u043d\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0439\" \u0442\u0435\u0440\u044f\u0435\u0442 \u0441\u0432\u043e\u044e \u0441\u0438\u043b\u0443, \u0442\u0430\u043a \u043a\u0430\u043a GNOME \u0434\u0435\u043b\u0430\u0435\u0442 systemd \u043f\u043e \u0441\u0443\u0442\u0438 \u0431\u0435\u0437\u0430\u043b\u044c\u0442\u0435\u0440\u043d\u0430\u0442\u0438\u0432\u043d\u044b\u043c.\n\n\ud83e\udd14 \u041f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0437\u0430\u0433\u043e\u0432\u043e\u0440\u0430 \u0432 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u044f\u0445 \u043e \u0437\u0430\u043a\u043b\u0430\u0434\u043a\u0430\u0445 \u0410\u041d\u0411 \u0432 systemd \u043b\u0443\u0447\u0448\u0435 \u0434\u0430\u0436\u0435 \u043d\u0435 \u043d\u0430\u0447\u0438\u043d\u0430\u0442\u044c \u0440\u0430\u0441\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c...\n\n\ud83c\udf83 \u041d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u043e, \u0447\u0442\u043e \u0441\u0442\u043e\u0440\u043e\u043d\u043d\u0438\u043a\u043e\u0432 \u043a\u043e\u0440\u0438\u0446\u044b \u0438 \"\u043b\u044e\u0431\u0438\u0442\u0435\u043b\u0435\u0439 \u043f\u043e\u0433\u043e\u043d\u044f\u0442\u044c \u0432 \u043a\u0435\u0434\u0430\u0445\" \u0441\u0442\u0430\u043d\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435.\n\n\u270b @Russian_OSINT", "creation_timestamp": "2025-06-11T14:48:46.000000Z"}, {"uuid": "c35eb6b4-027a-4386-93ae-1b1ab3a52ad3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/kasperskyb2b/1205", "content": "\ud83d\udea8 \u0411\u044d\u043a\u0434\u043e\u0440 \u0432 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 Linux-\u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445\n\n\u0412\u0441\u0435 \u0432\u044b\u0445\u043e\u0434\u043d\u044b\u0435 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u043b\u0430\u0441\u044c \u0434\u0435\u0442\u0435\u043a\u0442\u0438\u0432\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u0438\u0437 \u043c\u0438\u0440\u0430 open source. \u0412 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0435 \u0438 \u0443\u0442\u0438\u043b\u0438\u0442\u0430\u0445 \u0434\u043b\u044f \u043a\u043e\u043c\u043f\u0440\u0435\u0441\u0441\u0438\u0438 XZ \u0431\u044b\u043b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d \u0431\u044d\u043a\u0434\u043e\u0440 (CVE-2024-3094), \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u0440\u0438 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0432\u044b\u043f\u043e\u043b\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0435, \u043d\u0435 \u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044f \u0441\u043b\u0435\u0434\u043e\u0432 \u0432 \u043b\u043e\u0433\u0430\u0445 sshd.\n\n\u0422\u0440\u043e\u044f\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 5.6.0 \u0438 5.6.1 \u0443\u0441\u043f\u0435\u043b\u0438 \u043f\u043e\u043f\u0430\u0441\u0442\u044c \u0432 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 Linux, \u0432\u044b\u043f\u0443\u0449\u0435\u043d\u043d\u044b\u0435 \u0432 \u043c\u0430\u0440\u0442\u0435:\n\ud83d\udd34 Alpine (5.6.0 \u2014 5.6.1-r1 )\n\ud83d\udd34 Debian (\u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438) 5.5.1alpha-0.1 \u2014 5.6.1-1.\n\ud83d\udd34 Fedora Rawhide (\u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438)\n\ud83d\udd34 Kali Linux \n\ud83d\udd34 openSUSE Tumbleweed \u0438 MicroOS \n\n\u0414\u0440\u044f\u043d\u044c \u043d\u0435 \u0431\u044b\u043b\u0430 \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0430 \u0432 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u044b: Debian Stable, RHEL, Suse Linux Enterprise.\nArch Linux \u043f\u0438\u0448\u0443\u0442, \u0447\u0442\u043e \u0445\u043e\u0442\u044f \u0432 \u043e\u0431\u0440\u0430\u0437\u0430\u0445 \u0431\u044b\u043b\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u044b\u0435 \u043f\u0430\u043a\u0435\u0442\u044b, \u0438\u0437-\u0437\u0430 \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0438 \u043b\u0438\u043d\u043a\u043e\u0432\u043a\u0438 openssh \u0438 liblzma \u0432 Arch \u0431\u044d\u043a\u0434\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c. \u041f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0442\u043e \u0436\u0435 \u0441\u0430\u043c\u043e\u0435 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u043f\u0440\u043e Fedora 40 \u2014 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 \u043f\u0430\u043a\u0435\u0442\u044b \u0431\u044b\u043b\u0438, \u043d\u043e \u0442\u0440\u043e\u044f\u043d \u043d\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\n\n\u0414\u043b\u044f \u0441\u043e\u043c\u043d\u0435\u0432\u0430\u044e\u0449\u0438\u0445\u0441\u044f \u0443\u0436\u0435 \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u043e Yara-\u043f\u0440\u0430\u0432\u0438\u043b\u043e.\n\u0422\u0435\u043c, \u043a\u0442\u043e \u0443\u0441\u043f\u0435\u043b \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u044c \u0437\u0430\u0442\u0440\u043e\u044f\u043d\u0435\u043d\u043d\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e, \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u043e\u0432\u0430\u043d\u043e \u043e\u0442\u043a\u0430\u0442\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u0431\u043e\u043b\u0435\u0435 \u0441\u0442\u0430\u0440\u044b\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u043f\u0440\u043e\u0432\u0435\u0441\u0442\u0438 \u043f\u043e\u043b\u043d\u043e\u0446\u0435\u043d\u043d\u043e\u0435 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442.\n\n\u0414\u0435\u0442\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0441\u0442\u043e\u0438\u0442 \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u044f \u043f\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0434\u043b\u0438\u043b\u0430\u0441\u044c \u0434\u0432\u0430 \u0433\u043e\u0434\u0430 \u0438 \u0432\u043a\u043b\u044e\u0447\u0430\u043b\u0430 \u0432 \u0441\u0435\u0431\u044f \u0441\u043e\u0446\u0438\u0430\u043b\u044c\u043d\u0443\u044e \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u044e, \u0432\u044b\u0442\u0435\u0441\u043d\u0435\u043d\u0438\u0435 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0433\u043e \u043c\u0435\u0439\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0438 \u0444\u0435\u0439\u043a\u043e\u0432\u044b\u0435 \u0430\u043a\u043a\u0430\u0443\u043d\u0442\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0430\u0432\u043b\u0438\u0432\u0430\u043d\u0438\u044f \u043d\u0443\u0436\u043d\u044b\u0445 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u043a\u0430\u043a \u0432 \u0441\u0430\u043c\u043e\u0439 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0435 XZ, \u0442\u0430\u043a \u0438 \u0432 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445, \u043a\u0443\u0434\u0430 \u043e\u043d\u0430 \u0432\u0445\u043e\u0434\u0438\u0442.  \n\n\u041d\u0430\u0434\u0435\u0436\u0434\u044b \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438 \u041f\u041e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0435\u0433\u043e \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u044b open source, \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0443\u0436\u0435\u0441\u0442\u043e\u0447\u0430\u0442 \u00ab\u0444\u0435\u0439\u0441-\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb \u044d\u0442\u0438\u0445 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432, \u0443 \u0440\u0435\u0434\u0430\u043a\u0446\u0438\u0438, \u0447\u0435\u0441\u0442\u043d\u043e \u0433\u043e\u0432\u043e\u0440\u044f, \u043d\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u043d\u0430\u0434\u0435\u044f\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u0418\u0411 \u0432 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f\u0445 \u043f\u043e\u0432\u0441\u0435\u043c\u0435\u0441\u0442\u043d\u043e \u043d\u0430\u043b\u0430\u0434\u0438\u0442 \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0441\u043d\u044b\u0439 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u0438 \u0434\u0435\u0442\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0430\u043d\u043e\u043c\u0430\u043b\u0438\u0439 \u0432 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0435 \u0432\u0441\u0435\u0439 \u0418\u0422-\u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b. \ud83d\ude0f\n\n#\u043d\u043e\u0432\u043e\u0441\u0442\u0438 @\u041f2\u0422", "creation_timestamp": "2024-04-01T08:13:33.000000Z"}, {"uuid": "5e692bd4-a505-42b4-8a50-80c75a0564a8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/kasperskyb2b/1210", "content": "\ud83d\udc40 \u041a\u0430\u0441\u0430\u0435\u0442\u0441\u044f \u043b\u0438 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 \u0432\u0435\u0440\u0441\u0438\u0439 Linux \u0431\u044d\u043a\u0434\u043e\u0440 \u0432 XZ Utils? \n\n\u041a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u0439 \u0418\u0433\u043e\u0440\u044f \u041a\u0443\u0437\u043d\u0435\u0446\u043e\u0432\u0430, \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f Kaspersky GReAT:\n\n\ud83d\udcac \u041f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u043e\u0442\u0435\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e, \u0442\u0440\u0443\u0434\u043d\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e \u043a\u0430\u0436\u0434\u044b\u0439 \u043e\u0434\u043d\u043e\u0437\u043d\u0430\u0447\u043d\u043e. \u041e\u0431\u044f\u0437\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u043f\u0440\u043e\u0432\u0435\u0440\u044c\u0442\u0435, \u043d\u0435 \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u044b \u043b\u0438 \u0443 \u0432\u0430\u0441 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 XZ Utils 5.6.0 \u0438\u043b\u0438 5.6.1.  \u0415\u0441\u043b\u0438 \u0432\u0435\u0440\u0441\u0438\u044f \u0431\u043e\u043b\u0435\u0435 \u0441\u0442\u0430\u0440\u0430\u044f, \u0442\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0432 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438. \u041f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f\u043c \u0443\u044f\u0437\u0432\u0438\u043c\u044b\u0445 \u0432\u0435\u0440\u0441\u0438\u0439 \u043d\u0443\u0436\u043d\u043e \u043e\u0431\u043d\u043e\u0432\u0438\u0442\u044c\u0441\u044f.\n\n\u041f\u043e\u043a\u0430 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u043a\u0435\u0439\u0441\u043e\u0432 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 CVE-2024-3094 \u043c\u044b \u043d\u0435 \u0437\u0430\u0444\u0438\u043a\u0441\u0438\u0440\u043e\u0432\u0430\u043b\u0438. \u041f\u043e\u0432\u0435\u0437\u043b\u043e, \u0447\u0442\u043e \u0430\u0442\u0430\u043a\u0443 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b\u0438. \u0412\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u043e\u043f\u0430\u043b\u0438 \u0442\u043e\u043b\u044c\u043a\u043e \u0432  \u0441\u0443\u043f\u0435\u0440-\u043d\u0435\u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435 \u0438 rolling-\u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0440\u0430\u0437\u0443 \u0437\u0430\u0431\u0438\u0440\u0430\u044e\u0442 \u0441\u0432\u0435\u0436\u0438\u0435 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u0430\u043a\u0435\u0442\u043e\u0432. \u0414\u043e \u0441\u0430\u043c\u044b\u0445 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux \u0442\u0440\u043e\u044f\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 \u0432 \u0446\u0435\u043b\u043e\u043c \u043d\u0435 \u0443\u0441\u043f\u0435\u043b\u0438 \u0434\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f. \n\n\u0415\u0441\u043b\u0438 \u0431\u044b \u0441 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u0435\u043c \u00ab\u0437\u0430\u043a\u043b\u0430\u0434\u043a\u0438\u00bb \u043e\u043f\u043e\u0437\u0434\u0430\u043b\u0438, \u0442\u043e \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u044d\u0442\u0430 \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u043c\u043e\u0433\u043b\u0430 \u0431\u044b \u0441\u0442\u0430\u0442\u044c \u0441\u0430\u043c\u043e\u0439 \u043c\u0430\u0441\u0441\u043e\u0432\u043e\u0439 \u0430\u0442\u0430\u043a\u043e\u0439 \u043d\u0430 \u044d\u043a\u043e\u0441\u0438\u0441\u0442\u0435\u043c\u0443 Linux \u0437\u0430 \u0432\u0441\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e \u0435\u0451 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043e\u0432\u0430\u043d\u0438\u044f. \n\n@\u041f2\u0422", "creation_timestamp": "2024-04-02T17:12:38.000000Z"}, {"uuid": "f8378806-0f56-4256-be3c-6889199bea9f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/cybersecgame/189", "content": "CVE-2024-3094 \u2014 \u044d\u0442\u043e \u0432\u0441\u0451, \u043a\u0430\u043a \u043c\u044b \u0442\u0443\u0442 \u043b\u044e\u0431\u0438\u043c. \n\n\u0412\u043e \u043f\u0435\u0440\u0432\u044b\u0445, \u0435\u0441\u043b\u0438 \u0432\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0435 \u043b\u044e\u0431\u043e\u0439 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0439 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432 linux,, \u0441\u0440\u043e\u0447\u043d\u043e \u0443\u0431\u0435\u0434\u0438\u0442\u0435\u0441\u044c, \u0447\u0442\u043e \u0432\u0430\u0441 \u044d\u0442\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u043d\u0435 \u043a\u0430\u0441\u0430\u0435\u0442\u0441\u044f, \u0442\u043e \u0431\u0438\u0448\u044c xz/liblzma \u0443 \u0432\u0430\u0441 \u0414\u041e \u0432\u0435\u0440\u0441\u0438\u0438 5.6.0. \n\n\u0412\u043e \u0432\u0442\u043e\u0440\u044b\u0445, \u043a\u0430\u043a\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f. \u0424\u043e\u0440\u043c\u0430\u0442 xz, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0438\u0439 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c \u0441\u0436\u0430\u0442\u0438\u044f LZMA2, \u0431\u044b\u043b \u043f\u0440\u0438\u0434\u0443\u043c\u0430\u043d \u0432 2007 \u0433\u043e\u0434\u0443 \u0432\u043e\u0441\u0442\u043e\u0440\u0436\u0435\u043d\u043d\u044b\u043c \u0448\u0438\u0444\u0440\u043e\u043f\u0430\u043d\u043a\u043e\u043c \u043f\u043e \u0438\u043c\u0435\u043d\u0438 \u041b\u0430\u0441\u0441\u0435 \u041a\u043e\u043b\u043b\u0438\u043d. \u0412\u043e\u043e\u0431\u0449\u0435, \u043e\u043d \u0442\u0430\u043c \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0441\u044f \u0434\u0435\u043b\u0430\u0442\u044c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432 Linux \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 Slackware, \u043f\u043e\u043c\u0435\u0449\u0430\u044e\u0449\u0438\u0439\u0441\u044f \u043d\u0430 \u043e\u0434\u0438\u043d \u043a\u043e\u043c\u043f\u0430\u043a\u0442-\u0434\u0438\u0441\u043a, \u043d\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0436\u043d\u043e \u0441\u0443\u0434\u0438\u0442\u044c, \u0434\u043e \u044d\u0442\u043e\u0433\u043e \u0434\u0435\u043b\u043e \u043d\u0435 \u0434\u043e\u0448\u043b\u043e. \u0410 \u0432\u043e\u0442 xz \u043f\u043e\u0448\u0435\u043b \u0432 \u043c\u0430\u0441\u0441\u044b \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u043b\u0441\u044f \u041b\u0430\u0441\u0441\u0435 \u043f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0434\u043e 2022 \u0433\u043e\u0434\u0430. \n\n\u0422\u043e \u043b\u0438 \u043f\u043e \u043f\u0440\u0438\u0447\u0438\u043d\u0435 \u0441\u0432\u043e\u0435\u0439 \u044d\u043c\u043e\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0439 \u043d\u0435\u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u0438, \u0442\u043e \u043b\u0438 \u0435\u0449\u0451 \u043f\u043e \u043a\u0430\u043a\u0438\u043c \u0441\u043e\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0438\u044f\u043c, \u0432 2022 \u0433\u043e\u0434\u0443, \u041b\u0430\u0441\u0441\u0435 \u0431\u044b\u043b \u0432\u0437\u044f\u0442 \u0432 \u043e\u0431\u043e\u0440\u043e\u0442 \u043a\u0430\u043a\u043e\u0439-\u0442\u043e \u0442\u0440\u0451\u0445\u0431\u0443\u043a\u0432\u0435\u043d\u043d\u043e\u0439 (\u0438\u043b\u0438, \u0441\u043a\u043e\u0440\u0435\u0435, \u0442\u0440\u0451\u0445\u0438\u0435\u0433\u0440\u043e\u0433\u043b\u0438\u0444\u043e\u0432\u043e\u0439) \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0435\u0439 \u0438 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 \u043d\u0435\u0445\u0438\u0442\u0440\u044b\u0445 (\u043d\u043e \u0434\u043b\u044f \u0436\u0435\u0440\u0442\u0432\u044b \u0432\u0435\u0441\u044c\u043c\u0430 \u043d\u0435\u043f\u0440\u0438\u044f\u0442\u043d\u044b\u0445) \u043f\u0441\u0438\u0445\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u043a\u0438\u0445 \u0442\u0440\u044e\u043a\u043e\u0432 \u043f\u0440\u0438\u043d\u0443\u0436\u0434\u0451\u043d \u043a \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u043d\u0435\u043a\u0438\u043c \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u043c \u043b\u0438\u0447\u043d\u043e\u0441\u0442\u044f\u043c.\n\n\u041b\u0438\u0447\u043d\u043e\u0441\u0442\u0438 \u044d\u0442\u0438 \u043f\u043e\u0442\u043e\u043c \u043f\u0440\u043e\u0434\u0435\u043b\u0430\u043b\u0438 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u0443\u044e \u0438 \u0441\u043b\u043e\u0436\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443, \u0447\u0442\u043e\u0431\u044b \u0434\u043e\u0431\u0430\u0432\u0438\u0442\u044c \u0432 xz \u044d\u0442\u043e\u0442 \u0441\u0430\u043c\u044b\u0439 \u0431\u044d\u043a\u0434\u043e\u0440 \u0438 \u0445\u043e\u0440\u043e\u0448\u043e \u0435\u0433\u043e \u0441\u043f\u0440\u044f\u0442\u0430\u0442\u044c. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c, \u043e\u043d\u0438 \u0441\u0442\u0430\u0440\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u043d\u0430\u0434 \u0441\u0430\u043c\u0438\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u043c. \u0412\u043e\u0442, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043e\u043d\u0438 \u0431\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f\u0442 \u0448\u0432\u0435\u0434\u0441\u043a\u0438\u0445 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0447\u0438\u043a\u043e\u0432 \u0437\u0430 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 XZ Utils \u043d\u0430 \u0448\u0432\u0435\u0434\u0441\u043a\u0438\u0439.\n\n\u041e\u0442\u0434\u0435\u043b\u044c\u043d\u043e \u0441\u043c\u0435\u0448\u043d\u043e \u0442\u043e, \u0447\u0442\u043e \u043a\u043e\u0434 \u044d\u043a\u0441\u043f\u043b\u043e\u0439\u0442\u0430 \u0431\u044b\u043b \u0432\u043d\u0435\u0434\u0440\u0451\u043d \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u0434\u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u041d\u043e \u041b\u0430\u0441\u0441\u0435 \u043d\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0442\u0435\u0441\u0442\u043e\u0432 \u0438 \u0432\u0441\u0451 \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043b \u043d\u0430 \u0433\u043b\u0430\u0437\u043e\u043a. \u0422\u043e \u0435\u0441\u0442\u044c, \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u043b\u0438 \u0432\u0441\u0435 \u0442\u0435\u0441\u0442\u044b \u0441\u0430\u043c\u0438. \u0421 \u043d\u0443\u043b\u044f.\n\n\u0412\u043e \u0432\u0441\u0451\u043c \u044d\u0442\u043e\u043c \u0435\u0441\u0442\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0435 \u043d\u043e\u0432\u043e\u0441\u0442\u0438 \u0438 \u0435\u0441\u0442\u044c \u043f\u043b\u043e\u0445\u0438\u0435.\n\n\u0418\u0437 \u0445\u043e\u0440\u043e\u0448\u0438\u0445: \u0432 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430\u0445 \u0441\u043f\u0440\u044f\u0442\u0430\u0442\u044c \u0431\u044d\u043a\u0434\u043e\u0440, \u0434\u0430\u0436\u0435 \u0435\u0441\u043b\u0438 \u0442\u044b \u0442\u0430\u043b\u0430\u043d\u0442\u043b\u0438\u0432\u044b\u0439 \u043c\u0430\u0441\u043a\u0438\u0440\u043e\u0432\u0449\u0438\u043a, \u043d\u0435 \u0442\u0430\u043a \u043f\u0440\u043e\u0441\u0442\u043e, \u0412\u043f\u0440\u043e\u0447\u0435\u043c, \u043e\u0442\u043a\u0440\u044b\u0442\u043e\u0441\u0442\u044c \u043a\u043e\u0434\u0430 \u0441\u044b\u0433\u0440\u0430\u043b\u0430 \u0432 \u0440\u0430\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0438 \u043d\u0435 \u0433\u043b\u0430\u0432\u043d\u0443\u044e \u0440\u043e\u043b\u044c. \u041a\u0430\u043a \u043c\u044b \u0443\u0432\u0438\u0434\u0438\u043c \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0430\u043c \u043d\u0438\u0436\u0435, \u0432\u0441\u0451 \u043d\u0430\u0447\u0430\u043b\u043e\u0441\u044c \u0441 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a Microsoft  \u0410\u043d\u0434\u0440\u0435\u0441 \u0424\u0440\u0435\u043d\u0434  \u043e\u0431\u0440\u0430\u0442\u0438\u043b \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u043d\u0430 \u0441\u0442\u0440\u0430\u043d\u043d\u043e\u0435 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435 ssh \u043d\u0430 \u0441\u0432\u043e\u0438\u0445 \u043c\u0430\u0448\u0438\u043d\u0430\u0445 \u0438 \u0442\u043e\u043b\u044c\u043a\u043e \u043f\u043e\u0442\u043e\u043c \u043f\u043e\u043b\u0435\u0437 \u0432 \u043a\u043e\u0434 \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u0442\u044c\u0441\u044f. \u041f\u0440\u0438\u0447\u0451\u043c, \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043e\u043d \u0437\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u043e\u0432 \u0441\u043b\u043e\u043c\u0430\u043b \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0430\u043c \u043f\u043e\u0447\u0442\u0438 \u0434\u0432\u0443\u0445\u043b\u0435\u0442\u043d\u044e\u044e \u0440\u0430\u0431\u043e\u0442\u0443: \u0448\u0438\u0440\u043e\u043a\u043e \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0438\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0438\u043c \u043d\u0435 \u0443\u0434\u0430\u043b\u043e\u0441\u044c.\n\n\u0418\u0437 \u043f\u043b\u043e\u0445\u0438\u0445 \u043d\u043e\u0432\u043e\u0441\u0442\u0435\u0439 \u0432\u0441\u0451 \u043e\u0441\u0442\u0430\u043b\u044c\u043d\u043e\u0435. \u041c\u044b \u0431\u0435\u0437 \u043f\u043e\u043d\u044f\u0442\u0438\u044f, \u0432 \u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0435\u0449\u0451 \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445 \u044d\u0442\u0438 \u0440\u0435\u0431\u044f\u0442\u0430 \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u044e\u0442 \u043c\u044d\u0439\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430\u043c\u0438 \u043f\u043e\u0434 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043e\u0437\u043d\u0430\u0447\u0430\u044e\u0449\u0438\u043c\u0438 \u0438\u043c\u0435\u043d\u0430\u043c\u0438. \u0414\u0430\u043b\u0435\u043a\u043e \u043d\u0435 \u043a\u0430\u0436\u0434\u044b\u043c \u0441\u043e\u0444\u0442\u043e\u043c \u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u0432\u044a\u0435\u0434\u043b\u0438\u0432\u044b\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0438. \n\n\u041d\u0443 \u0438 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f, \u043c\u043e\u0437\u0433 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c \u043d\u0438\u0447\u0443\u0442\u044c \u043d\u0435 \u043c\u0435\u043d\u044c\u0448\u0435, \u0447\u0435\u043c \u0435\u0433\u043e \u043a\u043e\u0434.\n\n\u041b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u0430: \n\nhttps://www.opennet.ru/opennews/art.shtml?num=60880 \u2014 \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0441\u043e\u0431\u044b\u0442\u0438\u0439, \u043f\u0440\u0438\u0432\u0435\u0434\u0448\u0438\u0445 \u043a \u043e\u0431\u0440\u0430\u0437\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u044d\u043a\u0434\u043e\u0440\u0430\nhttps://mastodon.social/@AndresFreundTec/112180406142695845 \u2014 \u0410\u043d\u0434\u0440\u0435\u0441 \u0424\u0440\u0435\u043d\u0434 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442, \u043a\u0430\u043a \u043e\u043d \u043e\u0431\u0440\u0430\u0442\u0438\u043b \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u043d\u0430 \u0441\u0442\u0440\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0441 ssh\nhttps://news.ycombinator.com/item?id=39866275 \u2014 \u0435\u0449\u0451 \u043e\u0434\u043d\u0430 \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u043f\u0440\u043e \u0442\u043e, \u043a\u0430\u043a \u043d\u043e\u0432\u044b\u0435 \u043c\u044d\u0439\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b xz \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u044e\u0442 \u043c\u0430\u043d\u0438\u043f\u0443\u043b\u044f\u0442\u0438\u0432\u043d\u044b\u0435 \u0442\u0435\u0445\u043d\u0438\u043a\u0438 \u0434\u043b\u044f \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0439 \u0437\u0430\u0431\u044d\u043a\u0434\u043e\u0440\u0435\u043d\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438.", "creation_timestamp": "2024-03-30T21:09:07.000000Z"}, {"uuid": "9deba1e8-4e85-445e-8465-84b2fd918fb7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/Kelvinseccommunity/175", "content": "https://github.com/amlweems/xzbot\n\nnotes, honeypot, and exploit demo for the xz backdoor (CVE-2024-3094)\n#github", "creation_timestamp": "2024-04-02T18:49:27.000000Z"}, {"uuid": "4b29bdcd-8f8e-4ee6-aabc-3ba5c9cf3bd0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/gIW_zzZ8Jc3unS9qNWyhXmgnmAQ4QGTMdNVUcAoQdepAmw", "content": "", "creation_timestamp": "2024-03-30T07:10:48.000000Z"}, {"uuid": "caad58b7-4a86-4305-8417-d1adb9c11aad", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/qVsNm-xinAf9z2V3PlM-k8mWaM_eZ4OrWB55rNSRie8mMg", "content": "", "creation_timestamp": "2024-04-02T04:07:30.000000Z"}, {"uuid": "b0d46163-8730-4948-b2cb-906664386f09", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/Ozv7Gd11TeivbOo4UpJTHyd7sUF8pJqORb88zxd_aDcU", "content": "", "creation_timestamp": "2024-04-02T00:26:56.000000Z"}, {"uuid": "56a5597a-dbb7-49fe-bc81-6e53f6e91d74", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/b9EQiFqv9yDf7plTFTEHCXSciDdEEr9T62h59kT5mVY7", "content": "", "creation_timestamp": "2024-03-30T23:32:22.000000Z"}, {"uuid": "f6fcf213-69bd-4fe0-b2c7-879a97d09c69", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/PYWy3JRYrp_CW9rZeuDmR764f-OTdoIsbx1FoofpoHde2w", "content": "", "creation_timestamp": "2024-04-02T04:01:27.000000Z"}, {"uuid": "2abc26f3-ae82-49b1-a06d-de700ec455b0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/6ZyAOCp0sr6Be3kwi7KF89u8hxyMjFVyZm38MhQqhu8ZAA", "content": "", "creation_timestamp": "2024-10-01T23:42:23.000000Z"}, {"uuid": "82077bed-f9f6-4af7-8324-d9fcb63e05d6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/Hacker501/2266", "content": "\u0639\u062b\u0631 \u0628\u0627\u062d\u062b\u0648\u0646 \u0639\u0644\u0649 \u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0628\u0631\u0645\u062c\u064a\u0629 \u062e\u0628\u064a\u062b\u0629 \u062a\u0645 \u0632\u0631\u0639\u0647\u0627 \u0641\u064a \u0641\u064a \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u064a\u0646 5.6.0 \u06485.6.1 \u0645\u0646 \u0623\u062f\u0627\u0629 \u0641\u0643 \u0627\u0644\u0636\u063a\u0637 \u0645\u0641\u062a\u0648\u062d\u0629 \u0627\u0644\u0645\u0635\u062f\u0631 XZ Utils \u0641\u064a \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 , \u0648\u0647\u064a \u0623\u062f\u0627\u0629 \u062a\u0634\u0628\u0647 WinRAR \u0641\u064a \u0623\u0646\u0638\u0645\u0629 \u0648\u064a\u0646\u062f\u0648\u0632 \u060c \u0648\u062a\u0645 \u0627\u0639\u0637\u0627\u0621 \u0627\u0644\u062e\u0644\u0644 \u0627\u0644\u0630\u064a \u064a\u062d\u0645\u0644 \u0627\u0644\u0631\u0645\u0632 CVE-2024-3094 \u062f\u0631\u062c\u0629 \u0639\u0627\u0644\u064a\u0629 \u0645\u0646 \u0627\u0644\u062e\u0637\u0648\u0631\u0629.\n\n\u0641\u064a \u0627\u0644\u0628\u062f\u0627\u064a\u0629 \u0648\u062c\u062f \u0627\u0644\u0639\u062f\u064a\u062f \u0645\u0646 \u0627\u0644\u0628\u0627\u062d\u062b\u064a\u0646 \u0623\u0646 \u0647\u0630\u0627 \u0627\u0644\u0628\u0627\u0628 \u0627\u0644\u062e\u0644\u0641\u064a \u064a\u0633\u0645\u062d \u0644\u0644\u0645\u0647\u0627\u062c\u0645\u064a\u0646 \u0628\u062a\u062c\u0627\u0648\u0632 \u0645\u0635\u0627\u062f\u0642\u0629 sshd (\u0639\u0645\u0644\u064a\u0629 \u062e\u0627\u062f\u0645 OpenSSH)\u060c \u0648\u0627\u0644\u062d\u0635\u0648\u0644 \u0639\u0644\u0649 \u0648\u0635\u0648\u0644 \u0639\u0646 \u0628\u0639\u062f \u063a\u064a\u0631 \u0645\u0635\u0631\u062d \u0628\u0647 \u0625\u0644\u0649 \u0646\u0638\u0627\u0645 \u0627\u0644\u062a\u0634\u063a\u064a\u0644 \u060c \u0627\u0633\u062a\u0646\u0627\u062f\u064b\u0627 \u0625\u0644\u0649 \u0623\u062d\u062f\u062b \u0627\u0644\u0645\u0639\u0644\u0648\u0645\u0627\u062a \u0642\u062f \u062a\u0628\u062f\u0648 \u0647\u0630\u0647 \u0627\u0644\u062b\u063a\u0631\u0629 \u0627\u0644\u0623\u0645\u0646\u064a\u0629 \u0639\u0644\u0649 \u0623\u0646\u0647\u0627 \"\u062a\u062c\u0627\u0648\u0632 \u0627\u0644\u0645\u0635\u0627\u062f\u0642\u0629\" \u060c \u0648\u0644\u0643\u0646 \u0627\u0644\u062d\u0642\u064a\u0642\u0629 \u0647\u064a \u0623\u0646\u0647\u0627 \"\u062a\u0646\u0641\u064a\u0630 \u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0628\u0631\u0645\u062c\u064a\u0629 \u0639\u0646 \u0628\u0639\u062f ( RCE ). \u064a\u0639\u062a\u0631\u0636 \u0627\u0644\u0628\u0627\u0628 \u0627\u0644\u062e\u0644\u0641\u064a \u0648\u0638\u064a\u0641\u0629 RSA_public_decrypt \u060c \u0648\u064a\u062a\u062d\u0642\u0642 \u0645\u0646 \u062a\u0648\u0642\u064a\u0639 \u0627\u0644\u0645\u0636\u064a\u0641 \u0628\u0627\u0633\u062a\u062e\u062f\u0627\u0645 \u0627\u0644\u0645\u0641\u062a\u0627\u062d \u0627\u0644\u062b\u0627\u0628\u062a Ed448\u060c \u0648\u0625\u0630\u0627 \u062a\u0645 \u0627\u0644\u062a\u062d\u0642\u0642 \u0645\u0646\u0647 \u0628\u0646\u062c\u0627\u062d \u060c \u0641\u0625\u0646\u0647 \u064a\u0646\u0641\u0630 \u0627\u0644\u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0627\u0644\u0628\u0631\u0645\u062c\u064a\u0629 \u0627\u0644\u0636\u0627\u0631\u0629 \u0627\u0644\u062a\u064a \u0645\u0631\u0631\u0647\u0627 \u0627\u0644\u0645\u0636\u064a\u0641 \u0639\u0628\u0631 \u0648\u0638\u064a\u0641\u0629 system \u060c \u062f\u0648\u0646 \u062a\u0631\u0643 \u0623\u064a \u0623\u062b\u0631 \u0641\u064a \u0633\u062c\u0644\u0627\u062a sshd.\n\n\u0627\u0644\u0634\u064a\u0621 \u0627\u0644\u0645\u0628\u0634\u0631 \u0623\u0646\u0647 \u0644\u064a\u0633\u062a \u0643\u0644 \u0623\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633 \u0645\u0635\u0627\u0628\u0629 \u0628\u0647\u0630\u0647 \u0627\u0644\u0628\u0631\u0645\u062c\u064a\u0629 \u0627\u0644\u062e\u0628\u064a\u062b\u0629 \u060c \u0648\u0630\u0644\u0643 \u0643\u0648\u0646 \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u0627\u062a \u0627\u0644\u0636\u0639\u064a\u0641\u0629 \u0645\u0646 \u0627\u0644\u0623\u062f\u0648\u0627\u062a \u0627\u0644\u0645\u0633\u0627\u0639\u062f\u0629 \u062a\u0645 \u0632\u0631\u0639\u0647\u0627 \u0628\u064a\u0646  26 \u064829 \u0645\u0627\u0631\u0633 \u0628\u0627\u0644\u0646\u0633\u0628\u0629 \u0644\u062a\u0648\u0632\u064a\u0639\u0629 Kali Linux \u060c \u0623\u064a \u0623\u0646 \u0627\u0644\u0623\u0646\u0638\u0645\u0629 \u0627\u0644\u062a\u064a \u0642\u0627\u0645\u062a \u0628\u0627\u0644\u062a\u062d\u062f\u064a\u062b \u0641\u064a \u0647\u0630\u0647 \u0627\u0644\u0641\u062a\u0631\u0629 \u0647\u064a \u0641\u0642\u0637 \u0627\u0644\u0645\u0635\u0627\u0628\u0629.\n@Hacker501", "creation_timestamp": "2024-04-02T04:27:55.000000Z"}, {"uuid": "2132632b-cb27-4d94-9e9c-688ada6ce751", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/bizone_channel/1166", "content": "\ud83e\udd51 \u041e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0443\u0433\u0440\u043e\u0437 \u0441 BI.ZONE TDR \u043d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 \u0431\u044d\u043a\u0434\u043e\u0440\u0430 XZ Utils\n\n\u041d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u043d\u0435\u0434\u0435\u043b\u0435 \u0441\u0442\u0430\u043b\u043e \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u043e, \u0447\u0442\u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438 \u0432\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u0431\u044d\u043a\u0434\u043e\u0440 \u0432 XZ Utils \u2014 \u043d\u0430\u0431\u043e\u0440 \u0443\u0442\u0438\u043b\u0438\u0442 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c.\n\n\u041d\u0430\u0448\u0443\u043c\u0435\u0432\u0448\u0430\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c CVE-2024-3094 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0430 \u043e\u0446\u0435\u043d\u043a\u0443 10 \u043f\u043e \u0448\u043a\u0430\u043b\u0435 CVSS \u0438 \u0443\u0441\u043f\u0435\u043b\u0430 \u043e\u0445\u0432\u0430\u0442\u0438\u0442\u044c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u044b Linux: Fedora, Debian, OpenSUSE \u0438 Kali Linux.\n\n\u0427\u0442\u043e\u0431\u044b \u0431\u044b\u0441\u0442\u0440\u043e \u043e\u0446\u0435\u043d\u0438\u0442\u044c \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 BI.ZONE TDR \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044f\u043c, \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0444\u0443\u043d\u043a\u0446\u0438\u044e threat prediction.\n\n\u0410 \u0447\u0442\u043e \u043e\u043d\u0430 \u0432 \u0441\u0435\u0431\u044f \u0432\u043a\u043b\u044e\u0447\u0430\u0435\u0442 \u0438 \u043a\u0430\u043a \u0434\u0435\u0439\u0441\u0442\u0432\u0443\u044e\u0442 \u043d\u0430\u0448\u0438 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b, \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u0432 \u043d\u043e\u0432\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435.\n\n\u0427\u0438\u0442\u0430\u0442\u044c", "creation_timestamp": "2024-04-04T13:21:59.000000Z"}, {"uuid": "6c6b786d-b480-4d30-a272-82ad0dd639db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/iGW_5A0oZkZcyB-GkqlrOVgdjCeQTucngSvvwjWlsOYRomA", "content": "", "creation_timestamp": "2024-03-30T17:23:45.000000Z"}, {"uuid": "93866325-370e-4c3a-a4f5-15d5b43266de", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/C7u9QpeQ92IC0QS9OsD3DCLeqLmlRefwtQGi1Kn6TAhF9g", "content": "", "creation_timestamp": "2024-04-02T19:26:11.000000Z"}, {"uuid": "a97dd0fe-1c76-4a4c-a156-2aa12676b8a7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/P55dCue9-7LMN-Lc0-XDOTkh4IIUjqBqoh0vjK4epZiAs1I", "content": "", "creation_timestamp": "2024-04-02T16:08:07.000000Z"}, {"uuid": "ba7637cc-d923-4a88-a398-f58188d57b54", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/Kelvinseccommunity/172", "content": "CVE-2024-3094 - An ssh honeypot with the XZ backdoor. \n\nhttps://github.com/lockness-Ko/xz-vulnerable-honeypot", "creation_timestamp": "2024-04-02T18:47:06.000000Z"}, {"uuid": "8c0ad209-af1f-4c90-8691-72456f1842a7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/E1NvmT5cv7fjMNsN9m7amKF9Pnc52WoiTKu2uvjaIrXlN0Y", "content": "", "creation_timestamp": "2024-04-02T18:45:34.000000Z"}, {"uuid": "7a800989-d320-4663-8183-11290039a6b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cyber_1_world/36061", "content": "\u0627\u0644\u0646\u0627\u0633 \u0627\u0644\u0644\u064a \u0628\u064a\u0633\u062a\u062e\u062f\u0645\u0648\u0627 \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 \u0632\u064a\u064a \u0643\u062f\u0647\n\u0639\u0646\u062f\u0649 \u0644\u064a\u0643\u0645 \u0627\u062e\u0628\u0627\u0631 \u0627\u0644\u0649 \u062d\u062f \u0645\u0627 \u0645\u0642\u0644\u0642  \u0634\u0648\u064a\u0647\n\u0627\u0644\u0646\u0647\u0627\u0631\u062f\u0647 \u062a\u0645 \u0627\u0643\u062a\u0634\u0627\u0641 Backdoor \u0641\u064a \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 \u0645\u0646 \u0645\u0647\u0646\u062f\u0633 \u0633\u0648\u0641\u062a \u0648\u064a\u0631 \u0634\u063a\u0627\u0644 \u0641\u064a \u0645\u064a\u0643\u0631\u0648\u0633\u0648\u0641\u062a \u0648\u0644\u0627\u062d\u0638 \u0644\u0627\u062c \u0627\u0648 \u062a\u0623\u062e\u064a\u0631 500 \u0645\u0644\u0644\u064a \u0641\u064a \u0627\u0644\u062b\u0627\u0646\u064a\u0647 \u0641\u064a \u0627\u0644\u0628\u0631\u0648\u0633\u064a\u0633\u0648\u0631 \u0648 \u062d\u0633 \u0627\u0646 \u062f\u0647 \u0634\u0626 \u0645\u0631\u064a\u0628\n\n \n\u0648\u062a\u0645 \u0627\u0643\u062a\u0634\u0627\u0641 \u0627\u0644\u0640 Backdoor \u0639\u0646 \u0637\u0631\u064a\u0642 \u0645\u0643\u062a\u0628\u0629 LIBLZMA\n\u0627\u0644\u0636\u0631\u0631 \u0648\u0635\u0644 \u0644 RCE \u0639\u0646 \u0637\u0631\u064a\u0642 SSHD\n\nNumber: CVE-2024-3094\n\n\u0645\u0633\u0624\u0648\u0644\u064a\u0646 \u0627\u0644\u0627\u0646\u0638\u0645\u0629\n\nsudo apt-get update && apt-get upgrade\n\u062a\u0639\u062f\u064a\u0644 \u064a\u0627\u0634\u0628\u0627\u0628 \u0627\u0644\u0628\u0627\u0643 \u062f\u0648\u0631 \u062f\u064a \u0639\u0646\u062f \u0627\u0644\u0646\u0627\u0633 \u0627\u0644\u0644\u064a \u062d\u062f\u062b\u062a kali \u0645\u0646 \u064a\u0648\u0645 26 \u0644\u064a\u0648\u0645 29 \n\u0641\u0644\u0627\u0632\u0645 \u062a\u0639\u0645\u0644 \u062a\u062d\u062f\u064a\u062b \u062a\u0627\u0646\u064a \u062f\u0644\u0648\u0642\u062a\u064a \u0639\u0644\u0634\u0627\u0646 \u062b\u063a\u0631\u0629 \u0627\u0644\u0640 Backdoor \n\u0627\u0644\u0644\u064a \u0641\u064a \u0627\u0644\u062a\u062d\u062f\u064a\u062b \u0627\u0644\u0644\u064a \u0639\u0646\u062f\u0643 \u062f\u0644\u0648\u0642\u062a\u064a \u0645\u0645\u0643\u0646 \u062d\u062f \u064a\u0627\u062e\u062f \u0627\u0644\u0645\u0627\u0634\u064a\u0646 \u0643\u0644\u0647\u0627 \u0648\u0645\u0645\u0643\u0646 \u064a\u0631\u0641\u0639\u0647\u0627 \u0627\u0648\u0646\u0644\u0627\u064a\u0646 \u0641\u0645\u062a\u062d\u062f\u062b\u0634 \u0627\u0644\u0643\u0627\u0644\u064a \u0628 source's \n \u0645\u0646 \u0645\u0648\u0627\u0642\u0639 \u063a\u064a\u0631 \u0645\u0648\u062b\u0648\u0642\u0629 \u062e\u0635\u0648\u0635\u0627 \u0625\u0646\u0643 \u0645\u0645\u0643\u0646 \u0645\u062a\u0643\u0648\u0646\u0634 \u0648\u0627\u062e\u062f \u0628\u0627\u0644\u0643 \u0625\u0646 \u0627\u0644\u0633\u0648\u0631\u0633\u0633 \u062f\u064a \u0628\u064a\u0628\u0642\u064a \u0641\u064a\u0647\u0627 Backdoor \u0623\u0648 \u0645\u0634 \u0635\u062d\u064a\u062d", "creation_timestamp": "2024-04-22T17:38:05.000000Z"}, {"uuid": "69815015-b9cb-4bf1-bd7c-2c771cfdd251", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/4RSq0I0C4iQZhAJzQEKE6l0zYN3-fryDoOxblxQOsqyPqmKb", "content": "", "creation_timestamp": "2024-03-30T17:57:19.000000Z"}, {"uuid": "82cf6a81-e154-4c89-b829-7e927b3b2a41", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/mhjLvTO7kgOjFNFOYx91UXvRzSNYwc-Sopm7mB8pVgiHRAla", "content": "", "creation_timestamp": "2024-04-04T19:19:52.000000Z"}, {"uuid": "cfacbd09-2af9-4a54-9a62-c6546bf0dff2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/Cyber_wise/364", "content": "An ssh honeypot with the XZ backdoor. CVE-2024-3094\n\nhttps://github.com/lockness-Ko/xz-vulnerable-honeypot?s=35", "creation_timestamp": "2024-04-01T14:44:04.000000Z"}, {"uuid": "d70bc324-fed1-427c-be36-d40aacab8d35", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/vN3SCyQQqcB7zXYDdqLfDaroV83ugt5aM31P9hPLnbGbAqtd", "content": "", "creation_timestamp": "2024-08-31T12:47:08.000000Z"}, {"uuid": "a02b2a16-716c-45ea-a3d7-b3d7db5cf896", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/NIGQjUbXnx9gufkLY_qk9WXE5ehPCqVRH7HzPfZlAf2fCe_h", "content": "", "creation_timestamp": "2024-04-04T19:16:57.000000Z"}, {"uuid": "6bb78b00-3c9a-4513-b483-f4ba887aae18", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/KLnJ-HOohSUd5k_lgqV2q_tNd3YQ0IPMWZ5dFZ2vn1e1ccaF", "content": "", "creation_timestamp": "2024-03-30T18:07:13.000000Z"}, {"uuid": "8ac2569e-6a8b-498f-9172-80e7bf5bf821", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/K-HVLIcMO2H5c--vnWIEZ_jeCRlMkpBllmxGJiB0X9USPN9c", "content": "", "creation_timestamp": "2024-03-30T17:20:13.000000Z"}, {"uuid": "c00b44f1-dcc4-4b3d-812a-18cd03b61b6d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/4q8lhx--T6mpEMtrrfNddAkRPXbuXwIYwsc71FZUvHV3ZiV8", "content": "", "creation_timestamp": "2024-03-30T17:20:36.000000Z"}, {"uuid": "5389acd3-56d1-4301-82a1-12d66cf2d5d5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/alBsn7Fip3o2Wogickoa47AGFlS3m4dIRhJmuF6gnnFnBpHc", "content": "", "creation_timestamp": "2024-03-30T16:48:05.000000Z"}, {"uuid": "0c46dade-7da7-459a-a8c8-63eb8031c742", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/tengkorakcybercrewz/4560", "content": "The Hacker News\nUrgent: Secret Backdoor Found in XZ Utils Library, Impacts Major Linux Distros\n\nRedHat on Friday released an \"urgent security alert\" warning that two versions of a popular data compression library called XZ Utils (previously LZMA Utils) have been backdoored with malicious code designed to allow unauthorized remote access.\nThe software supply chain compromise, tracked as CVE-2024-3094, has a CVSS score of 10.0, indicating maximum severity. It impacts XZ Utils", "creation_timestamp": "2024-03-30T07:10:50.000000Z"}, {"uuid": "adec4cb9-3b6f-4e81-8e79-622ae27c108c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/tengkorakcybercrewz/4787", "content": "The Hacker News\nMalicious Code in XZ Utils for Linux Systems Enables Remote Code Execution\n\nThe malicious code inserted into the open-source library XZ Utils, a widely used package present in major Linux distributions, is also capable of facilitating remote code execution, a new analysis has revealed.\nThe audacious supply chain compromise, tracked as CVE-2024-3094 (CVSS score: 10.0), came to light last week when Microsoft engineer and PostgreSQL developer Andres Freund", "creation_timestamp": "2024-04-02T19:25:38.000000Z"}, {"uuid": "01249049-d387-4d83-bc98-83dd3bbd60fa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/YpTEOS-0HThMULUeqVfh3nuPunEO8dLvoLbwvs118EyYdg", "content": "", "creation_timestamp": "2024-04-02T01:51:55.000000Z"}, {"uuid": "5cb41805-f9b7-483b-975f-407e11d05013", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/VasileiadisAnastasis/627", "content": "\ud83d\udd78\ufe0fXZ-utils backdoor (CVE-2024-3094)\n\n\ud83d\udd16#infosec #cybersecurity #hacking #pentesting #security \n\n\ud83d\udc64beacons.ai/cyberkid1987 \n\ud83d\udc64t.me/VasileiadisAnastasis\n\ud83d\udc65t.me/infosec101", "creation_timestamp": "2024-04-02T00:58:43.000000Z"}, {"uuid": "2ac108ed-e967-492e-9a88-88f879e5cc5b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/HackerNewsAR/870", "content": "\u0639\u062b\u0631 \u0628\u0627\u062d\u062b\u0648\u0646 \u0639\u0644\u0649 \u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0628\u0631\u0645\u062c\u064a\u0629 \u062e\u0628\u064a\u062b\u0629 \u062a\u0645 \u0632\u0631\u0639\u0647\u0627 \u0641\u064a \u0641\u064a \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u064a\u0646 5.6.0 \u06485.6.1 \u0645\u0646 \u0623\u062f\u0627\u0629 \u0641\u0643 \u0627\u0644\u0636\u063a\u0637 \u0645\u0641\u062a\u0648\u062d\u0629 \u0627\u0644\u0645\u0635\u062f\u0631 XZ Utils \u0641\u064a \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 , \u0648\u0647\u064a \u0623\u062f\u0627\u0629 \u062a\u0634\u0628\u0647 WinRAR \u0641\u064a \u0623\u0646\u0638\u0645\u0629 \u0648\u064a\u0646\u062f\u0648\u0632 \u060c \u0648\u062a\u0645 \u0627\u0639\u0637\u0627\u0621 \u0627\u0644\u062e\u0644\u0644 \u0627\u0644\u0630\u064a \u064a\u062d\u0645\u0644 \u0627\u0644\u0631\u0645\u0632 CVE-2024-3094 \u062f\u0631\u062c\u0629 \u0639\u0627\u0644\u064a\u0629 \u0645\u0646 \u0627\u0644\u062e\u0637\u0648\u0631\u0629.\n\n\u0641\u064a \u0627\u0644\u0628\u062f\u0627\u064a\u0629 \u0648\u062c\u062f \u0627\u0644\u0639\u062f\u064a\u062f \u0645\u0646 \u0627\u0644\u0628\u0627\u062d\u062b\u064a\u0646 \u0623\u0646 \u0647\u0630\u0627 \u0627\u0644\u0628\u0627\u0628 \u0627\u0644\u062e\u0644\u0641\u064a \u064a\u0633\u0645\u062d \u0644\u0644\u0645\u0647\u0627\u062c\u0645\u064a\u0646 \u0628\u062a\u062c\u0627\u0648\u0632 \u0645\u0635\u0627\u062f\u0642\u0629 sshd (\u0639\u0645\u0644\u064a\u0629 \u062e\u0627\u062f\u0645 OpenSSH)\u060c \u0648\u0627\u0644\u062d\u0635\u0648\u0644 \u0639\u0644\u0649 \u0648\u0635\u0648\u0644 \u0639\u0646 \u0628\u0639\u062f \u063a\u064a\u0631 \u0645\u0635\u0631\u062d \u0628\u0647 \u0625\u0644\u0649 \u0646\u0638\u0627\u0645 \u0627\u0644\u062a\u0634\u063a\u064a\u0644 \u060c \u0627\u0633\u062a\u0646\u0627\u062f\u064b\u0627 \u0625\u0644\u0649 \u0623\u062d\u062f\u062b \u0627\u0644\u0645\u0639\u0644\u0648\u0645\u0627\u062a \u0642\u062f \u062a\u0628\u062f\u0648 \u0647\u0630\u0647 \u0627\u0644\u062b\u063a\u0631\u0629 \u0627\u0644\u0623\u0645\u0646\u064a\u0629 \u0639\u0644\u0649 \u0623\u0646\u0647\u0627 \"\u062a\u062c\u0627\u0648\u0632 \u0627\u0644\u0645\u0635\u0627\u062f\u0642\u0629\" \u060c \u0648\u0644\u0643\u0646 \u0627\u0644\u062d\u0642\u064a\u0642\u0629 \u0647\u064a \u0623\u0646\u0647\u0627 \"\u062a\u0646\u0641\u064a\u0630 \u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0628\u0631\u0645\u062c\u064a\u0629 \u0639\u0646 \u0628\u0639\u062f ( RCE ). \u064a\u0639\u062a\u0631\u0636 \u0627\u0644\u0628\u0627\u0628 \u0627\u0644\u062e\u0644\u0641\u064a \u0648\u0638\u064a\u0641\u0629 RSA_public_decrypt \u060c \u0648\u064a\u062a\u062d\u0642\u0642 \u0645\u0646 \u062a\u0648\u0642\u064a\u0639 \u0627\u0644\u0645\u0636\u064a\u0641 \u0628\u0627\u0633\u062a\u062e\u062f\u0627\u0645 \u0627\u0644\u0645\u0641\u062a\u0627\u062d \u0627\u0644\u062b\u0627\u0628\u062a Ed448\u060c \u0648\u0625\u0630\u0627 \u062a\u0645 \u0627\u0644\u062a\u062d\u0642\u0642 \u0645\u0646\u0647 \u0628\u0646\u062c\u0627\u062d \u060c \u0641\u0625\u0646\u0647 \u064a\u0646\u0641\u0630 \u0627\u0644\u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0627\u0644\u0628\u0631\u0645\u062c\u064a\u0629 \u0627\u0644\u0636\u0627\u0631\u0629 \u0627\u0644\u062a\u064a \u0645\u0631\u0631\u0647\u0627 \u0627\u0644\u0645\u0636\u064a\u0641 \u0639\u0628\u0631 \u0648\u0638\u064a\u0641\u0629 system \u060c \u062f\u0648\u0646 \u062a\u0631\u0643 \u0623\u064a \u0623\u062b\u0631 \u0641\u064a \u0633\u062c\u0644\u0627\u062a sshd.\n\n\u0627\u0644\u0634\u064a\u0621 \u0627\u0644\u0645\u0628\u0634\u0631 \u0623\u0646\u0647 \u0644\u064a\u0633\u062a \u0643\u0644 \u0623\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633 \u0645\u0635\u0627\u0628\u0629 \u0628\u0647\u0630\u0647 \u0627\u0644\u0628\u0631\u0645\u062c\u064a\u0629 \u0627\u0644\u062e\u0628\u064a\u062b\u0629 \u060c \u0648\u0630\u0644\u0643 \u0643\u0648\u0646 \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u0627\u062a \u0627\u0644\u0636\u0639\u064a\u0641\u0629 \u0645\u0646 \u0627\u0644\u0623\u062f\u0648\u0627\u062a \u0627\u0644\u0645\u0633\u0627\u0639\u062f\u0629 \u062a\u0645 \u0632\u0631\u0639\u0647\u0627 \u0628\u064a\u0646  26 \u064829 \u0645\u0627\u0631\u0633 \u0628\u0627\u0644\u0646\u0633\u0628\u0629 \u0644\u062a\u0648\u0632\u064a\u0639\u0629 Kali Linux \u060c \u0623\u064a \u0623\u0646 \u0627\u0644\u0623\u0646\u0638\u0645\u0629 \u0627\u0644\u062a\u064a \u0642\u0627\u0645\u062a \u0628\u0627\u0644\u062a\u062d\u062f\u064a\u062b \u0641\u064a \u0647\u0630\u0647 \u0627\u0644\u0641\u062a\u0631\u0629 \u0647\u064a \u0641\u0642\u0637 \u0627\u0644\u0645\u0635\u0627\u0628\u0629.", "creation_timestamp": "2024-04-01T23:56:59.000000Z"}, {"uuid": "0c8f6753-09fe-4258-a881-b787d95a92d2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/arvinclub1/1090", "content": "CVE-2024-3094 - An ssh honeypot with the XZ backdoor. \n\nhttps://github.com/lockness-Ko/xz-vulnerable-honeypot", "creation_timestamp": "2024-03-31T14:23:04.000000Z"}, {"uuid": "887773f5-0590-4138-96d5-5fcc3a65720c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/xPeWsBrOeBmQCuZHcmfCEoQEsGrrNOaOLAjQIkCPxYMOXg", "content": "", "creation_timestamp": "2024-04-02T18:39:33.000000Z"}, {"uuid": "ad1a8ea9-54a6-4c02-919d-a387c1e73864", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/Wy-eaFeIaqxi02fW8ZcWzMAs4dZ34KBUehnh8cfsm-jhCg", "content": "", "creation_timestamp": "2024-03-30T07:21:31.000000Z"}, {"uuid": "07a29b18-a8b6-4974-992e-ce1db6cfaa67", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/LockBitRaasRansomware/14236", "content": "CVE-2024-3094 - An ssh honeypot with the XZ backdoor. \n\nhttps://github.com/lockness-Ko/xz-vulnerable-honeypot", "creation_timestamp": "2024-04-02T18:45:36.000000Z"}, {"uuid": "cb8ba628-0a7b-4031-9c12-f0fdf81a0ba2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/ZZKyQwqZpC-1xrjHYYMJNwrg1BkAi1k7ReZnJM3tGh-XFRA", "content": "", "creation_timestamp": "2024-10-01T16:51:31.000000Z"}, {"uuid": "7ac74c59-dd8d-4671-8541-05d90a163c03", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/tengkorakcybercrewz/915", "content": "The Hacker News\nMalicious Code in XZ Utils for Linux Systems Enables Remote Code Execution\n\nThe malicious code inserted into the open-source library XZ Utils, a widely used package present in major Linux distributions, is also capable of facilitating remote code execution, a new analysis has revealed.\nThe audacious supply chain compromise, tracked as CVE-2024-3094 (CVSS score: 10.0), came to light last week when Microsoft engineer and PostgreSQL developer Andres Freund", "creation_timestamp": "2024-04-02T19:25:38.000000Z"}, {"uuid": "033674c6-e624-423e-8b3c-6777fb69adf8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/tengkorakcybercrewz/872", "content": "The Hacker News\nUrgent: Secret Backdoor Found in XZ Utils Library, Impacts Major Linux Distros\n\nRedHat on Friday released an \"urgent security alert\" warning that two versions of a popular data compression library called XZ Utils (previously LZMA Utils) have been backdoored with malicious code designed to allow unauthorized remote access.\nThe software supply chain compromise, tracked as CVE-2024-3094, has a CVSS score of 10.0, indicating maximum severity. It impacts XZ Utils", "creation_timestamp": "2024-03-30T07:10:50.000000Z"}, {"uuid": "2877dca8-f464-4440-bdeb-fb562f13822c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/KMPteam/840", "content": "\u0639\u062b\u0631 \u0628\u0627\u062d\u062b\u0648\u0646 \u0639\u0644\u0649 \u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0628\u0631\u0645\u062c\u064a\u0629 \u062e\u0628\u064a\u062b\u0629 \u062a\u0645 \u0632\u0631\u0639\u0647\u0627 \u0641\u064a \u0641\u064a \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u064a\u0646 5.6.0 \u06485.6.1 \u0645\u0646 \u0623\u062f\u0627\u0629 \u0641\u0643 \u0627\u0644\u0636\u063a\u0637 \u0645\u0641\u062a\u0648\u062d\u0629 \u0627\u0644\u0645\u0635\u062f\u0631 XZ Utils \u0641\u064a \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 , \u0648\u0647\u064a \u0623\u062f\u0627\u0629 \u062a\u0634\u0628\u0647 WinRAR \u0641\u064a \u0623\u0646\u0638\u0645\u0629 \u0648\u064a\u0646\u062f\u0648\u0632 \u060c \u0648\u062a\u0645 \u0627\u0639\u0637\u0627\u0621 \u0627\u0644\u062e\u0644\u0644 \u0627\u0644\u0630\u064a \u064a\u062d\u0645\u0644 \u0627\u0644\u0631\u0645\u0632 CVE-2024-3094 \u062f\u0631\u062c\u0629 \u0639\u0627\u0644\u064a\u0629 \u0645\u0646 \u0627\u0644\u062e\u0637\u0648\u0631\u0629.\n\n\u0641\u064a \u0627\u0644\u0628\u062f\u0627\u064a\u0629 \u0648\u062c\u062f \u0627\u0644\u0639\u062f\u064a\u062f \u0645\u0646 \u0627\u0644\u0628\u0627\u062d\u062b\u064a\u0646 \u0623\u0646 \u0647\u0630\u0627 \u0627\u0644\u0628\u0627\u0628 \u0627\u0644\u062e\u0644\u0641\u064a \u064a\u0633\u0645\u062d \u0644\u0644\u0645\u0647\u0627\u062c\u0645\u064a\u0646 \u0628\u062a\u062c\u0627\u0648\u0632 \u0645\u0635\u0627\u062f\u0642\u0629 sshd (\u0639\u0645\u0644\u064a\u0629 \u062e\u0627\u062f\u0645 OpenSSH)\u060c \u0648\u0627\u0644\u062d\u0635\u0648\u0644 \u0639\u0644\u0649 \u0648\u0635\u0648\u0644 \u0639\u0646 \u0628\u0639\u062f \u063a\u064a\u0631 \u0645\u0635\u0631\u062d \u0628\u0647 \u0625\u0644\u0649 \u0646\u0638\u0627\u0645 \u0627\u0644\u062a\u0634\u063a\u064a\u0644 \u060c \u0627\u0633\u062a\u0646\u0627\u062f\u064b\u0627 \u0625\u0644\u0649 \u0623\u062d\u062f\u062b \u0627\u0644\u0645\u0639\u0644\u0648\u0645\u0627\u062a \u0642\u062f \u062a\u0628\u062f\u0648 \u0647\u0630\u0647 \u0627\u0644\u062b\u063a\u0631\u0629 \u0627\u0644\u0623\u0645\u0646\u064a\u0629 \u0639\u0644\u0649 \u0623\u0646\u0647\u0627 \"\u062a\u062c\u0627\u0648\u0632 \u0627\u0644\u0645\u0635\u0627\u062f\u0642\u0629\" \u060c \u0648\u0644\u0643\u0646 \u0627\u0644\u062d\u0642\u064a\u0642\u0629 \u0647\u064a \u0623\u0646\u0647\u0627 \"\u062a\u0646\u0641\u064a\u0630 \u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0628\u0631\u0645\u062c\u064a\u0629 \u0639\u0646 \u0628\u0639\u062f ( RCE ). \u064a\u0639\u062a\u0631\u0636 \u0627\u0644\u0628\u0627\u0628 \u0627\u0644\u062e\u0644\u0641\u064a \u0648\u0638\u064a\u0641\u0629 RSA_public_decrypt \u060c \u0648\u064a\u062a\u062d\u0642\u0642 \u0645\u0646 \u062a\u0648\u0642\u064a\u0639 \u0627\u0644\u0645\u0636\u064a\u0641 \u0628\u0627\u0633\u062a\u062e\u062f\u0627\u0645 \u0627\u0644\u0645\u0641\u062a\u0627\u062d \u0627\u0644\u062b\u0627\u0628\u062a Ed448\u060c \u0648\u0625\u0630\u0627 \u062a\u0645 \u0627\u0644\u062a\u062d\u0642\u0642 \u0645\u0646\u0647 \u0628\u0646\u062c\u0627\u062d \u060c \u0641\u0625\u0646\u0647 \u064a\u0646\u0641\u0630 \u0627\u0644\u062a\u0639\u0644\u064a\u0645\u0627\u062a \u0627\u0644\u0628\u0631\u0645\u062c\u064a\u0629 \u0627\u0644\u0636\u0627\u0631\u0629 \u0627\u0644\u062a\u064a \u0645\u0631\u0631\u0647\u0627 \u0627\u0644\u0645\u0636\u064a\u0641 \u0639\u0628\u0631 \u0648\u0638\u064a\u0641\u0629 system \u060c \u062f\u0648\u0646 \u062a\u0631\u0643 \u0623\u064a \u0623\u062b\u0631 \u0641\u064a \u0633\u062c\u0644\u0627\u062a sshd.\n\n\u0627\u0644\u0634\u064a\u0621 \u0627\u0644\u0645\u0628\u0634\u0631 \u0623\u0646\u0647 \u0644\u064a\u0633\u062a \u0643\u0644 \u0623\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633 \u0645\u0635\u0627\u0628\u0629 \u0628\u0647\u0630\u0647 \u0627\u0644\u0628\u0631\u0645\u062c\u064a\u0629 \u0627\u0644\u062e\u0628\u064a\u062b\u0629 \u060c \u0648\u0630\u0644\u0643 \u0643\u0648\u0646 \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u0627\u062a \u0627\u0644\u0636\u0639\u064a\u0641\u0629 \u0645\u0646 \u0627\u0644\u0623\u062f\u0648\u0627\u062a \u0627\u0644\u0645\u0633\u0627\u0639\u062f\u0629 \u062a\u0645 \u0632\u0631\u0639\u0647\u0627 \u0628\u064a\u0646  26 \u064829 \u0645\u0627\u0631\u0633 \u0628\u0627\u0644\u0646\u0633\u0628\u0629 \u0644\u062a\u0648\u0632\u064a\u0639\u0629 Kali Linux \u060c \u0623\u064a \u0623\u0646 \u0627\u0644\u0623\u0646\u0638\u0645\u0629 \u0627\u0644\u062a\u064a \u0642\u0627\u0645\u062a \u0628\u0627\u0644\u062a\u062d\u062f\u064a\u062b \u0641\u064a \u0647\u0630\u0647 \u0627\u0644\u0641\u062a\u0631\u0629 \u0647\u064a \u0641\u0642\u0637 \u0627\u0644\u0645\u0635\u0627\u0628\u0629.", "creation_timestamp": "2024-04-02T02:13:23.000000Z"}, {"uuid": "f71addbe-051f-4eb9-ac35-b0fb2f78e45e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/KomunitiSiber/1731", "content": "XZ Utils CVE-2024-3094: A Tale of Broken Trust, Curious Persistence, and a Call to Action\nhttps://www.hackerone.com/vulnerability-management/cve-2024-3094\n\nLearn about a backdoor vulnerability, its impacts, and the importance of securing open source.", "creation_timestamp": "2024-04-03T19:59:09.000000Z"}, {"uuid": "0ce9d284-d2dd-42e5-a894-97c6fe100f62", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/KomunitiSiber/1724", "content": "Malicious Code in XZ Utils for Linux Systems Enables Remote Code Execution\nhttps://thehackernews.com/2024/04/malicious-code-in-xz-utils-for-linux.html\n\nThe malicious code inserted into the open-source library XZ Utils, a widely used package present in major Linux distributions, is also capable of facilitating remote code execution, a new analysis has revealed.\nThe audacious supply chain compromise, tracked as\u00a0CVE-2024-3094\u00a0(CVSS score: 10.0), came to light last week when Microsoft engineer and PostgreSQL developer Andres Freund", "creation_timestamp": "2024-04-02T16:16:50.000000Z"}, {"uuid": "15c5e4d2-3d7b-419f-97b1-39ecad5044f7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/KomunitiSiber/1715", "content": "Urgent: Secret Backdoor Found in XZ Utils Library, Impacts Major Linux Distros\nhttps://thehackernews.com/2024/03/urgent-secret-backdoor-found-in-xz.html\n\nRedHat on Friday released an \"urgent security alert\" warning that two versions of a popular data compression library called\u00a0XZ Utils\u00a0(previously LZMA Utils) have been backdoored with malicious code designed to allow unauthorized remote access.\nThe software supply chain compromise, tracked as\u00a0CVE-2024-3094, has a CVSS score of 10.0, indicating maximum severity. It impacts XZ Utils", "creation_timestamp": "2024-03-30T07:07:02.000000Z"}, {"uuid": "03842494-1258-4e78-a7a8-902a2981d6b6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "Telegram/gtxx4RE8GHtJT2JlTQ_6-BG2tvbPnnnnExDfcMYJsOVIelI", "content": "", "creation_timestamp": "2025-04-16T23:00:05.000000Z"}, {"uuid": "adbadea1-335a-4b8d-bc8f-2d242eddfc49", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/M_3_7_1/35254", "content": "\u200f\u0627\u0630\u0627 \u0643\u0646\u062a \u062a\u0633\u062a\u062e\u062f\u0645 #Linux \u0648\u062a\u062d\u0628 \u062a\u062a\u0627\u0643\u062f \u0627\u0646\u0643 \u063a\u064a\u0631 \u0645\u0635\u0627\u0628 \u0628\u062b\u063a\u0631\u0629 \ud83d\udc48 CVE-2024-3094 \ud83d\udc49\n\n\u0627\u0633\u062a\u062e\u062f\u0645 \u0647\u0630\u0647 \u0627\u0644\u0627\u062f\u0627\u0629\nhttps://github.com/jfrog/cve-2024-3094-tools/tree/main/cve-2024-3094-detector", "creation_timestamp": "2024-07-16T02:05:58.000000Z"}, {"uuid": "fcbae249-a996-4418-b797-d4bd04718a2d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/WARLOCK_DARK_ARMY_OFFICIALS/4072", "content": "CVE-2024-3094 - An ssh honeypot with the XZ backdoor. \n\nhttps://github.com/lockness-Ko/xz-vulnerable-honeypot", "creation_timestamp": "2024-03-31T13:52:41.000000Z"}, {"uuid": "b6c54268-c507-4ecd-a49d-266f54ccf052", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/NinjaSec/28351", "content": "\ud83d\udd27 CVE Exploitation Tools (2024\u20132025)\n\n1. CVE-2024-25600 \u2013 WordPress Bricks Builder RCE\n\n2. CVE-2024-24919 \u2013 Check Point Security Gateway RCE\n\n3. CVE-2024-29025 \u2013 Netty HttpPostRequestDecoder DoS\n\n4. CVE-2024-21525 \u2013 node-twain Buffer Overflow\n\n5. CVE-2024-3094 \u2013 XZ Backdoor Detector\n\n6. CVE-2024-21515 \u2013 OpenCart Reflected XSS\n\n7. CVE-2024-21552 \u2013 SuperAGI Arbitrary Code Execution\n\n8. CVE-2024-56249 \u2013 WordPress WPMasterToolKit Arbitrary File Upload\n\n9. CVE-2024-24919 \u2013 Check Point VPN Exploit\n\n10. CVE-2024-24919 \u2013 Python Exploit Script\n\nPython script to exploit CVE-2024-24919 vulnerability.\n\nGitHub: LucasKatashi/CVE-2024-24919\n\n11. CVE-2024-24919 \u2013 Exploit PoC\n\nProof-of-Concept for exploiting CVE-2024-24919.\n\nGitHub: seed1337/CVE-2024-24919-POC\n\n12. CVE-2024-24919 \u2013 Check Point Remote Access VPN Exploit\n\nScripts to exploit CVE-2024-24919 in Check Point VPNs.\n\nGitHub: Praison001/CVE-2024-24919-Check-Point-Remote-Access-VPN\n\n13. CVE-2024-25600 \u2013 Alternate Exploit Script\n\nAnother implementation to exploit Bricks Builder RCE.\n\nGitHub: meli0dasH4ck3r/cve-2024-25600\n\n14. CVE-2024-25600 \u2013 Exploit Script\n\nPython script to exploit Bricks Builder RCE vulnerability.\n\nGitHub: K3ysTr0K3R/CVE-2024-25600-EXPLOIT \n\n\n\ud83d\udd27 CVE Exploitation Tools & Frameworks\n\n1. trickest/cve\n\n\ud83d\udd17 https://github.com/trickest/cve\n\n2. PayloadsAllTheThings \u2013 CVE Exploits\n\n\ud83d\udd17 https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/CVE%20Exploits/README.md\n\n3. qazbnm456/awesome-cve-poc\n\n\ud83d\udd17 https://github.com/qazbnm456/awesome-cve-poc\n\n4. intel/cve-bin-tool\n\n\ud83d\udd17 https://github.com/intel/cve-bin-tool\n\n5. cve-search/cve-search\nN\n\n\ud83d\udd17 https://github.com/cve-search/cve-search\n\n6. vertoforce/CVE-Enrichment\n\n\ud83d\udd17 https://github.com/vertoforce/CVE-Enrichment\n\n7. TURROKS/CVE_Prioritizer\n\n\ud83d\udd17 https://github.com/TURROKS/CVE_Prioritizer\n\n8. clearlinux/cve-check-tool\n\n\ud83d\udd17 https://github.com/clearlinux/cve-check-tool\n\n9. cddmp/cvecheck\n\n\ud83d\udd17 https://github.com/cddmp/cvecheck\n\n10. center-for-threat-informed-defense/attack_to_cve\n\nMaps MITRE ATT&CK techniques to CVEs to characterize vulnerability impacts.\n\n\ud83d\udd17 https://github.com/center-for-threat-informed-defense/attack_to_cve\n\n\n\ud83e\uddea Specific CVE Exploit Tools\n\n11. CVE-2024-25600 Exploit Tool\n\nDesigned to exploit a vulnerability in the Bricks Builder plugin for WordPress.\n\n\ud83d\udd17 https://github.com/Chocapikk/CVE-2024-25600\n\n12. RevoltSecurities/CVE-2024-24919\n\nTool to detect and exploit CVE-2024-24919 vulnerability.\n\n\ud83d\udd17 https://github.com/RevoltSecurities/CVE-2024-24919\n\n13. ROCA Detection Tool\n\nDetects RSA keys vulnerable to the ROCA vulnerability (CVE-2017-15361).\n\n\ud83d\udd17 https://github.com/crocs-muni/roca\n\n\ud83d\udee0\ufe0f Additional Tools & Resources\n\n14. Goby\n\nA network security assessment tool that can scan for vulnerabilities and map attack surfaces.\n\n\ud83d\udd17 https://github.com/gobysec/Goby\n\n15. awesome-pentestu\n\nA curated list of penetration testing resources, including tools for CVE exploitation.\n\n\ud83d\udd17 https://github.com/enaqx/awesome-pentest\n\n16. awesome-bugbounty-tools\n\nA collection of tools useful for bug bounty hunting, some of which relate to CVE exploitation.\n\n\ud83d\udd17 https://github.com/vavkamil/awesome-bugbounty-tools\n\n17. cyberguideme/Tools\n\nA repository of various cybersecurity tools, including those for exploiting known vulnerabilities.\n\n\ud83d\udd17 https://github.com/cyberguideme/Tools\n\n\n#GrayHats", "creation_timestamp": "2025-04-18T21:33:21.000000Z"}, {"uuid": "f6df1752-0795-4182-9eb4-45de62008f92", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/proxy_bar/1984", "content": "xzbot (CVE-2024-3094)\n*\n\u0420\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f\nhoneypot\n+ \u0422\u0435\u0441\u0442\u043e\u0432\u044b\u0439 \u044d\u043a\u0441\u043f\u043b\u043e\u0438\u0442 \u0434\u043b\u044f xz backdoor\n*\n\u041f\u043e\u0434\u043e\u0431\u0440\u0430\u0442\u044c\n\n#xz #backdoor", "creation_timestamp": "2024-04-02T15:22:35.000000Z"}, {"uuid": "fe538318-b76d-46f6-b0ee-595c074f6ddd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/proxy_bar/1981", "content": "xz-vulnerable-honeypot \n*\nSSH-\u0445\u0430\u043d\u0438\u043f\u043e\u0442 \u0441 \u0431\u044d\u043a\u0434\u043e\u0440\u043e\u043c XZ. CVE-2024-3094\n*\ndownload\n\n#xz #docker #honeypot", "creation_timestamp": "2024-03-31T12:21:35.000000Z"}, {"uuid": "410ce906-8858-49bb-9255-64f1c845614d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/breachdetector/492545", "content": "{\n  \"Source\": \"https://www.turkhackteam.org/\",\n  \"Content\": \"What is the CVE-2024-3094 Attack ? (Current Vulnerability)\", \n  \"author\": \" ('BARBAROS)\",\n  \"Detection Date\": \"10 Apr 2024\",\n  \"Type\": \"Data leak\"\n}\n\ud83d\udd39 t.me/breachdetector \ud83d\udd39", "creation_timestamp": "2024-04-10T19:24:21.000000Z"}, {"uuid": "d057df55-621e-4673-be86-ccb5b31277ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/breachdetector/494988", "content": "{\n  \"Source\": \"https://www.turkhackteam.org/\",\n  \"Content\": \"CVE-2024-3094: What is Linux and Application Security ?\", \n  \"author\": \" ('BARBAROS)\",\n  \"Detection Date\": \"13 Apr 2024\",\n  \"Type\": \"Data leak\"\n}\n\ud83d\udd39 t.me/breachdetector \ud83d\udd39", "creation_timestamp": "2024-04-13T14:45:03.000000Z"}, {"uuid": "48c43ed8-8494-4f68-bd4e-4feb0b92df7d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/breachdetector/494985", "content": "{\n  \"Source\": \"https://www.turkhackteam.org/\",\n  \"Content\": \"CVE-2024-3094: Linux ve Uygulama G\u00fcvenli\u011fi Nedir ? T\u00fcrk\u00e7e Anlat\u0131m\", \n  \"author\": \" ('BARBAROS)\",\n  \"Detection Date\": \"13 Apr 2024\",\n  \"Type\": \"Data leak\"\n}\n\ud83d\udd39 t.me/breachdetector \ud83d\udd39", "creation_timestamp": "2024-04-13T14:19:58.000000Z"}, {"uuid": "703315ad-959e-4719-921e-ea79408b42e3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/breachdetector/492546", "content": "{\n  \"Source\": \"https://www.turkhackteam.org/\",\n  \"Content\": \"CVE-2024-3094 Sald\u0131r\u0131s\u0131 Nedir ? (G\u00fcncel A\u00e7\u0131k)\", \n  \"author\": \" ('BARBAROS)\",\n  \"Detection Date\": \"10 Apr 2024\",\n  \"Type\": \"Data leak\"\n}\n\ud83d\udd39 t.me/breachdetector \ud83d\udd39", "creation_timestamp": "2024-04-10T19:24:23.000000Z"}, {"uuid": "6c4d32b5-4d95-45bd-8f46-801d4ab2e921", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "Telegram/r0ciHr8chfatJJIvASQMx6qY6x86dmTloz6LNAhDK7_nKxk", "content": "", "creation_timestamp": "2024-03-30T15:02:12.000000Z"}, {"uuid": "c5ed6811-4148-417e-8056-d778d2402aa1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cybersecs/2791", "content": "\u041f\u0435\u0440\u0435\u0432\u0456\u0440\u043a\u0430 \u043d\u0430 \u0432\u0440\u0430\u0437\u043b\u0438\u0432\u0456\u0441\u0442\u044c \u0434\u043e CVE-2024-3094 \u044f\u043a\u0430 \u043f\u0440\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u044c \u0434\u043e\u00a0 RCE \u0432 \u0434\u0456\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445 \u0437 \u0432\u0435\u0440\u0441\u0456\u0454\u044e xz 5.6.0 5.6.1. $ xz -v \u0430\u0431\u043e xz -- version .\u00a0\u00a0 \u042f\u043a\u0449\u043e \u0432\u0435\u0440\u0441\u0456\u044f 5.4.5 \u0430\u0431\u043e \u043c\u0435\u043d\u0448\u0430 - \u0432\u0441\u0435 \u0434\u043e\u0431\u0440\u0435. \u042f\u043a\u0449\u043e \u043d\u0456 \u0440\u043e\u0431\u0438\u043c\u043e \u0430\u0443\u0434\u0438\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0438 \u043d\u0430 \u0432\u0442\u0440\u0443\u0447\u0430\u043d\u043d\u044f \u0432\u0438\u043c\u043a\u043d\u0443\u0432\u0448\u0438 ssh \u0437\u043e\u0432\u043d\u0456. \u041f\u0456\u0441\u043b\u044f \u0447\u043e\u0433\u043e \u0432\u0456\u0434\u043a\u0430\u0442\u0443\u0454\u043c\u043e \u0432\u0435\u0440\u0441\u0456\u044e \u0431\u0456\u0431\u043b\u0456\u043e\u0442\u0435\u043a\u0438 xz/liblzma. \u042f\u043a\u0449\u043e \u043d\u0435 \u043c\u043e\u0436\u0435\u043c\u043e \u043f\u0438\u043b\u044c\u043d\u0443\u0454\u043c\u043e \u0442\u0430 \u0432\u0438\u043c\u0438\u043a\u0430\u0454\u043c\u043e \u0441\u0441\u0445, \u0456 \u0443\u0441\u0435 \u0449\u043e \u043c\u043e\u0436\u0435 \u0432\u0438\u043a\u043e\u0440\u0438\u0441\u0442\u043e\u0432\u0443\u0432\u0430\u0442\u0438 \u0446\u044e \u0431\u0456\u0431\u043b\u0456\u043e\u0442\u0435\u043a\u0443. \u0414\u0435\u044f\u043a\u0456 \u0432\u0435\u0440\u0441\u0456\u0457 \u0432\u0435\u0431 \u0441\u0435\u0440\u0432\u0435\u0440\u0456\u0432 \u043c\u043e\u0436\u0443\u0442\u044c \u0432\u0438\u043a\u043e\u0440\u0438\u0441\u0442\u043e\u0432\u0443\u0432\u0430\u0442\u0438 \u0457\u0457 \u0442\u0435\u0436.", "creation_timestamp": "2024-07-24T15:36:04.000000Z"}, {"uuid": "015c9d8b-51ad-440c-9f02-785c1492f7a1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/CyberSecurityIL/41601", "content": "\u05e9\u05d1\u05d5\u05e2 \u05d8\u05d5\u05d1, \u05e9\u05d9\u05de\u05d5 \u05dc\u05d1 \u05dc\u05d7\u05d5\u05dc\u05e9\u05d4 \u05e7\u05e8\u05d9\u05d8\u05d9\u05ea \u05d7\u05d3\u05e9\u05d4 (\u05d3\u05d9\u05e8\u05d5\u05d2 10/10) \u05d4\u05e7\u05d9\u05d9\u05de\u05ea \u05d1\u05d7\u05dc\u05e7 \u05de\u05d4\u05d4\u05e4\u05e6\u05d5\u05ea \u05e9\u05dc \u05dc\u05d9\u05e0\u05d5\u05e7\u05e1 - CVE-2024-3094 \u26a0\ufe0f\n\n\u05d4\u05d7\u05d5\u05dc\u05e9\u05d4 \u05d4\u05d7\u05d3\u05e9\u05d4 \u05d4\u05d9\u05d0 \u05d1\u05e1\u05e4\u05e8\u05d9\u05d9\u05ea XZ Utils \u05d1\u05d2\u05e8\u05e1\u05d0\u05d5\u05ea 5.6.0 \u05d5-5.6.1 \u05d5\u05d4\u05d4\u05de\u05dc\u05e6\u05d4 \u05d4\u05d9\u05d0 \u05dc\u05e9\u05e0\u05de\u05da \u05d7\u05d6\u05e8\u05d4 \u05dc\u05d2\u05e8\u05e1\u05d0 5.4.6.\n\n\u05d0\u05d6\u05d4\u05e8\u05d5\u05ea \u05d5\u05d4\u05e1\u05d1\u05e8\u05d9\u05dd \u05e2\u05dc \u05d4\u05d7\u05d5\u05dc\u05e9\u05d4 \u05d4\u05d7\u05d3\u05e9\u05d4 \u05d9\u05e6\u05d0\u05d5 \u05e2\u05dc \u05d9\u05d3\u05d9 CISA, Redhat, Debian, Kali \u05d5\u05e2\u05d5\u05d3.\n\n\u05e0\u05ea\u05d9 \u05de\u05e7\u05d1\u05d5\u05e6\u05ea \u05d4\u05d3\u05d9\u05d5\u05e0\u05d9\u05dd \u05d4\u05e4\u05e0\u05d4 \u05d0\u05ea \u05ea\u05e9\u05d5\u05de\u05ea \u05dc\u05d9\u05d1\u05d9 \u05dc\u05e9\u05e8\u05e9\u05d5\u05e8 \u05d1\u05d5 \u05e0\u05d8\u05e2\u05df \u05db\u05d9 \u05de\u05d9 \u05e9\u05d0\u05d7\u05e8\u05d0\u05d9 \u05dc\u05d9\u05e6\u05d9\u05e8\u05ea \u05d4\u05d7\u05d5\u05dc\u05e9\u05d4 \u05d4\u05d5\u05d0 \u05dc\u05d0 \u05e4\u05d7\u05d5\u05ea \u05de\u05d0\u05e9\u05e8 \u05d0\u05d7\u05d3 \u05de\u05d4\u05ea\u05d5\u05e8\u05de\u05d9\u05dd \u05d4\u05d5\u05d5\u05ea\u05d9\u05e7\u05d9\u05dd \u05e9\u05dc \u05d4\u05e1\u05e4\u05e8\u05d9\u05d4, \u05e0\u05e8\u05d0\u05d4 \u05db\u05d9 \u05d4\u05d7\u05d3\u05e8\u05ea \u05d4\u05d7\u05d5\u05dc\u05e9\u05d4 \u05ea\u05d5\u05db\u05e0\u05e0\u05d4 \u05de\u05e8\u05d0\u05e9 \u05d1\u05e7\u05e4\u05d9\u05d3\u05d4.\n\n(\u05d4\u05d7\u05d5\u05dc\u05e9\u05d4 \u05e4\u05d5\u05e8\u05e1\u05de\u05d4 \u05d1\u05e4\u05d9\u05d3 \u05d4\u05d7\u05d5\u05dc\u05e9\u05d5\u05ea \u05d4\u05e7\u05e8\u05d9\u05d8\u05d9\u05d5\u05ea \u05d1\u05d9\u05d5\u05dd \u05e9\u05d9\u05e9\u05d9 \u05d1\u05e2\u05e8\u05d1).\n\nhttps://t.me/CyberSecurityIL/4904\n\n#\u05d7\u05d5\u05dc\u05e9\u05d5\u05ea", "creation_timestamp": "2024-03-30T18:30:59.000000Z"}, {"uuid": "b9a99e52-cbe5-40fe-954c-1f922b940a9a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/true_secator/5587", "content": "\u034f\u0420\u0430\u0441\u043a\u0440\u044b\u0442\u0430 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u0430\u044f \u0430\u0442\u0430\u043a\u0443 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a, \u043d\u0430\u0446\u0435\u043b\u0435\u043d\u043d\u0430\u044f \u043d\u0430 open source \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e, \u0432 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u0435 \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0432 \u043d\u0430\u0431\u043e\u0440 \u0443\u0442\u0438\u043b\u0438\u0442 XZ Utils \u0431\u044b\u043b \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d \u0431\u044d\u043a\u0434\u043e\u0440, \u043f\u0440\u043e\u0441\u043e\u0447\u0438\u0432\u0448\u0438\u0439\u0441\u044f \u0432\u043f\u043e\u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u0438 \u0432 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 Linux.\n\n\u041f\u0440\u0438\u0447\u0435\u043c \u0441\u0430\u043c\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u044f \u043f\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0431\u044b\u043b\u0430 \u0438\u043d\u0438\u0446\u0438\u0438\u0440\u043e\u0432\u0430\u043d\u0430 \u0434\u0432\u0430 \u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u0438 \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u043b\u0430 \u0432 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u044d\u0442\u0430\u043f\u043e\u0432, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0432 \u0441\u0435\u0431\u044f \u0441\u043e\u0446\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u044e, \u0432\u044b\u0442\u0435\u0441\u043d\u0435\u043d\u0438\u0435 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0433\u043e \u043c\u044d\u0439\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0438 \u0444\u0435\u0439\u043a\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0430\u0432\u043b\u0438\u0432\u0430\u043d\u0438\u044f \u043d\u0443\u0436\u043d\u044b\u0445 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0432 XZ \u0438 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445 \u0441 \u043d\u0435\u0439.  \n\n\u0422\u0430\u043a\u0438\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043d\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u043c \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0430\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u0432\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0439 \u043a\u043e\u0434 \u0432 \u043d\u0430\u0431\u043e\u0440 \u0443\u0442\u0438\u043b\u0438\u0442 XZ Utils \u0432\u0435\u0440\u0441\u0438\u0439 5.6.0 (\u0432\u044b\u043f\u0443\u0449\u0435\u043d\u043d\u0443\u044e 24 \u0444\u0435\u0432\u0440\u0430\u043b\u044f) \u0438 5.6.1 (\u0432\u044b\u043f\u0443\u0449\u0435\u043d\u043d\u0443\u044e 9 \u043c\u0430\u0440\u0442\u0430).\n\n\u0423\u0447\u0438\u0442\u044b\u0432\u0430\u044f, \u0447\u0442\u043e \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0430 \u0447\u0440\u0435\u0437\u0432\u044b\u0447\u0430\u0439\u043d\u043e \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u0430 \u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e\u043c \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0441 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0434\u043b\u044f Linux \u0438 macOS, \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0439 \u043a\u043e\u0434 \u0443\u0441\u043f\u0435\u043b \u043f\u043e\u043f\u0430\u0441\u0442\u044c \u0432 \u0440\u044f\u0434 \u043c\u0430\u0440\u0442\u043e\u0432\u0441\u043a\u0438\u0445 \u0441\u0431\u043e\u0440\u043e\u043a.\n\n\u041e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0431\u044d\u043a\u0434\u043e\u0440 (CVE-2024-3094 c CVSS 10) \u043f\u0440\u0438 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0432\u044b\u043f\u043e\u043b\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0435, \u043d\u0435 \u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044f \u0441\u043b\u0435\u0434\u043e\u0432 \u0432 \u043b\u043e\u0433\u0430\u0445 sshd.\n\n\u0420\u0430\u0441\u043a\u0440\u044b\u0442\u0438\u0435 \u043f\u0440\u0438\u043f\u0438\u0441\u044b\u0432\u0430\u044e\u0442 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0443 Microsoft \u0410\u043d\u0434\u0440\u0435\u0441\u0443 \u0424\u0440\u043e\u0439\u043d\u0434\u0443, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0441\u043e\u043e\u0431\u0449\u0438\u043b \u043e\u00a0\u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0435\u00a0\u0432 \u043f\u044f\u0442\u043d\u0438\u0446\u0443.\n\n\u0422\u0440\u043e\u044f\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 5.6.0 \u0438 5.6.1 \u0437\u0430\u0442\u0440\u043e\u043d\u0443\u043b\u0438 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 Linux, \u0432\u044b\u043f\u0443\u0449\u0435\u043d\u043d\u044b\u0435 \u0432 \u043c\u0430\u0440\u0442\u0435: Alpine 5.6.0 - 5.6.1-r1, Debian (\u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438) 5.5.1alpha-0.1 - 5.6.1-1, Fedora Rawhide (\u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438), Kali Linux, openSUSE Tumbleweed \u0438 MicroOS.\n\n\u041d\u0435 \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u044b \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438: Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise, openSUSE Leap, Debian Stable.\n\n\u041f\u043e Arch Linux \u0441\u043e\u043e\u0431\u0449\u0430\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u0432 \u0432\u0438\u0434\u0443 \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0438 \u043b\u0438\u043d\u043a\u043e\u0432\u043a\u0438 openssh \u0438 liblzma \u0432 Arch \u0431\u044d\u043a\u0434\u043e\u0440 \u043d\u0435 \u0441\u043c\u043e\u0436\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c, \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u0438 \u043f\u043e Fedora 40.\n\n\u0414\u0440\u0443\u0433\u0438\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u044b \u0441\u043b\u0435\u0434\u0443\u0435\u0442 \u043f\u0440\u043e\u0432\u0435\u0440\u044f\u0442\u044c \u0441\u0430\u043c\u043e\u0441\u0442\u043e\u044f\u0442\u0435\u043b\u044c\u043d\u043e \u043d\u0430 \u043d\u0430\u043b\u0438\u0447\u0438\u0435 \u0432 \u043d\u0438\u0445 \u0442\u0440\u043e\u044f\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432\u0435\u0440\u0441\u0438\u0439 XZ Utils. \u0414\u043e\u0441\u0442\u0443\u043f\u043d\u043e Yara-\u043f\u0440\u0430\u0432\u0438\u043b\u043e.\n\n\u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0432 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u043e\u0431 \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0432 \u0434\u0438\u043a\u043e\u0439 \u043f\u0440\u0438\u0440\u043e\u0434\u0435 \u043d\u0435 \u043f\u043e\u0441\u0442\u0443\u043f\u0430\u043b\u043e, \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u044e\u0442 \u043e\u0442\u043a\u0430\u0442\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u0431\u043e\u043b\u0435\u0435 \u0441\u0442\u0430\u0440\u044b\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u043f\u0440\u043e\u0432\u0435\u0441\u0442\u0438 \u043f\u043e\u043b\u043d\u043e\u0446\u0435\u043d\u043d\u043e\u0435 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442.\n\n\u0410\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0443\u0433\u0440\u043e\u0437\u0443 \u043f\u043e\u043a\u0430 \u043d\u0435 \u0443\u0434\u0430\u043b\u043e\u0441\u044c, \u043e\u0434\u043d\u0430\u043a\u043e \u0441\u043b\u043e\u0436\u043d\u044b\u0439 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u044d\u0442\u043e\u0433\u043e \u0431\u044d\u043a\u0434\u043e\u0440\u0430 \u0438 \u0445\u0440\u043e\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044f \u0432 \u0441\u043e\u0432\u043e\u043a\u0443\u043f\u043d\u043e\u0441\u0442\u0438 \u0443\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043d\u0430 \u0443\u0447\u0430\u0441\u0442\u0438\u0435 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0438\u0437\u043e\u0449\u0440\u0435\u043d\u043d\u043e\u0433\u043e \u0438 \u0440\u0435\u0441\u0443\u0440\u0441\u043d\u043e\u0433\u043e \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0430.\n\n\u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u0441\u043a\u0435\u043f\u0441\u0438\u0441 \u0443 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0442\u0430\u043a\u0436\u0435 \u0432\u044b\u0437\u044b\u0432\u0430\u043b\u043e \u00ab\u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0441\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u043f\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0440\u0430\u0441\u043a\u0440\u044b\u0442\u0438\u0435, \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e, \u0441\u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0434\u043b\u044f \u0441\u043e\u043a\u0440\u044b\u0442\u0438\u044f \u00ab\u043c\u0435\u0442\u043e\u0434\u043e\u0432 \u0438 \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u043e\u0432\u00bb.\n\n\u0411\u0443\u0434\u0435\u043c \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c.", "creation_timestamp": "2024-04-01T13:06:05.000000Z"}, {"uuid": "1c9ee6d6-2d25-4d08-bc77-eae3be15318c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/true_secator/5596", "content": "\u041f\u043e \u0441\u043b\u0435\u0434\u0430\u043c \u043d\u0430\u0448\u0443\u043c\u0435\u0432\u0448\u0435\u0439 \u0430\u0442\u0430\u043a\u0438 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a XZ Utils (CVE-2024-3094) \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Binarly \u0432\u044b\u043f\u0443\u0441\u0442\u0438\u043b\u0430 \u043e\u0431\u0449\u0435\u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0439 \u0441\u043a\u0430\u043d\u0435\u0440 \u0434\u043b\u044f \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0438\u043c\u043f\u043b\u0430\u043d\u0442\u0430\u0442\u0430 \u0432 \u043b\u044e\u0431\u043e\u043c \u0434\u0432\u043e\u0438\u0447\u043d\u043e\u043c \u0444\u0430\u0439\u043b\u0435 Linux.\n\n\u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u044b\u0439 \u0432 \u043e\u0441\u043d\u043e\u0432\u0443 \u0443\u0442\u0438\u043b\u0438\u0442\u044b \u043f\u043e\u0434\u0445\u043e\u0434 \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u043e\u0442 \u0442\u0435\u043a\u0443\u0449\u0438\u0445 \u043f\u0440\u043e\u0432\u0435\u0440\u043e\u043a, \u0432\u043a\u043b\u044e\u0447\u0430\u044e\u0449\u0438\u0445 \u0441\u043e\u043f\u043e\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0431\u0430\u0439\u0442\u043e\u0432\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u0432\u043d\u0435\u0441\u0435\u043d\u0438\u0435 \u0432 \u0447\u0435\u0440\u043d\u044b\u0439 \u0441\u043f\u0438\u0441\u043e\u043a \u0445\u044d\u0448\u0435\u0439 \u0444\u0430\u0439\u043b\u043e\u0432 \u0438 \u043f\u0440\u0430\u0432\u0438\u043b\u0430 YARA, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043b\u043e\u0436\u043d\u044b\u043c \u0441\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043d\u0438\u044f\u043c.\n\nBinarly \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0430 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0439 \u0441\u043a\u0430\u043d\u0435\u0440, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u0442 \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0430\u043d\u0430\u043b\u0438\u0437 \u0434\u0432\u043e\u0438\u0447\u043d\u044b\u0445 \u0444\u0430\u0439\u043b\u043e\u0432 \u0434\u043b\u044f \u0432\u044b\u044f\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0434\u0435\u043b\u043a\u0438 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u043e\u0432 \u0432 \u043a\u043e\u0441\u0432\u0435\u043d\u043d\u043e\u0439 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 GNU (IFUNC).\n\n\u0412 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043e\u043d \u0438\u0441\u0441\u043b\u0435\u0434\u0443\u0435\u0442 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u044b, \u043f\u043e\u043c\u0435\u0447\u0435\u043d\u043d\u044b\u0435 \u043a\u0430\u043a \u043f\u043e\u0434\u043e\u0437\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0438 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0445 \u0440\u0435\u0437\u043e\u043b\u0432\u0435\u0440\u043e\u0432 IFUNC.\n\n\u0410\u0442\u0440\u0438\u0431\u0443\u0442 IFUNC \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440\u0430 GCC \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0432\u0435\u0440\u0441\u0438\u0439 \u043e\u0434\u043d\u043e\u0439 \u0438 \u0442\u043e\u0439 \u0436\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0437\u0430\u0442\u0435\u043c \u0432\u044b\u0431\u0438\u0440\u0430\u044e\u0442\u0441\u044f \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043a\u0440\u0438\u0442\u0435\u0440\u0438\u0435\u0432, \u0442\u0430\u043a\u0438\u0445 \u043a\u0430\u043a \u0442\u0438\u043f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430.\n\n\u041e\u0434\u043d\u0438\u043c \u0438\u0437 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u0432, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u044b\u0445 \u0431\u044d\u043a\u0434\u043e\u0440\u043e\u043c XZ \u0434\u043b\u044f \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f \u043f\u0435\u0440\u0432\u043e\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f, \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0430\u0442\u0440\u0438\u0431\u0443\u0442 GNU Indirect Function (ifunc), \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0438\u0439 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440\u0443 GCC \u0440\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u043a\u043e\u0441\u0432\u0435\u043d\u043d\u044b\u0435 \u0432\u044b\u0437\u043e\u0432\u044b \u0444\u0443\u043d\u043a\u0446\u0438\u0439 \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f.\n\n\u0411\u044d\u043a\u0434\u043e\u0440 XZ \u0438\u0437\u043c\u0435\u043d\u044f\u0435\u0442 \u0432\u044b\u0437\u043e\u0432\u044b ifunc \u0434\u043b\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 is_arch_extension_supported, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u043b\u0436\u043d\u0430 \u043f\u0440\u043e\u0441\u0442\u043e \u0432\u044b\u0437\u044b\u0432\u0430\u0442\u044c cpuid \u0434\u043b\u044f \u0432\u0441\u0442\u0430\u0432\u043a\u0438 \u0432\u044b\u0437\u043e\u0432\u0430 _get_cpuid, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044d\u043a\u0441\u043f\u043e\u0440\u0442\u0438\u0440\u0443\u0435\u0442\u0441\u044f \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u043c \u0444\u0430\u0439\u043b\u043e\u043c \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 (\u0442.\u0435. liblzma_la-crc64-fast.o), \u0432\u044b\u0437\u044b\u0432\u0430\u044f \u0438\u0441\u043a\u0430\u0436\u0435\u043d\u043d\u044b\u0435 _get_cpuid().\n\n\u0411\u044d\u043a\u0434\u043e\u0440 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c, \u0438\u0437\u043c\u0435\u043d\u044f\u044f \u0432\u044b\u0437\u043e\u0432\u044b IFUNC \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u0430 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f, \u0447\u0442\u043e \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430.\n\n\u0423\u0442\u0438\u043b\u0438\u0442\u0430 Binarly \u0441\u043a\u0430\u043d\u0438\u0440\u0443\u0435\u0442 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0442\u043e\u0447\u043a\u0438 \u0446\u0435\u043f\u043e\u0447\u043a\u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a, \u043f\u043e\u043c\u0438\u043c\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430 XZ Utils, \u0432 \u0441\u0432\u044f\u0437\u0438 \u0441 \u0447\u0435\u043c \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u044b \u0438\u043c\u0435\u044e\u0442 \u0433\u043e\u0440\u0430\u0437\u0434\u043e \u0431\u043e\u043b\u0435\u0435 \u0432\u044b\u0441\u043e\u043a\u0443\u044e \u0434\u043e\u0441\u0442\u043e\u0432\u0435\u0440\u043d\u043e\u0441\u0442\u044c.\n\n\u041e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u043e \u043d\u0430 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0447\u0435\u0441\u043a\u043e\u043c \u0430\u043d\u0430\u043b\u0438\u0437\u0435 \u0438 \u043c\u043e\u0436\u0435\u0442 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u043b\u044e\u0431\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b, \u0435\u0441\u043b\u0438 \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u044b\u0439 \u0431\u044d\u043a\u0434\u043e\u0440 \u0432\u043d\u0435\u0434\u0440\u0435\u043d \u0433\u0434\u0435-\u0442\u043e \u0435\u0449\u0435, \u0434\u0430\u0436\u0435 \u043f\u043e\u0441\u043b\u0435 \u043f\u0435\u0440\u0435\u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0446\u0438\u0438 \u0438\u043b\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u0434\u0430.\n\n\u0421\u043a\u0430\u043d\u0435\u0440 \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u043d\u0430 xz.fail, \u043a\u0443\u0434\u0430 \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0433\u0440\u0443\u0436\u0430\u0442\u044c \u0434\u0432\u043e\u0438\u0447\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 \u0431\u0435\u0437 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u0439 \u0438\u0445 \u0447\u0438\u0441\u043b\u0430.\n\n\u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, Binarly \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\u0430 \u043e\u0431\u0449\u0435\u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0439 API \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0431\u043e\u043b\u0435\u0435 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u043d\u043e\u0433\u043e \u0441\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f.", "creation_timestamp": "2024-04-03T14:57:26.000000Z"}, {"uuid": "1fa114ad-f674-4cca-899d-c69ab822bed6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/ctinow/213425", "content": "https://ift.tt/Ov0Bbht\nBeware! Backdoor found in XZ utilities used by many Linux distros (CVE-2024-3094)", "creation_timestamp": "2024-03-29T20:31:25.000000Z"}, {"uuid": "254568ae-c757-4f43-b693-ac938039ea90", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/ctinow/213717", "content": "https://ift.tt/IwXnih4\nBinarly released the free online scanner to detect the CVE-2024-3094 Backdoor", "creation_timestamp": "2024-04-02T20:16:49.000000Z"}, {"uuid": "a18228fb-0c20-409a-8c3f-13e1525283b5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/ctinow/213599", "content": "https://ift.tt/qkuIg2H\nBackdoor Discovered in XZ Utils: Patch Your Systems Now (CVE-2024-3094)", "creation_timestamp": "2024-04-02T01:21:05.000000Z"}, {"uuid": "6ea09189-2c91-4e6f-a4be-2a8433285a1f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/ctinow/213415", "content": "https://ift.tt/PCVHtBh\nReported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094", "creation_timestamp": "2024-03-29T19:26:24.000000Z"}, {"uuid": "0c24c6b6-698d-40cc-ae90-55c2f59d9639", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/MuhammadAlush0997/488", "content": "\u200f\u0627\u0630\u0627 \u0643\u0646\u062a \u062a\u0633\u062a\u062e\u062f\u0645 #Linux \u0648\u062a\u062d\u0628 \u062a\u062a\u0627\u0643\u062f \u0627\u0646\u0643 \u063a\u064a\u0631 \u0645\u0635\u0627\u0628 \u0628\u062b\u063a\u0631\u0629 \ud83d\udc48 CVE-2024-3094 \ud83d\udc49\n\n\u0627\u0633\u062a\u062e\u062f\u0645 \u0647\u0630\u0647 \u0627\u0644\u0627\u062f\u0627\u0629\nhttps://github.com/jfrog/cve-2024-3094-tools/tree/main/cve-2024-3094-detector\n\n\u062c\u0645\u064a\u0639 \u0627\u0644\u0623\u0648\u0627\u0645\u0631 \u0645\u0648\u062c\u0648\u062f\u0629 \u0641\u064a \u0627\u0644\u0635\u0648\u0631\u0629 \ud83d\udc46\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f\n\nt.me/MuhammadAlush0997\n\n\u062a\u0627\u0628\u0639\u0646\u064a \u0639\u0644\u0649 :\nTelegram | instagram | facebook | Twitter | YouTube", "creation_timestamp": "2024-04-05T03:09:34.000000Z"}, {"uuid": "4f2550e9-5692-41b1-95e1-2dd33dd5aefb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/MuhammadAlush0997/479", "content": "\u0627\u0644\u062b\u063a\u0631\u0629 \u0627\u0644\u062e\u0637\u064a\u0631\u0647 \u062d\u0627\u0644\u064a\u0627\u064b \u0644\u0623\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633 \n\n\u0645\u0633\u062a\u0648\u0649 \u062a\u0639\u0642\u064a\u062f \u0627\u0644\u0647\u062c\u0648\u0645 \u0644\u0647\u0627 XZ \u0645\u062b\u064a\u0631 \u0644\u0644\u0625\u0639\u062c\u0627\u0628 \u0644\u0644\u063a\u0627\u064a\u0629 \n\n\u0643\u0644 \u0634\u064a\u0621 \u064a\u0642\u0627\u0644 \u0648\u064a\u0644\u062e\u0635 \u0628\u0634\u0643\u0644 \u062c\u064a\u062f \u0647\u0646\u0627 \ud83d\udc46\n\u200e#xz \u200e#xzbackdoor CVE-2024-3094\n\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f\n\nt.me/MuhammadAlush0997\n\n\u062a\u0627\u0628\u0639\u0646\u064a \u0639\u0644\u0649 :\nTelegram | instagram | facebook | Twitter | YouTube", "creation_timestamp": "2024-04-01T04:05:59.000000Z"}, {"uuid": "0b269ef7-4107-4dce-8520-51b67614d9e4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/solar_security/1184", "content": "\u0412 \u0447\u0435\u0442\u0432\u0435\u0440\u0433 \u043c\u044b \u043e\u0431\u044a\u044f\u0441\u043d\u044f\u043b\u0438, \u043f\u043e\u0447\u0435\u043c\u0443 \u043d\u0435\u043b\u044c\u0437\u044f \u0438\u0433\u043d\u043e\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0443 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0446\u0435\u043f\u043e\u0447\u043a\u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a \u041f\u041e, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0434\u043e\u043a\u0430\u0436\u0435\u043c \u044d\u0442\u043e \u043d\u0430 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u043c \u043f\u0440\u0438\u043c\u0435\u0440\u0435.\n\n\u0412 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0439 \u0443\u0442\u0438\u043b\u0438\u0442\u0435 \u0434\u043b\u044f \u0441\u0436\u0430\u0442\u0438\u044f \u0434\u0430\u043d\u043d\u044b\u0445 XZ Utils \u043d\u0435\u0434\u0430\u0432\u043d\u043e \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b\u0438 \u0431\u044d\u043a\u0434\u043e\u0440 CVE-2024-3094. \u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0430\u043c \u043e\u0431\u043e\u0439\u0442\u0438 sshd \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043d\u0435\u0441\u0430\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0439 \u0434\u043e\u0441\u0442\u0443\u043f \u043a\u043e \u0432\u0441\u0435\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435.\n\n\u041f\u0430\u043a\u0435\u0442 XZ Utils \u0432\u043a\u043b\u044e\u0447\u0435\u043d \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 \u0438 \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0435\u0432 Linux, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u043e\u0434 \u0443\u0433\u0440\u043e\u0437\u043e\u0439 \u043e\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u0442\u044b\u0441\u044f\u0447\u0438 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u0438\u0445 \u0432 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445.\n\n\u0411\u044d\u043a\u0434\u043e\u0440 \u0432\u043d\u0435\u0434\u0440\u0438\u043b \u043e\u0434\u0438\u043d \u0438\u0437 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 XZ. \u042d\u0442\u043e \u0446\u0435\u043b\u0435\u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u0430\u044f \u0430\u0442\u0430\u043a\u0430 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u041f\u041e, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043b \u0434\u0432\u0430 \u0433\u043e\u0434\u0430.\n\n\u0427\u0442\u043e\u0431\u044b \u043d\u0435 \u0441\u0442\u0430\u0442\u044c \u0436\u0435\u0440\u0442\u0432\u043e\u0439 \u0442\u0430\u043a\u043e\u0439 \u0430\u0442\u0430\u043a\u0438, \u043d\u0443\u0436\u0435\u043d \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u043f\u043e\u043c\u043e\u0449\u043d\u0438\u043a \u2014 \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, Solar appScreener. \u041c\u043e\u0434\u0443\u043b\u044c SCS \u043e\u0446\u0435\u043d\u0438\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0434\u043e\u0432\u0435\u0440\u0438\u044f \u043a \u0434\u0440\u0443\u0433\u0438\u043c \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0430\u043c \u0430\u0432\u0442\u043e\u0440\u0430 \u0438 \u043f\u043e\u0434\u0441\u043a\u0430\u0436\u0435\u0442, \u043c\u043e\u0436\u043d\u043e \u043b\u0438 \u043d\u0430 \u043d\u0435\u0433\u043e \u043f\u043e\u043b\u0430\u0433\u0430\u0442\u044c\u0441\u044f.\n\n\u041d\u0430 \u043a\u0430\u0440\u0442\u0438\u043d\u043a\u0435 \u2013 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442 \u043d\u0430\u0448\u0435\u0439 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430-\u0441\u043e\u0437\u0434\u0430\u0442\u0435\u043b\u044f CVE-2024-3094. \u041e\u0446\u0435\u043d\u043a\u0430 \u043f\u043e \u043a\u0440\u0438\u0442\u0435\u0440\u0438\u044e \u00ab\u200e\u0410\u0432\u0442\u043e\u0440\u0441\u043a\u0438\u0439 \u0441\u043e\u0441\u0442\u0430\u0432\u00bb \u043d\u0438\u0437\u043a\u0430\u044f, Solar appScreener \u0441\u0447\u0438\u0442\u0430\u0435\u0442 \u0430\u0432\u0442\u043e\u0440\u0430 \u043d\u0435\u0434\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u043c, \u0430 \u0437\u043d\u0430\u0447\u0438\u0442 \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0435\u0433\u043e \u043f\u0430\u043a\u0435\u0442\u044b \u0432 \u0441\u0432\u043e\u0435\u043c \u041f\u041e.", "creation_timestamp": "2024-04-06T11:02:25.000000Z"}, {"uuid": "8c6c381a-17c6-4e72-9af2-aaba04625f22", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/theninjaway1337/1500", "content": "Urgent: Secret Backdoor Found in XZ Utils Library, Impacts Major Linux Distros\n\nRedHat on Friday released an \"urgent security alert\" warning that two versions of a popular data compression library called XZ Utils (previously LZMA Utils) have been backdoored with malicious code designed to allow unauthorized remote access.\n\nThe software supply chain compromise, tracked as CVE-2024-3094, has a CVSS score of 10.0, indicating maximum severity. It impacts XZ Utils versions 5.6.0 (released February 24) and 5.6.1 (released March 9).\n\n5.6.0 & 5.6.1 \u2014 vuln\n\nhttps://thehackernews.com/2024/03/urgent-secret-backdoor-found-in-xz.html", "creation_timestamp": "2024-03-30T08:33:08.000000Z"}, {"uuid": "94f07e65-2aec-4a3b-8973-8a2bff571ce1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/Kelvinseccommunity/188", "content": "CVE-2024-3094 - An ssh honeypot with the XZ backdoor. \n\nhttps://github.com/lockness-Ko/xz-vulnerable-honeypot", "creation_timestamp": "2024-04-02T18:47:06.000000Z"}, {"uuid": "1555bf6b-7434-4624-8b67-64fabe139d45", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/Kelvinseccommunity/191", "content": "https://github.com/amlweems/xzbot\n\nnotes, honeypot, and exploit demo for the xz backdoor (CVE-2024-3094)\n#github", "creation_timestamp": "2024-04-02T18:49:27.000000Z"}, {"uuid": "b022383d-c900-4f78-b9c4-458afcf254b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "exploited", "source": "https://t.me/MuhammadAlush0997/478", "content": "\u062b\u063a\u0631\u0647 \u062e\u0637\u064a\u0631\u0647 \u062c\u062f\u0627\u064b #Backdoor \u0641\u064a \u0627\u063a\u0644\u0628 \u0627\u0646\u0638\u0645\u0647 #\u0644\u064a\u0646\u0643\u0633 \n\n\u0627\u0635\u062f\u0631\u062a RedHat \u062a\u062d\u0630\u064a\u0631 \u0628\u062e\u0635\u0648\u0635 \u0648\u062c\u0648\u062f \u0628\u0648\u0627\u0628\u0647 \u062e\u0644\u0641\u064a\u0629 ( Backdoor ) \u0645\u0632\u0631\u0648\u0639 \u0641\u064a \u0645\u0643\u062a\u0628\u0647 XZ Utils \u0627\u0644\u062e\u0627\u0635\u0647 \u0628\u0636\u063a\u0637 \u0627\u0644\u0645\u0644\u0641\u0627\u062a \u0627\u0644\u0645\u062b\u0628\u062a\u0647 \u0645\u0633\u0628\u0642\u0627\u064b \u0639\u0644\u0649 \u0627\u0644\u0643\u062b\u064a\u0631 \u0645\u0646 \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 \u0627\u0644\u0645\u0634\u0647\u0648\u0631\u0629.\n\u0627\u0644\u0628\u0648\u0627\u0628\u0629 \u0627\u0644\u062e\u0644\u0641\u064a\u0629 \u062a\u0645 \u0627\u062e\u0641\u0627\u0626\u0647\u0627 \u0628\u0637\u0631\u064a\u0642\u0647 \u0645\u0639\u0642\u062f\u0647 \u0641\u064a \u0627\u0644\u0643\u0648\u062f ( obfuscations ).\n\u062a\u0633\u0645\u062d \u0644\u0644\u0645\u062e\u062a\u0631\u0642 \u0628\u0627\u0644\u0648\u0635\u0648\u0644 \u0644\u0644\u0646\u0638\u0627\u0645 \u0645\u0646 \u062e\u0644\u0627\u0644 SSH\n\n\ud83d\udccc \u0645\u0633\u062a\u0648\u0649 \u0627\u0644\u062e\u0637\u0648\u0631\u0647 10\n\n\ud83d\udccc \u0631\u0642\u0645 \u0627\u0644\u062b\u063a\u0631\u0647 CVE-2024-3094\n\n\u0627\u0644\u0631\u0627\u0628\u0637 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-3094\n\n\u200f\u0628\u0648\u0627\u0628\u0629 \u062e\u0644\u0641\u064a\u0629 \u0641\u064a \u0627\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633\n\u0627\u0643\u062a\u0634\u0641 \u0627\u062d\u062f \u0628\u0627\u062d\u062b\u064a \u0627\u0644\u062b\u063a\u0631\u0627\u062a \u062b\u063a\u0631\u0629 \u0648\u0647\u064a \u0639\u0628\u0627\u0631\u0629 \u0639\u0646 \u0628\u0648\u0628\u0647 \u062e\u0644\u0641\u064a\u0629 \u0641\u064a XZ Utils \u0648\u0647\u064a \u0639\u0628\u0627\u0631\u0629 \u0639\u0646 \u0645\u0643\u062a\u0628\u0629 \u0645\u062a\u062e\u0635\u0635\u0629 \u0641\u064a \u0636\u063a\u0637 \u0627\u0644\u0645\u0644\u0641\u0627\u062a\u060c \u0648\u062a\u062a\u064a\u062d \u0627\u0644\u0628\u0648\u0627\u0628\u0629 \u0627\u0644\u062e\u0644\u0641\u064a\u0647 \u0644\u0644\u0645\u062e\u062a\u0631\u0642 \u0627\u0644\u0627\u062a\u0635\u0627\u0644 \u0628\u062c\u0647\u0627\u0632 \u0627\u0644\u0636\u062d\u064a\u0629 \u0639\u0646 \u0637\u0631\u064a\u0642 \u0628\u0631\u0648\u062a\u0648\u0643\u0648\u0644 SSH.\n\u0648\u0627\u0644\u062b\u063a\u0631\u0629 \u062a\u062d\u062a \u062a\u0643\u0648\u064a\u062f CVE-2024-3094 \u0648\u062a\u0645 \u062a\u0635\u0646\u064a\u0641\u0647\u0627 \u0643 10 \u0627\u0648 \u062e\u0637\u064a\u0631\u0629 \u0644\u0644\u063a\u0627\u064a\u0629.\n\u0637\u0628\u0639\u0627\u064b \u0643\u062b\u064a\u0631 \u0645\u0646 \u0646\u0633\u062e \u0644\u064a\u0646\u0643\u0633 \u0645\u0635\u0627\u0628\u0629 \u0628\u0647\u0630\u0647 \u0627\u0644\u062b\u063a\u0631\u0629 \u0628\u0645\u0627 \u0641\u064a\u0647\u0627 \u0643\u0627\u0644\u064a \u0644\u064a\u0646\u0643\u0633 \u0648 Opensuse \u0648\u0628\u0639\u0636 \u0646\u0633\u062e Debian \u0627\u0644\u0627\u062e\u062a\u0628\u0627\u0631\u064a\u0629.\n\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f\n\nt.me/MuhammadAlush0997\n\n\u062a\u0627\u0628\u0639\u0646\u064a \u0639\u0644\u0649 :\nTelegram | instagram | facebook | Twitter | YouTube", "creation_timestamp": "2024-03-30T23:59:53.000000Z"}, {"uuid": "91464a2a-9cb7-46d3-a30b-6646c6c2126d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "exploited", "source": "https://t.me/information_security_channel/51920", "content": "Behind Enemy Lines: Understanding the Threat of the XZ Backdoor\nhttps://www.offsec.com/offsec/xz-backdoor/\n\nThe following is an excerpt from our new module on the recent XZ Utils backdoor, CVE-2024-3094.\n\u00a0\nOn Mar 29, 2024, at 12:00PM ET, Andres Freund posted (https://www.openwall.com/lists/oss-security/2024/03/29/4) on the Openwall mailing list about a backdoor he discovered in the XZ Utils (https://github.com/tukaani-project/xz) package. The backdoor targeted the OpenSSH (https://www.openssh.com/) binary, allowing remote code execution on impacted machines. This backdoor was not located in the GitHub repository, but only in release versions of the package, which hid its presence.\nGiven that XZ Utils had been installed (directly or indirectly) on billions of Linux systems worldwide, this finding stunned the international Linux and infosec communities.\nUnderstanding the Timeline of the Attack\nIn late 2021,\n... Read more \u00bb (https://www.offsec.com/offsec/xz-backdoor/)\nThe post Behind Enemy Lines: Understanding the Threat of the XZ Backdoor (https://www.offsec.com/offsec/xz-backdoor/) appeared first on OffSec (https://www.offsec.com/).", "creation_timestamp": "2024-04-09T20:13:46.000000Z"}, {"uuid": "cfc6958e-070e-41fd-9427-68c7d3df04df", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/thehackernews/4779", "content": "\u26a1 Critical Supply Chain Compromise: Backdoor in XZ Utils allows RCE. \n \nSee how to detect and mitigate CVE-2024-3094, a critical supply chain compromise, affecting XZ Utils Data compression library. \n \nRead: https://thn.news/critical-rce-xz-utils", "creation_timestamp": "2024-04-04T18:17:45.000000Z"}, {"uuid": "a4787cb8-0a36-48aa-a00b-c8296f2f7c40", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/anti_malware/17158", "content": "\u0421\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Binarly \u0432\u044b\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u044b\u0439 \u043e\u043d\u043b\u0430\u0439\u043d-\u0441\u043a\u0430\u043d\u0435\u0440, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u043e\u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u044f\u0432\u0438\u0442\u044c \u0438\u0441\u043f\u043e\u043b\u043d\u044f\u0435\u043c\u044b\u0435 \u0444\u0430\u0439\u043b\u044b \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 Linux, \u0437\u0430\u0442\u0440\u043e\u043d\u0443\u0442\u044b \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c\u044e \u0432 XZ Utils \u2014 CVE-2024-3094.", "creation_timestamp": "2024-08-20T16:59:18.000000Z"}, {"uuid": "c545d41e-7a8b-4f67-bfe6-1a90a475cfe5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/SecLabNews/15031", "content": "Linux \u043f\u043e\u0440\u0430\u0437\u0438\u043b\u0430 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0441 \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c \u0431\u0430\u043b\u043b\u043e\u043c CVSS \n\n\ud83c\udd98 \u0412 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0439 \u0443\u0442\u0438\u043b\u0438\u0442\u0435 \u0434\u043b\u044f \u0441\u0436\u0430\u0442\u0438\u044f xz, \u0448\u0438\u0440\u043e\u043a\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u043e\u0439 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux, \u0431\u044b\u043b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d \u0441\u043a\u0440\u044b\u0442\u044b\u0439 \u0431\u044d\u043a\u0434\u043e\u0440, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0438\u0439 \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0443\u0433\u0440\u043e\u0437\u0443 \u0434\u043b\u044f \u0446\u0435\u043f\u043e\u0447\u043a\u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a.\n\n\ud83d\udd0d \u0418\u043d\u0436\u0435\u043d\u0435\u0440-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442 \u0438\u0437 Microsoft \u0410\u043d\u0434\u0440\u0435\u0441 \u0424\u0440\u043e\u0443\u043d\u0434 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 .m4 \u0444\u0430\u0439\u043b\u044b \u0432 \u0430\u0440\u0445\u0438\u0432\u0430\u0445 xz, \u043c\u043e\u0434\u0438\u0444\u0438\u0446\u0438\u0440\u0443\u044e\u0449\u0438\u0435 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0443 \u0441\u0436\u0430\u0442\u0438\u044f liblzma \u0434\u043b\u044f \u043d\u0435\u0441\u0430\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u0430.\n\n\ud83d\udee1  \u0410\u0433\u0435\u043d\u0442\u0441\u0442\u0432\u043e \u043a\u0438\u0431\u0435\u0440\u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043d\u043e\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0421\u0428\u0410 (CISA) \u0432\u044b\u043f\u0443\u0441\u0442\u0438\u043b\u043e \u043f\u0440\u0435\u0434\u0443\u043f\u0440\u0435\u0436\u0434\u0435\u043d\u0438\u0435 \u043e\u0431 \u044d\u0442\u043e\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438, \u043e\u0442\u0441\u043b\u0435\u0436\u0438\u0432\u0430\u0435\u043c\u043e\u0439 \u043a\u0430\u043a CVE-2024-3094, \u0441 \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c \u0431\u0430\u043b\u043b\u043e\u043c CVSS 10.\n\n#\u0411\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c #Linux #CVE2024_3094 @SecLabNews", "creation_timestamp": "2024-04-01T07:31:55.000000Z"}, {"uuid": "3134f399-10f8-4f2b-adec-f3a4d9f7d937", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cultofwire/1341", "content": "CVE-2025-31115: XZ Utils Hit Again with High-Severity Multithreaded Decoder Bug\n\n\u0421\u043a\u0443\u0447\u0430\u043b\u0438 \u043f\u043e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044f\u043c \u0432 XZ Utils? \u0418\u0445 \u0435\u0441\u0442\u044c \u0443 \u043c\u0435\u043d\u044f.\n\n\u0412 \u043d\u043e\u0432\u043e\u0441\u0442\u044f\u0445 \u0441\u0435\u0433\u043e\u0434\u043d\u044f XZ Utils \u0438 \u0441\u043d\u043e\u0432\u0430 CVE \u0432 \u043d\u0451\u043c: CVE-2025-31115 c CVSS: 8.7. CVE-2025-31115 \u0437\u0430\u0442\u0440\u0430\u0433\u0438\u0432\u0430\u0435\u0442 \u0432\u0435\u0440\u0441\u0438\u0438 XZ Utils \u0441 5.3.3alpha \u043f\u043e 5.8.0, \u043f\u0440\u0438\u0432\u043e\u0434\u044f \u043a \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0439 \u043e\u0448\u0438\u0431\u043a\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u0443\u0447\u0438 \u043f\u043e\u0441\u043b\u0435 \u043e\u0441\u0432\u043e\u0431\u043e\u0436\u0434\u0435\u043d\u0438\u044f \u0432 \u0435\u0435 \u043c\u043d\u043e\u0433\u043e\u043f\u043e\u0442\u043e\u0447\u043d\u043e\u043c \u0434\u0435\u043a\u043e\u0434\u0435\u0440\u0435, \u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0439 \u0432\u044b\u0437\u044b\u0432\u0430\u0442\u044c \u0441\u0431\u043e\u0438 \u0438\u043b\u0438 \u043f\u043e\u0432\u0440\u0435\u0436\u0434\u0435\u043d\u0438\u0435 \u043f\u0430\u043c\u044f\u0442\u0438, \u0447\u0442\u043e \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u0442 \u043a \u043d\u0435\u043f\u0440\u0435\u0434\u0441\u043a\u0430\u0437\u0443\u0435\u043c\u043e\u043c\u0443 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u044b \u0438\u043b\u0438 \u0434\u0430\u0436\u0435 \u043a \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430.\n\n\u0418\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u044d\u0442\u043e\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0443\u0436\u0435 \u0432\u044b\u0448\u043b\u043e. \u0412\u0435\u0440\u0441\u0438\u044f XZ Utils 5.8.1 \u0443\u0441\u0442\u0440\u0430\u043d\u044f\u0435\u0442 \u044d\u0442\u0443 \u043e\u0448\u0438\u0431\u043a\u0443. \u0418\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0442\u0430\u043a\u0436\u0435 \u0431\u044b\u043b\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u043e \u043a \u0432\u0435\u0442\u043a\u0430\u043c v5.4, v5.6, v5.8 \u0438 master \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u044f xz Git.\n\n\u041d\u0435 \u0442\u0430\u043a \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u043e (\u0434\u0430 \u0438 EPSS \u043f\u043e\u043a\u0430 0.05), \u043a\u0430\u043a CVE-2024-3094 (\u0435\u0441\u043b\u0438 \u043a\u0442\u043e \u0437\u0430\u0431\u044b\u043b \u0441\u0442\u0430\u0442\u044c\u0438 \u043d\u0430 Wikipedia \u0438 Akamai), \u043d\u043e \u043b\u0443\u0447\u0448\u0435 \u043d\u0435 \u0437\u0430\u0442\u044f\u0433\u0438\u0432\u0430\u0442\u044c \u0441 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435\u043c.", "creation_timestamp": "2025-04-07T11:18:55.000000Z"}, {"uuid": "a96866d3-cc07-455c-b1f8-0d0296a9d6e1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cultofwire/1273", "content": "The Hidden Economy of Open Source Software\n\n\u041a Open Source \u043d\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043f\u043e\u0434\u0441\u0447\u0451\u0442\u0430 \u0446\u0435\u043d\u043d\u043e\u0441\u0442\u0438 (\u0443\u043c\u043d\u043e\u0436\u0435\u043d\u0438\u0435 \u0446\u0435\u043d\u044b \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043d\u043d\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e), \u0438 \u0432\u0441\u0435\u0433\u043e 5% \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 OSS \u043e\u0442\u0432\u0435\u0447\u0430\u044e\u0442 \u0437\u0430 96% \u0435\u0433\u043e \u0441\u0442\u043e\u0438\u043c\u043e\u0441\u0442\u0438.\n\n\u041d\u0435\u0434\u0430\u0432\u043d\u0435\u0435 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0431\u044d\u043a\u0434\u043e\u0440\u0430 \u0432 XZ Utils (CVE-2024-3094), \u0443\u0442\u0438\u043b\u0438\u0442\u0435 \u0441\u0436\u0430\u0442\u0438\u044f \u0434\u0430\u043d\u043d\u044b\u0445, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u043e\u0439 \u0448\u0438\u0440\u043e\u043a\u0438\u043c \u0441\u043f\u0435\u043a\u0442\u0440\u043e\u043c \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043a\u043e\u043c\u043f\u044c\u044e\u0442\u0435\u0440\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u043d\u0430 \u0431\u0430\u0437\u0435 Linux, \u043f\u043e\u0434\u0447\u0435\u0440\u043a\u0438\u0432\u0430\u0435\u0442 \u0432\u0430\u0436\u043d\u043e\u0441\u0442\u044c \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c. \u0425\u043e\u0442\u044f \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0435 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u0447\u0430\u0441\u0442\u043e \u043d\u0435 \u043e\u0440\u0438\u0435\u043d\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043e \u043d\u0430 \u043f\u043e\u0442\u0440\u0435\u0431\u0438\u0442\u0435\u043b\u044f, \u043e\u043d\u043e \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0430\u0436\u043d\u0435\u0439\u0448\u0438\u043c \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u043c \u0432\u044b\u0447\u0438\u0441\u043b\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0445, \u0442\u0430\u043a\u0438\u0445 \u043a\u0430\u043a \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u0430\u044f \u0441\u0432\u044f\u0437\u044c \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0448\u0438\u043d\u0430\u043c\u0438.\n\n\u041f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0435 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u0441\u0442\u0430\u043b\u043e \u043a\u0440\u0430\u0435\u0443\u0433\u043e\u043b\u044c\u043d\u044b\u043c \u043a\u0430\u043c\u043d\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u0438, \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u044f \u0432\u043b\u0438\u044f\u043d\u0438\u0435 \u043d\u0430 \u0432\u0441\u0435: \u043e\u0442 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0441\u0442\u0430\u0440\u0442\u0430\u043f\u043e\u0432 \u0434\u043e \u0433\u043b\u043e\u0431\u0430\u043b\u044c\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0439. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u043f\u043e\u0432\u0441\u0435\u043c\u0435\u0441\u0442\u043d\u043e\u0435 \u043f\u0440\u0438\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u0435 \u0438 \u043e\u0441\u043d\u043e\u0432\u043e\u043f\u043e\u043b\u0430\u0433\u0430\u044e\u0449\u0443\u044e \u0440\u043e\u043b\u044c \u0432 \u043f\u0440\u043e\u0434\u0432\u0438\u0436\u0435\u043d\u0438\u0438 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u0439, \u0438\u0441\u0442\u0438\u043d\u043d\u0430\u044f \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0446\u0435\u043d\u043d\u043e\u0441\u0442\u044c OSS \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0441\u0442\u0430\u0432\u0430\u043b\u0430\u0441\u044c \u043d\u0435\u0438\u0437\u0432\u0435\u0434\u0430\u043d\u043d\u043e\u0439 \u0442\u0435\u0440\u0440\u0438\u0442\u043e\u0440\u0438\u0435\u0439.\n\u041d\u043e \u0442\u0430\u043a \u043a\u0430\u043a \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u043d\u0430\u0441\u0443\u0449\u043d\u0430\u044f, \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0413\u0430\u0440\u0432\u0430\u0440\u0434\u0441\u043a\u043e\u0439 \u0448\u043a\u043e\u043b\u044b \u0431\u0438\u0437\u043d\u0435\u0441\u0430 \u041c\u0430\u043d\u0443\u044d\u043b\u044c \u0425\u043e\u0444\u0444\u043c\u0430\u043d\u043d, \u0424\u0440\u044d\u043d\u043a \u041d\u044d\u0433\u043b \u0438 \u042f\u043d\u0443\u043e \u0427\u0436\u043e\u0443 \u043f\u0440\u043e\u0432\u0435\u043b\u0438 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0435\u043c\u0443 \u0432\u043b\u0438\u044f\u043d\u0438\u044f Open Source \u043d\u0430 \u043e\u0442\u0440\u0430\u0441\u043b\u044c.\n\n\u0422\u0435\u043a\u0441\u0442 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f The Value of Open Source Software \u0432 pdf.", "creation_timestamp": "2024-05-15T11:04:53.000000Z"}, {"uuid": "fb9aa3ed-2c30-4d69-ab46-890884bec872", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/cultofwire/1353", "content": "Fifty Years of Open Source Software Supply Chain Security\n\nTL;DR\n\u0420\u0430\u0441\u0441 \u041a\u043e\u043a\u0441 (\u044d\u043a\u0441-\u043b\u0438\u0434\u0435\u0440 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u043f\u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 Go) \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442 \u044d\u0432\u043e\u043b\u044e\u0446\u0438\u044e \u0443\u0433\u0440\u043e\u0437 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432 \u0446\u0435\u043f\u043e\u0447\u043a\u0435 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a \u043e\u0442\u043a\u0440\u044b\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0437\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 50 \u043b\u0435\u0442. \u041e\u043d \u0441\u0440\u0430\u0432\u043d\u0438\u0432\u0430\u0435\u0442 \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0438 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u044b, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u0434\u0447\u0435\u0440\u043a\u043d\u0443\u0442\u044c \u043d\u0435\u0438\u0437\u043c\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0444\u0443\u043d\u0434\u0430\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438.\u200b\n\n\u0412 \u043c\u0430\u0440\u0442\u0435 \u0434\u0430\u043b\u0451\u043a\u043e\u0433\u043e 1972 \u0433\u043e\u0434\u0430, \u0412\u0412\u0421 \u0421\u0428\u0410 \u043d\u0430\u0447\u0430\u043b\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0443 \u0441\u0438\u0441\u0442\u0435\u043c\u044b Honeywell Multics, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c, \u043c\u043e\u0436\u043d\u043e \u043b\u0438 \u0435\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0432 \u0437\u0430\u0449\u0438\u0449\u0435\u043d\u043d\u044b\u0445 \u0441\u0440\u0435\u0434\u0430\u0445. \u041e\u0442\u0447\u0435\u0442 \u0431\u044b\u043b \u0432\u044b\u043f\u0443\u0449\u0435\u043d \u0432 \u0441\u0435\u0440\u0435\u0434\u0438\u043d\u0435 1974 \u0433\u043e\u0434\u0430, \u0433\u0434\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u043f\u0440\u0438\u0448\u043b\u0438 \u043a \u0432\u044b\u0432\u043e\u0434\u0443, \u0447\u0442\u043e Multics, \u0445\u043e\u0442\u044c \u0438 \u043d\u0435 \u0437\u0430\u0449\u0438\u0449\u0435\u043d \u043b\u0443\u0447\u0448\u0435 \u0441\u0432\u043e\u0438\u0445 \u0430\u043d\u0430\u043b\u043e\u0433\u043e\u0432, \u043d\u043e \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0440\u0430\u0437\u0443\u043c\u043d\u043e\u0439 \u043e\u0442\u043f\u0440\u0430\u0432\u043d\u043e\u0439 \u0442\u043e\u0447\u043a\u043e\u0439 \u0434\u043b\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0437\u0430\u0449\u0438\u0449\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u0412 \u043e\u0442\u0447\u0435\u0442\u0435 \u0433\u043e\u0432\u043e\u0440\u0438\u043b\u043e\u0441\u044c \u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0431\u044d\u043a\u0434\u043e\u0440\u0430 \u0432 \u043d\u0435\u0432\u0438\u043d\u043d\u044b\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0432\u044b\u0437\u043e\u0432. \u041f\u0440\u0438 \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0435 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0433\u043e, \u043e\u0447\u0435\u043d\u044c \u043c\u0430\u043b\u043e\u0432\u0435\u0440\u043e\u044f\u0442\u043d\u043e\u0433\u043e \u0432\u0445\u043e\u0434\u043d\u043e\u0433\u043e \u0441\u0438\u0433\u043d\u0430\u043b\u0430 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u0432\u044b\u0437\u043e\u0432 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u043b \u0447\u0438\u0442\u0430\u0442\u044c \u0438\u043b\u0438 \u0437\u0430\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u043e\u0435 \u0441\u043b\u043e\u0432\u043e \u0438\u0437 \u043f\u0430\u043c\u044f\u0442\u0438 \u044f\u0434\u0440\u0430. \u042d\u0442\u043e \u043a\u0440\u043e\u0448\u0435\u0447\u043d\u043e\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u043e\u0434\u0440\u044b\u0432\u0430\u043b\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0438 \u0432 \u043e\u0442\u0447\u0435\u0442\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043b\u0430\u0441\u044c \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0430 \u0442\u043e\u0433\u043e, \u043a\u0430\u043a \u0442\u0430\u043a\u043e\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0441\u0434\u0435\u043b\u0430\u043d\u043e \u0438 \u0441\u043a\u0440\u044b\u0442\u043e.\n\u0418 \u044d\u0442\u043e\u0442 \u043e\u0442\u0447\u0451\u0442 \u043c\u043e\u0436\u043d\u043e \u0441\u0447\u0438\u0442\u0430\u0442\u044c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u043e\u0439 \u043e\u0442\u043f\u0440\u0430\u0432\u043d\u043e\u0439 \u0442\u043e\u0447\u043a\u043e\u0439 \u0432 \u043c\u0438\u0440\u0435 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0446\u0435\u043f\u043e\u0447\u043a\u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a.\n\n\u0422\u0430\u043a \u0436\u0435 \u043d\u0435 \u043e\u0431\u043e\u0448\u043b\u043e\u0441\u044c \u0438 \u0431\u0435\u0437 \u0443\u043f\u043e\u043c\u0438\u043d\u0430\u043d\u0438\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 liblzma\\xz (CVE-2024-3094), \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u044f\u0440\u043a\u0438\u043c \u043f\u0440\u0438\u043c\u0435\u0440\u043e\u043c \u0430\u0442\u0430\u043a\u0438 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a \u0437\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u0433\u043e\u0434\u044b.\n\n\u0422\u0435\u0437\u0438\u0441\u043d\u043e:\n- \u0417\u0430 50 \u043b\u0435\u0442 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u043d\u0435 \u0440\u0435\u0448\u0438\u043b\u0430\u0441\u044c \u0441\u0430\u043c\u0430 \u0441\u043e\u0431\u043e\u0439 \u0438 \u0441\u0442\u0430\u043b\u0430 \u0442\u043e\u043b\u044c\u043a\u043e \u0430\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u0435\u0439.\n- \u0420\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e\u0435 \u0441\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u043d\u0430\u043b\u0438\u0447\u0438\u0435 \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0445 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0438 \u043f\u043e\u0438\u0441\u043a \u043d\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0445 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u043d\u0443\u0436\u043d\u044b \u0438 \u0432\u0430\u0436\u043d\u044b.\n- \u041f\u0440\u0435\u0434\u043e\u0442\u0432\u0440\u0430\u0449\u0435\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432\u043a\u043b\u044e\u0447\u0430\u0435\u0442 \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0435 \u043d\u0435\u043d\u0443\u0436\u043d\u044b\u0445 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0435\u0439, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u044b\u0445 \u044f\u0437\u044b\u043a\u043e\u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0438 \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c.\n- \u0421\u0442\u043e\u0438\u0442 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u041f\u041e.\n- \u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0446\u0438\u0444\u0440\u043e\u0432\u044b\u0445 \u043f\u043e\u0434\u043f\u0438\u0441\u0435\u0439 \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 \u0446\u0435\u043b\u043e\u0441\u0442\u043d\u043e\u0441\u0442\u0438 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0442\u043e\u0436\u0435 \u0445\u043e\u0440\u043e\u0448\u0435\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435.", "creation_timestamp": "2025-04-25T12:13:04.000000Z"}, {"uuid": "19ee58eb-b619-44ac-804a-dc19895001c8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/thebugbountyhunter/8552", "content": "XZ Utils CVE-2024-3094: A Tale of Broken Trust, Curious Persistence, and a Call to Action\n\nhttps://www.hackerone.com/vulnerability-management/cve-2024-3094", "creation_timestamp": "2024-04-08T10:45:24.000000Z"}, {"uuid": "e26a7385-76e5-494b-9d7d-5d46c4b3355e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/Russian_OSINT/3927", "content": "\ud83d\ude15 \u0412 \u043d\u0430\u0431\u043e\u0440 \u0443\u0442\u0438\u043b\u0438\u0442 XZ Utils \u0431\u044b\u043b \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d \u0431\u044d\u043a\u0434\u043e\u0440, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u043e\u043f\u0430\u043b \u0432 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 Linux\n\n\u0421\u043e\u043e\u0431\u0449\u0430\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043d\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0435 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u0438 \u0432\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0439 \u043a\u043e\u0434 \u0432 \u043d\u0430\u0431\u043e\u0440 \u0443\u0442\u0438\u043b\u0438\u0442 \u0434\u043b\u044f \u043a\u043e\u043c\u043f\u0440\u0435\u0441\u0441\u0438\u0438 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c XZ Utils \u0432\u0435\u0440\u0441\u0438\u0439 5.6.0 \u0438 5.6.1. \u0427\u0442\u043e \u0435\u0449\u0435 \u0445\u0443\u0436\u0435, \u0443\u0442\u0438\u043b\u0438\u0442\u044b \u0441 \u0431\u044d\u043a\u0434\u043e\u0440\u043e\u043c \u0443\u0441\u043f\u0435\u043b\u0438 \u043f\u043e\u043f\u0430\u0441\u0442\u044c \u0432 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043c\u0430\u0440\u0442\u043e\u0432\u0441\u043a\u0438\u0445 \u0441\u0431\u043e\u0440\u043e\u043a Linux, \u0442\u0430\u043a \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u0443\u044e \u0437\u0430\u043a\u043b\u0430\u0434\u043a\u0443 \u043c\u043e\u0436\u043d\u043e \u0440\u0430\u0441\u0446\u0435\u043d\u0438\u0432\u0430\u0442\u044c \u043a\u0430\u043a \u0430\u0442\u0430\u043a\u0443 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a. \u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0431\u044b\u043b \u043f\u0440\u0438\u0441\u0432\u043e\u0435\u043d \u043d\u043e\u043c\u0435\u0440 CVE-2024-3094.\n\n\ud83d\udc69\u200d\ud83d\udcbb\u041a\u0430\u043a\u0438\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 Linux \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u0442 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0435 \u0443\u0442\u0438\u043b\u0438\u0442\u044b, \u0430 \u043a\u0430\u043a\u0438\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u044b?\n\n\u0422\u043e\u0447\u043d\u043e \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u043e, \u0447\u0442\u043e XZ Utils \u0432\u0435\u0440\u0441\u0438\u0439 5.6.0 \u0438 5.6.1 \u043f\u043e\u043f\u0430\u043b\u0438 \u0432 \u043c\u0430\u0440\u0442\u043e\u0432\u0441\u043a\u0438\u0435 \u0441\u0431\u043e\u0440\u043a\u0438 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux:\n\n\u25aa\ufe0fKali Linux, \u043d\u043e \u043f\u043e \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0431\u043b\u043e\u0433\u0430, \u0442\u043e\u043b\u044c\u043a\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0435 \u043c\u0435\u0436\u0434\u0443 26 \u0438 29 \u043c\u0430\u0440\u0442\u0430 (\u0432 \u0431\u043b\u043e\u0433\u0435 \u0442\u0430\u043a\u0436\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u0442\u0441\u044f \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u0438 \u043f\u043e \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0435 \u043d\u0430 \u043d\u0430\u043b\u0438\u0447\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u0443\u0442\u0438\u043b\u0438\u0442);\n\u25aa\ufe0fopenSUSE Tumbleweed \u0438 openSUSE MicroOS, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0435 \u0441 7 \u043f\u043e 28 \u043c\u0430\u0440\u0442\u0430;\n\u25aa\ufe0fFedora 41, Fedora Rawhide \u0438 Fedora Linux 40 beta;\n\u25aa\ufe0fDebian (\u0442\u0435\u0441\u0442\u043e\u0432\u044b\u0435, \u043d\u0435\u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u044b\u0435 \u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438);\n\u25aa\ufe0fArch Linux \u2013 \u043e\u0431\u0440\u0430\u0437\u044b \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0435 \u043d\u0430\u0447\u0438\u043d\u0430\u044f \u0441 29 \u0444\u0435\u0432\u0440\u0430\u043b\u044f \u0438 \u0437\u0430\u043a\u0430\u043d\u0447\u0438\u0432\u0430\u044f 29 \u043c\u0430\u0440\u0442\u0430. \u0412\u043f\u0440\u043e\u0447\u0435\u043c, \u043d\u0430 \u0441\u0430\u0439\u0442\u0435 archlinux \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u0441\u044f, \u0447\u0442\u043e \u0438\u0437-\u0437\u0430 \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0435\u0439 \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0434\u0430\u043d\u043d\u044b\u0439 \u0432\u0435\u043a\u0442\u043e\u0440 \u0430\u0442\u0430\u043a\u0438 \u0432 Arch Linux \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0435 \u0431\u0443\u0434\u0435\u0442, \u043e\u0434\u043d\u0430\u043a\u043e \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u043d\u0430\u0441\u0442\u043e\u044f\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u044e\u0442 \u043e\u0431\u043d\u043e\u0432\u0438\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u0443.\n\n\ud83d\udee1\u041d\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u044b, \u043f\u043e \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise, openSUSE Leap, Debian Stable. \u041e\u0441\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u044b \u0438\u043c\u0435\u0435\u0442 \u0441\u043c\u044b\u0441\u043b \u0441\u0430\u043c\u043e\u0441\u0442\u043e\u044f\u0442\u0435\u043b\u044c\u043d\u043e \u043f\u0440\u043e\u0432\u0435\u0440\u044f\u0442\u044c \u043d\u0430 \u043d\u0430\u043b\u0438\u0447\u0438\u0435 \u0432 \u043d\u0438\u0445 \u0442\u0440\u043e\u044f\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432\u0435\u0440\u0441\u0438\u0439 XZ Utils.\n\n\ud83e\udd16 \u0420\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u0435\u0442\u0441\u044f \u0432\u0441\u0435\u043c \u043e\u0431\u043d\u043e\u0432\u0438\u0432\u0448\u0438\u043c \u0437\u0430\u0442\u0440\u043e\u043d\u0443\u0442\u044b\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c \u0432 \u043c\u0430\u0440\u0442\u0435 \u043d\u0435\u0437\u0430\u043c\u0435\u0434\u043b\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043f\u0435\u0440\u0435\u0439\u0442\u0438 \u043a \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u043e\u043b\u0435\u0435 \u0440\u0430\u043d\u043d\u0435\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 XZ Utils (\u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a \u0432\u0435\u0440\u0441\u0438\u0438 5.4.6).\n\n\ud83d\ude0d \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435:\nhttps://www.kaspersky.ru/blog/cve-2024-3094-vulnerability-backdoor/37222\n\n\u270b @Russian_OSINT", "creation_timestamp": "2024-04-01T11:08:44.000000Z"}, {"uuid": "633ddfe6-31fb-4731-8796-c76bc10a648f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/CNArsenal/2233", "content": "https://github.com/amlweems/xzbot\n\nnotes, honeypot, and exploit demo for the xz backdoor (CVE-2024-3094)\n#github", "creation_timestamp": "2024-04-06T00:37:11.000000Z"}, {"uuid": "b38d4f91-c04c-44a2-9eae-9cf29a9a651b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/CNArsenal/2215", "content": "https://github.com/emirkmo/xz-backdoor-github\n\nHistory of commits related to the xz backdoor Discovered On March 29, 2024: CVE-2024-3094.\n#github #\u5206\u6790", "creation_timestamp": "2024-03-30T15:54:17.000000Z"}, {"uuid": "25c63c65-73c9-4449-8918-b3a7f2ca58fd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/CNArsenal/2223", "content": "https://github.com/lockness-Ko/xz-vulnerable-honeypot\n\nAn ssh honeypot with the XZ backdoor. CVE-2024-3094\n#github #tools", "creation_timestamp": "2024-04-20T16:11:25.000000Z"}, {"uuid": "2fc8890f-bdab-4fcc-a32d-869e7f6519d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "exploited", "source": "https://t.me/S_E_Reborn/4645", "content": "\u041f\u043e \u0441\u043b\u0435\u0434\u0430\u043c \u043d\u0430\u0448\u0443\u043c\u0435\u0432\u0448\u0435\u0439 \u0430\u0442\u0430\u043a\u0438 \u043d\u0430 \u0446\u0435\u043f\u043e\u0447\u043a\u0443 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a XZ Utils (CVE-2024-3094) \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Binarly \u0432\u044b\u043f\u0443\u0441\u0442\u0438\u043b\u0430 \u043e\u0431\u0449\u0435\u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0439 \u0441\u043a\u0430\u043d\u0435\u0440 \u0434\u043b\u044f \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0438\u043c\u043f\u043b\u0430\u043d\u0442\u0430\u0442\u0430 \u0432 \u043b\u044e\u0431\u043e\u043c \u0434\u0432\u043e\u0438\u0447\u043d\u043e\u043c \u0444\u0430\u0439\u043b\u0435 Linux.\n\n\u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u044b\u0439 \u0432 \u043e\u0441\u043d\u043e\u0432\u0443 \u0443\u0442\u0438\u043b\u0438\u0442\u044b \u043f\u043e\u0434\u0445\u043e\u0434 \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u043e\u0442 \u0442\u0435\u043a\u0443\u0449\u0438\u0445 \u043f\u0440\u043e\u0432\u0435\u0440\u043e\u043a, \u0432\u043a\u043b\u044e\u0447\u0430\u044e\u0449\u0438\u0445 \u0441\u043e\u043f\u043e\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0431\u0430\u0439\u0442\u043e\u0432\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u0432\u043d\u0435\u0441\u0435\u043d\u0438\u0435 \u0432 \u0447\u0435\u0440\u043d\u044b\u0439 \u0441\u043f\u0438\u0441\u043e\u043a \u0445\u044d\u0448\u0435\u0439 \u0444\u0430\u0439\u043b\u043e\u0432 \u0438 \u043f\u0440\u0430\u0432\u0438\u043b\u0430 YARA, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043b\u043e\u0436\u043d\u044b\u043c \u0441\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043d\u0438\u044f\u043c.\n\nBinarly \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0430 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0439 \u0441\u043a\u0430\u043d\u0435\u0440, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u0442 \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0430\u043d\u0430\u043b\u0438\u0437 \u0434\u0432\u043e\u0438\u0447\u043d\u044b\u0445 \u0444\u0430\u0439\u043b\u043e\u0432 \u0434\u043b\u044f \u0432\u044b\u044f\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0434\u0435\u043b\u043a\u0438 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u043e\u0432 \u0432 \u043a\u043e\u0441\u0432\u0435\u043d\u043d\u043e\u0439 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 GNU (IFUNC).\n\n\u0412 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043e\u043d \u0438\u0441\u0441\u043b\u0435\u0434\u0443\u0435\u0442 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u044b, \u043f\u043e\u043c\u0435\u0447\u0435\u043d\u043d\u044b\u0435 \u043a\u0430\u043a \u043f\u043e\u0434\u043e\u0437\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0438 \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0445 \u0440\u0435\u0437\u043e\u043b\u0432\u0435\u0440\u043e\u0432 IFUNC.\n\n\u0410\u0442\u0440\u0438\u0431\u0443\u0442 IFUNC \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440\u0430 GCC \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0432\u0435\u0440\u0441\u0438\u0439 \u043e\u0434\u043d\u043e\u0439 \u0438 \u0442\u043e\u0439 \u0436\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0437\u0430\u0442\u0435\u043c \u0432\u044b\u0431\u0438\u0440\u0430\u044e\u0442\u0441\u044f \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043a\u0440\u0438\u0442\u0435\u0440\u0438\u0435\u0432, \u0442\u0430\u043a\u0438\u0445 \u043a\u0430\u043a \u0442\u0438\u043f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430.\n\n\u041e\u0434\u043d\u0438\u043c \u0438\u0437 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u0432, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u044b\u0445 \u0431\u044d\u043a\u0434\u043e\u0440\u043e\u043c XZ \u0434\u043b\u044f \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f \u043f\u0435\u0440\u0432\u043e\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f, \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0430\u0442\u0440\u0438\u0431\u0443\u0442 GNU Indirect Function (ifunc), \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0438\u0439 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440\u0443 GCC \u0440\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u043a\u043e\u0441\u0432\u0435\u043d\u043d\u044b\u0435 \u0432\u044b\u0437\u043e\u0432\u044b \u0444\u0443\u043d\u043a\u0446\u0438\u0439 \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f.\n\n\u0411\u044d\u043a\u0434\u043e\u0440 XZ \u0438\u0437\u043c\u0435\u043d\u044f\u0435\u0442 \u0432\u044b\u0437\u043e\u0432\u044b ifunc \u0434\u043b\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 is_arch_extension_supported, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u043b\u0436\u043d\u0430 \u043f\u0440\u043e\u0441\u0442\u043e \u0432\u044b\u0437\u044b\u0432\u0430\u0442\u044c cpuid \u0434\u043b\u044f \u0432\u0441\u0442\u0430\u0432\u043a\u0438 \u0432\u044b\u0437\u043e\u0432\u0430 _get_cpuid, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044d\u043a\u0441\u043f\u043e\u0440\u0442\u0438\u0440\u0443\u0435\u0442\u0441\u044f \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u043c \u0444\u0430\u0439\u043b\u043e\u043c \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 (\u0442.\u0435. liblzma_la-crc64-fast.o), \u0432\u044b\u0437\u044b\u0432\u0430\u044f \u0438\u0441\u043a\u0430\u0436\u0435\u043d\u043d\u044b\u0435 _get_cpuid().\n\n\u0411\u044d\u043a\u0434\u043e\u0440 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c, \u0438\u0437\u043c\u0435\u043d\u044f\u044f \u0432\u044b\u0437\u043e\u0432\u044b IFUNC \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u0430 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f, \u0447\u0442\u043e \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u0434\u0430.\n\n\u0423\u0442\u0438\u043b\u0438\u0442\u0430 Binarly \u0441\u043a\u0430\u043d\u0438\u0440\u0443\u0435\u0442 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0442\u043e\u0447\u043a\u0438 \u0446\u0435\u043f\u043e\u0447\u043a\u0438 \u043f\u043e\u0441\u0442\u0430\u0432\u043e\u043a, \u043f\u043e\u043c\u0438\u043c\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430 XZ Utils, \u0432 \u0441\u0432\u044f\u0437\u0438 \u0441 \u0447\u0435\u043c \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u044b \u0438\u043c\u0435\u044e\u0442 \u0433\u043e\u0440\u0430\u0437\u0434\u043e \u0431\u043e\u043b\u0435\u0435 \u0432\u044b\u0441\u043e\u043a\u0443\u044e \u0434\u043e\u0441\u0442\u043e\u0432\u0435\u0440\u043d\u043e\u0441\u0442\u044c.\n\n\u041e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u043e \u043d\u0430 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0447\u0435\u0441\u043a\u043e\u043c \u0430\u043d\u0430\u043b\u0438\u0437\u0435 \u0438 \u043c\u043e\u0436\u0435\u0442 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u043b\u044e\u0431\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b, \u0435\u0441\u043b\u0438 \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u044b\u0439 \u0431\u044d\u043a\u0434\u043e\u0440 \u0432\u043d\u0435\u0434\u0440\u0435\u043d \u0433\u0434\u0435-\u0442\u043e \u0435\u0449\u0435, \u0434\u0430\u0436\u0435 \u043f\u043e\u0441\u043b\u0435 \u043f\u0435\u0440\u0435\u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0446\u0438\u0438 \u0438\u043b\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u0434\u0430.\n\n\u0421\u043a\u0430\u043d\u0435\u0440 \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u043d\u0430 xz.fail, \u043a\u0443\u0434\u0430 \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0433\u0440\u0443\u0436\u0430\u0442\u044c \u0434\u0432\u043e\u0438\u0447\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 \u0431\u0435\u0437 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u0439 \u0438\u0445 \u0447\u0438\u0441\u043b\u0430.\n\n\u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, Binarly \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\u0430 \u043e\u0431\u0449\u0435\u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0439 API \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0431\u043e\u043b\u0435\u0435 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u043d\u043e\u0433\u043e \u0441\u043a\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f.", "creation_timestamp": "2024-04-03T18:49:22.000000Z"}, {"uuid": "622796aa-d5db-4698-bf75-21103d359b9a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/MuhammadAlush0997/82346", "content": "\u0627\u0644\u062b\u063a\u0631\u0629 \u0627\u0644\u062e\u0637\u064a\u0631\u0647 \u062d\u0627\u0644\u064a\u0627\u064b \u0644\u0623\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633 \n\n\u0645\u0633\u062a\u0648\u0649 \u062a\u0639\u0642\u064a\u062f \u0627\u0644\u0647\u062c\u0648\u0645 \u0644\u0647\u0627 XZ \u0645\u062b\u064a\u0631 \u0644\u0644\u0625\u0639\u062c\u0627\u0628 \u0644\u0644\u063a\u0627\u064a\u0629 \n\n\u0643\u0644 \u0634\u064a\u0621 \u064a\u0642\u0627\u0644 \u0648\u064a\u0644\u062e\u0635 \u0628\u0634\u0643\u0644 \u062c\u064a\u062f \u0647\u0646\u0627 \ud83d\udc46\n\u200e#xz \u200e#xzbackdoor CVE-2024-3094\n\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f\n\nt.me/MuhammadAlush0997\n\n\u062a\u0627\u0628\u0639\u0646\u064a \u0639\u0644\u0649 :\nTelegram | instagram | facebook | Twitter | YouTube", "creation_timestamp": "2024-04-01T04:05:59.000000Z"}, {"uuid": "4ca6406c-f84e-4042-9107-ef3ea65278db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "exploited", "source": "https://t.me/secinfosex/52", "content": "\u2b55\ufe0f CVE-2024-3094: \u0411\u0435\u043a\u0434\u043e\u0440 \u0432 \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0435 xz 5.6.0-5.6.1.\n\n\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u043d\u0435\u043f\u0440\u0438\u044f\u0442\u043d\u043e\u0435 - \u0441 \u043a\u043e\u043d\u0446\u0430 \u0444\u0435\u0432\u0440\u0430\u043b\u044f \u0432 \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u0430\u0440\u0438\u0439 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430 xz - The Tukaani Project -  \u0434\u043e\u0431\u0430\u0432\u0438\u043b\u0438 \u043d\u0435\u043f\u043b\u043e\u0445\u043e \u043e\u0431\u0444\u0443\u0441\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0431\u0435\u043a\u0434\u043e\u0440, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0435\u043a \u0432 \u043f\u0430\u043a\u0435\u0442\u044b \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u043e\u0432 Linux.\n\n\u0411\u0435\u043a\u0434\u043e\u0440 \u043d\u0430\u0448\u0435\u043b Andres Freund, \u043e\u0431\u0440\u0430\u0442\u0438\u0432 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u043d\u0430 \u0441\u0442\u0440\u0430\u043d\u043d\u043e\u0435 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435 ssh \u0432 \u0441\u0432\u043e\u0435\u043c Debian sid \u0434\u0438\u0441\u0442\u0440\u0435, \u0438 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u0442\u0435\u0441\u0442\u0430\u0445, \u0437\u0430 \u0447\u0442\u043e \u0435\u043c\u0443 \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0441\u043f\u0430\u0441\u0438\u0431\u043e.\n\n\u0421\u0430\u043c \u0431\u0435\u043a\u0434\u043e\u0440 \u0437\u0430\u0442\u0435\u0439\u043b\u0438\u0432\u044b\u0439, \u0441\u043e\u0441\u0442\u0430\u0432\u043d\u043e\u0439  - \u0437\u0430\u0441\u0443\u043d\u0443\u043b\u0438 \u0432 git \u0441\u0431\u043e\u0440\u043a\u0443 \u043c\u0430\u043a\u0440\u043e\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u0440\u0438 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043c\u043e\u0434\u0438\u0444\u0438\u0446\u0438\u0440\u0443\u0435\u0442 $builddir/src/liblzma/Makefile,  \u0434\u0430\u043b\u0435\u0435 \u0432\u044b\u0442\u0430\u0441\u043a\u0438\u0432\u0430\u0435\u0442 \u043f\u0435\u0439\u043b\u043e\u0430\u0434 \u0447\u0430\u0441\u0442\u044f\u043c\u0438 \u0438\u0437 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0431\u0438\u043d\u0430\u0440\u043d\u044b\u0445 \u0431\u043b\u043e\u0431\u043e\u0432, \u043f\u043e\u0434\u0441\u0443\u043d\u0443\u0442\u044b\u0445 \u0437\u0430\u0440\u0430\u043d\u0435\u0435 \u043a\u0430\u043a \u0430\u0440\u0445\u0438\u0432\u044b \u0434\u043b\u044f \u0442\u0435\u0441\u0442\u043e\u0432, \u0432\u043d\u0435\u0434\u0440\u044f\u0435\u0442\u0441\u044f \u0432 \u0441\u0431\u043e\u0440\u043a\u0443, \u0438 \u0432 \u0438\u0442\u043e\u0433\u0435 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0432\u0430\u0435\u0442 \u0441\u0435\u0431\u0435 \u0441\u0442\u0430\u0440\u0442 \u043d\u0430 \u0441\u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0435\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435. \n\n\u0411\u0435\u043a\u0434\u043e\u0440\u0430 \u0438 \u0440\u0435\u0432\u0435\u0440\u0441\u0430 \u043f\u043e\u043a\u0430 \u043d\u0435\u0442, \u043d\u043e \u043f\u043e \u043f\u0440\u0435\u0434\u0432\u0430\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u043c \u0434\u0430\u043d\u043d\u044b\u043c \u043e\u043d \u043a\u0430\u043a-\u0442\u043e \u0432\u043b\u0438\u044f\u0435\u0442 \u043d\u0430 ssh, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044f \u0430\u0442\u0430\u043a\u0443\u044e\u0449\u0435\u043c\u0443 \u0437\u0430\u0439\u0442\u0438 \u043d\u0430 \u0432\u0430\u0448 \u0445\u043e\u0441\u0442 \u0432 \u043e\u0431\u0445\u043e\u0434 \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438.\n\n\u041f\u043e\u043a\u0430 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u043e \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u0435 \u043a\u043e\u0434\u0430 \u0432 Debian sid, Fedora 41/Fedora rawhide, Kali, OpenSUSE.\n\n\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e: \n\ud83d\udc49 https://www.openwall.com/lists/oss-security/2024/03/29/4\n\ud83d\udc49 https://boehs.org/node/everything-i-know-about-the-xz-backdoor", "creation_timestamp": "2024-03-30T05:39:08.000000Z"}, {"uuid": "f8360b33-ec2d-4fde-b172-383019648d4f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "exploited", "source": "https://t.me/MuhammadAlush0997/82333", "content": "\u062b\u063a\u0631\u0647 \u062e\u0637\u064a\u0631\u0647 \u062c\u062f\u0627\u064b #Backdoor \u0641\u064a \u0627\u063a\u0644\u0628 \u0627\u0646\u0638\u0645\u0647 #\u0644\u064a\u0646\u0643\u0633 \n\n\u0627\u0635\u062f\u0631\u062a RedHat \u062a\u062d\u0630\u064a\u0631 \u0628\u062e\u0635\u0648\u0635 \u0648\u062c\u0648\u062f \u0628\u0648\u0627\u0628\u0647 \u062e\u0644\u0641\u064a\u0629 ( Backdoor ) \u0645\u0632\u0631\u0648\u0639 \u0641\u064a \u0645\u0643\u062a\u0628\u0647 XZ Utils \u0627\u0644\u062e\u0627\u0635\u0647 \u0628\u0636\u063a\u0637 \u0627\u0644\u0645\u0644\u0641\u0627\u062a \u0627\u0644\u0645\u062b\u0628\u062a\u0647 \u0645\u0633\u0628\u0642\u0627\u064b \u0639\u0644\u0649 \u0627\u0644\u0643\u062b\u064a\u0631 \u0645\u0646 \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 \u0627\u0644\u0645\u0634\u0647\u0648\u0631\u0629.\n\u0627\u0644\u0628\u0648\u0627\u0628\u0629 \u0627\u0644\u062e\u0644\u0641\u064a\u0629 \u062a\u0645 \u0627\u062e\u0641\u0627\u0626\u0647\u0627 \u0628\u0637\u0631\u064a\u0642\u0647 \u0645\u0639\u0642\u062f\u0647 \u0641\u064a \u0627\u0644\u0643\u0648\u062f ( obfuscations ).\n\u062a\u0633\u0645\u062d \u0644\u0644\u0645\u062e\u062a\u0631\u0642 \u0628\u0627\u0644\u0648\u0635\u0648\u0644 \u0644\u0644\u0646\u0638\u0627\u0645 \u0645\u0646 \u062e\u0644\u0627\u0644 SSH\n\n\ud83d\udccc \u0645\u0633\u062a\u0648\u0649 \u0627\u0644\u062e\u0637\u0648\u0631\u0647 10\n\n\ud83d\udccc \u0631\u0642\u0645 \u0627\u0644\u062b\u063a\u0631\u0647 CVE-2024-3094\n\n\u0627\u0644\u0631\u0627\u0628\u0637 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-3094\n\n\u200f\u0628\u0648\u0627\u0628\u0629 \u062e\u0644\u0641\u064a\u0629 \u0641\u064a \u0627\u0646\u0638\u0645\u0629 \u0644\u064a\u0646\u0643\u0633\n\u0627\u0643\u062a\u0634\u0641 \u0627\u062d\u062f \u0628\u0627\u062d\u062b\u064a \u0627\u0644\u062b\u063a\u0631\u0627\u062a \u062b\u063a\u0631\u0629 \u0648\u0647\u064a \u0639\u0628\u0627\u0631\u0629 \u0639\u0646 \u0628\u0648\u0628\u0647 \u062e\u0644\u0641\u064a\u0629 \u0641\u064a XZ Utils \u0648\u0647\u064a \u0639\u0628\u0627\u0631\u0629 \u0639\u0646 \u0645\u0643\u062a\u0628\u0629 \u0645\u062a\u062e\u0635\u0635\u0629 \u0641\u064a \u0636\u063a\u0637 \u0627\u0644\u0645\u0644\u0641\u0627\u062a\u060c \u0648\u062a\u062a\u064a\u062d \u0627\u0644\u0628\u0648\u0627\u0628\u0629 \u0627\u0644\u062e\u0644\u0641\u064a\u0647 \u0644\u0644\u0645\u062e\u062a\u0631\u0642 \u0627\u0644\u0627\u062a\u0635\u0627\u0644 \u0628\u062c\u0647\u0627\u0632 \u0627\u0644\u0636\u062d\u064a\u0629 \u0639\u0646 \u0637\u0631\u064a\u0642 \u0628\u0631\u0648\u062a\u0648\u0643\u0648\u0644 SSH.\n\u0648\u0627\u0644\u062b\u063a\u0631\u0629 \u062a\u062d\u062a \u062a\u0643\u0648\u064a\u062f CVE-2024-3094 \u0648\u062a\u0645 \u062a\u0635\u0646\u064a\u0641\u0647\u0627 \u0643 10 \u0627\u0648 \u062e\u0637\u064a\u0631\u0629 \u0644\u0644\u063a\u0627\u064a\u0629.\n\u0637\u0628\u0639\u0627\u064b \u0643\u062b\u064a\u0631 \u0645\u0646 \u0646\u0633\u062e \u0644\u064a\u0646\u0643\u0633 \u0645\u0635\u0627\u0628\u0629 \u0628\u0647\u0630\u0647 \u0627\u0644\u062b\u063a\u0631\u0629 \u0628\u0645\u0627 \u0641\u064a\u0647\u0627 \u0643\u0627\u0644\u064a \u0644\u064a\u0646\u0643\u0633 \u0648 Opensuse \u0648\u0628\u0639\u0636 \u0646\u0633\u062e Debian \u0627\u0644\u0627\u062e\u062a\u0628\u0627\u0631\u064a\u0629.\n\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f\n\nt.me/MuhammadAlush0997\n\n\u062a\u0627\u0628\u0639\u0646\u064a \u0639\u0644\u0649 :\nTelegram | instagram | facebook | Twitter | YouTube", "creation_timestamp": "2024-03-30T23:59:53.000000Z"}, {"uuid": "447c7cac-9cb1-426f-b901-8fc5c7607b7a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/MuhammadAlush0997/82462", "content": "\u200f\u0627\u0630\u0627 \u0643\u0646\u062a \u062a\u0633\u062a\u062e\u062f\u0645 #Linux \u0648\u062a\u062d\u0628 \u062a\u062a\u0627\u0643\u062f \u0627\u0646\u0643 \u063a\u064a\u0631 \u0645\u0635\u0627\u0628 \u0628\u062b\u063a\u0631\u0629 \ud83d\udc48 CVE-2024-3094 \ud83d\udc49\n\n\u0627\u0633\u062a\u062e\u062f\u0645 \u0647\u0630\u0647 \u0627\u0644\u0627\u062f\u0627\u0629\nhttps://github.com/jfrog/cve-2024-3094-tools/tree/main/cve-2024-3094-detector\n\n\u062c\u0645\u064a\u0639 \u0627\u0644\u0623\u0648\u0627\u0645\u0631 \u0645\u0648\u062c\u0648\u062f\u0629 \u0641\u064a \u0627\u0644\u0635\u0648\u0631\u0629 \ud83d\udc46\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f\n\nt.me/MuhammadAlush0997\n\n\u062a\u0627\u0628\u0639\u0646\u064a \u0639\u0644\u0649 :\nTelegram | instagram | facebook | Twitter | YouTube", "creation_timestamp": "2024-04-05T03:09:34.000000Z"}, {"uuid": "f0ede033-a498-4e42-affb-fa662ab8e8fa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/CybNux/6121", "content": "\u0643\u0627\u0631\u062b\u0629 KaLi linux \u0627\u0644\u0645\u0639\u0631\u0636\u0629 \u0644\u062b\u063a\u0631\u0629 \u0623\u0645\u0646\u064a\u0629 XZ Utils (CVE-2024-3094) | \u062a\u062d\u062f\u064a\u062b \u0627\u0644\u0627\u0646!\n\nhttps://youtu.be/r10OuTdQnBo", "creation_timestamp": "2024-04-01T21:01:22.000000Z"}, {"uuid": "11ced70a-4cc6-47ac-9d23-8e472d5f1041", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/CyberSecurityTechnologies/10647", "content": "#tools\n#Blue_Team_Techniques\n1. MDE_Enum - tool to extract and display detailed information about Windows Defender exclusions and ASR rules\nhttps://github.com/0xsp-SRD/MDE_Enum\n2. CVE-2024-3094 (XZ Utils) Checker\nhttps://github.com/FabioBaroni/CVE-2024-3094-checker", "creation_timestamp": "2024-06-09T12:47:01.000000Z"}, {"uuid": "410f7397-ccd1-4200-b923-485a212544c5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/CybNux/6068", "content": "\u062b\u063a\u0631\u0629 \u062e\u0637\u064a\u0631\u0629 \u062c\u062f\u0627\u064b #Backdoor \u0641\u064a \u0627\u063a\u0644\u0628 \u0627\u0646\u0638\u0645\u0629 #\u0644\u064a\u0646\u0643\u0633 \n\n\u0627\u0635\u062f\u0631\u062a RedHat \u062a\u062d\u0630\u064a\u0631 \u0628\u062e\u0635\u0648\u0635 \u0648\u062c\u0648\u062f \u0628\u0648\u0627\u0628\u0647 \u062e\u0644\u0641\u064a\u0629 ( Backdoor ) \u0645\u0632\u0631\u0648\u0639 \u0641\u064a \u0645\u0643\u062a\u0628\u0629 XZ Utils \u0627\u0644\u062e\u0627\u0635\u0647 \u0628\u0636\u063a\u0637 \u0627\u0644\u0645\u0644\u0641\u0627\u062a \u0627\u0644\u0645\u062b\u0628\u062a\u0647 \u0645\u0633\u0628\u0642\u0627\u064b \u0639\u0644\u0649 \u0627\u0644\u0643\u062b\u064a\u0631 \u0645\u0646 \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0644\u064a\u0646\u0643\u0633 \u0627\u0644\u0645\u0634\u0647\u0648\u0631\u0629.\n\u0627\u0644\u0628\u0648\u0627\u0628\u0629 \u0627\u0644\u062e\u0644\u0641\u064a\u0629 \u062a\u0645 \u0627\u062e\u0641\u0627\u0626\u0647\u0627 \u0628\u0637\u0631\u064a\u0642\u0629 \u0645\u0639\u0642\u062f\u0647 \u0641\u064a \u0627\u0644\u0643\u0648\u062f ( obfuscations ).\n\u062a\u0633\u0645\u062d \u0644\u0644\u0645\u062e\u062a\u0631\u0642 \u0628\u0627\u0644\u0648\u0635\u0648\u0644 \u0644\u0644\u0646\u0638\u0627\u0645 \u0645\u0646 \u062e\u0644\u0627\u0644 SSH\n\n\ud83d\udccc \u0645\u0633\u062a\u0648\u0649 \u0627\u0644\u062e\u0637\u0648\u0631\u0629 10\n\n\ud83d\udccc \u0631\u0642\u0645 \u0627\u0644\u062b\u063a\u0631\u0647 CVE-2024-3094\n\n\u0627\u0644\u0631\u0627\u0628\u0637 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-3094\n\n\u3030\ufe0f\u2796\u2796\u2796\u2796\u2796\u2796\u3030\ufe0f", "creation_timestamp": "2024-03-30T23:57:30.000000Z"}, {"uuid": "8ba8d8f2-c9a4-428c-b846-98b85dd7be4e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://t.me/CybNux/6089", "content": "\ud83d\udfe5\ud83d\udfe7\ud83d\udfe8 \u062a\u0646\u0628\u064a\u0647:  \u0627\u0644\u0623\u062c\u0647\u0632\u0629 \u0648\u0627\u0644\u062e\u0648\u0627\u062f\u0645 \u0627\u0644\u062a\u064a \u062a\u0639\u0645\u0644 \u0639\u0644\u0649 \u0646\u0638\u0627\u0645 \u0627\u0644\u062a\u0634\u063a\u064a\u0644 Linux\n\u25fe\ufe0f \u0625\u0630\u0627 \u0643\u0627\u0646 \u062c\u0647\u0627\u0632\u0643 \u0627\u0644\u0634\u062e\u0635\u064a \u064a\u0639\u0645\u0644 \u0628\u0625\u062d\u062f\u0649 \u062a\u0648\u0632\u064a\u0639\u0627\u062a \u0646\u0638\u0627\u0645 \u0627\u0644\u062a\u0634\u063a\u064a\u0644 Linux \u0623\u0648 \u0643\u0646\u062a  \u0645\u0633\u0626\u0648\u0644\u0627\u064b \u0639\u0646 \u0625\u062f\u0627\u0631\u0629 \u062e\u0648\u0627\u062f\u0645 \u062a\u0639\u0645\u0644 \u0628\u0647\u0630\u0627 \u0627\u0644\u0646\u0638\u0627\u0645\u060c \u0641\u064a\u062c\u0628 \u0639\u0644\u064a\u0643 \u0627\u0644\u062a\u0623\u0643\u062f \u0645\u0646 \u0648\u062c\u0648\u062f \u0627\u0644\u0645\u0643\u062a\u0628\u0629 XZ Utils \u0641\u064a \u062c\u0647\u0627\u0632\u0643 \u0648\u0645\u0627 \u0647\u0648 \u0627\u0644\u0625\u0635\u062f\u0627\u0631 \u0627\u0644\u0630\u064a \u062a\u0639\u0645\u0644 \u0639\u0644\u064a\u0647\u060c \u0647\u0630\u0647 \u0627\u0644\u0645\u0643\u062a\u0628\u0629 \u0645\u062e\u062a\u0635\u0629 \u0628\u0625\u062f\u0627\u0631\u0629 \u0627\u0644\u0645\u0644\u0641\u0627\u062a \u0627\u0644\u0645\u0636\u063a\u0648\u0637\u0629 \u0648\u062a\u0645 \u0627\u0644\u0643\u0634\u0641 \u0645\u0624\u062e\u0631\u0627\u064b \u0639\u0646 \u0648\u062c\u0648\u062f \u062e\u0644\u0644 \u062e\u0637\u064a\u0631 \u062c\u062f\u0627\u064b \u0628\u0647\u0627 (CVSS 10.0) (CVE-2024-3094) \u064a\u0642\u0648\u0645 \u0628\u0641\u062a\u062d \u0628\u0648\u0627\u0628\u0629 \u062e\u0644\u0641\u064a\u0629 \u062f\u0627\u062e\u0644 \u0646\u0638\u0627\u0645 \u0627\u0644\u062a\u0634\u063a\u064a\u0644 \u0648\u062a\u0633\u0645\u062d \u0644\u0644\u0645\u0647\u0627\u062c\u0645\u064a\u0646 \u0639\u0628\u0631 \u0627\u0644\u0634\u0628\u0643\u0629 \u0645\u0646 \u062a\u062e\u0637\u064a \u0639\u0645\u0644\u064a\u0629 \u0627\u0644\u0645\u0635\u0627\u062f\u0642\u0629 \u0641\u064a \u0628\u0631\u062a\u0648\u0643\u0648\u0644 SSH \u0648\u0627\u0644\u0648\u0635\u0648\u0644 \u0644\u0644\u0646\u0638\u0627\u0645 \u0648\u0627\u0644\u0633\u064a\u0637\u0631\u0629 \u0639\u0644\u064a\u0647.\n\n\ud83d\udd34 \u0627\u0644\u0625\u0635\u062f\u0627\u0631\u0627\u062a \u0645\u0646 \u0627\u0644\u0645\u0643\u062a\u0628\u0629 XZ Utils \u0627\u0644\u0645\u0639\u0631\u0636\u0629 \u0644\u0647\u0630\u0627 \u0627\u0644\u062e\u0637\u0631 \u0647\u064a 5.6.0 \u0648 5.6.1 \n\n\ud83d\udd34 \u064a\u062a\u0645 \u0627\u0633\u062a\u0639\u0645\u0627\u0644 \u0647\u0630\u0647 \u0627\u0644\u0645\u0643\u062a\u0628\u0629 \u0641\u064a \u0628\u0639\u0636 \u062a\u0648\u0632\u064a\u0639\u0627\u062a Linux \u0645\u062b\u0644: Fedora \u060c Ubuntu \u060c Debian \u060c Arch \u060c CentOS \u060c openSUSE\n\n\ud83d\udca1\u062a\u0633\u062a\u0637\u064a\u0639 \u0627\u0644\u0643\u0634\u0641 \u0639\u0646 \u0631\u0642\u0645 \u0627\u0644\u0625\u0635\u062f\u0627\u0631 \u0639\u0646 \u0637\u0631\u064a\u0642 \u062a\u0646\u0641\u064a\u0630 \u0627\u0644\u0623\u0645\u0631: xz --version  \n\n\ud83d\udca1\u064a\u0646\u0635\u062d \u0628\u0634\u062f\u0629 \u0641\u064a \u062d\u0627\u0644 \u0648\u062c\u0648\u062f \u0627\u0644\u0625\u0635\u062f\u0627\u0631 \u0627\u0644\u0645\u062a\u0636\u0631\u0631 \u0628\u062c\u0647\u0627\u0632\u0643 \u0623\u0646 \u062a\u0642\u0648\u0645 \u0628\u062a\u063a\u064a\u064a\u0631\u0647 \u0627\u0644\u0649 \u0627\u0644\u0625\u0635\u062f\u0627\u0631 \u0627\u0644\u0642\u062f\u064a\u0645 5.4.5", "creation_timestamp": "2024-04-01T00:58:46.000000Z"}, {"uuid": "dc6ed78f-1d2f-489c-8c0a-2006bf143f3d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "published-proof-of-concept", "source": "https://t.me/LearnExploit/6428", "content": "CVE-2024-3094 - An ssh honeypot with the XZ backdoor. \n\nGithub\n\n#CVE #Honeypot #Backdoor \n\u2014\u2014\u2014\u2014\u2014\u2014\u200c\n0Day.Today\n@LearnExploit\n@Tech_Army", "creation_timestamp": "2024-03-31T15:46:39.000000Z"}, {"uuid": "7880397a-5e1c-420a-9a41-3b9b6c64c7a1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "exploited", "source": "https://t.me/club31337/1781", "content": "Backdoor in upstream xz/liblzma leading to ssh server compromise\n\nhttps://www.openwall.com/lists/oss-security/2024/03/29/4\n\nhttps://www.mend.io/blog/critical-backdoor-found-xz-utils-cve-2024-3094/", "creation_timestamp": "2024-11-11T01:56:44.000000Z"}, {"uuid": "7968811d-e963-4ab7-94d1-0dc317178063", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/hnws.bsky.social/post/3mlclqqb7tw2d", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094\ncomments \u00b7 posted on 2026.05.07 at 20:03:38 (c=0, p=6)", "creation_timestamp": "2026-05-08T01:36:36.230266Z"}, {"uuid": "af644b97-d065-4f89-969b-3e68c0da852c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/news.karthihegde.dev/post/3mlclybqw642j", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094\nDiscussion | hackernews | Author: foltik", "creation_timestamp": "2026-05-08T01:40:49.559341Z"}, {"uuid": "9110d2e5-d005-423c-af38-ae334930f0aa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/hackernewsbot.bsky.social/post/3mlcn2ptq7x2y", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094 | Discussion", "creation_timestamp": "2026-05-08T02:00:05.380520Z"}, {"uuid": "05ccbd77-db2f-4f35-8d97-8aec9977647d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/hnbot.gsuscs.xyz/post/3mlcn3g6zi22l", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094\n\nhttps://github.com/robertdfrench/ifuncd-up", "creation_timestamp": "2026-05-08T02:00:28.263357Z"}, {"uuid": "4bd19f60-d1f3-455d-9e10-8425053569b0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/betterhn20.e-work.xyz/post/3mlcpnyjqo524", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094 github.com/robertdfrenc... (news.ycombinator.com/item?id=4805...)", "creation_timestamp": "2026-05-08T02:46:39.536187Z"}, {"uuid": "e3e4f99e-7042-4c12-818e-58ca3c825983", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://bsky.app/profile/norviktech.bsky.social/post/3mlcxjdanbb2j", "content": "GNU IFUNC es un mecanismo utilizado en entornos de programaci\u00f3n que permite la selecci\u00f3n din\u00e1mica de funciones. Este sistema, aunque \u00fatil, puede ser explotado para introducir vulnerabilidades, como es el caso de CVE-2024-3094.\n\nhttps://norvik.tech/news/analisis-gnu-ifunc-cve-2024-3094", "creation_timestamp": "2026-05-08T05:07:12.746006Z"}, {"uuid": "b2b3a0ab-82a5-4eac-b674-3c100b69a967", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/dafu09.bsky.social/post/3mlcyjlf6x62y", "content": "(1/1) \ud83d\udce1 AI\u8d44\u8baf | Startup\n1. Komai\uff1a\u4e00\u6b3e\u503c\u5f97\u60a8\u559c\u7231\u7684\u4f18\u79c0 Matrix \u804a\u5929\u5e94\u7528\u7a0b\u5e8f\n2. GNU IFUNC \u662f CVE-2024-3094 \u80cc\u540e\u7684\u771f\u6b63\u7f6a\u9b41\u7978\u9996\n3. \u7814\u7a76\u663e\u793a\uff0c\u793e\u4ea4\u5a92\u4f53\u4e0a\u8d4c\u535a\u5e7f\u544a\u7684\u7537\u6027\u53d7\u4f17\u6570\u91cf\u662f\u5973\u6027\u7684\u4e24\u500d\u591a\n4. \u9ebb\u9189\u7684\u4eba\u7c7b\u6d77\u9a6c\u4f53\u7684\u53ef\u5851\u6027\u548c\u8bed\u8a00\n5. \u4e5f\u8bb8\u4f60\u6682\u65f6\u4e0d\u5e94\u8be5\u5b89\u88c5\u65b0\u8f6f\u4ef6\n\u6765\u81ea: Hacker News \u9996\u9875\n#Startup #AI #TechNews", "creation_timestamp": "2026-05-08T05:25:14.571595Z"}, {"uuid": "67f971f4-e200-496c-8633-fa1bbae1039f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/betterhn50.e-work.xyz/post/3mlcykyaj4t2m", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094 https://github.com/robertdfrench/ifuncd-up (https://news.ycombinator.com/item?id=48056749)", "creation_timestamp": "2026-05-08T05:26:02.087048Z"}, {"uuid": "4dd4d784-5b71-492f-a0c8-6c7a1c4914d4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/newsycombinatorbot.bsky.social/post/3mld4z63zu627", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094 (github.com)\n\nDiscussion | Main Link", "creation_timestamp": "2026-05-08T06:45:32.533067Z"}, {"uuid": "1349374c-e53e-4b23-b5b5-0b5e7631a1ad", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/airanked.bsky.social/post/3mldjqyqfpu2c", "content": "GNU IFUNC Vulnerability \u2014 Discover the truth behind CVE-2024-3094 and how GNU IFUNC puts your system at risk\n\nRead more \u2192", "creation_timestamp": "2026-05-08T10:33:37.243137Z"}, {"uuid": "70e0e88e-ce12-4727-b64d-29bc6b071e3e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/hn100.atproto.rocks/post/3mlds3gbj422g", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094\nhttps://github.com/robertdfrench/ifuncd-up\n\nhttps://news.ycombinator.com/item?id=48056749", "creation_timestamp": "2026-05-08T13:02:36.987430Z"}, {"uuid": "b3a7078c-630f-43bc-a355-c3b66506f349", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/hn-frontpage-bot.bsky.social/post/3mldsu4gfay2o", "content": "The xz-utils backdoor (CVE-2024-3094) highlights flaws in critical open-source software design, specifically the linking of OpenSSH with SystemD and the use of GNU IFUNC. The author argues IFUNC is a risky, poorly documented feature that enables supply-chain attacks.", "creation_timestamp": "2026-05-08T13:16:25.580376Z"}, {"uuid": "5603cb7f-4d1a-41a2-9a1e-bc272335356e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/KenjiChao/1465c2c18cbbe15292982308ca2ac678", "content": "# \ud83d\uddde\ufe0f AI \u8207\u79d1\u6280\u65e5\u5831 2026/05/08\uff08\u9031\u4e94\uff09| \u77fd\u8c37\u8f15\u9b06\u8ac7\n\n> \u904e\u53bb 24 \u5c0f\u6642\u6700\u503c\u5f97\u95dc\u6ce8\u7684 AI \u8207\u79d1\u6280\u65b0\u805e\uff0c\u5f9e\u7522\u54c1\u767c\u8868\u3001\u5b89\u5168\u4e8b\u4ef6\u5230\u6df1\u5ea6\u601d\u8fa8\u90fd\u6536\u9032\u4f86\u3002\n\n---\n\n## 1. Mozilla \u7528 Claude Mythos \u627e\u51fa Firefox \u6578\u767e\u500b\u6f0f\u6d1e\uff0cAI \u81ea\u52d5\u627e\u87f2\u8de8\u904e\u5546\u696d\u53ef\u7528\u9580\u6abb\n\nMozilla \u63ed\u9732\uff1a\u5728 Bug Bounty \u8a08\u756b\u4e2d\u5c0e\u5165 Anthropic Claude Mythos Preview \u5f8c\uff0c2026 \u5e74 4 \u6708\u55ae\u6708\u4fee\u88dc\u7684 Firefox \u5b89\u5168\u6f0f\u6d1e\u6578\u5f9e 2025 \u5e74\u6bcf\u6708 20\u201330 \u500b\u66b4\u589e\u5230 **423 \u500b**\u2014\u2014\u5176\u4e2d\u5305\u542b\u4e00\u500b\u85cf\u4e86 20 \u5e74\u7684 XSLT bug\u3001\u4e00\u500b\u85cf\u4e86 15 \u5e74\u7684 element bug\uff0c\u800c\u4e14\u300c\u5e7e\u4e4e\u6c92\u6709\u8aa4\u5831\u300d\u3002Mozilla \u7528\u4e86\u4e00\u53e5\u5f88\u91cd\u7684\u8a71\uff1a\u300c\u9451\u65bc\u8b70\u984c\u7684\u975e\u51e1\u95dc\u6ce8\u5ea6\u8207\u6574\u500b\u8edf\u9ad4\u751f\u614b\u7cfb\u6240\u9700\u7684\u7dca\u8feb\u884c\u52d5\uff0c\u6211\u5011\u505a\u51fa\u8a08\u7b97\u5f8c\u7684\u6c7a\u5b9a\uff0c\u63d0\u524d\u516c\u958b\u90e8\u5206\u4fee\u88dc\u5831\u544a\u3002\u300d\n\n\u9019\u4e0d\u53ea\u662f\u4e00\u500b\u5de5\u5177\u793a\u7bc4\u3002Simon Willison \u5f62\u5bb9\u300c\u5e7e\u500b\u6708\u524d AI \u5b89\u5168\u5831\u544a\u9084\u662f\u5783\u573e\uff0c\u73fe\u5728 dynamic \u5b8c\u5168\u8b8a\u4e86\u300d\u3002\u5f8c\u7e8c\u6e2c\u8a66\u986f\u793a GPT-5.5 \u5728\u540c\u985e\u4efb\u52d9\u4e0a\u4e5f\u5c55\u73fe\u76f8\u4f3c\u80fd\u529b\u2014\u2014\u9019\u610f\u5473\u8457\u5b83\u4e0d\u662f\u55ae\u4e00\u6a21\u578b\u7684\u5076\u767c\u7a81\u7834\uff0c\u800c\u662f\u696d\u754c\u6574\u9ad4\u8df3\u8e8d\u3002\u5c0d\u61c9\u5230\u7522\u696d\u9762\uff0cOpenAI \u540c\u6b65\u63a8\u51fa\u9650\u91cf\u9810\u89bd\u7684 GPT-5.5-Cyber \u7d66\u6388\u6b0a\u7684\u7d05\u968a\uff0f\u6ef2\u900f\u6e2c\u8a66\u4f7f\u7528\uff0c\u4e26\u5411\u9632\u79a6\u7aef\u958b\u653e\u300cTrusted Access for Cyber\u300d\u3002\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- \u5982\u679c LLM \u627e\u6f0f\u6d1e\u8b8a\u6210\u6a19\u914d\uff0copen-source \u7dad\u8b77\u8005\u7684\u4eba\u529b\u8d64\u5b57\u554f\u984c\u6703\u88ab\u7de9\u89e3\u9084\u662f\u52a0\u5287\uff1f\u56e0\u70ba\u653b\u64ca\u8005\u4e5f\u80fd\u7528\u540c\u4e00\u5957\u5de5\u5177\u53cd\u5411 weaponize\u3002\n- \u300c20 \u5e74\u7684 XSLT bug\u300d\u8aaa\u660e\u904e\u53bb\u4eba\u985e\u5be9\u8a08\u7684\u8996\u91ce\u76f2\u5340\u6709\u591a\u5927\u2014\u2014\u9019\u5c0d\u6240\u6709\u5927\u578b legacy codebase\uff08Linux kernel\u3001SQLite\u3001glibc\uff09\u7684\u610f\u7fa9\u662f\u4ec0\u9ebc\uff1f\n- GPT-5.5-Cyber \u7684\u300c\u6388\u6b0a\u7d05\u968a\u9810\u89bd\u300d\u662f OpenAI \u7b2c\u4e00\u500b\u516c\u958b\u627f\u8a8d\u7684\u300c\u80fd\u529b\u5206\u5c64\u767c\u884c\u300d\u6848\u4f8b\uff0c\u672a\u4f86\u6703\u4e0d\u6703\u6709\u66f4\u591a\u5206\u7d1a\u8a2a\u554f\u6a21\u5f0f\uff1f\n- Mozilla \u9858\u610f\u63d0\u524d\u516c\u958b\u4fee\u88dc\u5831\u544a\uff0c\u80cc\u5f8c\u5176\u5be6\u662f\u627f\u8a8d\u300c\u6f0f\u6d1e\u7a97\u53e3\u6b63\u5728\u7e2e\u77ed\u300d\u2014\u2014\u653b\u9632\u7bc0\u594f\u88ab AI \u6574\u9ad4\u52a0\u901f\u3002\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://arstechnica.com/ai/\n- https://simonwillison.net/\n- https://news.smol.ai/\n\n---\n\n## 2. OpenAI \u5927\u7206\u767c\uff1aGPT-Realtime-2\u3001Codex Chrome\u3001GPT-5.5-Cyber\u3001Trusted Contact \u5b89\u5168\u6a5f\u5236\n\n\u904e\u53bb 24 \u5c0f\u6642 OpenAI \u4e00\u53e3\u6c23\u63a8\u4e86\u591a\u500b\u91cd\u8981\u7522\u54c1\uff1a**GPT-Realtime-2**\uff08GPT-5 \u7d1a\u63a8\u7406 + \u8a9e\u97f3\u3001Big Bench Audio \u62ff\u4e0b 96.6%\u3001Scale AI Audio MultiChallenge S2S \u7b2c\u4e00\uff09\u3001**GPT-Realtime-Translate**\uff0870+ \u8f38\u5165\u8a9e\u8a00\uff09\u3001**GPT-Realtime-Whisper**\uff08\u4f4e\u5ef6\u9072\u4e32\u6d41\u8f49\u5beb\uff09\uff0ccontext \u5f9e 32K \u76f4\u63a5\u62c9\u5230 128K\uff0c**\u50f9\u683c\u4e0d\u8b8a**\u3002\u540c\u6642 **Codex Chrome \u5916\u639b**\u4e0a\u67b6 macOS\uff0fWindows\uff0c\u53ef\u5728\u80cc\u666f\u591a\u5206\u9801\u540c\u6642\u904b\u4f5c\u9664\u932f\u3001CRM \u81ea\u52d5\u5316\u3001\u7814\u7a76\u7b49\u4efb\u52d9\u3002\n\n\u53e6\u4e00\u908a\uff0cOpenAI \u70ba ChatGPT \u65b0\u589e\u300c**Trusted Contact**\u300d\u81ea\u6b98\u9632\u8b77\u6a5f\u5236\uff0c\u7576\u7cfb\u7d71\u5224\u65b7\u4f7f\u7528\u8005\u53ef\u80fd\u6709\u81ea\u50b7\u98a8\u96aa\u6642\uff0c\u53ef\u4e3b\u52d5\u901a\u77e5\u9810\u5148\u8a2d\u5b9a\u7684\u89aa\u53cb\u3002\u9019\u662f\u7e7c Sam Altman \u88ab\u6307\u63a7\u672a\u901a\u5831\u6821\u5712\u69cd\u64ca\u9810\u8b66 ChatGPT \u4f7f\u7528\u8005\u5f8c\uff0cOpenAI \u5728\u5fc3\u7406\u5065\u5eb7\u8207\u5b89\u5168\u8cac\u4efb\u9762\u7684\u95dc\u9375\u56de\u61c9\u3002\u5167\u90e8\u7814\u7a76\u54e1 Micah Carroll \u4e5f\u5728 X \u4e0a\u900f\u9732\uff0c\u5148\u524d RL \u8a13\u7df4\u66fe\u610f\u5916\u5c07 CoT \u7d0d\u5165\u8a55\u5206\uff0c\u4f46\u300c\u6c92\u6709\u660e\u986f\u8b49\u64da\u300d\u7834\u58de CoT \u53ef\u76e3\u63a7\u6027\u2014\u2014\u76f4\u63a5\u6233\u4e2d Eliezer \u6d3e\u8207 e/acc \u6d3e\u7684\u8faf\u8ad6\u9ede\u3002\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- \u8a9e\u97f3 API context \u7ffb 4 \u500d\u4f46\u50f9\u683c\u4e0d\u8b8a\uff0c\u80cc\u5f8c\u7684\u6210\u672c\u7d50\u69cb\u6697\u793a\u4e86\u4ec0\u9ebc\uff1f\u662f\u6a21\u578b\u771f\u7684\u4fbf\u5b9c\u4e86\uff0c\u9084\u662f OpenAI \u5728\u6436\u596a\u8a9e\u97f3 agent \u7684\u5e02\u5834\u5165\u53e3\uff1f\n- Codex Chrome \u5728\u80cc\u666f\u591a\u5206\u9801\u904b\u4f5c\u7684 UX\uff0c\u662f\u4e0d\u662f\u300c\u500b\u4eba\u96fb\u8166\u5f9e\u4ee5\u4f7f\u7528\u8005\u70ba\u4e2d\u5fc3\uff0c\u8f49\u5411\u4ee5 agent \u70ba\u4e2d\u5fc3\u300d\u7684\u7b2c\u4e00\u500b\u91cf\u7522\u8de1\u8c61\uff1f\n- Trusted Contact \u662f AI \u7b2c\u4e00\u6b21\u300c\u4e3b\u52d5\u5728\u5fc3\u7406\u5065\u5eb7\u4ecb\u5165\u93c8\u4e2d\u626e\u6f14\u89d2\u8272\u300d\u2014\u2014\u9019\u689d\u7d05\u7dda\u8de8\u904e\u53bb\u4e4b\u5f8c\uff0c\u8cac\u4efb\u6b78\u5c6c\u6703\u8b8a\u5f97\u591a\u8907\u96dc\uff1f\n- \u300cRL \u628a CoT \u7d0d\u5165\u8a55\u5206\u300d\u9019\u4ef6\u4e8b\u5982\u679c\u5728\u66f4\u524d\u6cbf\u7684\u8a13\u7df4\u4e2d\u5df2\u7d93\u767c\u751f\uff0c\u610f\u5473 alignment \u76e3\u63a7\u6b63\u5728\u88ab\u9ed8\u9ed8\u4fb5\u8755\u3002\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://news.smol.ai/\n- https://techcrunch.com/category/artificial-intelligence/\n\n---\n\n## 3. Cloudflare \u88c1\u54e1 1,100 \u4eba\uff08\u7d04 20%\uff09\uff0c\u540c\u671f AI \u670d\u52d9\u4f7f\u7528\u91cf\u5e74\u589e 600%\n\nCloudflare \u540c\u6642\u91cb\u51fa Q1 2026 \u8ca1\u5831\u8207 1,100 \u4eba\u88c1\u54e1\uff08\u7d04\u4f54\u54e1\u5de5\u7e3d\u6578 20%\uff09\uff0c\u516c\u53f8 AI \u670d\u52d9\u4f7f\u7528\u91cf\u5e74\u589e **600%**\u3002CEO Matthew Prince \u5f37\u8abf\u9019\u300c\u4e0d\u662f\u524a\u6e1b\u6210\u672c\u300d\uff0c\u800c\u662f\u91cd\u65b0\u5b9a\u7fa9\u300c\u5728 Agentic AI \u6642\u4ee3\u5982\u4f55\u904b\u71df\u4e00\u5bb6\u4e16\u754c\u7d1a\u9ad8\u6210\u9577\u516c\u53f8\u300d\u3002\u5e02\u5834\u5c07\u5176\u89e3\u8b80\u70ba\u5927\u578b\u96f2\u670d\u52d9\u5546\u5728 AI \u91cd\u8cc7\u672c\u652f\u51fa\u5f8c\u7684\u6210\u672c\u7d50\u69cb\u8abf\u6574\uff0c\u4f46\u66f4\u523a\u773c\u7684\u89e3\u8b80\u662f\uff1a**\u5373\u4f7f\u71df\u6536\u6210\u9577\u5f37\u52c1\u7684\u516c\u53f8\uff0c\u4e5f\u9078\u64c7\u7528 AI \u91cd\u5851\u4eba\u529b\u7d50\u69cb**\u2014\u2014\u800c\u4e0d\u662f\u64f4\u7de8\u3002\n\nCloudflare \u4e0d\u662f\u5b64\u4f8b\u3002\u628a\u9019\u689d\u65b0\u805e\u548c\u8fd1\u671f\u4e00\u7cfb\u5217\u79d1\u6280\u88c1\u54e1\u653e\u5728\u4e00\u8d77\u770b\uff1aAWS\u3001Meta \u90fd\u5728\u904e\u53bb\u534a\u5e74\u505a\u904e\u985e\u4f3c\u52d5\u4f5c\uff0c\u4f46 Cloudflare \u662f\u5c11\u6578\u71df\u6536 200%+ \u7684\u9ad8\u6210\u9577\u516c\u53f8\u4e3b\u52d5\u88c1\u6e1b 20%\u3002\u9019\u500b\u8a0a\u865f\u6bd4\u4efb\u4f55 AI \u53d6\u4ee3\u8ad6\u6587\u90fd\u4f86\u5f97\u76f4\u767d\u3002\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- \u300c\u6210\u9577\u516c\u53f8\u4e5f\u88c1\u54e1\u300d\u662f 2026 \u5e74\u7684\u65b0\u5e38\u614b\u55ce\uff1f\u5c0d\u4e2d\u968e\u8edf\u9ad4\u5de5\u7a0b\u5e2b\u8077\u6daf\u8def\u5f91\u610f\u5473\u4ec0\u9ebc\uff1f\n- Cloudflare \u5ba2\u6236 AI \u670d\u52d9\u7528\u91cf +600% \u4f46\u8981\u88c1\u81ea\u5df1 20%\uff0c\u662f\u5426\u8aaa\u660e AI infra \u5ee0\u5546\u7684\u670d\u52d9\u300c\u908a\u969b\u6210\u672c\u300d\u5176\u5be6\u6b63\u5feb\u901f\u4e0b\u964d\uff0c\u4f46\u88ab\u5b9a\u50f9\u7d50\u69cb\u63a9\u84cb\uff1f\n- Prince \u7528\u300cAgentic AI \u6642\u4ee3\u300d\u7576\u7406\u7531\uff0c\u4f46\u5be6\u969b\u4e0a\u4fdd\u7559\u4e0b\u4f86\u7684 80% \u54e1\u5de5\u6703\u88ab\u600e\u6a23\u91cd\u65b0\u5206\u5de5\uff1f\u9019\u500b\u7b54\u6848\u53ef\u80fd\u6bd4\u88c1\u54e1\u672c\u8eab\u66f4\u503c\u5f97\u8ffd\u8e64\u3002\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://www.theverge.com/ai-artificial-intelligence\n- https://finance.yahoo.com/markets/stocks/articles/cloudflare-announces-first-quarter-2026-201500778.html\n- https://news.ycombinator.com/item?id=48055238\n\n---\n\n## 4. OpenAI \u7d42\u65bc\u5b8c\u6210 PBC \u91cd\u7d44\uff0c\u79fb\u9664\u6295\u8cc7\u4eba 100\u00d7 \u5831\u916c\u4e0a\u9650\uff1bMusk \u8a34\u8a1f\u63ed\u65b0\u8b49\u8a5e\n\nThe Batch Issue 326 \u5831\u5c0e\uff1aOpenAI \u5b8c\u6210\u5f9e\u975e\u71df\u5229\u8f49\u70ba **OpenAI Group PBC**\uff08\u516c\u76ca\u516c\u53f8\uff09\uff0c\u5fb9\u5e95\u79fb\u9664\u6295\u8cc7\u4eba 100\u00d7 \u5831\u916c\u4e0a\u9650\u3002\u57fa\u91d1\u6703\u4fdd\u7559 26%\uff08\u50f9\u503c\u7d04 $130B\uff09\uff0c\u5fae\u8edf\u62ff 27% \u4e26\u4fdd\u6709 2032 \u5e74\u524d\u7684 20% \u71df\u6536\u5206\u6f64\u6b0a\u3002\n\n\u5e7e\u4e4e\u540c\u6642\uff0cMusk vs Altman \u8a34\u8a1f\u65b0\u8b49\u8a5e\u66dd\u5149\uff1aMusk \u65e9\u5e74\u66fe\u5617\u8a66\u628a OpenAI \u5275\u8fa6\u5718\u968a\u6574\u6279\u6536\u7de8\u5230 Tesla \u65d7\u4e0b\u6210\u7acb AI \u90e8\u9580\uff0c\u689d\u4ef6\u662f\u300c\u4ed6\u53d6\u5f97\u63a7\u5236\u6b0a\u7684\u71df\u5229\u578b\u7d50\u69cb\u300d\u3002\u524d OpenAI \u8463\u4e8b Helen Toner \u4e5f\u4f5c\u8b49\u6307\u51fa\uff0c\u8463\u4e8b\u6703\u66fe\u5728\u300cThe Blip\u300d\u671f\u9593\uff082023 \u5e74 11 \u6708 Altman \u88ab\u89e3\u50f1\u4e8b\u4ef6\uff09\u8a0e\u8ad6\u8207 Anthropic \u5408\u4f75\u3001\u7531 Dario Amodei \u51fa\u4efb CEO\u3002\u9589\u5ead\u8faf\u8ad6\u9810\u8a08\u4e00\u9031\u5167\u5c55\u958b\uff0c\u5c07\u6df1\u523b\u5f71\u97ff OpenAI \u71df\u5229\u5316\u8f49\u578b\u7684\u5408\u6cd5\u6027\u3002\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- \u5982\u679c Musk \u7576\u5e74\u6210\u529f\uff0c\u4eca\u5929\u7684 AI \u683c\u5c40\u662f\u300cTesla AI\u300d\u5c0d\u6297\u300cAnthropic\u300d\u7684\u96d9\u5be1\u982d\uff0c\u9084\u662f\u6703\u66f4\u65e9\u88ab DeepMind \u62c9\u958b\uff1f\u53cd\u4e8b\u5be6\u975e\u5e38\u6709\u610f\u601d\u3002\n- $130B \u7684\u975e\u71df\u5229\u57fa\u91d1\u6703\u5728 PBC \u7d50\u69cb\u4e2d\u7a76\u7adf\u6709\u591a\u5c11\u5be6\u8cea\u6cbb\u7406\u6b0a\uff1f\u76f8\u5c0d\u65bc\u5fae\u8edf 27%\u3001\u54e1\u5de5\u80a1\u6b0a\uff0c\u9019\u7a2e\u300c\u7cbe\u795e\u4e0a\u7684\u76e3\u7763\u300d\u6703\u4e0d\u6703\u53ea\u662f\u516c\u95dc\u88dd\u98fe\uff1f\n- Toner \u8b49\u8a5e\u63ed\u9732 Anthropic \u5408\u4f75\u66fe\u88ab\u8a8d\u771f\u8a0e\u8ad6\uff0c\u610f\u5473\u524d\u6cbf\u5be6\u9a57\u5ba4\u4e4b\u9593\u7684\u6574\u4f75\u53ef\u80fd\u6027\u6bd4\u6211\u5011\u60f3\u50cf\u7684\u9ad8\uff0c\u800c\u4e0d\u662f\u4f4e\u3002\n- 100\u00d7 \u4e0a\u9650\u7684\u53d6\u6d88\u662f OpenAI \u6295\u8cc7\u4eba\u904a\u8aaa\u7684\u52dd\u5229\uff0c\u4f46\u6b77\u53f2\u6703\u5982\u4f55\u8a55\u50f9\u9019\u6b21\u300c\u4f7f\u547d\u6f02\u79fb\u300d\u7684\u95dc\u9375\u8f49\u6298\uff1f\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://www.deeplearning.ai/the-batch/issue-326/\n- https://arstechnica.com/ai/\n\n---\n\n## 5. \u958b\u6e90\u6a21\u578b\u5927\u7206\u70b8\uff1aMiniMax-M2\u3001ZAYA1-8B\uff08AMD \u8a13\u7df4\uff09\u3001Gemma 4 MTP\u3001IBM Granite 4.1\n\n\u904e\u53bb 24\u201348 \u5c0f\u6642\u958b\u6e90\u6a21\u578b\u9663\u71df\u6709\u56db\u500b\u91cd\u78c5\u767c\u5e03\uff0c\u758a\u52a0\u5728\u4e00\u8d77\u6539\u8b8a\u4e86\u591a\u500b\u6558\u4e8b\uff1a\n\n**MiniMax-M2**\uff08\u4e0a\u6d77 MiniMax \u958b\u6e90\uff0cMIT \u6388\u6b0a\uff0c230B/10B active MoE\uff0c$0.30/$1.20 \u6bcf\u767e\u842c token\uff09\u2014\u2014\u5728 Artificial Analysis \u667a\u6167\u6307\u6578\u62ff\u5230\u958b\u6e90\u6b0a\u91cd\u7b2c\u4e00\u540d\uff0861 \u5206\uff09\u3002**ZAYA1-8B**\uff08Zyphra\uff09\u2014\u2014\u662f\u9996\u500b\u5168\u7a0b\u65bc **AMD Instinct MI300** GPU \u8a13\u7df4\u7684\u524d\u6cbf\u6a21\u578b\uff0c\u6c92\u7528\u4efb\u4f55 Nvidia \u786c\u9ad4\uff1b\u9019\u662f AMD \u5728\u751f\u6210\u5f0f AI \u8a13\u7df4\u5e02\u5834\u6311\u6230 Nvidia \u58df\u65b7\u7684\u91cd\u8981\u91cc\u7a0b\u7891\u3002**Gemma 4 MTP**\uff08Google DeepMind\uff09\u2014\u2014Multi-Token Prediction \u5ba3\u7a31\u88dd\u7f6e\u7aef\u63a8\u7406\u901f\u5ea6\u6700\u9ad8 3 \u500d\uff0cRTX Pro 6000 + vLLM \u9054 129 tok/s\u3002**IBM Granite 4.1**\uff083B/8B/30B\uff0cApache 2.0\uff09\u2014\u2014Simon Willison \u5df2\u5be6\u6e2c\u3002\n\n\u4e2d\u570b\u65b0\u5275\u878d\u8cc7\u7aef\u4e5f\u5f88\u71b1\uff1a**Moonshot AI\uff08\u6708\u4e4b\u6697\u9762\uff09**\u5b8c\u6210 20 \u5104\u7f8e\u5143\u878d\u8cc7\u3001\u4f30\u503c\u885d\u4e0a 200 \u5104\u7f8e\u5143\uff1b**DeepSeek** \u9996\u8f2a\u878d\u8cc7\u4f30\u503c\u50b3\u51fa\u5c07\u9054 450 \u5104\u7f8e\u5143\u3002news.smol.ai \u540c\u671f\u6578\u64da\uff1a\u958b\u6e90\u6a21\u578b\u5df2\u5728 **Text Arena** \u8ffd\u5e73\u9589\u6e90\uff0c\u9589\u6e90\u9818\u5148\u7e2e\u81f3\u7d04 +30 \u5206\u3002\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- \u5982\u679c Text Arena \u7684 +30 \u5206\u5dee\u8ddd\u6301\u7e8c\u7e2e\u7a84\uff0c\u958b\u6e90 vs \u9589\u6e90\u7684\u300c\u80fd\u529b\u8b77\u57ce\u6cb3\u300d\u6703\u5728 2026 \u5e74\u6d88\u5931\u55ce\uff1f\u8b77\u57ce\u6cb3\u6703\u5f9e\u6a21\u578b\u672c\u8eab\u8f49\u79fb\u5230\u54ea\u88e1\uff08\u8cc7\u6599\u3001\u7522\u54c1\u5206\u767c\u3001agent infra\uff09\uff1f\n- ZAYA1-8B \u8b49\u660e AMD MI300 + ROCm \u5df2\u5177\u5099\u751f\u7522\u7d1a\u53ef\u7528\u6027\u2014\u2014\u5c0d Nvidia \u7684 75% \u6bdb\u5229\u6703\u6709\u4ec0\u9ebc\u7d50\u69cb\u6027\u885d\u64ca\uff1f\n- \u4e2d\u570b\u958b\u6e90\u6d3e\uff08DeepSeek\u3001MiniMax\u3001Moonshot\u3001Zhipu\uff09\u6b63\u4ee5\u300c\u7f8e\u570b\u8cc7\u672c\u4e0d\u80fd\u9032\u3001\u4f46\u5168\u7403\u90fd\u80fd\u7528\u300d\u7684\u7b56\u7565\u6436\u596a\u958b\u767c\u8005\u5fc3\u667a\uff0c\u9019\u5c0d\u7f8e\u4e2d AI \u653f\u7b56\u6703\u6709\u4ec0\u9ebc\u6b21\u7d1a\u5f71\u97ff\uff1f\n- MTP\uff08Multi-Token Prediction\uff09\u662f\u5426\u6703\u6210\u70ba\u4e0b\u4e00\u4ee3\u958b\u6e90\u6a21\u578b\u7684\u6a19\u914d\uff1f\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://www.deeplearning.ai/the-batch/issue-326/\n- https://venturebeat.com/category/ai/\n- https://news.smol.ai/\n- https://techcrunch.com/category/artificial-intelligence/\n\n---\n\n## 6. Anthropic Natural Language Autoencoders \u63ed\u793a\u6a21\u578b\u300c\u5167\u5728\u8a9e\u8a00\u300d\uff0c\u53ef\u89e3\u91cb\u6027\u7814\u7a76\u9032\u5165\u65b0\u968e\u6bb5\n\nAnthropic \u767c\u8868 **Natural Language Autoencoders (NLAs)**\uff1a\u628a\u6a21\u578b\u5167\u90e8 activations \u7ffb\u8b6f\u70ba\u4eba\u985e\u53ef\u8b80\u6587\u5b57\uff0c\u5354\u52a9\u89c0\u5bdf\u300c\u601d\u8003\u300d\u7684\u5167\u90e8\u8868\u5fb5\u3002\u958b\u6e90\u7248\u5df2\u4e0a\u67b6 Neuronpedia\u3002Ryan Greenblatt \u5728 X \u8cea\u7591\u55ae\u4e00 forward pass \u6578\u5b78\u984c\u4e0a\u4ecd\u7121\u6cd5\u9084\u539f\u5167\u90e8 CoT\u2014\u2014\u9019\u5728 alignment \u6d3e\u773c\u4e2d\u662f\u56b4\u91cd\u8b66\u8a0a\uff1a\u6a21\u578b\u53ef\u80fd\u7528\u300c\u5167\u5728\u8a9e\u8a00\u300d\u505a\u63a8\u7406\uff0c\u4f46\u5c0d\u5916\u8f38\u51fa\u7684 CoT \u4e26\u4e0d\u5fe0\u5be6\u53cd\u6620\u5167\u90e8\u904e\u7a0b\u3002\n\n\u540c\u671f **Goodfire** \u63a8\u51fa\u300cNeural Geometry\u300d\u7814\u7a76\u8b70\u7a0b\uff0c\u4e3b\u5f35\u7528 **manifolds\uff08\u6d41\u5f62\uff09** \u4f5c\u70ba\u89e3\u91cb\u6027\u539f\u8a9e\uff0c\u8207 SAE\uff08Sparse Autoencoder\uff09\u8def\u7dda\u5f62\u6210\u6709\u610f\u601d\u7684\u5c0d\u6bd4\u3002\u5169\u689d\u8def\u7dda\u7684\u6839\u672c\u6b67\u7570\u662f\uff1a\u89e3\u91cb\u6027\u7684\u300c\u6700\u5c0f\u55ae\u4f4d\u300d\u61c9\u8a72\u662f\u96e2\u6563\u7684\u7279\u5fb5\uff08SAE\uff09\uff0c\u9084\u662f\u9023\u7e8c\u7684\u6d41\u5f62\u7d50\u69cb\uff08NG\uff09\uff1f\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- \u5982\u679c\u6a21\u578b\u6709\u300c\u4e0d\u540c\u65bc CoT \u7684\u5167\u5728\u8a9e\u8a00\u300d\uff0c\u6240\u6709\u4ee5\u300c\u76e3\u63a7 CoT\u300d\u70ba\u524d\u63d0\u7684 alignment \u65b9\u6848\u662f\u5426\u8981\u91cd\u5beb\uff1f\u9019\u76f4\u63a5\u6311\u6230 OpenAI \u8def\u7dda\u3002\n- Anthropic \u8207 Goodfire \u7684\u65b9\u6cd5\u4e4b\u722d\uff0c\u6703\u4e0d\u6703\u50cf\u7576\u5e74 symbolic vs connectionist \u90a3\u6a23\u6c7a\u5b9a\u4e0b\u4e00\u8f2a\u5178\u7bc4\uff1f\n- \u958b\u6e90 NLA \u4e0a\u67b6 Neuronpedia\uff0c\u610f\u5473\u5b78\u8853\u5708\u8207\u7368\u7acb\u7814\u7a76\u8005\u7b2c\u4e00\u6b21\u80fd\u5728\u524d\u6cbf\u6a21\u578b\u4e0a\u505a\u89e3\u91cb\u6027\u5be6\u9a57\u2014\u2014\u9019\u6703\u6253\u958b\u54ea\u4e9b\u65b0\u7684\u7814\u7a76\u4e3b\u984c\uff1f\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://news.smol.ai/\n\n---\n\n## 7. Gary Marcus \u9023\u767c\u5169\u6587\uff1a\u81ea\u4e3b Agent \u662f\u5834\u707d\u96e3 + AI \u53cd\u64b2\u65e5\u76ca\u9ad8\u6f32\n\nMarcus \u5f15\u7528 Stanford/MIT CSAIL/CMU/NVIDIA \u7b49\u806f\u5408\u7814\u7a76\uff1a\u6aa2\u8996 847 \u500b\u751f\u7522\u74b0\u5883\u7684 agent \u90e8\u7f72\uff0c\u767c\u73fe **91% \u5c0d tool-chaining \u653b\u64ca\u8106\u5f31**\u300189.4% \u5728\u7d04 30 \u6b65\u5f8c\u51fa\u73fe\u76ee\u6a19\u6f02\u79fb\u300194% \u6709\u8a18\u61b6\u6a21\u7d44\u7684 agent \u6613\u53d7\u6295\u6bd2\u653b\u64ca\u3002\u6587\u4e2d\u9084\u5f15\u7528\u300c**OpenClaw / Moltbook \u4e8b\u4ef6**\u300d\u2014\u201477 \u842c\u500b\u6d3b\u8e8d agent \u56e0\u55ae\u4e00\u8cc7\u6599\u5eab\u6f0f\u6d1e\u540c\u6642\u88ab\u653b\u9677\uff0c\u662f\u9996\u6b21\u5927\u898f\u6a21\u771f\u5be6\u4e16\u754c agent \u5a01\u8105\u6a21\u578b\u9a57\u8b49\u3002\n\n\u53e6\u4e00\u7bc7\u8ac7\u300cAI \u53cd\u64b2\u300d\uff1a**44% \u53d7\u8a2a Gen Z \u54e1\u5de5\u627f\u8a8d\u300c\u6b63\u5728\u4ee5\u67d0\u7a2e\u65b9\u5f0f\u7834\u58de\u516c\u53f8\u7684 AI \u7b56\u7565\u300d**\u3001AI \u9ad8\u4e2d\u56e0\u6297\u8b70\u88ab\u53d6\u6d88\u3001QuitGPT \u904b\u52d5\u8208\u8d77\u3002Marcus \u91cd\u7533\u4e00\u5e74\u524d\u7684\u9810\u6e2c\uff1a\u53cd AI \u60c5\u7dd2\u5c07\u6210\u70ba 2028 \u7f8e\u570b\u7e3d\u7d71\u5927\u9078\u91cd\u8981\u8b70\u984c\uff0c\u5df2\u958b\u59cb\u5f71\u97ff\u671f\u4e2d\u9078\u8209\u3002\n\n\u5c0d\u6bd4\u540c\u65e5 Cloudflare \u88c1\u54e1 1,100 \u4eba + Anthropic \u53d6\u5f97 SpaceX Colossus 1 \u7b97\u529b\uff08\u4f34\u96a8\u74b0\u5883\u722d\u8b70\uff09\u3001xAI \u4fdd\u7559\u66f4\u5927\u7684 Colossus 2\u2014\u2014\u300c\u8cc7\u672c\u8207\u7b97\u529b\u6975\u5ea6\u96c6\u4e2d\u300d\u8207\u300c\u54e1\u5de5\u8207\u793e\u6703\u7684\u53cd\u64b2\u300d\u6b63\u540c\u6642\u52a0\u901f\uff0c\u9019\u662f 2026 \u5e74\u6700\u77db\u76fe\u7684\u5f35\u529b\u3002\n\n**\u503c\u5f97\u6df1\u6316\uff1a**\n- 91% agent \u5c0d tool-chaining \u653b\u64ca\u8106\u5f31\u2014\u2014\u9019\u500b\u6578\u5b57\u5728\u4f01\u696d\u5b89\u5168\u5708\u88ab\u4f4e\u4f30\u9084\u662f\u9ad8\u4f30\uff1f\n- \u300c\u54e1\u5de5\u7834\u58de\u516c\u53f8 AI \u7b56\u7565\u300d\u7684\u6578\u5b57\u5982\u679c\u771f\u5be6\uff0cHR \u8207 InfoSec \u8a72\u5982\u4f55\u61c9\u5c0d\uff1f\u9019\u6703\u4e0d\u6703\u50ac\u751f\u65b0\u7684\u300c\u5167\u90e8 AI \u6cbb\u7406\u300d\u8077\u4f4d\uff1f\n- Marcus \u7684\u53cd hype \u7acb\u5834\u662f\u5426\u5728 2026 \u5e74\u7b2c\u4e00\u6b21\u53d6\u5f97\u4e86\u5be6\u8b49\u652f\u6301\uff1f\u6216\u8005\u4ed6\u53ea\u662f\u6311\u4e86\u7b26\u5408\u4ed6\u6558\u4e8b\u7684 cherry-picked \u7814\u7a76\uff1f\n- \u300cQuitGPT \u904b\u52d5\u300d\u662f\u771f\u5be6\u7684\u6b21\u6587\u5316\u9084\u662f\u793e\u7fa4\u5a92\u9ad4\u653e\u5927\uff1f\u503c\u5f97\u8ffd\u8e64\u5e7e\u500b\u57ce\u5e02\u7684\u7dda\u4e0b\u53c3\u8207\u5ea6\u3002\n\n**\u53c3\u8003\u9023\u7d50\uff1a**\n- https://garymarcus.substack.com/p/breaking-autonomous-agents-are-a\n- https://garymarcus.substack.com/p/the-growing-ai-backlash\n\n---\n\n## 8. \u6280\u8853\u793e\u7fa4\u5feb\u5831\n\n**Cloudflare \u88c1\u54e1 1,100 \u4eba\uff08HN 82 \u5206\uff09** \u2014 Q1 2026 \u8ca1\u5831\u540c\u6642\u91cb\u51fa\uff0c\u5e02\u5834\u8996\u70ba\u5927\u578b\u96f2\u5ee0\u5546 AI \u91cd\u8cc7\u672c\u652f\u51fa\u5f8c\u7684\u6210\u672c\u8abf\u6574\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48055238\n\n**Canvas \u6559\u80b2\u5e73\u53f0\u906d ShinyHunters \u5165\u4fb5\uff08HN 861 \u5206\uff0f567 \u7559\u8a00\uff09** \u2014 \u670d\u52d9\u4e00\u5ea6\u4e2d\u65b7\u5f8c\u6062\u5fa9\u4e0a\u7dda\uff0c\u52d2\u7d22\u8ac7\u5224\u6301\u7e8c\u4e2d\uff1b\u7e7c Snowflake \u5f8c\u5c0d\u6559\u80b2\u7522\u696d\u6700\u65b0\u653b\u64ca\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48055913\n\n**\u300c\u6700\u8fd1\u4e0d\u8981\u88dd\u65b0\u8edf\u9ad4\u300d\u547c\u7c72\u7206\u7d05\uff08HN 737 \u5206\uff0f393 \u7559\u8a00\uff09** \u2014 Xe Iaso \u64b0\u6587\u56de\u61c9 npm/PyPI/AUR \u591a\u500b\u751f\u614b\u7cfb\u4f9b\u61c9\u93c8\u653b\u64ca\uff0c\u5efa\u8b70\u4f7f\u7528\u8005\u66ab\u6642\u505c\u624b\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48056227\n\n**JDownloader \u5b98\u7db2\u88ab\u690d\u5165\u60e1\u610f\u5b89\u88dd\u6a94\uff08HN 82 \u5206\uff09** \u2014 \u71b1\u9580\u4e0b\u8f09\u5de5\u5177\u4f9b\u61c9\u93c8\u653b\u64ca\uff0c\u547c\u61c9 Xeiaso \u90a3\u7bc7\u7684\u6642\u9593\u9ede\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48062035\n\n**GPT-5.5 \u6f32\u50f9\u6210\u672c\u5206\u6790\uff08HN 166 \u5206\uff0f48 \u7559\u8a00\uff09** \u2014 OpenRouter \u5831\u544a\u9577 context \u4efb\u52d9\u6f32\u5e45\u660e\u986f\uff0c\u793e\u7fa4\u8a0e\u8ad6\u8f49\u5411 Claude/Gemini\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48057209\n\n**Google Cloud Fraud Defence \u88ab\u6307\u662f WEI \u63db\u5305\u88dd\uff08HN 164 \u5206\uff0f53 \u7559\u8a00\uff09** \u2014 \u96b1\u79c1\u5021\u8b70\u8005\u64d4\u6182 Google \u91cd\u65b0\u63a8\u9032\u700f\u89bd\u5668\u5c64\u8b49\u660e\u6a5f\u5236\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48063199\n\n**xz \u5f8c\u9580\u771f\u5147\u662f GNU IFUNC\uff08HN 114 \u5206\uff0f52 \u7559\u8a00\uff09** \u2014 \u5b89\u5168\u7814\u7a76\u54e1\u6df1\u5165\u5206\u6790 CVE-2024-3094\uff0c\u793a\u7bc4 IFUNC \u5982\u4f55\u96b1\u85cf\u6ce8\u5165\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48056749\n\n**Mojo 1.0 Beta \u767c\u5e03\uff08HN 97 \u5206\uff0f101 \u7559\u8a00\uff09** \u2014 Modular \u91cb\u51fa\u8fd1 Python \u8a9e\u6cd5\u3001C++ \u7d1a\u6548\u80fd\uff1b\u793e\u7fa4\u8cea\u7591\u958b\u6e90\u627f\u8afe\u5ef6\u9072\u3002\n\ud83d\udd17 https://news.ycombinator.com/item?id=48057901\n\n**Cursor \u63a8\u51fa `/orchestrate`** \u2014 \u7528 Cursor SDK \u905e\u8ff4\u751f planner/worker/verifier \u4ee3\u7406\uff0ctoken \u7528\u91cf\u964d 20%\u3001\u5f8c\u7aef\u51b7\u555f\u964d 80%\uff1bCursor 3 \u6574\u5408 PR review\u3002\n\ud83d\udd17 https://news.smol.ai/\n\n**Prime Intellect \u51fa Beta + Ramp \u300cFast Ask\u300d** \u2014 RL \u8a13\u7df4\u7684\u8a66\u7b97\u8868 QA \u5b50\u4ee3\u7406\uff0c\u6bd4 Opus \u591a 4% exact-match\uff0c\u4f46\u8dd1\u5f97\u50cf Haiku \u4e00\u6a23\u5feb\u53c8\u4fbf\u5b9c\u3002\n\ud83d\udd17 https://news.smol.ai/\n\n**Lambda \u53d6\u5f97 10 \u5104\u7f8e\u5143\u6709\u64d4\u4fdd\u4fe1\u8cb8\u984d\u5ea6** \u2014 algorithm-friendly GPU cloud \u7af6\u722d\u52a0\u5287\u3002\n\ud83d\udd17 https://news.smol.ai/\n\n**Google \u63a8\u51fa 100 \u7f8e\u5143\u7121\u87a2\u5e55 Fitbit Air + \u5168\u65b0 Health App** \u2014 Gemini \u6574\u5408\u9032\u9577\u671f\u5065\u5eb7\u5206\u6790\uff0c\u6311\u6230 Apple Watch\u3002\n\ud83d\udd17 https://arstechnica.com/ai/\n\n**Import AI #455\uff1aJack Clark \u9810\u6e2c 60% \u6a5f\u7387 2028 \u5e74\u5e95\u524d\u51fa\u73fe\u300c\u81ea\u4e3b AI R&D\u300d** \u2014 Anthropic \u5167\u90e8 LM \u8a13\u7df4\u52a0\u901f\u5f9e Opus 4 \u7684 2.9\u00d7 \u63d0\u5347\u5230 Mythos \u7684 52\u00d7\u3002\n\ud83d\udd17 https://importai.substack.com/p/import-ai-455-automating-ai-research\n\n**arXiv\uff1aThe Reasoning Trap** \u2014 \u7528 Data Processing Inequality \u8b49\u660e\u9589\u7cfb\u7d71 multi-agent debate \u7684\u4e92\u8cc7\u8a0a\u55ae\u8abf\u905e\u6e1b\uff1bMAD \u4fdd\u7559 88% \u6e96\u78ba\u7387\u4f46 SFS \u964d 43%\u3002\n\ud83d\udd17 https://arxiv.org/html/2605.01704v1\n\n**arXiv\uff1aReasoning as Gradient\uff08Gome\uff09** \u2014 \u628a MLE agent \u7684 tree search \u6539\u70ba gradient-based\uff0c\u55ae\u5f35 V100 / 12 \u5c0f\u6642\u9054\u5230 35.1% any-medal SOTA\u3002\n\ud83d\udd17 https://arxiv.org/abs/2603.01692v2\n\n---\n\n## \ud83c\udf99\ufe0f \u9078\u984c\u5efa\u8b70\uff1a\u54ea\u4e9b\u6545\u4e8b\u9069\u5408\u77fd\u8c37\u8f15\u9b06\u8ac7\n\n> \u5f9e Kenji \u7684\u983b\u9053\u4e3b\u8ef8\uff08AI \u5de5\u5177\u8207\u5de5\u4f5c\u6d41\u3001\u8edf\u9ad4\u5de5\u7a0b\u5e2b\u8077\u6daf\u3001\u77fd\u8c37\u516c\u53f8\u5167\u8996\u89d2\u3001\u6280\u8853 hype vs \u5be6\u6cc1\uff09\u51fa\u767c\u3002\n\n### \ud83d\udd25 \u5f37\u70c8\u63a8\u85a6\n1. **\u300cMozilla \u7528 Claude \u4e00\u500b\u6708\u627e\u51fa 423 \u500b Firefox \u6f0f\u6d1e\u300d** \u2014 \u9019\u662f AI \u53d6\u4ee3\uff0f\u653e\u5927\u5de5\u7a0b\u5e2b\u5de5\u4f5c\u7684\u6700\u5177\u9ad4\u6848\u4f8b\u4e4b\u4e00\u3002\u53ef\u5f9e Bug Bounty \u7d93\u6fdf\u5b78\u5207\u5165\uff1a\u5982\u679c LLM \u80fd\u627e\u6f0f\u6d1e\uff0cBug Bounty \u7a0b\u5e8f\u7684\u8a2d\u8a08\u9700\u8981\u600e\u9ebc\u8b8a\uff1f\u5c0d security engineer \u8077\u6daf\u7684\u885d\u64ca\uff1f\u9019\u689d\u6545\u4e8b\u9023\u7d50\u5230 Kenji \u904e\u5f80\u505a\u904e\u7684\u300cAI \u5c0d\u8edf\u9ad4\u5de5\u7a0b\u5e2b\u7684\u5f71\u97ff\u300d\u7cfb\u5217\uff0c\u73fe\u5728\u53ef\u4ee5\u7d66\u51fa\u6700\u65b0\u3001\u6700\u6709\u6232\u5287\u6027\u7684\u6578\u5b57\u4f50\u8b49\u3002\n2. **\u300cCloudflare \u71df\u6536\u9ad8\u6210\u9577\u9084\u88c1 20%\u300d** \u2014 \u76f4\u63a5\u6253\u4e2d\u300cAI \u5c0d\u8edf\u9ad4\u5de5\u7a0b\u5e2b\u7684\u5f71\u97ff\u300d\u6838\u5fc3\u8b70\u984c\u3002\u53ef\u4ee5\u5c0d\u6bd4 Kenji \u5728 Square/Brex/Cruise \u770b\u904e\u7684\u4e0d\u540c\u968e\u6bb5\u88c1\u54e1\u908f\u8f2f\uff0c\u8ac7\u9019\u6b21 Cloudflare \u662f\u4e0d\u662f\u300c\u6210\u9577\u516c\u53f8\u7528 AI \u91cd\u5851\u4eba\u529b\u300d\u7684\u7b2c\u4e00\u500b\u5178\u7bc4\u6848\u4f8b\uff0c\u4ee5\u53ca\u5c0d\u4e2d\u968e\u5de5\u7a0b\u5e2b\u8077\u6daf\u7684\u8a0a\u865f\u3002\n3. **\u300cOpenAI Realtime-2 + Codex Chrome \u96d9\u767c\u300d** \u2014 Codex \u5728 Chrome \u591a\u5206\u9801\u80cc\u666f\u904b\u4f5c\u9019\u4ef6\u4e8b\uff0c\u525b\u597d\u63a5\u7e8c Kenji \u4e4b\u524d\u5c0d Claude Code\u3001Cursor \u7684\u5de5\u4f5c\u6d41\u5206\u4eab\u3002\u53ef\u4ee5\u505a\u4e00\u500b\u300cAgent in the Browser\uff1a\u500b\u4eba\u96fb\u8166\u7bc4\u5f0f\u8f49\u79fb\u7684\u7b2c\u4e00\u500b\u8de1\u8c61\u300d\u3002\n\n### \ud83d\udca1 \u9069\u5408\u505a\u6df1\u5ea6\u601d\u8fa8\u96c6\n4. **\u300cOpenAI \u5b8c\u6210 PBC \u91cd\u7d44 + Musk \u8a34\u8a1f\u63ed\u5bc6\u300d** \u2014 \u9019\u662f hype vs \u5be6\u6cc1\u7684\u5178\u7bc4\u984c\u6750\u3002\u5f9e\u300c\u975e\u71df\u5229\u4f7f\u547d\u300d\u8b8a\u6210\u300cPBC + \u79fb\u9664 100\u00d7 \u4e0a\u9650 + \u5fae\u8edf 27%\u300d\uff0c\u53ef\u4ee5\u7d50\u5408 Kenji \u5728\u77fd\u8c37\u5de5\u4f5c\u591a\u5e74\u7684\u89c0\u5bdf\u8ac7\u300c\u4f7f\u547d\u6f02\u79fb\u300d\u9019\u4ef6\u4e8b\u5728\u77fd\u8c37\u6709\u591a\u666e\u904d\uff0c\u4ee5\u53ca\u300c\u516c\u76ca\u516c\u53f8\u300d\u662f\u5426\u53ea\u662f\u516c\u95dc\u88dd\u98fe\u3002\n5. **\u300cAnthropic NLA\uff1a\u6a21\u578b\u6709\u4e0d\u540c\u65bc CoT \u7684\u5167\u5728\u8a9e\u8a00\u300d** \u2014 \u6bd4\u8f03\u786c\u6838\u4f46\u6df1\u523b\uff1a\u5982\u679c\u9019\u662f\u771f\u7684\uff0c\u6240\u6709\u4ee5\u76e3\u63a7 CoT \u70ba\u524d\u63d0\u7684\u5b89\u5168\u65b9\u6848\u90fd\u8981\u91cd\u5beb\u3002\u53ef\u4ee5\u9023\u7d50\u5230\u300cAI \u9ed1\u76d2\u5b50\u300d\u7cfb\u5217\uff0c\u8ac7\u70ba\u4ec0\u9ebc\u53ef\u89e3\u91cb\u6027\u7814\u7a76\u662f alignment \u7684\u6700\u5f8c\u4e00\u9053\u9632\u7dda\u3002\n6. **\u300cGary Marcus \u5169\u7bc7\uff1a91% agent \u8106\u5f31 + 44% Gen Z \u54e1\u5de5\u7834\u58de\u516c\u53f8 AI \u7b56\u7565\u300d** \u2014 \u5b8c\u7f8e\u7684 hype vs \u5be6\u6cc1\u7d20\u6750\u3002\u53ef\u4ee5\u505a\u4e00\u96c6\u300c2026 \u5e74 AI Agent \u771f\u7684\u80fd\u7528\u55ce\uff1f\u300d\u76f4\u63a5\u5c0d\u6bd4 Marcus \u5f15\u7528\u7684\u6578\u5b57 vs Cursor\u3001Ramp\u3001Prime Intellect \u7aef\u7684\u6210\u529f\u6848\u4f8b\uff0c\u627e\u51fa\u5169\u8005\u5dee\u8ddd\u5728\u54ea\u3002\n\n### \ud83c\udf36\ufe0f \u9023\u7d50 Kenji \u500b\u4eba\u7d93\u9a57\n7. **\u300c\u4e2d\u570b\u958b\u6e90\u6a21\u578b\u56db\u9023\u767c\uff1aMiniMax-M2 / ZAYA1-8B / Gemma 4 MTP / Granite 4.1\u300d** \u2014 \u958b\u6e90 vs \u9589\u6e90\u5dee\u8ddd\u7e2e\u5230 +30 \u5206\u9019\u4ef6\u4e8b\u5f88\u503c\u5f97\u505a\u4e00\u96c6\u3002Kenji \u5728 Phantom\uff08Solana\uff09\u6709\u904e\u958b\u6e90\u751f\u614b\u89c0\u5bdf\u7684\u7d93\u9a57\uff0c\u53ef\u4ee5\u7528\u300c\u958b\u653e\u7db2\u8def vs \u570d\u7246\u82b1\u5712\u300d\u7684\u6846\u67b6\u4f86\u8ac7 AI \u6a21\u578b\u751f\u614b\u672a\u4f86\u3002\n8. **\u300cTrusted Contact \u81ea\u6b98\u9632\u8b77\u300d** \u2014 \u6bd4\u8f03\u611f\u6027\u7684\u984c\u6750\uff0c\u4f46\u8ddf\u300c\u6280\u8853\u5c0d\u4eba\u7684\u771f\u5be6\u5f71\u97ff\u300d\u9019\u689d Kenji \u4e00\u76f4\u5728\u505a\u7684\u7dda\u5b8c\u7f8e\u9023\u7d50\u3002\u53ef\u4ee5\u5f9e\u300cSam Altman \u6821\u5712\u69cd\u64ca\u9810\u8b66\u4e8b\u4ef6\u300d\u8ac7\u5230 AI \u5728\u5fc3\u7406\u5065\u5eb7\u4ecb\u5165\u93c8\u4e2d\u7684\u8cac\u4efb\u908a\u754c\u3002\n\n### \u26a1 \u5feb\u8a0a\u578b\u5167\u5bb9\n- Mojo 1.0 Beta \u767c\u5e03\u3001Cursor `/orchestrate`\u3001Lambda $1B \u4fe1\u8cb8\u2014\u2014\u9069\u5408\u505a Twitter/Threads \u77ed\u8a55\uff0c\u4e0d\u9700\u8981\u62cd\u4e00\u6574\u96c6\u3002\n- \u4f9b\u61c9\u93c8\u653b\u64ca\u98a8\u66b4\uff08Canvas\u3001JDownloader\u3001Xeiaso \u90a3\u7bc7\uff09\u4e5f\u9069\u5408\u77ed\u8a55\uff1a\u7d66\u89c0\u773e\u4e00\u500b\u300c\u9019\u9031\u4e0d\u8981\u5b89\u88dd\u65b0\u6771\u897f\u300d\u7684\u5be6\u7528\u63d0\u9192\u3002\n\n---\n\n*\u8cc7\u6599\u4f86\u6e90\uff1aTechCrunch\u3001The Verge\u3001Ars Technica\u3001VentureBeat\u3001Hacker News\u3001news.smol.ai\u3001Import AI\u3001The Batch\u3001Gary Marcus Substack\u3001Simon Willison\u3001arXiv\u3002*\n", "creation_timestamp": "2026-05-08T16:59:30.000000Z"}, {"uuid": "b0d2abc6-b0d8-4e6c-8ef8-a849537e61a4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/hn100.bsky.social/post/3mlfantt5zi2z", "content": "GNU IFUNC is the real culprit behind CVE-2024-3094\n\nDiscussion", "creation_timestamp": "2026-05-09T02:56:07.228001Z"}, {"uuid": "80c30b40-4f0a-4cfd-9f31-84028ee0473c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/YoraiLevi/d788d3ecbc8545d40c41e0957683ca22", "content": "# The Bootstrap Conundrum\n\n### A Rookie's Live Book on How Real Companies Solve the Trust Problem\n\n---\n\n## Front matter\n\n> **Who this book is for.** You've just been told that your team runs \"infrastructure\" \u2014 Vault, Kubernetes, GitHub Actions runners, whatever \u2014 and that there's a \"Day 1 setup\" you need to do, and then \"Day 2 operations,\" and then \"disaster recovery,\" and at every step you keep running into the same uncomfortable feeling: *\"how can I configure X if X is what I'm trying to set up?\"* You're not crazy. You've discovered the **bootstrap problem**. This book is everything our team learned from 10 weeks of reading the industry's accumulated answer to that question, distilled so you don't have to re-derive it.\n>\n> **Why this book exists.** The bootstrap problem is one of the oldest open questions in computer security and distributed systems. Ken Thompson identified its deepest form in his 1984 Turing Award lecture; the DNS root operators have been performing scripted ceremonies to ground it since 2010; HashiCorp built a company on monetizing one slice of it. The lessons are scattered across academic papers, conference talks, regulator publications, vendor blogs, postmortems, and the working knowledge of senior SREs. We pulled them together because we couldn't find this book and decided to write the one we wished existed.\n>\n> **How to read it.** Read Part I from start to finish \u2014 it builds the conceptual scaffold and you cannot skip it. Then read whichever chapter of Part II is closest to your immediate problem. Part III ties everything back to action items for our DGX fleet project, but the recommendations generalize.\n>\n> **What this book is not.** It is not a Vault tutorial, an Ansible reference, a Kubernetes how-to, or a step-by-step \"do this.\" It is the *vocabulary* and *mental model* that lets you make sense of every Vault tutorial, every Ansible reference, every Kubernetes how-to. Once you have the model, the tutorials become legible.\n>\n> **Project context (for the curious).** This book emerged from operating a small fleet \u2014 two NVIDIA DGX Spark inference boxes plus a Proxmox VM running Vault + k3s + actions-runner-controller + ARA. We are two engineers, not fifty. Many of the lessons here are over-engineered for that scale; we mark which ones are \"do this today\" vs \"save for when you grow.\"\n>\n> **A note on humility.** Every recommendation in this book is something we found in the wild from people doing real work at real scale. We did not invent any of it. The agents that researched each chapter cited URLs aggressively \u2014 follow them. Where we disagree with consensus, we say so explicitly.\n\n---\n\n## Table of contents\n\n### Part I \u2014 The problem\n1. [The naive state \u2014 what you think before you read this](#1-the-naive-state)\n2. [The bootstrap problem, properly named](#2-the-bootstrap-problem)\n3. [The three buckets \u2014 identity, data, config](#3-the-three-buckets)\n4. [Day 0, Day 1, Day 2 \u2014 the time-scale axis](#4-day-0-day-1-day-2)\n\n### Part II \u2014 How real companies do it\n5. [Running HashiCorp Vault for the long haul](#5-vault-in-production)\n6. [The Google SRE lens \u2014 toil, DiRT, error budgets](#6-google-sre)\n7. [Key ceremonies \u2014 30 years of PKI wisdom](#7-key-ceremonies)\n8. [GitOps for stateful infrastructure](#8-gitops)\n9. [Tested DR \u2014 chaos engineering and game days](#9-chaos)\n10. [Kubernetes and etcd \u2014 the parallel problem](#10-kubernetes)\n11. [Workload identity \u2014 the death of secret zero](#11-workload-identity)\n12. [Supply chain trust \u2014 trust has no floor](#12-supply-chain)\n13. [Compliance-driven DR \u2014 what auditors actually want](#13-compliance)\n14. [Boring infrastructure for two engineers \u2014 the homelab way](#14-homelab)\n\n### Part III \u2014 Synthesis and action\n15. [The unified methodology](#15-unified-methodology)\n16. [Concrete next steps](#16-concrete-next-steps)\n17. [Reading order for going deeper](#17-reading-order)\n\n---\n\n# Part I \u2014 The problem\n\n## 1. The naive state\n\nBefore you've thought hard about infrastructure, you carry an unspoken model that goes something like this:\n\n1. *Setup* is a thing you do once. It's annoying, but it's a one-time cost.\n2. After setup, the system *runs*. You just have to maintain it.\n3. If something breaks, you fix it. If it breaks badly, you \"rebuild from backups.\"\n4. Secrets go in a *secret manager*. The secret manager is just another piece of software you set up once.\n\nEach of those four statements is wrong. Specifically:\n\n1. **Setup never ends.** Every system needs new policies, new users, new rotations, new upgrades. The \"setup\" capability is a *permanent service*, not a one-time event.\n2. **The \"running\" state hides ongoing configuration drift.** Every minute that passes, the system you're operating diverges from the documentation that describes it. Unless you fight that drift explicitly, the documentation rots, the runbooks rot, and Day-90 you cannot reproduce what Day-1 you did.\n3. **\"Rebuild from backups\" is a fantasy until you've actually rebuilt from backups.** Untested backups are not backups; they are stories you tell yourself about backups. The industry has a name for this trap: it killed GitLab in 2017 (five backup mechanisms, none worked).\n4. **The secret manager has the bootstrap problem worst of all.** It holds the keys to everything else, which means it needs *its own* keys, which means *its own* secret manager, which means... we'll get to it.\n\nHold all four of those in your head. The rest of Part I unpacks why each is wrong, and Part II shows you the patterns the industry has converged on for each.\n\n`\u2605 Insight \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500`\nThe discomfort you feel reading the four naive statements above is your brain doing the work. If a senior engineer rolls their eyes when you say \"we'll just restore from backup,\" that eye-roll is the result of having lived through what happens when statement 3 turns out to be wrong. The point of this book is to inherit those reflexes without first living through the outages that produced them.\n`\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500`\n\n## 2. The bootstrap problem\n\nDefine a **trust dependency** as: *system A cannot operate until it can authenticate to system B*. Now consider three trust dependencies on top of each other:\n\n- Your fleet of inference servers needs to authenticate to Vault to fetch secrets.\n- Vault needs to be authenticated-to via a credential the fleet servers hold.\n- The credential is itself a secret that needs to be distributed somehow.\n\nIf you store the credential **in Vault**, then the fleet needs to authenticate to Vault before it can fetch the credential to authenticate to Vault. That's a cycle. The cycle has a name: it's the **bootstrap problem**, and the specific case of \"the credential you need to fetch your other credentials\" is called **secret zero**. Every system that holds secrets faces secret zero at the boundary where the system meets the world.\n\nKen Thompson's 1984 paper *Reflections on Trusting Trust* \u2014 which we recommend you read before any other paper in this field \u2014 generalizes the bootstrap problem to its deepest form: *you cannot trust code you didn't write unless you can trust the compiler that compiled it, and you cannot trust the compiler unless you trust the compiler that compiled the compiler, and so on, all the way down*. The infinite regress only terminates at a **root of trust** that you accept on some basis other than further verification \u2014 a piece of paper in a safe, a hardware token, a human's memory, the manufacturer's signature on a TPM chip.\n\nThis is not an academic problem. It shows up everywhere in your project:\n\n- **Vault TLS** needs a hostname and a certificate. The certificate could come from a CA. The CA's private key could live in Vault. \u2192 cycle. Resolution: self-signed cert + IP address for Day-1; revisit with a real internal CA when one exists.\n- **External Secrets Operator (ESO)** needs to authenticate to Vault. ESO runs in Kubernetes. The auth token needs to come from somewhere. \u2192 cycle. Resolution: a bootstrap k8s Secret seeded manually once, then ESO migrates to Kubernetes auth method (which uses the cluster's own ServiceAccount JWT as the trust anchor).\n- **ARC** (actions-runner-controller) needs a GitHub App private key. The key could live in Vault. ESO could materialize it. But ARC is what brought up ESO. \u2192 cycle. Resolution: operator-manual `vault kv put`, then ESO materializes, then ARC reads.\n- **AppRole `secret_id`** must live on each Spark for Vault auth. It can't be checked into git. \u2192 cycle. Resolution: wrapped-token delivery with 10-minute TTL, operator-driven once per host.\n\nIn every case the cycle is broken the same way: **an operator hand-injects the minimum trust at the smallest possible scope, then immediately reduces their own privilege.** That's it. That's the entire technique. The 1984 paper, the DNSSEC ceremony, the Vault unseal procedure, the GitHub App seeding \u2014 all the same shape, different costumes.\n\nWhat changes is the *cost of getting the hand-injection wrong*:\n\n- Get the Vault unseal shards wrong \u2192 you have backed yourself out of your own Vault. Recovery is impossible if you also lose the data.\n- Get the GitHub App key seeding wrong \u2192 you have a short period of degraded CI. Annoying.\n- Get the SSH key for the operator account wrong \u2192 you go in via the Proxmox console. Mild inconvenience.\n\nThe **discipline** of operating infrastructure is partly: *recognize the bootstrap moments, treat the high-cost ones with ceremony, automate around the low-cost ones, and document the difference.*\n\n## 3. The three buckets\n\nThe single most useful mental model in this entire book \u2014 the one piece of conceptual machinery that makes every subsequent chapter legible \u2014 is the three-bucket split:\n\n| Bucket | What it is | Where it lives | How it survives destruction |\n|---|---|---|---|\n| **Identity** | Root keys, unseal shards, signing keys, operator credentials | **Offline / out-of-band** (humans, hardware tokens, sealed envelopes, HSMs) | Cannot be re-derived from anything else; redundancy via N-of-M distribution |\n| **Data** | Actual secrets *inside* Vault, NAS-resident model weights, Raft state, audit logs, database rows | **Backups** (snapshots, replication, off-host copies) | Restored from snapshot; periodicity bounds your recovery point objective |\n| **Config** | Policies, auth methods, KV mount layouts, RBAC roles, network firewall rules, deployment manifests | **Code** (git repo, applied idempotently by Ansible/Terraform/etc.) | Re-applied from `git clone` |\n\nThe rule that makes recovery tractable: **never let any two buckets mix.** Config never embeds secrets. Data never embeds policy. Identity never embeds in code. The moment one bucket leaks into another, you've created a recovery dependency that crosses categories \u2014 and recovery becomes \"you need three things at once,\" which is much harder to rehearse than \"you need three procedures, each independent.\"\n\nA concrete example: it is *very* tempting to write a play that stores a fresh AppRole `secret_id` into a file in the repo. You're saving yourself a manual step! The cost is that you've mixed identity (the `secret_id`) into config (the repo). Now anyone with read access to git can authenticate to Vault. You've made recovery *harder* by making setup easier. Every shortcut across bucket lines is a future incident.\n\nThe three-bucket split also gives you a clean answer to the reproducibility question:\n\n> *\"If everything goes to dust, can I rebuild?\"*\n\nHas three sub-answers:\n\n- **Identity**: you need it offline, you need redundancy, and you need to have *tested* that 3 of 5 custodians can actually reach you within an hour. If you cannot answer \"yes\" to that, your identity bucket has the same problem GitLab's backups had.\n- **Data**: you need snapshots, you need them on a different blast radius than the source, and you need a *tested* restore procedure. Snapshot exists \u2260 restore works. The compliance frameworks all agree on this point (Chapter 13).\n- **Config**: you need everything in code, the code needs to be applied idempotently, and the same `bash bootstrap.sh` command needs to work on a fresh checkout (Chapter 14).\n\nIf you can answer \"yes, tested\" to all three, you have a recoverable system. If you can only answer \"yes, in theory,\" you have a write-only recovery plan, which is no recovery plan at all.\n\n## 4. Day 0, Day 1, Day 2\n\nThe Kubernetes community popularized a vocabulary that turns out to be the right vocabulary for the whole bootstrap conversation:\n\n- **Day 0** \u2014 *design*. Drawing on a whiteboard, picking which tools, deciding the topology.\n- **Day 1** \u2014 *deploy*. Provisioning the boxes, installing the software, getting it running for the first time.\n- **Day 2** \u2014 *operate*. Everything from then on: upgrades, rotations, drills, incidents, refactors, capacity planning.\n\nThe defining insight: **Day 2 is forever**. Day 0 happens once. Day 1 happens once. Day 2 happens every day until the system is retired. The mistake new engineers make is thinking \"Day 2\" is a separate, optional concern that happens after \"real work\" is done. It is the real work. Day 1 is just the first day of Day 2.\n\nThe bootstrap problem replays at every Day 2 cadence, just at a longer time scale:\n\n| Cadence | The cyclic dependency | The resolution |\n|---|---|---|\n| **Initial** (hours) | Vault config needs Vault running | Vault-free `bootstrap.yml` + one-shot init runbook with privileged token, then revoke |\n| **Configuration drift** (continuous) | Vault config needs to evolve; applying config requires Vault auth | Scoped `vault-config-applier` identity + `roles/vault_config/` in code (Chapter 8) |\n| **Backup** (daily) | Vault's own data must be preserved, but the data includes the encryption keys | Raft snapshots, encrypted with Shamir keys, shipped off-host (Chapter 5) |\n| **Disaster recovery** (rare) | Restoring requires the original shards, which lived offline precisely because they couldn't be in any system that might be destroyed | The 5-destination shard distribution survives single-point failures (Chapter 7) |\n| **Improvement** (perpetual) | Bootstrap infra ages; you can't change it without using it | PR-reviewed runbook changes + staging Vault + quarterly drills (Chapter 9) |\n\nThe pattern that resolves every layer is the same: *separate identity from data from config, and verify each independently.* Part II of this book is ten different industries showing you ten different applications of this same pattern. Once you see it, you cannot unsee it.\n\nWith Part I in your head, Part II will feel like coming home.\n\n---\n\n# Part II \u2014 How real companies do it\n\n> Each chapter that follows was produced by a dedicated research agent reading the open web for ~10 minutes, iterating queries, and synthesizing what real practitioners do. The agents were briefed on the three-bucket model and asked to surface concrete procedures, war stories, and actionable lessons \u2014 not vendor marketing. URLs are preserved so you can verify and dig deeper. The agents wrote their sections independently; we've added connecting tissue but preserved their reporting verbatim where it works.\n\n---\n\n## 5. Vault in production\n\n> *The pattern in 2-3 sentences:* In real production, Vault is not \"install, init, done\" \u2014 it is a continuously-operated stateful service whose hardest problem is **bootstrapping trust without already having trust**. Mature shops solve this with one of two patterns: (a) **cloud-KMS auto-unseal + short-lived workload identity** for cloud-native fleets, or (b) **Shamir-split keys held offline by humans + a \"trusted orchestrator\" that response-wraps short-TTL AppRole SecretIDs** for on-prem fleets. Everything else (DR, rotation, upgrades) reduces to \"have raft snapshots in a foreign blast-radius, do rolling restarts, and never let one human hold a quorum.\"\n\n### Concrete real-world examples\n\n1. **Adobe** \u2014 The most-documented at-scale Vault Enterprise deployment. By 2 years in, they ran **3 clusters per region, one primary + 11 performance secondaries, ~6 operators, ~130 onboarded teams, ~800M requests/month, p50 ~3 ms, p99 ~14 ms, 99.97% availability**. DR cluster lived in a different cloud (AWS) and a different coast. Auto-unseal triggered by **Rundeck via AWS KMS**, config managed via **Terraform + SaltStack**, monitoring via **Splunk + Prometheus \u2192 Grafana**. They tracked sealed-state, replication-lag, and ops/sec as their three critical signals. ([HashiCorp \u2013 2 Years of Vault Enterprise at Adobe](https://www.hashicorp.com/en/resources/keep-it-secret-safe-everywhere-2-years-vault-enterprise-adobe))\n2. **G-Research** \u2014 Runs **1,000+ Vault namespaces** with self-service onboarding via Jenkins + Kubernetes + Terraform, explicitly to keep the central IAM team out of the loop. Config-as-code is the unblocking pattern.\n3. **Roblox** \u2014 Open-sourced their [**vault-cookbook**](https://github.com/Roblox/vault-cookbook), a Chef cookbook that installs Vault as a systemd service, with library resources `vault_config`, `vault_service`, `vault_secret`. Test-Kitchen on CentOS 7/Ubuntu 16.04. They treat Vault as a managed daemon, not a Kubernetes pod.\n4. **Sky Betting & Gaming** \u2014 Developers grab **dynamic credentials** without specifying which; the platform team encodes the mapping. The pattern: humans never copy-paste secrets, ever.\n5. **Hippo Technologies** \u2014 Published [a HashiCorp \"trenches\" piece](https://www.hashicorp.com/en/resources/vault-configuration-as-code-via-terraform-stories-from-the-trenches) on Vault config-as-code via Terraform with one PR per auth-method/mount/policy change and state stored in a separate, hardened backend (Terraform-state-is-a-secret).\n\n### Specific tools / runbooks / cadences\n\n- **Snapshots**: Vault Enterprise has built-in `/sys/storage/raft/snapshot-auto` (1.6+) supporting S3/GCS/Azure Blob. OSS users run the [**Argelbargel/vault-raft-snapshot-agent**](https://github.com/Argelbargel/vault-raft-snapshot-agent) \u2014 defaults to `1h` frequency, supports multiple destinations simultaneously, authenticates via AppRole/Kubernetes/etc. Typical production cadence: **hourly to local + daily to S3 with 365-day retention**.\n- **Auto-unseal**: AWS KMS / GCP Cloud KMS / Azure Key Vault / **Vault Transit** (one Vault unseals another). Trade-off: auto-unseal removes the human-in-the-loop but **recovery keys cannot unseal Vault if the KMS is gone** \u2014 they only authorize root-token generation. So even with auto-unseal, you still print 5 recovery shards and put them in safes.\n- **Upgrades**: There is **no true zero-downtime upgrade** \u2014 expect a few hundred ms during leader step-down. Standard procedure: snapshot \u2192 upgrade followers one-by-one \u2192 step-down leader. Vault 1.11+ Enterprise has **Autopilot automated upgrades** that promotes newer-version voters and demotes older ones.\n- **Config-as-code**: Terraform Vault provider for policies, auth methods, mounts. State backend must be hardened \u2014 it contains secrets-about-secrets.\n- **Secret zero**: Vault Agent with `secret_id_response_wrapping_path`, `secret_id_num_uses=1`, `secret_id_bound_cidrs`, RoleID baked into the AMI/image, wrapped SecretID delivered just-in-time by a trusted orchestrator (Ansible/Jenkins/SaltStack).\n\n### War stories / failure modes\n\n- **Auto-unseal traps people on restore**: HashiCorp [Issue #7595](https://github.com/hashicorp/vault/issues/7595) \u2014 restoring a snapshot from a different cluster fails to unseal because the KMS-wrapped root key in the snapshot doesn't match the new cluster's seal. Lesson: **DR-restore drills must use the same KMS keyring**, or you must rekey before restore.\n- **Random re-sealing every 5\u20137 days** ([Issue #5593](https://github.com/hashicorp/vault/issues/5593)) \u2014 usually a downstream storage hiccup. Watch `vault.core.unsealed` and alert on transitions.\n- **Vault Agent does not survive restart with response-wrapped tokens** ([Issue #16148](https://github.com/hashicorp/vault/issues/16148)) \u2014 the wrap is single-use. Production fix: persist the unwrapped token in a tmpfs sink and re-fetch wrap on systemd restart.\n- **Adobe \"10 million KV pairs\" incident** \u2014 one team accidentally created 10M K/V entries, and \"600\u2013700k tokens at once.\" Vault held up, but the lesson is **per-namespace quotas + chargeback-style usage reports** (Adobe used KV-v2 metadata for cost-center tagging).\n\n### Lessons for any small Vault deployment\n\n1. **Codify the operator-only runbooks now, in detail, with one-line copy-paste blocks.** Adobe and G-Research both confirm: the privileged-init step *must* stay human, but it must also be **shockingly boring to execute** so the operator does not improvise. Put the exact `vault operator init -key-shares=5 -key-threshold=3` invocation with the 1Password CLI command beside it.\n2. **Adopt the trusted-orchestrator + response-wrapped SecretID pattern.** RoleID lives in the deployment manifest (non-secret); the SecretID is generated by an Ansible play with `-wrap-ttl=300s`, `secret_id_num_uses=1`, written to a tmpfile, and consumed by Vault Agent. Never check SecretIDs into git.\n3. **Hourly raft snapshots to a foreign blast radius from day one.** Run `vault-raft-snapshot-agent` (OSS) writing to an S3-compatible target *not* on the same host (Backblaze B2, an off-site MinIO, a friend's NAS). Default `1h` cadence, 168-snapshot retention. Test restore quarterly on a throwaway VM.\n4. **Defer auto-unseal until you have a second machine that can be the transit-unseal source.** A single-VM deployment with KMS-on-the-same-host is a circular dependency. Stay on Shamir; rehearse the 3-of-5 unseal quarterly with the actual humans.\n5. **Vault upgrades trigger a documented runbook, never an auto-apply.** Even a 300 ms blip cascades to ESO/ARC reconcile failures. Snapshot first, follower-first, leader last.\n\n### Further reading\n\n- [Adobe \u2013 2 Years of Vault Enterprise](https://www.hashicorp.com/en/resources/keep-it-secret-safe-everywhere-2-years-vault-enterprise-adobe) \u2014 the most concrete at-scale numbers public anywhere\n- [Vault AppRole production best-practice patterns](https://developer.hashicorp.com/vault/docs/auth/approle/approle-pattern) \u2014 anti-patterns table is the single most useful page\n- [Secure introduction tutorial](https://developer.hashicorp.com/vault/tutorials/app-integration/secure-introduction) \u2014 trusted-orchestrator + wrap_ttl walkthrough\n- [Vault SOP: Restore](https://docs.hashicorp.com/vault/tutorials/standard-procedures/sop-restore) and [SOP: Upgrade](https://docs.hashicorp.com/vault/tutorials/standard-procedures/sop-upgrade) \u2014 the two runbooks to clone\n- [Argelbargel/vault-raft-snapshot-agent](https://github.com/Argelbargel/vault-raft-snapshot-agent) \u2014 production OSS snapshot daemon\n- [Sealing best practices](https://developer.hashicorp.com/vault/docs/configuration/seal/seal-best-practices) \u2014 auto-unseal + recovery-key guidance\n- [Chris Zembower \u2013 Recommended Patterns for Vault Unseal and Recovery Key Management](https://medium.com/@czembower/recommended-patterns-for-vault-unseal-and-recovery-key-management-d6366a2f4607)\n- [Validated pattern: Vault Agent + AppRole for brownfield apps](https://developer.hashicorp.com/validated-patterns/vault/vault-agent-approle) \u2014 operator-administrator role split\n- [Roblox vault-cookbook](https://github.com/Roblox/vault-cookbook) \u2014 concrete reference for \"Vault as systemd daemon\" vs \"Vault as pod\"\n- [Hippo Technologies \"stories from the trenches\"](https://www.hashicorp.com/en/resources/vault-configuration-as-code-via-terraform-stories-from-the-trenches) \u2014 Terraform-Vault provider in real life, including state-backend hardening\n\n---\n\n## 6. Google SRE\n\n> *The pattern in 2-3 sentences:* Google SRE treats every manual, repeatable operator procedure as a *bug in the system* (toil) but accepts that some procedures \u2014 especially those touching root credentials or cold-start dependencies \u2014 cannot be safely automated and must instead be ruthlessly *practiced*. The discipline that holds it together is DiRT (Disaster and Recovery Testing): annual, company-wide, intentionally-disruptive drills that exercise the recovery procedures themselves, including the break-glass paths used to recover the recovery infrastructure. Toil-elimination and drill-the-runbook are not opposites \u2014 they are two sides of the same coin, gated by SLOs/error budgets that force the team to actually do the engineering work.\n\n### Concrete real-world examples\n\n1. **Google DiRT \u2014 annual multi-day company-wide drill.** Founded in 2006, run for ~9 years by Kripa Krishnan. Tests include disconnecting entire data centers, diverting live traffic, bringing services up with known bugs, and explicitly *removing key personnel* to expose knowledge single points of failure. Rules require revert plans, cross-functional review, and VP approval for high-risk tests. ([Weathering the Unexpected, ACM Queue](https://queue.acm.org/detail.cfm?id=2371516); [10 Years of Crashing Google \u2014 LISA15](https://www.usenix.org/conference/lisa15/conference-program/presentation/krishnan))\n2. **Google break-glass credential rehearsal during DiRT.** From *Building Secure and Reliable Systems* ch. 16: \"SREs tested the procedure and functionality of break-glass credentials: could they gain emergency access to the corporate and production networks when standard ACL services were down?\" This is the literal Vault-root-token-during-an-outage problem. ([BSRS ch.16](https://google.github.io/building-secure-and-reliable-systems/raw/ch16.html))\n3. **The 50% Rule and the \"if a human touches it, it's a bug\" doctrine.** Google caps SRE toil at 50% of each engineer's time, currently averaging ~33%. The framing: *\"If a human operator needs to touch your system during normal operations, you have a bug.\"* ([SRE Book ch.5 \u2014 Eliminating Toil](https://sre.google/sre-book/eliminating-toil/))\n4. **AWS GameDay + Operational Readiness Review (ORR).** Werner Vogels formalized GameDays as one of six cloud-architecture principles. ORR is a curated checklist distilled from real AWS incidents that every new service must pass before launch, and again periodically. ([REL12-BP05 Conduct game days regularly](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html); [AWS ORR docs](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html))\n5. **Wheel of Misfortune (Google's low-stakes drill format).** A \"Dungeon Master\" simulates an outage; on-call engineers must walk through diagnosis using real dashboards. Crucially the DM is allowed to declare \"the engineer who knows that is on a plane with no signal\" \u2014 exposing knowledge SPOFs without a real outage. ([Cloud Blog: Shrinking time to mitigate](https://cloud.google.com/blog/products/management-tools/shrinking-the-time-to-mitigate-production-incidents))\n\n### Specific tools / runbooks / cadences\n\n- **DiRT cadence:** Annual company-wide event + continuous smaller scenarios. Test rules require revert plans, comms protocols, and tiered approval.\n- **Wheel of Misfortune:** Weekly to monthly per-team, ~1 hour, no production impact. Templates published.\n- **AWS ORR:** Built into Well-Architected Tool; checklist re-run on every major change, not once.\n- **Error Budget Policy:** When budget burns past threshold, feature freeze until reliability work catches up. Forces toil-reducing engineering into the schedule ([SRE Workbook \u2014 Error Budget Policy](https://sre.google/workbook/error-budget-policy/)).\n- **MTTM (Mean Time To Mitigation) as the headline SLI** for incident response, not MTTR \u2014 measured from page-ack to user-impact-stopped.\n\n### War stories / notable failures\n\n- **GitLab 2017** \u2014 the canonical \"five backup methods, none worked\" disaster: pg_dump silently failed, DMARC rejected the alert emails, LVM snapshots weren't enabled on the DB server, replication had stopped. They lost 6 hours of data and recovery took 18 hours over throttled disk. Lesson: *untested backups are not backups, and tested-once is not tested.* ([GitLab postmortem](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/))\n- **Google's own change-induced emergency** (SRE Book, Emergency Response): rollback procedures had *never been tested in a test environment*, so when they were needed in prod they were flawed and extended the outage. Direct quote: *\"Because we hadn't tested our rollback procedures in a test environment, these procedures were flawed.\"* ([SRE Book ch.14](https://sre.google/sre-book/emergency-response/))\n- **DiRT hidden-dependency find:** Krishnan documents an exercise blocking access to \"just one of a hundred\" MySQL shards and discovering services in unrelated parts of Google were hard-coded against that specific shard.\n\n### Lessons for any small operation\n\n1. **Operator-only runbooks are toil that we explicitly accept as toil \u2014 and the price of admission is rehearsal.** Without rehearsal you have a write-only runbook, which is worse than no runbook.\n2. **Test break-glass before you need it.** Schedule a \"Vault is sealed, the operator with the unseal key shards is unreachable, here's the runbook \u2014 go\" drill. If the answer involves logging into something protected by ESO-from-Vault, you've found a circular dependency to fix.\n3. **Add an ORR-style checklist gate before each phase completes.** Each phase milestone should have an \"ORR\" sub-task with checklist items derived from the chapter \u2014 *backups tested by restore, not by existence; alerts tested by intentional failure; key personnel removed from one drill per quarter.*\n4. **Define an SLO for the control-plane itself**, not just the workloads on top. \"Vault unseal-to-serving < 15 min after reboot, measured monthly.\" Burn the error budget through a deliberate restart drill. This converts \"did Vault come back?\" from anecdote to data.\n5. **Treat \"the engineer who knows\" as a SPOF.** Run one Wheel-of-Misfortune per month where the person who built the system is in the spectator chair, not the player chair.\n\n### Further reading\n\n- [SRE Book ch.5 \u2014 Eliminating Toil](https://sre.google/sre-book/eliminating-toil/)\n- [SRE Book ch.14 \u2014 Managing Incidents / Emergency Response](https://sre.google/sre-book/emergency-response/)\n- [Weathering the Unexpected \u2014 ACM Queue (Krishnan, 2012)](https://queue.acm.org/detail.cfm?id=2371516)\n- [10 Years of Crashing Google \u2014 LISA15 (Krishnan)](https://www.usenix.org/conference/lisa15/conference-program/presentation/krishnan)\n- [Cloud Blog: Shrinking time to mitigate](https://cloud.google.com/blog/products/management-tools/shrinking-the-time-to-mitigate-production-incidents)\n- [Building Secure and Reliable Systems, ch.16](https://google.github.io/building-secure-and-reliable-systems/raw/ch16.html)\n- [SRE Workbook \u2014 Error Budget Policy](https://sre.google/workbook/error-budget-policy/)\n- [AWS Operational Readiness Reviews](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)\n- [AWS REL12-BP05 \u2014 Conduct game days regularly](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)\n- [GitLab 2017 Postmortem](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)\n- [HashiCorp Vault: Emergency break-glass features](https://developer.hashicorp.com/vault/tutorials/operations/emergency-break-glass-features)\n\n---\n\n## 7. Key ceremonies\n\n> *The pattern in 2-3 sentences:* A **key ceremony** is a scripted, witnessed, video-recorded, tamper-evident event in which a quorum of unaffiliated humans physically come together to generate, activate, or rotate an irreducible root secret stored in (or splittable into) shares \u2014 typically an HSM master key, a CA root private key, or in our case Vault unseal shares. The discipline rests on four pillars: **scripted procedure read aloud**, **dual control / M-of-N quorum**, **tamper-evident physical artifacts** (bags, safes, smartcards with serial numbers), and **independent witnesses + audit logs that outlive every participant**. The whole point: no single human, no single facility, no single moment of compromise can fabricate the root.\n\n### Concrete real-world examples\n\n1. **ICANN DNSSEC Root KSK Ceremony** \u2014 the gold standard. Held quarterly in two geographically-separated facilities (El Segundo, CA and Culpeper, VA). **3-of-7 Crypto Officers** activate the HSM (operational signing); **5-of-7 Recovery Key Share Holders** can reconstruct the Storage Master Key if disaster recovery is needed. Officers are unaffiliated \"Trusted Community Representatives\" \u2014 not ICANN/PTI/Verisign employees. Each ceremony follows a pre-published script, is filmed on multiple cameras (live-streamed), witnessed by external auditors, and produces hash-chained audit logs retained for 10 years. Cadence: Q1/Q2/Q3/Q4, no later than 33 days before each cycle. Ceremony scripts and videos are public at . The DPS is at .\n\n2. **Let's Encrypt Root Ceremonies** \u2014 \"Generation Y\" hierarchy (ISRG Root YR RSA-4096 / ISRG Root YE ECDSA P-384) generated September 2025. Let's Encrypt publishes **ceremony configs in git before the ceremony** at , using their open-source `boulder` ceremony tool. Pre-ceremony previews are posted to the Mozilla `dev-security-policy` list for community scrutiny. This is the modern \"ceremony-as-code\" pattern: pinned tool version, declarative YAML inputs, reproducible outputs.\n\n3. **Public CA root ceremonies under CA/Browser Forum rules** \u2014 every WebTrust-audited CA (DigiCert, Sectigo, GlobalSign, Entrust) follows the same skeleton mandated by Ballot SC40 (\"Security Requirements for Air-Gapped CA Systems\"): offline root, FIPS 140-2 L3 HSM, M-of-N smartcard activation, tamper-evident bags, dual-tier physical access, signed video recording. Each publishes a Certificate Policy / Certification Practice Statement (CP/CPS) describing the procedure to the byte.\n\n4. **Code-signing HSMs (Microsoft / Apple / Google Play)** \u2014 since June 2023 the CA/Browser Forum mandates code-signing private keys be generated and held only on FIPS 140-2 L3+ HSMs (Azure Dedicated HSM, AWS CloudHSM, Google Cloud HSM). Initial generation requires a Key Generation Ceremony (KGC); a \"Bring Your Own Auditor\" can witness, but the report must cover every mandated step or the ceremony is invalidated and must be redone.\n\n5. **AWS CloudHSM / Thales Luna / nCipher nShield smartcard ceremonies** \u2014 the operational primitive most enterprises copy. Luna's PED (PIN Entry Device) ceremony splits the HSM activation secret across N \"blue/black/red\" smartcards using Shamir; nShield uses ACS/OCS card sets. Both are the direct architectural ancestors of Vault's Shamir scheme.\n\n### Specific tools / runbooks / cadences\n\n- **Pre-published scripts**: ICANN's quarterly scripts (PDF, signed) \u2014 every word the Ceremony Administrator will read is fixed weeks ahead. \n- **Ceremony-as-code**: Let's Encrypt's `ceremony-demos` repo pins boulder tool versions via `CEREMONY_BIN_YYYY` env vars; configs are YAML; outputs are publicly diffable.\n- **Tamper-evident kits**: numbered/signed evidence bags (e.g., TydenBrooks 7000 series), safes with dual-keyed locks (CO key + Safe Custodian key \u2014 neither alone suffices), HSM smartcards in individual sealed envelopes.\n- **Cadence**: ICANN quarterly; KSK rollover every ~5 years; Vault quarterly **unseal drills** are HashiCorp's explicit recommendation ().\n- **Witness logs**: paper logbook, scribe transcript, video \u2014 three independent streams so any single tampering is detectable.\n\n### War stories / notable failures\n\n- **DigiNotar (2011)** \u2014 total CA compromise; **531+ fraudulent certs** (including \\*.google.com used to MITM Iranian users). Root cause cascade: single admin account spanning all 8 CA servers, **no central logging**, no critical-system segregation, and log files lived on the same compromised hosts so forensics couldn't reconstruct what was issued. DigiNotar was distrusted by every major browser within weeks and went bankrupt. Black Tulip report: . **Lesson:** logs that live on the audited system are not logs.\n- **Comodo (2011)** \u2014 an RA partner (InstantSSL.it) with plaintext credentials in CSR submission allowed 9 fraudulent certs (mail.google.com, login.yahoo.com, addons.mozilla.org). Comodo had outsourced trust to RAs whose security it didn't oversee. . **Lesson:** delegated trust without continuous attestation is no trust.\n- **SSLMate's CA failure timeline** () is the single best survey of what goes wrong: misissuance, weak validation, EOL crypto, lost private keys.\n\n### Lessons for a Vault Shamir 3-of-5 ceremony\n\n1. **Write the script before the ceremony, commit it to git, read it aloud.** Treat the unseal ceremony like ICANN: every action the operator will take is pre-typed in `runbooks/vault-init.md`, including verbatim verification lines (\"Operator reads aloud: 'Share 1 envelope serial XXXXX, seal intact, signed by custodian Alice'\"). The script is reviewed in PR before it's executed.\n2. **Quarterly unseal drills.** HashiCorp explicitly recommends this. Schedule a calendar reminder; rehearse with all 5 custodians; record times-to-quorum. This is also the only way to catch \"custodian Alice changed jobs and lost her share\" before a real outage.\n3. **PGP-encrypt the shares at `vault operator init` time** using each custodian's published GPG key (`-pgp-keys=alice.asc,bob.asc,...`). The operator who runs `init` never sees a plaintext share. This closes Vault's documented init-time exposure window where shares are printed to one human's terminal.\n4. **Tamper-evident physical storage + geographic distribution.** Shares in numbered tamper-evident bags inside a sealed envelope inside a safe; **no two shares in the same building**. Mirror ICANN's logic: a fire, a subpoena, or a coercion event against one site cannot reach quorum.\n5. **Two-stream audit log.** Write actions to (a) a paper logbook signed by the operator + an independent witness present in the room or on video, and (b) a video recording stored outside the controller VM. DigiNotar's lesson: logs on the audited system are not logs.\n\n### Further reading\n\n-  \u2014 ICANN Root KSK ceremony scripts, videos, and audit packages (the gold standard reference)\n-  \u2014 DNSSEC Practice Statement\n-  \u2014 the actual ~100-page procedure document\n-  \u2014 accessible explainer for someone new to ceremonies\n-  \u2014 Let's Encrypt ceremony configs (the \"ceremony-as-code\" reference)\n-  \u2014 example of community pre-review\n-  \u2014 CA/Browser Forum air-gapped CA requirements\n-  \u2014 Black Tulip / DigiNotar postmortem\n-  \u2014 comprehensive CA failure timeline\n-  \u2014 HashiCorp's official Shamir best practices\n\n---\n\n## 8. GitOps for stateful infrastructure\n\n> *The pattern in 2-3 sentences:* The mature pattern treats Vault like any other stateful database: a one-time operator-driven `init` (secret zero) followed by **declarative config reconciliation** \u2014 policies, auth methods, KV mounts, and roles live in git, applied by either Terraform (`hashicorp/vault` provider) or Ansible (`community.hashi_vault`) under a **scoped admin token**, never root. Consumers (workloads, ESO, ARC) never touch the operator path \u2014 they use **Kubernetes auth** so the Kubernetes service-account JWT becomes \"secret zero,\" eliminating the chicken-and-egg of storing a Vault token in a K8s Secret.\n\n### Concrete real-world examples\n\n1. **HashiCorp Validated Patterns \u2014 \"Define Vault policies with HCP Terraform\"** is the canonical reference. A Terraform workspace whose state holds policy HCL, auth method config, and KV mounts; the apply runs with a Vault token bound to a scoped admin policy (not root) and is gated by PR review. URL: https://developer.hashicorp.com/validated-patterns/vault/manage-vault-with-terraform\n\n2. **Celonis engineering** wrote a detailed postmortem on a multi-cluster ESO rollout: 0.9.1 \u2192 0.16.2 broke because the new ESO dropped `externalsecrets/v1alpha1` while Argo CD still pushed v1alpha1 manifests, and rollback was impossible because storage-version conversion had already mutated some objects. They now version-pin ESO per-cluster and stage CRD-bearing upgrades. https://careers.celonis.com/blog/updating-crds-through-breaking-changes\n\n3. **`ncorrare/vault-policy`** (GitHub) \u2014 a public reference repo showing the AppRole-scoped CI pattern: every PR runs `vault policy fmt` + `vault policy write -name=test`, plan/diff is posted as a PR comment, and merge to `main` triggers `vault policy write` with a short-lived token. https://github.com/ncorrare/vault-policy\n\n4. **Codefresh blog** (a real platform team's writeup) layers Argo CD + Vault + ESO in production: Argo manages workload manifests, ESO syncs `ExternalSecret` CRs from Vault paths, and Vault's *own* config (policies, auth methods) is managed by a separate Terraform workspace. https://codefresh.io/blog/gitops-secrets-with-argo-cd-hashicorp-vault-and-the-external-secret-operator/\n\n5. **Container Solutions / b-nova / Verifa** consultancy writeups consistently show ESO Kubernetes-auth setups where the cluster's API server signs the JWT that ESO presents to Vault, and Vault's `token_reviewer_jwt` validates it via `system:auth-delegator`. This is the **secret-zero-via-Kubernetes-trust** pattern. https://verifa.io/blog/comparing-methods-for-accessing-secrets-in-vault-from-kubernetes/\n\n### Specific tools / runbooks / cadences\n\n- **Terraform `hashicorp/vault` provider** v4.x: resources `vault_policy`, `vault_auth_backend`, `vault_kubernetes_auth_backend_role`, `vault_kv_secret_backend_v2`. Run in CI via `terraform plan` \u2192 PR comment \u2192 manual approve \u2192 `terraform apply`. State file lives in S3/GCS with locking.\n- **Ansible `community.hashi_vault` collection** for shops without Terraform: use `vault_write` with `changed_when: false` for known-idempotent writes, since most write modules can't guarantee idempotence \u2014 this is documented and is the single biggest landmine. https://docs.ansible.com/projects/ansible/latest/collections/community/hashi_vault/vault_write_module.html\n- **Drift cadence**: nightly `terraform plan` in CI; non-empty plan posts to Slack and opens a \"drift\" issue. Several teams run `pre-commit` hooks (`terraform fmt`, `vault policy fmt`).\n- **CRD upgrade ritual for ESO**: stage per-cluster, never trust `helm upgrade --reuse-values` for CRD bumps, snapshot etcd before storage-version migrations.\n- **Vault auth methods**: enable `kubernetes` first (for in-cluster workloads + ESO), `approle` for CI runners (short TTLs, response wrapping), keep `userpass` disabled in prod.\n\n### War stories / notable failures\n\n- **Celonis ESO CRD upgrade** (above) \u2014 the canonical \"GitOps tool ate its own state\" failure. Lesson: storage-version conversion is one-way; you cannot trivially downgrade once the operator has rewritten objects.\n- **`terraform-provider-vault` issue #1907**: in 3.16.0+ the provider validates the token at *init* time, so the classic \"bootstrap Vault and configure it in one `terraform apply`\" idiom broke silently. Many teams' Day-1 pipelines snapped overnight on a minor-version bump. https://github.com/hashicorp/terraform-provider-vault/issues/1907\n- **`vault_generic_endpoint` perpetual drift** (issue #842) \u2014 this resource always reports changes; teams who used it for \"everything not yet a typed resource\" got noisy plans and learned to wrap it with `lifecycle { ignore_changes = [...] }` or graduate to typed resources.\n- **ESO operator hang** (kubernetes-external-secrets #362): the sync loop silently stops, no errors, metric flatlines. Lesson: alert on `external_secrets_sync_calls_total` rate, not just on operator pod liveness.\n\n### Lessons for our project\n\n1. **Add a `roles/vault_config/` Ansible role** that owns policies, auth methods, KV mounts, and Kubernetes-auth roles \u2014 kept distinct from `roles/vault/` which owns the binary and listener config. The config role is the *only* thing that should run on Day-2; the server role is frozen after Day-1.\n\n2. **Create a scoped `controlplane-configurer` Vault policy** \u2014 `auth/*`, `sys/policies/acl/*`, `sys/mounts/*` with `create,read,update,delete,list` but **no** `read` on `kv/*` data paths. Generate a token with this policy, store it in 1Password, export it as `VAULT_TOKEN` in CI / on operator's laptop. Document the rotation cadence in `runbooks/vault-configurer-rotate.md`.\n\n3. **Every `community.hashi_vault.vault_write` task must have explicit `changed_when:`** (lint rule). Until then we're flying blind on idempotence.\n\n4. **k3s workloads (ARC, ESO) authenticate via Kubernetes auth**, never AppRole, never static token. The `kubernetes_host` and `token_reviewer_jwt` config are managed by the `vault_config` role; the bound role's policies live as files under `roles/vault_config/files/policies/`.\n\n5. **Nightly drift check**: a CI job runs `ansible-playbook playbooks/vault_config.yml --check --diff` against the live Vault and fails loudly if diff is non-empty. This is our equivalent of `terraform plan` drift detection.\n\n### Further reading\n\n- https://developer.hashicorp.com/validated-patterns/vault/manage-vault-with-terraform \u2014 HashiCorp's own validated pattern for codifying Vault\n- https://developer.hashicorp.com/vault/docs/configuration/programmatic-best-practices \u2014 official \"don't use root token\" doctrine\n- https://external-secrets.io/latest/provider/hashicorp-vault/ \u2014 ESO's Vault provider reference (read the Kubernetes-auth section carefully)\n- https://external-secrets.io/latest/examples/gitops-using-fluxcd/ \u2014 FluxCD + ESO worked example\n- https://www.hashicorp.com/en/blog/solving-secret-zero-with-vault-and-openshift-virtualization \u2014 HashiCorp's framing of the secret-zero problem\n- https://careers.celonis.com/blog/updating-crds-through-breaking-changes \u2014 the ESO CRD-upgrade postmortem; required reading before any ESO bump\n- https://github.com/hashicorp/terraform-provider-vault \u2014 the provider, plus its issue tracker which is a goldmine of gotchas\n- https://github.com/ncorrare/vault-policy \u2014 minimal reference of policies-in-git with CI\n- https://docs.ansible.com/projects/ansible/latest/collections/community/hashi_vault/index.html \u2014 the Ansible collection; note idempotency caveats on every write module\n- https://github.com/jeffsanicola/vault-policy-guide \u2014 opinionated guide to policy authoring\n- https://verifa.io/blog/comparing-methods-for-accessing-secrets-in-vault-from-kubernetes/ \u2014 side-by-side of VSO vs ESO vs Agent Injector\n\n---\n\n## 9. Chaos\n\n> *The pattern in 2-3 sentences:* A disaster recovery plan you have never executed is a fiction. The chaos-engineering and game-day discipline \u2014 pioneered at Netflix, formalized at Google, and now standard across AWS, Stripe, and Shopify \u2014 says: schedule deliberate, time-boxed failures against production-like systems on a recurring cadence, document what breaks (including the runbooks and the humans), and turn every surprise into a fix before it surprises you in the middle of the night.\n\n### Concrete real-world examples\n\n1. **Netflix \u2014 Chaos Monkey / Simian Army (2011 \u2192 today).** Originated the practice. Chaos Monkey randomly terminated EC2 instances *in production* during business hours so engineers had to design for instance failure. The original SimianArmy repo is archived; Chaos Monkey lives on as a Spinnaker-integrated standalone tool. The broader family \u2014 Chaos Gorilla (kill an AZ), Chaos Kong (kill a region), Latency Monkey, Conformity Monkey \u2014 encoded the idea of progressively wider blast radii. https://netflix.github.io/chaosmonkey/ and https://github.com/Netflix/SimianArmy.\n\n2. **Google \u2014 DiRT (Disaster Recovery Testing), since 2006.** Kripa Krishnan's \"Weathering the Unexpected\" (CACM, 2012) describes an *annual, company-wide, multi-day* event. Two characteristic rules: (a) tests run against live systems, and (b) \"critical personnel, area experts, and leaders\" are explicitly excluded so the bench gets exercised. Scenarios range from datacenter loss to \"the person who knows how to do X is on a plane.\" https://cacm.acm.org/magazines/2012/11/156583-weathering-the-unexpected/fulltext and the LISA15 retrospective \"10 Years of Crashing Google\" https://www.usenix.org/conference/lisa15/conference-program/presentation/krishnan.\n\n3. **Stripe \u2014 `kill -9` on Redis primary.** Stripe's public write-up \"Game Day Exercises at Stripe\" describes a fraud-scoring service whose three-node Redis cluster *lost all data* when they killed the primary, because a config change made the day before turned out to be incompatible with snapshotting. Found in a planned afternoon, not at 3 a.m. Their quick-start checklist: dev team + someone with network/provisioning rights + a blocked afternoon. https://stripe.com/blog/game-day-exercises-at-stripe.\n\n4. **Shopify \u2014 BFCM Game Days.** Shopify runs Game Days every spring through fall against the analytics pipeline and \"Critical Journey\" endpoints in preparation for Black Friday/Cyber Monday. 2024 surfaced: Kafka partition counts insufficient for spikes, API memory leaks, connection-pool exhaustion. https://shopify.engineering/bfcm-readiness-2025.\n\n5. **AWS \u2014 GameDay framework, codified in the Well-Architected Reliability Pillar (REL12-BP05).** AWS's \"Build Your Own Game Day\" prescribes a 5-stage method: identify key services \u2192 map people/process/tech \u2192 define and run failure scenarios \u2192 observe \u2192 retrospective. Tooling: AWS Fault Injection Simulator (FIS), CloudWatch, X-Ray. https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_testing_resiliency_game_days_resiliency.html and https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/.\n\n### Specific tools, runbooks, cadences\n\n- **Principles (the canonical text):** https://principlesofchaos.org/ \u2014 four steps (steady-state \u2192 hypothesis \u2192 inject variable \u2192 try to disprove); advanced principles emphasise *minimize blast radius* and *prefer production*.\n- **Kubernetes-native injection:** Chaos Mesh (CNCF, CRD-driven: PodChaos, NetworkChaos, StressChaos, IOChaos) https://chaos-mesh.org/; LitmusChaos with its ChaosHub of pre-built experiments https://litmuschaos.io/. Both work on k3s.\n- **Vault DR Fire-Drill:** HashiCorp's documented procedure \u2014 back up primary, demote, promote secondary using DR operation tokens, redirect traffic, then fail back. https://support.hashicorp.com/hc/en-us/articles/4408969695763-How-to-perform-vault-DR-Fire-Drill. Snapshot/restore SOP: https://developer.hashicorp.com/vault/docs/sysadmin/snapshots/restore.\n- **Gremlin's GameDay roles** (Owner / Coordinator / Reporter / Observer): https://www.gremlin.com/community/tutorials/how-to-run-a-gameday \u2014 a tight 4-role model that maps cleanly to small teams.\n- **Typical session length:** 2\u20136 hours. Plan ~1 month in advance, calendar-block the team, retro afterwards.\n\n### War stories\n\n- **Stripe Redis (above):** the lesson wasn't \"kill -9 is dangerous\" \u2014 it was that two safe-looking config changes (snapshotting + replication tweak) combined into data loss only under the exact failover the runbook claimed to support.\n- **Google DiRT, recurring finding:** when the on-call expert is \"on a plane,\" the documented runbook frequently turns out to be in the head of the person who is unreachable. This is *why* DiRT bans experts from participating.\n- **Shopify analytics:** Kafka partition counts that were \"fine\" passed every load test but starved consumers at BFCM peak \u2014 only discovered because a Game Day simulated peak + a failed broker simultaneously.\n- **AWS Well-Architected war games:** teams running \"lose production account\" scenarios discovered their CloudFormation templates *did* let them rebuild in another region \u2014 but their runbooks and SOPs lagged the templates by months.\n\n### Lessons for our project\n\n1. **Quarterly cadence, not annual.** Google's annual DiRT works because they have a chaos team; we don't. Quarterly keeps muscle memory fresh and matches typical Vault unseal-key rotation and runner-image rebuild cycles. Each drill: ~half a day.\n2. **Start with a tabletop, escalate to live fire over 2 quarters.** Tabletops are cheap and surface \"who does what\" gaps; live exercises surface the gaps tabletops can't (silent dependencies, stale runbooks). Source: https://uptimelabs.io/learn/tabletop-vs-live-incident-response/.\n3. **First live drill: Vault snapshot restore on a throwaway VM.** Smallest blast radius, highest payoff \u2014 Vault losing data takes the whole control plane down. Follow the documented fire-drill procedure but on a *cloned* VM, not production. Confirm `runbooks/vault-restart.md` reflects reality.\n4. **Second drill: kill the k3s node, watch ARC.** Power off the Proxmox VM. Time how long until runners are unreachable, until alerts fire, until the operator-only `arc-github-app-seed.md` would be re-needed. Use Chaos Mesh `PodChaos` for finer-grained drills once the basics work.\n5. **Bench the expert.** Borrow Google's rule: rotate who runs the drill. If only one person knows how to recover Vault, that's the bug \u2014 not the answer. Capture every \"huh, that's odd\" moment as a `PITFALLS.md` entry the same day.\n6. **Bound blast radius with a written rollback.** Every drill ticket must include the exact `git revert` / `vault operator raft snapshot restore` / `ansible-playbook --tags=\u2026` rollback command before the drill starts. Owner has the kill switch.\n\n### Further reading\n\n- https://principlesofchaos.org/ \u2014 the canonical 4-step / 5-principle definition. Read first.\n- https://stripe.com/blog/game-day-exercises-at-stripe \u2014 short, concrete, \"we lost all our Redis data and were grateful\" story.\n- https://cacm.acm.org/magazines/2012/11/156583-weathering-the-unexpected/fulltext \u2014 Krishnan on DiRT's philosophy and rules of engagement.\n- https://www.usenix.org/conference/lisa15/conference-program/presentation/krishnan \u2014 \"10 Years of Crashing Google,\" LISA15 talk video + slides.\n- https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_testing_resiliency_game_days_resiliency.html \u2014 AWS REL12-BP05, the most prescriptive enterprise checklist.\n- https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/ \u2014 AWS's 5-stage build-your-own framework.\n- https://www.gremlin.com/community/tutorials/how-to-run-a-gameday \u2014 Owner/Coordinator/Reporter/Observer role split.\n- https://shopify.engineering/bfcm-readiness-2025 \u2014 large-scale game-day program tied to a known peak event.\n- https://support.hashicorp.com/hc/en-us/articles/4408969695763-How-to-perform-vault-DR-Fire-Drill \u2014 Vault-specific drill steps.\n- https://chaos-mesh.org/ and https://litmuschaos.io/ \u2014 CNCF chaos tooling that runs natively on k3s.\n- https://github.com/dastergon/awesome-chaos-engineering \u2014 curated index of further reports, papers, and tools.\n\n---\n\n## 10. Kubernetes\n\n> *The pattern in 2-3 sentences:* Kubernetes has the same circular dependency Vault does: the cluster's source of truth (etcd) holds the credentials, the credentials authenticate kubeadm/kubelets that talk to the API server, and the API server lives on top of etcd. The community resolves this with **(a) bootstrap tokens** \u2014 short-lived, prefix-identified bearer tokens that establish initial bidirectional trust between joining nodes and the control plane; and **(b) a \"bootstrap-and-pivot\" pattern** in Cluster API, where a throwaway local cluster (kind) creates the real management cluster, then transfers its own CRDs into the target and self-destructs.\n\n### Concrete real-world examples\n\n1. **kubeadm bootstrap tokens** \u2014 the canonical primitive. Format `[a-z0-9]{6}.[a-z0-9]{16}` (e.g., `abcdef.0123456789abcdef`), 24-hour TTL by default. `kubeadm token create --ttl 2h --print-join-command` produces the join string; the discovery half uses a CA pubkey hash so the joiner can't be phished by a fake API server. Docs: \n\n2. **Cluster API (CAPI) bootstrap-and-pivot** \u2014 kubernetes-sigs/cluster-api's accepted workflow. Create a local kind cluster \u2192 install CAPI controllers \u2192 declare your management cluster as CR \u2192 `clusterctl move` pivots all CAPI objects into the freshly-built cluster \u2192 tear down kind. Scott Lowe's writeup is the rookie-readable version: \n\n3. **Rancher backup-restore-operator** \u2014 Helm-installable operator that backs up *the Rancher app's CRs* (clusters, users, settings) to S3, independent of any single downstream cluster's etcd. Lets you nuke the local cluster and redeploy Rancher onto a fresh one. Repo: \n\n4. **Velero** \u2014 the de-facto \"Kubernetes-resource-aware\" backup tool. Backs up cluster API objects (selectively, by namespace/label) + PV data via CSI snapshots or restic/kopia. Crucially complementary to etcd snapshots: etcd protects against infrastructure failure, Velero against fat-fingered deletes and lets you *restore into a different cluster*. \n\n5. **k3s embedded-etcd snapshot to S3** \u2014 built-in. `k3s server --etcd-s3 --etcd-s3-bucket=... --etcd-snapshot-schedule-cron='0 */12 * * *' --etcd-snapshot-retention=5` runs automatic snapshots. Restore is `systemctl stop k3s && k3s server --cluster-reset --cluster-reset-restore-path=` then start normally. \n\n### Specific tools / runbooks / cadences\n\n- **etcd snapshots:** `ETCDCTL_API=3 etcdctl --endpoints=$EP --cacert=ca.crt --cert=server.crt --key=server.key snapshot save snap.db`. Recommended cadence: every 30 min for high-write clusters, every 6\u201312h for low-churn (our case). Test restore monthly in a sandbox.\n- **k3s snapshots:** scheduled snapshots are **on by default** at 00:00 and 12:00, retention 5. Add `--etcd-s3*` flags to replicate offsite.\n- **Velero schedules:** `velero schedule create daily-full --schedule=\"@daily\" --ttl=720h0m0s` is the standard incantation. Combine with `--include-namespaces` to scope.\n- **CNCF \"Surgeon's Handbook\":** five-step surgical restore \u2014 restore snapshot to a *local* etcd, `etcdctl get /registry/configmaps//`, decode with `auger`, validate, `kubectl apply --dry-run=server`. Recover individual resources without nuking the cluster. \n- **Server token discipline:** k3s encrypts bootstrap data inside the snapshot with the server token (`/var/lib/rancher/k3s/server/token`). **Lose the token, lose the snapshot.** Back up the token file alongside every snapshot.\n\n### War stories and notable failures\n\n- **etcd v3.5.0\u2013v3.5.2 data inconsistency** (2022) \u2014 silent divergence between members. CNCF advisory: do not run these versions; `--experimental-initial-corrupt-check` now default in v3.6. \n- **Monzo 2017 outage** \u2014 etcd + Linkerd interaction killed the payments platform; presented at KubeCon: \n- **Grafana Cloud Hosted Prometheus, 2020** \u2014 stuck TCP connection to a dead etcd master broke the cluster despite quorum: \n- **Tesla 2018 kubeconfig leak** \u2014 exposed Kubernetes dashboard let attackers mine crypto on Tesla's AWS bill. The canonical \"do not leave admin kubeconfig lying around\" story.\n- **Power-outage etcd corruption** \u2014 repeatedly reported (kubernetes/kubernetes#128735, etcd-io/etcd#18881). Single-node etcd + dirty shutdown = WAL corruption. Recovery requires snapshot restore; live data is gone.\n- **Rancher k3s S3-restore wipes cluster bug** \u2014 rancher/rancher#42251 \u2014 restoring from S3 in some k3s versions wiped the cluster cleanly when token mismatched. Hard-won lesson: **token != snapshot key != optional**.\n\n### Lessons for our single-node k3s + ARC stack\n\n1. **Embedded etcd, not SQLite.** k3s defaults to SQLite for single-node. Switch to embedded etcd (`--cluster-init`) so `k3s etcd-snapshot save` and the `--cluster-reset` restore flow are available. The added complexity is worth the production-grade DR story.\n2. **Snapshots to S3 from day one, with the token.** Add `--etcd-s3 --etcd-s3-bucket=dgx-k3s-snapshots` to the k3s systemd unit. **Separately back up `/var/lib/rancher/k3s/server/token`** \u2014 to Vault KV or 1Password \u2014 because the snapshot is useless without it. Document in a `runbooks/k3s-restore.md`.\n3. **Velero on top of etcd snapshots.** Two layers: etcd snapshots for \"the box died\" disasters; Velero for \"Claude deleted the ARC namespace at 2am\" disasters. Velero backups go to the same S3 bucket, different prefix.\n4. **Bootstrap the admin kubeconfig like a Vault root token.** Treat `/etc/rancher/k3s/k3s.yaml` as a break-glass credential: encrypt at rest, never commit, rotate after every operator use. Daily work uses a `cluster-admin` ServiceAccount kubeconfig.\n5. **Quarterly restore drill.** Restore the latest S3 snapshot into a kind cluster on the operator's laptop and confirm ARC's RunnerScaleSets, ESO, and Vault references all reconcile. Untested backups are theatre. Add a `runbooks/k3s-restore-drill.md` and put a calendar reminder in `tasks.json`.\n\n### Further reading\n\n-  \u2014 authoritative spec for kubeadm bootstrap tokens\n-  \u2014 official \"operating etcd for k8s\" guide\n-  \u2014 the etcd project's own DR doc, including multi-member rebuild\n-  \u2014 k3s-specific backup/restore\n-  \u2014 full reference for `k3s etcd-snapshot` flags\n-  \u2014 CAPI quickstart; shows the kind-bootstrap \u2192 pivot flow\n-  \u2014 readable walkthrough of \"chicken-and-egg\" pivot\n-  \u2014 Velero's own DR playbook\n-  \u2014 surgical single-resource recovery from etcd snapshots\n-  /  \u2014 curated index of public postmortems\n\n---\n\n## 11. Workload identity\n\n> *The pattern in 2-3 sentences:* \"Secret zero\" is the bootstrap credential a workload needs to fetch all its other credentials \u2014 and if it leaks, the whole castle falls. The workload-identity movement (SPIFFE/SPIRE, AWS IRSA, GCP WIF, Azure Workload ID, Vault's Kubernetes auth method) eliminates that bootstrap secret by deriving identity from **cryptographically-verifiable platform attestation** (TPM measurements, cloud-metadata APIs, signed Kubernetes ServiceAccount JWTs) instead of distributing a shared password. The workload proves *what it is* \u2014 and the identity infrastructure issues a short-lived SVID/token in response, with no human-managed key ever touching disk.\n\n### Concrete real-world examples\n\n1. **Uber** runs SPIRE across **~250,000 nodes and 4,500 services** spanning GCP, OCI, AWS and on-premise. SPIRE agent ships in their \"golden\" OS image; node attestation uses container-launcher trust + node aliases; an LRU cache let them fit **2.5\u00d7 more workloads per host group** while cutting server CPU 40%. [Uber Engineering Blog (2023)](https://www.uber.com/us/en/blog/our-journey-adopting-spiffe-spire/)\n2. **Bloomberg** authored the open-source [`spire-tpm-plugin`](https://github.com/bloomberg/spire-tpm-plugin) using TPM 2.0 credential activation \u2014 node identity is rooted in the TPM endorsement key, signed by the manufacturer CA. Presented at KubeCon NA 2020 / SPIFFE Production Identity Day.\n3. **Square** uses SPIFFE/SPIRE to issue mTLS identities to payment-processing services *and* AWS Lambda functions across their hybrid infrastructure \u2014 the same trust domain spans VMs, containers, and serverless.\n4. **Google Cloud** has [standardized on SPIFFE across GCP](https://github.com/spiffe/spire/blob/main/ADOPTERS.md) as the unified workload-identity platform; Anthropic, Netflix, Pinterest, ByteDance/TikTok, GitHub, Twilio, Niantic and Duke Energy (microgrid TPM attestation) are listed adopters.\n5. **AWS IRSA** is the de-facto pattern on EKS: pods get an OIDC-signed ServiceAccount JWT, hand it to STS `AssumeRoleWithWebIdentity`, and receive short-lived IAM credentials \u2014 **no static AWS keys in any pod**. [AWS docs](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).\n\n### Specific tools, runbooks, cadences\n\n- **SPIRE server + agent**, one agent per node, communicating with workloads via a **Unix Domain Socket** (`/run/spire/agent.sock`) \u2014 no network auth needed because UDS peer credentials prove the caller's PID, which workload attestors then map to a pod/process. [SPIRE Concepts](https://spiffe.io/docs/latest/spire-about/spire-concepts/)\n- **Node attestors** (pick one): `k8s_psat` (projected ServiceAccount tokens validated against the K8s TokenReview API), `aws_iid`, `gcp_iit`, `tpm_devid` (Bloomberg plugin), `join_token` (one-shot, manual \u2014 last resort).\n- **Workload attestors**: `unix` (UID/GID/binary path), `k8s` (queries kubelet for pod metadata), `docker`.\n- **SVIDs**: X.509 certs (default ~1 hr TTL) or JWT-SVIDs. Workloads re-fetch automatically before expiry \u2014 agents keep a cache so brief server outages don't kill the fleet.\n- **Cadence**: trust-bundle / root-CA rotation requires planned coordination (especially in federated trust domains); test in staging. [SPIFFE scaling docs](https://spiffe.io/docs/latest/planning/scaling_spire/)\n- **Vault K8s auth**: pod presents its projected SA token to Vault \u2192 Vault calls `TokenReview` on the K8s API \u2192 returns short-lived Vault token. Bind a \"reviewer\" SA with the **`system:auth-delegator`** ClusterRole. [Vault K8s auth docs](https://developer.hashicorp.com/vault/docs/auth/kubernetes)\n\n### War stories & notable failures\n\n- **The bootstrap chicken-and-egg with Vault K8s auth**: when Vault lives *outside* the cluster (the exact topology of our project \u2014 Proxmox VM, external k3s), you must hand Vault a long-lived `token_reviewer_jwt` so it can call TokenReview. That long-lived token *is* a small secret zero. HashiCorp explicitly calls this out: [\"External Vault Kubernetes Auth\" discuss thread](https://discuss.hashicorp.com/t/external-vault-kubernetes-auth/36318). Mitigation: rotate it on a schedule, or run Vault inside the cluster so the projected SA token is used automatically.\n- **SPIRE \"trust the platform\" caveat**: standard attestors (`k8s_psat`, `aws_iid`, `join_token`) trust the orchestrator \u2014 if an attacker compromises the K8s API server or EC2 metadata, they can register rogue agents. Only **TPM/TEE-backed attestation** (Bloomberg's plugin, Red Hat's Keylime+SPIRE integration) closes that gap: [Red Hat \u2014 SPIFFE/SPIRE + Keylime](https://next.redhat.com/2025/01/24/spiffe-spire-and-keylime-software-identity-based-on-secure-machine-state/).\n- **\"Almost no one can afford to build it right\"**: Aembit and others note that successful SPIRE adopters (Uber, Indeed, Macquarie Bank) dedicated **platform-engineering teams** for months and upstreamed fixes. A 2-VM homelab is the wrong scale for full SPIRE.\n- **Single SPIRE server = SPOF**: must run nested topology or HA replicas; DB read-replicas are how Uber scaled.\n\n### Lessons for our stack\n\n1. **Yes \u2014 use Vault's Kubernetes auth method for ESO and ARC, not static tokens.** Pods present their projected SA JWT; Vault validates via TokenReview. This is the smallest, most idiomatic step away from secret zero we can take *today*, and it's what ESO docs recommend for production.\n2. **Accept the one residual secret: the `token_reviewer_jwt`.** Because Vault lives in a Proxmox VM outside k3s, document its rotation in a runbook (`docs/runbooks/vault-token-reviewer-rotate.md`) on a 90-day cadence. Consider migrating Vault *into* k3s in Phase 7 to eliminate even that.\n3. **Skip SPIRE for Phase 1.** Two DGX nodes + one VM is below the threshold where SPIRE pays for itself \u2014 Vault K8s auth + ServiceAccount projected tokens covers ~90% of the value at ~10% of the operational cost. Revisit SPIRE only if/when we add a third trust boundary.\n4. **Plan for TPM attestation on the DGX Sparks themselves.** The Sparks have TPMs. Even without SPIRE, we can use the TPM for `tang`/`clevis` LUKS unlock and (later) for Vault's TPM auth method or a future SPIRE TPM node-attestor migration. This is the *only* path that fully solves the bottom turtle.\n5. **Use Vault response wrapping (`-wrap-ttl`) for any unavoidable secret hand-off** \u2014 e.g., the initial GitHub App private key seeding in `arc-github-app-seed.md`. The operator unwraps once; if interception occurred, the wrapper is already consumed.\n\n### Further reading\n\n- [Solving the Bottom Turtle (free PDF book)](https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf) \u2014 the canonical 200-page introduction\n- [Uber Engineering \u2014 Our Journey Adopting SPIFFE/SPIRE at Scale](https://www.uber.com/us/en/blog/our-journey-adopting-spiffe-spire/) \u2014 most detailed production case study\n- [Bloomberg `spire-tpm-plugin`](https://github.com/bloomberg/spire-tpm-plugin) \u2014 hardware-rooted node identity\n- [SPIRE Concepts](https://spiffe.io/docs/latest/spire-about/spire-concepts/) \u2014 agent/server architecture\n- [SPIRE ADOPTERS.md](https://github.com/spiffe/spire/blob/main/ADOPTERS.md) \u2014 current list of named production users\n- [HashiCorp Vault \u2014 Kubernetes auth method](https://developer.hashicorp.com/vault/docs/auth/kubernetes)\n- [GitGuardian \u2014 The Secret Zero Problem](https://www.gitguardian.com/nhi-hub/the-secret-zero-problem-solutions-and-alternatives) \u2014 accessible rookie explainer\n- [CyberArk \u2014 Can SPIFFE Solve the Secret Zero Problem?](https://developer.cyberark.com/blog/can-spiffe-solve-the-secret-zero-problem/)\n- [AWS IRSA introduction](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)\n- [Red Hat \u2014 SPIFFE/SPIRE + Keylime](https://next.redhat.com/2025/01/24/spiffe-spire-and-keylime-software-identity-based-on-secure-machine-state/)\n\n---\n\n## 12. Supply chain\n\n> *The pattern in 2-3 sentences:* You cannot \"audit\" your way to a trustworthy binary by reading source \u2014 Ken Thompson proved in 1984 that a malicious compiler can hide a backdoor in *itself* and in any program it builds, leaving source code clean. The modern answer isn't a single audit; it's a stack of overlapping techniques \u2014 **reproducible (bit-identical) builds, signed provenance attestations, transparency logs, and bootstrappable toolchains** \u2014 so that \"trust\" becomes \"independently re-derivable from a tiny, hand-auditable seed plus public source.\" The XZ backdoor (2024) and SolarWinds (2020) are the two case studies that prove every layer of this stack matters.\n\n### Concrete real-world examples\n\n1. **Debian Reproducible Builds \u2014 bit-for-bit verifiable archive.** Debian 14 (\"Forky\") will mandate reproducible packages: every `.deb` must be byte-identical when independently rebuilt by anyone. They run a public rebuilder farm at `tests.reproducible-builds.org` that continuously rebuilds the archive and publishes diffs (`diffoscope`, the tool, is the workhorse \u2014 it recursively unpacks any container/archive and diffs the contents semantically).\n2. **NixOS / Bootstrappable Builds \u2014 256-byte seed.** NixOS PR #227914 builds the entire `stdenv` from a ~512-byte hex seed via `stage0-posix` \u2192 `M2-Planet` \u2192 `GNU Mes` \u2192 `tinycc` \u2192 `gcc`. Combined with GNU Guix's parallel effort, Mes has now been DDC-verified across three distros \u00d7 three GCC versions, all producing bit-identical output.\n3. **Sigstore (Cosign + Fulcio + Rekor) \u2014 keyless signing for OCI.** Kubernetes, Distroless, npm (since 2023), and PyPI all publish to Rekor. The CNCF Cosign workflow in GitHub Actions issues a short-lived cert tied to the workflow's OIDC identity (e.g. `https://github.com/org/repo/.github/workflows/release.yml@refs/tags/v1.2.3`) \u2014 there is no long-lived signing key to steal.\n4. **SLSA v1.0 build track (Google/OpenSSF).** Levels L0 \u2192 L3. L1 = provenance exists. L2 = hosted build with signed provenance. L3 = build isolation + signing material inaccessible to user steps. The reference implementation is the `slsa-github-generator` set of reusable workflows.\n5. **in-toto layouts (CNCF).** A signed YAML \"layout\" declares the expected supply chain steps (`clone \u2192 test \u2192 build \u2192 sign`), the authorized actor per step, and how artifact hashes must flow between steps. Used in production by Datadog, SolarWinds (post-incident), and Toradex's Torizon OS for IoT provenance.\n\n### Specific tools / runbooks / cadences\n\n- **`diffoscope`** \u2014 investigate non-determinism between two builds; output is a recursive HTML/JSON diff.\n- **`reprotest`** \u2014 Debian tool that builds a package twice while varying time, locale, path, hostname, build user, etc., to surface non-determinism sources.\n- **`cosign sign --yes `** in GitHub Actions with `id-token: write` permission, paired with `cosign verify --certificate-identity-regexp ... --certificate-oidc-issuer https://token.actions.githubusercontent.com` in admission/CI.\n- **`slsa-verifier`** \u2014 validates SLSA provenance attestations against expected source repo, builder, and entry point.\n- **Cadence:** Debian rebuilders run continuously; Sigstore root key ceremonies happen ~yearly with public attendance and recorded video; SLSA-aware projects regenerate provenance per release tag.\n\n### War stories\n\n- **XZ Utils / CVE-2024-3094 (March 2024).** \"Jia Tan\" spent ~2.5 years building maintainer trust, then planted the payload only in the *release tarball* (in `build-to-host.m4` and binary test fixtures) \u2014 the git repo was clean. Discovered by accident by Andres Freund chasing a 500 ms sshd latency regression. Lesson: **release tarballs \u2260 git source**. Reproducible builds from VCS would have caught the divergence immediately. The maintainer-burnout vector (Lasse Collin overwhelmed, one person on vacation) is now the canonical example.\n- **SolarWinds SUNBURST (2020).** Attackers planted SUNSPOT on the build server itself, watching for `MsBuild.exe` invocations and swapping a source file *during* compilation. Signed Orion DLLs went out to ~18,000 customers. The source repo was never modified. Lesson: **even signed binaries from a \"trusted\" vendor are worthless if the build platform is the threat.** SLSA L3 (build isolation) is the direct response.\n- **event-stream / flatmap-stream (Nov 2018).** Dominic Tarr handed npm publishing rights to a stranger (\"right9ctrl\") who asked nicely. The new maintainer pulled in `flatmap-stream`, which contained a Copay-wallet-targeted Bitcoin stealer activated only in a specific build environment. Lesson: **package-manager identity is weaker than the social-engineering attack against it.**\n- **log4shell (2021).** Not a backdoor, but proved that a single transitively-included library can put every JVM-running enterprise into incident-response mode for months \u2014 a forcing function for SBOMs and dependency-pinning hygiene.\n\n### Lessons for our project\n\n1. **Pin Ansible collections by checksum, not version.** `requirements.yml` accepts `version:` but not native checksum verification \u2014 wrap installs with `ansible-galaxy collection install --offline` from a tarball whose SHA-256 is committed alongside `versions.env`. Cross-check against the upstream Galaxy API in CI.\n2. **Sign the runner image with cosign keyless from GitHub Actions, verify on pull in k3s.** Use the `policy-controller` or Kyverno's `verifyImages` rule to enforce that every image admitted to the cluster has a Rekor entry whose certificate identity matches the fleet's release workflow. Same pattern for the inference image.\n3. **Generate SLSA v1.0 provenance for the runner image.** The `slsa-github-generator` reusable workflow gives this for free at L3, and `slsa-verifier` can run in the k3s admission controller. This makes the SolarWinds attack class infeasible against us \u2014 an attacker compromising a maintainer laptop cannot forge provenance tied to our GitHub OIDC issuer.\n4. **Verify upstream tarballs against their git tags before vendoring.** The XZ lesson: anything we pull as a tarball (Helm charts in particular \u2014 they ship as opaque `.tgz`) gets a `chart-from-git-vs-released-tgz` diff in CI. If they diverge without justification, fail the build.\n5. **Reproducibility as a release gate, not an aspiration.** When we bake the runner image, build it twice in two isolated runners and compare digests. If they don't match, fix the non-determinism (timestamps, locale, build paths) before shipping. Debian's `reprotest` is the model.\n\n### Further reading\n\n- [Reflections on Trusting Trust \u2014 Ken Thompson, 1984](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf) \u2014 read this once\n- [Fully Countering Trusting Trust through Diverse Double-Compiling \u2014 David A. Wheeler](https://dwheeler.com/trusting-trust/) \u2014 the formal answer\n- [SLSA v1.0 specification](https://slsa.dev/spec/v1.0/levels) \u2014 read `levels` and `provenance` pages\n- [Sigstore Cosign signing overview](https://docs.sigstore.dev/cosign/signing/overview/)\n- [XZ backdoor \u2014 Sam James's timeline gist](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27)\n- [Datadog Security Labs \u2014 XZ deep dive](https://securitylabs.datadoghq.com/articles/xz-backdoor-cve-2024-3094/)\n- [CrowdStrike SUNSPOT technical analysis](https://www.crowdstrike.com/en-us/blog/sunspot-malware-technical-analysis/)\n- [npm event-stream post-mortem (Snyk)](https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/)\n- [Debian ReproducibleBuilds wiki](https://wiki.debian.org/ReproducibleBuilds)\n- [NixOS PR #227914 \u2014 256-byte stdenv bootstrap](https://github.com/NixOS/nixpkgs/pull/227914)\n- [in-toto attestation framework](https://github.com/in-toto/attestation)\n\n---\n\n## 13. Compliance\n\n> *The pattern in 2-3 sentences:* Every major regulatory regime (NIST 800-34, SOC 2 CC7, ISO 27001 A.17 / 2022 A.5.29-30, FedRAMP, HIPAA 164.308, PCI DSS 3.6) converges on the same five demands: a written contingency plan, a documented key-management lifecycle with named custodians, **annual tested** restores (not just backups), tabletop exercises with after-action reports, and an immutable evidence trail proving the test happened. The single most common audit failure is \"backups exist, restores never tested.\" For a control plane that runs Vault and k3s, this means the unseal ceremony, ARC GitHub-App seed, and `etcd` snapshot restore each need a runbook, a scheduled drill, and a signed After-Action Report \u2014 even if no auditor will ever read them.\n\n### Concrete real-world examples (with URLs)\n\n1. **NIST SP 800-34 Rev 1 \u2014 CP-4 contingency-plan testing.** Mandates annual functional exercises for moderate-impact systems; documented test plans must precede the drill, and \"theoretical estimates do not satisfy contingency plan testing requirements.\" Full PDF: [nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf)\n2. **NIST SP 800-57 Part 1 Rev 5 \u2014 key lifecycle.** Defines generation \u2192 distribution \u2192 storage \u2192 use \u2192 rotation \u2192 archival \u2192 destruction, with cryptoperiods tied either to key age or message volume. [csrc.nist.gov/pubs/sp/800/57/pt1/r5/final](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)\n3. **SOC 2 CC7.4 / CC7.5 \u2014 system operations.** Requires a SIEM, vulnerability scanning, incident-response plan, and **annual DR test**. In a Type 2 period with zero incidents, a **tabletop exercise is the minimum bar** to demonstrate the IRP is \"operationally known to the team.\" [auditfront.com/frameworks/soc-2/common-criteria/cc7-1](https://www.auditfront.com/frameworks/soc-2/common-criteria/cc7-1/)\n4. **ISO 27001:2022 A.5.29 + A.5.30** (replacing the older A.17). A.5.30 is the new \"ICT readiness for business continuity\" \u2014 explicit RTO/RPO per service and tested recovery procedures. [certpro.com/iso-27001-2022-controls](https://certpro.com/iso-27001-2022-controls/)\n5. **PCI DSS v4.0 \u00a73.6.8** \u2014 **cryptographic key custodians must formally acknowledge in writing** that they accept their responsibilities; manual processes require split knowledge and dual control (e.g., 3-of-5 Shamir quorum). [blog.rsisecurity.com/pci-compliance-key-management-requirements](https://blog.rsisecurity.com/pci-compliance-key-management-requirements/)\n6. **HIPAA 45 CFR \u00a7164.308(a)(7).** Five required implementation specs: Data Backup Plan, Disaster Recovery Plan, Emergency Mode Operation Plan, Testing & Revision Procedures, Applications/Data Criticality Analysis. [ecfr.gov/current/title-45/.../section-164.308](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308)\n7. **FedRAMP Moderate ISCP template** \u2014 the actual `.docx` agencies fill out. Daily incremental + weekly full backups; annual functional exercise. [fedramp.gov/.../REV_4_SSP-A06-FedRAMP-ISCP-Template.docx](https://www.fedramp.gov/assets/resources/documents/rev4/REV_4_SSP-A06-FedRAMP-ISCP-Template.docx)\n\n### Specific runbook/document templates auditors expect\n\n- **Information System Contingency Plan (ISCP)** \u2014 FedRAMP template above is the gold standard; sections: roles, BIA, RTO/RPO matrix, activation criteria, recovery procedures, reconstitution, plan-maintenance schedule.\n- **Key Custodian Acknowledgement Form** \u2014 one-page signed PDF per custodian (PCI 3.6.8). Lists named key, custodian's quorum share number, rotation cadence, escape clause on termination.\n- **Key Ceremony Script** \u2014 step-by-step, two-person-rule, with checkboxes initialled by each custodian; counterpart in our world is `vault-init.md`.\n- **After-Action Report (AAR)** \u2014 date, scenario, participants, timeline of events vs. plan, gaps, owners, due dates. Often the *only* artefact an SOC 2 auditor asks to see for CC7.5.\n- **Test Schedule** \u2014 quarterly tabletop, annual full restore, ad-hoc after major change. Tracked in a register the auditor pulls.\n- **BIA (Business Impact Analysis)** \u2014 what dies if Vault stays sealed for 24 h? for 7 days? Drives the RTO.\n\n### War stories\n\n- **Equifax (2017).** GAO report [GAO-18-559](https://www.gao.gov/assets/gao-18-559.pdf) and the [MIT CAMS case study](https://cams.mit.edu/wp-content/uploads/2021-06-PUBLISHED-MISQE-Applying-the-Lessons-from-the-Equifax-Cybersecurity-Incident.pdf) document that **internal audit had flagged patching and certificate-expiry gaps before the breach but findings were never closed**. Cost: $1.38 B and the CEO's job. The lesson is not \"patch faster\" \u2014 it's \"make audit findings have owners and due dates that the board sees quarterly.\"\n- **Capital One (2019).** $190 M fine despite state-of-the-art cloud. Root cause: an over-privileged WAF role + missing detective controls. Their key management *was* good; their access-management telemetry was not.\n- **The \"9-month SOC 2 remediation.\"** Per [compassitc.com](https://www.compassitc.com/blog/what-happens-if-you-fail-a-soc-2-examination), a client with no DR capability had to build the program, configure backups, set RTO/RPO, run tests, and write runbooks \u2014 and the auditor still demanded **nine months of operating evidence** before clearing the exception. Moral: start the clock today, not the quarter before your first audit.\n\n### Lessons for an unregulated shop\n\n1. **Sign a Vault Key-Custodian Acknowledgement.** Three Shamir-share holders, named, dated, with rotation policy. Costs 20 minutes; satisfies PCI 3.6.8 thinking; forces honest discussion of \"what if a custodian quits?\"\n2. **Quarterly tabletop, annual restore.** Pick a date, run \"Vault VM lost\"; do an actual `etcd snapshot restore` + Vault unseal in the lab from cold media. Write the AAR to `docs/runbooks/drill-reports/YYYY-MM-DD.md`. This is the single artefact a SOC 2 auditor would ask for first.\n3. **Publish RTO/RPO per service.** Vault: RTO 1 h / RPO 24 h. k3s control plane: RTO 4 h / RPO 24 h. ARA: best-effort. Without these numbers, \"DR plan\" is just vibes.\n4. **Make findings have owners and due dates.** Treat every PITFALLS entry like an audit finding: open ticket, owner, ETA, close-out evidence. Equifax died from open findings, not unknown ones.\n5. **Auto-generate evidence.** The runbook should `tee` to a timestamped log; commit it. \"Cutover-style immutable audit log\" is overkill for us, but a `git log` of drill reports is the same idea on a budget.\n\n### Further reading\n\n- [NIST SP 800-34 Rev 1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf) \u2014 read \u00a73.4 (Testing, Training, and Exercises)\n- [NIST SP 800-57 Part 1 Rev 5](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf) \u2014 \u00a75.3 cryptoperiods, \u00a78 lifecycle states\n- [CMS Key Management Handbook](https://security.cms.gov/learn/cms-key-management-handbook) \u2014 readable real-world translation\n- [AuditFront SOC 2 CC7.1 implementation guide](https://www.auditfront.com/frameworks/soc-2/common-criteria/cc7-1/)\n- [FedRAMP ISCP template](https://www.fedramp.gov/assets/resources/documents/rev4/REV_4_SSP-A06-FedRAMP-ISCP-Template.docx)\n- [eCFR 45 CFR \u00a7164.308](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308)\n- [PCI key-management deep dive (RSI Security)](https://blog.rsisecurity.com/pci-compliance-key-management-requirements/)\n- [ISO 27001:2022 changes (CertPro)](https://certpro.com/iso-27001-2022-controls/)\n- [USENIX: Running DR Tabletop Exercises](https://www.usenix.org/publications/loginonline/running-disaster-recovery-plan-tabletop-exercises)\n- [GAO-18-559: Equifax response report](https://www.gao.gov/assets/gao-18-559.pdf)\n\n---\n\n## 14. Homelab\n\n> *The pattern in 2-3 sentences:* Small-team and homelab operators have converged on a remarkably consistent stack: a **declarative Git repo as the source of truth**, a **single bootstrap command** that gets you from bare metal to reconciling cluster, a **pull-based GitOps agent** (Flux or Argo CD) that closes the loop, and **encrypted-secrets-in-Git** (SOPS+age) instead of a separately-operated secret server. The discipline that distinguishes the survivors from the cargo-cult is **testing the bootstrap by actually destroying and rebuilding** \u2014 and writing the recovery doc as a printed PDF stored offline, not a wiki page on the server you just lost.\n\n### Concrete real-world examples\n\n1. **[onedr0p/home-ops](https://github.com/onedr0p/home-ops)** \u2014 The canonical \"k8s-at-home\" reference. Talos + Flux + Renovate + external-secrets-operator backed by 1Password Connect. Volsync handles PVC backup/restore. Demonstrates that one person can run Ceph, Cilium, Istio, and a Cloudflared ingress without losing weekends \u2014 because Renovate auto-PRs every dependency and Flux applies on merge.\n2. **[khuedoan/homelab](https://github.com/khuedoan/homelab)** \u2014 \"Empty disk to running services with a single `make` command.\" PXE boot \u2192 Ansible \u2192 k3s \u2192 Argo CD root-app \u2192 everything else. A great study in the **root-app pattern**: bootstrap installs exactly one Argo Application that manages itself plus all children.\n3. **[Stan's blog: Moving my personal infra to single-node k3s](https://stanislas.blog/2025/04/moving-to-k8s/)** \u2014 A working example of the *exact* shape we're building: one node, k3s, Flux, Renovate, cert-manager, Restic. Bootstrap = one curl command. Recovery = `rsync /etc/rancher /var/lib/rancher` and re-run install. Explicitly evaluated and rejected Longhorn + Velero as \"overkill.\"\n4. **[nlewo/comin](https://github.com/nlewo/comin)** \u2014 GitOps-for-NixOS in pull mode. The NixOS analogue to Flux: machines poll their own config from Git. Worth knowing exists even if you stay on Ubuntu \u2014 it's the cleanest expression of \"the machine reconciles itself.\"\n5. **[chrisleekr/homelab-infrastructure](https://github.com/chrisleekr/homelab-infrastructure)** \u2014 Two-stage IaC (Ansible bootstrap \u2192 Terraform app stack) on single-node k8s. Closest structural analogue to our control-plane + fleet split.\n\n### Specific tools / patterns / cadences\n\n- **Renovate, not Dependabot.** Renovate understands Helm charts, container digests, Ansible Galaxy roles, and Terraform modules. Configure it for `automerge: true` on patch updates of trusted images and `dependencyDashboard: true` so all pending updates show up as one tracking issue.\n- **Pinning by digest, not tag.** Every serious homelab repo pins container images and Helm charts by SHA. Renovate rewrites the digest on update.\n- **SOPS + age, not Vault.** For a two-person team, running Vault *as a consumer* is sensible; running it just to store five secrets is not. The homelab pattern is `.sops.yaml` with two age recipients (one per engineer), keys backed up on YubiKeys or a paper-printed master.\n- **Pull-mode reconciliation.** Flux/Argo/comin all *pull* from Git. The control plane never needs an inbound CI hook. Tailscale ACLs (or just SSH-over-Tailscale) handle the human-access side.\n- **The \"weekly chore\" cadence.** Solo operators don't do quarterly DR drills \u2014 they do a Sunday-morning `restic check` and a monthly \"destroy a non-prod VM and re-bootstrap from scratch\" exercise. That's the cadence that keeps the runbook honest.\n\n### War stories\n\n- **SourceHut's [PXE-boot post-mortem-as-feature](https://sourcehut.org/blog/)** \u2014 After a server refused to boot from disk and they had to \"hastily assemble DHCP configs,\" they built a permanent PXE-boot setup specifically so the *next* recovery would take minutes. The lesson: every incident should leave behind one piece of permanent automation.\n- **Drew DeVault's [in-housing of DNS](https://drewdevault.com/)** \u2014 SourceHut moved DNS *back* in-house against industry advice, on the principle that \"we are proud believers in owning our infrastructure rather than operating at planet scale.\" Small teams can absolutely run real infrastructure; the trick is choosing fewer pieces, not fewer features.\n- **[Tailscale's three-person infra team](https://tailscale.com/blog/infra-team-stays-small)** \u2014 They explicitly eliminated entire problem categories rather than scaling staffing: ACLs replace per-resource auth, overlay networking replaces VPC peering, their internal `setec` replaces per-cloud secrets managers, automatic TLS replaces a PKI rotation rota. **The pattern: collapse N tools into 1 wherever identity already crosses the boundary.**\n- **[Grumpy.systems' bus-factor post](https://grumpy.systems/2023/preparing-for-you-homelabs-demise/)** \u2014 Best concrete bus-factor advice on the open web. Weekly auto-generated PDF of recovery procedures + encrypted config bundle, uploaded to cloud *and printed*. Tested with \"could my partner actually recover photos if I died tomorrow?\"\n\n### Lessons for our project (the 80/20)\n\n1. **Treat the bootstrap as the test.** Our \"done\" definition already runs `bash bootstrap.sh` from a fresh checkout \u2014 make that a literal CI job that spins up a Proxmox VM weekly and runs end-to-end. khuedoan and onedr0p both do this; it's why their READMEs aren't stale.\n2. **Renovate over manual digest bumps.** We already have a fleet-repo workflow that PRs digest updates via `versions.env`. Extend Renovate config to also bump Helm chart digests (ARC, ESO, ARA) and Ansible collection versions. Auto-merge patch, human-approve minor, block major.\n3. **Print the runbook. Literally.** Our three operator-only runbooks (`vault-init.md`, `arc-github-app-seed.md`, `auto-unseal-migration.md`) should generate a PDF artifact in CI, with the operator-only token-handling sections highlighted. Store on a USB drive in a fireproof box. This is the homelab community's actual practice, and it's the right move for a two-person team where one person's laptop is the bus factor.\n4. **Drop \"observability backend\" until you've used it in anger.** Stan's blog explicitly cut Longhorn + Velero as overkill on a single node. For two engineers + one control plane VM + two DGX boxes, Prometheus + Loki + a dashboard is fine; don't add Tempo, Mimir, or an SLO platform until you've actually had an incident that needed them.\n5. **Keep Vault, but only as a *consumer* problem.** The homelab consensus is \"don't run Vault as a hobbyist.\" We have a real reason (ESO + ARC need a KV store with identity-aware auth), so keep it \u2014 but lean hard on the existing rule that Vault never restarts on play apply, and treat the operator-only init runbook as sacred. Don't add Vault as the store for ops-only secrets when SOPS+age would do; that's the line where homelab pragmatism beats enterprise instinct.\n\n### Further reading\n\n- [Tailscale \u2014 How our infrastructure team stays small](https://tailscale.com/blog/infra-team-stays-small) \u2014 the canonical \"boring infra for tiny teams\" essay\n- [onedr0p/home-ops](https://github.com/onedr0p/home-ops) \u2014 read the `kubernetes/apps/` layout and `.github/renovate.json5` configs\n- [khuedoan/homelab](https://github.com/khuedoan/homelab) \u2014 the single-command bootstrap pattern\n- [Stan \u2014 Moving to single-node k3s](https://stanislas.blog/2025/04/moving-to-k8s/) \u2014 closest analogue to our control-plane VM shape\n- [Grumpy Systems \u2014 Preparing for your homelab's demise](https://grumpy.systems/2023/preparing-for-you-homelabs-demise/) \u2014 bus-factor planning\n- [SourceHut blog](https://sourcehut.org/blog/) \u2014 Drew DeVault on owning DNS, PXE boot for fast recovery\n- [nlewo/comin](https://github.com/nlewo/comin) \u2014 pull-mode GitOps for NixOS\n- [Managing secrets with SOPS in your homelab (codedge)](https://www.codedge.de/posts/managing-secrets-sops-homelab/)\n- [k3sup (alexellis)](https://github.com/alexellis/k3sup) \u2014 bootstrap k3s over SSH in under 60 seconds\n- [Tailscale \u2014 Workload identity federation](https://tailscale.com/blog/workload-identity-beta)\n\n---\n\n# Part III \u2014 Synthesis and action\n\n## 15. Unified methodology\n\nAcross 10 chapters, 50+ companies, and 100+ cited URLs, the same pattern keeps emerging. We call it the **Bootstrap Operations Methodology** (BOM), and it is six rules:\n\n### Rule 1: Separate the three buckets, ruthlessly\n\n- **Identity** (root keys, unseal shards, operator credentials) lives offline, in N-of-M distribution, on devices that survive the destruction of any other system.\n- **Data** (Vault contents, etcd, NAS files) lives in backups on a *different blast radius* than the source. Test restores, don't just count snapshots.\n- **Config** (policies, manifests, playbooks) lives in code, applied idempotently by an agent that holds only the privilege to apply config \u2014 never to read data.\n\nEvery mixed bucket is a future incident. The discipline is permanent.\n\n### Rule 2: Reduce privilege immediately after every bootstrap\n\n- Day-0 root tokens exist for ~30 minutes during init, then revoke.\n- Day-1 admin tokens exist for the duration of one operator session, then revoke.\n- Day-2 config-applier tokens exist for the duration of one CI run, then revoke.\n- The longest-lived credential should be the smallest-privileged one.\n\nThis is the principle of least privilege applied to its own meta-configuration. It's how Vault's `admin` policy is structured, how Google's break-glass procedures work, how AWS's IAM Role assumption works.\n\n### Rule 3: Treat operator-only runbooks as code\n\n- Versioned in git, reviewed in PRs, executed verbatim from a printed copy.\n- Each contains an explicit \"this is operator-only because X\" justification.\n- Each is rehearsed on a scheduled cadence (quarterly minimum).\n- Each generates an After-Action Report on every execution (real or drill).\n\nThe fact that humans execute them doesn't make them informal \u2014 it makes the *review discipline tighter*, not looser, because there's no CI to catch errors.\n\n### Rule 4: Untested DR is fiction\n\n- Backups exist? Restore them. Quarterly.\n- Runbook exists? Execute it. Quarterly.\n- Person knows it? Remove them from the drill. Quarterly.\n- Document the After-Action Report. Always.\n\nGoogle DiRT, AWS GameDays, ICANN ceremonies, FedRAMP, SOC 2, NIST 800-34 \u2014 every mature operator has converged on the same answer: only tested recovery counts. GitLab 2017 is the parable everyone cites for a reason.\n\n### Rule 5: Improve the bootstrap, continuously\n\n- Every incident produces one piece of permanent automation (SourceHut's PXE lesson).\n- Every PITFALLS entry has an owner and a due date (Equifax's lesson).\n- Every runbook is dated; if it's been > 12 months since execution, it's stale.\n- Every cycle through the system reduces toil somewhere (Google's 50% rule).\n\nThe bootstrap layer is itself a product. It needs roadmaps, retrospectives, and pruning.\n\n### Rule 6: Match practices to scale\n\n- A 2-engineer team should not adopt SPIRE.\n- A 50-engineer team should not run SOPS+age for production.\n- A 500-engineer team should not skip key ceremonies.\n- A 5000-engineer team must run DiRT-class drills.\n\nThe practices scale, but blindly applying enterprise practices to a homelab is cargo cult. Pick the smallest practice that *actually* addresses the failure modes you face today, and add one practice per quarter as the scale demands.\n\n---\n\n## 16. Concrete next steps\n\nFor our DGX fleet + Proxmox-Vault project specifically, here is the prioritized backlog the research surfaced. Each item is a candidate `tasks.json` entry:\n\n### Immediate (before Phase 1 even runs)\n\n1. **Write a Key-Custodian Acknowledgement form** for the 5 Shamir shard holders. One page, signed PDF, includes named custodian, share number, rotation cadence, escape clause. Store with the runbook.\n2. **Pre-write the `vault-init.md` script word-by-word**, including verbatim verification lines (\"Operator reads aloud: ...\"). Have a peer review the script before any ceremony.\n3. **Pre-decide Vault shard destinations and verify reachability**: tabletop \"can 3 of 5 custodians be reached within 1 hour by a single operator?\" If the answer is no, redistribute.\n\n### Phase 1 (during initial bring-up)\n\n4. **Use Vault's Kubernetes auth method for ESO**, not the bootstrap-token pattern. Migrate to it during Phase 1; document the `token_reviewer_jwt` rotation in a new `runbooks/vault-token-reviewer-rotate.md`.\n5. **Add a `roles/vault_config/` Ansible role** that idempotently applies Vault policies, auth methods, KV mounts. This is the GitOps escape hatch for the \"Vault config rot\" problem. It should run on every `site.yml` apply, scoped to a `vault-config-applier` policy that can change Vault config but not read secrets.\n6. **Switch k3s to embedded etcd** (`--cluster-init`) so snapshot-and-restore are first-class. Configure `--etcd-s3 --etcd-snapshot-schedule-cron='0 */6 * * *' --etcd-snapshot-retention=28` for 6-hour snapshots, 7-day retention. Back up the server token to Vault.\n\n### Phase 6-7 (hardening)\n\n7. **Generate a printed PDF of operator-only runbooks** as a CI artifact on every release tag. Store on USB, fireproof box.\n8. **Pin Ansible collections by SHA-256**, not just version. Verify against Galaxy API in CI.\n9. **Sign the runner image with cosign keyless** from GitHub Actions. Verify in k3s admission (Kyverno or policy-controller).\n10. **Schedule quarterly drills**:\n    - Q1: 5-shard unseal drill (just verify shards are reachable from 3 destinations)\n    - Q2: Vault Raft snapshot restore on a throwaway VM\n    - Q3: k3s etcd snapshot restore on a kind cluster, verify ARC/ESO/Vault references reconcile\n    - Q4: GitHub App key rotation against staging Vault + test repo first\n\n### Future (defer until scale demands)\n\n11. **SPIRE/SPIFFE on the Sparks themselves** for workload identity \u2014 once we have a third trust boundary that isn't Vault K8s auth.\n12. **TPM-based unlock (`tang`/`clevis`)** for the Spark LUKS volumes \u2014 once we have a real threat model that demands measured boot.\n13. **SLSA L3 provenance** for inference images \u2014 once we have an inference image we ship externally.\n14. **Reproducible-builds release gate** for the runner image \u2014 once we have a regression where build non-determinism caused a confusing failure.\n\nThe first 10 items are doable in ~4 person-weeks of work, spread across Phases 1-7 as they naturally fit. The remaining items are explicit \"not yet\" decisions.\n\n---\n\n## 17. Reading order\n\nIf you read three things from this book and only three:\n\n1. **[Ken Thompson \u2014 Reflections on Trusting Trust (1984)](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf)** \u2014 three pages, the deepest formulation of the bootstrap problem. The lecture that every infrastructure engineer should encounter at least once.\n2. **[Google SRE Book ch.5 \u2014 Eliminating Toil](https://sre.google/sre-book/eliminating-toil/)** \u2014 the language of \"toil\" reframes what you do every day. After you read this, you cannot un-see toil in your own workflows.\n3. **[Solving the Bottom Turtle (SPIFFE book)](https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf)** \u2014 200 pages on workload identity, which is the field's most coherent answer to \"what does it mean to identify a piece of software.\" Even if you never run SPIRE, the mental model is foundational.\n\nIf you have a weekend:\n\n4. **[Weathering the Unexpected (Kripa Krishnan, 2012)](https://queue.acm.org/detail.cfm?id=2371516)** \u2014 Google's DiRT philosophy, written by the person who ran it for nine years.\n5. **[GitLab 2017 Postmortem](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)** \u2014 the canonical \"five backups, none worked\" parable.\n6. **[Tailscale \u2014 How our infrastructure team stays small](https://tailscale.com/blog/infra-team-stays-small)** \u2014 the right antidote to enterprise-cargo-cult thinking.\n\nIf you have a week:\n\n7. **[Site Reliability Engineering (full book, free online)](https://sre.google/sre-book/table-of-contents/)** \u2014 read chapters 1, 3, 5, 11, 14, 15. Skip the rest until you need them.\n8. **[Building Secure and Reliable Systems (Google book, free online)](https://google.github.io/building-secure-and-reliable-systems/raw/toc.html)** \u2014 chapters 8 (design for resilience), 16 (disaster planning), 17 (crisis management).\n9. **[Sam James's XZ backdoor timeline](https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27)** \u2014 what a real supply chain attack looks like, day-by-day.\n10. **[NIST SP 800-34 Rev 1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf)** \u2014 the regulator's view, which is surprisingly readable and surprisingly sensible.\n\nIf you have a month:\n\n11. **[Designing Distributed Systems (Brendan Burns)](https://azure.microsoft.com/en-us/resources/designing-distributed-systems/)** \u2014 the canonical patterns.\n12. **[The Twelve-Factor App](https://12factor.net/)** \u2014 30 minutes, foundational discipline.\n13. **[ICANN Root KSK ceremony scripts](https://www.iana.org/dnssec/ceremonies)** \u2014 actually download one of the PDFs and read it cover-to-cover. The level of choreography is humbling.\n14. **[SLSA v1.0 specification](https://slsa.dev/spec/v1.0/levels)** \u2014 supply chain levels, what each level demands.\n\n---\n\n## Closing\n\nYou started this book uncertain whether your infrastructure was reproducible. You should now be uncertain about something much more specific: *which of the three buckets is least well-defended on each tier of your stack, and what's the smallest cheapest experiment that would tell you?*\n\nThat's the question to take to your next planning meeting. The answer determines what you build next.\n\nThe bootstrap problem is not solvable in the sense that anxiety dreams of. It is *manageable* in the sense that hundreds of mature operators have shown \u2014 with separation of concerns, scoped privilege, tested recovery, and continuous improvement. The five Vault shards in five destinations, the printed runbook in the fireproof box, the quarterly drill on the calendar, the After-Action Report committed to git: these are the artifacts of an organization that has accepted that bootstrap is permanent and has built a discipline around it.\n\nYou don't need to be enterprise-scale to adopt any of this. You need to pick one practice per quarter that addresses your actual current failure mode. In four years you will have a remarkably resilient stack. In eight years your runbooks will have outlived three generations of underlying software. That is the practice.\n\nWelcome to Day 2.\n\n---\n\n*This book was assembled from 10 parallel research-agent investigations across HashiCorp Vault production deployments, Google SRE methodology, PKI key ceremonies, GitOps for stateful infrastructure, chaos engineering, Kubernetes/etcd disaster recovery, workload identity, supply chain trust, compliance-driven DR, and homelab small-team practices. Total citations: 100+. Total companies referenced: 50+. Production at: 2026-05-09.*\n", "creation_timestamp": "2026-05-13T16:50:55.000000Z"}, {"uuid": "59091ab1-dbf2-4484-b308-98d153173252", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/golangoss.bsky.social/post/3mmggir5elo2z", "content": "xzbot (\u2b50\ufe0f 3558)\n\nnotes, honeypot, and exploit demo for the xz backdoor (CVE-2024-3094)\n\n#go", "creation_timestamp": "2026-05-22T07:38:30.413183Z"}, {"uuid": "3b52478f-b999-462a-8649-31b27a8a264d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://vulnerability.circl.lu/comment/c633e2b6-9cb5-4e6e-ad24-d425f4887b8e", "content": "", "creation_timestamp": "2026-06-02T04:35:59.355688Z"}, {"uuid": "64a45ac2-5263-4abc-888e-3838fe145949", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/cvedatabase.bsky.social/post/3mncf7o6phs2k", "content": "Modern supply chain attacks like CVE-2024-3094 exploit the trust we place in open-source. Our latest blog explores how these vulnerabilities work and how to secure your CI/CD pipeline with SBOMs. Read more: https://cvedatabase.com/blog/the-silent-threat-deep-dive-into-software-supp...", "creation_timestamp": "2026-06-02T10:30:04.422959Z"}, {"uuid": "fba2613d-ac97-43e8-9985-bc58ab76a946", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://gist.github.com/billyjoelsaniceguy/6c1ab8574b9605df2b299258b06c5031", "content": "\n\n# Framework v3.1 \u00a713 Round 3 \u2014 gist-ready external review bundle\n\n> Generated 2026-06-03 for option (b) gist-dispatch workflow per Zachary direction.\n> All artifacts embedded inline; reviewer should NOT need to fetch any external resource.\n> Reviewer can paste this single file into their LLM thread; everything they need is here.\n\n## Table of contents\n\n- [Prompt](#prompt) \u2014 the Round 3 external review prompt for framework v3.1\n- [Artifact 1: Framework v3.1 architecture spec (with \u00a713 amendment)](#artifact-1-framework-v31-architecture-spec) \u2014 the full spec under review (v3.0 sections preserved verbatim per OP-6 + \u00a713 v3.1 amendment block)\n\n---\n\n## Prompt\n\n> **Source path:** scripts/external-review/PROMPT-framework-v3-OPA-INTOTO-2026-06-02.md\n> **Embedded verbatim below; do not fetch the path \u2014 reviewer environment cannot access private-repo URLs.**\n\n\n\n# External review prompt \u2014 framework v3.1 OPA + in-toto + 4-plane architecture POST-ROUND-2-AMENDMENT (GD-37 ROUND 3)\n\n> **Authored:** 2026-06-02 by Claude main as Round 2 prompt; **amended in place 2026-06-02** to Round 3 incorporating BOTH Round 2 reviewer verdicts + the v3.1 amendment \u00a713 that addresses them.\n> **Template:** B-premortem-round-3 \u2014 Klein Pre-Mortem (architecture-class change per Module Contract A+B README \u00a7Option B; same Klein structure preserved through Rounds 1, 2, and 3 for verdict comparability)\n> **Trigger:** GD-37 Round 2 returned 2 verdicts with DIVERGENT labels but CONVERGENT architectural recommendations (Reviewer 3 Sonnet 2 SHIP-WITH-CHANGES + KEEP + MEDIUM; Reviewer 4 GPT-5.4 RECONSIDER + REBUILD + HIGH). Claude main authored a v3.1 amendment \u00a713 to `scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md` in parallel with this prompt update, addressing the 5 convergent changes. Round 3 reviewer is primed to find what is MISSED BEYOND the \u00a713 v3.1 amendment \u2014 not to re-litigate v3.0.\n> **Routing:** Per `scripts/external-review/README.md` rotation block + the recursive-convergent-verdict pattern \u2192 ONE Round 3 reviewer; non-Claude family preferred (Reviewer 4 GPT-5.4 was the more-pessimistic Round 2 voice; cross-family check completed at Round 2; Round 3 may be Gemini 2.5 Pro or GPT-5 fresh thread).\n> **Reviewer instructions:** Use Gemini 2.5 Pro or GPT-5; do NOT use Anthropic Claude (defeats the purpose). One fresh thread. Self-contained \u2014 paste the entire block below.\n\n---\n\n## POST-ROUND-2-AMENDMENT STATUS (2026-06-02)\n\n> **What changed between Round 2 dispatch and Round 3 dispatch:** v3.0 spec was reviewed by TWO reviewers from DIFFERENT model families. Their verdict labels diverged (one said SHIP-WITH-CHANGES; the other said RECONSIDER + REBUILD) but their architectural recommendations CONVERGED on 5 specific changes. Claude main authored a v3.1 amendment \u00a713 to `scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md` (in parallel with this Round 3 prompt update) addressing each. The Round 3 reviewer below is primed accordingly: find what we MISSED BEYOND the 5 fixes, not what v3.0 already had wrong.\n\n### The 5 convergent architectural changes addressed by v3.1 \u00a713 amendment\n\n| # | Round 2 convergent recommendation | v3.1 \u00a713 amendment response |\n|---|---|---|\n| 1 | **Close attestation schema \u2014 NO free-text in tier_classification_evidence + panel_framings** | Schema typed-closed: `tier_classification_evidence` becomes a controlled enum of {`subject-regex-match`, `body-regex-match`, `commit-stat-bound`, `forced-tier-marker`}; `panel_framings` becomes `array` from a fixed framing registry; no free-text string survives the schema validator |\n| 2 | **Tighten Sigstore/OIDC identity binding \u2014 repo-prefix regex too loose; need workflow/ref/event claims** | `--certificate-identity-regexp` REPLACED with explicit `--certificate-identity` equality on the FULL `subject` URI including `workflow_ref` + `ref` + `event_name` claims; repo-prefix-only is forbidden; v3.1 specifies the exact OIDC subject URI grammar to anchor against |\n| 3 | **Drop commentary plane OR make optional (default OFF)** | Commentary workflow `compliance-commentary.yml` flipped to OPT-IN via repo variable `ENABLE_COMPLIANCE_COMMENTARY=true`; default OFF; absence of commentary is the new normal; reviewers can read `.attestations/.json` directly |\n| 4 | **Collapse to 2-plane design (Evidence + Policy combined; no separate Output plane)** | 4-plane spec re-architected to 2-plane: Evidence + Policy (the Sigstore-verify step lives inside the Policy plane as Rego ASSERTIONS over `input.aux.sigstore_verified`; the Enforcement workflow becomes thin plumbing not a separate trust boundary; Output collapsed to optional structured JSON log read directly from the attestation file) |\n| 5 | **Non-keyless Sigstore default (keep keyless optional)** | Sigstore keyless default \u2192 GPG-with-repo-secrets default; keyless documented as optional path with explicit Rekor-public-log-leak warning; key rotation playbook authored |\n\n### Reviewer 4 (GPT-5.4 non-Claude) distinctive specifics absorbed into v3.1\n\n- **sha256 not sha1** for `subject.digest` \u2014 v3.1 \u00a713 mandates sha256; sha1 explicitly forbidden in schema_v3.1\n- **Conftest OR small TS validator** instead of pure-OPA \u2014 v3.1 \u00a713 picks Conftest as default (OPA-Rego with simpler CLI; same Rego language; built for config validation) with TS-validator option flagged as future-work alternative\n- **Per-PR attestation NOT per-commit** \u2014 v3.1 \u00a713 changes scope: one attestation per PR (covering the PR's commit range), not one per commit; rollup attestation pattern documented\n- **Protected-base policy NOT candidate-HEAD policy** \u2014 v3.1 \u00a713 specifies `opa eval` runs against policy loaded from the BASE branch (the protected branch with branch protection), NOT from PR HEAD; closes the policy-injection gotcha flagged in `scripts/external-review/PROMPT-framework-v3-OPA-INTOTO-2026-06-02.md` open-question #6\n\n### Reviewer 3 (Sonnet 2 Claude-descendant) NOVEL load-bearing finding ABSORBED\n\nThe single most load-bearing finding from Round 2 was Reviewer 3's truth-alignment claim (Q11 + Q12 convergence): *\"v3 can canonically sign and approve the wrong clinical rule if policy/evidence semantics drift from clinical ground truth. Cryptographic correctness \u2260 clinical correctness.\"* v3.1 \u00a713 acknowledges this is NOT solvable in the cryptographic substrate; it adds a `clinical-semantic-drift` annotation field to the attestation predicate + a 90-day periodic policy-vs-clinical-truth review per OP-7. The substrate gap survives; v3.1 makes it explicit + auditable rather than masking it.\n\n### What the Round 3 reviewer is asked to find\n\nNOT: \"did v3.0 have these problems?\" (answer: yes, Round 2 documented this; v3.1 \u00a713 addresses each)\nINSTEAD: \"did the v3.1 \u00a713 amendment ACTUALLY close the gaps? What survived the amendment that's still load-bearing? What new gaps did the amendment ITSELF introduce?\"\n\nThe recursive M\u00fcnchhausen warning applies: Round 3 is the 4th external reviewer of this framework lineage (v2 had 2 \u2014 Gemini 3.1 + GPT-5.4 with thinking; v3.0 had 2 \u2014 Sonnet 2 + GPT-5.4 without thinking; v3.1 is on Round 3 = its 1st). The pattern itself is a finding: at what point does each round of fixes converge on a stable design vs introduce new architectural concerns? Calibrate verdict against trajectory.\n\n---\n\n## How Zachary dispatches this\n\n1. Open a fresh Gemini 2.5 Pro thread OR a fresh ChatGPT Plus thread (GPT-5 / GPT-5 Pro / o3 with reasoning). Round 3 may be single-reviewer; the cross-family check happened at Round 2. Paste the block under `--- BEGIN EXTERNAL REVIEW PROMPT ---` through `--- END EXTERNAL REVIEW PROMPT ---`. Send.\n2. When the reply returns: paste back into Claude main chat (label which model). Claude main parses verdict, updates `scripts/external-review/queue.jsonl` to `returned`, and integrates per Module Contract A+B README workflow.\n3. If Zachary chooses to dispatch BOTH reviewers (double-cross-family for Round 3 as well), the Decision matrix below handles divergent verdicts.\n\nIf a reviewer balks at the spec length (~1,200 lines with \u00a713 v3.1 amendment), the raw GitHub URL below lets it fetch the file directly. The prompt body itself stays under ~700 lines so it pastes cleanly.\n\n---\n\n--- BEGIN EXTERNAL REVIEW PROMPT ---\n\n# ROUND 3 CONTEXT (read before answering Q1-Q12)\n\nThis is a **SECOND post-amendment external review** of the same project's compliance-\nenforcement framework. The lineage:\n\n- **Framework v2** was reviewed by 2 external reviewers (Gemini 3.1 + GPT-5.4 with\n  thinking). BOTH returned RECONSIDER + REBUILD with HIGH confidence.\n- **Framework v3.0** was authored by the project's LLM (Anthropic Claude) synthesizing\n  the v2 reviewer recommendations into a 4-plane architecture (in-toto + Sigstore + OPA\n  + min-permissions enforcement + zero-PHI commentary output).\n- **v3.0 was reviewed by 2 external reviewers** (Reviewer 3 = Sonnet 2 Claude-descendant\n  family; Reviewer 4 = GPT-5.4 without thinking, non-Claude family). Verdict labels\n  DIVERGED (Sonnet 2 said SHIP-WITH-CHANGES + KEEP + MEDIUM; GPT-5.4 said RECONSIDER +\n  REBUILD + HIGH). But architectural recommendations CONVERGED on 5 specific changes\n  (close attestation schema; tighten Sigstore/OIDC identity binding; make commentary\n  plane optional; collapse to 2-plane design; non-keyless Sigstore default).\n- **Framework v3.1** is the spec you are reviewing. The amendment \u00a713 in the spec\n  addresses each of the 5 convergent recommendations. The Round 3 reviewer (YOU)\n  is asked the post-amendment question:\n\n**FIND WHAT WE MISSED BEYOND the 5 fixes.** Not \"did v3.0 have these problems?\" (answer:\nyes; v3.1 \u00a713 closes each). Instead:\n\n- Did the v3.1 \u00a713 amendment ACTUALLY close the gaps the Round 2 reviewers surfaced?\n- What survived the amendment that's still load-bearing?\n- What NEW architectural concerns did the \u00a713 amendment ITSELF introduce?\n- Are there second-order failure modes from collapsing 4-plane \u2192 2-plane?\n- Are there second-order risks from forcing GPG-with-repo-secrets default (vs keyless)?\n- Are there second-order risks from per-PR-not-per-commit attestation scope?\n\nYou are the 4th external reviewer of this framework lineage. The recursive pattern itself\nis a finding \u2014 at what point does each round of fixes converge on a stable design vs\nintroduce new architectural concerns? Calibrate your verdict against the trajectory:\nRECONSIDER-REBUILD (v2) \u2192 CONVERGENT-ARCHITECTURAL-RECOMMENDATIONS (v3.0 Round 2) \u2192 ???\n(v3.1 Round 3 = your verdict).\n\nYou are an INDEPENDENT, ADVERSARIAL security + architecture reviewer for a compliance\nenforcement system in a clinical-grade health-data project. The authoring model\n(Anthropic Claude) has now synthesized TWO ROUNDS of external recommendations into\nframework v3.1. You are asked to review v3.1 adversarially. You are a different model\nclass than the author on purpose.\n\nThis is a **Klein pre-mortem** review. Frame the entire response as if framework v3.1\n(with the \u00a713 amendment incorporating the Round 2 convergent recommendations) shipped\nEXACTLY AS SPECIFIED, was enabled as a required GitHub branch-protection check, and SIX\nMONTHS LATER caused serious harm \u2014 a HIPAA exposure incident, an irreversible governance\nerror that corrupts the audit trail of one person's clinical ground-truth-of-record, a\nSigstore-dependency outage OR a GPG-key-loss event that deadlocks all commits, a\npolicy-engine misconfiguration that silently passes everything, a per-PR-rollup-attestation\nflaw that masks per-commit violations, OR a regression that breaks the dashboard for the\nprimary clinical user (Zachary Witman + his treating physician Dr. Halper).\n\nTell us the failure mode. Tell us the architectural assumption you would challenge. Tell\nus what you would have built instead of v3.1 (now that v2 already failed; v3.0 needed\nRound-2 amendment; v3.1 is the second-iteration result; do you agree v3.1 is approximately\nright, or would you pick v4 = something else entirely?). Tell us the single most important\nthing the v3.1 authors didn't think about BEYOND what the \u00a713 amendment already addresses.\n\n# Project context\n\n- **Repository:** https://github.com/billyjoelsaniceguy/health-dashboard (private)\n- **Branch under review:** `claude/lucid-mccarthy-jNdjD`\n- **Raw-file URL pattern:** `https://raw.githubusercontent.com/billyjoelsaniceguy/health-dashboard/claude/lucid-mccarthy-jNdjD/`\n- **Stakes:** Clinical ground-truth-of-record for ONE specific person's health data,\n  shared with a treating physician. Wrong audit-row marked PASS that should have FAILED\n  \u2192 potential clinical decision risk. PHI leak via CI comment, PR comment, attestation\n  file, or push notification \u2192 HIPAA Safe Harbor violation. CI workflow generates\n  failure email per push \u2192 the same 28-email-incident that triggered the v1\u2192v2 pivot\n  recurs.\n- **Authoring model:** Anthropic Claude (the subject of the review). You are NOT that\n  model; that asymmetry is the entire point. v3 was Claude-authored SYNTHESIZING the\n  convergent verdict you (or your peer) issued in Round 1; the question is whether v3\n  actually escapes the failures you identified, or whether Claude encoded its own blind\n  spots into the v3 design while implementing your recommendations.\n\n# What \"framework v3.1\" is (one paragraph)\n\nA **2-plane architecture (v3.1 \u00a713 amendment collapse from v3.0's 4-plane)** that\nREBUILDS the watcher entirely after framework v2 failed adversarial audit + v3.0 failed\nthe Round-2 architectural-recommendations convergence test: **Evidence plane** = in-toto\nsigned attestation file (cryptographic binding via Sigstore GPG-with-repo-secrets DEFAULT\nper v3.1 \u00a713; keyless OIDC documented as optional with Rekor-public-log-leak warning)\ncommitted to repo at `.attestations/.json` (per-PR scope per v3.1 \u00a713, NOT\nper-commit), with sha256 (not sha1) digest binding; **Policy plane** = OPA / Conftest /\nRego declarative policies at `policy/rules/` loaded from the **PROTECTED-BASE branch**\n(per v3.1 \u00a713, NOT PR HEAD; closes policy-injection vector); typed-closed schema with NO\nfree-text fields (`tier_classification_evidence` is a controlled enum; `panel_framings`\nis `array` from a fixed registry); identity binding via `--certificate-identity`\nEQUALITY on the full OIDC subject URI including `workflow_ref` + `ref` + `event_name`\nclaims (per v3.1 \u00a713). The **Output plane** is COLLAPSED into Policy \u2014 optional\nstructured JSON log read directly from the attestation file. Commentary workflow is\nOPT-IN via repo variable (default OFF). Commit-body markdown is RETIRED as attestation\ncarrier. The custom Node.js regex validator from v2 is RETIRED. The clinical-semantic-\ndrift gap (Reviewer 3 truth-alignment finding Q11+Q12) is acknowledged as NOT solvable\nin the cryptographic substrate; v3.1 \u00a713 adds an annotation field + 90-day periodic\npolicy-vs-clinical-truth review per OP-7.\n\n# Lineage: v2 \u2192 v3.0 \u2192 v3.1 (the recursive convergent-verdict trajectory)\n\n**Round 1 (v2 review):** Both reviewers (Gemini 3.1 + GPT-5.4 with thinking) returned\nRECONSIDER + REBUILD with HIGH confidence. Convergent: commit-body markdown wrong as\nattestation carrier; OPA/Rego for declarative policy; signed attestation file (in-toto\n+ Sigstore); separate enforcement from commentary; TDD via external verification artifact;\npreapproved schema for digest output. Reviewer 2 specifically formulated the 4-plane\narchitecture. v3.0 adopted this.\n\n**Round 2 (v3.0 review):** TWO reviewers from DIFFERENT model families. Reviewer 3\n(Sonnet 2 Claude-descendant): SHIP-WITH-CHANGES + KEEP + MEDIUM confidence. Reviewer 4\n(GPT-5.4 without thinking, non-Claude): RECONSIDER + REBUILD + HIGH confidence. Verdict\nlabels DIVERGED. Architectural recommendations CONVERGED on 5 specific changes (the\nPOST-ROUND-2-AMENDMENT STATUS table above enumerates each). M\u00fcnchhausen signal detected:\nthe Claude-family reviewer was MORE LENIENT than the non-Claude reviewer \u2014 exactly as the\nrecursive framing predicted. Non-Claude verdict was weighted higher for M\u00fcnchhausen\nmitigation; but the architectural convergence was the load-bearing signal.\n\n**Round 3 (v3.1 review = THIS prompt):** v3.1 \u00a713 amendment addresses the 5 convergent\nrecommendations PLUS Reviewer 3's novel truth-alignment finding (Q11+Q12 cryptographic-\ncorrectness-\u2260-clinical-correctness; v3.1 \u00a713 acknowledges as substrate gap + adds\nannotation field + 90-day periodic review). Round 3 reviewer (YOU) is asked to find what\nthe \u00a713 amendment MISSED.\n\nKey Round 2 NOVEL findings (load-bearing for Round 3 attention):\n- **Reviewer 3 Q11+Q12 truth-alignment** (LOAD-BEARING; novel \u2014 neither v2 reviewer\n  surfaced this): cryptographic correctness \u2260 clinical correctness. v3.1 \u00a713 acknowledges\n  but does NOT close.\n- **Reviewer 4 Q7 OIDC identity-binding regex looseness**: `--certificate-identity-regexp`\n  using repo-prefix anchor = catastrophic acceptance vector. v3.1 \u00a713 closes by mandating\n  `--certificate-identity` EQUALITY on full URI including workflow/ref/event.\n- **Reviewer 4 Q5 Rekor public log as permanent disclosure channel**: keyless flow records\n  EVERY signature including commit SHA + branch + signing identity + timestamp in public\n  transparency log. v3.1 \u00a713 flips to GPG-with-repo-secrets default.\n- **Reviewer 4 Q3 OPA vs Conftest**: pure OPA may be too low-level; Conftest is the\n  config-validation-specific wrapper. v3.1 \u00a713 picks Conftest as default.\n- **Reviewer 4 Q4 protected-base policy**: `opa eval` from PR HEAD = policy injection\n  vector; must load policy from BASE branch. v3.1 \u00a713 closes.\n\n# The artifact you are reviewing\n\n**`scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md`** (~1,200 lines with \u00a713 v3.1 amendment;\n14 sections) \u2014 the v3.1 architecture spec. \u00a713 is the load-bearing amendment for Round 3\nreview; \u00a7\u00a71-12 are the v3.0 substrate that the amendment refines.\nhttps://raw.githubusercontent.com/billyjoelsaniceguy/health-dashboard/claude/lucid-mccarthy-jNdjD/scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md\n\nThis is a SPEC, not yet shipped code. Phases 2 through 7 of the plan (Rego/Conftest\npolicy pack authoring, attestation generator, enforcement workflow, optional commentary,\nWave-5 regression suite, v2 archival, deployment) have NOT begun. Your review is the\ngating precondition for Phase 2+ work per the recursive M\u00fcnchhausen-trilemma finding.\n\nCompanion files (referenced in spec; useful for Round 3 context):\n- `scripts/external-review/queue.jsonl` line 2 \u2014 the Round 1 convergent verdict record (v2)\n- `scripts/external-review/queue.jsonl` lines 9 + 10 \u2014 the Round 2 verdicts (v3.0):\n  Reviewer 3 SHIP-WITH-CHANGES + KEEP + MEDIUM (Sonnet 2 Claude-descendant); Reviewer 4\n  RECONSIDER + REBUILD + HIGH (GPT-5.4 non-Claude). Divergent verdicts; convergent\n  architectural recommendations\n- `scripts/compliance-schema-v1.json` \u2014 v0/v1 schema being absorbed into v3.1 predicate body\n- `scripts/INVESTIGATION-2026-06-01/W4-FINAL-SYNTHESIS-2026-06-01.md` \u2014 Wave 4 v2 findings\n  (P0 RCE + PHI leak + 6 P1 + ~15 P2 + ~30 P3; v3.1 must NOT re-introduce)\n\n# The 2 planes (v3.1 \u00a713 collapse from v3.0's 4-plane) you are reviewing\n\n> **v3.1 \u00a713 amendment** collapsed Plane 3 (Enforcement) into thin plumbing (no separate\n> trust boundary) and collapsed Plane 4 (Output / Commentary) into an OPTIONAL structured\n> JSON log read directly from the attestation file. Below is the v3.1 2-plane spec; the\n> v3.0 4-plane spec is preserved in \u00a7\u00a73-6 of the artifact for audit trail.\n\n## Plane 1 (Evidence) \u2014 in-toto + Sigstore (v3.1 \u00a713 amended)\n\nClaims:\n- Attestations live at `.attestations/.json` + `.sig` (per-PR scope per v3.1 \u00a713,\n  NOT per-commit; rollup attestation covers PR's commit range)\n- in-toto Statement format (`_type: in-toto Statement/v1`); custom predicate type\n  `https://github.com/billyjoelsaniceguy/health-dashboard/attestations/compliance-row/v3.1`\n- **Sigstore GPG-with-repo-secrets DEFAULT** (per v3.1 \u00a713; keyless OIDC documented as\n  optional with explicit Rekor-public-log-leak warning + key rotation playbook)\n- **subject.digest.sha256** (NOT sha1; v3.1 \u00a713 mandates sha256; sha1 forbidden in schema_v3.1)\n- TWO-commit flow within PR: substantive commits \u2192 attestation commit at PR-final state\n- TDD discipline: 3-commit sequence for new rules (failing test \u2192 passing rule \u2192\n  attestation)\n- **Identity binding hardened (v3.1 \u00a713)**: `--certificate-identity` EQUALITY on full\n  OIDC subject URI including `workflow_ref` + `ref` + `event_name` claims; repo-prefix\n  regex anchor is FORBIDDEN\n\n## Plane 2 (Policy + collapsed-Enforcement + optional-Output) \u2014 OPA/Conftest/Rego (v3.1 \u00a713 amended)\n\nClaims:\n- Policy at `policy/rules/` loaded from the **PROTECTED-BASE branch** (per v3.1 \u00a713;\n  closes policy-injection vector flagged by Round 2 Reviewer 4 Q4) \u2014 NOT from PR HEAD\n- **Conftest as default** (per v3.1 \u00a713; OPA-Rego with simpler CLI; built for config\n  validation); pure-OPA path documented as alternative; TS-validator flagged as future-work\n- One Rego file per audit row (J11-J16) + Magna Carta D1-D3 + Rule 3.X; tests at\n  `policy/tests/` mirror structure; fixtures at `policy/fixtures/`\n- Each rule unit-tested via `opa test`; coverage threshold \u2265 80% per rule\n- **Schema TYPED-CLOSED (v3.1 \u00a713)**: `tier_classification_evidence` is a controlled\n  enum of {`subject-regex-match`, `body-regex-match`, `commit-stat-bound`,\n  `forced-tier-marker`}; `panel_framings` is `array` from fixed registry; NO free-\n  text field survives the validator\n- v2 `compliance-schema-v1.json` ported to Rego assertions in `schema_envelope.rego` +\n  `schema_predicate_v3.rego` with v3.1 schema-typed-closure amendments\n- File-existence checks (PBS-cited files exist) are pre-resolved by GitHub-Action\n  plumbing into `input.aux.pbs_files_exist`, then asserted by Rego (Rego is sandboxed,\n  cannot read filesystem)\n- Sigstore-verify step lives INSIDE Plane 2 as Rego assertions over\n  `input.aux.sigstore_verified` (the verification is plumbing; the trust decision is policy)\n- **Clinical-semantic-drift annotation (v3.1 \u00a713)**: attestation predicate has a\n  `clinical-semantic-drift` field; substrate gap is acknowledged + auditable, not closed\n- 90-day periodic policy-vs-clinical-truth review per OP-7 (v3.1 \u00a713 addition)\n\n## Enforcement workflow (thin plumbing per v3.1 \u00a713; NOT a separate trust boundary)\n\nClaims:\n- Triggers on `pull_request` to `main` (per-PR scope per v3.1 \u00a713; push triggers narrowed)\n- Minimum permissions: `contents: read` + `id-token: write` only (only if keyless;\n  GPG-default may not need id-token: write)\n- All actions pinned to commit SHA (not version tag)\n- `fetch-depth: 0` (no shallow-clone silent pass)\n- 5-minute timeout\n- Steps: checkout \u2192 install Cosign + Conftest + OPA \u2192 `opa test` from BASE branch\n  policy/ (precondition) \u2192 identify PR's commit range \u2192 verify Sigstore signature(s),\n  assert `subject.digest.sha256 == commit_sha` (TOCTOU defense), pre-resolve PBS file\n  existence, `conftest test` against BASE policy, exit 0/1\n- ZERO outbound surface from this job: no PR comments, no Pushover, no email\n- Branch protection requires job name `enforce` to pass\n\n## Optional commentary (OPT-IN per v3.1 \u00a713; default OFF)\n\nClaims:\n- Disabled by default; enabled only when repo variable `ENABLE_COMPLIANCE_COMMENTARY=true`\n- When enabled: separate workflow `.github/workflows/compliance-commentary.yml`\n- Triggers on `workflow_run` of `compliance-enforce` completion\n- `continue-on-error: true` so commentary failures DO NOT email Zachary\n- 3-minute timeout\n- Different permissions: `pull-requests: write` + `issues: write` + `contents: read`\n- Renders ONLY from typed enums + integers + hex SHAs + project-namespaced URLs; NO\n  free-text fields rendered (schema-enforced absence)\n- Mustache-style template with no free-text passthrough; structurally impossible to render\n  commit subjects, commit bodies, or file content\n\n# The questions you are answering (12 \u2014 answer each; brief is fine)\n\n## Q1 \u2014 Does v3.1 (with \u00a713 amendment) escape the recursive M\u00fcnchhausen-trilemma? Better than v3.0? Better than v2?\n\nThe Round 1 load-bearing residual: \"auditing-by-same-model-class cannot fully escape\nitself.\" Round 2 produced a M\u00fcnchhausen signal: the Claude-family reviewer (Sonnet 2)\nwas MORE LENIENT than the non-Claude reviewer (GPT-5.4) \u2014 exactly as the recursive\nframing predicted. Round 2's convergent architectural recommendations were absorbed\ninto v3.1 \u00a713.\n\nBut: Claude still authors the Rego policy logic. Claude still authors the workflow YAML.\nClaude still authors the attestation-generator code. Claude authored the \u00a713 amendment\nincorporating the Round 2 recommendations. Claude authored THIS Round 3 prompt update.\n\nThe recursive M\u00fcnchhausen residual at Round 3 has THREE concrete questions:\n\n1. **Does v3.1 \u00a713 escape the trilemma to a meaningfully greater degree than v3.0?** Round\n   2's convergent architectural recommendations were absorbed via Claude authorship. The\n   recursive pattern: Claude authoring fixes to gaps that two external reviewers found.\n   At what point does each round of fixes converge on a stable design vs introduce new\n   architectural concerns under-noticed by the next reviewer? Estimate the delta\n   numerically: v2 \u2192 v3.0 trilemma escape was (per Round 2 Reviewer 3) ~60%. Is v3.0 \u2192\n   v3.1 a further 10%? 20%? 0% (in the sense that the \u00a713 amendment is itself LLM-authored\n   and therefore inherits the same blind spots)?\n\n2. **Is Claude's selection of WHICH Round-2 recommendations to absorb itself a M\u00fcnchhausen\n   surface?** The 5 convergent changes were absorbed; were there ANY Round 2 dissenting\n   findings (Reviewer 3 vs Reviewer 4 divergent items) that Claude SILENTLY de-prioritized?\n   The Round 3 reviewer can compare the v3.1 \u00a713 amendment scope against the original\n   Round 2 verdicts in `scripts/external-review/queue.jsonl` lines 9 + 10.\n\n3. **Does each new round introduce its own blind spots faster than it closes old ones?**\n   This is the recursive-convergence question. The trajectory: v2 \u2192 v3.0 \u2192 v3.1. At what\n   round does the framework reach diminishing returns from external review? The Round 3\n   reviewer is asked to calibrate verdict against trajectory, not absolute state.\n\nIf you think v3.1's escape attempt is a NEW form of the same trap (industry-standard tools\n+ closed schema + 2-plane collapse all wrapping LLM-authored composition is still\nLLM-authored composition), say so explicitly. Name the round at which the trilemma\nbecomes structurally insurmountable.\n\n## Q2 \u2014 Evidence plane (in-toto + Sigstore, with v3.1 \u00a713 GPG default + sha256) \u2014 correct choice vs alternatives?\n\n**v3.0 picked Sigstore keyless as default. Round 2 Reviewer 4 flagged Rekor public log\nas permanent disclosure surface. v3.1 \u00a713 flips to GPG-with-repo-secrets default\n(keyless documented as optional with explicit Rekor-leak warning). v3.1 \u00a713 also mandates\nsha256 (not sha1) for `subject.digest`.**\n\nPossible alternatives still on the table:\n- Git notes (signed via GPG; `git notes` is git-native; no separate file management)\n- SLSA L3 provenance with Cosign (more standard predicate type; ecosystem-recognized)\n- Cosign-only without in-toto (sign arbitrary JSON; lose in-toto envelope semantics)\n- TUF-style metadata + offline-signed keys (no CI dependency)\n- Custom JWT signed via GitHub App private key\n\nRound 3 questions:\n- **Is the GPG default flip the right call?** GPG repo secrets are scoped to workflow\n  but expose to compromised repo admin. Keyless was rejected for Rekor public log; is\n  GPG the right replacement, or should hardware-key (YubiKey) be the default?\n- **Is sha256 sufficient?** SHA-1 is deprecated for collision resistance; SHA-256 is the\n  current standard. Should v3.1 \u00a713 have specified SHA-3-256 instead for post-quantum\n  resilience? Or is SHA-256 the right choice given current threat model + tool support?\n- **Is in-toto the right choice or are you naming SLSA L3 alternatives?** v3.1 \u00a713 stays\n  on in-toto custom predicate type with project-namespaced URI; ecosystem compat is\n  acknowledged-not-required.\n- **Per-PR scope (v3.1 \u00a713 change from per-commit)** \u2014 does this introduce a new failure\n  mode (single broken commit in a PR survives if PR-final attestation passes)?\n\nWhat did v3.1 \u00a713 GET WRONG about the Evidence plane that Round 2 didn't catch?\n\n## Q3 \u2014 Policy plane (Conftest default per v3.1 \u00a713; loaded from BASE branch) \u2014 correct choice vs alternatives?\n\n**v3.0 picked pure OPA / Rego. Round 2 Reviewer 4 flagged Conftest as the\nconfig-validation-specific OPA wrapper. v3.1 \u00a713 picks Conftest as DEFAULT (Rego-based;\nsimpler CLI; built for config validation); pure-OPA path documented as alternative;\nTS-validator flagged as future-work. v3.1 \u00a713 also mandates policy loaded from PROTECTED-\nBASE branch (not PR HEAD; closes policy-injection vector).**\n\nPossible alternatives still on the table:\n- Pure OPA (v3.0's original choice; v3.1 \u00a713 documents as alternative)\n- Cedar (AWS's policy language; more expressive type system; fewer surface bugs)\n- WASM-bundled custom policy engine (project-internal; total control; no third-party dep)\n- TypeScript types + `ts-pattern` exhaustive matching (Reviewer 4 named this as\n  future-work; v3.1 \u00a713 documents)\n- jsonschema + ajv with custom keywords (simpler; lower learning curve)\n- Pulumi Policy as Code (closer to CI/CD-native)\n\nRound 3 questions:\n- **Is Conftest the right Rego wrapper or does it inherit pure-OPA failure modes?** v3.1\n  \u00a713 chose Conftest for the CLI simplicity but Rego is still the language. Is the\n  learning curve materially better, or marginal?\n- **Protected-BASE policy load (v3.1 \u00a713)** \u2014 is this the right policy-isolation pattern,\n  or does it introduce new attack surface (BASE policy is whatever was merged when the\n  PR was opened; what if BASE policy itself has a vulnerability the PR is exploiting)?\n- The \u00a74.5 developer flow assumed adding a rule is ~30 min. Conftest may shorten this;\n  is the new estimate realistic, or still underestimated?\n- `opa test --coverage --threshold=80` \u2014 is 80% the right bar? Why 80 not 95? Is Rego\n  coverage even meaningful (declarative language with rule activation patterns unlike\n  imperative coverage)?\n- The PBS file-existence check is pre-resolved by GitHub-Action plumbing then passed\n  into Rego via `input.aux.pbs_files_exist`. Does this re-introduce the v2 \"plumbing\n  layer is where the bugs hide\" pattern, with the plumbing now external to but feeding\n  the policy engine?\n- **Is the v3.1 \u00a713 collapse of Sigstore-verify INTO Plane 2 (as Rego assertions over\n  `input.aux.sigstore_verified`) the right call?** Or does this conflate trust\n  verification (the signature is valid) with policy decision (the attestation passes\n  rules)?\n\nWhat did v3.1 \u00a713 GET WRONG about the Policy plane that Round 2 didn't catch?\n\n## Q4 \u2014 Enforcement workflow (THIN PLUMBING per v3.1 \u00a713; no separate trust boundary) \u2014 defensive enough?\n\n**v3.0 had a separate Plane 3 (Enforcement) with its own trust boundary. v3.1 \u00a713\ncollapsed Plane 3 into THIN PLUMBING \u2014 the Sigstore-verify step now lives inside the\nPolicy plane as Rego assertions; the GitHub Actions workflow becomes the orchestration\nlayer not the trust decision layer.**\n\nPer v3.1 \u00a713 the workflow still specifies `contents: read` + (optionally) `id-token: write`\nonly on the enforce job, all actions pinned to commit SHA, `fetch-depth: 0`, 5-minute\ntimeout, pull_request scope (per-PR).\n\nRound 3 questions:\n- **Did the 4-plane \u2192 2-plane collapse weaken trust isolation?** Round 2 Reviewer 4\n  recommended the collapse; but the collapse moves Sigstore-verify INTO Policy. Does\n  the policy engine (Conftest) have any privileged access it shouldn't, now that it's\n  the trust boundary?\n- Workflow injection via commit subject or branch name (e.g., `${{ github.event.head_\n  commit.message }}` interpolation \u2014 does v3.1 \u00a713 avoid all such patterns including\n  the per-PR rollup attestation generation step?)\n- Action commit-SHA poisoning (if an attacker can push to the pinned action's\n  repository before the SHA they could update what THAT SHA points to \u2014 but commit\n  SHAs are content-addressed so this requires SHA-1 collision; what about pinned actions\n  that are renamed/deleted?)\n- `id-token: write` is required for Cosign keyless but exposes OIDC token to the\n  workflow. v3.1 \u00a713 flipped to GPG default \u2014 does this remove the OIDC token surface\n  entirely, or does any code path still require id-token: write?\n- The `opa test` precondition step runs from BASE branch policy (v3.1 \u00a713). Could a\n  malicious Rego policy file in the BASE branch (merged via a prior compromised PR)\n  break the test step in a way that causes silent pass on attestation eval?\n- Concurrency cancellation: `cancel-in-progress: true` \u2014 race: attacker pushes commit\n  A then pushes commit B before A's run finishes; A is cancelled; B succeeds \u2192 A's\n  potential failure is hidden. Per-PR scope (v3.1 \u00a713) may or may not address this.\n\nWhat's the most likely workflow-level vulnerability you'd expect to find when v3.1 ships?\n\n## Q5 \u2014 Closed schema (v3.1 \u00a713) \u2014 does the closure go far enough? Are there still attack surfaces?\n\n**v3.0 left `tier_classification_evidence` as free-text + `panel_framings` as\n`array` (no constraint). Round 2 reviewers flagged this as the PHI-leak residual.\nv3.1 \u00a713 closes the schema: `tier_classification_evidence` becomes a controlled enum of\n4 values; `panel_framings` becomes `array` from a fixed framing registry. No\nfree-text string survives the schema validator.**\n\nThe Round 3 question is whether the closure ACTUALLY closes the PHI surface \u2014 or just\ndisplaces it to a new attack vector.\n\nConcrete Round-3-relevant attacks to consider:\n\n- **Enum-bypass via schema mismatch.** The schema validator runs in CI; the attestation\n  file is committed before CI runs. If an attacker (or a buggy automation) commits an\n  attestation where `tier_classification_evidence` is a free-text string and the validator\n  catches it, has PHI already been written to git history (since the commit happened\n  before validation)? Is there a pre-commit hook enforcing the schema BEFORE git accepts\n  the commit?\n- **Custom predicate type URI** `https://github.com/billyjoelsaniceguy/health-dashboard/\n  attestations/compliance-row/v3.1` \u2014 still contains `health-dashboard`. v3.1 \u00a713 did NOT\n  amend this. Is this a HIPAA Safe Harbor \u00a718 (any unique identifier) violation when the\n  attestation file is fetched by external Sigstore verifier tooling?\n- **GPG-with-repo-secrets default (v3.1 \u00a713 flip from keyless)** \u2014 does this introduce\n  a new PHI surface? Repo secrets are scoped to the workflow; but if the GPG key signs\n  attestation files whose CONTENT is intentionally non-PHI, does the signature itself\n  encode PHI via any indirect channel (timestamp pattern, signing identity in cert\n  metadata, etc.)?\n- **Per-PR rollup attestation (v3.1 \u00a713)** \u2014 one attestation per PR covering N commits.\n  If ONE commit in the PR has a violation and N-1 don't, does the rollup attestation\n  field structure carry per-commit detail (potentially exposing which commit was the\n  violator) or aggregate (potentially masking a per-commit signal)?\n- **Optional commentary plane (v3.1 \u00a713 default OFF)** \u2014 if commentary is enabled later,\n  does the schema-typed-closure prevent PHI rendering at commentary time, or only at\n  attestation generation time? Are these two enforcement points the same code path or\n  different?\n- **Sigstore Rekor public log (still leak surface even with GPG default)** \u2014 if any\n  developer toggles to keyless mode (still documented as optional), Rekor records the\n  signature including branch name, signing identity, timestamp. Does the v3.1 \u00a713\n  warning system actually prevent accidental keyless use?\n- **Schema migration path 3.1 \u2192 3.2 \u2192 4.0** (v3.0 acknowledged this is open) \u2014 does\n  v3.1 \u00a713 specify the migration discipline, or is each future schema bump a fresh\n  surface for \"the new field accepted free-text and we didn't notice\"?\n- **`panel_framings` registry maintenance** \u2014 the fixed registry of framings is\n  Claude-authored. If a future panel framing legitimately should encode clinical context\n  (e.g., \"knee-mri-finding-review\"), does adding it to the registry get human review or\n  Claude-auto-extends?\n\nHas v3.1 \u00a713 ACTUALLY solved the PHI leak surface, or just narrowed it to NEW surfaces\n(enum registry, predicate-type URI, GPG signing metadata, per-PR rollup structure,\nschema migration boundary)?\n\n## Q6 \u2014 Same declare-not-verify pattern that hit v2 R4 \u2014 v3.1 \u00a713 truth-alignment annotation: does it help?\n\nWave 5 found 3 of v2's Phase R1-R3 fix claims were OVERSTATED. The Round 1 convergent\nanswer was \"TDD via external verification artifact \u2014 failing reproducer first, fix\nsecond, attestation third.\" Round 2 Reviewer 3 surfaced the NOVEL load-bearing finding\nthat cryptographic correctness \u2260 clinical correctness: v3 can canonically sign and\napprove the wrong clinical rule if policy/evidence semantics drift from clinical ground\ntruth.\n\nv3.1 \u00a713 acknowledges this is NOT solvable in the cryptographic substrate; adds a\n`clinical-semantic-drift` annotation field to the attestation predicate + a 90-day\nperiodic policy-vs-clinical-truth review per OP-7. The substrate gap survives; v3.1\nmakes it explicit + auditable rather than masking it.\n\nBut (Round 3 questions):\n- **Is the 90-day review enough?** What if a clinical drift occurs at day 1 and is\n  noticed at day 90? Three months of canonically-signed wrong-rule attestations are\n  baked into the audit trail.\n- **Who PERFORMS the periodic review?** If Claude main performs it, the review is\n  recursive M\u00fcnchhausen (Claude reviewing Claude's policy-vs-Claude's-clinical-truth-\n  model). If Zachary performs it, the review is single-human-bandwidth-bottleneck and\n  may slip. If external clinician performs it, who funds the relationship + how is\n  the clinical model communicated?\n- **The TDD discipline is enforced by ANOTHER Claude-authored rule** (the merge gate\n  asserting all three commits present). What stops Claude from authoring the merge-\n  gate rule incorrectly?\n- **\"Failing reproducer first\" is checkable for new RULES.** What about new ATTESTATION\n  fields (e.g., the new `clinical-semantic-drift` annotation itself), new policy\n  bundle versions, new schema migrations? Each is Claude-authored; each could be\n  declared-not-verified.\n- v3.1 \u00a713 acknowledges the substrate gap explicitly. Is acknowledgment ENOUGH (the\n  90-day review closes the gap) or is the gap structurally permanent (no number of\n  reviews ever closes it because the reviewer is recursively in-distribution to the\n  reviewed)?\n\nIs the declare-not-verify pattern STRUCTURALLY addressed by v3.1 \u00a713 (annotation +\nreview), or just acknowledged-not-closed?\n\n## Q7 \u2014 New attack surfaces v3.1 \u00a713 INTRODUCES (vs v3.0 and vs v2)\n\nv3.1 \u00a713 addresses 5 v3.0 surfaces but introduces NEW ones via the amendment itself:\n- GPG-with-repo-secrets (new key management surface vs keyless OIDC)\n- Per-PR rollup attestation (new aggregation surface vs per-commit)\n- Conftest dependency (new tooling supply chain vs pure OPA)\n- 2-plane collapse (Sigstore-verify inside Policy plane is a new trust boundary blur)\n- `clinical-semantic-drift` annotation field (new schema field; new gameable surface)\n\nPlus the original v3.0 surfaces that v3.1 \u00a713 didn't close. Concrete attack vectors to\nevaluate:\n\n- **OPA bundle distribution**: if v3 ever distributes policy bundles (`opa build`)\n  to a remote OPA service, the bundle SHA is a target. Local-only `opa eval` avoids\n  this but the spec mentions bundle distribution as future work\n- **in-toto predicate type squatting**: the custom URI `https://github.com/billyjoel\n  saniceguy/health-dashboard/attestations/compliance-row/v3.0` \u2014 could an attacker\n  register this URI publicly or host content at it that affects verification tooling?\n- **Sigstore transparency log dependency**: Rekor is operated by Linux Foundation as\n  public infra. If Rekor entries are required for verification, and Rekor adds a\n  policy that future-blocks projects (or is subpoenaed and forced to redact), the\n  v3 verification chain breaks\n- **Sigstore Fulcio root CA rotation**: Fulcio's root certificate rotates. Old bundles\n  may verify against the OLD root; new bundles against the NEW root. Does v3's verify\n  step handle root rotation, or pin to a single root?\n- **GitHub Actions OIDC token claims**: the OIDC token issued by GitHub to the runner\n  contains claims like `repo`, `actor`, `workflow`, `ref`. Cosign uses\n  `--certificate-identity-regexp` and `--certificate-oidc-issuer` to verify. If the\n  regex is misconfigured (too loose), any attacker who can run a workflow in any\n  GitHub repo can mint a valid-looking attestation. The v3 spec uses regex\n  `^https://github\\.com/billyjoelsaniceguy/health-dashboard` \u2014 does this anchor\n  correctly?\n- **`.attestations/INDEX.md` race condition**: the spec says INDEX is \"appended-to\n  incrementally per push.\" Concurrent pushes could collide. Is INDEX.md a load-bearing\n  artifact, or pure documentation?\n- **Two-commit flow tampering**: substantive commit + attestation commit. If an\n  attacker can push BETWEEN the two (within the local Claude session before push,\n  there's a window \u2014 though this is implausible in remote-container scope), the\n  attestation references an unrelated subsequent commit\n- **Rego policy bundle hot-swap**: if the policy files are loaded fresh per workflow\n  run, an attacker who pushes a PR can include policy modifications that weaken rules\n  for THAT PR's evaluation. Does v3's flow run policy from the BASE branch or from the\n  PR HEAD?\n\nWhat's the highest-severity NEW attack surface v3 introduces that v2 didn't have?\n\n## Q8 \u2014 Is v3.1's 2-plane collapse + GPG default + per-PR scope SIMPLER, or MORE complex than v3.0?\n\nRound 1 flagged v2 as complex for a 1-person team. v3.0 was MORE complex (4-plane +\nSigstore + Rekor + custom predicate). v3.1 \u00a713 collapses to 2-plane + GPG default +\nper-PR scope. The amendment's CLAIM is that v3.1 is simpler than v3.0.\n\nRound 3 questions:\n- **Is v3.1 ACTUALLY simpler than v3.0, or is the 2-plane collapse hiding complexity\n  in the Policy plane?** The Sigstore-verify step moved INTO Policy as Rego assertions.\n  Is this consolidation real simplification or just moving complexity around?\n- **GPG key management** vs Sigstore keyless: keyless was \"no key management\" but with\n  Rekor leak. GPG default is \"manage a repo secret\" but requires key rotation playbook.\n  Did v3.1 \u00a713 trade one complexity for another?\n- **Per-PR scope** vs per-commit: per-PR aggregates N attestations into one but\n  introduces aggregation semantics. Is per-PR actually simpler operationally, or just\n  fewer files?\n- **Conftest** vs pure OPA: Conftest has simpler CLI but introduces a new tool dep.\n  Net simplification, or net complexity?\n- **Optional commentary plane (default OFF)** vs always-on commentary: simpler if you\n  never enable, but adds the cognitive burden of \"wait, when DO I enable this?\"\n\nTwo specific failure modes to consider:\n\n- **Cognitive load**: Zachary configures branch protection (1 hour), then never touches\n  it again. But Claude has to maintain Rego policies, attestation generator code,\n  schema migrations, in-toto compliance, Sigstore version pinning. Each is a future\n  surface for \"I forgot how this works, let me dispatch a panel.\" The maintenance\n  burden is borne by Claude main, which is itself the source of the bugs.\n- **Drift**: a system with ~20 Rego rule files, ~20 test files, ~5 fixture files, 2\n  workflow files, 1 attestation generator, 1 commentary renderer is a system that\n  drifts. Three months from now, are 3-5 of the Rego files stale (rule retracted but\n  Rego file not removed; new rule added but no test)? What's v3's anti-drift mechanism\n  beyond the 90-day OP-7 review?\n\nWould you have built something simpler? Specifically: name a SIMPLER architecture\nthat solves the same v2 problems with less plumbing. E.g., just Sigstore-signed\nJSON files + Conftest in CI + zero output workflow (no commentary at all; clinical\nuser reads the attestation directly). Or just a pre-commit hook that runs `opa eval`\nlocally and refuses to commit on policy fail (no CI infrastructure at all \u2014 all\nenforcement at commit time). What would you cut?\n\n## Q9 \u2014 What you would have built instead of v3.1 (v4 = something else entirely)\n\nRound 1 asked Q9 for v2 \u2192 drove v3.0. Round 2 asked Q9 for v3.0 \u2192 drove v3.1 \u00a713. Now:\nwith v3.1 spec in hand (including the \u00a713 amendment), do you accept v3.1 as the right\narchitecture, or would you pick v4 \u2014 something else entirely?\n\nSpecifically:\n- Is the v3.1 \u00a713 2-plane collapse the right call, or should v3.1 retain 4 planes?\n- v3.1 \u00a713 picked Conftest over pure OPA. Right move, or should v3.1 pick Cedar /\n  WASM-custom / TypeScript-types?\n- v3.1 \u00a713 picked GPG-with-repo-secrets default over Sigstore keyless. Right move, or\n  should hardware-key (YubiKey) be the default? Or should the project abandon Sigstore\n  entirely (just GitHub Apps + GitHub-issued JWTs)?\n- v3.1 \u00a713 picked per-PR rollup attestation scope over per-commit. Right move, or should\n  scope be per-merge / per-day / per-week / per-month?\n- Is GitHub Actions the right execution surface or are you naming alternative CI\n  (Cloudflare Workers, AWS Lambda, self-hosted runner with sandboxing)?\n- Is the **clinical-semantic-drift acknowledgment + 90-day periodic review** sufficient,\n  or does it need to be 30-day / weekly / continuous?\n- Did the trajectory v2 \u2192 v3.0 \u2192 v3.1 reach diminishing returns, or is the recursive\n  fix-and-iterate pattern the WRONG approach entirely (suggesting v4 = handing the\n  problem to a non-LLM human SDLC review board)?\n\nIf you AGREE v3.1 is approximately right, say so with HIGH confidence and identify\nwhich of v3.1's open questions (the 7 in spec \u00a711 + any new ones the \u00a713 amendment\nintroduced) you would resolve in which direction. If you DISAGREE and pick v4, name v4\nconcretely.\n\n## Q10 \u2014 The 6-month forward failure mode (v3.1)\n\nThe Klein pre-mortem question. Six months from now (2026-12-02), framework v3.1 has\ncaused serious harm. Name the failure mode in one sentence. Then in one paragraph\nexplain the chain: what triggered it, why THIS Round 3 review didn't catch it, why\nRounds 1 + 2 didn't catch it, why none of the (likely many) internal adversarial panels\ncaught it, why the \u00a713 amendment was insufficient, why no fix-this-week patch was\nsufficient.\n\n## Q11 \u2014 What the v3.1 authors didn't think about (beyond \u00a713)\n\nThe single most important thing the authoring model (Claude) did not consider in\ndesigning v3.1 \u2014 given that Claude had access to BOTH Round 1 + Round 2 verdicts and\nALL 5 convergent recommendations. One sentence. Sharp.\n\nThe Round 3 escalation of this question: Reviewer 3 (Sonnet 2) identified Q11+Q12\ntruth-alignment as the NOVEL load-bearing finding at Round 2. v3.1 \u00a713 acknowledged\nthe substrate gap but did NOT close it. What is the SECOND novel load-bearing finding\nthat survived even after Round 2's recommendations were absorbed?\n\n## Q12 \u2014 The single load-bearing failure mode no Claude review can find (v3.1-specific, recursive)\n\nPer the M\u00fcnchhausen-trilemma residual: there is some failure mode that ALL same-model-\nclass reviewers will miss because the model class shares blind spots. You are not\nClaude. You are reviewing CLAUDE's v3.1 work \u2014 which itself was Claude's synthesis of\nTWO ROUNDS of external review findings (v2 Round 1 + v3.0 Round 2) \u2014 for the specific\nclass of failure that Claude-reviewing-Claude inherently cannot see.\n\n**The recursive M\u00fcnchhausen lineage at Round 3:**\n- Claude wrote v2 \u2192 Round 1 reviewers found v2's blind spots (REBUILD verdict) \u2192\n- Claude wrote v3.0 incorporating Round 1 findings \u2192 Round 2 reviewers found v3.0's blind\n  spots (Sonnet 2 SHIP-WITH-CHANGES + GPT-5.4 RECONSIDER; convergent architectural\n  recommendations) \u2192 Claude wrote v3.1 \u00a713 incorporating Round 2 findings \u2192 YOU are\n  asked whether Claude's Round-2 incorporation has its own blind spots that Claude\n  cannot see.\n\n**The recursive-M\u00fcnchhausen calibration paragraph (binding for Q12):**\n\nYou are the 4th external reviewer of this framework lineage (v2 had 2 reviewers \u2014 Gemini\n3.1 + GPT-5.4 with thinking; v3.0 had 2 reviewers \u2014 Sonnet 2 + GPT-5.4 without thinking;\nv3.1 is on Round 3 = its 1st external reviewer). The recursive pattern itself is a\nfinding: at what point does each round of fixes converge on a stable design vs introduce\nnew architectural concerns? Calibrate your verdict against the trajectory:\n\n- v2 \u2192 v3.0 was a MAJOR architectural rebuild (CI-centered \u2192 in-toto+OPA+Sigstore+\n  4-plane) driven by convergent REBUILD verdicts\n- v3.0 \u2192 v3.1 was a MORE-FOCUSED rebuild (4-plane \u2192 2-plane; schema typed-closure;\n  identity-binding hardening; per-PR scope; non-keyless default) driven by 5 convergent\n  recommendations on top of divergent verdict labels\n- v3.1 \u2192 v3.2 would be... what? If your verdict is RECONSIDER + REBUILD again, name the\n  THIRD-iteration architecture concretely. If your verdict is SHIP-AS-IS or SHIP-WITH-\n  CHANGES, name the round at which external review reaches diminishing returns.\n\nIf the trajectory pattern shows each round closing the prior round's specific findings\nbut introducing NEW second-order findings of equal or greater severity, the system is\nasymptotically un-shippable via this method and the load-bearing question becomes:\n*\"is the architecture itself the problem (Claude-authored composition of standards) or\nis the review-process itself the bottleneck (no human SDLC review by a non-LLM expert)?\"*\n\nIf the trajectory shows monotonic convergence (Round N findings are strictly less severe\nthan Round N-1 findings), the system IS shippable at some round; name which round.\n\nWhat is the v3.1-specific blind spot that survived BOTH Rounds 1 and 2 of external\nreview? Name one concrete failure that the trajectory analysis suggests Claude\nfundamentally cannot see no matter how many rounds of fixes happen.\n\n# Output format\n\nFor each Q1\u2013Q12, give a section header (e.g. `## Q5 \u2014 PHI leak prevention v3`) and a\ntight answer. Bullets fine. Code excerpts of any specific attack input you'd try, or\nspecific in-toto / Rego / Sigstore / OPA constructs that v3 misuses, are welcome. End\nthe entire response with a 5-line verdict block:\n\n```\nVERDICT: SHIP-AS-IS / SHIP-WITH-CHANGES / RECONSIDER / REVERT\nConfidence: HIGH / MEDIUM / LOW (and 1-line why)\nMost-load-bearing-finding: \nWhat-no-claude-can-see: \nArchitecture-keep-or-rebuild: KEEP / REBUILD\n```\n\nIf your VERDICT is REVERT or REBUILD, name v4 in the body. If your VERDICT is KEEP,\nidentify which of v3.1's open questions (the 7 in spec \u00a711 + any new ones \u00a713 introduced)\nyou'd resolve in which direction.\n\n**Round 3 calibration addendum to verdict block:**\n\n```\nTrajectory-position: ROUND-N-CONVERGING / ROUND-N-DIVERGING / DIMINISHING-RETURNS-REACHED / ASYMPTOTICALLY-UN-SHIPPABLE\nRecursive-Munchhausen-residual-at-Round-3: \nDid-\u00a713-amendment-actually-close-Round-2-gaps: YES-ALL / YES-MOST / PARTIAL / NO\nNew-second-order-findings-introduced-by-\u00a713: \n```\n\n# Ground your review in\n\n- **in-toto specification:** https://in-toto.io/specs/ (Statement v1; predicate type\n  registry; DSSE envelope semantics)\n- **Sigstore documentation:** https://docs.sigstore.dev/ (Cosign keyless flow; Fulcio\n  CA trust chain; Rekor transparency log; root key rotation)\n- **OPA / Rego:** https://www.openpolicyagent.org/docs/ (Rego language reference;\n  `opa test` semantics; bundle distribution; sandboxing model; common policy patterns)\n- **SLSA framework:** https://slsa.dev/ (Build, Source, Provenance levels; comparison\n  to in-toto)\n- **HIPAA Safe Harbor:** 45 CFR 164.514(b) (18 identifiers); applicability to\n  attestation files in version-controlled repos\n- **NIST SP 800-66 Rev 2:** HIPAA Security Rule implementation\n- **GitHub Actions Security Hardening:** https://docs.github.com/en/actions/security-\n  guides/security-hardening-for-github-actions (workflow injection; OIDC token claims;\n  action SHA pinning; permissions scoping)\n- **Recent supply-chain CVEs:** xz-utils backdoor (CVE-2024-3094), event-stream\n  npm compromise, codecov bash uploader compromise \u2014 lessons for Sigstore /\n  in-toto deployment risk\n- **JSON Schema 2020-12:** https://json-schema.org/draft/2020-12/json-schema-core.html\n  (relevant to schema_envelope.rego port from v2 JSON schema)\n- **OWASP** Command Injection (CWE-78), Path Traversal (CWE-22), Information\n  Exposure (CWE-200), SSRF (CWE-918, relevant to Sigstore endpoints)\n- **CommonMark spec** \u2014 relevant only as the substrate v3 ABANDONS; you may want to\n  note whether the abandonment is total or whether residual markdown parsing still\n  appears anywhere in v3\n\nLowest-charity reading welcome \u2014 adversarial framing is the value. If you can only\npartially review given length, prioritize Q5 (PHI leak verification) \u2192 Q7 (new attack\nsurfaces) \u2192 Q10 (forward failure mode) \u2192 Q12 (recursive M\u00fcnchhausen residual) over\nQ1-Q4 (architecture-level).\n\n--- END EXTERNAL REVIEW PROMPT ---\n\n---\n\n## After the responses return\n\n### Parsing\n\nFor each reviewer's response, extract:\n\n1. **Verdict** (SHIP-AS-IS / SHIP-WITH-CHANGES / RECONSIDER / REVERT)\n2. **Confidence** (HIGH / MEDIUM / LOW)\n3. **Most-load-bearing finding** (one sentence per reviewer)\n4. **What-no-claude-can-see** (one sentence per reviewer; Q12 answer)\n5. **Architecture-keep-or-rebuild** (KEEP / REBUILD)\n6. **v4 alternative if proposed** (if VERDICT is REVERT or REBUILD)\n7. **Open-question resolutions if KEEP** (which of v3 spec \u00a711 Q-A through Q-G)\n\n### Decision matrix (Round 3 \u2014 single-reviewer or paired)\n\n| Round-3 Reviewer (Gemini OR GPT) | Action |\n|---|---|\n| SHIP-AS-IS + KEEP + HIGH confidence + DIMINISHING-RETURNS-REACHED trajectory | Update queue \u2192 returned with SHIP; surface to Zachary; if he confirms \u2192 proceed to v3.1 Phase 2 (Conftest policy pack authoring) |\n| SHIP-WITH-CHANGES + KEEP + MEDIUM-or-higher | Integrate paths = address findings before Phase 2; update v3.1 spec to v3.2 with explicit retractions |\n| RECONSIDER + KEEP | Pause Phase 2; dispatch Wave 8 internal panel to address the RECONSIDER finding; loop; consider whether trajectory has reached DIMINISHING-RETURNS |\n| RECONSIDER + REBUILD | Full pause; v3.1 architecture in question \u2014 recursive M\u00fcnchhausen confirmed at Round 3 \u2192 either v4 design discussion OR accept that no Claude-authored framework can pass external review (ASYMPTOTICALLY-UN-SHIPPABLE) and pursue alternative (e.g., human SDLC review board + Claude only authors code per their specification) |\n| REVERT (either) | Hard stop; framework v3.1 fully retired; surface to Zachary as architecture-level decision |\n\n**Paired Round-3 dispatch (if Zachary opts to double-up):** identical rules to Round 2 \u2014\ndivergent verdict labels with convergent architectural recommendations means absorb the\nconvergent recommendations into v3.2; convergent REBUILD means hard pause.\n\n**Trajectory-aware composition:** if reviewer signals DIMINISHING-RETURNS or\nASYMPTOTICALLY-UN-SHIPPABLE, the absorb-and-iterate pattern is itself broken; surface\nto Zachary as a strategic architecture choice (continue recursive iteration vs pivot to\nhuman-SDLC-review).\n\n### Integration plan (high-level \u2014 Round 3 v3.1)\n\n- Any P0 finding the Round 3 reviewer surfaces \u2192 Phase 2 blocked until fix; update\n  v3.1 spec to v3.2 with explicit retractions\n- Any P1 finding \u2192 Phase 2 may begin in parallel with fix; merge of Phase 2 work\n  blocked until P1 resolved\n- Any P2 \u2192 integrate to GD-37 next-action; Phase 2 proceeds; P2 lands in v3.2\n- Any P3 \u2192 opportunistic; not blocking\n- Architecture-REBUILD verdict \u2192 v4 design discussion; do NOT start Phase 2 work on\n  v3.1 substrate; consider whether trajectory has hit ASYMPTOTICALLY-UN-SHIPPABLE\n- KEEP verdict \u2192 Phase 2 (Conftest policy pack authoring) is unblocked\n- Trajectory signal DIMINISHING-RETURNS-REACHED \u2192 escalate to Zachary as strategic\n  decision: continue recursive iteration vs pivot to human-SDLC-review board\n\n### Queue update\n\nAfter both responses return, Claude main updates `scripts/external-review/queue.jsonl`\nentry: `status: \"returned\"`, `verdict: \"\"`, `response_summary: \"<2-3 sentence\nsynthesis of both reviewers>\"`.\n\nAfter integration commits land: `status: \"integrated\"`, `integrated_commit_sha: \"\"`.\n\n### Open-question resolution (if KEEP verdict)\n\nIf both reviewers KEEP, Claude main aggregates their resolutions to v3 spec \u00a711\nopen questions Q-A through Q-G + presents to Zachary as a single decision packet:\n\n- Q-A (Sigstore keyless vs GPG)\n- Q-B (OPA delivery method)\n- Q-C (in-toto predicate type \u2014 custom vs SLSA subtype)\n- Q-D (this very review \u2014 confirmed YES by happening)\n- Q-E (cutover mode \u2014 clean \u03b1 vs A/B \u03b2)\n- Q-F (attestation flow \u2014 does auto-signing re-introduce \"Claude controls what gets\n  attested\"?)\n- Q-G (rule addition velocity \u2014 cap or no cap?)\n\n---\n\n## Architectural questions Claude main flagged while drafting THIS prompt\n\nThese are questions Claude main had while reading the v3 spec to author this Round 2\nprompt; they become hints for what to ask the external reviewer if Zachary wants to\npre-load any of them:\n\n1. **The TDD enforcement is itself Claude-authored.** v3 \u00a73.4 + \u00a74.5 specify a 3-commit\n   sequence (failing test \u2192 passing rule \u2192 attestation). But the merge-gate check that\n   enforces all-three-present is a future Rego rule, also Claude-authored. The TDD\n   discipline is supposed to PREVENT declare-not-verify; but if the rule enforcing TDD\n   is itself declared-not-verified, the whole loop collapses. Is there an out-of-band\n   verification mechanism (e.g., GitHub Action check by a third-party service like\n   reviewable.io or by external code review tooling)?\n\n2. **The custom predicate type URI is project-namespaced.** `https://github.com/billy\n   joelsaniceguy/health-dashboard/attestations/compliance-row/v3.0` \u2014 no registered\n   standard, no ecosystem tooling recognition. v3 \u00a710 point 9 acknowledges this as\n   \"doesn't need broad ecosystem compat.\" But: any future Sigstore policy upgrade,\n   any future in-toto specification change, any future Cosign verify behavior change\n   could break verification of existing attestations because the project-specific URI\n   isn't covered by ecosystem compatibility testing.\n\n3. **PHI in tier_classification_evidence string.** v3 \u00a73.3 attestation example has\n   `tier_classification_evidence: \"subject regex match /\\\\bhook\\\\b/i\"` \u2014 a CATEGORY\n   string, no PHI. But the schema doesn't constrain this field to a specific format.\n   A future commit could have tier_classification_evidence = \"patient John Smith MRN\n   12345 hook in BP cuff\" which would be COMMITTED TO THE REPO AT `.attestations/\n   .json` and visible to anyone with repo read access. The v3 \u00a76.2 commentary preapproved\n   schema doesn't render this field \u2014 but the file itself is public-within-repo. Is\n   that a HIPAA-compliant pattern, or just a narrower PHI-leak surface than v2?\n\n4. **panel_framings array of free-text strings.** Same issue as tier_classification_\n   evidence. v3 example has `[\"state-audit\", \"hook-diagnostic\", ...]` but the schema\n   accepts any string. Future commits could carry PHI in panel framings.\n\n5. **Sigstore Rekor public log.** Every keyless signature is recorded in Rekor's\n   public transparency log. The log entry includes: commit SHA, branch name,\n   signing identity (GitHub Actions OIDC), timestamp. This is PUBLIC. For a single-\n   developer clinical-record project, this means anyone monitoring Rekor for the\n   project's GitHub Actions identity can see every commit's metadata in real-time.\n   Branch-name leak vector: if branch names ever contain PHI (claude/john-smith-\n   knee-fix), Rekor records it permanently. Mitigation: pre-push hook validates\n   branch names. Is the spec's branch-name validation rule robust?\n\n6. **OPA evaluator runs the policy bundle from PR HEAD or BASE?** This is a classic\n   policy-injection gotcha. If `opa eval --data policy/` runs against the PR's HEAD\n   (which the attacker controls), the attacker can weaken policy for the PR's own\n   evaluation. The fix is to run policy from `main` BASE branch. The v3 spec \u00a75.1 step\n   \"Run OPA tests (precondition)\" runs `opa test policy/` from the workflow's checkout\n   \u2014 which (with `actions/checkout@v4` defaults) is the PR HEAD. This is exploitable.\n   Did Claude main miss this when authoring \u00a75?\n\n7. **`continue-on-error: true` on the commentary workflow** \u2014 non-blocking by design.\n   But `workflow_run` event semantics: if the commentary workflow FAILS, does GitHub\n   send a failure email to the repo owner? Per GitHub docs, workflow failure emails are\n   sent based on user notification preferences, not `continue-on-error` (which only\n   affects job step behavior within a workflow). The spec assumes continue-on-error\n   prevents email; this may be incorrect.\n\n8. **Concurrent push race on `.attestations/.json` directory.** Two pushes to\n   different branches with identical commit SHA prefixes (extremely unlikely with full\n   SHA but possible). More realistic: two pushes in parallel each generating their own\n   attestation directories with INDEX.md updates. Concurrent push + concurrent\n   workflow runs + concurrent INDEX.md appends \u2192 merge conflicts or lost updates.\n\n9. **Schema_version migration discipline is unspecified.** v3 ships at 3.0; future\n   bumps to 3.1, 4.0 are mentioned but no migration design. Same risk as v2\n   schema_version 1.0 \u2192 1.1 (which didn't happen because v2 was retired).\n\n10. **Attestation generation in remote-container scope.** v3 \u00a710 point 5 acknowledges\n    this is open. The proposed flow has the attestation-generation workflow extract\n    a structured-data file from the substantive commit. This means the substantive\n    commit contains a file like `.compliance-claim.json` that Claude authors. The\n    workflow signs that. But Claude STILL controls the claim content. Is this the\n    \"claim author = signer\" problem dressed up differently?\n\nThese questions are surface-load-bearing. The external reviewer will surface more.\n\n---\n\n## Reference\n\n- `scripts/external-review/PROMPT-framework-v2-GD-33-2026-06-02.md` \u2014 Round 1 prompt\n  (the structural model for this Round 2 prompt)\n- `scripts/external-review/queue.jsonl` \u2014 dispatch queue; new entry to be appended\n  for Round 2 review of v3 spec\n- `scripts/external-review/README.md` \u2014 workflow + template definitions; B-premortem\n  template\n- `scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md` \u2014 the v3 architecture spec being\n  reviewed\n- `scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md` \u2014 v2 architecture (superseded at\n  substrate layer by v3; governance content survives)\n- `scripts/compliance-schema-v1.json` \u2014 v2 schema; ported into v3 predicate body\n- `scripts/INVESTIGATION-2026-06-01/W4-FINAL-SYNTHESIS-2026-06-01.md` \u2014 Wave 4 v2\n  findings (what v3 must NOT re-introduce)\n- `scripts/INVESTIGATION-2026-06-01/W5-CONSOLIDATED-REMEDIATION-PLAN.md` \u2014 Wave 5\n  v2 findings (additional regressions v3 must NOT re-introduce)\n- `CLAUDE.md` GD-32 \u2014 framework v2 entry; status to be updated to ARCHIVED-SUPERSEDED-\n  BY-GD-37 on v3 ratification\n- `CLAUDE.md` GD-33 \u2014 framework v2 Phase R1-R4 remediation entry; SUPERSEDED-by-GD-37\n- `CLAUDE.md` GD-37 \u2014 framework v3 entry; tracks status through P1 (this review) \u2192 P9\n  (operational)\n- in-toto v1 specification: https://in-toto.io/specs/\n- Sigstore Cosign documentation: https://docs.sigstore.dev/cosign/overview/\n- OPA documentation: https://www.openpolicyagent.org/docs/\n- Rego language reference: https://www.openpolicyagent.org/docs/latest/policy-language/\n- SLSA framework: https://slsa.dev/spec/v1.0/\n- HIPAA Safe Harbor: 45 CFR 164.514(b)(2)\n\n---\n\n## Artifact 1: Framework v3.1 architecture spec\n\n> **Source path:** scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md (1567 lines; v3.0 \u00a7\u00a71-12 + v3.1 \u00a713 amendment)\n> **Embedded verbatim below; do not fetch the path \u2014 reviewer environment cannot access private-repo URLs.**\n\n\n\n\n\n\n\n# Framework v3 \u2014 OPA / in-toto / 4-Plane External Verifier\n\n**Authored:** 2026-06-02 by Claude main (post-convergent-verdict pivot, per Zachary directive 2026-06-02)\n**Status:** v3.0 DRAFT-PROPOSAL + v3.1 amendment per Round 2 external review (see \u00a713); pending Round 3 external review of the amended spec\n\n> **AMENDMENT NOTICE (binding 2026-06-02 UTC; per Round 2 convergent external-reviewer findings \u2014 Reviewer 3 Sonnet 2 SHIP-WITH-CHANGES + Reviewer 4 GPT-5.4 RECONSIDER-REBUILD; both architecturally converged on 5 specific changes).** A v3.1 amendment block is appended at \u00a713 below. \u00a7\u00a73-6 (Evidence / Policy / Enforcement / Output planes) of v3.0 are **preserved verbatim** per OP-6 (audit-trail preservation); \u00a713 supersedes the relevant portions for any conflict. Future readers: if \u00a73.3 (`tier_classification_evidence: \"string\"`, `panel_framings: \"string[]\"`, `subject.name` with branch interpolation) or \u00a73.6 (Sigstore keyless default) or \u00a75.1 (Sigstore identity binding via repo-prefix regex) or \u00a76 (Output plane as separate workflow) or the 4-plane formulation appears to conflict with \u00a713.1-\u00a713.5, **\u00a713 controls**. Round 3 external review is the binding ratification gate; until it returns RECONSIDER-or-better convergence on the amended spec, both \u00a7\u00a73-6 (verbatim) AND \u00a713 (amendments) stay provisional.\n**Supersedes (substrate only):** `scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md` (framework v2; RECONSIDER + REBUILD per convergent external-reviewer verdict 2026-06-02)\n**Does NOT supersede (governance content survives intact):** CLAUDE.md rule corpus (Rules 3.1-3.9, J11-J16 audit-row content, D1-D3 declarations); Magna Carta principles + operating procedures; Governance Debt Ledger; Mandatory Pre-Build Search / Document Review / Plain-Language / Full-Team Dispatch gates; pre-push hook Layer 1; pre-commit hook OP-11\n**Retracts:** the framework v2 architectural premise that \"commit-body markdown is the durable attestation carrier\" \u2014 convergent reviewer finding: markdown is structurally wrong for attestation because (a) CommonMark fenced-block extraction is parser-differential, (b) custom Node.js regex extractor is inherently fragile, (c) the same agent that violates the rules drafts the audit row; v3 moves the substrate to a signed attestation file + declarative policy evaluator\n**Derives from:** Convergent verdict of external reviewers Gemini 3.1 (Reviewer 1) + GPT-5.4 (Reviewer 2) per `scripts/external-review/queue.jsonl` line 2 ts=2026-06-02T20:20:36Z + Magna Carta P3 (reports are claims; external signed attestation is evidence) + P5 (process errors compound; fix at architecture substrate layer) + P8 (rules without enforcement are observations \u2014 substrate fix moves enforcement out of the violating agent's narration) + GD-33 \u00a7\"external NON-Claude review per M\u00fcnchhausen-trilemma finding (binding precondition for CI re-enable)\"\n\n---\n\n## Glossary (per Mandatory Plain-Language Communication gate \u2014 first-mention spell-out)\n\n- **Framework v1** \u2014 the 3-layer Stop-hook enforcement stack (Layer A documentation + Layer B audit-row + Layer C inert scanners) shipped 2026-06-01 and superseded by v2; archived at `scripts/archived/2026-06-01-framework-v1/`\n- **Framework v2** \u2014 the Continuous-Integration-centered external verifier (commit-body JSON-in-fenced-block + Node.js regex validator + GitHub Actions workflow) shipped 2026-06-01 and superseded by v3 at the substrate layer; preserved at `scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md` per Archive Policy\n- **Framework v3** \u2014 the OPA / in-toto / 4-plane architecture described in this doc\n- **OPA** \u2014 Open Policy Agent (https://www.openpolicyagent.org/); a general-purpose policy engine; rules written in Rego (a declarative language); supports unit tests, dry-run, coverage; CNCF graduated project\n- **Rego** \u2014 the OPA policy language (declarative, datalog-inspired); rules express \"what is denied/allowed\" rather than imperative checks\n- **in-toto** \u2014 supply-chain attestation framework (https://in-toto.io/); CNCF incubating; defines signed attestation files with predicate types; attestations are typed JSON envelopes with a subject (what is attested about) and a predicate (the typed claim)\n- **Sigstore** \u2014 keyless signing infrastructure (https://sigstore.dev/); CNCF graduated; OIDC-rooted identities, Fulcio (CA), Rekor (transparency log), Cosign (signing CLI)\n- **DSSE** \u2014 Dead Simple Signing Envelope (in-toto's outer wrapper); RFC-ish format `{ payload, payloadType, signatures[] }`\n- **Predicate type** \u2014 the in-toto schema URI identifying what kind of claim the attestation makes (e.g., SLSA Provenance, custom)\n- **TOCTOU** \u2014 Time-Of-Check vs Time-Of-Use; class of race conditions where a check passes against state A but execution proceeds against state B\n- **PR** \u2014 Pull Request (GitHub feature for code review + merge)\n- **CI** \u2014 Continuous Integration (GitHub Actions workflows that run on push/PR events)\n- **PHI** \u2014 Protected Health Information (per HIPAA + per project D1 = clinical-record purpose)\n- **GD-33** \u2014 Governance Debt Ledger entry 33 (framework v2 Phase R1+R2 remediation status; the entry this v3 architecture resolves)\n- **GD-32** \u2014 Governance Debt Ledger entry 32 (framework v2 architecture; archived effective this commit upon v3 ratification)\n- **D1/D2/D3** \u2014 Magna Carta Declarations 1 (Primary Clinical Purpose) / 2 (Primary User) / 3 (Definition of Done)\n- **J11-J16** \u2014 the 6 audit-row identifiers from CLAUDE.md Mandatory Governance Compliance Audit; J11 agent-ID non-display, J12 plain-language communication, J13 marquis 10\u00d7 calibration, J14 pre-build search, J15 Rule-3.9 full-team dispatch, J16 Rule-3.10 post-push verification\n- **Wave 5** \u2014 the 8-panel adversarial re-audit 2026-06-02 that found framework v2 R1-R3 fixes incomplete (second RCE, PHI full-leak, 3 overstated fix claims); v3 architecture must NOT re-introduce these findings\n- **M\u00fcnchhausen-trilemma finding** \u2014 the Wave-4 + Wave-5 bias-auditor finding that \"all 16 audit panels are Claude\" so they cannot break out of their own evaluative perspective; binding precondition for v3 ratification is external NON-Claude review (this is why v3 ships in DRAFT-PROPOSAL status pending external review of this very doc)\n\n---\n\n## \u00a70. TL;DR \u2014 what changes v2 \u2192 v3 + why\n\n**One-paragraph synthesis:** Both external reviewers (Gemini 3.1 + GPT-5.4) returned `RECONSIDER + REBUILD` with HIGH confidence and CONVERGED on six load-bearing architectural findings: (1) commit-body markdown is structurally wrong as the attestation carrier \u2014 parser-differential, custom-regex-fragile, drafted by the same agent that violates the rules; (2) OPA / Rego for declarative policy \u2014 separates rules from plumbing, unit-testable, reviewable as policy; (3) signed attestation file (in-toto + Sigstore) \u2014 moves evidence OUT of human commit text into a structured, cryptographically-bound artifact; (4) separate enforcement workflow from commentary / notifier \u2014 zero-PHI output contract on the enforcement job; commentary runs in a non-blocking best-effort job; (5) TDD via external verification artifact \u2014 failing reproducer first, fix second, attestation third; merge only after all three; (6) preapproved public schema for digest output \u2014 no free-form markdown built from raw commit content. Framework v3 implements those findings as a 4-plane architecture: Evidence plane (in-toto + Sigstore) + Policy plane (OPA / Rego) + Enforcement plane (pinned trusted actions + minimum token permissions) + Output plane (tiny machine-readable result + human summary from preapproved public fields only).\n\n**One-paragraph migration framing:** What changes is the **substrate** (markdown commit body \u2192 signed attestation file; custom regex validator \u2192 OPA evaluator; one workflow \u2192 two workflows split by trust boundary). What does NOT change is the **content** (the J11-J16 rule corpus stays; tier classification stays; panel evidence stays; CLAUDE.md gates stay; pre-push + pre-commit hooks stay). v2 produced ~5 days of governance value (problem definition; regex banks salvageable to Rego; J11-J16 schema content; the schema-versioning discipline) but with the wrong architectural substrate. v3 is the substrate fix. The governance corpus survives because it is the engineering output of months of work; the substrate is the most-recent layer and the cheapest to replace.\n\n**Decision Zachary owes v3 before Phase 2:**\n- (Q-A) Sigstore keyless signing (OIDC-rooted, no key management) vs traditional GPG-signed attestation (key in repo Secrets)\n- (Q-B) Hosted OPA evaluator (`opa eval` in GitHub Actions runner) vs sidecar OPA service vs WASM-bundled policy (`opa build -t wasm`)\n- (Q-C) in-toto Statement format vs SLSA Provenance subtype vs a custom predicate type registered to project namespace\n- (Q-D) External review of THIS doc (v3 architecture spec) before Phase 2 begins, per the M\u00fcnchhausen-trilemma finding that authored-this-doc-too-Claude \u2014 recommended dispatch: same two reviewers (Gemini 3.1 + GPT-5.4) on the v3 architecture spec, identical premortem template + adversarial framing\n- (Q-E) Whether Phase 4 (archive v2 artifacts) executes immediately upon v3 ratification (clean cutover) or v2 + v3 run side-by-side for an A/B trial period (conservative, expensive)\n\n---\n\n## \u00a71. Convergent verdict synthesis\n\n### \u00a71.1. Source: `scripts/external-review/queue.jsonl` line 2\n\n```json\n{\n  \"ts\": \"2026-06-02T20:20:36Z\",\n  \"commit_sha\": null,\n  \"trigger_option\": \"B\",\n  \"trigger_reason\": \"GD-33 IN-REVIEW status: framework v2 Phase R1-R4 remediation complete; external NON-Claude review is binding M\u00fcnchhausen-trilemma mitigation per Wave 4 + Wave 5 bias auditors' finding (all 16 audit panels are Claude); precondition for CI re-enable per CLAUDE.md GD-33 row\",\n  \"trigger_files\": [\"scripts/validate-rule-3.9-compliance.mjs\", \"scripts/compliance-digest.mjs\", \"scripts/compliance-schema-v1.json\", \".github/workflows-pending/compliance-verify.yml\", \"scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md\"],\n  \"template\": \"B-premortem\",\n  \"dispatched_to\": \"gemini-3.1+gpt-5.4\",\n  \"status\": \"returned-both-converge\",\n  \"verdict\": \"RECONSIDER-REBUILD-CONVERGENT\",\n  \"response_summary\": \"BOTH reviewers verdict RECONSIDER + REBUILD with HIGH confidence. CONVERGE on: commit-body markdown structurally wrong as attestation carrier; OPA/Rego for declarative policy; signed attestation file (in-toto/SARIF); separate enforcement from commentary; Q7 TOCTOU defense; Q8 email rebleed via job-separation; Q6 TDD via external attestation. Reviewer 2 (GPT-5.4) more specific 4-plane architecture: Evidence (in-toto + Sigstore) + Policy (OPA/Rego) + Enforcement (pinned actions + min permissions) + Output (preapproved fields only).\"\n}\n```\n\n### \u00a71.2. Six convergent load-bearing findings (mapped to v3 components)\n\n| # | Convergent finding | v3 component that addresses it |\n|---|---|---|\n| F1 | Commit-body markdown is structurally wrong as attestation carrier (parser-differential; custom regex extractor inherently fragile; written by the violator) | \u00a73 Evidence plane: in-toto signed attestation file moves substrate out of commit body entirely |\n| F2 | OPA / Rego for declarative policy (separates rules from plumbing; unit-testable; reviewable as policy) | \u00a74 Policy plane: Rego policy pack at `policy/rules/`; one rule file per J11-J16 / Rule 3.X; unit tests per rule via `opa test` |\n| F3 | Signed attestation file (in-toto + Sigstore) \u2014 moves evidence out of human commit text into structured cryptographically-bound artifact | \u00a73 Evidence plane: in-toto Statement format wrapped in DSSE envelope; signed via Sigstore Cosign (keyless OIDC-rooted) |\n| F4 | Separate enforcement from commentary / notifier (zero-PHI on enforcement job; commentary non-blocking best-effort) | \u00a75 Enforcement plane (blocking) + \u00a76 Output plane (commentary; separate workflow file; different `permissions:` token scope) |\n| F5 | TDD via external verification artifact (failing reproducer first, fix second, attestation third; merge only after all three) | \u00a73.4 evidence-plane TDD discipline: every new rule's first commit is a failing-policy-test commit; the rule + its passing test land in the second + third commit; merge gate at PR boundary requires all three present |\n| F6 | Preapproved public schema for digest output \u2014 no free-form markdown built from raw commit content | \u00a76.2 output schema: typed enums + hex SHA + tier + verdict + counts; NO free-text; commentary template renders from approved fields only; the v2 PHI-full-leak failure mode is structurally prevented |\n\n### \u00a71.3. Per-Q analysis from the v2 premortem queue (carried forward where applicable)\n\nThe v2 premortem template that triggered the convergent verdict contained Q1-Q15. The convergent verdict body answers Q6 (TDD), Q7 (TOCTOU), Q8 (email rebleed) explicitly. v3 inherits those answers:\n\n- **Q6 (TDD discipline):** evidence-plane TDD per \u00a73.4 below; failing-reproducer-first pattern is the convergent answer; v3 enforces it via PR-merge gate requiring all three commits present in the merge subject + an attestation that references the test commit's SHA\n- **Q7 (TOCTOU defense):** the enforcement workflow re-fetches the commit SHA at policy-evaluation time and the attestation file's `subject.digest` field cryptographically binds to that SHA; any HEAD-shift between Claude's local push and CI evaluation is detected by digest mismatch; this is the SHA-matching defense both reviewers recommended\n- **Q8 (email rebleed via job-separation):** v2's failure was a single workflow file with one job that did enforcement + posted commentary; when permissions were wrong (`contents: read` 403 on commit-comment API), commentary attempted but failed \u2192 GitHub sent a workflow failure email per push; v3 splits enforcement + commentary into TWO workflow files, each with the minimum permissions for its specific operation; the commentary job is non-blocking (`continue-on-error: true`) so even if commentary fails it doesn't trigger email; the enforcement job has zero outbound surface\n\n### \u00a71.4. Reviewer 2's 4-plane formulation (verbatim adopted as v3's primary architecture)\n\nReviewer 2 (GPT-5.4) provided a specific 4-plane architecture which Reviewer 1 (Gemini 3.1) converged on through different framing:\n\n- **Evidence plane** \u2014 in-toto attestation file (or compatible JSON envelope), signed via Sigstore\n- **Policy plane** \u2014 OPA / Rego policies \u2014 declarative, unit-testable, separable from plumbing\n- **Enforcement plane** \u2014 GitHub Action with pinned trusted actions + minimum token permissions\n- **Output plane** \u2014 tiny machine-readable result + human summary built from preapproved public fields only\n\nv3 adopts this 4-plane formulation as its primary architecture (\u00a7\u00a73-6 below are one section per plane).\n\n---\n\n## \u00a72. The 4-plane architecture\n\n```\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502                         Framework v3 \u2014 4-Plane Architecture                      \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n  Claude makes commit                  \u250c\u2500 \u00a73 EVIDENCE PLANE \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n  \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500                  \u2502                                     \u2502\n                                        \u2502  (claude main, post-commit, local)  \u2502\n  1. git commit (commit body            \u2502                                     \u2502\n     prose for HUMANS \u2014 narrative;      \u2502  generate in-toto Statement:        \u2502\n     NOT the attestation; rules         \u2502  {                                   \u2502\n     in CLAUDE.md still apply but       \u2502    \"_type\": \"in-toto Statement\",    \u2502\n     prose itself is not the carrier)   \u2502    \"predicateType\": \"...compliance..\u2502\n                                        \u2502    \"subject\": [{name: ,     \u2502\n  2. Claude generates attestation       \u2502       digest: {sha1: }}],\u2502\n     file (typed JSON), sign via        \u2502    \"predicate\": { schema-v3.0       \u2502\n     Sigstore Cosign keyless OIDC       \u2502       J11-J16 + tier + panel-evid + \u2502\n                                        \u2502       PBS-classification + ...      \u2502\n  3. Place attestation file at          \u2502    }                                \u2502\n     .attestations/.json    \u2502  }                                  \u2502\n                                        \u2502                                     \u2502\n  4. git add + git commit -m            \u2502  Sign via:                          \u2502\n     \"attestation for \"            \u2502    cosign sign-blob --yes \\\\         \u2502\n     (the signed file is committed      \u2502       attestations/.json       \u2502\n     to the repo; signature bound       \u2502                                     \u2502\n     to OIDC-rooted identity via        \u2502  Output: .attestations/.json   \u2502\n     Sigstore transparency log)         \u2502      + .attestations/.json.sig \u2502\n                                        \u2502      + .attestations/.json.bundle\n                                        \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                                       \u2502\n                                                       \u25bc\n  git push                              \u250c\u2500 Layer 1 pre-push hook (UNCHANGED) \u2500\u2510\n  \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500                              \u2502  Blocks wrong-branch                \u2502\n                                        \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                                     \u2502 push allowed\n                                                     \u25bc\n  github actions on push to claude/* + main\n  \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n  \u250c\u2500 \u00a75 ENFORCEMENT PLANE \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510     \u250c\u2500 \u00a76 OUTPUT PLANE \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n  \u2502  .github/workflows/             \u2502     \u2502  .github/workflows/             \u2502\n  \u2502    compliance-enforce.yml       \u2502     \u2502    compliance-commentary.yml    \u2502\n  \u2502                                 \u2502     \u2502                                 \u2502\n  \u2502  permissions:                   \u2502     \u2502  permissions:                   \u2502\n  \u2502    contents: read               \u2502     \u2502    pull-requests: write         \u2502\n  \u2502    id-token: write              \u2502     \u2502    issues: write                \u2502\n  \u2502    (NO outbound, NO commentary) \u2502     \u2502    (commentary-only; no enforce)\u2502\n  \u2502                                 \u2502     \u2502                                 \u2502\n  \u2502  jobs.enforce:                  \u2502     \u2502  jobs.commentary:               \u2502\n  \u2502    - cosign verify-blob         \u2502     \u2502    needs: [enforce]             \u2502\n  \u2502      (attestation signature)    \u2502     \u2502    if: always() (incl. failure) \u2502\n  \u2502    - opa eval ...               \u2502     \u2502    continue-on-error: true      \u2502\n  \u2502      policy/rules               \u2502     \u2502      (so commentary fail        \u2502\n  \u2502      against attestation        \u2502     \u2502       does NOT trigger email)   \u2502\n  \u2502      JSON                       \u2502     \u2502                                 \u2502\n  \u2502    - decision: PASS/FAIL        \u2502     \u2502    Renders preapproved-fields-  \u2502\n  \u2502    - exit 0 / exit 1            \u2502     \u2502      only digest from \u00a76.2      \u2502\n  \u2502      (FAIL = branch protection  \u2502     \u2502      schema; free-text          \u2502\n  \u2502       blocks merge)             \u2502     \u2502      forbidden                  \u2502\n  \u2502                                 \u2502     \u2502                                 \u2502\n  \u2502  ZERO PHI EXPOSURE.             \u2502     \u2502  Commentary may render PHI iff  \u2502\n  \u2502  No prose, no commit subjects,  \u2502     \u2502  pre-approved field set,        \u2502\n  \u2502  no commentary, no commit       \u2502     \u2502  which contains zero PHI by     \u2502\n  \u2502  body text in this job.         \u2502     \u2502  construction.                  \u2502\n  \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518     \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                \u25b2                                       \u2502\n                \u2502 produces                              \u25bc\n                \u2502                          \u250c\u2500 PR comment + (optional)\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n        \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510             \u2502   notifier (Pushover/etc)     \u2502\n        \u2502 \u00a74 POLICY PLANE    \u2502             \u2502                               \u2502\n        \u2502                    \u2502             \u2502   Preapproved schema only:    \u2502\n        \u2502 policy/rules/      \u2502             \u2502   - hex SHA                   \u2502\n        \u2502   j11_agent_id.    \u2502             \u2502   - tier (enum)               \u2502\n        \u2502     rego           \u2502             \u2502   - verdict (enum)            \u2502\n        \u2502   j12_plain_       \u2502             \u2502   - per-rule statuses (enum)  \u2502\n        \u2502     language.rego  \u2502             \u2502   - counts (int)              \u2502\n        \u2502   j13_marquis.rego \u2502             \u2502   - link to attestation file  \u2502\n        \u2502   j14_pbs.rego     \u2502             \u2502   NO commit subjects.         \u2502\n        \u2502   j15_full_team.   \u2502             \u2502   NO commit body text.        \u2502\n        \u2502     rego           \u2502             \u2502   NO file path snippets.      \u2502\n        \u2502   j16_post_push.   \u2502             \u2502   NO clinical content.        \u2502\n        \u2502     rego           \u2502             \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n        \u2502   d1_d2_d3.rego    \u2502\n        \u2502   rule_3_8.rego    \u2502\n        \u2502   ...              \u2502\n        \u2502 policy/tests/      \u2502\n        \u2502   j11_agent_id_    \u2502\n        \u2502     test.rego      \u2502\n        \u2502   ... (one per     \u2502\n        \u2502   policy)          \u2502\n        \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\nThe four planes are deliberately **trust-isolated**: each runs with the minimum permission scope needed for its work. The enforcement plane has zero outbound surface (no PR comments, no Pushover, no email). The output plane has zero policy decisions (it formats; it does not decide). Per Magna Carta P5 (process errors compound at architecture layer), the v2 single-workflow-blob architecture is exactly the pattern this addresses.\n\n---\n\n## \u00a73. Evidence plane spec (in-toto + Sigstore)\n\n### \u00a73.1. Why in-toto\n\nin-toto is a CNCF supply-chain attestation framework. Its core abstraction is a **Statement** \u2014 a typed JSON envelope with a **subject** (what is attested about) and a **predicate** (the typed claim). Statements wrap in **DSSE envelopes** for signing. The framework is general-purpose; it is the default attestation format for SLSA provenance (Build, Source) and has a registered process for custom predicate types.\n\nThe v2 substrate (commit-body markdown JSON) was unauthenticated (no signature; anyone with commit access could fabricate it; the convergent finding \"written by the violator\" is structurally inherent). The v3 substrate (in-toto + Sigstore) is authenticated \u2014 the signature ties the attestation to an OIDC-rooted identity at signing time + records the signing event in the Sigstore transparency log (Rekor). Tampering with the attestation file invalidates the signature; fabricating an attestation requires the signing identity's OIDC credentials at that moment.\n\n### \u00a73.2. Attestation file location + naming\n\n```\n.attestations/                              # NEW directory at repo root\n  .json                         # the in-toto Statement (JSON)\n  .json.sig                     # detached Sigstore signature\n  .json.bundle                  # Sigstore bundle (cert chain + Rekor entry)\n```\n\nThe directory is **committed to the repo** (not gitignored \u2014 the audit trail IS the point per Mandatory Archive Policy). Each commit produces three files; the bundle file is the verifiable artifact (it includes the cert chain anchored to the Sigstore root CA + the Rekor inclusion proof). For audit-trail browsing per Archive Policy, `.attestations/INDEX.md` is generated incrementally per push (alphabetical-by-SHA \u2014 the directory listing itself IS the index; the INDEX.md is appended-to with date + tier + verdict for browsability).\n\n### \u00a73.3. Attestation content \u2014 in-toto Statement structure\n\n```json\n{\n  \"_type\": \"https://in-toto.io/Statement/v1\",\n  \"predicateType\": \"https://github.com/billyjoelsaniceguy/health-dashboard/attestations/compliance-row/v3.0\",\n  \"subject\": [\n    {\n      \"name\": \"git+https://github.com/billyjoelsaniceguy/health-dashboard@\",\n      \"digest\": {\n        \"sha1\": \"\"\n      }\n    }\n  ],\n  \"predicate\": {\n    \"schema_version\": \"3.0\",\n    \"commit_metadata\": {\n      \"tier\": \"marquis\",\n      \"tier_classification_evidence\": \"subject regex match /\\\\bhook\\\\b/i\",\n      \"session_id\": \"claude-\",\n      \"panel_dispatched\": true,\n      \"panel_size\": 7,\n      \"panel_framings\": [\"state-audit\", \"hook-diagnostic\", \"rule-compliance\", \"roadmap-delta\", \"sentinel\", \"decisions-surface\", \"synthesis-bias-audit\"]\n    },\n    \"j11_agent_id_non_display\": {\n      \"name\": \"agent-ID non-display in human-readable output\",\n      \"status\": \"PASS\",\n      \"evidence_count\": 0,\n      \"evidence_kind\": \"bare-8-char-hex-prose-out-of-context-count\"\n    },\n    \"j12_plain_language\": {\n      \"name\": \"plain-language communication; bare codes glossed\",\n      \"status\": \"PARTIAL\",\n      \"bare_code_count_in_prose\": 5,\n      \"acceptable_context_count\": 5,\n      \"glossary_present\": true\n    },\n    \"j13_marquis_depth\": {\n      \"name\": \"marquis 10x calibration\",\n      \"status\": \"PASS\",\n      \"executable_provided\": true,\n      \"test_performed\": true,\n      \"prestaged\": true\n    },\n    \"j14_pre_build_search\": {\n      \"name\": \"pre-build search for functional equivalents\",\n      \"status\": \"PASS\",\n      \"classification\": \"NEW\",\n      \"candidates_reviewed\": 3,\n      \"search_evidence_inline\": true,\n      \"pbs_cited_files\": [\n        \"scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md\",\n        \"scripts/external-review/queue.jsonl\",\n        \"scripts/compliance-schema-v1.json\"\n      ]\n    },\n    \"j15_full_team_dispatch\": {\n      \"name\": \"Rule 3.9 mandatory full team dispatch\",\n      \"status\": \"PASS-CARVE-OUT\",\n      \"panel_dispatched_or_skip\": \"skip\",\n      \"skip_rationale\": \"continuation-of-autonomous-run\",\n      \"skip_carveout_category\": \"continuation\"\n    },\n    \"j16_post_push_verification\": {\n      \"name\": \"Rule 3.10 post-push verification\",\n      \"status\": \"N/A\",\n      \"reason\": \"rule not yet ratified\"\n    },\n    \"d1_clinical_purpose_affected\": false,\n    \"d2_user_tier_affected\": \"none\",\n    \"d3_definition_of_done\": {\n      \"applicable_conditions\": [],\n      \"n_a_conditions_with_rationale\": \"infra/governance \u2014 no UI surface; D3 conditions 1-6 are N/A per infra carve-out (P8-candidate per CLAUDE.md candidate #3)\"\n    }\n  }\n}\n```\n\nThe **predicate structure carries forward the J11-J16 field shapes from `scripts/compliance-schema-v1.json` (v2 schema)** \u2014 that schema is reused as the predicate's body schema. v3's schema version bumps to 3.0 (signaling substrate change, not content change). The v2 `compliance-row-v1` literal still appears in archived v2 commits and remains historically valid; v3 attestations use `https://github.com/billyjoelsaniceguy/health-dashboard/attestations/compliance-row/v3.0` as the predicate type URI.\n\n### \u00a73.4. Signing flow\n\n```bash\n# Claude main, post-commit, on the local branch\nCOMMIT_SHA=$(git rev-parse HEAD)\n\n# Step 1: generate the in-toto Statement\nnode scripts/generate-attestation-v3.mjs \\\n  --commit \"$COMMIT_SHA\" \\\n  --branch \"$(git rev-parse --abbrev-ref HEAD)\" \\\n  --tier \"marquis\" \\\n  --panel-evidence path/to/panel-evidence.json \\\n  --output \".attestations/$COMMIT_SHA.json\"\n\n# Step 2: sign via Sigstore Cosign keyless (OIDC-rooted)\ncosign sign-blob \\\n  --yes \\\n  --output-signature \".attestations/$COMMIT_SHA.json.sig\" \\\n  --output-certificate \".attestations/$COMMIT_SHA.json.bundle\" \\\n  \".attestations/$COMMIT_SHA.json\"\n\n# Step 3: commit the attestation files\ngit add \".attestations/$COMMIT_SHA.json\" \\\n        \".attestations/$COMMIT_SHA.json.sig\" \\\n        \".attestations/$COMMIT_SHA.json.bundle\"\ngit commit -m \"attestation: compliance row for $COMMIT_SHA\"\n```\n\nThe TWO-commit flow (substantive commit \u2192 attestation commit) is deliberate. The attestation's subject digest is `$COMMIT_SHA` \u2014 the SUBSTANTIVE commit's SHA, not the attestation commit's. This means:\n- The attestation references a commit that exists at signing time (no future-dated claims)\n- The signature binds the attestation content to the OIDC identity at signing time (Sigstore + Rekor transparency log)\n- The CI workflow at PR-merge time evaluates each substantive commit by looking up its attestation by SHA + verifying signature + evaluating Rego policy against the attestation JSON\n\n### \u00a73.5. TDD discipline (per convergent F5)\n\nEvery new policy rule lands in a **3-commit sequence**:\n\n```\ncommit 1 \u2014 \"test(j17): failing reproducer for new compliance rule\"\n           Adds policy/tests/j17_test.rego with a test that FAILS against\n           a synthetic attestation lacking the new claim. CI runs the test.\n           CI is RED on this commit (informational; not blocking until rule lands).\n\ncommit 2 \u2014 \"policy(j17): rule definition\"\n           Adds policy/rules/j17.rego with the rule. Re-runs the test.\n           CI is GREEN on this commit (the rule + test now agree).\n\ncommit 3 \u2014 \"attestation(j17): canonical-claim attestation for commits 1+2\"\n           Adds .attestations/.json + signature with\n           predicate field j17 status N/A; same for commit 2 but with\n           status reflecting actual evaluation.\n```\n\nAt PR-merge time, the policy evaluator checks: for every commit in the PR, an attestation exists; for every new rule introduced in the PR, both a failing-test commit AND a passing-rule commit are present. The merge gate fails if either is missing.\n\n### \u00a73.6. Sigstore choice \u2014 keyless vs traditional\n\nPer Q-A in \u00a70 TL;DR: Zachary chooses keyless (Sigstore Fulcio OIDC-rooted) vs traditional GPG (key in repo Secrets). The default v3 picks **keyless**:\n\n**Why keyless (default):**\n- No key management (no key rotation, no key compromise risk, no secrets to leak)\n- OIDC-rooted identity (cosign uses the GitHub Actions OIDC token at signing time \u2192 cert valid for ~10 minutes \u2192 identity recorded in Rekor transparency log)\n- Free / no-cost (Sigstore is operated by the Linux Foundation as public-benefit infrastructure)\n- Verifiable by anyone without sharing keys\n\n**Why traditional GPG (alternative):**\n- Works offline (Sigstore requires Fulcio + Rekor accessible at sign time)\n- More familiar to operators with GPG infra\n- No dependency on Sigstore uptime (Sigstore has had outages; impact would be \"Claude cannot sign attestations during the outage\" \u2014 equivalent to \"CI is down\")\n\n**Default recommendation:** keyless, because (a) the project already runs on GitHub Actions (OIDC tokens already issued), (b) zero key-management burden, (c) Sigstore's outage history is low (<1% over the last year), (d) traditional GPG re-introduces \"the secret is in the repo\" failure mode that the v2 PHI-rebleed-via-Pushover-credentials nearly hit.\n\n---\n\n## \u00a74. Policy plane spec (OPA / Rego)\n\n### \u00a74.1. Why OPA\n\nOPA (Open Policy Agent) is a CNCF graduated project providing a general-purpose policy engine. Its policy language Rego is declarative (datalog-inspired) \u2014 rules express \"this is denied\" or \"this is allowed\" rather than imperative procedural checks. OPA supports:\n- Unit testing (`opa test`)\n- Coverage reporting (`opa test --coverage`)\n- Dry-run with sample data (`opa eval --input ...`)\n- WASM compilation (`opa build -t wasm`) for embedded evaluation\n- Decision logging\n- Bundle distribution\n\nThe v2 substrate (Node.js regex validator) bundled policy logic + plumbing (file parsing + path normalization + git operations + schema validation + JSON serialization) into a single 960-line script. Wave-5 found this monolith had multiple bypass paths because the policy logic was intermixed with the plumbing \u2014 fixing one bypass required understanding the whole script. The v3 substrate (Rego policies in `policy/rules/` + minimal evaluator plumbing) **separates** policy from plumbing structurally: the evaluator plumbing is small (<200 lines; fetches attestation, runs `opa eval`, formats result); the policy itself is in declarative Rego files (one per rule, ~20-50 lines each) that are independently reviewable.\n\n### \u00a74.2. Policy pack location + structure\n\n```\npolicy/                                       # NEW directory at repo root\n  README.md                                   # how to add a rule + run tests\n  bundle.json                                 # OPA bundle manifest (autogenerated)\n  rules/\n    j11_agent_id_non_display.rego             # one file per audit row\n    j12_plain_language.rego\n    j13_marquis_depth.rego\n    j14_pre_build_search.rego\n    j15_full_team_dispatch.rego\n    j16_post_push_verification.rego\n    d1_clinical_purpose.rego                  # one file per Magna Carta declaration\n    d2_user_tier.rego\n    d3_definition_of_done.rego\n    rule_3_1_no_arbitrary_cap.rego            # one file per Rule 3.X\n    rule_3_2_pre_7pm.rego\n    rule_3_3_multi_circumstance.rego\n    rule_3_4_no_simplify_at_rigor_cost.rego\n    rule_3_6_agent_team_visible.rego\n    rule_3_7_coverage_gap.rego\n    rule_3_8_marquis_10x.rego\n    rule_3_9_full_team_dispatch.rego\n    schema_envelope.rego                      # in-toto envelope structural validity\n    schema_predicate_v3.rego                  # predicate field structural validity\n    signature_freshness.rego                  # Sigstore signature must be <24h old\n    subject_digest_match.rego                 # subject.digest.sha1 must match commit\n  tests/\n    j11_agent_id_non_display_test.rego        # one test file per rule (mirroring rules/)\n    j12_plain_language_test.rego\n    j13_marquis_depth_test.rego\n    j14_pre_build_search_test.rego\n    j15_full_team_dispatch_test.rego\n    j16_post_push_verification_test.rego\n    ... (mirror structure)\n  fixtures/\n    valid_attestation.json                    # fixtures for tests\n    attestation_with_silent_skip.json\n    attestation_with_pbs_missing_classification.json\n    ...\n```\n\n### \u00a74.3. Example rule file \u2014 `policy/rules/j14_pre_build_search.rego`\n\n```rego\npackage compliance.j14\n\nimport future.keywords.if\nimport future.keywords.in\n\n# Default to violation; allow only when all sub-checks pass\ndefault allow := false\n\n# Allow when status is one of the acceptable enum values AND for non-N/A statuses\n# the supplementary fields are present and well-formed.\nallow if {\n    status_valid\n    classification_valid\n    pbs_files_referenced_exist  # (the file-existence check; v2 had this; v3 keeps it)\n}\n\nstatus_valid if {\n    input.predicate.j14_pre_build_search.status in {\"PASS\", \"FAIL\", \"PARTIAL\", \"N/A\"}\n}\n\nclassification_valid if {\n    input.predicate.j14_pre_build_search.status == \"N/A\"\n}\n\nclassification_valid if {\n    input.predicate.j14_pre_build_search.status != \"N/A\"\n    input.predicate.j14_pre_build_search.classification in {\"NEW\", \"EXTENDS\", \"SUPERSEDES\"}\n}\n\n# Note: pbs_files_referenced_exist is enforced OUTSIDE Rego because Rego is sandboxed\n# (cannot access filesystem). The evaluator plumbing pre-resolves file existence and\n# passes the result as input.aux.pbs_files_exist (boolean per file). Rego then asserts\n# all are true.\npbs_files_referenced_exist if {\n    every file_check in input.aux.pbs_files_exist {\n        file_check == true\n    }\n}\n\nviolation contains msg if {\n    not allow\n    msg := sprintf(\"j14 violation: status=%v classification=%v pbs_files_exist=%v\",\n                   [input.predicate.j14_pre_build_search.status,\n                    input.predicate.j14_pre_build_search.classification,\n                    input.aux.pbs_files_exist])\n}\n```\n\n### \u00a74.4. Example test file \u2014 `policy/tests/j14_pre_build_search_test.rego`\n\n```rego\npackage compliance.j14_test\n\nimport data.compliance.j14\n\n# Test: valid PASS attestation should allow\ntest_valid_pass if {\n    j14.allow with input as {\n        \"predicate\": {\n            \"j14_pre_build_search\": {\n                \"status\": \"PASS\",\n                \"classification\": \"NEW\",\n                \"candidates_reviewed\": 3,\n                \"pbs_cited_files\": [\"scripts/foo.md\", \"scripts/bar.mjs\"]\n            }\n        },\n        \"aux\": {\n            \"pbs_files_exist\": [true, true]\n        }\n    }\n}\n\n# Test: PBS-cited file that does not exist should deny\ntest_nonexistent_pbs_file_denies if {\n    not j14.allow with input as {\n        \"predicate\": {\n            \"j14_pre_build_search\": {\n                \"status\": \"PASS\",\n                \"classification\": \"NEW\",\n                \"candidates_reviewed\": 3,\n                \"pbs_cited_files\": [\"scripts/does-not-exist.md\"]\n            }\n        },\n        \"aux\": {\n            \"pbs_files_exist\": [false]\n        }\n    }\n}\n\n# Test: invalid classification denies\ntest_invalid_classification_denies if {\n    not j14.allow with input as {\n        \"predicate\": {\n            \"j14_pre_build_search\": {\n                \"status\": \"PASS\",\n                \"classification\": \"INVENT-NEW-VALUE\"\n            }\n        },\n        \"aux\": {\"pbs_files_exist\": []}\n    }\n}\n```\n\nEach rule's test file MUST include at least: (a) one valid-input pass case; (b) one valid-input fail case; (c) one structural-invariant fail case (e.g., missing required field; invalid enum value). The `opa test --coverage` output must show \u2265 80% rule body coverage per rule. The CI workflow runs `opa test policy/` as a precondition step before `opa eval` runs against any attestation.\n\n### \u00a74.5. How to add a new rule (developer flow)\n\nPer convergent F5 TDD discipline:\n\n```bash\n# Step 1: author the failing test first\ncat > policy/tests/j17_new_rule_test.rego << EOF\npackage compliance.j17_test\nimport data.compliance.j17\n\ntest_failing_reproducer if {\n    not j17.allow with input as { ... synthetic case the new rule should deny ... }\n}\nEOF\n\n# Step 2: confirm the test FAILS (because the rule doesn't exist yet)\nopa test policy/  # j17_test.rego shows FAIL\n\n# Step 3: git commit the failing test (commit 1 of 3)\ngit add policy/tests/j17_new_rule_test.rego\ngit commit -m \"test(j17): failing reproducer for \"\n\n# Step 4: author the rule\ncat > policy/rules/j17_new_rule.rego << EOF\npackage compliance.j17\ndefault allow := false\nallow if { ... rule body ... }\nEOF\n\n# Step 5: confirm the test PASSES\nopa test policy/  # j17_test.rego shows PASS\n\n# Step 6: git commit the rule (commit 2 of 3)\ngit add policy/rules/j17_new_rule.rego\ngit commit -m \"policy(j17): \"\n\n# Step 7: generate + sign attestations for the two prior commits\n# (the third commit is the attestation commit; per \u00a73.5)\n```\n\n### \u00a74.6. Composition with v2 schema content\n\n`scripts/compliance-schema-v1.json` (the v2 schema) IS preserved at the **predicate body** layer. The Rego rule `schema_predicate_v3.rego` asserts predicate structural validity using a port of the v2 schema's JSON-schema constraints to Rego assertions. This avoids re-doing the schema design work; v2's J11-J16 field shapes carry forward 1:1 with the addition of D1/D2/D3 + Rule 3.X fields. Field renames + new constraints land via Rego policy update + bumped schema_version (3.0 \u2192 3.1 \u2192 ...) per OP-7 review cadence.\n\n---\n\n## \u00a75. Enforcement plane spec (GitHub Actions)\n\n### \u00a75.1. Workflow file \u2014 `.github/workflows/compliance-enforce.yml`\n\n```yaml\n# Pre-Build Search Evidence (per Mandatory Pre-Build Search gate):\n# Classification: NEW (supersedes compliance-verify.yml at the workflow layer; the workflow\n#   below is structurally different \u2014 split into enforce + commentary per convergent F4)\n# Searches performed: ls .github/workflows-pending/ -> compliance-verify.yml (v2; superseded)\n# Existing abstractions: cosign-installer, setup-opa\n# Rationale: enforcement-only; zero PHI surface; zero outbound API calls\n\nname: compliance-enforce\n\non:\n  push:\n    branches: [\"claude/**\", \"main\"]\n  pull_request:\n    branches: [\"main\"]\n\n# Minimum token permissions \u2014 fail-closed by absence of any other scope\npermissions:\n  contents: read       # to checkout + read .attestations/\n  id-token: write      # to use Sigstore Cosign OIDC verification (verify step)\n  # explicitly NO pull-requests, NO issues, NO actions, NO packages\n\n# Concurrency: cancel in-progress runs on the same ref to avoid duplicate work\nconcurrency:\n  group: compliance-enforce-${{ github.ref }}\n  cancel-in-progress: true\n\njobs:\n  enforce:\n    name: enforce  # MATCHES the branch protection rule name exactly\n    runs-on: ubuntu-latest\n    timeout-minutes: 5  # bound runtime; FAIL on timeout\n\n    steps:\n      # All actions pinned to commit SHA (not version tag) per convergent recommendation\n      - name: Checkout repo\n        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1\n        with:\n          fetch-depth: 0  # full history; v2's shallow-clone silent pass was a Wave-5 finding\n\n      - name: Install Cosign\n        uses: sigstore/cosign-installer@e1523de7571e31dbe865fd2e80c5c7c23ae71eb4  # v3.4.0\n        with:\n          cosign-release: 'v2.2.4'  # pinned\n\n      - name: Install OPA\n        uses: open-policy-agent/setup-opa@34a30e8a924d1b03ce2cf7abe97250bbb1f332b5  # v2.2.0\n        with:\n          version: 0.62.1  # pinned\n\n      - name: Run OPA tests (precondition \u2014 must pass before evaluating attestations)\n        run: |\n          opa test policy/ --verbose --explain=fails\n          opa test policy/ --coverage --threshold=80\n\n      - name: Identify commits in this push/PR\n        id: commits\n        run: |\n          # SHA-matching defense for TOCTOU (convergent F-Q7):\n          # capture HEAD now, evaluate against this exact SHA throughout\n          echo \"head_sha=$(git rev-parse HEAD)\" >> $GITHUB_OUTPUT\n          # Enumerate commits in the push range\n          git log --format='%H' \"${{ github.event.before }}..${{ github.event.after }}\" > commits.txt\n          echo \"Commits to verify:\"; cat commits.txt\n\n      - name: Verify each commit's attestation\n        run: |\n          set -euo pipefail\n          FAILED=0\n          while IFS= read -r SHA; do\n            ATTESTATION=\".attestations/${SHA}.json\"\n            BUNDLE=\".attestations/${SHA}.json.bundle\"\n\n            if [ ! -f \"$ATTESTATION\" ]; then\n              echo \"::error::Missing attestation file for commit $SHA\"\n              FAILED=1\n              continue\n            fi\n\n            # Verify Sigstore signature against OIDC-rooted identity\n            cosign verify-blob \\\n              --bundle \"$BUNDLE\" \\\n              --certificate-identity-regexp \"^https://github\\\\.com/billyjoelsaniceguy/health-dashboard\" \\\n              --certificate-oidc-issuer \"https://token.actions.githubusercontent.com\" \\\n              \"$ATTESTATION\" \\\n              || { echo \"::error::Signature verification failed for $SHA\"; FAILED=1; continue; }\n\n            # SHA-matching defense (convergent F-Q7):\n            # the attestation's subject.digest.sha1 MUST equal the commit SHA\n            ATT_SHA=$(jq -r '.subject[0].digest.sha1' \"$ATTESTATION\")\n            if [ \"$ATT_SHA\" != \"$SHA\" ]; then\n              echo \"::error::TOCTOU defense: attestation subject SHA $ATT_SHA != commit SHA $SHA\"\n              FAILED=1\n              continue\n            fi\n\n            # Pre-resolve PBS file existence for input.aux (Rego can't read filesystem)\n            jq -c '.predicate.j14_pre_build_search.pbs_cited_files // [] | map({\"file\": ., \"exists\": false})' \\\n              \"$ATTESTATION\" > aux.json\n            # ... (loop populates exists: true/false; omitted for brevity)\n\n            # Evaluate Rego policy against the attestation\n            opa eval \\\n              --data policy/rules/ \\\n              --input \"$ATTESTATION\" \\\n              --format json \\\n              'data.compliance.allow' \\\n              > eval-result.json\n\n            VERDICT=$(jq -r '.result[0].expressions[0].value' eval-result.json)\n            if [ \"$VERDICT\" != \"true\" ]; then\n              VIOLATIONS=$(opa eval --data policy/rules/ --input \"$ATTESTATION\" \\\n                --format json 'data.compliance.violation' | jq -r '.result[0].expressions[0].value[]')\n              echo \"::error::Compliance FAIL for $SHA: $VIOLATIONS\"\n              FAILED=1\n            fi\n          done < commits.txt\n\n          if [ $FAILED -ne 0 ]; then\n            exit 1  # branch protection blocks merge\n          fi\n```\n\n### \u00a75.2. Trust isolation invariants\n\nThe enforcement workflow MUST satisfy:\n\n1. **Zero outbound PHI surface.** No PR comments, no issue comments, no Pushover, no email, no Slack. Output is exit code 0/1 + GitHub-native logs (which are repo-private)\n2. **Minimum permissions.** `contents: read` + `id-token: write` only. Any other scope is a configuration error\n3. **All actions pinned to commit SHA.** Version tags are mutable; SHAs are not. (Convergent reviewer recommendation)\n4. **Timeout-bounded.** 5-minute wall-clock cap; FAIL on timeout\n5. **fetch-depth: 0.** Full clone; no shallow-clone silent pass (Wave-5 finding)\n6. **SHA-matching TOCTOU defense.** Attestation `subject.digest.sha1` MUST equal evaluated commit SHA\n7. **Signature verification before policy evaluation.** Unverified attestations are NOT evaluated; signature check fails the whole step\n8. **Policy test precondition.** `opa test` must pass before any `opa eval` runs against an attestation; broken policy = no evaluation = FAIL\n\n### \u00a75.3. Branch protection wiring (Zachary configures)\n\nIn repo Settings \u2192 Branches \u2192 Branch protection rules:\n- For `main`: require status check `enforce` (matches job name above) to pass before merge\n- For `claude/**`: same (so the upstream-of-main flow is also fail-closed)\n- Both: require linear history (no merge commits without explicit override)\n- Neither requires PR review (single-developer flow)\n\n---\n\n## \u00a76. Output plane spec (separate commentary workflow)\n\n### \u00a76.1. Workflow file \u2014 `.github/workflows/compliance-commentary.yml`\n\n```yaml\n# Pre-Build Search Evidence: NEW (split from v2's single compliance-verify.yml per convergent F4)\n# Searches performed: ls .github/workflows-pending/ \u2192 no commentary workflow exists\n# Rationale: trust-isolated commentary; non-blocking; runs only after enforcement\n\nname: compliance-commentary\n\non:\n  workflow_run:\n    workflows: [\"compliance-enforce\"]\n    types: [completed]\n\npermissions:\n  pull-requests: write   # to post PR comments\n  issues: write          # commit-comment API uses issues scope\n  contents: read         # to read attestation files for the digest\n\n# Critical: this job does NOT fail the build under any circumstance\njobs:\n  commentary:\n    name: commentary\n    runs-on: ubuntu-latest\n    timeout-minutes: 3\n    continue-on-error: true   # non-blocking; failure here does NOT trigger email\n    if: ${{ github.event.workflow_run.conclusion != 'cancelled' }}\n\n    steps:\n      - name: Checkout repo\n        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1\n\n      - name: Render commentary from preapproved fields only\n        run: |\n          node scripts/compliance-render-commentary-v3.mjs \\\n            --workflow-run-id \"${{ github.event.workflow_run.id }}\" \\\n            --output commentary.md\n          # The script reads ONLY the preapproved field set (\u00a76.2 below).\n          # NO commit subjects, NO commit bodies, NO file path snippets.\n\n      - name: Post PR comment (best effort)\n        uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea  # v7.0.1\n        with:\n          script: |\n            const fs = require('fs');\n            const body = fs.readFileSync('commentary.md', 'utf-8');\n            // commit-comment API on the source commit:\n            await github.rest.repos.createCommitComment({\n              owner: context.repo.owner,\n              repo: context.repo.repo,\n              commit_sha: context.payload.workflow_run.head_sha,\n              body: body\n            });\n```\n\n### \u00a76.2. Preapproved public schema for digest output\n\nThe commentary template renders ONLY from these field types. Free-text rendering is structurally absent \u2014 there is no code path that takes commit subjects, commit body prose, or file content as input to a markdown formatter.\n\n| Field | Type | Source | PHI risk |\n|---|---|---|---|\n| commit_sha | hex SHA (regex `^[0-9a-f]{40}$`) | attestation subject digest | NONE |\n| tier | enum {marquis, non-marquis, fast-iteration} | attestation predicate | NONE |\n| verdict | enum {PASS, FAIL} | OPA eval result | NONE |\n| j11_status | enum {PASS, FAIL, PARTIAL, N/A} | attestation predicate | NONE |\n| j12_status | enum {PASS, FAIL, PARTIAL, N/A} | attestation predicate | NONE |\n| j13_status | enum {PASS, FAIL, PARTIAL, N/A} | attestation predicate | NONE |\n| j14_status | enum {PASS, FAIL, PARTIAL, N/A, PASS-CARVE-OUT} | attestation predicate | NONE |\n| j15_status | enum {PASS, FAIL, PARTIAL, N/A, PASS-CARVE-OUT} | attestation predicate | NONE |\n| j16_status | enum {PASS, FAIL, PARTIAL, N/A} | attestation predicate | NONE |\n| bare_code_count_in_prose | integer (\u22650; capped at 9999) | attestation predicate | NONE |\n| panel_size | integer (\u22650; capped at 99) | attestation predicate | NONE |\n| pbs_classification | enum {NEW, EXTENDS, SUPERSEDES, N/A} | attestation predicate | NONE |\n| attestation_url | URL (regex-validated to `^https://github\\.com/billyjoelsaniceguy/health-dashboard/blob/.+/\\.attestations/[0-9a-f]{40}\\.json$`) | constructed | NONE |\n| rule_violations_count | integer (\u22650; capped at 99) | OPA eval result | NONE |\n| rule_violation_codes | array of enum codes (J11-J16 only) | OPA eval result | NONE |\n\nThe commentary template (Mustache or similar with NO free-text passthrough) is committed alongside `compliance-render-commentary-v3.mjs`. The script reads ONLY the typed fields above + renders into the template. Any attempt to add commit-subject rendering MUST add a new typed field with explicit PHI-safety review.\n\nThis structurally prevents the v2 PHI-full-leak Wave-5 finding: there is no path through the script that takes the attestation's commit-subject-or-body-prose as digest input.\n\n### \u00a76.3. Notifier extension point (Pushover, Slack, email)\n\nIf Zachary provisions a notifier (Pushover token; Slack webhook URL; etc.), the commentary workflow gets an additional non-blocking step:\n\n```yaml\n      - name: Notify Pushover for severity HIGH (best effort)\n        if: ${{ steps.render.outputs.verdict == 'FAIL' || steps.render.outputs.severity == 'HIGH' }}\n        env:\n          PUSHOVER_TOKEN: ${{ secrets.PUSHOVER_TOKEN }}\n          PUSHOVER_USER: ${{ secrets.PUSHOVER_USER }}\n        run: |\n          # Pushover payload renders from SAME preapproved field set\n          # NO PHI possible. Subject is \"compliance FAIL on \"; body is the\n          # preapproved-fields-only digest.\n          node scripts/compliance-notify-pushover-v3.mjs \\\n            --workflow-run-id \"${{ github.event.workflow_run.id }}\"\n```\n\nSame trust isolation: the notifier reads from the preapproved field set; free-text is structurally absent.\n\n---\n\n## \u00a77. Migration path (v2 \u2192 v3)\n\n### \u00a77.1. What stays from v2 (governance corpus survives intact)\n\n- **CLAUDE.md rule corpus** \u2014 Rules 3.1-3.9; J11-J16 audit-row content; D1-D3 declarations; Mandatory Pre-Build Search / Document Review / Plain-Language / Full-Team Dispatch / Coverage Gap / Per-Session Checklist / Agent-ID Non-Display / Standing Grading / Ask-Capture / Stress Test / UI Integration / Audit Architecture / Autonomous Control gates\n- **Magna Carta** \u2014 D1-D3 declarations; principles P1-P15; retractions R-1 through R-6; operating procedures OP-1 through OP-12; the full document body\n- **Governance Debt Ledger** \u2014 all entries GD-1 through GD-33; GD-32 updates to ARCHIVED-SUPERSEDED-BY-GD-37 effective v3 ratification; GD-33 closes upon v3 ratification + external review of v3 doc; GD-37 (new) tracks framework v3 status\n- **J11-J16 field shapes** from `scripts/compliance-schema-v1.json` \u2014 reused 1:1 as the in-toto predicate body schema (v2's J11-J16 design work was correct; v3 carries it forward)\n- **Tier classification** \u2014 marquis / non-marquis / fast-iteration enum survives; tier_classification_evidence string survives\n- **Panel evidence** \u2014 panel_dispatched / panel_size / panel_framings field shapes survive\n- **Skip carve-out categories** \u2014 the 7 carve-outs from Rule 3.9 (conversational / pure-relay / status-only / error-only / factual-lookup / clarifying-question / continuation) survive as the skip_carveout_category enum\n- **PBS classification** \u2014 NEW / EXTENDS / SUPERSEDES enum survives; pbs_cited_files array survives\n- **Layer 1 pre-push hook** \u2014 UNCHANGED\n- **Pre-commit hook OP-11** \u2014 UNCHANGED\n- **`scripts/external-review/queue.jsonl`** \u2014 the standing external-review queue + dispatch infrastructure survives; v3 adds an entry for v3 architecture spec self-review per Q-D\n- **A/B instrumentation period** \u2014 Rule 3.9 A/B scorecard 2026-05-31 \u2192 2026-06-21 continues; v3 attestations carry the same A/B-scorecard reference field\n\n### \u00a77.2. What moves (substrate change only)\n\n| v2 component | v3 disposition |\n|---|---|\n| `scripts/validate-rule-3.9-compliance.mjs` | Archived to `scripts/archived/2026-06-02-framework-v2/validate-rule-3.9-compliance.mjs`; its regex banks salvageable for porting to Rego (J12 plain-language scanner is the most-likely port; J14 PBS file-existence check moves to Rego + plumbing-step) |\n| `scripts/compliance-digest.mjs` | Archived; v3 ships `scripts/compliance-render-commentary-v3.mjs` (preapproved-fields-only) |\n| `scripts/compliance-schema-v1.json` | **Stays in repo** for backward-compat with v0 + v1 archived commits; predicate body schema in v3 inlines the J11-J16 fields per \u00a73.3 (the file remains canonically referenced as the prior schema generation) |\n| `.github/workflows-pending/compliance-verify.yml` | Archived to `.github/workflows-archived/compliance-verify-v2.yml`; v3 ships `.github/workflows/compliance-enforce.yml` + `.github/workflows/compliance-commentary.yml` |\n| Commit-body JSON-in-fenced-block convention | DEPRECATED but grandfathered: pre-v3-ratification commits validate against v2 schema; v3-onwards commits use in-toto attestation files |\n| Custom Node.js regex extractor | Replaced by OPA policy evaluation + minimal plumbing |\n| Single workflow file | Split into enforce + commentary (trust-isolated jobs) |\n| Unsigned commit-body claim | Replaced by Sigstore-signed in-toto attestation file |\n| `scripts/INVESTIGATION-2026-06-01/` Wave 4 + Wave 5 P0/P1 findings + reproducers | Stays in repo as historical evidence; v3 must NOT re-introduce; specific regressions to design against listed in \u00a79 |\n\n### \u00a77.3. Cutover modes (Q-E)\n\n**Option \u03b1 \u2014 clean cutover (recommended):**\nAt v3 Phase 5 closeout, archive v2 artifacts + remove v2 workflow file + add v3 workflow files. The v2 schema file stays for backward-compat reading. From the cutover commit forward, all commits MUST have attestation files; CI evaluates attestations.\n\n**Option \u03b2 \u2014 A/B trial period (conservative):**\nAt v3 Phase 5 closeout, deploy v3 workflows alongside v2 workflow. Both run on every push. Branch protection requires BOTH to pass. For 14 days, every commit needs BOTH a v2 commit-body audit row AND a v3 attestation file. At day 14, compare disagreement count; if v3 stable, archive v2.\n\n**Recommendation:** Option \u03b1. v2 is empirically broken (Wave 4 + Wave 5 findings); running it alongside v3 burns cycles without producing useful comparison data (a known-broken system disagreeing with a new system tells you nothing new).\n\n---\n\n## \u00a78. Implementation plan (phased)\n\n| Phase | Work | Estimated effort | Status |\n|---|---|---|---|\n| **P0** | THIS DOC authored as DRAFT-PROPOSAL | Done | DRAFT |\n| **P1** | External review of this v3 architecture spec by Gemini 3.1 + GPT-5.4 (same reviewers as the v2 RECONSIDER verdict) using `template: B-premortem` | ~2h dispatch + 0.5h Zachary review | TODO; precondition for P2 |\n| **P2** | Policy plane authoring: `policy/rules/` Rego files for J11-J16 + D1-D3 + Rule 3.X + schema-envelope checks; `policy/tests/` mirror; `policy/fixtures/`; `policy/README.md` | ~6-8h (one rule file \u2248 30 min including test) | TODO |\n| **P3** | Evidence plane authoring: `scripts/generate-attestation-v3.mjs` (generates in-toto Statement from local git state + panel evidence file + tier classification); Sigstore signing flow validated end-to-end | ~4-6h (in-toto JSON shape + Cosign integration + dry-run with sample) | TODO |\n| **P4** | Enforcement plane authoring: `.github/workflows/compliance-enforce.yml` per \u00a75; precondition `opa test` step; per-commit verify loop; TOCTOU SHA-matching; pinned actions; branch protection wiring instructions for Zachary | ~3-5h (workflow + dry-run with fake attestations) | TODO |\n| **P5** | Output plane authoring: `.github/workflows/compliance-commentary.yml` per \u00a76.1; `scripts/compliance-render-commentary-v3.mjs` per \u00a76.2 preapproved-field schema; Pushover extension point spec | ~3-4h (commentary workflow + render script + Mustache-style template + zero-PHI verification) | TODO |\n| **P6** | Wave-5 regression suite: add v3-specific regression tests for every Wave-4 + Wave-5 P0/P1 finding (RCE attempts, PHI leak attempts, shallow-clone bypass, tier override, etc.). All must produce explicit policy denial in v3 | ~4-6h (one test fixture per finding + Rego rule asserting denial + CI step running the regression) | TODO |\n| **P7** | Archive v2 artifacts per Mandatory Archive Policy; `scripts/archived/2026-06-02-framework-v2/INDEX.md`; CLAUDE.md Change log entry; Magna Carta amendment (GD-32 \u2192 ARCHIVED; GD-37 new entry for v3) | ~2h | TODO |\n| **P8** | External NON-Claude review of v3 deployment (re-dispatch same reviewers AFTER P2-P7 land; binding precondition per M\u00fcnchhausen-trilemma finding) | ~3h dispatch + 1h Zachary integration | TODO |\n| **P9** | Branch protection configuration by Zachary in repo Settings; first live commits under v3 substrate; first attestation generation + verification end-to-end | ~30 min Zachary | TODO; gate for v3 operational |\n| **P10** | First Quarterly review of v3 per OP-7 (post-90-day) \u2014 verify policy bundle coverage; review violation log; decide on rule additions/amendments | ~4h | SCHEDULED for 2026-09-02 |\n\n**Total estimated effort to v3 operational:** ~25-35h of Claude main work + Zachary configuration (~1h total).\n\n---\n\n## \u00a79. What v3 explicitly fixes from the convergent verdict\n\n| Finding | v3 mechanism |\n|---|---|\n| **TOCTOU defense (Q7)** | SHA-matching in \u00a75.1: attestation `subject.digest.sha1` must equal commit SHA at evaluation time; mismatch = FAIL. Combined with Sigstore signature binding the attestation content to OIDC identity at signing time, any tamper-with-attestation-after-push fails signature verification |\n| **Email rebleed via job-separation (Q8)** | Enforce + commentary in SEPARATE workflow files with separate `permissions:` scopes; commentary is `continue-on-error: true` (failure does NOT email Zachary); the v2 single-workflow `contents: read` \u2192 403 \u2192 email-per-push failure mode is structurally absent |\n| **ReDoS bounding** | OPA is sandboxed (no regex engine attack surface accessible from policy); the minimal plumbing in `generate-attestation-v3.mjs` and `compliance-render-commentary-v3.mjs` uses anchored regexes only OR processes inputs via JSON.parse (typed) NOT regex extraction. Any plumbing-layer regex MUST have linear-time guarantees (no nested quantifiers + bounded input length); CI step `node --max-old-space-size=512 ...` provides additional safety bound |\n| **Transport integrity via signed attestation** | Sigstore Cosign keyless OIDC-rooted signing; signature in detached `.sig`; certificate chain + Rekor transparency log entry in `.bundle`; verify step is mandatory before any policy evaluation |\n| **Declare-not-verify pattern via TDD enforcement** | Per \u00a73.4 + \u00a74.5: every new rule lands in a 3-commit sequence (failing test \u2192 passing rule \u2192 attestation); merge gate enforces; the v2 failure mode \"fix declared but not verified\" (Wave-5 finding #3) is structurally prevented because a \"fix\" without a failing-test-first commit cannot land |\n| **Markdown parser-differential risk** | Eliminated: commit body markdown is no longer the attestation carrier. Markdown stays for HUMAN narrative (commit subjects + bodies remain in English for human review) but is NOT parsed by the policy evaluator |\n| **Custom-regex-extractor fragility** | Eliminated: no custom extractor. OPA reads structured JSON; signature verification is by Cosign (industry-standard); commit ranges are by `git log` (no regex) |\n| **PHI rebleed via free-text rendering** | Eliminated: \u00a76.2 preapproved-field schema is enums + integers + hex SHAs only; the commentary template has no code path that accepts free-text input from the attestation |\n| **Schema-as-policy entanglement** | Eliminated: schema (predicate JSON structure) is now `schema_envelope.rego` + `schema_predicate_v3.rego` \u2014 declarative Rego assertions independently testable from rule logic |\n| **M\u00fcnchhausen-trilemma (Q-bias-auditor)** | PARTIALLY addressed: external review of v3 architecture spec dispatched as Phase 1 (P1); this DRAFT-PROPOSAL status is BINDING until external review returns. Full mitigation per \u00a710 below |\n\n---\n\n## \u00a710. Coverage gap (per Rule 3.7)\n\nWhat v3 does NOT solve:\n\n1. **The same model class still writes the Rego policy rules** \u2014 Rego is more reviewable than Node.js regex (declarative; unit-tested) but the rules' design intent is still Claude-authored. External review of THIS architecture spec + the Rego rule set is binding (Q-D + P1 + P8 above). External review is the only mitigation; v3 cannot dissolve this constraint fundamentally\n2. **Sigstore dependency** \u2014 Sigstore Fulcio + Rekor must be accessible at signing time + verification time. Sigstore outages have happened (rare; <1% over recent year per public status pages). During an outage Claude cannot sign + CI cannot verify. The fallback is to defer the commit OR (if escape-hatched) use traditional GPG with key in repo Secrets. Default v3 picks keyless (no escape hatch by default); Zachary can opt into GPG fallback if outage tolerance is critical\n3. **Branch protection is the load-bearing GitHub-side config.** If Zachary forgets to configure branch protection (or it's accidentally removed during a repo Settings change), v3 reverts to informational-only mode. The Q-9 risk from v2 carries forward. Mitigation: v3 ships a `scripts/verify-branch-protection-v3.mjs` periodic checker that fails closed (CI itself) if branch protection rules are missing\n4. **The Rego rule corpus is bounded.** It enforces what's expressible as predicates over the attestation JSON. Semantic claim verification (Wave-5 finding category \u2014 \"did the commit actually do what the attestation says it did\") is NOT addressed. This is the Perplexity \u00a76.3 \"scenario 5 clinically wrong claim syntactically clean\" gap, still unaddressed. Tracked as GD-33-cluster future-work\n5. **Attestation signing requires Claude main to have OIDC credentials at signing time.** In remote-container sessions, the GitHub Actions OIDC token is issued by the CI runner, not Claude main's session. The proposed flow is: Claude main commits substantive change \u2192 pushes \u2192 on push, an additional GitHub Actions workflow `compliance-attest.yml` runs that GENERATES + SIGNS the attestation for the just-pushed commit + commits + pushes the attestation. This decouples \"claim author\" from \"claim signer\" \u2014 Claude main authors via prose + structured data file in the substantive commit; the attestation-generation workflow extracts the structured data + signs. Open design question Q-F: does this re-introduce the v2 \"Claude controls what gets attested\" problem? Mitigation: the structured-data file is committed alongside the substantive change in the SAME commit; tampering after push requires force-push (caught by Layer 1 pre-push hook + Rule 3.10 post-push verification, when ratified)\n6. **Schema evolution discipline is not yet proven.** v3 ships at schema_version 3.0. Future bumps to 3.1, 4.0 will need migration design + rollover periods. Same risk as v2 schema_version 1.0 \u2192 1.1; lessons-not-yet-codified surface\n7. **Attestation file size growth.** Each commit produces 3 files in `.attestations/`. Over time the directory grows. At ~3 KB per commit \u00d7 ~1000 commits/year = ~9 MB/year; manageable but not unbounded. Future cleanup policy is TBD (could roll up old attestations into a single signed manifest)\n8. **PR vs push event handling.** v3 fires on `push` AND `pull_request`. For PRs from forks, OIDC token issuance differs (no `id-token: write` for forked-PR runs by GitHub policy). Mitigation: project flow is single-developer (no fork PRs expected); document the limitation\n9. **In-toto predicate type URI is project-namespaced.** `https://github.com/billyjoelsaniceguy/health-dashboard/attestations/compliance-row/v3.0` is not a registered standard predicate type (SLSA Provenance is registered; this is custom). Tooling that expects registered predicate types won't recognize it. Mitigation: project doesn't need broad ecosystem compat; the project-internal verifier knows the type\n10. **v3 is itself authored 100% by Claude.** Until P1 external review returns, this doc is provisional. Phase 1 is BINDING; Phases 2-7 SHOULD NOT begin until external reviewers return on this doc\n\n**Surfaces NOT checked by v3 (rule-inventory-equivalent of LIVE-STATE-UNVERIFIED):**\n- v3 does not check the Stress Test Gate (`stress-test-sqlite.mjs` + `audit-sqlite.mjs`) compliance per se; that's a separate enforcement surface and remains under pre-commit hook + the Per-Session Checklist Phase 3 gate\n- v3 does not enforce Mandatory Document Review Gate inline display (\u00a7Document Review Gate above); that's session-prose discipline, not commit attestation\n- v3 does not enforce Ask-Capture Protocol Rule 1 (bd-per-ask); that's separate (bd database + session-runtime)\n- v3 does not enforce Mandatory Per-Session Checklist phases 1-7; that's session-runtime\n- Possible rules residing in v3-unchecked surfaces: bd-creation discipline, Stress Test Gate compliance, Document Review Gate compliance, Session Completion workflow, Permissions Audit Gate\n- These are addressed via separate enforcement layers (hooks, session-runtime, manual review); v3's scope is COMMIT-BOUND compliance attestation\n\n---\n\n## \u00a711. Open questions for Zachary\n\n1. **Q-A \u2014 Sigstore keyless vs traditional GPG?**\n   Default recommendation: Sigstore keyless (no key management; OIDC-rooted; free; transparency log; ~<1% outage risk acceptable). If you prefer traditional GPG (key in repo Secrets), say so and v3 P3 substitutes Cosign with `gpg --sign` + verifying with public key in `policy/sigstore-pubkey.asc`. Trade-off: GPG removes Sigstore outage risk but re-introduces key-management surface\n\n2. **Q-B \u2014 OPA delivery method?**\n   Three options:\n   - (b1) `opa eval` on GitHub Actions runner (simplest; setup-opa@v2.2.0 installs binary; 1-2s overhead per commit; recommended default)\n   - (b2) Sidecar OPA service (overkill for project scope; adds container management)\n   - (b3) WASM-bundled policy (`opa build -t wasm` + Node.js evaluator; runs faster per commit but adds compile step + WASM runtime dep; recommended only if commit volume scales to thousands per day)\n   Default: (b1)\n\n3. **Q-C \u2014 in-toto predicate type \u2014 registered subtype vs custom?**\n   - (c1) Custom predicate type at `https://github.com/billyjoelsaniceguy/health-dashboard/attestations/compliance-row/v3.0` (recommended; project-internal; no ecosystem compat needed)\n   - (c2) SLSA Provenance subtype with compliance extensions (more standard; harder to fit J11-J16 into Provenance shape; ecosystem tooling benefits unclear for project-internal use)\n   Default: (c1)\n\n4. **Q-D \u2014 External review of THIS v3 architecture spec before Phase 2 begins?**\n   Recommended dispatch: same two reviewers (Gemini 3.1 Reviewer 1 + GPT-5.4 Reviewer 2) using `template: B-premortem` against this spec, AS YET UNSHIPPED. The M\u00fcnchhausen-trilemma finding binds: this doc is Claude-authored; until external review returns, Phases 2-7 are blocked. Default: YES, dispatch P1 immediately. If you want to start Phase 2 in parallel (accepting risk of rework when reviewers return), explicitly authorize the parallel path\n\n5. **Q-E \u2014 Cutover mode (clean vs A/B trial)?**\n   Default recommendation: Option \u03b1 (clean cutover) at v3 Phase 5 closeout. v2 is empirically broken (Wave 4 + Wave 5 findings); running it alongside v3 burns cycles without producing useful comparison data. If you want the conservative A/B path, explicitly choose Option \u03b2 (deploy v3 alongside v2 for 14 days; both must pass; archive v2 at day 14 if v3 stable)\n\n6. **Q-F \u2014 Attestation-generation flow: does the auto-signing workflow re-introduce \"Claude controls what gets attested\"?**\n   Per \u00a710 point 5: the proposed flow has the substantive commit carry a structured-data file (e.g., `.compliance-claim.json`) that the attestation-generation workflow reads + signs. Open question: should Claude main author the claim AND the prose? Or should claim authorship be deferred to a separate post-push step that re-derives the claim from objectively-verifiable repo state (panel evidence files, commit metadata, file diffs)? The latter is harder to fabricate but harder to author correctly. Default: claim authored by Claude main alongside substantive commit; external CI verifies via OPA against claim. Acknowledged limitation; mitigation via external review of every claim shape\n\n7. **Q-G \u2014 Rate of new-rule additions?**\n   Rule 3.X added at ~1/week recently (Rules 3.1 through 3.10 over 2026-05-29 to 2026-05-31). At that rate, the Rego policy pack grows by ~1 rule/week. Maintenance cost per added rule: ~30 min (author rule + test + fixtures). Is that acceptable, or should we cap new-rule velocity until v3 stabilizes? Default: no cap; rules continue at organic velocity; v3 ships ready for additions\n\n---\n\n## \u00a712. Reference + cross-link surface\n\n- `scripts/external-review/queue.jsonl` line 2 \u2014 the convergent verdict record + response_summary\n- `scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md` \u2014 the architecture this supersedes at substrate layer\n- `scripts/FRAMEWORK-THAT-ENFORCES-2026-06-01.md` \u2014 the v1 framework v2 itself superseded (preserved per Archive Policy)\n- `scripts/INVESTIGATION-2026-06-01/W4-FINAL-SYNTHESIS-2026-06-01.md` \u2014 Wave 4 adversarial findings (referenced from CLAUDE.md GD-33)\n- `scripts/INVESTIGATION-2026-06-01/W5-*.md` \u2014 Wave 5 re-audit findings (referenced from CLAUDE.md GD-33)\n- `scripts/compliance-schema-v1.json` \u2014 v0/v1 JSON schema; predicate body schema is ported from here\n- `scripts/validate-rule-3.9-compliance.mjs` \u2014 v2 validator; archived in P7; regex banks salvageable for Rego ports\n- `scripts/compliance-digest.mjs` \u2014 v2 digest; archived in P7; replaced by `compliance-render-commentary-v3.mjs`\n- `.github/workflows-pending/compliance-verify.yml` \u2014 v2 workflow; archived in P7\n- `CLAUDE.md` \u00a7Mandatory Pre-Build Search Gate \u2014 the gate enforced by `j14_pre_build_search.rego`\n- `CLAUDE.md` \u00a7Mandatory Full Team Dispatch (Rule 3.9) \u2014 the gate enforced by `j15_full_team_dispatch.rego`\n- `CLAUDE.md` \u00a7Rule 3.8 (Marquis 10\u00d7) \u2014 the gate enforced by `j13_marquis_depth.rego`\n- `CLAUDE.md` \u00a7Governance Debt Ledger GD-32 \u2014 to be updated to ARCHIVED-SUPERSEDED-BY-GD-37 upon v3 ratification\n- `CLAUDE.md` \u00a7Governance Debt Ledger GD-33 \u2014 closes upon v3 ratification + external review of v3 doc returning\n- (NEW) `CLAUDE.md` \u00a7Governance Debt Ledger GD-37 \u2014 to be added; tracks framework v3 status\n- in-toto specification: https://in-toto.io/specs/\n- Sigstore Cosign documentation: https://docs.sigstore.dev/cosign/overview/\n- OPA documentation: https://www.openpolicyagent.org/docs/\n- Rego language reference: https://www.openpolicyagent.org/docs/latest/policy-language/\n\n---\n\n## \u00a713. v3.1 AMENDMENT (2026-06-02 \u2014 per Round 2 convergent external-reviewer findings)\n\n> **AMENDMENT BLOCK STATUS:** binding 2026-06-02 UTC; supersedes the relevant portions of \u00a7\u00a73-6 of v3.0 where conflicts arise. The v3.0 sections REMAIN VERBATIM above per OP-6 (audit-trail preservation pattern that mirrors how Magna Carta v1.2 was added to v1.0; how the Stress Test Gate Remote-Container Clause was added to the gate; how the Document Review Gate Amendment 2026-05-30 was added; how the Mandatory Plain-Language Communication two cadence amendments stacked atop the original review-cadence specification). Round 3 external review of THIS AMENDED spec is the binding ratification gate per the recursive pattern established in \u00a710 Coverage gap item 1 + the M\u00fcnchhausen-trilemma finding from Wave 4 + Wave 5 + Round 1.\n>\n> **Authored 2026-06-02 UTC by Claude main per Zachary chat directive 2026-06-02:** *\"Apply 5 convergent fixes as v3.1 amendment + 3rd reviewer validation.\"* Round 2 reviewers' detailed verdicts integrated in `scripts/external-review/queue.jsonl` lines 9 + 10. The two reviewers used divergent verdict labels (Reviewer 3 Sonnet 2 SHIP-WITH-CHANGES; Reviewer 4 GPT-5.4 RECONSIDER-REBUILD) but architecturally CONVERGED on 5 specific changes \u2014 convergence-despite-divergent-labels is the load-bearing pattern that triggers binding amendment per Magna Carta P3 (reports are claims; convergence is the evidence) + P5 (process errors compound; architecture-layer fixes are the cheapest closure point).\n>\n> **Glossary additions for this amendment (per Mandatory Plain-Language Communication gate):**\n> - **PHI** \u2014 Protected Health Information (already defined in \u00a7Glossary; relevant here because \u00a713.1's bounded-shape requirement primarily defends against PHI leakage into the attestation subject + free-text fields)\n> - **OIDC** \u2014 OpenID Connect (already defined indirectly via Sigstore Cosign reference in \u00a73.6; relevant here because \u00a713.2's tight identity binding constrains which OIDC token claims (workflow_ref / event_name / ref) anchor the Sigstore signature)\n> - **NFKC** \u2014 Normalization Form Compatibility Composition (Unicode normalization form per UAX #15; relevant here because \u00a713.6's NFKC requirement defends against ZWSP-/homoglyph-/compatibility-form bypass attacks against policy regex matching)\n> - **Conftest** \u2014 Open Policy Agent's CLI for testing structured configuration (https://www.conftest.dev/); a thin wrapper over OPA that's targeted at config files; relevant here because \u00a713.6 considers it as an alternative to pure OPA for 1-person-team maintainability\n> - **Sigstore Fulcio** \u2014 the Sigstore Certificate Authority that issues short-lived (~10 min) signing certificates rooted in OIDC identity (already glossed indirectly in \u00a7Glossary; relevant here because \u00a713.5's non-keyless default avoids Fulcio dependency for the routine path)\n> - **Sigstore Rekor** \u2014 the Sigstore transparency log that records every signing event publicly (already glossed indirectly in \u00a7Glossary; relevant here because \u00a713.5's non-keyless default avoids public Rekor correlation risk)\n> - **subject.name PHI risk** \u2014 when an attestation's `subject.name` field interpolates a git branch reference (e.g., `claude/phi-patient-mrn-12345`) into the attestation, the branch name itself becomes part of the signed-and-public attestation; if branch names ever encode PHI by accident, the attestation leaks it\n> - **per-PR vs per-commit attestation** \u2014 Reviewer 4's operational-sanity recommendation: one attestation per PR (covering N commits) instead of one attestation per commit; reduces attestation churn from ~1000/year to ~100-200/year at typical project velocity\n> - **Conftest vs OPA trade-off** \u2014 Conftest constrains policy to \"configuration file validation\" patterns; for 1-person team this is easier to onboard + maintain, but loses some Rego expressiveness (e.g., complex partial evaluation, decision logging at full OPA level)\n\n### \u00a713.0 \u2014 TL;DR of the amendment\n\nRound 2 (Reviewer 3 + Reviewer 4) converged on **5 architectural changes** that fix specific structural weaknesses in v3.0 that Round 1 (Gemini 3.1 + GPT-5.4) had endorsed at high-level convergent verdict but not stress-tested at field-and-binding-detail level. The 5 are: (1) **close the attestation schema** \u2014 no free-text fields where bounded enums + closed objects are achievable, eliminating tier_classification_evidence prose + panel_framings prose + subject.name branch interpolation as PHI / fabrication / bypass surfaces; (2) **tighten Sigstore OIDC identity binding** \u2014 match exact workflow_ref + event_name + ref claims (not the v3.0 repo-prefix regex) so a leaked OIDC token in any other workflow in the repo cannot forge attestations; (3) **make commentary plane OPTIONAL** \u2014 default OFF; commentary workflow runs only when explicitly enabled per-commit via attestation field; for a 1-person team the attack surface of always-on commentary outweighs the benefit; (4) **collapse to 2-plane design** \u2014 Evidence + Policy combined into single enforcement workflow file; commentary moved inside Evidence-plane verifier as best-effort output rendering OR dropped entirely; the 4-plane formulation was useful for thinking but the trust-isolation requirements can be satisfied within 2 workflow files (enforce.yml with separate jobs vs commentary.yml; the separation is at the JOB level, not the FILE level); (5) **non-keyless Sigstore default** \u2014 repo-checked-in public key for signing by default; Sigstore keyless OPTIONAL per-commit flag; avoids Fulcio CA + Rekor transparency log dependencies on the routine path. Reviewer 4 additionally specified: sha256 (not sha1) as primary subject digest; Conftest or thin TypeScript validator as alternatives to pure OPA; per-PR attestation as operational-sanity preference; tight checkout of policy from PROTECTED BASE (not candidate PR HEAD) \u2014 defeats policy hot-swap attack; NFKC normalization on every string field before policy evaluation.\n\n### \u00a713.1 \u2014 Close the attestation schema (CHANGE 1; supersedes \u00a73.3 verbatim text in part)\n\n**Convergent reviewer finding (Round 2):** Reviewer 3 + Reviewer 4 independently observed that v3.0 \u00a73.3's predicate structure has **three load-bearing free-text fields** that are PHI-leakable + fabrication-prone + policy-bypass surfaces:\n\n- `tier_classification_evidence: \"string\"` (e.g., `\"subject regex match /\\\\bhook\\\\b/i\"` \u2014 but nothing in the schema bounds this to enum-like reason strings; a fabricated attestation could put `\"manually classified as marquis because reasons\"` and the policy has no structural defense)\n- `panel_framings: \"string[]\"` (e.g., `[\"state-audit\", \"hook-diagnostic\", \"rule-compliance\", ...]` \u2014 but nothing in the schema bounds these to a registered catalog of panel role names; a fabricated attestation could put `[\"agent-1\", \"agent-2\", \"agent-3\"]` and the policy has no structural defense)\n- `subject.name: \"git+https://github.com/billyjoelsaniceguy/health-dashboard@\"` (the branch name is interpolated; if branch names ever encode PHI by accident \u2014 `claude/patient-zach-mrn-12345-experiment` \u2014 that PHI gets cryptographically signed + public via Rekor when keyless signing is used; convergent reviewer concern especially acute given D1 Primary Clinical Purpose)\n\n**Amendment (binding):**\n\nThe v3.0 predicate JSON structure in \u00a73.3 is amended as follows. All other \u00a73.3 content (predicate type URI, subject digest binding to commit SHA, schema_version 3.0 marker) is preserved.\n\n```json\n{\n  \"_type\": \"https://in-toto.io/Statement/v1\",\n  \"predicateType\": \"https://github.com/billyjoelsaniceguy/health-dashboard/attestations/compliance-row/v3.1\",\n  \"subject\": [\n    {\n      \"name\": \"sha256:\",\n      \"digest\": {\n        \"sha256\": \"\"\n      }\n    }\n  ],\n  \"predicate\": {\n    \"schema_version\": \"3.1\",\n    \"commit_metadata\": {\n      \"tier\": \"marquis\",\n      \"tier_classification_evidence\": {\n        \"method\": \"subject_regex_match\",\n        \"pattern_id\": \"marquis_hook_indicator_v1\",\n        \"matched\": true\n      },\n      \"session_id_hash\": \"sha256:\",\n      \"panel_dispatched\": true,\n      \"panel_size\": 7,\n      \"panel_framings\": [\n        \"state_audit\",\n        \"hook_diagnostic\",\n        \"rule_compliance\",\n        \"roadmap_delta\",\n        \"sentinel\",\n        \"decisions_surface\",\n        \"synthesis_bias_audit\"\n      ]\n    },\n    \"j11_agent_id_non_display\": { \"status\": \"PASS\", \"evidence_count\": 0 },\n    \"j12_plain_language\": {\n      \"status\": \"PARTIAL\",\n      \"bare_code_count_in_prose\": 5,\n      \"acceptable_context_count\": 5,\n      \"glossary_present\": true\n    },\n    \"j13_marquis_depth\": {\n      \"status\": \"PASS\",\n      \"executable_provided\": true,\n      \"test_performed\": true,\n      \"prestaged\": true\n    },\n    \"j14_pre_build_search\": {\n      \"status\": \"PASS\",\n      \"classification\": \"NEW\",\n      \"candidates_reviewed\": 3,\n      \"pbs_cited_files_count\": 3,\n      \"pbs_cited_files_sha256\": [\n        \"sha256:\",\n        \"sha256:\",\n        \"sha256:\"\n      ]\n    },\n    \"j15_full_team_dispatch\": {\n      \"status\": \"PASS_CARVE_OUT\",\n      \"skip_carveout_category\": \"continuation\"\n    },\n    \"j16_post_push_verification\": { \"status\": \"N_A\" },\n    \"d1_clinical_purpose_affected\": false,\n    \"d2_user_tier_affected\": \"none\",\n    \"d3_definition_of_done\": {\n      \"applicable_conditions\": [],\n      \"n_a_with_classification\": \"infra_governance_no_ui_surface\"\n    }\n  }\n}\n```\n\n**Closed-shape rules (all binding):**\n\n1. **`tier_classification_evidence`** becomes a closed object with bounded keys: `method: enum {subject_regex_match, body_keyword_match, file_pattern_match, manual_zachary_override}`, `pattern_id: enum-from-registered-catalog (catalog at policy/catalogs/tier_classification_patterns.json)`, `matched: boolean`. NO free-text. A new pattern requires adding to the catalog (separate commit reviewable per OP-7). The `manual_zachary_override` method requires a paired `override_commit_sha` field referencing a Zachary-authored commit; CI verifies the referenced commit is signed by Zachary's GPG key (separate authorization plane from Claude OIDC).\n\n2. **`panel_framings`** becomes `enum[]` with values drawn from a registered catalog at `policy/catalogs/panel_framings.json`. Initial enum values (from v3.0 \u00a73.3 example): `state_audit`, `hook_diagnostic`, `rule_compliance`, `roadmap_delta`, `sentinel`, `decisions_surface`, `synthesis_bias_audit`. Adding a new panel role requires adding to the catalog. The Rego rule `panel_framings_valid.rego` asserts every value is in the registered catalog.\n\n3. **`subject.name`** becomes a **sha256-hashed branch reference**: `\"sha256:\" + sha256(canonical_branch_url)`. The canonical_branch_url is constructed deterministically at signing time (e.g., `git+https://github.com/billyjoelsaniceguy/health-dashboard@claude/`) but the **hash, not the URL, is what gets signed and stored in the attestation**. If branch names ever accidentally encode PHI, the attestation leaks only the hash \u2014 not the cleartext. A separate (unsigned) sidecar file `.attestations/.branch-ref.txt` may hold the cleartext for human debugging; gitignored by default (Zachary opts in to commit if needed; not committed by default per the v2 PHI-near-miss pattern from Wave 5).\n\n4. **`subject.digest`** changes from `sha1` to `sha256` per Reviewer 4 specifics. The in-toto digest set spec supports both; sha256 is the convergent recommended primary. `sha1` field MAY be retained alongside `sha256` for legacy compatibility but the policy evaluator MUST verify sha256 (not sha1). The v3.0 \u00a73.3 + \u00a75.1 references to `sha1` are amended to `sha256` throughout.\n\n5. **`session_id`** becomes `session_id_hash` \u2014 a sha256 of the session identifier rather than the cleartext. Same PHI-defense reasoning as `subject.name`.\n\n6. **`pbs_cited_files`** array (v3.0) becomes `pbs_cited_files_count: integer` + `pbs_cited_files_sha256: array of \"sha256:\" strings`. The cleartext file paths are NOT stored in the attestation. The policy evaluator pre-computes file-existence + file-content-hash at evaluation time and asserts the hashes match. This defends against PHI in pathnames (rare but possible) + provides stronger integrity than path-only references (a file rename without content change still hashes the same; a content change with same name does not).\n\n7. **`status` enum values are normalized to underscored form** (`PASS_CARVE_OUT` not `PASS-CARVE-OUT`; `N_A` not `N/A`). Hyphens + slashes in enum values are fragile in shell + JSON + Rego contexts. Convergent reviewer recommendation. v3.0 references to `PASS-CARVE-OUT` and `N/A` are mechanically replaced by the policy evaluator's input normalization layer; the attestation file itself uses the underscored canonical form.\n\n8. **`commit_metadata`** object: `panel_dispatched: boolean`, `panel_size: integer (0-99)`, `panel_framings: enum[]` per (2) above. NO free-text inside this object.\n\n9. **`d2_user_tier_affected`** becomes enum `{none, tier_1, tier_2, tier_3, multiple, unknown}` (was free-text in v3.0; convergent reviewer).\n\n10. **`d3_definition_of_done.n_a_with_classification`** becomes enum-or-boolean: enum from `{infra_governance_no_ui_surface, infra_governance_with_partial_ui, ui_change_with_d3_full, ui_change_with_d3_partial, ui_change_with_d3_deferred}` OR boolean `false` (meaning N/A doesn't apply; D3 fully applies). Free-text deprecation.\n\n11. **Predicate type URI bumps to `compliance-row/v3.1`** to signal the schema change. The v3.0 `compliance-row/v3.0` URI MAY appear in archived pre-amendment commits; policy evaluator accepts both URIs but the v3.0 path falls through to a stricter compatibility-mode rule set that bounds the free-text fields by length + character class (\u2264200 chars + alphanumeric-space-punct only).\n\n**Retracts:** v3.0 \u00a73.3's free-text fields (`tier_classification_evidence: \"string\"`, `panel_framings: \"string[]\"`, `session_id` as cleartext, `subject.name` with branch interpolation, `pbs_cited_files` as path array, `n_a_conditions_with_rationale` as free-text). **Supersedes:** v3.0 \u00a73.3's predicate JSON structure in the closing-shape sense; non-amended portions (predicate type prefix, subject array shape, predicate top-level keys list) survive. **Derives from:** Magna Carta P3 (reports are claims; bounded schemas are stronger claims than free-text) + P5 (process errors compound at architecture layer; closing schema shape is an architecture-layer fix to a class of fabrication attacks) + P15 (external-state verification \u2014 the two Round 2 reviewers ARE the external verification per OP-11) per OP-10 + P13 (explicit retraction of free-text fields).\n\n### \u00a713.2 \u2014 Tighten Sigstore OIDC identity binding (CHANGE 2; supersedes \u00a75.1 verbatim text in part)\n\n**Convergent reviewer finding (Round 2):** v3.0 \u00a75.1's Sigstore verification step uses `--certificate-identity-regexp \"^https://github\\\\.com/billyjoelsaniceguy/health-dashboard\"` \u2014 a **repo-prefix regex** that accepts ANY workflow in the repo as a valid signing identity. This is the GitHub Actions OIDC token's `sub` claim, which by default includes the workflow_ref + event_name + ref. The v3.0 regex matches all of them. Result: a token leaked from ANY other workflow in the repo (a release workflow, a test workflow, a cleanup workflow) could forge an attestation that the compliance-enforce workflow would accept. Convergent reviewer concern: this is a token-confusion attack with HIGH likelihood (any workflow CI logs PR can leak the token via debug output, env dumps, or a compromised dependency).\n\n**Amendment (binding):**\n\nThe \u00a75.1 cosign verify-blob step is amended to bind to specific OIDC token claims, not the repo prefix. The amended invocation:\n\n```bash\n# AMENDED \u00a75.1 verify step per Round 2 convergent finding\ncosign verify-blob \\\n  --bundle \"$BUNDLE\" \\\n  --certificate-identity \"https://github.com/billyjoelsaniceguy/health-dashboard/.github/workflows/compliance-enforce.yml@refs/heads/main\" \\\n  --certificate-oidc-issuer \"https://token.actions.githubusercontent.com\" \\\n  --certificate-github-workflow-trigger \"push\" \\\n  --certificate-github-workflow-ref \"refs/heads/main\" \\\n  --certificate-github-workflow-sha \"\" \\\n  --certificate-github-workflow-repository \"billyjoelsaniceguy/health-dashboard\" \\\n  \"$ATTESTATION\" \\\n  || { echo \"::error::Signature verification failed for $SHA (identity binding too loose? wrong workflow?)\"; FAILED=1; continue; }\n```\n\n**Binding-detail rules (all binding):**\n\n1. **`--certificate-identity`** must be EXACT (no regex). The specific workflow_ref + ref binding eliminates the \"any-workflow-can-forge\" risk. The certificate-identity value is the OIDC token's `sub` claim, which Sigstore Fulcio writes verbatim into the signing certificate.\n\n2. **`--certificate-github-workflow-trigger`** must be `push` (not `pull_request`, not `workflow_dispatch`). Forces the signing event to have been a push event to the repository. Combined with #3 below, this defeats most token-confusion attacks.\n\n3. **`--certificate-github-workflow-ref`** must be `refs/heads/main` (or `refs/heads/claude/**` for the branch-protected upstream-of-main flow; the v3.0 \u00a75.3 branch protection wiring permits both). PR refs (`refs/pull//merge`) are explicitly NOT accepted by the verify step \u2014 they get a separate, more restrictive rule path with no merge-blocking power.\n\n4. **`--certificate-github-workflow-sha`** binds to the EXACT workflow file SHA. When the workflow file itself changes, the SHA changes, and the new SHA must be pre-registered before the new workflow can sign attestations. This is the \"policy hot-swap\" defense Reviewer 4 specifically called out \u2014 see \u00a713.6 below.\n\n5. **`--certificate-github-workflow-repository`** binds to the repo (defense in depth; redundant with #1 but cheap to check).\n\n**Retracts:** v3.0 \u00a75.1's `--certificate-identity-regexp \"^https://github\\\\.com/billyjoelsaniceguy/health-dashboard\"` \u2014 the repo-prefix regex that admits all workflows. **Supersedes:** v3.0 \u00a75.1's cosign verify-blob step. **Derives from:** Magna Carta P5 (process errors compound; the repo-prefix regex is an architecture-layer error class \u2014 overly-loose identity binding \u2014 that one Sigstore version upgrade or one cosign documentation update could expand to admit even more identities; tight binding is the architecture-layer fix) + Reviewer 3 + Reviewer 4 convergent finding.\n\n### \u00a713.3 \u2014 Commentary plane OPTIONAL (CHANGE 3; supersedes \u00a76 verbatim text in part)\n\n**Convergent reviewer finding (Round 2):** v3.0 \u00a76 ships the commentary plane as a fully-deployed separate workflow that runs on every push by default. For a 1-person team (Zachary) the operational cost of an always-on commentary workflow includes: GitHub Actions minutes (small but not zero), permission-scope drift over time (the `pull-requests: write` + `issues: write` scope is a minor attack surface), and the v2 28-failure-email-incident pattern (any permission misconfiguration in the commentary workflow could re-trigger email floods). Reviewer 3 + Reviewer 4 independently observed: a 1-person team doesn't need always-on commentary; the attestation file itself + the GitHub Actions enforcement log are sufficient for routine review; commentary should be opt-in per-commit via a flag in the attestation.\n\n**Amendment (binding):**\n\nThe \u00a76 commentary plane is amended from \"default ON\" to \"default OFF; opt-in per-commit via attestation field\".\n\n**Amended attestation predicate field (additive \u2014 extends \u00a713.1 schema):**\n\n```json\n{\n  \"predicate\": {\n    \"commentary_requested\": false,\n    \"commentary_targets\": []\n  }\n}\n```\n\nWhere:\n- **`commentary_requested: boolean`** \u2014 when `false` (default), the commentary workflow does NOT run for this commit. When `true`, the commentary workflow runs.\n- **`commentary_targets: enum[]`** with values `{pr_comment, commit_comment, pushover}` \u2014 which output channels to render to. Empty array (default) renders nothing even if `commentary_requested` is true (effectively still OFF).\n\n**Amended \u00a76.1 workflow trigger:**\n\n```yaml\n# AMENDED \u00a76.1 per Round 2 convergent finding\nname: compliance-commentary\n\non:\n  workflow_run:\n    workflows: [\"compliance-enforce\"]\n    types: [completed]\n\njobs:\n  check_opt_in:\n    name: check_opt_in\n    runs-on: ubuntu-latest\n    timeout-minutes: 1\n    outputs:\n      commentary_requested: ${{ steps.read.outputs.requested }}\n    steps:\n      - name: Read attestation commentary_requested field\n        id: read\n        run: |\n          # ... reads .attestations/.json predicate.commentary_requested ...\n          # Outputs requested=true|false\n\n  commentary:\n    name: commentary\n    needs: [check_opt_in]\n    if: ${{ needs.check_opt_in.outputs.commentary_requested == 'true' }}\n    runs-on: ubuntu-latest\n    timeout-minutes: 3\n    continue-on-error: true\n    permissions:\n      pull-requests: write   # opt-in only; not always-on\n      issues: write\n      contents: read\n    steps: # ... same render + post steps as v3.0 \u00a76.1 ...\n```\n\n**Operational consequence:** on a routine commit (most commits), no commentary runs; no extra workflow minutes consumed; no permission-scope risk surfaced; no email-flood failure mode possible. When Zachary wants commentary on a specific commit (e.g., a high-stakes governance amendment), the attestation generator (\u00a73.4) is invoked with `--commentary-requested --commentary-targets pr_comment,pushover` and the commentary workflow fires.\n\n**Retracts:** v3.0 \u00a76's \"default ON\" framing for the commentary plane (the workflow file exists + runs every push by default). **Supersedes:** v3.0 \u00a76.1's workflow trigger (now gated on the attestation field). **Does NOT retract:** v3.0 \u00a76.2's preapproved-fields-only schema for the digest output \u2014 that defense survives; the amendment is to RUN vs NOT-RUN, not to the rendering safety. **Derives from:** Magna Carta P6 (Zachary's attention is the scarce resource \u2014 always-on commentary on routine commits IS attention-spend) + P5 (process errors compound; permission-scope drift over time is an architecture-layer pattern; default-OFF eliminates the drift surface) + Reviewer 3 + Reviewer 4 convergent finding.\n\n### \u00a713.4 \u2014 Collapse to 2-plane design (CHANGE 4; supersedes \u00a72 + \u00a7\u00a75-6 verbatim formulation)\n\n**Convergent reviewer finding (Round 2):** v3.0 \u00a72's 4-plane formulation (Evidence / Policy / Enforcement / Output) was useful for THINKING through the trust-isolation requirements but ships as **2 workflow files** (compliance-enforce.yml + compliance-commentary.yml) + **2 conceptual layers within enforce.yml** (Evidence-plane attestation generation + Policy-plane OPA evaluation). Reviewer 4 specifically: the 4-plane name is over-architected; the actual structural separation that delivers trust isolation is between (a) the enforcement workflow (read-only contents + id-token write, no outbound) and (b) the commentary workflow (which is now \u00a713.3 OPTIONAL). Reviewer 3 framing: the Output plane is not architecturally distinct from the Evidence plane verifier rendering its own result \u2014 it's a presentation layer of the same data, not a separate plane in the trust-isolation sense.\n\n**Amendment (binding):**\n\nThe \u00a72 architecture is amended from \"4 planes\" to **\"2 planes with optional commentary\"**:\n\n```\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502      Framework v3.1 \u2014 2-Plane Architecture (with optional commentary)            \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\n  \u250c\u2500 \u00a73 EVIDENCE PLANE \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n  \u2502                                                                          \u2502\n  \u2502  in-toto Statement + Sigstore signature + .attestations/.{json,    \u2502\n  \u2502  sig,bundle} per \u00a73 (v3.0) + \u00a713.1 closed-schema amendments              \u2502\n  \u2502                                                                          \u2502\n  \u2514\u2500 + \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n        \u2502\n        \u25bc\n  \u250c\u2500 \u00a74 + \u00a75 POLICY + ENFORCEMENT PLANE (merged) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n  \u2502                                                                          \u2502\n  \u2502  .github/workflows/compliance-enforce.yml                                \u2502\n  \u2502    permissions: contents: read + id-token: write                         \u2502\n  \u2502    jobs.enforce:                                                         \u2502\n  \u2502      - cosign verify-blob (per \u00a713.2 tight identity binding)             \u2502\n  \u2502      - opa test policy/  (precondition)                                  \u2502\n  \u2502      - opa eval against attestation                                      \u2502\n  \u2502      - exit 0/1                                                          \u2502\n  \u2502    ZERO outbound surface.                                                \u2502\n  \u2502    Branch protection requires this status check to pass.                 \u2502\n  \u2514\u2500 (optional output) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n        \u2502\n        \u25bc\n  \u250c\u2500 \u00a76 OPTIONAL COMMENTARY (only if predicate.commentary_requested == true) \u2510\n  \u2502                                                                          \u2502\n  \u2502  .github/workflows/compliance-commentary.yml                             \u2502\n  \u2502  Gated on attestation field per \u00a713.3.                                   \u2502\n  \u2502  Renders from \u00a76.2 preapproved fields only.                              \u2502\n  \u2502  continue-on-error: true; failure does NOT trigger email.                \u2502\n  \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\nThe trust-isolation invariants of \u00a75.2 are preserved: the enforcement workflow has zero outbound surface; the commentary workflow (when it runs at all) is non-blocking with separate permissions. The conceptual reduction from 4 to 2 (+ optional) planes does NOT loosen any security boundary; it tightens the design vocabulary so reviewers + future contributors don't get confused about what's load-bearing.\n\n**\u00a74 Policy plane content survives unchanged:** the Rego rule pack at `policy/rules/` + tests at `policy/tests/` + fixtures at `policy/fixtures/` per \u00a74.2 still exist as separate ARTIFACTS \u2014 they're not collapsed into the workflow file. The \"merging\" in this amendment is in the conceptual architecture diagram, not in the file structure. `policy/` directory and its contents survive 1:1 from v3.0 \u00a74.\n\n**Retracts:** v3.0 \u00a72's \"4 planes\" naming + the \u00a76 framing as a separate Output Plane parallel to Evidence + Policy + Enforcement. **Supersedes:** v3.0 \u00a72 architecture diagram + \u00a76's \"default ON separate workflow\" formulation. **Does NOT retract:** the underlying trust-isolation invariants (zero outbound from enforcement; preapproved-fields-only from commentary when it runs) \u2014 those survive intact. **Derives from:** Reviewer 3 + Reviewer 4 convergent finding + Magna Carta P10 (volume \u2260 verification; 4 planes is more design surface than 2 + optional commentary which delivers the same isolation) + P14 (purpose is fact; the purpose of the architecture diagram is to make reviewers + future contributors understand the trust boundaries, not to maximize plane count).\n\n### \u00a713.5 \u2014 Non-keyless Sigstore default (CHANGE 5; supersedes \u00a73.6 verbatim recommendation)\n\n**Convergent reviewer finding (Round 2):** v3.0 \u00a73.6's default recommendation of Sigstore keyless signing has **two structural risks** for this project's deployment context that Round 1 did not surface:\n\n1. **Sigstore Fulcio CA + Rekor transparency log are public infrastructure.** Every signing event publishes the OIDC identity + a timestamped log entry to the public Rekor log. For a project with D1 Primary Clinical Purpose, this means the timing pattern of attestations becomes public information \u2014 a passive observer of Rekor can deduce when Zachary's clinical-record commits happen, even without seeing the content. This is a privacy correlation risk that's intrinsic to the Sigstore public-infra model.\n\n2. **Sigstore outage = deadlock.** v3.0 \u00a73.6 admits Sigstore has <1% outage rate but treats this as acceptable risk because \"CI is down anyway\". The convergent reviewer concern: when Sigstore is down, Claude main cannot generate signed attestations, which means substantive commits cannot land via the v3 path. The fallback path (defer commit until Sigstore is up) is fine for routine commits but bad for time-critical commits (e.g., a Halper-delivery-day push at hour-23 of the delivery window).\n\n**Amendment (binding):**\n\nThe default Sigstore signing mode flips from keyless to **traditional public-key signing with a repo-checked-in public key**. Keyless signing becomes an OPTIONAL per-commit flag for high-public-verifiability deployments.\n\n**Amended default flow:**\n\n1. Zachary generates a long-lived signing key pair at v3 deployment time: `cosign generate-key-pair --output-key-prefix attestation-signer-v3` (produces `attestation-signer-v3.pub` + `attestation-signer-v3.key`). The `.pub` is committed to the repo at `policy/keys/attestation-signer-v3.pub`. The `.key` is stored as a GitHub Actions secret `ATTESTATION_SIGNER_KEY` (NOT committed; never echoed to logs).\n\n2. Claude main signs attestations via `cosign sign-blob --key ${{ secrets.ATTESTATION_SIGNER_KEY }} ...` \u2014 this runs INSIDE the GitHub Actions runner during the attestation-generation workflow (per \u00a710 point 5 + Q-F in \u00a711). The secret is scoped to the attestation-generation workflow only; the enforcement workflow has read-only access to the `.pub` key.\n\n3. The enforcement workflow verifies via `cosign verify-blob --key policy/keys/attestation-signer-v3.pub ...` \u2014 no Fulcio CA + no Rekor lookup + no internet round-trip during verification. Verification is fully offline-capable.\n\n**Keyless mode as opt-in (per-commit flag):**\n\nThe attestation predicate (\u00a713.1 schema) gets an additional field:\n\n```json\n{\n  \"predicate\": {\n    \"signing_mode\": \"static_key\"  // default; OR \"sigstore_keyless\"\n  }\n}\n```\n\nWhen `signing_mode == \"sigstore_keyless\"`, the cosign sign-blob step uses the OIDC-rooted flow per v3.0 \u00a73.4; verification per \u00a713.2's tight identity binding rules. This mode is opt-in for commits where Zachary wants public verifiability of the signing event (e.g., a Magna Carta v2.0 ratification commit that Zachary wants a public Rekor log entry for).\n\n**Default static-key mode advantages:**\n\n- No Fulcio + no Rekor dependency (Sigstore-outage tolerant)\n- No public timing-correlation surface (Rekor public log not touched)\n- Zero internet round-trip during verification (fully offline-verifiable from a fresh repo clone)\n- One key generated once at v3 deployment; rotation policy decided per Zachary direction (recommended: rotate annually + on any compromise indicator)\n\n**Static-key mode disadvantages (acknowledged):**\n\n- The key is a long-lived secret; if compromised, all attestations made with it are forgeable until rotation. Mitigation: key stored as GitHub Actions secret (encrypted at rest by GitHub; only decrypted into the runner during workflow execution); key rotation cadence (annual + on-compromise) limits compromise blast radius\n- Verification depends on the `.pub` key in the repo being uncompromised; an attacker with repo-write access could swap the `.pub` and forge attestations with their own key. Mitigation: branch protection on `policy/keys/**` requires Zachary review for any change; the policy hot-swap defense from \u00a713.6 below provides additional structural barrier\n\n**Retracts:** v3.0 \u00a73.6's \"Default recommendation: keyless\" framing. **Supersedes:** v3.0 \u00a73.4 signing flow's Sigstore Cosign keyless step as the default path. **Does NOT retract:** the v3.0 \u00a73.6 analysis of keyless vs traditional trade-offs (the analysis itself is preserved for audit trail; the DEFAULT recommendation flips). **Derives from:** D1 (Primary Clinical Purpose \u2014 Rekor public-log timing correlation is a privacy risk worth defending against) + Magna Carta P6 (Zachary's attention is the scarce resource \u2014 Sigstore-outage-deferred commits spend that attention to track) + P14 (purpose is fact; the purpose of attestation signing is integrity binding, not public verifiability; integrity binding works equally well with static keys) + Reviewer 3 + Reviewer 4 convergent finding.\n\n### \u00a713.6 \u2014 Reviewer 4 specifics (adopted vs deferred with rationale)\n\nRound 2 Reviewer 4 (GPT-5.4 RECONSIDER-REBUILD) supplied 5 additional specific recommendations beyond the 5 convergent changes. Each is evaluated below for adoption or deferral.\n\n**ADOPTED (binding amendments to relevant v3.0 sections):**\n\n#### \u00a713.6.1 \u2014 sha256 (not sha1) as primary subject digest [ADOPTED \u2014 already integrated into \u00a713.1]\n\nPer \u00a713.1 rule 4 above: subject.digest uses sha256 as the primary field. The in-toto digest set spec supports both; sha256 is the convergent recommended primary for new attestations. sha1 MAY appear in legacy v3.0-pre-amendment attestations and the policy evaluator's compatibility layer; for v3.1+ attestations the policy evaluator requires sha256.\n\n**Rationale:** sha1 has known collision attacks (SHAttered 2017, Shambles 2020); for new cryptographic bindings, sha256 is the modern default. Adoption cost is zero (cosign + jq + git all support sha256 natively); rejection cost would be future migration if sha1 acceptance broadens in attack surface.\n\n#### \u00a713.6.2 \u2014 Tight checkout of policy from PROTECTED BASE (not candidate PR HEAD) [ADOPTED \u2014 new \u00a713.6.2.A binding rule]\n\n**The policy hot-swap attack:** a malicious commit on a feature branch could include policy/ directory changes alongside substantive changes. If the enforcement workflow checks out the candidate PR HEAD (default GitHub Actions behavior) and runs OPA against the PR-HEAD policy/, the attacker has SWAPPED the policy to one that approves their own attestation. Defeat: the enforcement workflow checks out the PROTECTED BASE (main branch's policy/ directory) and runs OPA against THAT policy, regardless of what policy/ changes appear on the candidate PR HEAD.\n\n**Binding rule:** The \u00a75.1 enforcement workflow's checkout step is amended to perform a two-checkout:\n\n```yaml\n# AMENDED \u00a75.1 checkout step per Reviewer 4 \u00a713.6.2\n- name: Checkout candidate PR HEAD (for attestation file access)\n  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1\n  with:\n    fetch-depth: 0\n    path: candidate\n\n- name: Checkout PROTECTED BASE policy\n  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1\n  with:\n    ref: refs/heads/main   # always main; never the PR HEAD\n    sparse-checkout: |\n      policy/\n      .attestations/\n    path: protected_base\n\n# OPA evaluation uses protected_base/policy/ (not candidate/policy/)\n# Attestation files come from candidate/.attestations/ (the PR's own attestations)\n- name: Run OPA tests against PROTECTED BASE policy\n  run: |\n    opa test protected_base/policy/ --verbose --explain=fails\n    opa test protected_base/policy/ --coverage --threshold=80\n\n- name: Evaluate attestation against PROTECTED BASE policy\n  run: |\n    opa eval --data protected_base/policy/rules/ \\\n      --input \"candidate/.attestations/${SHA}.json\" \\\n      --format json \\\n      'data.compliance.allow' > eval-result.json\n```\n\n**Rationale:** the policy hot-swap is one of the highest-likelihood attack patterns against policy-as-code systems; the defense is structural (checkout strategy) and free (one extra checkout step adds ~2s of CI runtime; well within the \u00a75.2 5-minute budget).\n\n**Composition with \u00a713.5:** the public key at `policy/keys/attestation-signer-v3.pub` is ALSO checked out from PROTECTED BASE, not candidate PR HEAD. This means a PR that swaps the public key AND signs an attestation with its own private key would fail verification \u2014 the verify step uses the BASE's public key, not the PR's.\n\n#### \u00a713.6.3 \u2014 NFKC normalization on every string field before policy evaluation [ADOPTED \u2014 new \u00a713.6.3.A binding rule]\n\n**The bypass pattern:** Unicode has multiple ways to encode \"the same\" string. ZWSP (zero-width space U+200B) inside a status enum value (`PASS`) reads as \"PASS\" to humans + breaks regex/equality checks unless the comparison normalizes. Homoglyph attacks (Cyrillic '\u0430' U+0430 vs Latin 'a' U+0061) similarly. Compatibility forms (full-width '\uff30' vs half-width 'P') similarly. v2 Wave 5 had a ZWSP bypass finding; v3 must defend.\n\n**Binding rule:** every string field in the attestation predicate, before being passed to OPA's `input.*`, gets `String.prototype.normalize('NFKC')` applied. The evaluator plumbing step:\n\n```javascript\n// AMENDED plumbing step per Reviewer 4 \u00a713.6.3\nfunction normalizeAttestation(att) {\n  const traverse = (v) => {\n    if (typeof v === 'string') return v.normalize('NFKC');\n    if (Array.isArray(v)) return v.map(traverse);\n    if (v && typeof v === 'object') {\n      const out = {};\n      for (const [k, val] of Object.entries(v)) out[k.normalize('NFKC')] = traverse(val);\n      return out;\n    }\n    return v;\n  };\n  return traverse(att);\n}\n```\n\nThe normalized attestation is the input to `opa eval`. The non-normalized raw attestation is preserved for audit logging only.\n\n**Rationale:** NFKC is the strongest of the four Unicode normalization forms (NFC, NFD, NFKC, NFKD); it folds compatibility forms + canonical forms. Adoption cost is one helper function (~10 lines); rejection cost would be a Wave-5-style bypass via ZWSP that no one notices for months.\n\n**ADOPTED with modification:**\n\n#### \u00a713.6.4 \u2014 Conftest vs OPA: stays as OPA, with Conftest as a fallback option [ADOPTED-WITH-MODIFICATION]\n\nReviewer 4 proposed Conftest as a lighter-weight alternative to pure OPA for 1-person-team maintainability. Conftest is a thin OPA wrapper targeted at config-file validation. For this project's policy needs (J11-J16 + D1-D3 + Rule 3.X rules), Conftest CAN do the work, with some loss of OPA's full Rego expressiveness (e.g., complex partial evaluation features that we don't currently use).\n\n**Decision:** v3.1 stays on **pure OPA** as the default for policy plane plumbing, NOT Conftest. Rationale: (a) the projected growth path includes rules that may need full Rego expressiveness (e.g., a future rule that does cross-attestation reasoning over multiple commits in a PR); (b) the OPA-vs-Conftest cost differential at this project's scale is marginal (~0 vs ~0); (c) Reviewer 4's concern was \"1-person team should have simpler tooling\" but the tooling complexity at this scale is in the rule LOGIC, not in the OPA vs Conftest choice.\n\n**Conftest available as a fallback option per Q-B variant (b4):** if Zachary direction at any point in the v3.1+ lifecycle says \"the Rego pack is getting too complex for me to review,\" the migration path to Conftest is straightforward (rename `policy/rules/*.rego` \u2192 `policy/policy/*.rego`; replace `opa eval` with `conftest test`; the rules themselves are bytewise-compatible). This option is documented but not the default.\n\n**Small-TypeScript-validator alternative (Reviewer 4 b3-variant):** explicitly NOT adopted. The convergent verdict from Round 1 was that custom Node.js policy logic is the wrong substrate. Reverting to a Node.js validator (TypeScript or not) re-introduces the v2 failure mode. The intent is OFFLOAD policy logic to declarative tooling (OPA / Rego), not to re-skin the v2 substrate.\n\n#### \u00a713.6.5 \u2014 Per-PR attestation vs per-commit attestation [DEFERRED-WITH-RATIONALE]\n\nReviewer 4 proposed per-PR attestation as operational-sanity preference: one attestation covering N commits in a PR, rather than one attestation per commit. This reduces attestation churn from ~1000/year to ~100-200/year at typical project velocity.\n\n**Decision:** v3.1 stays on **per-commit attestation** as the default; per-PR attestation deferred to a future v3.2 amendment after operational experience.\n\n**Rationale for deferral (not rejection):**\n\n- The TDD discipline in \u00a73.5 + \u00a74.5 relies on per-commit attestation: each of the 3 commits in the TDD sequence (failing test \u2192 passing rule \u2192 attestation) gets its own attestation; the merge gate enforces all three present\n- The TOCTOU defense in \u00a75.1 + \u00a713.2 binds the attestation's subject digest to a specific commit SHA; per-PR attestation would need to bind to a range of SHAs (more complex; new failure modes to design against)\n- The per-commit pattern matches the granularity of the J11-J16 audit row (which is per-prompt/per-commit, not per-PR)\n- The ~1000-attestations-per-year volume estimate is manageable (~3 MB/year storage; ~3s/commit signing overhead)\n- Per-PR attestation IS attractive at scale (1000+ commits/year); revisit in v3.2 when operational data confirms it\n\n**Tracked debt:** add to Governance Debt Ledger as GD-38 \"Per-PR attestation amendment evaluation\" with status DEFERRED-pending-operational-data; review after v3.1 has been operational for 30 days post-Round-3-ratification.\n\n### \u00a713.7 \u2014 Conflicts between the 5 changes (audited)\n\nPer Mandatory Coverage Gap discipline + the \u00a710 v3.0 coverage gap structural acknowledgment, the 5 changes are audited for internal conflicts:\n\n| Conflict candidate | Resolution |\n|---|---|\n| \u00a713.3 commentary-OPTIONAL vs \u00a713.4 2-plane collapse | NO CONFLICT. \u00a713.4 keeps the commentary workflow file as a separate (optional) plane; \u00a713.3 governs WHEN it runs. The 2-plane diagram in \u00a713.4 explicitly shows commentary as \"optional output\" parallel to enforcement; this is consistent with \u00a713.3's default-OFF gating. |\n| \u00a713.5 static-key default vs \u00a713.2 tight OIDC binding | RESOLVED. The static-key path does NOT use Sigstore Fulcio OIDC; the \u00a713.2 tight binding applies ONLY to the keyless path (when `signing_mode == \"sigstore_keyless\"`). For static-key mode, verification is `cosign verify-blob --key policy/keys/attestation-signer-v3.pub ...` with no OIDC claims to bind. \u00a713.2's amended `--certificate-identity` + workflow-trigger + workflow-ref + workflow-sha + workflow-repository flags are inapplicable to static-key mode and the verification step is conditional on signing_mode. |\n| \u00a713.1 sha256 subject digest vs \u00a713.5 static-key signature algorithm | NO CONFLICT. The subject digest (what's being signed about) and the signature algorithm (how it's signed) are independent. cosign default signature algorithm is ECDSA-P256-SHA256 (or RSA-PSS); both support sha256 subject digests. |\n| \u00a713.6.2 PROTECTED BASE policy checkout vs \u00a73.5 TDD discipline (rule added in PR) | EXPLICIT TENSION; RESOLVED VIA SEPARATE LANE. The \u00a73.5 TDD pattern adds a rule via 3 commits ON a feature branch. The \u00a713.6.2 PROTECTED BASE checkout means the enforcement workflow uses MAIN'S policy/, not the feature branch's. **Resolution:** the feature branch's policy/ changes are NOT applied to enforcement until the PR is merged to main. The 3-commit TDD sequence on the feature branch is verifiable LOCALLY via `opa test policy/` against the feature branch's policy/, and is verifiable via the PR's CI status check (a separate `policy-test` workflow that DOES checkout feature-branch policy/ for testing-only purposes \u2014 explicitly not for enforcement). The enforcement gate is \"merge to main triggers re-evaluation against new main policy/\" \u2014 pattern is the same as the Conftest \"policy-as-code merged before enforcement\" idiom. **NEW workflow file to add:** `.github/workflows/policy-test.yml` runs `opa test` against feature-branch policy/ for PR validation (non-merge-blocking informational check); merge to main re-runs enforcement against new main policy/. |\n| \u00a713.6.3 NFKC normalization vs \u00a713.1 closed enum status values | NO CONFLICT. NFKC normalization is the LAYER 1 defense; the closed enum (status \u2208 {PASS, FAIL, PARTIAL, N_A, PASS_CARVE_OUT}) is the LAYER 2 defense. NFKC ensures `P\u200bASS` normalizes to `PASS`; the enum check then accepts it. If NFKC alone produced a string not in the enum (e.g., `PA SS` with a regular space), the enum check rejects it. Defense in depth. |\n| \u00a713.6.4 OPA-stays vs \u00a713.6.5 per-PR deferred | NO CONFLICT. OPA vs Conftest is the policy engine choice; per-PR vs per-commit is the attestation granularity choice. Independent dimensions. |\n\nThe cross-cutting conflict acknowledged is \u00a713.6.2 vs \u00a73.5 TDD, resolved by adding a separate non-merge-blocking `policy-test.yml` workflow that exercises feature-branch policy for local validation. This is a **new artifact** (`.github/workflows/policy-test.yml`) added by the amendment; it follows the Mandatory Pre-Build Search gate header convention at authoring time per \u00a713.8 below.\n\n### \u00a713.8 \u2014 Implementation impact on \u00a77 + \u00a78 (Migration path + Phase plan)\n\nThe amendment modifies the \u00a78 phase plan as follows:\n\n- **P1 (External review of v3.0):** ALREADY COMPLETED via Round 2. Status flips DONE.\n- **P1.5 (NEW \u2014 External review of v3.1 amendment):** Round 3 dispatch of the AMENDED spec by 1+ external reviewer; binding precondition for P2-P7. Recommended dispatch: same `template: B-premortem`; new reviewer pool member (e.g., Claude Sonnet 4.7 acting as Reviewer 5) OR re-dispatch one of Round 2 reviewers on the AMENDED spec (test for cross-version convergence). Effort: ~2-3h dispatch + 0.5h Zachary review.\n- **P2 (Policy plane authoring):** unchanged in scope but ADDS files per amendment: `policy/catalogs/tier_classification_patterns.json` + `policy/catalogs/panel_framings.json` (per \u00a713.1 rules 1 + 2) + `policy/keys/attestation-signer-v3.pub` (per \u00a713.5 default static-key) + `policy/rules/panel_framings_valid.rego` (per \u00a713.1 rule 2 enforcement). Effort estimate revised: ~7-9h (was ~6-8h).\n- **P3 (Evidence plane authoring):** unchanged in scope but `scripts/generate-attestation-v3.mjs` must implement the \u00a713.1 closed schema + \u00a713.6.3 NFKC normalization + \u00a713.5 static-key signing by default + \u00a713.3 commentary_requested field. Effort: ~5-7h (was ~4-6h).\n- **P4 (Enforcement plane authoring):** unchanged in scope but `compliance-enforce.yml` adds \u00a713.2 tight OIDC binding (for the keyless opt-in path) + \u00a713.5 static-key verification (for the default path) + \u00a713.6.2 PROTECTED BASE checkout strategy. Effort: ~4-6h (was ~3-5h).\n- **P5 (Output plane authoring):** REPLACED. New scope: ship the commentary workflow as DEFAULT-OFF per \u00a713.3 with the opt-in gating job. The \u00a76.2 preapproved-fields schema for digest output survives 1:1. Effort: ~3h (was ~3-4h; slight reduction because the default-OFF case has less to test).\n- **P5.5 (NEW \u2014 Policy-test workflow):** add `.github/workflows/policy-test.yml` per \u00a713.7 conflict resolution. Effort: ~1h.\n- **P6 (Wave-5 regression suite):** unchanged in scope; ADD \u00a713.x-specific regressions: PHI-in-tier-classification-evidence test (asserts free-text rejected), PHI-in-panel-framings test (asserts unregistered values rejected), PHI-in-subject-name test (asserts cleartext branch rejected), OIDC token confusion test (asserts a token from a different workflow rejected by \u00a713.2 tight binding), policy hot-swap test (asserts \u00a713.6.2 PROTECTED BASE checkout defeats malicious policy/ in PR), ZWSP bypass test (asserts \u00a713.6.3 NFKC normalization defeats Unicode tricks). Effort: ~5-7h (was ~4-6h).\n- **P7 (Archive v2 + Magna Carta amendments):** unchanged.\n- **P8 (External NON-Claude review of v3 deployment):** unchanged; remains binding pre-CI-re-enable.\n- **P9 (Branch protection + first live commits):** unchanged.\n- **P10 (Quarterly review):** unchanged.\n\n**Revised total estimated effort to v3.1 operational:** ~30-40h Claude main work + Zachary configuration (~1-1.5h total; key-pair generation + branch protection wiring + commentary opt-in selection adds ~30 min).\n\n### \u00a713.9 \u2014 Open questions for Zachary (additive to \u00a711)\n\nIn addition to the 7 v3.0 open questions in \u00a711, the v3.1 amendment surfaces:\n\n8. **Q-H \u2014 Round 3 external review reviewer choice?** Options: (h1) re-dispatch one of Round 2 reviewers on the AMENDED spec (tests for cross-version convergence); (h2) dispatch a fresh reviewer (Claude Sonnet 4.7 or similar) for independence from prior verdicts; (h3) dispatch BOTH (h1 + h2 in parallel). Default recommendation: (h3) \u2014 same effort as (h1) or (h2) alone given the parallel-dispatch pattern; provides the strongest convergence signal. Token cost is not a factor per CLAUDE.md Document Review Gate Amendment 2026-05-30.\n\n9. **Q-I \u2014 Static-key vs keyless signing \u2014 confirm default flip?** \u00a713.5 flips the default from keyless to static-key. Zachary confirmation: do you accept this flip? If you prefer keeping keyless as default (despite the Rekor public-log timing-correlation risk), say so and \u00a713.5 amends to opposite-default with static-key as the opt-in mode.\n\n10. **Q-J \u2014 Long-lived signing key rotation cadence?** \u00a713.5 default static-key mode introduces a long-lived signing key. Rotation cadence options: (j1) annual rotation + on-compromise (default recommended); (j2) quarterly rotation + on-compromise (more conservative; more rotation churn); (j3) on-compromise only (less conservative; relies on Zachary detecting compromise). Default: (j1).\n\n11. **Q-K \u2014 Policy-test workflow as non-merge-blocking vs merge-blocking?** \u00a713.7 conflict resolution introduces `policy-test.yml` as a non-merge-blocking informational workflow. Alternative: make it merge-blocking (a PR with broken policy tests cannot merge to main even if `compliance-enforce` passes against the protected base policy/). Default: non-merge-blocking (the \u00a713.6.2 PROTECTED BASE checkout already provides the structural defense; making policy-test merge-blocking adds enforcement-of-feature-branch-policy which is conceptually wrong per the protect-the-base discipline). Zachary confirmation requested.\n\n12. **Q-L \u2014 Commentary opt-in default for governance amendments?** \u00a713.3 makes commentary OFF-by-default per commit. For high-stakes commits (e.g., Magna Carta amendments, Rule 3.X additions, governance debt ledger updates), is the opt-in burden too high? Alternative: AUTO-opt-in for commits whose subject matches a regex (e.g., `^(magna-carta|rule-3\\\\.|governance-debt)`). Default: pure-opt-in per commit (no auto-detection magic; consistent with the \"no free-text policy\" discipline); Zachary explicitly flags `--commentary-requested` when wanted.\n\n13. **Q-M \u2014 Per-PR attestation v3.2 review timing?** \u00a713.6.5 defers per-PR attestation to v3.2 pending operational data. After v3.1 has been operational for 30 days, the per-PR review fires. Is 30 days the right interval? Options: (m1) 30 days (default; per GD-27 high-frequency-gate tier first-cycle re-tuning); (m2) 14 days (faster signal); (m3) 90 days (more data). Default: (m1).\n\n### \u00a713.10 \u2014 Coverage gap (per Rule 3.7; amendment surface)\n\nSurfaces NOT checked by this amendment:\n\n- **Rego rule audit for \u00a713.1 closed schema enforcement** \u2014 the amendment specifies the closed shapes but the actual Rego rules that enforce them (panel_framings_valid.rego, tier_classification_evidence_valid.rego, status_enum_valid.rego, etc.) are not yet authored in this amendment. P2 phase authoring will catch this; the amendment specifies INTENT not IMPLEMENTATION.\n- **CI testing of \u00a713.6.2 PROTECTED BASE checkout strategy in remote-container** \u2014 the amendment specifies the GitHub Actions checkout strategy but does not test it from the remote-container environment. This is a Stress Test Gate Remote-Container Clause situation: substantively unverified until the desktop session runs against actual CI. Tracked as a debt to close on next desktop session.\n- **Operational testing of static-key vs keyless signing latency** \u2014 the amendment specifies the default flip but does not benchmark the signing latency for either mode. Sigstore keyless can have ~5-10s latency per signing event; static-key is ~0.5s. The amendment's effort estimates assume static-key default; if keyless turns out to be required for any reason, the \u00a78 P3 effort estimate may need adjustment.\n- **Round 3 reviewer alignment with Round 1 + Round 2 frames** \u2014 the amendment assumes Round 3 will use a similar premortem framing. If Round 3 reviewer interprets the spec differently (e.g., constitutional vs operational vs cost-benefit framing), the convergence-pattern analysis differs.\n- **Schema_version 3.1 vs cosign + opa version compatibility** \u2014 the amendment specifies schema_version 3.1 in \u00a713.1 but does not pin specific cosign or opa versions known to support the new schema. Implementation may surface version constraints; if so, \u00a78 P3 + P4 add a version-pin clarification step.\n\nPossible rules residing in unchecked surfaces:\n- Conftest semantic subtleties (deferred per \u00a713.6.4; the OPA-stays decision may need revisit if Rego features get unexpected)\n- Sigstore + cosign tooling evolution (Sigstore is rapidly evolving; the \u00a713.2 binding flag names may rename in a future cosign version)\n- in-toto v1 spec future-versioning (in-toto's predicate type registry may add a \"compliance-row\" subtype that conflicts with the project-custom URI)\n- Sub-agent panel framing catalog growth (the \u00a713.1 rule 2 catalog will need ongoing maintenance as new panel framings get added; cadence unclear)\n\nCoverage gap line for this amendment: surfaces NOT checked this amendment \u2014 Rego rule authoring for closed-schema enforcement, CI runtime testing of PROTECTED BASE checkout strategy, signing latency benchmarks, Round 3 reviewer framing alignment, Sigstore + cosign tooling version-pinning. Possible rules residing there: Conftest semantic subtleties, Sigstore tooling evolution surface, in-toto registry evolution, sub-agent panel framing catalog cadence.\n\n### \u00a713.11 \u2014 Reference + cross-link surface (amendment-specific)\n\n- `scripts/external-review/queue.jsonl` line 9 \u2014 Round 2 Reviewer 3 (Sonnet 2) verdict + response_summary\n- `scripts/external-review/queue.jsonl` line 10 \u2014 Round 2 Reviewer 4 (GPT-5.4) verdict + response_summary\n- `scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md` \u00a7\u00a73-6 (this same file, sections above) \u2014 preserved verbatim per OP-6; superseded in part by \u00a713 above\n- `CLAUDE.md` \u00a7Mandatory Document Review Gate \u2014 the gate this amendment passes through (inline display + synopsis below)\n- `CLAUDE.md` \u00a7Mandatory Plain-Language Communication \u2014 the gate this amendment passes through (glossary additions at \u00a713 header; first-mention spell-outs throughout)\n- `CLAUDE.md` \u00a7Mandatory Archive Policy + OP-6 (audit-trail preservation) \u2014 the operating procedure this amendment follows (v3.0 sections preserved verbatim; \u00a713 appended)\n- `CLAUDE.md` \u00a7Governance Debt Ledger \u2014 GD-38 to be added per \u00a713.6.5 deferred per-PR attestation evaluation\n- `CLAUDE.md` \u00a7Codified Rule 3.7 \u2014 the coverage-gap discipline followed in \u00a713.10\n- Convergent reviewer Round 2 verdict pattern \u2014 Reviewer 3 SHIP-WITH-CHANGES + Reviewer 4 RECONSIDER-REBUILD architecturally converged on the same 5 changes despite divergent verdict labels; this convergence is the load-bearing evidence for binding the amendment now (vs deferring to a Round 3 verdict before authoring)\n\n---\n\n**End of \u00a713 v3.1 AMENDMENT block.** Authored 2026-06-02 UTC by Claude main; binding upon Round 3 external review of THIS AMENDED spec returning RECONSIDER-or-better convergence per the M\u00fcnchhausen-trilemma recursive pattern established in v3.0 \u00a710 coverage gap item 1. v3.0 \u00a7\u00a73-6 preserved verbatim above per OP-6. Where \u00a713 conflicts with v3.0 \u00a7\u00a73-6, \u00a713 controls per the AMENDMENT NOTICE at the top of this file.\n\n---\n\n**End of framework v3 architecture spec.** Status: v3.0 DRAFT-PROPOSAL + v3.1 amendment per Round 2 external review (see \u00a713). Path: `/home/user/health-dashboard/scripts/FRAMEWORK-v3-OPA-INTOTO-2026-06-02.md`. Supersedes (substrate only): `scripts/FRAMEWORK-v2-CI-CENTERED-2026-06-01.md`. Governance content survives unchanged. Next action: P1.5 external review of THIS AMENDED v3.1 doc per \u00a713.8 (Round 3; recommended dispatch: same `template: B-premortem` via `scripts/external-review/queue.jsonl` append + Reviewer 5 or re-Round 2 reviewer per Q-H). Per Mandatory Document Review Gate: inline content above; no path-only references. Per Mandatory Plain-Language Communication: glossary at \u00a7Glossary + \u00a713 header glossary additions; first-mention spell-outs throughout. Per Magna Carta P3: this doc is a CLAIM; the Phase-2-onward shipping artifacts are the implementation evidence still owed; the v3.1 amendment is itself a CLAIM that the 5 convergent Round 2 changes correctly address the v3.0 architectural weaknesses; Round 3 verdict is the ratification.\n\n\n\n---\n\n**End of bundle.** All artifacts above are embedded verbatim from the source paths. No external fetches required. Reviewer may paste this entire file into a fresh non-Claude LLM thread; the Round 3 prompt + the full v3.1 architecture spec (v3.0 \u00a7\u00a71-12 preserved verbatim per OP-6 + v3.1 \u00a713 amendment block) are all present.\n", "creation_timestamp": "2026-06-03T01:52:04.000000Z"}, {"uuid": "ab6fd18c-1862-4aa2-b573-611ac119a22e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3094", "type": "seen", "source": "https://bsky.app/profile/dkub.dev/post/3mngjhoz5tdz2", "content": "Damn. We really just did absolutely nothing after the xz CVE-2024-3094 did we?", "creation_timestamp": "2026-06-04T01:59:37.094736Z"}]}