CVE-2026-48075

OpenReception'ın randevu rezervasyon yazılımı, uçtan uca şifreli bir randevu rezervasyon platformu sunmaktadır. Versiyon 1.0.5 öncesinde, `add-to-tunnel` uç noktası, herhangi bir çağırıcı kimlik doğrulaması olmaksızın herhangi bir istemci tünelinde yeni bir randevu satırı oluşturmaktadır. Herhangi bir geçerli `tunnelId` ve herhangi bir geçerli `emailHash` sağlayan bir istek (bu ikisinin aynı tünele ait olması gerekmez), `status = "CONFIRMED"` durumunda, saldırgan tarafından kontrol edilen şifreli alanlara, saldırgan tarafından kontrol edilen tarih ve süreye ve saldırgan tarafından seçilen bir aracıya sahip eklenmiş bir randevu ile sonuçlanır. Uç nokta yalnızca verilen `emailHash` ile eşleşen bir tünelin mevcut olduğunu doğrular ve ardından randevuyu doğrudan saldırgan tarafından sağlanan `tunnelId` kullanarak yazar. `emailHash` araması aslında kiracı üzerinde bir varlık kontrolüdür; çağırıcıyı sağlanan `tunnelId`'nin sahibi olarak kimliklendirmez. Herhangi bir oturumun, Authorization başlığının, rezervasyon erişim belirtecinin veya PoW'un bulunmamasıyla birleştiğinde bu durum, uç noktanın rastgele tünellere keyfi randevu kayıtlarını kabul etmesine neden olur. Buna karşılık, (yepyeni bir istemci tüneli başlatmak için kullanılan) kardeş uç nokta `create-new-client`, bootstrap-challenge / bootstrap-verify akışı tarafından düzenlenen bir Bearer bootstrap rezervasyon erişim belirteci gerektirir. Geri dönen müşterilerin ek randevular alması için tasarlanan `add-to-tunnel` uç noktasında ise benzer bir denetim yoktur. Uygulamanın kendi ara katman yazılımı bunun kasıtlı olduğunu onaylamaktadır: `add-to-tunnel`, bootstrap ve challenge uç noktalarıyla birlikte (bunların meşru olarak oturumu yoktur) apiAuthHandle public-route izin listesinde açıkça belirtilmiştir. Versiyon 1.0.5 bu sorunu düzeltmektedir.