شناسه CVE-2026-32746 :CVE
CWE-120 :CWE
yes :Advisory
منتشر شده: مارس 13, 2026
به روز شده: مارس 13, 2026
امتیاز: 9.8
نوع حمله: Buffer Overflow

اثر گذاری: Remote code execution(RCE)
حوزه: نرم افزارهای شبکه و امنیت
برند: GNU
محصول: Apache Solr
وضعیتPublished :CVE
Yes :POC
وضعیت آسیب پذیری: patch نشده

چکیده

آسیب‌پذیری بحرانی در سرویس telnetd از مجموعه GNU inetutils به دلیل وجود سرریز بافر (Buffer Overflow) در فرآیند پردازش زیرگزینه LINEMODE SLC و در مرحله تعیین گزینه‌های پروتکل Telnet (Option Negotiation) رخ می‌دهد. این ضعف به مهاجم از راه دور اجازه می‌دهد با ارسال یک درخواست دستکاری‌شده از طریق شبکه و بدون نیاز به احراز هویت، موجب خرابی حافظه (Memory Corruption) شده و در نهایت اجرای کد دلخواه (RCE) را با سطح دسترسی root روی سیستم هدف ممکن سازد.

توضیحات

آسیب‌پذیری CVE-2026-32746 یک ضعف بحرانی از نوع سرریز بافر (Buffer Overflow) مطابق با CWE-120 است که در پیاده‌سازی LINEMODE SLC (Set Local Characters) در سرویس telnetd از بسته GNU inetutils مشاهده می‌شود. این بخش از کد وظیفه پردازش زیرگزینه‌های SLC در پروتکل Telnet را بر عهده دارد؛ پروتکلی که برای ارتباط ترمینالی از طریق شبکه و بر پایه مکانیزم تعیین گزینه‌های پروتکل (Option Negotiation) با استفاده از کاراکتر کنترلی IAC (Interpret As Command) طراحی شده است.

ریشه این آسیب‌پذیری در فایل ‎telnetd/slc.c‎ و به‌طور مشخص در تابع ‎add_slc‎ قرار دارد. این تابع مسئول افزودن داده‌های SLC سه گانه دریافتی شامل سه مقدار ‎func‎، ‎flag‎ و ‎value‎ به یک بافر ثابت به نام ‎slcbuf‎ است؛ بافری که اندازه کل آن 108 بایت است، اما تنها 104 بایت آن برای ذخیره‌سازی واقعی سه گانه ها استفاده می‌شود و 4 بایت پایانی در عمل به‌عنوان فضای رزرو باقی می‌ماند. نکته کلیدی این است که در این تابع هیچ‌گونه بررسی برای کنترل ظرفیت بافر (Buffer Boundary Checking) انجام نمی‌شود؛ در نتیجه اشاره‌گر داخلی slcptr بدون محدودیت به نوشتن ادامه داده و از مرز حافظه تخصیص‌یافته عبور می‌کند.

در سناریوی حمله، کلاینت می‌تواند یک زیرگزینه SLC با حجم بالا ارسال کند؛ این زیرگزینه در چارچوب محدودیت پروتکل می‌تواند تا حدود 512 بایت داده شامل تقریباً 170 سه گانه را در بر بگیرد. در صورتی که مقدار func هر یک از این سه گانه ها بزرگ‌تر از 18 باشد (که نشان‌دهنده عدم پشتیبانی آن قابلیت است)، سرور برای هر مورد یک پاسخ پشتیبانی نشده (not supported) تولید کرده و این پاسخ‌ها از طریق تابع add_slc در همان بافر slcbuf ذخیره می‌شوند. در نتیجه، پس از پردازش حدود 35 سه گانه ، ظرفیت بافر به پایان رسیده و عملیات نوشتن از محدوده مجاز خارج می‌شود.

این وضعیت منجر به نوشتن خارج از محدوده حافظه (Out-of-bounds Write) شده و بخش‌های مجاور در حافظه، به‌ویژه قسمت BSS (Block Started by Symbol segment) را تحت تأثیر قرار می‌دهد. در این میان حتی ساختار حیاتی slcptr نیز ممکن است بازنویسی شود. در ادامه، تابع end_slc از این اشاره‌گر مخرب استفاده می‌کند که نتیجه آن ایجاد یک شرایط نوشتن دلخواه در حافظه (Arbitrary Write Primitive) است؛ قابلیتی که در عمل می‌تواند منجر به کنترل جریان اجرای برنامه و در نهایت اجرای کد دلخواه از راه دور (RCE) شود.

