آیا این سایبر جدید طبیعی است؟

هفته گذشته شاهد انبوهی از آسیب‌پذیری‌های نرم‌افزاری شدید و حیاتی بودیم که هزاران سایت اصلی را تحت تأثیر قرار داد و مردم را به وحشت انداخت. اینجا چه خبر است و چه کاری می توانیم در مورد آن انجام دهیم؟

اگر می‌خواهیم بفهمیم در حال حاضر در دنیای امنیت نرم‌افزار چه می‌گذرد، باید بفهمیم که با همه این باگ‌ها چه می‌گذرد. من یک متخصص امنیت سایبری نیستم، بنابراین به جای اینکه خودم وارد جزئیات فنی شوم، به توضیحات خارجی لینک می دهم، زیرا این افراد همیشه در این زمینه کار بهتری انجام می دهند.

دو تیم امنیتی مختلف، یکی از شرکت امنیتی کالیفرنیا Calif (به عنوان بخشی از برنامه OpenAI "Patch the Planet") و دیگری از اسرائیل-ایالات متحده. شرکت امنیت ابری Wiz (ظاهرا بخشی از Google Cloud هستند)، هر دو این دو باگ Remote Code Execution (RCE) را در PHP پیدا کردند. آنها هر دو از مدل‌های هوش مصنوعی مرزی (با نام مستعار LLM، به‌ویژه GPT-5.6 Sol/Gemini 4 Argon) برای یافتن این آسیب‌پذیری‌ها و ساختن اکسپلویت‌ها استفاده می‌کردند.

جالب اینجاست که یکی از باگ‌ها (CVE-2026-109618) توسط یک ممیزی امنیتی که بنیاد PHP در سال 2024 انجام داد (با بودجه آژانس Sovereign Tech که اتفاقا یکی از جالب‌ترین اتفاقاتی است که در حال حاضر در فضای منبع باز رخ می‌دهد) پیدا شد، اما آنها اساسا آن را نادیده گرفتند زیرا نگرانی‌های بزرگ‌تری در مورد آن داشتند. دلیل پشت آن این بود که هیچ کس واقعا نمی‌توانست بفهمد چگونه می‌توان یک اکسپلویت واقعی را بر اساس موضوع تئوریک ایجاد کرد.

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

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

تخمین زده می‌شود که این PHP2Shell (همان‌طور که در حال بازاریابی است، آسیب‌پذیری‌ها با بخش‌های بازاریابی خودشان همراه هستند) با هزاران وب‌سایت از بنیاد Wikimedia گرفته تا DeviantArt تا بسیاری از دولت بریتانیا و سیستم‌های بانکی ژاپن تا وب‌سایت برنامه The Traitors BBC. آسیب‌پذیری‌ها پیدا می‌شوند، اما معمولا باعث نمی‌شوند نیمی از اینترنت سرورهایشان را خاموش کنند، پس چه اتفاقی می‌افتد؟

برای درک این موضوع، اجازه دهید به پست اصلی گروه PHP نگاه کنیم:

شخصی به نام petecooper در هکر نیوز در مورد CVE ها پست کرده است، ظاهرا غافل از اینکه حتی یک تحریم وجود دارد. این (و سایر اطلاعات آشکار) باعث این بیانیه شتابزده از طرف گروه PHP و ارائه پچ از پنجشنبه 22 تا چهارشنبه 21 شد. با این حال، پچ هنوز تا روز بعد در دسترس قرار نگرفت. این نشت ناخواسته شامل امتیاز CVSS 10.0 بود (یعنی بد، اگرچه به طور عجیبی امتیازات واقعی 9.2 بود).

تقریبا بلافاصله، این خبر مانند آتش منتشر شد و مردم وحشت کردند. اگرچه این مورد توسط «محققان امنیتی مسئول» در «شرکت‌های معتبر» یافت شد، اما در زمان انتشار وصله امنیتی، در حال حاضر در طبیعت مورد سوء استفاده قرار می‌گرفت. بنیاد پی‌اچ‌پی کالیف و شرکتی به نام Chainguard را مقصر دانست و گفت که کالیف ویدیویی از این سوء استفاده در عمل (با موسیقی پس‌زمینه عجیب و یک دختر انیمه در حال رقص) را درز کرد، در حالی که Chainguard 6 ساعت قبل از لغو تحریم، اصلاحاتی را منتشر کرد که هر دو به مهاجمان اجازه می‌داد تا مدیران سیستم را مورد ضرب و شتم قرار دهند.

