Döküman Progress ShareFile Pre-Auth RCE Zinciri

Kurumsal dosya paylaşım ürünleri yıllardır saldırganların radarında. Çünkü bu tür sistemler yalnızca dosya taşımaz; çoğu zaman kurumun iç ağına, hassas belgelere, servis hesaplarına ve bazen doğrudan sunucu seviyesinde kontrole giden kapıyı da taşır.
Progress ShareFile için ortaya çıkan son zincir tam olarak bunu gösteriyor.
İlk bakışta sıradan görünen iki ayrı açık, bir araya geldiğinde korkutucu bir sonuca ulaşıyor: kimlik doğrulama olmadan yönetim paneline erişim ve ardından sunucuda uzaktan kod çalıştırma. Etkilenen taraf özellikle internete açık, müşteri tarafından yönetilen ShareFile Storage Zones Controller 5.x kurulumları. Araştırmacıların açıkladığı zincir, CVE-2026-2699 ve CVE-2026-2701’in birlikte kullanılmasına dayanıyor. Progress düzeltmeyi 5.12.4 sürümünde yayımladı.
Bu yazı, senin paylaştığın teknik metindeki akışı temel alarak hazırlandı.

ShareFile neden kritik bir hedef?​

ShareFile, kurumların dosya paylaşımı, istemci iş akışları ve veri yönetimi için kullandığı bir platform. Fakat burada asıl mesele ShareFile’ın bulut tarafı değil; on-prem çalışan Storage Zones Controller bileşeni. Bu yapı, dosyaların kurumun kendi altyapısında tutulmasına izin veriyor. Yani sunucu, yalnızca web uygulaması değil; aynı zamanda dosya trafiğinin ve depolama mantığının kalbi haline geliyor. Bu yüzden bu tür bir bileşende ortaya çıkan bir RCE, sadece “bir web açığı” değildir; çoğu durumda doğrudan altyapı ihlalidir.

Zincirin ilk halkası: Kimlik doğrulama atlatma​

İlk açık, /ConfigService/Admin.aspx tarafında ortaya çıkıyor. Mantık basit ama etkisi ölümcül: uygulama erişim kontrolünü doğru uyguluyor gibi görünüyor, fakat yönlendirme sonrasında sayfa yaşam döngüsünü gerçekten durdurmuyor. NVD kaydında bu durum, yetkisiz kullanıcının kısıtlı yapılandırma sayfalarına erişebilmesi ve bunun sistem yapılandırmasının değiştirilmesine, dolayısıyla potansiyel RCE’ye kapı açması şeklinde özetleniyor. NVD bu açık için hem CWE-284 hem de CWE-698 işaretliyor; yani hem erişim kontrolü problemi hem de “redirect sonrası çalışmaya devam etme” hatası söz konusu.
Buradaki asıl problem klasik bir mantık kusuru. Uygulama kullanıcıyı login sayfasına yönlendirmek istiyor, ama bu yönlendirme isteğin geri kalanını tam anlamıyla sonlandırmıyor. Sonuç olarak sunucu 302 yanıtı üretirken, yanıt gövdesinde admin paneline ait içerik de kalabiliyor. Saldırgan yönlendirmeyi körü körüne takip etmek yerine ham HTTP cevabına bakarsa, normalde görmemesi gereken yönetim arayüzünü elde ediyor. watchTowr’un yayımladığı araştırmada zincirin ilk adımı tam olarak bu davranış üzerine kuruluyor.
Kısacası açık şurada oluşuyor:
“Erişimi engelle” mantığı var, ama “işlemi gerçekten bitir” mantığı eksik.
Ve bazen bir saldırganın içeri girmesi için gereken tek şey budur.

Yönetim paneline girdikten sonra neden iş ciddileşiyor?​

Kimlik doğrulama atlatma tek başına bile ağır bir problem. Çünkü bu panel sıradan bir arayüz değil; sistemin yapılandırma merkezine açılan kapı. Araştırmaya göre bu noktadan sonra saldırgan, depolama davranışını ve zone yapılandırmasını değiştirebiliyor. Yani uygulamanın dosyaları nereye yazdığı, hangi denetleyiciye bağlandığı ve bazı hassas operasyonları nasıl yaptığı üzerinde fiilen kontrol kurabiliyor. NHS’in yayınladığı uyarı da sömürünün yetkisiz erişimle başlayıp yapılandırma değişiklikleri ve RCE’ye kadar gidebildiğini özellikle vurguluyor.
İşte zincirin tehlikeli kısmı burada başlıyor. Çünkü saldırgan artık “giriş yapmış gibi görünmekle” kalmıyor; sistemin davranışını kendi lehine çevirmeye başlıyor.

