انتشار curl 8.23.0 برای رفع آسیب‌پذیری HTTP/2 که با کمک Claude کشف شد

نسخه ۸.۲۳.۰ ابزار curl که در ۱۴ اکتبر ۲۰۲۶ منتشر شد، آسیب‌پذیری CVE-2026-92392 را برطرف می‌کند؛ نقصی از نوع استفاده پس از آزادسازی حافظه (Use-after-free) در فرایند بارگذاری فایل از طریق HTTP/2 که پروژه curl شدت آن را «بالا» ارزیابی کرده است. لونا تانگ از شرکت Anthropic این آسیب‌پذیری را با کمک هوش مصنوعی Claude کشف کرد. این نقص نسخه‌های curl و کتابخانه libcurl از ۸.۱۲.۰ تا ۸.۲۲.۰ را تحت تأثیر قرار می‌دهد.

curl ابزاری برای خط فرمان است که به همراه کتابخانه libcurl امکان انتقال داده از طریق نشانی‌های وب را فراهم می‌کند. توسعه‌دهندگان هر روز از آن برای بارگیری و بارگذاری فایل‌ها استفاده می‌کنند، اما همین کد در مرورگرها، اپلیکیشن‌های موبایل، روترها، خودروها و خطوط پردازش و یکپارچه‌سازی مداوم نرم‌افزار نیز اجرا می‌شود؛ اغلب بدون آنکه کاربران این محصولات از وجود curl در آن‌ها خبر داشته باشند. دنیل استنبرگ سال‌هاست هدایت و نگهداری این پروژه را بر عهده دارد. Anthropic، شرکت مستقر در کالیفرنیا و سازنده Claude، در ۸ اکتبر سرویس OSS Scanner را راه‌اندازی کرد؛ سرویسی که در آن مدل‌های هوش مصنوعی این شرکت پروژه‌های متن‌باز را بررسی می‌کنند.

نسخه curl 8.23.0 چه مشکلی را برطرف می‌کند؟

این نقص به نحوه مدیریت فریم RST_STREAM در curl مربوط می‌شود. سرور HTTP/2 با ارسال این پیام می‌تواند یک جریان ارتباطی را متوقف کند. آسیب‌پذیری زمانی بروز می‌کند که سرور هنگام بارگذاری فایل، این فریم را با یکی از دو دلیل HTTP_1_1_REQUIRED یا REFUSED_STREAM ارسال کند. پس از بازنشانی جریان، curl همچنان به ساختاری داخلی اشاره می‌کند که در این فاصله حذف شده است. این ساختار با نام struct Curl_easy شناخته می‌شود و نماینده یک عملیات انتقال داده است. طبق هشدار امنیتی رسمی پروژه، این نقص نمونه‌ای از خطاهای شناخته‌شده و کلاسیک در برنامه‌نویسی با زبان C است.

این نسخه فقط به رفع همین آسیب‌پذیری محدود نمی‌شود و در مجموع ۲۴ اصلاح امنیتی را در بر دارد: یک مورد با شدت بالا و ۲۳ مورد با شدت پایین. به گزارش The Hacker News، این نخستین آسیب‌پذیری با شدت بالا در curl از زمان کشف سرریز بافر در پراکسی SOCKS5 در اکتبر ۲۰۲۳ است. دنیل استنبرگ در نوشته خود توضیح می‌دهد که فاصله انتشار نسخه‌ها از هشت هفته به شش هفته کاهش یافت تا وصله تهیه‌شده به دست استفان آیسینگ هرچه سریع‌تر منتشر شود.

آیا آسیب‌پذیری curl واقعاً امکان اجرای کد از راه دور را فراهم می‌کند؟

از نظر تئوری، بله؛ اما در عمل، احتمال آن پایین است. پژوهشگر توانسته است اجرای کد را روی رایانه‌ای که فایل را بارگذاری می‌کند نشان دهد، ولی این کار به فراهم بودن مجموعه‌ای بسیار دقیق از شرایط نیاز دارد. توسعه‌دهندگان curl نیز معتقدند محتمل‌ترین پیامد یک حمله واقعی، صرفاً از کار افتادن برنامه است.

برای عملی شدن این سناریو باید چند شرط هم‌زمان برقرار باشد:

• سرور HTTP/2 تحت کنترل مهاجم باشد و گواهی آن نیز بررسی‌های امنیتی سمت کاربر را با موفقیت پشت سر بگذارد؛
• فایلی با حجم تقریبی ۱۳۵ کیلوبایت بارگذاری شود و دو انتقال موازی به‌صورت هماهنگ انجام گیرند؛ این جزئیات در بازسازی فنی Red Hot Cyber آمده است؛
• دستور مورد اجرا فقط ۲۳ بایت طول داشته باشد؛
• مهاجم از نسخه curl، معماری سیستم، تخصیص‌دهنده حافظه libc، رفتار کتابخانه nghttp2 که curl برای HTTP/2 به کار می‌برد و پروتکل TLS 1.3 شناخت دقیقی داشته باشد.

پروژه curl برای آسیب‌پذیری‌های خود امتیاز CVSS، یعنی مقیاس عددی صفر تا ۱۰ مورد استفاده در پایگاه‌های اطلاعاتی خارجی، منتشر نمی‌کند و به‌جای آن از چهار سطح کیفی استفاده می‌کند. به همین دلیل، باید تیترهایی را که این نقص را «بحرانی» می‌خوانند با دقت بررسی کرد. در هشدار رسمی پروژه، شدت آسیب‌پذیری «بالا» اعلام شده است؛ تفاوتی که اهمیت دارد. هیچ‌یک از منابع گزارش نداده‌اند که حملاتی مبتنی بر این نقص هم‌اکنون در جریان باشد.

پس چرا این آسیب‌پذیری همچنان نگران‌کننده است؟ سازوکار آن با دیگر خطاهای همین نوع تفاوتی ندارد. وقتی curl حافظه مربوط به شیء انتقال را آزاد می‌کند، اما همچنان به آن اشاره می‌کند، مهاجم می‌تواند داده‌های دلخواه خود را در همان ناحیه حافظه قرار دهد. سپس برنامه این داده‌ها را به‌اشتباه به‌عنوان داده‌های متعلق به ساختار اصلی خود می‌خواند. در بدترین حالت، سرور می‌تواند بر کدی که اجرا می‌شود تأثیر بگذارد؛ اما در سناریوی محتمل‌تر، فرایند برنامه متوقف می‌شود. بنابراین، خطر برای سامانه‌هایی همچنان جدی است که از خودکارسازی برای بارگذاری داده از طریق HTTP/2 به سرورهای خارجی یا سرورهایی با تنظیمات پویا استفاده می‌کنند؛ از جمله سامانه‌های پشتیبان، ابزارهای بک‌اند و خطوط پردازش CI/CD. در این محیط‌ها، تکرار از کار افتادن برنامه نیز می‌تواند یک سرویس را از دسترس خارج کند.

زمان‌بندی واکنش تیم پروژه نیز نکته مهمی را روشن می‌کند. از زمان گزارش آسیب‌پذیری در ۱۵ سپتامبر تا انتشار نسخه جدید در ۱۴ اکتبر، ۲۹ روز گذشت. در این مدت، نقص محرمانه باقی ماند تا تیم بتواند وصله را آماده کند، آن را روی شاخه‌هایی که همچنان پشتیبانی می‌شوند بیازماید و ۲۳ اصلاح امنیتی دیگر را نیز آماده انتشار کند. برای پروژه‌ای که سال‌ها به برنامه زمانی منظمی برای انتشار نسخه‌های جدید پایبند بوده است، کوتاه کردن چرخه انتشار به میزان دو هفته تصمیمی نیست که برای یک اشکال جزئی گرفته شود.

چه کسانی باید به‌روزرسانی کنند و چگونه؟

نسخه‌های ۸.۱۲.۰ تا ۸.۲۲.۰، با احتساب هر دو نسخه ابتدا و انتهای این بازه، در curl و libcurl آسیب‌پذیرند؛ این موضوع هم ابزار خط فرمان و هم کتابخانه را شامل می‌شود. اصلاحات در نسخه ۸.۲۳.۰ ارائه شده‌اند. کاربرانی که به شاخه‌های قدیمی‌تر وابسته‌اند نیز می‌توانند از نسخه‌های اصلاح‌شده ۸.۲۰.۲، ۸.۱۶.۲ و ۸.۱۴.۳ استفاده کنند. نسخه‌های پیش از ۸.۱۲.۰ این آسیب‌پذیری را ندارند.