مشت جدول زمانی گیج کننده است، اما به نظر می رسد که چندین چیز به هم پیوسته در اینجا اشتباه پیش رفته اند، همه در عرض حدود 17 ساعت.

بحث های زیادی در مورد اینکه آیا هوش مصنوعی واقعا تغییر دهنده بازی است که امنیت رایانه را کاملا متحول می کند یا خیر، وجود دارد. شرکت های بزرگ هوش مصنوعی (و آنها بزرگ هستند) بدیهی است که می خواهند شما فکر کنید که چنین است. برخی از افراد استدلال می‌کنند که PHP2Shell بیش از حد پر شده است، زیرا LLM‌ها تمایل دارند در مورد آسیب‌پذیری‌ها پارانویا باشند و «سوءاستفاده‌هایی» را ارائه کنند که مفروضات بدی ایجاد می‌کنند (مثل اینکه سرور کد PHP را که خودتان از طریق برخی آسیب‌پذیری‌های گنجاندن فایل موجود آپلود می‌کنید اجرا می‌کند) یا به نوعی تقلب می‌کنند.

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

برخی دیگر اشاره می کنند که بسیاری از دولت ها (بریتانیا 2، اتحادیه اروپا، ژاپن، ایالات متحده آمریکا) بیش از حد هیجان زده شدند و اعلامیه های فوری منتشر کردند که می گفتند همه باید فورا کامپیوترهای خود را از برق بکشند، بنابراین مردم وحشت کردند. فکر می‌کنم دلیل وحشت همه این است که همه می‌دانند PHP به شدت ناامن است و به هر حال از آن استفاده می‌کنند، بنابراین به نوعی آماده اخبار بد و واکنش بیش از حد هستند. همچنین، واقعا بسیار بد است، بنابراین شاید وحشت یک نوع واکنش صحیح باشد؟

نکته مهم برای من از این موضوع این است که - به دلیل LLM ها - زمان از "هی، شنیدم RCE بدی در این پروژه وجود دارد" تا "حملات پیچیده، خودکار و هماهنگ با استفاده از یک سوء استفاده که این آسیب پذیری را هدف قرار می دهد وجود دارد" از هفته ها/ماه ها به ساعت ها/دقیقه ها رسیده است. این واقعیت که انبوهی از اکسپلویت غیر کاری وجود دارد، نشان می‌دهد که هنوز چقدر برای ساختن این چیزها به تخصص واقعی نیاز است – اگر ندانید به چه چیزی نگاه می‌کنید، نمی‌توانید تشخیص دهید که آیا هوش مصنوعی تقلب کرده یا مفروضات بدی کرده است.

دقیقا در همان روز (20 اکتبر 2026)، موزیلا اعلام کرد که 8 گواهینامه میانی امضا شده توسط مرجع گواهی هند eMudhra را مسدود می کند. این اتفاق پس از آن رخ داد که یک محقق امنیتی با نام مستعار که فقط به نام "وین" شناخته می شود، به چندین شرکت بزرگ فناوری (مانند موزیلا، اپل، گوگل، مایکروسافت و غیره) گزارش داد که مرجع گواهی از کلیدهای خصوصی با کیفیت بسیار ضعیف برای گواهینامه های میانی خود استفاده می کنند. در جایی که یک کلید امن ممکن است یک عدد 100 رقمی باشد، eMudhra از کلیدهایی مانند "115"، "56" و "4" استفاده می کرد. آنها باید RFC 1149.5 را دنبال کرده باشند:

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

در زمان نگارش این مقاله (23 اکتبر)، eMudhra اعلام کرده است که از فضای مرجع گواهی بازنشسته خواهد شد. در خبری غیرمرتبط، یک کشاورز اعلام کرده است که درب اصطبل خود را بسته است، در پی گزارش هایی مبنی بر فرار یک اسب.

روز بعد، Railway ارائه‌دهنده ابر اعلام کرد که شواهدی پیدا کرده‌اند که نشان می‌دهد هکرها به متغیرهای محیطی از پلتفرم خود دسترسی پیدا کرده‌اند و حتی آن‌ها را رمزگشایی کرده‌اند، که اغلب اسرار اطلاعاتی مانند اعتبار پایگاه داده، کلیدهای API و غیره را در خود دارند.