این آسیب‌پذیری به‌صورت کاملاً از راه دور و بدون نیاز به احراز هویت (Pre-Authentication) و همچنین بدون تعامل کاربر قابل بهره‌برداری است. مهاجم تنها کافی است به پورت 23 متصل شده و در فرآیند اولیه تعیین گزینه‌های Telnetبا ارسال پاسخ WILL LINEMODE در مقابل پیام DO LINEMODE از سوی سرور، حالت LINEMODE را فعال کند. پس از آن، ارسال یک LINEMODE SLC suboption دست‌کاری‌شده برای ایجاد سرریز بافر کافی است. این حمله به دلیل ساختار ساده و قابل پیش‌بینی داده‌ها، به‌راحتی قابل خودکارسازی بوده و با استفاده از اسکریپت‌ها یا ابزارهای تولید بسته‌های Telnet قابل اجرا است.

کد اثبات مفهومی (PoC) منتشرشده نشان می‌دهد که تنها با ارسال حدود 40 تا 50 سه گانه مخرب می‌توان موجب کرش برنامه یا ایجاد خرابی کنترل‌شده در حافظه شد که زمینه‌ساز بهره‌برداری پیشرفته‌تر است. در سناریوهای عملی، این وضعیت می‌تواند منجر به توسعه اکسپلویت کامل و دستیابی به اجرای کد دلخواه شود.

از منظر اثرگذاری، این آسیب‌پذیری می‌تواند محرمانگی (Confidentiality) را از طریق دسترسی غیرمجاز به داده‌های سیستم، یکپارچگی (Integrity) را از طریق تغییر یا دستکاری ساختارهای سیستمی و فایل‌ها، و دسترس‌پذیری (Availability) را از طریق از کار انداختن سرویس یا ایجاد کرش‌های هدفمند به‌طور کامل تحت تأثیر قرار دهد. نکته بسیار مهم این است که سرویس telnetd در بسیاری از پیاده‌سازی‌ها با سطح دسترسی root اجرا می‌شود؛ بنابراین موفقیت در بهره‌برداری از این ضعف می‌تواند معادل با تصاحب کامل سیستم باشد.

در زمان نگارش این تحلیل، برای این آسیب‌پذیری پچ رسمی منتشر نشده است که این موضوع ریسک عملیاتی آن را در محیط‌های در معرض اینترنت به‌طور قابل توجهی افزایش می‌دهد.

CVSS

Score	Severity	Version	Vector String
9.8	CRITICAL	3.1	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

لیست محصولات آسیب پذیر

Versions	Product
affected from 0 through 2.7	inetutils

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که Inetutils را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.

Approx. Usage in .ir Domain via Google (Total Pages)	Search Query (Dork)	Product
18700	site:.ir “Telnet”	Inetutils

نتیجه گیری

این آسیب‌پذیری در سرویس telnetd از بسته GNU inetutils به دلیل ضعف در کنترل مرزهای حافظه هنگام پردازش سه گانه های SLC (Set Local Characters) رخ می‌دهد. در نتیجه، مهاجم می‌تواند تنها با برقراری یک اتصال ساده به پورت 23 و ارسال داده دستکاری‌شده، شرایط سرریز بافر را ایجاد کرده و در نهایت به اجرای کد از راه دور با سطح دسترسی root دست یابد. از آنجا که این ضعف پیش از مرحله احراز هویت قابل بهره‌برداری است، سطح ریسک آن بسیار بالا ارزیابی می‌شود و نیازمند اقدام فوری برای کاهش سطح حمله است.

برای کاهش ریسک و جلوگیری از بهره‌برداری، اقدامات زیر توصیه می‌شود:

غیرفعال‌سازی سرویس Telnet: اگر استفاده از Telnet ضرورت ندارد، سرویس telnetd را به‌طور کامل غیرفعال کرده و به‌جای آن از پروتکل امن‌تری مانند SSH استفاده کنید؛ زیرا Telnet فاقد رمزنگاری و بسیاری از سازوکارهای امنیتی پایه است.
محدودسازی دسترسی شبکه‌ای: دسترسی به پورت 23 را در فایروال تا حد امکان محدود کرده و آن را فقط به آدرس‌های مشخص و مورد اعتماد اختصاص دهید.
ایزوله‌سازی سرویس: در صورت نیاز به استفاده از Telnet، بهتر است telnetd در محیط‌های ایزوله مانند Docker، chroot jail یا sandbox اجرا شود تا در صورت سوءاستفاده، دامنه اثر حمله محدود بماند.
محدودسازی مسیر دسترسی: دسترسی به Telnet را تنها از طریق شبکه‌های داخلی امن یا مسیرهای کنترل‌شده‌ای مانند VPN یا Gateway مدیریتی فراهم کنید.
کاهش سطح دسترسی سرویس: سرویس telnetd را با حداقل سطح دسترسی ممکن اجرا کرده و در صورت امکان از سیاست‌های ایمن‌سازی مانند SELinux یا AppArmor برای محدود کردن قابلیت‌های آن استفاده کنید.
مانیتورینگ امنیتی: لاگ‌های telnetd را با سطح جزئیات بالا (مانند DEBUG) ثبت و بررسی کنید تا عملکردهای غیرعادی، مانند زیرگزینه‌های غیرمعمول یا الگوهای غیرطبیعی در تعیین گزینه‌ها شناسایی شوند.

