CVE-2026-48075 in appointment-booking-software
Tóm tắt
Bởi VulDB • 07/08/2026
Phần mềm đặt lịch hẹn của OpenReception cung cấp một nền tảng đặt lịch được mã hóa đầu cuối. Trước phiên bản 1.0.5, điểm kết thúc `add-to-tunnel` tạo một hàng lịch hẹn mới trong bất kỳ tunnel nào của khách hàng mà không yêu cầu xác thực người gọi. Một yêu cầu cung cấp bất kỳ `tunnelId` hợp lệ và bất kỳ `emailHash` hợp lệ nào (hai giá trị này không cần thuộc về cùng một tunnel) sẽ dẫn đến việc chèn một lịch hẹn có `status = "CONFIRMED"`, các trường ciphertext do kẻ tấn công kiểm soát, ngày và thời lượng do kẻ tấn công chỉ định, cũng như tác vụ viên do kẻ tấn công chọn. Điểm kết thúc này chỉ xác thực rằng tồn tại một tunnel với `emailHash` đã cho, sau đó ghi lịch hẹn bằng cách sử dụng trực tiếp `tunnelId` do kẻ tấn công cung cấp. Việc tra cứu `emailHash` về cơ bản là kiểm tra sự tồn tại của tenant; nó không xác thực người gọi là chủ sở hữu của `tunnelId` được cung cấp. Kết hợp với việc thiếu bất kỳ phiên nào, tiêu đề Authorization, token truy cập đặt lịch hoặc PoW (Proof of Work), điều này khiến điểm kết thúc chấp nhận các ghi chép lịch hẹn tùy ý vào bất kỳ tunnel nào. Ngược lại, điểm kết thúc anh em `create-new-client` (được sử dụng để khởi tạo một tunnel khách hàng hoàn toàn mới) yêu cầu Bearer bootstrap booking access token do luồng bootstrap-challenge / bootstrap-verify cấp phát. Điểm kết thúc `add-to-tunnel`, dự định dành cho các khách hàng quay lại đặt thêm lịch hẹn, không có cơ chế kiểm soát tương đương. Middleware của chính ứng dụng xác nhận đây là hành động cố ý: `add-to-tunnel` được liệt kê rõ ràng trong danh sách trắng public-route của apiAuthHandle cùng với các điểm kết thúc bootstrap và challenge (những điểm này hợp lệ khi không có phiên). Phiên bản 1.0.5 đã khắc phục sự cố này.
If you want to get best quality of vulnerability data, you may have to visit VulDB.