در 12 اکتبر 2026، GitLab در مورد یک اشکال با حداکثر شدت در تجزیه عبارات منظم GitLab CI/CD هشدار داد که می تواند مهاجمان را قادر به اجرای کد دلخواه (RCE دیگر) با استفاده از یک regex ساخته شده ویژه کند. این یک امتیاز CVSS 10.0 است که حداکثر ممکن است، به این معنی که "این تقریبا به همان اندازه بد است" 3 . این در 21 اکتبر 2026 توسط یک سرریز عدد صحیح regex دیگر RCE، 10.0 دیگر دنبال شد.

این به دنبال نسخه دیگری از 10.0 CVSS CVE از ماه گذشته (CVE-2026-85706) است که مربوط به پیمایش مسیر بود. هر سه این باگ ها از طریق برنامه جایزه باگ HackerOne GitLab گزارش شده اند. وقتی مشخص شد که LLM ها می توانند آسیب پذیری ها را بررسی کنند و اکسپلویت ها را بنویسند، صحبت های زیادی در مورد خاموش کردن برنامه های باگ بونتی به وجود آمد زیرا دیگر منطقی نبودند. من مطمئن هستم که GitLab خوشحال است که اکنون این کار را انجام نداده است.

اگرچه GitLab به طور گسترده در سراسر دانشگاه، دولت و شرکت‌های خصوصی استفاده می‌شود، به نظر نمی‌رسد که این موضوع چندان مورد توجه قرار گرفته باشد. بدیهی است که CVE ها در GitLab بسیار جدی هستند، به ویژه برای شرکت های خصوصی، زیرا بسیاری از دارایی های معنوی مهم آنها در آنجا ذخیره می شود، و داشتن این نشت می تواند فاجعه آمیز باشد. اغلب، شرکت‌ها نمونه GitLab خود را در پشت یک VPN/firewall قرار می‌دهند تا در دسترس عموم قرار نگیرند، که خطر مرتبط با آن را تا حد زیادی کاهش می‌دهد.

همچنین کاملا مشخص نیست که آیا این CVE‌ها به شرایط خاصی مانند پروژه‌های در دسترس عموم، ثبت نام کاربر و غیره نیاز دارند یا خیر.

هیچ نشانه ای وجود ندارد که اینها با استفاده از AI یا LLM کشف شده اند. آنها ممکن است بوده باشند، اما در این مرحله دلیلی وجود ندارد که فکر کنیم آنها بودند.

در 21 اکتبر، یک اشکال در libc musl مربوط به regex (libc regex دارد؟ ظاهرا...) اعلام شد که حداقل منجر به انکار سرویس، اگر نه اجرای کد، می شود. تا آنجا که من می توانم بگویم، این از نظر زمان بندی کاملا تصادفی است و به اشکالات GitLab مربوط نمی شود، که به نظر می رسد هر دوی آنها هنگام تجزیه عبارات منظم غیرقابل اعتماد، سرریز اعداد صحیح هستند، یکی دقیقا در همان روز گزارش شده است.

چه کسی می دانست که موتور regex چنین مشکل امنیتی است - آیا regex رندر فونت جدید است؟ اشکالات GitLab هر دو توسط یک سوئدی به نام Johan Carlsson (joaxcar) پیدا شدند، در حالی که اشکال musl توسط Julien Voisin، یک فرانسوی خودخوانده "منبع باز" گزارش شد.

آه، سلام دوست قدیمی من LiteLLM. ثابت می کند که وقتی شما از فلز ساخته شده اید و قد 200 فوتی دارید، صاعقه در واقع می تواند دو بار برخورد کند. این نشانه خوبی نیست که وقتی کسی از شما می پرسد که آیا در مورد سازش بزرگ LiteLLM 2026 شنیده اید، باید بپرسید "کدام؟" از اقبال خوب، کل PHP2Shell و سایر PHP2Shell توجه زیادی را به خود جلب کرده‌اند، به این معنی که با وجود بد بودن مشابه، کشش مشابه دفعه قبل در ماه مارس را ندارد.

این بار، این یک نسخه مخرب در نمایه بسته Python (PyPI) و تصاویر Docker است. برای کسانی که به خاطر ندارند، LiteLLM اتفاق بسیار مشابهی در ماه مارس رخ داد، جایی که یک بسته مخرب در بسته litellm در PyPI آپلود شد که از فایل‌های pth برای بارگیری خودکار کدهای مخرب استفاده می‌کرد (آره، بد بود).