ترکیب اقداماتی مانند غیرفعال‌سازی Telnet، محدودسازی دسترسی شبکه‌ای و ایزوله‌سازی سرویس می‌تواند احتمال بهره‌برداری از این آسیب‌پذیری را به‌طور قابل توجهی کاهش داده و از سناریوهای بحرانی مانند تصاحب کامل سیستم جلوگیری کند.

امکان استفاده در تاکتیک‌های Mitre Attack (در زمان اجرای حمله)

Initial Access (TA0001)
مهاجم با اسکن شبکه و شناسایی یک سرویس telnetd آسیب‌پذیر، یک اتصال TCP به پورت 23 برقرار می‌کند. با ارسال یک پیام دست دادن (handshake) خاص حاوی زیرگزینه LINEMODE SLC و بدون نیاز به احراز هویت، موفق به بهره‌برداری از آسیب‌پذیری و دستیابی اولیه به سیستم می‌شود.

Execution (TA0002)
کلاهبرداری از طریق آسیب‌پذیری سرریز بافر، به مهاجم اجازه می‌دهد تا کد دلخواه خود را بر روی سیستم هدف اجرا کند. در موفقیت‌آمیزترین سناریو، مهاجم می‌تواند یک شل (shell) معکوس (reverse shell) یا یک شل بایند (bind shell) با دسترسی root اجرا کند و کنترل کامل سیستم را در دست گیرد.

Privilege Escalation (TA0004)
از آنجایی که سرویس telnetd معمولاً با بالاترین سطح دسترسی (root) اجرا می‌شود، بهره‌برداری موفق مستقیماً منجر به دستیابی به privileged account می‌شود و عملاً نیازی به Privilege Escalation مجزا نیست. مهاجم بلافاصله به سطح دسترسی root می‌رسد.

Credential Access (TA0006)
مهاجم با اجرای کد با دسترسی root، می‌تواند به تمام فایل‌های سیستم از جمله فایل‌های حاوی رمز عبور مانند /etc/shadow دسترسی پیدا کرده و اطلاعات احراز هویت کاربران را استخراج کند.

Impact (TA0040)
بهره‌برداری موفق از این آسیب‌پذیری می‌تواند عواقب فاجعه‌باری به همراه داشته باشد. مهاجم با دسترسی کامل root، قادر به نابودی محرمانگی، یکپارچگی و در دسترس بودن داده‌های سیستم است. این دسترسی می‌تواند منجر به سرقت اطلاعات حساس، تخریب داده‌ها، نصب باج‌افزار (Ransomware)، تغییر در پیکربندی سیستم، ایجاد یک پل برای حملات بیشتر به شبکه داخلی سازمان (Lateral Movement) و در نهایت از کار افتادن کامل سرویس‌های حیاتی شود. در چنین وضعیتی، اعتماد کاربران از بین رفته و سازمان با هزینه‌های سنگین ناشی از نقض داده‌ها، جریمه‌های قانونی و خسارت به اعتبار خود مواجه خواهد شد.

منابع

گزارش اثبات آسیب‌پذیری CVE-2026-32746

اطلاعات آسیب‌پذیری

عنوان: سرریز بافر پیش از احراز هویت در telnetd (Buffer Overflow)
شناسه: CVE-2026-32746
وضعیت مشاوره: Advisory / Patch Available
امتیاز: CVSS: 9.8 (Critical)
محصول: GNU Inetutils

محصول / نسخه‌های آسیب‌پذیر

در نسخه‌های زیر (پیش از اعمال پچ امنیتی):

GNU Inetutils telnetdنسخه2.7وتمامنسخه‌هایقبلی
• سیستم‌هایی که GNU Inetutils روی آن‌ها نصب شده و در معرض شبکه قرار دارد
پیاده‌سازی‌هایمشتق‌شدهازکدSLCاصلیBSD
کلیهتوزیع‌هایلینوکسکهازاینبستهاستفادهمی‌کنند
سیستم‌هایقدیمی (Legacy) دارایسرویسTelnet
محیط‌هایOT/ICSکههنوزازTelnetبهرهمی‌برند

محیط‌های درگیر

