CVE-2026-48088

OpenReception'ın randevu rezervasyon yazılımı, uçtan uca şifreli bir randevu rezervasyon platformu sunmaktadır. Versiyon 1.0.4 öncesinde, `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` rotası, kimlik doğrulaması olmaksızın platformdaki herhangi bir kiracı için saldırgan tarafından kontrol edilen ML-KEM-768 genel anahtarlarını kabul etmekte ve depolamaktadır. İşleyici, ne bir oturum ne de bir kayıt çerezi mevcut olmadığında "Unauthorized crypto key storage attempt" uyarısını günlüğe kaydetmekte ancak buna rağmen satırı eklemeye devam etmektedir. Platformun "yöneticilerin bile hassas bilgileri görüntüleyemeyeceği" yönündeki E2E iddiası bozulmuştur: Kimliği doğrulanmamış herhangi bir ağ saldırganı, herhangi bir kiracının gelecekteki hasta randevuları için kendisini ek bir şifreleme alıcısı olarak kaydedebilir. Hatanın ikinci bir varyantı, yetkisiz erişim uyarı günlüğü girişini bastırmaktadır. Zod şeması `email` alanını isteğe bağlı hale getirmektedir. İstek gövdesinde `email` alanı eksik olduğunda ve istek herhangi bir kayıt çerezi taşımadığında, `registrationEmail === email` karşılaştırması `undefined === undefined` haline gelmekte ve bu durum `true` olarak değerlendirilmektedir. İşleyici, isteği meşru bir kayıt akışı olarak görmekte, uyarıyı tamamen atlamakta ve satırı depolamaktadır. Başarılı depolama işlemi hala bir `[info]` günlük satırı olarak kaydedilmektedir, ancak operatörlerin izlemesi veya alarm kurması en muhtemel olan güvenlik açısından ilgili uyarı ortadan kalkmaktadır. `staff_crypto` tablosunun `user_id` üzerinde benzersiz bir kısıtlaması yoktur, bu nedenle aynı personel tanımlayıcısı için rastgele sayıda saldırgan satırı bir arada bulunabilir ve tamamı `is_active=true` olarak dönebilir. Sağlanan `staffId` değerinin mevcut herhangi bir kullanıcıyla veya bekleyen davetle eşleşmesi gerekmemektedir. `passkeyId`, `publicKey` ve `privateKeyShare` üzerindeki şema doğrulaması da zayıftır: Alan varlığının ötesinde uzunluk, format veya kriptografik geçerlilik kontrolü yapılmadığını gösteren `<placeholder-base64>` literal dizesi kabul edilmiştir. Bu zayıflık, kimlik doğrulama atlatmadan bağımsızdır ancak onu derinleştirmektedir: Zehirlenmiş bir dizin, meşru rezervasyon akışlarını bozan hatalı girdilerle doldurulabilir. Enjekte edilen anahtar, genel rezervasyon akışı tarafından tüketilmektedir. Bir "hasta" olarak kimlik doğrulaması yapılmamış `bootstrap-challenge` ve `bootstrap-verify` seremonisi tamamlandıktan sonra, ortaya çıkan `bookingAccessToken`, saldırgan tarafından kontrol edilen anahtarları meşru olanlarla birlikte döndüren `GET /api/tenants/{id}/appointments/staff-public-keys` tarafından kabul edilir. Yeni bir randevu, tünel anahtarını ML-KEM ile listelenen tüm alıcılara şifreler; böylece saldırgan şifrelemenin ortak alıcısı olur ve tünel anahtarını eşleşen gizli anahtarla kapsül dışına çıkarabilir (decapsulate). Buradan itibaren, o rezervasyona ait tüm randevu veri yükleri çözülebilir. Versiyon 1.0.4 sorunu gidermektedir.