| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.5, the unauthenticated `/api/tenants/{id}/schedule` endpoint returns every non-archived channel for a tenant regardless of the channel's `isPublic` flag. Channels marked `isPublic = false` are intended to be invisible to public callers; the dashboard creates them deliberately to hide internal-only services from the patient booking UI. The schedule endpoint ignores the flag entirely and discloses channel names, descriptions, IDs, agent associations, pause status, confirmation requirements, and computed slot availability for the requested date range. The asymmetry between `addAppointmentToTunnel` (which enforces `eq(channel.isPublic, true)`) and the schedule endpoint (which does not) confirms the design intent: private channels exist as a real access boundary in the booking flow, just not in the schedule disclosure. Version 1.0.5 patches the issue. |
| OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, when a user navigates to the `/logout` page, the page's server-side load handler deletes the `access_token` cookie before calling `/api/auth/logout` via an internal `event.fetch()`. The internal fetch consequently runs without the auth cookie, so `apiAuthHandle` rejects it, the logout handler never executes, and `SessionService.revokeSession()` is never called for the current session. The DB session row remains valid until its natural expiry (one week by default). The user sees a successful logout (cookie gone, UI returns to login), but any party still holding a copy of the now-deleted access token can continue making authenticated API calls until the session naturally expires. The root cause is a simple ordering mistake. The same auth subsystem implements the correct order in `/api/auth/logout`: revoke the current DB session first, then delete the cookie. The page-level wrapper does the opposite. Version 1.0.2 initiates server-side logout before removing authentication cookies and first appears in version 1.0.2. Version 2.0.0 later replaces this with a race-free client-side logout flow. |
| OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, the `/api/log` endpoint accepts unauthenticated POST requests, applies no schema validation to the message body, writes attacker-controlled content directly into the application's stdout log, interprets newline characters as real line breaks, and enforces no size or rate limits. Three independent abuse modes follow: log injection (forge log lines that look like legitimate system events), log volume DoS (saturate the logging pipeline at sustained 100+ requests per second of small messages), and oversized-payload submission (100 KB payloads accepted; larger sizes not tested). The most operationally damaging mode is log injection. An attacker can inject lines that an operator scanning logs would mistake for real system errors, mask their own activity behind fake noise, or pollute SIEM alerting rules with crafted false positives. A line such as `[error]: injected admin error` injected from an unauthenticated source is indistinguishable from the application's own error output once written to disk. Version 1.0.2 fixes the issue. |
| OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the route `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` accepts and stores attacker-controlled ML-KEM-768 public keys against any tenant on the platform without authentication. The handler logs an "Unauthorized crypto key storage attempt" warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform's E2E claim that "even administrators cannot view sensitive information" is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant's future patient appointments. A second variant of the bug suppresses the unauthorized-warning log entry. The Zod schema makes the `email` field optional. When the request body omits `email` and the request carries no registration cookie, the comparison `registrationEmail === email` becomes `undefined === undefined`, which evaluates to `true`. The handler treats the request as a legitimate registration flow, skips the warning entirely, and stores the row. Successful storage is still recorded as an `[info]` log line, but the security-relevant warning that operators are most likely to monitor or alert on is gone. The `staff_crypto` table has no unique constraint on `user_id`, so an arbitrary number of attacker rows can coexist for the same staff identifier and all return as `is_active=true`. The supplied `staffId` does not need to match any existing user or pending invite. Schema validation on `passkeyId`, `publicKey`, and `privateKeyShare` is also weak: the literal string `<placeholder-base64>` was accepted, indicating no length, format, or cryptographic-validity check beyond field presence. This weakness is independent of the auth bypass but compounds it: a poisoned directory can also be filled with malformed entries that break legitimate booking flows. The injected key is consumed by the public booking flow. After completing the unauthenticated `bootstrap-challenge` and `bootstrap-verify` ceremony as a "patient", the resulting `bookingAccessToken` is accepted by `GET /api/tenants/{id}/appointments/staff-public-keys`, which returns the attacker-controlled keys alongside any legitimate ones. A new appointment encrypts its tunnel key with ML-KEM to all listed recipients, so the attacker becomes a co-recipient of the encryption and can decapsulate the tunnel key with the matching secret. From there, all appointment payloads for that booking are decryptable. Version 1.0.4 patches the issue. |
| h2 is a pure-Python implementation of a HTTP/2 protocol stack. Versions up to and including 4.4.0 accept request header blocks containing more than one Host header, and forward every Host header to the consuming application. Where the consumer downgrades HTTP/2 to HTTP/1.1, the resulting request carries two Host header lines, providing a request smuggling primitive. This issue is fixed in version 4.4.1. |
| Improper verification of cryptographic signature in Microsoft 365 Admin Center allows an unauthorized attacker to elevate privileges over a network. |
| The Stream plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 4.2.0. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to access all Stream activity records via the Heartbeat API. |
| A flaw was found in the libXfont2 font-server client. This heap buffer overflow vulnerability allows a malicious font server to send specially crafted glyph data. The fs_read_glyphs() function fails to properly validate the total size of the incoming data, leading to an overwrite of memory beyond the intended buffer. If the X server runs as a privileged user, this could result in privilege escalation, allowing an attacker to gain higher access. If the X server runs as an unprivileged user, it could lead to a denial of service, causing the system to crash. |
| A flaw was found in the libXfont2 font-server client. A remote attacker, by operating a malicious font server, could exploit an out-of-bounds read/write vulnerability. This occurs because the client incorrectly handles font data, leading to an out-of-bounds memory access. This can lead to privilege escalation if the X server runs with root privileges, or a denial of service (crash) if it runs as an unprivileged user. |
| A flaw was found in hypershift-addon-operator. A hub-cluster administrator with write access to the hypershift-operator-install-flags ConfigMap can inject malicious command-line arguments into the privileged install Job. This vulnerability, known as argument injection, allows the attacker to pull arbitrary container images and gain full administrative control (cluster-admin code execution) on managed spoke clusters. |
| Heap-based buffer overflow in Microsoft Windows Media Foundation allows an unauthorized attacker to execute code over a network. |
| Improper access control in Extensible Storage Engine (ESENT) allows an authorized attacker to elevate privileges locally. |
| Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Routing and Remote Access Service (RRAS) allows an authorized attacker to elevate privileges locally. |
| Use of uninitialized resource in Windows RDP allows an authorized attacker to disclose information over a network. |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Runtime allows an authorized attacker to elevate privileges locally. |
| Out-of-bounds read in Windows USB Audio Class driver (usbaudio.sys) allows an unauthorized attacker to disclose information with a physical attack. |
| Heap-based buffer overflow in Windows Resilient File System (ReFS) allows an unauthorized attacker to execute code locally. |
| Heap-based buffer overflow in Windows Bluetooth Service allows an authorized attacker to elevate privileges locally. |
| Use of uninitialized resource in Windows RDP allows an unauthorized attacker to disclose information over a network. |