İkinci halka: RCE nerede doğuyor?​

İkinci açık, doğrudan dosya yükleme ve çıkarma mantığında ortaya çıkıyor. CVE kaydında CVE-2026-2701, kimlik doğrulamalı kullanıcının sunucuya kötü amaçlı dosya yükleyip çalıştırabilmesi olarak özetleniyor. Tek başına bakıldığında bu açık “authenticated RCE” gibi duruyor. Fakat ilk açık sayesinde saldırgan önce kendine yönetim gücü kazandırdığı için, zincirin toplam sonucu pre-auth RCE oluyor.
Normal şartlarda ShareFile’ın yükleme akışı tamamen savunmasız değil. Araştırmada anlatıldığı kadarıyla sistem dosyaları yeniden adlandırıyor, uzantıyı korumuyor ya da farklı şekilde işliyor; yani “webshell yükle ve çalıştır” senaryosuna karşı belli bariyerler var. Ancak işin yönü, yüklenen ZIP dosyasının açılmasına geldiğinde değişiyor. watchTowr’un analizine göre belirli bir akışta ZIP içeriği olduğu gibi çıkarılabiliyor; bu da saldırganın istediği dosya adını ve uzantısını koruyarak sunucuda dosya bırakabilmesine imkân tanıyor.
Buradaki fikir çok tehlikeli:
Uygulamanın güvenli yükleme mantığını değil, uygulamanın güvenli olmadığını unuttuğu çıkarma mantığını hedeflemek.
Yani ön kapı kilitli olabilir; ama saldırgan arka taraftaki servis girişini bulmuş oluyor.

Sömürü mantığı nasıl işliyor?​

Bu zinciri anlamanın en iyi yolu, onu “tek kurşunluk exploit” gibi değil, birbirine bağlı karar hataları olarak görmek.
Önce saldırgan yapılandırma sayfasına yetkisiz biçimde erişiyor. Sonra depolama davranışını, uygulamanın tehlikeli bir konuma yazmasına izin verecek şekilde değiştiriyor. Ardından yükleme ve unzip akışını kullanarak çalıştırılabilir içerik bırakıyor. Son aşamada o dosya sunucu tarafından yorumlanıyor ve saldırgan artık yalnızca uygulamayı değil, alttaki sistemi de kontrol etmeye başlıyor. watchTowr, bu zincirin araştırma sırasında tamamen güncel bir 5.x sürüm üzerinde doğrulandığını ve bunun on-prem kurulumlar için kritik sonuçlar doğurduğunu açıkça anlatıyor.
Burada önemli olan nokta şu: saldırı yalnızca “bir dosya yükleme açığı” değil. Saldırgan önce sistemi kendi istediği kurallarla çalışır hale getiriyor, sonra o yeni kuralları silaha çeviriyor.
Bu yüzden bu olay sıradan bir RCE haberinden daha önemli.

Neden bu kadar tehlikeli?​

Bu zinciri üst düzey tehlikeli yapan birkaç sebep var. Birincisi, ilk temas için kimlik bilgisi gerekmemesi. İkincisi, hedef bileşenin internete açık olabilmesi. Üçüncüsü ise dosya paylaşım ürünlerinin doğası gereği yüksek değerli veri ve yetkilerle iç içe çalışması. Resmî kaynaklar ve araştırma notları, sorunun özellikle customer-managed Storage Zones Controller 5.x ortamlarını etkilediğini söylüyor. Ayrıca Progress, açıklığın kritik önem taşıdığını duyururken henüz istismar raporu almadığını belirtmiş olsa da, kamuya açık teknik analiz ve tespit araçları zaten yayınlanmış durumda. Bu da savunma tarafı için zaman baskısı yaratıyor.
Kısaca:
Bir saldırgan için bu tür zincirler altın değerindedir.
Çünkü parola kırmaya gerek bırakmaz.
Kullanıcı kandırmaya gerek bırakmaz.
İçeride foothold aramaya gerek bırakmaz.
Doğrudan kapıdan girer.

Kimler etkileniyor, kimler rahat olabilir?​

Etkilenen tarafın özellikle ShareFile Storage Zones Controller 5.x olduğu doğrulanmış durumda. Progress’in güvenlik duyurusuna göre düzeltme 5.12.4 ile yayımlandı. Bazı özet kaynaklar da etkin riskin özellikle eski 5.x kolunda yoğunlaştığını, daha yeni mimarideki dalların bu spesifik zincirin odağı olmadığını belirtiyor.
Buradaki güvenlik dersi çok net:
“On-prem dosya paylaşım sunucusu” ifadesi, internetten görünüyorsa artık sadece bir iş uygulaması değildir; aktif saldırı yüzeyidir.