توزیع‌هایلینوکس (Debian, Ubuntu, RHEL, SUSE) کهسرویسtelnetdازبستهGNU Inetutilsرویآن‌هادرحالاجرااست
• سرویس‌های میزبان‌شده روی پورت 23 (پورت پیش‌فرض Telnet) و در معرض اینترنت
• محیط‌های ابری، مراکز داده و سرورهای مجازی که از Telnet بهره می‌برند
زیرساخت‌هایlegacyودستگاه‌هایصنعتیفاقدامکانمهاجرتبهSSH

کامپوننت‌های آسیب‌پذیر

telnetd (بخشسرویس‌دهندهTelnet)

ریشه مشکل (Root Cause Analysis)

ریشه مشکل به عدم وجود بررسی حد مجاز (Bounds Checking) در هنگام ساخت پاسخ پروتکل Telnet بازمی‌گردد.

سرویس telnetd برای مدیریت ویژگی LINEMODE، از یک بافر ثابت به اندازه ۱۰۸ بایت به نام slcbuf استفاده می‌کند. از این مقدار، فقط ۱۰۴ بایت فضای خالی برای داده‌ها وجود دارد (۴ بایت اول مربوط به هدر است) . هنگامی که کلاینت درخواست تنظیم کاراکترهای محلی (SLC) را ارسال می‌کند، تابع add_slc برای هر “سه‌تایی” (triplet) کاراکتر، ۳ بایت به بافر اضافه می‌کند. تابع add_slc هیچ‌گاه بررسی نمی‌کند که آیا بافر پر شده است یا خیر و صرفاً اشاره‌گر slcptr را افزایش می‌دهد .

اگر کلاینت بیش از حد مجاز (حدود ۳۵ عدد سه‌تایی) دستور SLC ارسال کند، بافر ۱۰۴ بایتی پر شده و داده‌ها شروع به نوشتن در حافظه مجاور (پس از slcbuf در بخش BSS) می‌کنند. این امر باعث بازنویسی اشاره‌گر slcptr و سایر متغیرهای حیاتی می‌شود که در نهایت به اجرای کد دلخواه توسط مهاجم منجر می‌شود

.بخش آسیب‌پذیر

رفتار ناامن سیستم:

دیمون telnetd داده‌های دریافتی از کاربر را بدون بررسی حجم، به یک بافر استاتیک کپی می‌کند.

نحوه سوءاستفاده مهاجم:

برقراری اتصال TCP به پورت ۲۳:

مهاجم یک اتصال ساده TCP به پورت ۲۳ سیستم هدف برقرار می‌کند. در این مرحله، هیچ صفحه ورود (login prompt) نمایش داده نمی‌شود و مهاجم نیازی به ارائه نام کاربری یا رمز عبور ندارد. (بدون نیاز به احراز هویت)

مهاجم ──TCP SYN──> سرور (پورت 23)

سرور ──TCP SYN-ACK──> مهاجم

ورود به حالت LINEMODE:

پس از برقراری اتصال، فرآیند مذاکره گزینه‌ها (Option Negotiation) آغاز می‌شود. در این مرحله، کلاینت و سرور در مورد قابلیت‌های پشتیبانی شده به توافق می‌رسند. مهاجم برای ورود به حالت آسیب‌پذیر، یک پیام WILL LINEMODE به سرور ارسال می‌کند:

IAC WILL LINEMODE (0xFF 0xFB 0x22)

سرور نیز در پاسخ، DO LINEMODE را ارسال می‌کند :

IAC DO LINEMODE (0xFF 0xFC 0x22)

با این کار، سرور وارد حالت پردازش SLC (Set Local Characters) می‌شود.

ارسال Payload مخرب (SLC Triplet های جعلی):

در این مرحله، مهاجم یک LINEMODE SLC حاوی تعداد زیادی SLC Triplet (سه‌تایی) ارسال می‌کند :

IAC SB LINEMODE LM_SLC <SLC Triplet> IAC SE

سرریزبافر (Buffer Overflow) درحافظهBSS:

بافر slcbuf دارای 108 بابت است که 4 بایت اول آن برای هدر رزرو شده است و 104 مابقی آن را می توان استفاده کرد.

در تابع نا امن add_slc به ازای هر SLC Triplet دریافتی 3 بایت در آدرس بافر slcptr می نویسد سپس اشاره گر slcptr را به اندازه 3 بات افزایش می دهد و هیچ گونه بررسی نمی کند که آیا بافر پر شده است یا خیر. پس از دریافت حدود 35 تا SLC Triplet، فضای 104 بایت بافر slcbuf کاملا پر می شود ولی ارسال SLC Triplet ها همچنان اداه می یابد. اینجا نقطه ی سرریز است و داده های اضافی شروع به نوشتن در حافظه ی مجاور می کنند.