این سازش مجددا از فایل‌های .pth و این بار نیز از فایل sitecutomize.py برای بارگیری خودکار بارهای مخرب استفاده کرد که به محض راه‌اندازی مفسر پایتون در مرحله پیش‌بارگذاری اجرا می‌شود. بر اساس تجزیه و تحلیل Wiz، محموله دارای «نشانه‌های قوی توسعه با کمک LLM» است – مواردی مانند نام‌های متغییر بیش از حد پرمخاطب، مدیریت خطاهای دفاعی بیش از حد، موارد لبه‌های شکننده، و همه نظراتی که می‌گویند «این جایی است که واقعا گاز می‌گیرد»، «ارزش نشستن با آن را دارد»، «به آن تکیه کنید»، و «به‌طور مکرر به آن تکیه کنید»، و «به‌طور مکرر به آن می‌ماند».

به گفته LiteLLM، این حادثه به این دلیل رخ داد که مهاجم به اعتبارنامه های GitHub CLI دسترسی داشت که به آنها اجازه می داد کارهای CI را اجرا کنند. LiteLLM توجه داشته باشد که Claude Code ظاهرا گاهی اوقات توکن GitHub CLI OAuth کاربر را در بدنه‌های پاسخ جاسازی می‌کند که می‌تواند باعث شود آنها در لاگ‌های LiteLLM ظاهر شوند.

در 19 اکتبر 2026، یک شرکت نرم افزاری سازمانی به نام "PingCAP" که پایگاه داده ای به نام "TiDB" را توسعه می دهد، "دسترسی غیرمجاز به PingCAP" را بدون "هیچ مدرکی مبنی بر اینکه داده های ذخیره شده در TiDB تحت تاثیر قرار گرفته است" فاش کرد. در همان زمان، یک گروه اخاذی سایبری به نام «FulcrumSec» (معروف به «Threatspians» 5) گفت که 10.6 ترابایت داده را از PingCAP استخراج کرده و تورنتی با 200 گیگابایت داده را به‌عنوان «نسخه مرحله اول» (شما باید روی مردم سرمایه‌گذاری کنید) به صورت عمومی منتشر کرده‌اند.

آن‌ها همچنین جزئیات کامل آنچه را که گرفته‌اند و برخی از اقدامات امنیتی عالی PingCAP، از جمله قرار دادن کلیدهای دسترسی مخفی AWS مشتری در بلیط‌های Jira و پیوست کردن لاگ‌های بزرگ ویرایش نشده به بلیط‌های Jira از جمله کلیدهای OpenAI، Anthropic، Gemini، xAI API را منتشر کردند. بله اگر مایل به بازدید از وب سایت گروه اخاذی سایبری هستید، آنها نوشتن بسیار جالبی از آن انجام می دهند. آن زمان که روس‌ها مجبور بودند این چیزها را بدون LLM بنویسند تا برایشان انجام دهند و مقالات معین و نامشخص را به آنها یادآوری کنند، گذشته است. 6

خبر خوب برای PingCAP این است که پیدا نکردن شواهدی از استخراج داده ها در واقع فوق العاده آسان است. در واقع، من در حال حاضر این کار را برای هزاران شرکت به صورت رایگان انجام می دهم. من مطمئن هستم که یک پیشنهاد تجاری در جایی وجود دارد. تنها کاری که باید انجام دهید این است که نگاه نکنید (همچنین نگاه کنید به: U+1F648). اگر منصف باشیم، فکر می کنم استدلال آنها این است که هیچ داده ای در داخل نمونه های TiDB به خطر نیفتاده است. اگر اینطور باشد، 10.6 ترابایت به نظر داده های زیادی است. واضح است که هنوز هزاران داده مشتری وجود دارد.

توسعه هسته لینوکس همه از طریق لیست های پستی اتفاق می افتد. به طور طبیعی، برخی از آنها در مورد موارد حساس امنیتی هستند، بنابراین خصوصی هستند. در شب 21 تا 22 اکتبر 2026، Zero Day Initiative (ZDI)، یک ابتکار آسیب‌پذیری نرم‌افزار متعلق به Trend Micro، یک دسته از CVE‌های با شدت بالا (بیش از 9.0 CVSS) را به‌جای فهرست خصوصی به فهرست پست‌های عمومی گزارش کرد. به طور طبیعی، فرض بر این است که هر کسی با یک LLM و قلبی پر از رویا می‌تواند آن گزارش‌ها را بگیرد و در عرض چند دقیقه آنها را به بهره‌برداری‌های فعال تبدیل کند.

