# Ruby ve GitLab Güvenlik Açıkları: CI/CD Riskleri URL: https://intellego.com.tr/blog/ruby-gitlab-guvenlik-aciklari-cicd-riskleri Yayın tarihi: 2026-10-24 Güncelleme: 2026-10-24 Yazan: Intellego Softworks > Ruby, 23 Ekim 2026'da GitLab'ın tespit ettiği dört güvenlik açığının temelindeki hataları düzelten sürümler yayımladı. Açıklar, dışarıdan alınan düzenli ifadelerin işlenmesi sırasında bazı GitLab sunucularında kod çalıştırılmasına yol açabiliyordu. Ruby ve GitLab güncellemelerinin hangi sistemlerde gerekli olduğunu ve geliştirme altyapısını korumak için nelere dikkat edilmesi gerektiğini ele alıyoruz. 23 Ekim 2026'da Ruby geliştiricileri, GitLab'ın tespit ettiği dört güvenlik açığıyla bağlantılı hataları düzelten yeni sürümler yayımladı. Ruby 4.0.9, 3.4.12 ve 3.3.13 sürümleri, Ruby'nin düzenli ifadeleri işleyen Onigmo bileşenindeki sorunları gideriyor. GitLab, bu hataların belirli koşullarda sunucuda izinsiz kod çalıştırmak için kullanılabildiğini açıkladı. GitLab söz konusu açıkları daha önce, 23 Eylül, 12 Ekim ve 21 Ekim 2026 tarihlerinde yayımladığı güvenlik güncellemeleriyle kapatmıştı. Ruby'nin 23 Ekim duyurusu ise bu sorunların yalnızca GitLab ile sınırlı olmadığını, kullanıcıdan aldığı metni düzenli ifade olarak işleyen diğer Ruby uygulamalarında da incelenmesi gerektiğini gösteriyor. [Ruby'nin 23 Ekim 2026 tarihli resmî açıklaması](https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/) ## Güvenlik Açıkları Nasıl Ortaya Çıktı? Düzenli ifadeler, metinlerde belirli kalıpları bulmak veya doğrulamak için kullanılır. Yazılım geliştirirken sık karşılaşılan bu yöntem, GitLab'de CI/CD yapılandırmalarında da kullanılıyor. GitLab, kullanıcıların tanımladığı bazı kalıpları Ruby'nin `Regexp.new` özelliğiyle işliyor. Araştırmacıların bulduğu sorun, bu kalıpların işlenişi sırasında ortaya çıkıyor. Özel hazırlanmış girdiler, Ruby'nin belleği hatalı yönetmesine neden olabiliyor. GitLab, bu bellek hatalarından yararlanılarak sunucuda kod çalıştırılabilecek saldırı senaryoları tespit etti. GitLab dört güvenlik kaydı yayımladı. **CVE-2026-89078** ve **CVE-2026-93577**, belirli koşullarda sisteme giriş yapmış bir kullanıcı tarafından istismar edilebiliyordu. **CVE-2026-97229** ve **CVE-2026-110264** içinse yine belirli koşullarda giriş yapılmadan saldırı mümkün olabiliyordu. GitLab'ın CVSS 3.1 değerlendirmesinde ilk iki açık 9,9; diğer ikisi 10,0 puan aldı. Bu numaralar GitLab'ın yayımladığı güvenlik kayıtlarına ait. Ruby ekibi, aynı hatalar için kendi adına ayrı CVE numaraları istemediğini belirtti. ## Hangi Ruby ve GitLab Sistemleri Etkileniyor? Her Ruby uygulaması bu açıklardan etkilenmiyor. Ruby'nin açıklamasına göre hata, dışarıdan gelen bir metnin düzenli ifade olarak derlenmesi sırasında tetiklenebiliyor. Yalnızca geliştiricinin önceden yazdığı sabit düzenli ifadeleri kullanan uygulamalar bu sorunlardan etkilenmiyor. Ruby'nin `Regexp.timeout` ayarı da söz konusu açıkları kapatmıyor. Bu ayar, düzenli ifadelerin çalışması sırasında harcanan zamanı sınırlamak için kullanılıyor. Oysa burada sorun, ifadenin hazırlanması sırasında ortaya çıkabiliyor. Girdinin uzunluğunu sınırlamak da tek başına güvenilir bir önlem değil. GitLab kullanan şirketlerde dikkat edilmesi gereken nokta ise **GitLab sunucusunun kendi sürümü**. Şirket içinde kurulu bir GitLab sistemi kullanıyorsanız yalnızca uygulamalarınızın Ruby sürümünü yükseltmeniz, GitLab sunucusundaki açıkları kapatmaz. GitLab'ın ilgili güvenlik güncellemesini de yüklemeniz gerekiyor. GitLab, kendi yönettiği GitLab.com ve GitLab Dedicated altyapılarında düzeltmelerin uygulandığını açıkladı. Şirketlerin kendilerinin yönettiği GitLab kurulumlarında ise güncelleme sorumluluğu ilgili ekibe ait. ## Güvenlik Açıkları Nasıl Kapatılır? Ruby kullanan uygulamalar için **4.0.9, 3.4.12 veya 3.3.13** sürümlerine ya da aynı düzeltmeleri içeren daha yeni bir sürüme geçilmesi öneriliyor. Ruby 4.0 serisindeki bazı düzeltmeler önceki küçük sürümlere eklenmiş olsa da dört GitLab kaydıyla ilgili düzeltmelerin tamamı 4.0.9'da bulunuyor. GitLab tarafında ise kullanılan sürüm dalına uygun güvenlik güncellemesi gerekli. GitLab'ın 21 Ekim 2026 duyurusunda, **19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ve 18.11.13** sürümleri ilgili son düzeltmeyi içeriyor. Destek dışı veya daha eski kurulumlarda güncel ve desteklenen bir GitLab sürümüne geçiş planlanmalı. En doğrusu, kullanılan dalın mevcut en son güvenlik güncellemesini tercih etmek. GitLab'ın kendi paketinde bulunan Ruby bileşenini elle değiştirmek yerine GitLab'ın yayımladığı güncellemelerin kullanılması daha uygun. Güncelleme öncesinde yedek alınması ve geçişin test edilmesi de olası kesintileri azaltır. [GitLab'ın 21 Ekim 2026 güvenlik güncellemesi](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) ## Bir GitLab Açığı Şirket İçin Ne Anlama Gelir? GitLab yalnızca kodların saklandığı bir yer olmayabilir. Birçok şirkette testleri çalıştırır, yazılım paketlerini hazırlar ve yeni sürümlerin sunuculara aktarılmasını yönetir. Bu işlemler için kaynak kodlara, sunucu bağlantılarına veya erişim anahtarlarına ihtiyaç duyabilir. GitLab sunucusunda kod çalıştırabilen bir saldırganın neye erişebileceği, sistemde tanımlanan yetkilere bağlıdır. Gereğinden geniş izinler, bir güvenlik açığının etkisini büyütebilir. Bu nedenle GitLab sunucusunun güncel olması kadar erişimlerin sınırlandırılması ve gizli bilgilerin uygun biçimde saklanması da önemlidir. Açıklar için güncelleme yayımlanması, bir sistemin kesin olarak ele geçirildiği anlamına gelmez. Ancak etkilenen sürümü kullanan şirketlerin güncelleme yapması ve şüpheli etkinlik olup olmadığını kayıtlarından kontrol etmesi gerekir. GitLab, ilgili açıklar için bazı saldırı girişimlerini tespit etmeye yardımcı olabilecek işaretler de yayımladı. ## Yazılım Geliştirme Altyapısı Nasıl Korunabilir? Güvenlik duyurularını takip etmek, hangi sistemin hangi sürümde çalıştığı bilinmiyorsa tek başına yeterli olmuyor. Öncelikle şirketin kullandığı GitLab sunucuları, Ruby uygulamaları ve bunların temel yazılım bileşenleri belirlenmeli. Yeni bir açık duyurulduğunda bu liste üzerinden hangi sistemlerin incelenmesi gerektiği anlaşılabilir. Ruby uygulamalarında kullanıcıdan gelen metinlerle düzenli ifade oluşturulan noktalar da kontrol edilmeli. Mümkünse kullanıcı girdilerinden doğrudan düzenli ifade oluşturulmamalı. Böyle bir özellik gerçekten gerekiyorsa risk, kullanılan uygulama ve güncel Ruby sürümü birlikte değerlendirilerek ele alınmalı. CI/CD süreçlerinde erişim yetkileri de düzenli olarak gözden geçirilmeli. Bir test işleminin üretim sunucusuna erişmesine gerek yoksa o yetki verilmemeli. Sürümler önce test ortamında denenmeli; günlük kayıtları, olağan dışı hatalar ve beklenmeyen işlemler izlenmeli. Güncelleme kadar, bir sorunun erken fark edilmesi de güvenliğin parçasıdır. ## Intellego Yazılım Geliştirme Altyapınızı Nasıl Destekleyebilir? Intellego Softworks olarak şirketlere özel yazılım geliştiriyor, mevcut uygulamaların bakımını yapıyor ve [DevOps altyapıları](https://intellego.com.tr/hizmetlerimiz/devops-hizmetleri) kuruyoruz. CI/CD süreçlerinin tasarlanması, otomatik testler, güvenli dağıtım ve sistemlerin izlenmesi bu çalışmaların içinde yer alıyor. Kullandığınız yazılımları ve bağımlılıklarını değerlendirerek yeni güvenlik duyurularının hangi sistemleri ilgilendirdiğini belirlemenize yardımcı olabiliriz. Güncellemelerin planlanması, test edilmesi ve kontrollü biçimde uygulanması için de mevcut geliştirme süreçlerinize uygun bir çalışma düzeni oluşturabiliriz. GitLab sunucunuzun, Ruby uygulamalarınızın veya yazılım geliştirme süreçlerinizin gözden geçirilmesini istiyorsanız [Intellego Softworks ile iletişime geçebilirsiniz](https://intellego.com.tr/iletisim). ## Sorular ve cevaplar ### GitLab güncellendiyse Ruby'yi de güncellemek gerekiyor mu? GitLab'ın kendi dağıtımında kullandığı Ruby için GitLab'ın güvenlik güncellemeleri esas alınmalı. Aynı şirkette ayrı çalışan Ruby uygulamaları varsa onların sürümleri ayrıca kontrol edilmeli. GitLab güncellemesi, diğer uygulamalardaki Ruby kurulumlarını güncellemez. ### Ruby'deki `Regexp.timeout` ayarı bu açıkları önlüyor mu? Hayır. Ruby geliştiricileri, bu hataların düzenli ifade hazırlanırken tetiklenebildiğini ve `Regexp.timeout` ayarının koruma sağlamadığını açıkça belirtiyor. ### Bütün GitLab kullanıcılarının sunucuları risk altında mı? Hayır. Risk, kullanılan GitLab sürümüne ve açıkların istismar koşullarına bağlı. GitLab.com ve GitLab Dedicated için gerekli düzeltmeler uygulanmış durumda. Kendi GitLab sunucusunu yöneten şirketlerin ise sürümlerini kontrol etmesi gerekiyor. ## Kaynaklar - [Ruby - Regexp Compilation Fixes Related to GitLab CVEs (23 October 2026)](https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/) - [GitLab - Critical Patch Release 19.4.1 (23 September 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-1-released/) - [GitLab - Critical Patch Release 19.4.2 (12 October 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/) - [GitLab - Critical Patch Release 19.5.1 and Backports (21 October 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) - [Intellego Softworks - DevOps Hizmetleri](https://intellego.com.tr/hizmetlerimiz/devops-hizmetleri)