بازنویسیحافظهوکنترلجریاناجرا و اجرایکد (Remote Code Execution):

داده های اضافی وقتی شروع به نوشتن در حافظه مجاور می کنند شامل داده های خود اشاره گر slcptr و سایر متغیرهای حیاتی می شوند و با بازنویسی اشاره‌گر slcptr مهاجم می‌تواند آدرس مقصد را برای نوشتن‌های بعدی کنترل کند. زمانی که تابع end_slc فراخوانی می‌شود، از اشاره‌گر slcptr آسیب‌دیده استفاده می‌کند و داده‌ها را تا آدرس کنترل شده توسط مهاجم ارسال می‌کند. این وضعیت به مهاجم امکان نوشتن دلخواه در حافظه (arbitrary write) را می‌دهد. در حالت تئوری، با استفاده از قابلیت نوشتن دلخواه در حافظه، مهاجم می‌تواند شل کد خود را در آدرس بازگشت تابع به آدرس شل کد تغییر دهد این کار باعث می شود سرور، شل کد را با دسترسی root اجرا کند.

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری یک نقطه ورود اولیه (Initial Access) بسیار قدرتمند و یک ابزار افزایش سطح دسترسی (Privilege Escalation) کامل در زنجیره حمله محسوب می‌شود. با توجه به نمره CVSS 9.8 (بحرانی)، ماهیت شبکه‌ای و عدم نیاز به احراز هویت، مهاجم می‌تواند از راه دور و بدون نیاز به هرگونه تعامل با کاربر، با دسترسی root وارد سیستم شود.

پیش‌نیازهای بهره‌برداری (Prerequisites)

دسترسی شبکه مهاجم به پورت 23 (یا پورت سفارشی) سرویس telnetd روی سرور هدف
• استفاده از نسخه آسیب‌پذیر telnetd (نسخه‌های 2.7 و پایین‌تر)
• عدم اعمال پچ امنیتی (ارتقا به نسخه 2.8 یا بالاتر) روی سیستم هدف
• نبود محدودیت دسترسی مبتنی بر IP (عدم تنظیم IP‌وایت‌لیست)

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

بررسیحدمجازبافر (Bounds Checking)

تابع add_slc بدون هیچ بررسی، هر SLC triplet را در آدرس جاری اشاره‌گر slcptr می‌نویسد و سپس اشاره‌گر را ۳ بایت افزایش می‌دهد. اما رفتار امن مورد انتظار به این صورت است که قبل از هر بار نوشتن در بافر، باید بررسی شود که آیا فضای کافی وجود دارد یا خیر. به عبارت دیگر

استفادهازتوابعمحدودشده (Bounded Functions)

به جای مدیریت دستی اشاره‌گرها، باید از توابع استاندارد و امنی استفاده شود که به طور خودکار بررسی حد مجاز را انجام می‌دهند. برای مثال به ترتیب برای توابع ناامن sprintf، strcpy و memcpy از توابع جایگزین امن snprintf، strncpy یا strlcpy و memcpy با بررسی قبلی فضای کافی بررسی شود.

مدیریتصحیحSLC TripletهاینامعتبربراساسRFC 1184

طبق RFC شماره 1184 یا Telnet Linemode Option لیست سه تایی ها (همان SLC Triplet) در SLC suboption برای اعلام پشتیبانی یا عدم پشتیبانی از توابع مختلف است، نه برای ذخیره سازی موقت پاسخ های متعدد. در رفتار ناامن GNU Inetutils به ازای هر تابع ناشناخته، یک پاسخ 3 بایتی در بافر ذخیره می کند این کار باعث می شود با ارسال تعداد زیادی تابع ناشناخته بافر به سرعت پر شود. در صورتی که به جای ذخیره همه پاسخ ها در بافر، سرور باید پاسخ های مربوط به توابع پشتیبانی نشده را نادیده بگیرد یا آن ها را به صورت جداگانه در بافر ارسال کند.

اعتبارسنجیورودی (Input Validation)

پیش از پردازش هر داده دریافتی از کلاینت، باید اعتبارسنجی‌های زیر انجام شود:

حداکثر تعداد SLC triplet های قابل قبول را محدود کنید (مثلاً ۳۰ triplet) یا در صورت تجاوز از حد مجاز، اتصال را قطع کنید.

اگر کد تابع خارج از محدوده پشتیبانی شده است، آن triplet را نادیده بگیرید یا یک پاسخ محدود ارسال کنید.

غیرفعالکردنLINEMODE

اگر ویژگی LINEMODE ضروری نیست، آن را به طور کامل از سرویس حذف کنید. بسیاری از حملات مدرن از طریق همین ویژگی انجام می‌شوند.

