آسیب‌پذیری GitLab با امتیاز 10؛ باگ بحرانی CVE-2026-110264 و راه رفع آن

دیروز، ۲۹ مهر ۱۴۰۵ (۲۱ اکتبر ۲۰۲۶) ، گیت‌لب (GitLab) یک وصلهٔ امنیتی فوری منتشر کرد برای یک آسیب‌پذیری GitLab که امتیازش بالاتر از این نمی‌شود: 10 از 10. شناسهٔ این باگ CVE-2026-110264 است و طبق اطلاعیهٔ رسمی، «تحت شرایط خاص» به یک کاربر بدون لاگین اجازه می‌دهد روی سرور GitLab کد دلخواه اجرا کند. بدتر اینکه همهٔ نسخه‌ها از GitLab 7.0 (سال ۲۰۱۴) به بعد آسیب‌پذیرند؛ یعنی حدود ۱۲ سال.

خیلی از شرکت‌ها و تیم‌های برنامه‌نویسی ایرانی، به‌خاطر تحریم‌ها و محدودیت‌های دسترسی، به‌جای GitLab.com یا گیت‌هاب، یک GitLab شخصی (Self-Managed) روی سرور خودشان راه انداخته‌اند. اگر شما هم یکی از آن‌ها هستید، این آسیب‌پذیری GitLab مستقیماً به شما مربوط است. اینجا به زبان ساده توضیح می‌دهم این باگ چیست، چه کسانی در خطرند و از همه مهم‌تر، چطور قدم‌به‌قدم سرورتان را امن کنید.

آسیب‌پذیری GitLab با شناسهٔ CVE-2026-110264 چیست؟

عنوان رسمی این باگ «سرریز عدد صحیح (Integer Overflow) در کامپایلر عبارت‌های باقاعده» است. عبارت باقاعده یا رجکس (Regular Expression) همان الگوهای جست‌وجوی متنی است که هر برنامه‌نویسی با آن سروکار دارد؛ مثل ^\d{4}-\d{2}$. قبل از اینکه یک رجکس اجرا شود، موتور رجکس آن را به یک ساختار داخلی «کامپایل» می‌کند.

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

GitLab در اطلاعیه نام کتابخانه را نیاورده، اما در فهرست تغییرات همین نسخه‌ها وصله‌ای با عنوان «Ruby regexp repeat ID overflow» برای روبی 3.3، 3.4 و 4.0 آمده است. یکی از دو قانون تشخیصی که خود GitLab منتشر کرده هم اسم Onigmo را دارد، یعنی موتور رجکس داخل زبان روبی (Ruby) . GitLab با Ruby on Rails نوشته شده، پس منطقی است که باگ در لایهٔ زبان باشد، نه در کد خود GitLab. جزئیات کامل فنی طبق روال GitLab حدود ۹۰ روز بعد، یعنی حدود دی ۱۴۰۵، منتشر می‌شود.

چرا امتیازش 10 از 10 است؟

امتیاز CVSS این باگ 10.0 است با بردار AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. اگر بخواهم این رشتهٔ عجیب را به زبان آدمیزاد ترجمه کنم:

• از راه اینترنت قابل حمله است (AV:N) و پیچیدگی حمله کم است (AC:L) .
• هیچ حساب کاربری لازم ندارد (PR:N) و هیچ کاری از قربانی لازم نیست (UI:N) ؛ نه کلیک، نه باز کردن لینک.
• اثرش از خود برنامه بیرون می‌زند (S:C) و محرمانگی، سلامت داده و دسترس‌پذیری هر سه در بالاترین سطح آسیب می‌بینند.

به گزارش منابع امنیتی، کد مهاجم با کاربر سیستمی git اجرا می‌شود. این کاربر به همهٔ مخزن‌ها (Repository) ، تنظیمات اتصال پایگاه داده و بخشی از اسرار (Secrets) دسترسی دارد. حالا فکر کنید روی یک GitLab شرکتی چه چیزهایی پیدا می‌شود: کل سورس‌کد محصولات، توکن‌های CI/CD، کلیدهای سرور تولید و رمزهایی که کسی اشتباهی کامیت کرده. برای همین است که نفوذ به یک سرور گیت معمولاً شروع یک حملهٔ بزرگ‌تر به کل زیرساخت است.

طبق همین گزارش‌ها، برای حمله فقط کافی است روی سرور یک پروژهٔ عمومی (Public) وجود داشته باشد که GitLab محتوایش را نمایش دهد. چیزی که خیلی‌ها دارند.