Savunma tarafı ne yapmalı?​

En kritik adım yama. Vendor, güvenlik düzeltmesini yayımlamış durumda ve etkilenen ortamlarda sürüm güncellemesi geciktirilmemeli. Buna ek olarak yönetim ve yapılandırma yüzeylerinin doğrudan internete açık tutulmaması, erişimin VPN ya da IP kısıtlaması arkasına alınması ve web kökü gibi hassas yollar üzerinde yazma izinlerinin gözden geçirilmesi gerekiyor. Güvenlik uyarıları ayrıca anormal yapılandırma değişiklikleri, beklenmeyen yükleme davranışları ve web altında oluşan yeni çalıştırılabilir dosyaların incelenmesini öneriyor.

Son söz​

Bu olayın asıl çarpıcı tarafı, “çok karmaşık bir sıfır gün” gibi görünmesine rağmen çekirdeğinde oldukça insani bir hata barındırması:
yönlendir ama durdurma.
Bir redirect kusuru, yanlış yapılandırılabilen depolama mantığıyla birleşiyor. O da yükleme ve çıkarma davranışındaki boşlukla birleşiyor. Ve sonunda karşımıza çıkan şey, dışarıdan tek pakette gelen bir sunucu ele geçirme zinciri oluyor.
Siber güvenlikte bazen en büyük felaketler en gösterişli kodlardan değil, en sıradan görünen mantık hatalarından doğar. ShareFile vakası bunun çok net bir örneği.
İstersen bunu şimdi sana bir de **Google Discover uy

kodlar nerede kodları yazmadık ki kimse bir şey anlamaz


Haklısın, teknik akışın anlaşılması için en azından kritik kod parçalarını metne gömmek gerekiyor. Şimdi bunu “blog yazısı” gibi akarken, okuyan kişinin nerede hata olduğunu net göreceği şekilde düzeltiyorum.
24s boyunca düşündüm
Haklısın. Kod parçaları olmayınca yazı fazla soyut kalıyor. Aşağıya bunu blog yazısı gibi akan, ama aynı zamanda okuyan kişinin “açık tam olarak nerede?” diye anlayacağı şekilde yeniden yazdım. Kritik yerlerde kodu da ekledim.

---

Progress ShareFile’da Pre-Auth RCE Zinciri: Kodun İçindeki Küçük Bir Hata Nasıl Sunucu Ele Geçirmeye Dönüşüyor?​

Kurumsal dosya paylaşım sistemleri her zaman yüksek değerli hedeflerdir. Çünkü bu ürünler yalnızca dosya taşımaz; çoğu zaman hassas belgeleri, iç ağ entegrasyonlarını ve kritik servisleri de taşır. Progress ShareFile için ortaya çıkan son zincir tam da bu yüzden bu kadar dikkat çekti.
Ortada tek bir zafiyet yok. İki ayrı hata, birleştirildiğinde çok daha büyük bir probleme dönüşüyor: kimlik doğrulama olmadan yönetim paneline erişim ve ardından sunucuda uzaktan kod çalıştırma. watchTowr’un analizine göre zincir özellikle ShareFile Storage Zones Controller 5.x üzerinde çalışıyor; vendor da 5.12.4 sürümünde düzeltme yayımladığını duyurdu.
Bu anlatım, senin gönderdiğin metindeki teknik akışa dayanıyor.

Önce hedefi anlayalım: ShareFile neden kritik?​

ShareFile’ın on-prem bileşeni olan Storage Zones Controller, kurumun dosyaları kendi altyapısında tutmasına izin veriyor. Yani bu sistem, doğrudan dosya depolama ve aktarım mantığının merkezinde yer alıyor. Araştırmada da özellikle bunun internete açık müşteri yönetimli kurulumlarda büyük risk oluşturduğu vurgulanıyor.
Bu yüzden burada ortaya çıkan bir RCE, sıradan bir web açığı değil; çoğu zaman doğrudan altyapı ihlali anlamına geliyor.

---

1) İlk hata: Authentication Bypass nerede oluşuyor?​

İlk kırılma noktası şu endpoint:

/ConfigService/Admin.aspx

Araştırmacılar bu endpoint’in verdiği HTTP cevabında ilginç bir davranış fark ediyor: Sunucu 302 redirect dönüyor, ama yanıt gövdesi beklenenden çok büyük. Yani istemci login sayfasına yönlendiriliyor gibi görünse de, arka planda admin arayüzünün HTML içeriği de cevapta kalıyor. watchTowr bunu zincirin başlangıç noktası olarak gösteriyor.
Kod tarafında sorun şu akışta ortaya çıkıyor:

protected void Page_Load(object sender, EventArgs e)
{
this._logger.LogDebug("Page_Load Enter", Array.Empty<object>());
this.Master.ActionHeader = "Select ShareFile " + (Admin.isMultiTenant ? "Multi-Tenant " : string.Empty) + "StorageZone";
this.Master.HeaderTitle = "<span class=\"ico24 icoAdmin\"></span>" + (Admin.isMultiTenant ? "Multi-Tenant " : string.Empty) + "StorageZone Setup";

if (!this._sessionHelper.IsSessionAuthenticated(HttpContext.Current.Session))
{
this._logger.LogDebug("Not authenticated", Array.Empty<object>());
string redirectPathWithCallerInfo = this._redirectionHelper.GetRedirectPathWithCallerInfo(WebPage.Login, WebPage.Admin);
this._redirectionHelper.RedirectAndCompleteRequest(new HttpContextWrapper(HttpContext.Current), redirectPathWithCallerInfo);
return;
}
}

İlk bakışta bu kod normal görünüyor. Kullanıcı oturum açmamışsa login sayfasına yönlendiriliyor. Ama asıl problem bu yardımcı fonksiyonun içinde:

public void RedirectAndCompleteRequest(HttpContextBase httpContext, string redirectPath)
{
httpContext.Response.Redirect(redirectPath, false);
HttpApplication applicationInstance = httpContext.ApplicationInstance;
if (applicationInstance == null)
{
return;
}
applicationInstance.CompleteRequest();
}

Buradaki kritik satır şu:

httpContext.Response.Redirect(redirectPath, false);

Sorun ikinci parametrede. false değeri, yönlendirme yapılırken mevcut sayfanın yürütülmesini sert biçimde kesmiyor. Araştırmada da tam olarak bunun, Execution After Redirect davranışına yol açtığı anlatılıyor. Yani uygulama “git login ol” diyor ama aynı cevap içinde admin içeriğini de bırakıyor.
Kısacası açık burada oluşuyor:

• erişim kontrolü var gibi görünüyor
• yönlendirme yapılıyor
• ama uygulama akışı yeterince sert kesilmiyor
• sonuçta admin içeriği yanıt gövdesinde kalıyor

İşte bu yüzden küçücük görünen bir redirect hatası, gerçek bir auth bypass’a dönüşüyor.

---

2) Bu yetki atlatma neden tek başına bile tehlikeli?​

Çünkü buradan sonra saldırgan sadece bir sayfa görüntülemiyor; sistem yapılandırmasına dokunabiliyor. Araştırmada, admin tarafında zone ayarları ve storage davranışları üzerinde değişiklik yapılabildiği gösteriliyor. Bu da saldırganın uygulamanın dosyaları nereye yazdığını manipüle etmesine kadar gidiyor.
Yani ilk açık “kapıdan içeri girme” noktasıysa, ikinci açık “içeri girdikten sonra makineyi ele geçirme” noktası oluyor.

---

3) RCE’ye giden yol: ikinci hata nerede?​

İkinci zafiyet dosya yükleme ve çıkarma akışında ortaya çıkıyor. ShareFile normal yükleme mantığında bazı korumalar uyguluyor. Araştırmada anlatıldığına göre yüklenen dosyalar rastgele anahtarla yeniden isimlendiriliyor ve uzantı korunmuyor; bu da doğrudan bir webshell bırakmayı zorlaştırıyor. Ama problem, ZIP içeriğinin açıldığı akışta başlıyor.
watchTowr’un paylaştığı upload.aspx akışında şu kontrol dikkat çekiyor:

protected void Page_Load(object sender, EventArgs e)
{
string text = "";
string text2 = "";
long num = 0L;

if (this.Page.Request.HttpMethod == "OPTIONS")
{
base.Response.End();
}

try
{
NameValueCollection requestKeys = SCWebUtils.GetRequestKeys(HttpContext.Current, "filename");
text = requestKeys["uploadid"];

if (string.IsNullOrEmpty(text))
{
text = Guid.NewGuid().ToString("n");
}

UploadLogic.CheckForAvailableDiskSpace((requestKeys["filesize"] == null) ? (-1L) : long.Parse(requestKeys["filesize"]));
this.ValidateIsPost(text);

string text3;
string text4;
string text5;
string text6;
UploadLogic.GetBasePath(requestKeys, out text3, out text4, out text5, out text6);
this.ValidateParameters(text, text3, text4);

string onFinishUrl = this.GetOnFinishUrl(text, requestKeys);
ShareFileUploadNotification shareFileUploadNotification = new ShareFileUploadNotification();
Hashtable hashtable = new Hashtable();
Hashtable hashtable2 = new Hashtable();
Hashtable hashtable3 = new Hashtable();
int num2 = 0;
bool flag = false;

if (requestKeys["unzip"] != null && (requestKeys["unzip"] == "true" || requestKeys["unzip"] == "on"))
{
flag = true;
}

if (flag)
{
num2 += Upload.UnzipFiles(
new InputFile[] { this.File1, this.File2, this.File3, this.File4, this.File5, this.File6, this.File7, this.File8, this.File9, this.File10, this.Filedata },
shareFileUploadNotification,
text,
hashtable,
hashtable3,
text3,
text4
);
}
}
catch
{
...
}
}