استفادهازSSHبهجایTelnet

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

اقدامات فوری برای کاهش ریسک:

به‌روزرسانی فوری GNU Inetutils به نسخه 2.8 یا بالاتر (که این آسیب‌پذیری در آن پچ شده است)
• در صورت عدم امکان به‌روزرسانی فوری، متوقف و غیرفعال کردن سرویس telnetd. در اکثر سیستم‌ها دستور sudo systemctl disable –now telnetd یا sudo service telnetd stop کافی است
محدود کردن دسترسی شبکه به پورت 23 تنها به آدرس‌های IP معتبر (شبکه مدیریت) با استفاده از فایروال
• قطع دسترسی اینترنت به سرویس Telnet در صورت عدم نیاز به مدیریت خارج از شبکه داخلی

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک:

دسترسیبهاینپورتراصرفاًبهچندIPمعتبروقابلاعتمادمحدودکنید.
مهاجرت کامل از Telnet به SSH و حذف تدریجی این سرویس از محیط عملیاتی
اجرای telnetd در محیط‌های chroot یا کانتینر با کمترین امتیازات ممکن
محدود کردن دسترسی به سرویس telnetd به تنها آدرس‌های IP داخلی معتبر با استفاده از xinetd و ACL
فعال‌سازی لاگینگ دقیق تمام اتصالات به پورت ۲۳ و ذخیره متمرکز آن‌ها
اسکن دوره‌ای شبکه داخلی برای شناسایی سیستم‌هایی که هنوز telnetd روشن دارند

اقدامات بلندمدت برای کاهش ریسک:

مهاجرتبهSSH: اینمهم‌ترینراهکاراست. استفادهازTelnetبهدلیلوجودآسیب‌پذیری‌هاییازایندست،کاملاًمنسوخشدهاست. سرویسsshdجایگزینامنواستانداردیاست
• استقرار راهکارهای خودکار به‌روزرسانی امنیتی (Patch Management) برای اعمال سریع وصله‌های امنیتی
• پیاده‌سازی فرآیندهای منظم تست نفوذ (Penetration Testing) و ارزیابی امنیتی برای کشف زودهنگام آسیب‌پذیری‌های مشابه در زیرساخت
• تدوین و اجرای سیاست‌های هاردنینگ برای تمام مؤلفه‌های مدیریتی بر اساس راهنمای امنیتی رسمی
• استفاده از ابزارهای تحلیل کد ایستا (SAST) در چرخه CI/CD برای شناسایی الگوهای حذف تصادفی میان‌افزارهای امنیتی

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوءاستفاده:

مانیتورینگپورت ۲۳ برایدریافتبسته‌هایحاویدنباله‌هایطولانیازگزینه‌هایTelnet (SLC)کهحاویکدهایتابعبالاتراز ۱۸(NSLC) هستند.
بررسیلاگ‌های /var/log/auth.logیاmessagesبرایرفتارهایغیرعادیدرسرویسtelnetd.
• افزایش ناگهانی ترافیک خروجی شبکه از سمت سرور به سمت آدرس‌های IP ناشناس (که حاکی از هدایت ترافیک به سرور مهاجم است)
• ورودهای موفق غیرعادی به سیستم از آدرس‌های IP غیرمعمول

منابع پیشنهادی برای مانیتورینگ و پایش:

لاگ‌های سیستمی (syslog) و دیمن (daemon.log) با تمرکز بر خروجی inetd/xinetd و telnetd
مانیتورینگبسته‌هایشبکهرویپورت ۲۳ بااستفادهازtcpdumpوابزارهایIDS/IPS
• بروزرسانی امضاهای سیستم‌های تشخیص نفوذ (IDS) برای شناسایی الگوی حمله (اندازه بافر بیش از حد معمول).
• سیستم‌های SIEM برای جمع‌آوری و تحلیل مرکزی لاگ‌های سرویس Telnet
راهکارهای NDR (Network Detection and Response) برای شناسایی ترافیک مشکوک به سمت پورت 23
• استفاده از ابزارهای امنیتی مانند Wazuh یا OSSEC برای مانیتورینگ تغییرات در باینری telnetd و پرتال‌های امنیتی.
پایشفرآیندهایسیستمیبرایشناساییفرآیندهایفرزندtelnetdکهفرمان‌هایغیرمنتظرهاجرامی‌کنند

واکنش به حادثه (Incident Response)