چه کسی باگ را پیدا کرد و آیا الان مورد حمله است؟

این باگ را پژوهشگری با نام کاربری joaxcar از طریق برنامهٔ باگ‌بانتی GitLab در HackerOne گزارش کرده است. یعنی قبل از اینکه دست مهاجم‌ها بیفتد، به خود GitLab رسیده و وصله شده.

تا امروز، ۳۰ مهر، این خبرهای خوب را داریم:

• اطلاعیهٔ GitLab از سوءاستفادهٔ فعال حرفی نزده است.
• باگ هنوز در فهرست آسیب‌پذیری‌های در حال سوءاستفادهٔ آژانس امنیت سایبری آمریکا (CISA KEV) نیست.
• هیچ اکسپلویت عمومی (Proof of Concept) منتشر نشده است.

ولی این خبرهای خوب تاریخ انقضا دارند. معمولاً چند روز بعد از انتشار وصله، مهاجم‌ها نسخهٔ قدیم و جدید را مقایسه می‌کنند (Patch Diffing) و خودشان راه حمله را پیدا می‌کنند. پس «هنوز کسی حمله نکرده» دلیل صبر کردن نیست؛ دلیل عجله کردن است.

یک نکتهٔ مهم دیگر: ۹ روز پیش، ۱۲ اکتبر، GitLab یک باگ 10 از 10 دیگر هم وصله کرده بود (CVE-2026-97229، باز هم سرریز عدد صحیح در رجکس، این بار در بخش CI/CD). اگر آن موقع به 19.4.2، 19.3.5 یا 19.2.8 آپدیت کرده‌اید و خیالتان راحت شده، باید بدانید آن نسخه‌ها در برابر باگ جدید آسیب‌پذیرند و باید دوباره آپدیت کنید.

چه کسانی در خطرند؟

• GitLab.com: امن است. GitLab خودش سرورها را آپدیت کرده و شما کاری لازم نیست بکنید.
• GitLab Dedicated: نسخه‌های 19.3.5-internal0 و 19.4.2-internal0 و بعد از آن وصله را دارند.
• GitLab شخصی (Self-Managed)، چه Community Edition (رایگان) و چه Enterprise Edition، با هر روش نصبی (Omnibus، Docker، Helm یا سورس) : اگر نسخه‌تان پایین‌تر از جدول زیر است، در خطرید.

چطور آسیب‌پذیری GitLab را رفع کنیم؟ قدم‌به‌قدم

برای این آسیب‌پذیری GitLab صریحاً گفته هیچ راه‌حل موقتی (Workaround) وجود ندارد و تنها راه کامل، آپدیت است.

قدم ۱: نسخهٔ GitLab را پیدا کنید

از رابط وب، منوی Help (علامت سؤال) یا صفحهٔ /help را باز کنید. از خط فرمان سرور هم این‌طور:

sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"
# or
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

قدم ۲: نسخهٔ امن شاخهٔ خودتان را ببینید

قدم ۳: از پشتیبان شروع کنید، بعد آپدیت

قبل از هر آپدیت، از داده‌ها و فایل‌های اسرار پشتیبان بگیرید. فایل gitlab-secrets.json را فراموش نکنید؛ بدون آن، پشتیبان شما نصفه است:

sudo gitlab-backup create
sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb ~/gitlab-config-backup/

حالا روی دبیان و اوبونتو (اگر با apt آشنا نیستید، قسمت سوم مجموعهٔ دبیان را ببینید):

sudo apt update
sudo apt install gitlab-ce   # or gitlab-ee
sudo gitlab-ctl status

روی RHEL، AlmaLinux و Rocky Linux:

sudo dnf install gitlab-ce   # or gitlab-ee

اگر GitLab را با Docker اجرا می‌کنید، ایمیج را با تگ نسخهٔ جدید (مثلاً gitlab/gitlab-ce:19.5.1-ce.0) pull و کانتینر را دوباره بسازید. با Helm هم نسخهٔ چارت را بالا ببرید.

قدم ۴: اگر نسخه‌تان خیلی قدیمی است، مسیر ارتقا را رعایت کنید

اگر هنوز روی GitLab 16 یا 17 یا حتی قدیمی‌تر هستید، نمی‌توانید یک‌جا به 19.5.1 بپرید. GitLab «ایستگاه‌های اجباری» (Upgrade Stops) دارد و هر بار باید به نسخهٔ بعدی برسید و بگذارید مهاجرت‌های پایگاه داده تمام شود. مسیر دقیق را با ابزار رسمی مسیر ارتقا پیدا کنید. این کار ممکن است چند ساعت طول بکشد، پس اگر الان وقتش را ندارید، حداقل قدم ۵ را همین امروز انجام دهید.

