CVE-2026-70663: alf.io API anahtarları, API-key rol kümesi dışındaki roller alabiliyordu

Sürüm notları ne diyor

10 Kasım 2026 tarihinde dev.to'da yayımlanan bir yazıya göre alf.io'nun sürüm notlarında, anahtar rollerinin API-key rolleriyle sınırlı tutulmadığı bir API anahtarı rol atama sorunu olarak CVE-2026-70663 listeleniyor. alf.io; yönetim yüzeyinde organizatör hesapları, etkinlik yapılandırması, ödeme ayarları, katılımcı verileri, check-in iş akışları ve API entegrasyonları barındırabilen bir bilet rezervasyon ve etkinlik yönetim sistemi.

dev.to yazısı, bilinenlerin sınırları konusunda dikkatli. Satıcı notu kısa ve mevcut birincil malzemede tam bir istismar zinciri, CVSS vektörü veya sürüm özetinde sabitlenmiş bir sürüm yayımlanmamış. Danışma genişletilene kadar herhangi bir dağıtımın maruziyeti bir skordan okunmak yerine yerel olarak tespit edilmek zorunda.

Bir kod hatası değil, yetkilendirme kusuru

Yazı, sorunu bir yetkilendirme modeli kusuru olarak nitelendiriyor: API kullanımı için tasarlanmış bir kimlik bilgisine, API anahtarları için öngörülen kümenin dışında bir rol atanabiliyordu. Sonuç, örnek üzerinde mevcut rollere ve bunlara bağlı izinlere bağlı. İstenmeyen bir role sahip bir API anahtarı bu nedenle yalnızca bilet oluşturup okumakla yetinmeyebilir. Kendisine atanan daha yüksek yetkili rolün erişebildiği aynı nesnelere ve eylemlere ulaşabilir; bu da alf.io'da ödeme ayarları ve katılımcı verilerini kapsayabilir.

Rol tavanları neden önemli

Yazarın merkezî argümanı, API-key rollerinin açık bir tavana ihtiyaç duyduğudur. Rol, bir izin demetidir ve bir API-key rolü, uygulamanın insan rollerine işaret edebilen bir takma ad değil, bunların bilinçli bir alt kümesi olmalıdır. Bu tavan; etkinlik kapsamını, organizatör kapsamını, okuma veya yazma yeteneğini, check-in yetkisini ve idari işlevleri açıkça belirtmelidir.

Bir anahtara rastgele bir rol atanabildiğinde, inceleme sorunu anahtar sahibinden rol düzenleyicisine kayar. Normal arayüz üzerinden yönetici olamayan bir kullanıcı, etkin izinleri kendisini aşan bir anahtar oluşturabilir. Yazıya göre doğru kontrol, istenen rolü hem çağıranın yetkisiyle hem de anahtar türü için izin verilen en yüksek rolle karşılaştırmalıdır.

Yazının belirttiğine göre aynı örüntü bilet sistemlerinde genelgeçerdir: organizatörlerin kendi etkinlikleri üzerinde geniş kontrole ihtiyacı vardır ama her organizatörü yöneten veya örnek geneli ödeme ayarlarını değiştiren bir anahtar üretebilmemelidir; bir tarayıcı anahtarı da katılımcı kayıtlarını dışa aktaramadan biletleri doğrulayabilmelidir.

Aynı notlarda ikinci bir CVE

Sürüm notlarında ayrıca, bir admin etkinlik veya abonelik API'sinde doğrulanmamış bir görsel URL'siyle ilgili bir SSRF sorunu olan CVE-2026-70664 yer alıyor. Yazı, iki bulguyu tek bir mekanizma olarak görmeye karşı uyarıyor; ancak birlikte, API yönetiminin geçerli bir tokenden fazlasına ihtiyaç duyduğunu gösterdiklerini söylüyor: sunucu tarafı bir istek veya rol sorgusu tetikleyen her alan, amaçlanan yetkiye karşı denetlenmelidir.

Operatörler ne yapmalı

dev.to yazısı bir yanıt planı ortaya koyuyor. Düzeltmeyi içeren sürümü belirleyin ve güvenli bir sürümü CVE numarasından çıkarsamadan satıcının güncel desteklenen sürümüne geçin. Tam yamalanmış sürüm için sürüm notlarını ve depo danışmasını kontrol edin, ardından çalışan container veya paket özetini doğrulayın.

API anahtarlarını sahip, etkinlik veya organizatör kapsamı, rol, oluşturulma tarihi, son kullanım ve amaç ölçütleriyle envanterleyin. Sahibi olmayan veya belgelenmiş bir entegrasyonu olmayan anahtarları iptal edin; eski rol açıkça sınırlı değildse yükseltmeden sonra anahtarları yeniden verin. Yazının uyardığı gibi, düzeltmeden önce oluşturulmuş bir anahtar, uygulama artık yamalandığı gerekçesiyle güvenilir kalmamalıdır.

Operatörler ayrıca API anahtarlarına bağlı rolleri insan kullanıcıların erişebildiği izinlerle karşılaştırarak idari roller, genel kapsam, ödeme erişimi veya dışa aktarma yetenekleri olan anahtarları aramalı ve her anahtarın kullanımı çevresindeki rol değişiklikleri, etkinlik dışa aktarımları, iade ve check-in olayları için denetim izini incelemelidir. Bir tespit durumunda, yazı her API çağrısı için anahtar tanımlayıcısını, rolü, işlemi, etkinliği, kaynak adresi ve sonucu kaydetmeyi, ancak hiçbir zaman gizli değeri kaydetmemeyi öneriyor. Uyarılar; bir anahtarın belgelenmiş amacı dışında işlem yapması, rol değişikliğinin ardından yetki genişlemesi ve yeni ağlardan alışılmadık kullanım durumlarında tetiklenmelidir.

Yazı ayrıca yeni anahtarlar için bir onay yolu öneriyor: istek yapan kişi iş entegrasyonunu, etkinlik kapsamını, rol tavanını ve beklenen ömrü belirtir; onaylayan kişi ise rolün gerçekten API kullanımına açık olduğunu ve istek yapan kişinin kendi yetkisini aşamayacağını doğrular. Bu onay, izlenmeyen bir elektronik tabloda değil, anahtarın meta verisiyle birlikte saklanmalıdır.

Neden önemli

API anahtarları çoğu zaman makine kimlik bilgileri olarak tanımlanır; bu çerçeve, bir anahtarın hangi rolleri üstlenebileceğini ve bu rolleri kimin belirlediğini gizleyen önemli soruyu gözden kaçırır. CVE-2026-70663, büyük olasılıkla diğer etkinlik ve bilet platformlarında da var olan bir kusur sınıfının somut bir örneğidir: rol atamasına hiçbir zaman sert bir tavan verilmemiş bir kimlik bilgisi türü. alf.io operatörleri için yama, hatayı kapatır ama maruziyeti kapatmaz; çünkü eski model altında verilmiş anahtarlar hâlâ kimsenin niyet etmediğinden fazla yetki taşıyor olabilir. Yazının çerçevelediği gibi pratik hedef dar ve sınanabilirdir: bu anahtar bu etkinlikte şu eylemleri gerçekleştirebilir ve bir rol düzenleyici hatası, bu kümeyi yeni bir onay olmadan genişletemez.