ایزوله‌سازی فوری سیستم آسیب‌دیده از شبکه جهت جلوگیری از حرکت جانبی مهاجم و ادامه نفوذ
• جمع‌آوری و حفظ لاگ‌های /var/log/auth.log و ترافیک شبکه مرتبط برای فارنزیک
• بازبینی فایل‌های پیکربندی Nginx برای شناسایی تغییرات مخرب (مانند پراکسی معکوس به سرور مهاجم) و حذف آن‌ها
• به دلیل دسترسی root، احتمال دارد مهاجم بکدور یا Rootkit نصب کرده باشد. صرفاً تغییر رمز عبور کافی نیست.
• اعمال پچ امنیتی (ارتقا به نسخه 2.8 یا بالاتر)
اسکن کامل شبکه برای شناسایی سایر سیستم‌هایی که ممکن است مهاجم به آن‌ها دسترسی یافته باشد
• مستندسازی کامل حادثه (زمان وقوع، نشانه‌ها، اقدامات انجام‌شده، درس‌آموخته‌ها) و گزارش به مدیریت ارشد و تیم واکنش سریع (CSIRT)

جریان حمله (Attack Flow)

در نمودار زیر (شکل ۱)، جریان کلی بهره‌برداری از این آسیب‌پذیری نشان داده شده است. در این سناریو، مهاجم یک اتصال ساده به پورت 23 برقرار می کند و پیش از هرگونه احراز هویت مهاجم اعلام می کند که می خواهد از قابلیت LINEMODE استفاده کند، سیستم برای آماده سازی بافر یک ثابت ۱۰۸ بایتی (slcbuf) برای مدیریت این ویژگی در حافظه BSS آماده می‌کند. اشاره‌گر slcptr به ابتدای این بافر اشاره دارد. مهاجم یک فرمان SLC معادل بیش از ۱۰4 بایت می‌فرستد و تابع add_slc بدون هیچ بررسی، محتویات فرمان SLC را در آدرس جاری slcptr می‌نویسد و سپس slcptr را جلو می‌برد. این کار تا آخرین 104 بایت ادامه می‌یابد. پس از پر شدن فضای ۱۰۴ بایتی، داده‌های اضافی شروع به نوشتن در حافظه‌ی مجاور می‌کنند. مهاجم به گونه‌ای payload خود را طراحی کرده که مقدار slcptr (که اکنون در حافظه مجاور قرار دارد) و آدرس بازگشت تابع را بازنویسی کند. وقتی تابع end_slc فراخوانی می‌شود، از slcptr آلوده شده استفاده می‌کند و در نهایت جریان اجرای برنامه به سمت شل کد (Shellcode) مهاجم که در همان payload قرار دارد، هدایت می‌شود و شل کد با سطح دسترسی root اجرا می‌شود و یک شل تعاملی به مهاجم برمی‌گرداند.

شکل 1: جریان اجرای آسیب پذیری

اثبات مفهوم (PoC) — کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte، این آسیب‌پذیری را در محیط ایزوله و کنترل‌شده با استفاده از نسخه آسیب‌پذیر بررسی و اجرا کرده است
• یک سیستم لینوکسی با سرویس آسیب‌پذیر(پیش از اعمال پچ) telnetd در محیط مجازی راه‌اندازی شده است
سرویس telnetd با فایل کانفیگ مشابه شکل 2 اجرا شده است (بخش server_args مربوط به تنظیمات LINEMODE SLC است)
این اثبات مفهوم صرفاً توصیفی و آموزشی بوده و شامل تغییرات مخرب نمی‌شود
• شکل 3 در Phase 2 کلاینت درخواست تنظیم کاراکترهای محلی (SLC) را ارسال می‌کند. در Phase 3 دستور SLC ارسال مشود، بافر ۱۰۴ بایتی با مقدار 186 بایت پر شده و داده‌ها شروع به نوشتن در حافظه مجاور می‌کنند. این امر باعث بازنویسی اشاره‌گر slcptr و سایر متغیرهای حیاتی می‌شود که در نهایت باعث کرش سرویس telnetd میشود

شکل 2: فایل گانفیگ سرویس

شکل 3: اجرای POC

رفع مسئولیت

این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوب‌های قانونی از محتوای آن ممنوع است.

منابع

https://www.cve.org/CVERecord?id=CVE-2026-32746

https://nvd.nist.gov/vuln/detail/CVE-2026-32746

https://cwe.mitre.org/data/definitions/120.html

https://github.com/jeffaf/cve-2026-32746

https://labs.watchtowr.com/a-32-year-old-bug-walks-into-a-telnet-server-gnu-inetutils-telnetd-cve-2026-32746/

https://lists.gnu.org/archive/html/bug-inetutils/2026-03/msg00031.html

https://thehackernews.com/2026/03/critical-telnetd-flaw-cve-2026-32746.html

GNU Inetutils telnetd