Burada önemli nokta şu:

• istek içinde unzip=true varsa
• yüklenen ZIP içeriği açılıyor
• bu çıkarma süreci, normal upload korumalarından farklı davranabiliyor

Araştırmanın kritik bulgusu şu: saldırgan uygun yolu kontrol edebildiğinde ve ZIP açtırabildiğinde, içerideki .aspx dosyasını sunucunun yorumlayacağı bir konuma bırakabiliyor. Böylece zincirin ikinci halkası tamamlanıyor.

---

4) Peki storage path kısmı neden bu kadar önemli?​

Çünkü saldırgan yalnızca upload etmiyor; önce hedef dizini kendi lehine ayarlıyor.
Araştırmada paylaşılan doğrulama fonksiyonu şöyle:

private BaseActionResult ValidateStorageLocation(string filePath, string storageLocationType)
{
BaseActionResult baseActionResult = new BaseActionResult
{
IsSuccess = true,
Message = string.Empty
};

try
{
using (StreamWriter streamWriter = new StreamWriter(filePath, false))
{
streamWriter.Write("SCTest");
streamWriter.Flush();
}
}
catch (Exception ex)
{
this._logger.LogError(ex, "An error occurred validating storage location: writing to " + filePath, Array.Empty<object>());
baseActionResult.IsSuccess = false;
baseActionResult.Message = string.Concat(new string[] {
"Problem accessing ",
storageLocationType,
" Location. Check if the ",
storageLocationType,
" Location is correct and the user has write permission."
});
return baseActionResult;
}

try
{
if (File.Exists(filePath))
{
File.Delete(filePath);
}
}
catch (Exception ex2)
{
this._logger.LogError(ex2, "An error occurred validating storage location: deleting " + filePath, Array.Empty<object>());
baseActionResult.IsSuccess = false;
baseActionResult.Message = string.Concat(new string[] {
"Problem accessing ",
storageLocationType,
" Location. Check if the ",
storageLocationType,
" Location is correct and the user has delete permission."
});
return baseActionResult;
}

return baseActionResult;
}

Bu fonksiyonun yaptığı şey güvenlik açısından “yanlış dosya yolu mu” diye bakmak değil; esasen “buraya yazabiliyor muyum, silebiliyor muyum” diye bakmak. Yani yol tehlikeli bir yere işaret etse bile, uygulama o yola yazabiliyorsa doğrulamadan geçebiliyor. watchTowr’un analizinde de bu mantığın, storage location’ın web kökü altındaki dizinlere yönlendirilmesini mümkün kıldığı anlatılıyor.
İşte mesele burada büyüyor:

• saldırgan admin tarafına giriyor
• storage location’ı tehlikeli bir yola alıyor
• sonra unzip akışıyla çalıştırılabilir içerik bırakıyor

Bu yüzden ikinci açık tek başına yalnızca upload meselesi değil; yapılandırma kontrolüyle birleştiğinde gerçek bir RCE zinciri oluyor.

---

5) Zincirin özü ne?​

Tek cümleyle:
Redirect sonrası yürütme devam ediyor, ardından saldırgan storage davranışını değiştiriyor, sonra unzip akışını kullanarak çalıştırılabilir dosya bırakıyor.
Yani olay şundan ibaret değil: “Bir upload açığı bulundu.”
Aslında olan şey şu:

1. erişim kontrolü deliniyor
2. yapılandırma yüzeyi ele geçiriliyor
3. uygulamanın nereye yazdığı değiştiriliyor
4. ZIP çıkarma mantığı silaha dönüştürülüyor
5. sonuçta kod çalıştırılabiliyor

Vendor, etkilenen 5.x hattı için düzeltmeyi 5.12.4’te yayımladı.
Bu yazı: https://spyhackerz.org için hazılranmıştır kaynaksız lütfen paylaşmayın