این به اندازه آن زمان بد نیست که پیت هگزث بطور تصادفی جزئیات حملات نظامی آتی در یمن را به آتلانتیک 7 پیامک کرد، اما هنوز هم جالب است که مردم اکنون چقدر این موضوع را جدی می گیرند.

من فکر می کنم منصفانه است که بگویم این چند روز اخیر از نظر همه این حوادث سایبری و افشای امنیتی به طور غیرعادی فعال بوده است. نظرات بسیاری در بحث های Hacker News برای این حوادث وجود دارد که می گویند این چیزی نیست و فقط بدتر خواهد شد. راستش من هنوز تصمیم نگرفتم راستش را بخواهید، اگر 4 سال پیش از من می پرسیدید که LLM تا کجا پیش می رود، هرگز حدس نمی زدم که آنها به خوبی الان شوند.

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

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

چرا این کار را نمی کند؟

می توانید ببینید که چرا سازمان هایی مانند NHS انگلستان تصمیم گرفتند همه کد منبع باز خود را خصوصی نگه دارند (حتی اگر این تصمیم احمقانه بود). وقتی این LLM ها آنقدر خوب هستند که هر کسی می تواند عامل خود را به سمت کدهای منبع باز هدایت کند و آسیب پذیری های زیادی را پیدا کند، سپس برای آنها اکسپلویت های کامل بنویسد که برای بسیاری نگران کننده است. پس راه حل اینجا چیست؟

رویکرد NHS: همه چیز را منبع نزدیک کنید. (با نام مستعار رویکرد ماداگاسکار)

رویکرد AI-Embracer: اگر نمی توانید آنها را شکست دهید، به آنها بپیوندید. به عبارت دیگر، اگر ما LLM های بهتر خود را سریعتر و با پول بیشتر و مدل های بهتر اجرا کرده باشیم، نمی توانند از LLM برای یافتن آسیب پذیری ها استفاده کنند.

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

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

AWS از آن زمان گفته است که از 17 اکتبر، قبل از وقوع هر یک از این آسیب‌پذیری، فردی را دیده‌اند که این آسیب‌پذیری را امتحان کرده است.

حتی چیزی مانند حداقل سن انتشار که پس از حوادث Shalk/Debug، Shai-Hulud و March LiteLLM محبوبیت پیدا کرد، زیرا به این معنی است که به‌روزرسانی‌های بزرگی که آسیب‌پذیری‌های به‌طور گسترده مورد سوءاستفاده قرار گرفته‌اند، برای چند روز اصلاح نمی‌شوند و به مهاجمان فرصت کافی برای هک کردن شما می‌دهند. حداقل، شاید بتوانیم مدیریت کلاینت بهتری را انجام دهیم تا از وحشت همه و آفلاین کردن سرورهایشان جلوگیری کنیم.

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

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

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

در حالی که من پیش‌بینی‌های زیادی در مورد آینده انجام نمی‌دهم (چون نمی‌خواهم در ۱۲ ماه آینده مانند یک احمق به نظر بیایم که به ناچار اشتباه می‌کنم)، می‌گویم که صنعت نرم‌افزار تغییر خواهد کرد و منبع باز تغییر خواهد کرد، و این مسئولیت جمعی ما به عنوان اعضای جامعه نرم‌افزاری است که مطمئن شویم این تغییر به نفع همه ما و شرکت‌های خصوصی نیست.

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

در مورد اینکه آیا قبل از انتشار پچ، تلاش‌های واقعی برای بهره‌برداری از این موضوع انجام شده است یا خیر، بحث و اختلاف نظر وجود دارد. ↩

سلب مسئولیت: من به نوعی برای دولت بریتانیا کار می کنم. ↩

GitLab از CVSS 3.1 استفاده می کند در حالی که PHP از CVSS 4.0 در اینجا استفاده می کند، به این معنی که آنها معیارهای کمی متفاوت را برای محاسبه امتیاز CVSS دنبال می کنند، به این معنی که شما نمی توانید مستقیما آنها را با هم مقایسه کنید. ↩

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

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