CVE-2026-32746 – Pre-Authentication Buffer Overflow Leading to Remote Code Execution

Affects

GNU Inetutils telnetd
Versions:
- All versions up to 2.7 (including all previous versions)
Components:
- Telnet daemon (telnetd)
- LINEMODE SLC (Set Local Characters) handler
Files:
- telnetd/slc.c
Functions:
- add_slc()
- end_slc()

Description

CVE-2026-32746 is a critical pre-authentication buffer overflow vulnerability in GNU Inetutils telnetd.

The telnet daemon uses a fixed-size buffer (slcbuf) of 108 bytes to handle LINEMODE SLC commands. Of these, only 104 bytes are available for actual data.

The issue arises because:

The add_slc() function does not perform any bounds checking
The slcptr pointer is incremented without verifying buffer capacity
A malicious client can send more than 35 SLC triplets (approximately 105+ bytes)

This results in buffer overflow in the BSS segment, allowing attackers to:

Overwrite adjacent memory (including the slcptr pointer itself),
Control the return address of the end_slc() function,
Execute arbitrary code with root privileges.

Attack Vector

Primary Attack Vector:
Remote / Unauthenticated (TCP Port 23 Exposure)

Attack Scenario:

An attacker discovers a system running telnetd on port 23 (publicly accessible or internal).
The attacker establishes a TCP connection to port 23.
Before any login prompt appears (pre-authentication phase), the attacker sends:
- IAC WILL LINEMODE (0xFF 0xFB 0x22)
- A crafted IAC SB LINEMODE SLC command containing 40–60 fake SLC triplets
Due to lack of bounds checking, the buffer overflows and corrupts memory.
The attacker’s shellcode executes with root privileges.

Key Characteristics:

No authentication required (pre-auth).
No user interaction required.
Exploitable over the network via TCP.
Relies on unsafe memory handling (no bounds checking).

Conditions Increasing Risk:

Public exposure of Telnet service (port 23).
Default configuration unchanged.
Lack of firewall or network segmentation.
Use of legacy systems (IoT, OT/ICS, older Linux distributions).

Impact

Successful exploitation allows:

Full remote code execution with root privileges,
Complete system compromise,
Backdoor installation for persistence,
Lateral movement to internal networks,
Data theft or ransomware deployment.

This represents a complete system takeover risk.

Observed Exploitation & Threat Activity

No confirmed widespread exploitation at disclosure (March 2026).
High likelihood of rapid exploitation due to:
- trivial exploitation (public PoC available),
- pre-auth access (no credentials needed),
- root-level impact.

Severity & Metrics

CVSS v3.1: Critical (9.8)
Attack Vector: Network
Privileges Required: None
User Interaction: None

Relevant CWE:

CWE-121 – Stack-based Buffer Overflow (or CWE-122 Heap-based, though BSS is similar to data segment overflow)
CWE-787 – Out-of-bounds Write
CWE-119 – Improper Restriction of Operations within Memory Bounds

Patch & Vendor Status

No official patch available at time of publication (expected April 1, 2026).

Mitigation & Remediation

Immediate Actions

Disable telnetd service immediately:
sudo systemctl disable --now telnetd or sudo service telnetd stop
Block port 23 via firewall:
sudo ufw deny 23 or sudo iptables -A INPUT -p tcp --dport 23 -j DROP
If telnet is absolutely required, restrict access to trusted IP addresses only.

Defensive Measures

Migrate from Telnet to SSH – This is the most important long-term solution.
Run telnetd with least privilege (non-root) if possible.
Place Telnet behind a VPN or jump host.
Monitor for unexpected core dumps from telnetd process.

Detection & Hunting

Indicators:

Unexpected crash or core dump of telnetd process.
Requests to port 23 containing long sequences of Telnet options (SLC commands with function codes above 18 / NSLC).
Unusual child processes spawned from telnetd.
Unexpected Nginx restarts or config changes (if Nginx is present on the same host).

Log analysis:

Check /var/log/auth.log or /var/log/messages for telnetd errors.

Post-Incident Response

If exploitation is suspected:

Isolate affected system from the network immediately.
Preserve forensic evidence (core dumps, logs, network captures).
Rotate all credentials and keys stored on the compromised system.
Audit system for backdoors (check crontabs, SSH keys, systemd services).
Assume full compromise – do not simply change passwords.
Rebuild system from a trusted backup or clean installation.

References

Security Affairs – Critical Telnetd vulnerability
NVD – CVE-2026-32746
GitHub – jeffaf/cve-2026-32746
CWE-121 – Stack-based Buffer Overflow
CWE-787 – Out-of-bounds Write

CVE-2026-32746

Pre-Authentication Buffer Overflow Leading to Remote Code Execution