قدم ۵: تا وقتی آپدیت نکرده‌اید، در را ببندید

این‌ها جای آپدیت را نمی‌گیرند، فقط ریسک را کم می‌کنند:

• دسترسی شبکه را محدود کنید: اگر GitLab شما فقط برای تیم خودتان است، اصلاً نباید از کل اینترنت در دسترس باشد. پشت VPN یا فایروال با فهرست IPهای مجاز ببریدش.
• سطح دسترسی «عمومی» را ببندید: از مسیر Admin → Settings → General → Visibility and access controls سطح Public را محدود کنید. این مسیر بدون لاگین را تنگ‌تر می‌کند، ولی ممکن است دسترسی ناشناس به پروژه‌های عمومی‌تان قطع شود.

قدم ۶: نشانه‌های حمله را بررسی کنید

GitLab دو قانون تشخیص منتشر کرده: «کرش ورکر بومی Onigmo» و «انفجار خطای رندر Org Mode» . فایل‌های این قوانین روی gitlab.com است که از داخل ایران معمولاً باز نمی‌شود، ولی طبق گزارش منابع امنیتی، خلاصه‌اش این است که در لاگ‌ها دنبال کرش ناگهانی ورکرهای Puma و خطاهای پشت‌سرهم در رندر فایل‌های .org بگردید:

sudo grep -n "\[BUG\]" /var/log/gitlab/puma/puma_stderr.log
sudo grep -c "OtherMarkup" /var/log/gitlab/gitlab-rails/exceptions_json.log

دو نکته را جدی بگیرید: اگر چیزی پیدا شد، یعنی باید بررسی کنید، نه اینکه حتماً هک شده‌اید. و اگر چیزی پیدا نشد هم خیالتان کاملاً راحت نباشد، چون خود GitLab گفته یک حملهٔ موفق ممکن است هیچ کرش یا لاگی به جا نگذارد. اگر سرورتان مدت‌ها آسیب‌پذیر و رو به اینترنت بوده، عوض کردن توکن‌های CI/CD و رمزهای حساس، احتیاط معقولی است.

باگ‌های دیگری که در همین آپدیت رفع شد

این وصله در مجموع ۱۲ آسیب‌پذیری را رفع می‌کند. دو تای مهم دیگر:

• CVE-2026-15723 (امتیاز 8.2) : اگر ورود با SAML و پیوند خودکار LDAP هر دو فعال باشند، یک کاربر لاگین‌کرده می‌توانست حساب یک کاربر LDAP دیگر را تصاحب کند.
• CVE-2026-112212 (امتیاز 7.5) : مسموم کردن کش (Cache Poisoning) سند OAuth/OIDC، که می‌توانست جریان ورود را به سرور مهاجم بفرستد.

بقیه متوسط و کم‌خطرند، اما چون همه با همین آپدیت رفع می‌شوند، دلیل دیگری برای عقب انداختنش نمی‌ماند. فهرست کامل در اطلاعیهٔ رسمی GitLab آمده است.

جمع‌بندی

یک آسیب‌پذیری GitLab دوازده‌ساله با امتیاز کامل 10، بدون نیاز به لاگین، در ابزاری که سورس‌کد کل یک شرکت در آن است. همین یک جمله کافی است که این آپدیت را برای امروز بگذارید، نه هفتهٔ بعد. خلاصهٔ کار: نسخه را ببینید، پشتیبان بگیرید، به نسخهٔ امن شاخهٔ خودتان آپدیت کنید و GitLab را از اینترنت عمومی دور نگه دارید.

من خودم پروژه‌هایم را منبع‌باز روی گیت‌هاب نگه می‌دارم؛ مثل جدول امتیاز شلم و لوگوی تیم‌های فوتبال ایران. ولی می‌دانم خیلی از تیم‌های ایرانی برای کار روزانه به GitLab شخصی تکیه کرده‌اند، همان‌طور که در لینک‌های مفید آرما هم برای روزهای محدودیت اینترنت آینه‌های داخلی ابزارهای برنامه‌نویسی را جمع کرده‌ام. اگر GitLab شرکتتان را نمی‌شناسید، این نوشته را برای مدیر سرور یا تیم DevOps بفرستید؛ و اگر سؤالی دربارهٔ آپدیت دارید، در بخش نظرات بپرسید.