• نسخه نصب‌شده را با دستور curl --version بررسی کنید و به نسخه ۸.۲۳.۰ ارتقا دهید؛ در صورت لزوم می‌توانید نسخه محلی خود را نیز وصله کنید.
• اگر امکان به‌روزرسانی فوری وجود ندارد، با استفاده از گزینه --http1.1، ارتباط را به HTTP/1.1 محدود کنید. در libcurl نیز می‌توان از گزینه CURLOPT_HTTP_VERSION استفاده کرد. بدون HTTP/2، مسیر اجرای آسیب‌پذیر فعال نمی‌شود.
• کانتینرها، تصاویر مورد استفاده در CI/CD و بسته‌هایی را که libcurl را در خود جای داده‌اند، دوباره بسازید. به‌روزرسانی سیستم‌عامل به‌تنهایی کافی نیست، اگر کتابخانه درون خود برنامه تعبیه شده باشد.
• توزیع‌های لینوکس وصله‌های اختصاصی خود را جداگانه منتشر می‌کنند. ردیاب امنیتی دبیان نمونه‌ای از این روند برای شناسه CVE-2026-92392 است.

Claude چگونه این آسیب‌پذیری را کشف کرد؟

گزارش آسیب‌پذیری به نام لونا تانگ از شرکت Anthropic ثبت شده و تاریخ آن ۱۵ سپتامبر ۲۰۲۶ است. تیم curl ظرف چند ساعت صحت گزارش را تأیید کرد. در هشدار امنیتی رسمی، اعتبار کشف به این صورت ثبت شده است: «لونا، با Claude از Anthropic». استنبرگ نیز در نوشته خود توضیح می‌دهد که گزارش از طریق OSS Scanner، ابزار جدید شرکت تحت مدیریت داریو آمودی، به دست پروژه رسیده است. او اضافه می‌کند که احتمالاً مدل‌های هوش مصنوعی این شرکت نیز در فرایند کشف نقش داشته‌اند.

این جزئیات برای کسانی که امنیت نرم‌افزارهای متن‌باز را دنبال می‌کنند اهمیت دارد. OSS Scanner به درخواست نگه‌دارندگان پروژه‌ها کار می‌کند: آن‌ها یک درخواست ادغام تغییرات در GitHub ایجاد می‌کنند و فایل Dockerfile لازم را در اختیار سرویس می‌گذارند تا پروژه ساخته و بدون اتصال به اینترنت بررسی شود. این سرویس تازه‌ترین مرحله از مجموعه اقداماتی است که طی ماه‌های گذشته در این وبلاگ پوشش داده شده‌اند؛ از برنامه تأیید امنیت سایبری گرفته تا اقدام بانک آو آمریکا برای به‌کارگیری هزار نفر جهت رفع نقص‌های کشف‌شده توسط Mythos. وجه مشترک این تحولات آن است که آسیب‌پذیری‌ها سریع‌تر از توانایی تیم‌ها برای رفع آن‌ها کشف می‌شوند.

این اتفاق در خارج از Anthropic نیز نمونه‌های مشابهی دارد. شرکت Visa یک ابزار هوش مصنوعی را که ۱۰ هزار آسیب‌پذیری را شناسایی کرده بود، به‌صورت متن‌باز منتشر کرد. همچنین مدل متن‌باز GLM-5.3 در آزمون‌های NIST تعداد ۴٬۲۴۹ آسیب‌پذیری را پیدا کرد. بااین‌حال، نقص curl نمونه‌ای شاخص از این مسئله است: کدی به زبان C که به‌طور گسترده استفاده می‌شود و پروژه‌ای با سابقه طولانی در حوزه امنیت از آن نگهداری می‌کند. این اشکال در یازده نسخه، از ۸.۱۲.۰ تا ۸.۲۲.۰، باقی مانده بود تا اینکه یک مدل هوش مصنوعی آن را شناسایی کرد.

پایان پشتیبانی از SMB

