TexnoX-in baxışı (Deep Insight)
Önəmli Detallar
- Gemini CLI ilə bağlı əsas boşluq @google/gemini-cli 0.39.1-dən əvvəlki versiyalara, 0.40.0-preview.3-dən əvvəlki preview buraxılışlarına və google-github-actions/run-gemini-cli 0.1.22-dən əvvəlki versiyalara təsir edib
- Gemini CLI zəifliyi CVSS 10.0 ilə qiymətləndirilib və xüsusən etibarsız girişlərlə işləyən CI iş axınlarında risk yaradıb
- Cursor-da CVE-2026-26268 kimi izlənən və CVSS 8.1 alan boşluq 2.5-dən əvvəlki versiyalarda Git hook-ları vasitəsilə sandbox-dan kənar kod icrasına şərait yarada bilər
Ətraflı Məqalə
Google-un son təhlükəsizlik yeniləməsi Gemini CLI-də kritik səviyyəli bir boşluğu bağlayır. Problem əsasən CI və headless mühitlərdə workspace etibar modelinin yanlış tətbiqindən qaynaqlanırdı və nəticədə host üzərində əmrlərin icrasına qədər uzanan ssenarilər yarada bilirdi. Boşluğun CVSS 10.0 ilə qiymətləndirilməsi riskin nəzəri deyil, birbaşa əməliyyat mühitlərinə toxunduğunu göstərir. Xüsusilə avtomatlaşdırılmış iş axınlarında etibarsız məzmun işləyən komandalar üçün bu, dərhal yenilənmə tələb edən məsələdir.
Məsələnin mahiyyəti ondadır ki, Gemini CLI əvvəlki davranışında bəzi workspace qovluqlarını avtomatik etibarlı sayırdı. Bu yanaşma lokal .gemini konfiqurasiyasına və mühit dəyişənlərinə arzuolunmaz çıxış imkanı yarada, agentin icra etdiyi alətlər vasitəsilə hücum zəncirini dərinləşdirə bilirdi. Google-un düzəlişi qovluqların açıq şəkildə trusted kimi işarələnməsini tələb edir. Şirkət eyni zamanda –yolo rejimində tool allowlisting məntiqini də sərtləşdirib.
Hadisə yalnız bir məhsul yeniləməsi kimi yox, AI əsaslı inkişaf alətlərinin təhlükəsizlik arxitekturası ilə bağlı daha geniş siqnal kimi oxunur. Eyni vaxtda Cursor-da üzə çıxan boşluqlar göstərir ki, prompt injection, Git sazlamaları və hook mexanizmləri birləşəndə IDE daxilində başlayan təsir real kod icrasına çevrilə bilir. Cursor-un 2.5-dən əvvəlki versiyalarında təsvir olunan ssenari Git hook-ları üzərindən sandbox sərhədinin aşılmasına imkan verə bilərdi. Bu isə agent əsaslı məhsuldarlıq alətlərinin yalnız model davranışı ilə deyil, ətraf icra qatları ilə də qiymətləndirilməli olduğunu önə çıxarır.
Bazar baxımından mesaj aydındır: enterprise komandalar AI köməkçilərini CI CD, Git və IDE zəncirinə inteqrasiya etdikcə trust boundary, icazə siyasətləri və hook nəzarəti əsas infrastruktur mövzusuna çevrilir. Bu cür boşluqlar vendor seçimini təkcə funksionallıq deyil, təhlükəsiz orkestrasiya qabiliyyəti üzərindən də formalaşdıra bilər. Xüsusən multi-tool mühitlərində bir alətin zəif etibar modeli bütün iş axınının risk profilini yüksəldir. Nəticədə müəssisələr üçün əsas sual hansı modelin daha güclü olması deyil, hansı agentin daha sərt nəzarət çərçivəsində işləməsidir.
