CVE-2026-48088

OpenReception-ın təyinatlaşdırma proqram təminatı uçdan-uca şifrlənmiş təyinatlaşdırma platforması təqdim edir. Versiya 1.0.4-dən əvvəl `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` marşrutu autentifikasiya olmadan platformadakı hər hansı tenant üçün hücumçunun idarə etdiyi ML-KEM-768 açıq açarlarını qəbul edir və saxlayır. Sessiya və ya qeydiyyat kukisi mövcud olmadıqda, handler "Unauthorized crypto key storage attempt" xəbərdarlığını loqlayır, lakin buna baxmayaraq sətiri daxil etməyə davam edir. Platformanın "hətta administratorlar belə həssas məlumatları görə bilməz" şəklindəki E2E iddiası pozulur: autentifikasiya olunmamış istənilən şəbəkə hücumçusu özünü hər hansı tenantın gələcək pasiyent təyinatları üçün əlavə şifrləmə alıcısı kimi qeydiyyata ala bilər. Xətanın ikinci variantı isə icazəsiz girişlə bağlı xəbərdarlıq loqunu gizlədir. Zod sxemi `email` sahəsini opsional edir. Sorğu gövdəsində `email` olmadıqda və sorğuda qeydiyyat kukisi mövcud olmadıqda, `registrationEmail === email` müqayisəsi `undefined === undefined` olur ki, bu da `true` kimi qiymətləndirilir. Handler sorğunu legitim qeydiyyat axını kimi qəbul edir, xəbərdarlığı tamamilə ötürür və sətiri saxlayır. Uğurlu yaddaşa yazma hələ də `[info]` loq sətri kimi qeydə alınır, lakin operatorların izləməsi və ya xəbərdarlıq alması ehtimal olunan təhlükəsizliklə bağlı kritik xəbərdarlıq itir. `staff_crypto` cədvəlində `user_id` üzrə unikal məhdudiyyət (unique constraint) yoxdur, buna görə də eyni personal identifikatoru üçün istənilən sayda hücumçu sətirləri mövcud ola bilər və onların hamısı `is_active=true` olaraq geri dönər. Təqdim edilən `staffId`-nin mövcud istifadəçi və ya gözləyən dəvətlə uyğun gəlməsi tələb olunmur. `passkeyId`, `publicKey` və `privateKeyShare` üzərində sxem validasiyası da zəifdir: `<placeholder-base64>` literal sətiri qəbul edilmişdir, bu da sahənin mövcudluğundan başqa heç bir uzunluq, format və ya kriptoqrafik validlik yoxlamasının aparılmadığını göstərir. Bu zəiflik autentifikasiyadan yan keçməyə bağlı olmasa da, onu daha da ağırlaşdırır: zəhərlənmiş kataloq həmçinin legitim təyinat axınlarını pozan yanlış formatlı girişlərlə doldurula bilər. İnjeksiya edilmiş açar ictimai təyinat axını tərəfindən istifadə edilir. "Pasiyent" kimi autentifikasiyasız `bootstrap-challenge` və `bootstrap-verify` prosesini tamamladıqdan sonra alınan `bookingAccessToken` `GET /api/tenants/{id}/appointments/staff-public-keys` sorğusu tərəfindən qəbul edilir və bu sorğu legitim açarlarla yanaşı hücumçunun idarə etdiyi açarları da qaytarır. Yeni təyinat öz tunel açarını ML-KEM vasitəsilə siyahıda olan bütün alıcılar üçün şifrləyir, beləliklə hücumçu şifrləmənin ortaq alıcısına çevrilir və uyğun sirr açarı ilə tunel açarını dekapsulyasiya edə bilir. Buradan etibarən həmin təyinat üçün bütün yüklər (payloads) şifrədən açıla bilir. Versiya 1.0.4 bu problemi aradan qaldırır.