بر اساس گزارشی از mind-verse به نقل از heise، نسخه ۸.۲۳.۰ پشتیبانی از پروتکل‌های SMB و SMBS را به‌طور کامل از کتابخانه و ابزار خط فرمان حذف می‌کند. در نتیجه، نشانی‌های smb:// و smbs:// دیگر کار نخواهند کرد. پروژه پیش‌تر در بهار استفاده از SMB و NTLM را به حالت اختیاری تغییر داده بود. تصمیم نهایی پس از سال‌ها مشکل گرفته شد؛ از جمله محدود بودن پشتیبانی به SMBv1، وابستگی به NTLM و سابقه وجود اشکالات امنیتی متعدد.

اگر اسکریپت‌ها یا خطوط پردازش شما از curl برای دسترسی به پوشه‌های اشتراکی شبکه استفاده می‌کنند، پیش از به‌روزرسانی باید کدها را برای یافتن این نشانی‌ها بررسی کنید و سپس به یک کلاینت سازگار با SMBv2 یا SMBv3 یا پروتکل دیگری مهاجرت کنید.

چرا curl به زبان برنامه‌نویسی امن از نظر حافظه منتقل نمی‌شود؟

استنبرگ می‌پذیرد که اگر این کد با زبانی امن از نظر مدیریت حافظه نوشته شده بود، احتمالاً چنین خطایی رخ نمی‌داد. بااین‌حال، او بار دیگر تأکید می‌کند که پروژه curl بازنویسی نخواهد شد؛ نه با زبان برنامه‌نویسی دیگری و نه حتی از نو با زبان C، زیرا گزینه‌های موجود هنوز قابلیت حمل‌پذیری گسترده curl را فراهم نمی‌کنند. راهکارهای مورد نظر پروژه عملی و تدریجی‌اند. قرار است تعداد اشاره‌گرهای داخلی به اشیا و دسته‌های مدیریتی کاهش یابد و به‌جای آن‌ها از شناسه‌های انتقال استفاده شود که هنگام نیاز، شیء مربوط به آن‌ها پیدا می‌شود. این روش کمی کندتر است، اما در برابر خطاهای منطقی استحکام بیشتری دارد. همچنین آزمایش‌های بیشتر و ابزارهای تحلیل اضافی در دستور کار قرار دارند. بااین‌همه، پروژه احتمال بروز آسیب‌پذیری‌های دیگری از نوع استفاده پس از آزادسازی حافظه را در آینده رد نمی‌کند.

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

پرسش‌های متداول

۱. اگر فقط از curl برای بارگیری فایل استفاده کنم، در معرض خطر هستم؟

این آسیب‌پذیری به بارگذاری فایل مربوط می‌شود. هشدار امنیتی، سناریویی را شرح می‌دهد که در آن سرور یک بارگذاری از طریق HTTP/2 را با بازنشانی جریان متوقف می‌کند. بنابراین، کاربرانی که فقط فایل دریافت می‌کنند، در سناریوی مستندشده قرار نمی‌گیرند. بااین‌حال، به‌روزرسانی همچنان اقدام درستی است، زیرا نسخه ۸.۲۳.۰ علاوه بر این نقص، ۲۳ آسیب‌پذیری دیگر با شدت پایین را نیز برطرف می‌کند.

۲. آیا حملاتی با استفاده از CVE-2026-92392 در جریان است؟

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

۳. سطح شدت «بالا» در مقیاس curl چه معنایی دارد؟

این سطح دومین درجه بالای شدت در مقیاس پروژه است. curl برای آسیب‌پذیری‌های خود امتیاز CVSS تعیین نمی‌کند و از چهار سطح پایین، متوسط، بالا و بحرانی استفاده می‌کند. CVE-2026-92392 در سطح بالا قرار دارد؛ یعنی نقصی جدی است، اما در بالاترین سطح شدت طبقه‌بندی نمی‌شود.

۴. چگونه بفهمم برنامه من از libcurl استفاده می‌کند؟

وابستگی‌های بسته نرم‌افزاری یا تصویر مورد استفاده را بررسی کنید. در لینوکس می‌توانید کتابخانه‌هایی را که برنامه بارگذاری می‌کند، برای مثال با دستور ldd، بررسی کنید و نسخه نصب‌شده libcurl را به دست آورید. در کانتینرها و برنامه‌های بسته‌بندی‌شده نیز باید نسخه جدید کتابخانه را وارد فرایند ساخت مجدد کنید.