DB-GPT'te kimlik doğrulaması gerektirmeyen iki path-traversal dosya yazma açığı; yalnızca biri 0.8.1'de giderildi

Ne oldu

dev.to üzerinde yayımlanan bir yazıya (aslen HOL tarafından yayımlandı) göre, kimlik doğrulaması gerektirmeyen iki ayrı path-traversal açığı DB-GPT'te keyfî dosya yazımına imkân veriyor. İlki, CVE-2026-80104 olarak takip edilen açıklık, skill upload API'sini hedefliyor. İkincisi, CVE-2026-73034, python dosya yükleme API'sini hedefliyor. Her ikisi de herhangi bir kimlik bilgisine sahip olmayan bir saldırganın dosyaları amaçlanan yükleme dizininin dışına yerleştirmesine olanak tanıyor. Kritik ayrıntı şu: En son PyPI sürümü olan 0.8.1'e yükseltme yalnızca ilk açığı kapatıyor. İkincisi ise etiketlenmiş hiçbir sürümde hâlâ giderilmiş değil.

Birinci hata: skill upload dosya adı geçişi

DB-GPT 0.8.0'da, agentic_data_api.py içindeki skill_upload işleyicisi, multipart dosyanın dosya adını hiçbir doğrulama yapmadan doğrudan pilot/tmp yoluna birleştiriyordu; bu yüzden ../ segmentleri içeren bir ad, dosyayı yükleme dizininin dışına yerleştirebiliyordu. Kimlik doğrulama burada bir engel oluşturmuyor: yazıya göre, dbgpt-serve'in auth yardımcı programındaki get_user_from_headers, user_id başlığı verilip verilmediğine bakılmaksızın role="admin" döndüren bir mock.

GitHub issue #3026 bu açığı takip ediyor. Düzeltme, mutlak yolları ve çok segmentli adları reddeden bir _validate_upload_filename yardımcı fonksiyonu ekleyen commit aecad1a9 (PR #3065, Mayıs 2026) olarak geldi. Bu yardımcı fonksiyon PyPI'daki etiketli v0.8.1 sürümünde mevcut. CVE-2026-80104, 2026-08-25 tarihinde atandı.

İkinci hata: python upload user_id geçişi

CVE-2026-73034 farklı çalışıyor. Python upload işleyicisi, yükleme dizinini temel dizin, bir python_uploads klasörü ve user_id HTTP başlığının değeri (FastAPI bunu user-id olarak eşliyor) birleştirerek oluşturuyor. Mevcut bir kapsama denetimi olan _resolve_upload_path, dosya adını yalnızca saldırganın etkileyebildiği bu dizine göre doğruladığından, user_id başlığına yerleştirilen geçiş dizileri dosyaları yükleme kökünden tamamen kaçırıyor. GitHub issue #3104, çalışma dizininin dışına kimlik doğrulaması gerektirmeyen bir yazım gerçekleştirildiğini doğruladı ve aynı mock kimlik doğrulaması burada da geçerli.

Hiçbir sürüm düzeltmeyi içermiyor. Yazıya göre, araştırma sırasında PyPI'da dbgpt ve dbgpt-app için hâlâ en yeni sürüm olan v0.8.1, _SAFE_USER_ID_RE ve _resolve_user_id doğrulamasını getiren commit e0c741bd olarak yalnızca main dalında bulunan yamayı içermiyor. Ne bir v0.8.2 GitHub etiketi ne de PyPI sürümü var. Yazar, sorunun "0.8.2'de giderildiğini" iddia eden ikincil raporların var olmayan bir sürümü tarif ettiği konusunda uyarıyor; operatörler e0c741bd içeren bir build'a ya da eşdeğer bir backport'a ihtiyaç duyuyor.

Kapsam ve risk azaltma

Skill upload rotalarını (/v1/agentic_data/skill/upload ve ilgili rotaları) ya da python upload rotasını (/api/v1/python/file/upload) dışa açmayan dağıtımlar, kod mevcut olsa bile bu yollar üzerinden erişilebilir değil. Yazı ayrıca hikâyenin sınırlarını da çiziyor: DB-GPT'teki eklenti kod çalıştırma, skill script çalıştırma ve skill.md içindeki Jinja SSTI gibi diğer sorunlar, ayrı düzeltmeleri olan ayrı hatalar.

Önerilen yol, CVE-2026-80104 için dbgpt-app'i 0.8.1'e yükseltmek, ardından kurulu ağacın gerçekten her iki yardımcı fonksiyonu içerdiğini doğrulamak. Kurulu pakete karşı yapılacak kısa bir Python kontrolü, _validate_upload_filename'in agentic_data_api.py içinde ve _SAFE_USER_ID_RE'in python_upload_api.py içinde var olup olmadığını gösteriyor. Standart PyPI 0.8.1'de ilki True, ikincisi False döndürüyor. CVE-2026-73034 için e0c741bd içeren bir checkout ya da image çalıştırın, user_id doğrulamasını cherry-pick edin veya backportlayın ya da python upload API'sini güvenilmeyen hiçbir ağ sınırında bulundurmayın ve önüne gerçek bir kimlik doğrulaması koyun — standart mock'un sağlamadığı şey tam olarak bu.

Neden önemli

Bir agent framework'ü barındıran sunucuda keyfî dosya yazımı, doğrudan bir ele geçirme ilkesidir (compromise primitive): dosyalar, uygulamanın daha sonra yüklediği veya çalıştırdığı kod ya da yapılandırma yollarına bırakılabilir. Daha geniş ders ise kısmî remediation hakkında. "En son sürümdeyiz" konforlu bir cevaptır ama şu anda bu sorunun yarısı için yanlıştır; ayrıca hiç yayımlanmamış bir yama sürümüne atıfta bulunan üçüncü taraf yazılar, operatörlerin korunduklarına inanmasını kolaylaştırıyor. İki upload API'sinden herhangi biri dışa açık olan DB-GPT çalıştıran herkes, yalnızca sürüm numaralarına veya danışma belgelerine güvenmek yerine, kurulu ağaçlarında bu belirli düzeltmelerin var olduğunu doğrulamalı.