| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| Flowise through 3.1.4 contains an authentication bypass vulnerability that allows unauthenticated attackers to access the OAuth2 credential refresh endpoint by exploiting prefix-based whitelist matching in the authentication middleware defined in packages/server/src/utils/constants.ts. Attackers can send a POST request to the oauth2-credential refresh route with a trailing credential identifier to bypass all authentication and authorization checks, triggering unauthorized OAuth token rotation against credentials belonging to any workspace and potentially disrupting dependent OAuth integrations. This is a bypass of CVE-2026-41273. |
| FFmpeg versions from 0.5 up to, but not including, 9.0 contain an uninitialized heap memory disclosure vulnerability in the native TIFF decoder in libavcodec/tiff.c. An attacker who can cause FFmpeg to decode a crafted TIFF file can supply a valid Deflate-compressed strip that terminates successfully after producing fewer bytes than the declared strip requires. The tiff_unpack_zlib() function allocates a heap buffer sized for the full declared strip but copies all declared rows via memcpy() regardless of how many bytes zlib actually decompressed, causing unwritten bytes that can contain stale data from prior heap allocations to be incorporated into decoded image output and potentially exposing sensitive data in persistent services. |
| 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. |
| Fedify is a TypeScript library for building federated server apps powered by ActivityPub. From version 1.2.0 through the affected 1.9, 1.10, 2.0, 2.1, 2.2, and 2.3 maintenance lines, getNodeInfo() follows an attacker-controlled links[].href value from /.well-known/nodeinfo without scheme, redirect, or private-address validation, allowing requests to loopback, link-local, cloud metadata, and private-network services and returning their response bodies. This issue is fixed in versions 1.9.13, 1.10.12, 2.0.22, 2.1.18, 2.2.7, and 2.3.2. |
| 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. |
| A vulnerability was found in MZ Automation libiec61850 up to 1.6.1. The affected element is the function deleteDataSetValuesShadowBuffer of the file src/iec61850/server/mms_mapping/reporting.c of the component URCB Revalidation. The manipulation results in use after free. The attack needs to be approached locally. The exploit has been made public and could be used. Upgrading to version 1.6.2 is sufficient to fix this issue. The patch is identified as 486fd57f3aed65bb9d636ff00f9ddce2e450b168. Upgrading the affected component is advised. |
| Decidim is a participatory democracy framework. Prior to 0.30.9, from 0.31.0 before 0.31.5, and in 0.32.0.rc1 before 0.32.0.rc2, when VAPID delivery is enabled, the notification subscription flow stores a client-supplied push endpoint without validating that it belongs to an approved push service, and SendPushNotification later passes that endpoint to WebPush.payload_send, allowing an authenticated user to create stored, mostly blind server-side requests to arbitrary reachable HTTPS endpoints. This issue is fixed in versions 0.30.9, 0.31.5, and 0.32.0.rc2. |
| Nx is a monorepo solution for TypeScript and polyglot codebases. From version 20.8.0 until 22.7.7 and 23.0.2, the Nx self-hosted HTTP remote cache extracts downloaded cache artifacts without constraining where files are written. A malicious or on-path (MITM) remote cache server can return a crafted tar archive whose entries escape the cache directory and write to arbitrary locations on the machine running Nx, which can be escalated to remote code execution. Nx's default local cache and Nx Cloud are not affected; only workspaces configured to use a self-hosted remote cache are affected. This issue is fixed in versions 22.7.7 and 23.0.2. |
| A stored cross-site scripting (XSS) vulnerability exists in the management interface of WatchGuard Firebox appliances via the IPS configuration. An authenticated remote attacker with administrator privileges could exploit this vulnerability to execute arbitrary JavaScript code in the Firebox management ninterface of another management user. |
| Statamic is a Laravel and Git powered content management system (CMS). Prior to 5.74.3 and 6.24.2, the default ("automagic") form notification email rendered user-submitted values without escaping, allowing an unauthenticated form submitter to inject HTML into the notification emails sent to the configured recipients. This issue is fixed in versions 5.74.3 and 6.24.2. |
| An authenticated admin user with access to both the management WebUI and command line interface on a Firebox can enable a diagnostic debug shell by uploading a platform and version-specific diagnostic package and executing a leftover diagnostic command. |
| In versions of the Datadog Android application prior to v554-5.9.4, two Room-backed SQLite databases store sensitive content in plaintext: LocalNotificationDatabase (notification title, message, recipient, service, tags, and on-call/incident deep links) and SearchRecentDatabase (the user's full in-app search history).
Impact: Any actor able to bypass the app sandbox can read these databases in plaintext. |
| In versions of the Datadog Android application prior to v541-5.9.2, the exported launcher activity AppActivity accepts an attacker-supplied session (including OAuth tokens) from Intent extras with no permission guard, and signs the app into that session without validating it against the backend.
This requires a malicious application co-installed on a device with the Datadog app installed, and an OAuth token the attacker is willing to load into the victim's app.
Impact: A co-installed application can switch the victim's Datadog app to a session the attacker controls. This is an account-confusion issue; it does not by itself expose the victim's existing session or data. |
| In versions of the Datadog Android application prior to v545-5.9.2, the app tags Crashlytics data with the user's Datadog UUID, with no user-facing opt-out.
Impact: The Datadog user UUID and crash data are visible within Firebase Crashlytics. This UUID is not identifying outside Datadog's own systems. |
| Dinky's POST /download/uploadFromRsByLocal handler passes the caller-supplied path parameter directly to new File(path) and file.transferTo(dest) with no path validation. The route is marked @SaIgnore and /download/** is excluded from the Sa-Token interceptor, so the only guard is a header equality check against a dinkyToken value whose default (efda1551-7958-4e0f-80a8-dfd107df3e38) is hardcoded in source and shipped to every deployment. Anyone who can reach Dinky's HTTP port (8888 by default) and supplies the hardcoded token can write arbitrary files as the Dinky service account. The default Docker image runs on 8888 with no proxy or authentication and chmod 777 on /opt/dinky, so the application's own classpath, launch scripts, and static assets are writable. Demonstrated impact: overwriting /opt/dinky/config/static/index.html served attacker JavaScript to admin browsers immediately, and writing /opt/dinky/org/dinky/Dinky.class executed attacker code as the Dinky service account at the next JVM start via a classpath-shadow launched by script/bin/auto.sh. Writes are uid 9999 (flink), not root, so /etc, /root, /home, and /usr are refused. Affects Dinky v1.2.5 (the current release) and the development branch, where the code is byte-identical. |
| The WatchGuard Mobile VPN with SSL Client on Windows allows a locally authenticated non-administrative Windows user to escalate their privileges to NT AUTHORITY/SYSTEM on the Windows machine where the VPN Client is installed. |
| Contiki-NG's MQTT client parse_publish_vhdr() in os/net/app-layer/mqtt/mqtt.c sets topic_len_received=1 before checking topic_len against the 64-byte limit, so an over-length topic returns early but leaves the flag set. On the next TCP segment, tcp_input() re-invokes the parser with topic_received==0, and the persisted topic_len_received==1 skips the length-reading block containing the guard, falling through directly to a memcpy() that uses the unvalidated 16-bit topic_len as the copy length. The 65-byte topic[] destination overruns into adjacent struct fields including the payload_chunk pointer, which subsequent MQTT code dereferences, giving a compromised or attacker-controlled broker an arbitrary-pointer-write primitive. Contiki-NG's MQTT implementation has no TLS support so the connection is plaintext. Impact ranges from information disclosure and denial of service to remote code execution on embedded targets without memory protection. |
| A stored cross-site scripting (XSS) vulnerability exists in the management interface of WatchGuard Firebox appliances via the Access Portal configuration. An authenticated remote attacker with administrator privileges could exploit this vulnerability to execute arbitrary JavaScript code in the Firebox management interface of another management user. |
