Total
397439 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-59850 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 4.3 MEDIUM |
| A flaw was found in libssh. If data packets are processed after a channel is closed, channel data callbacks can be invoked after the associated data has already been freed, leading to crashes or possible use-after-free conditions. | |||||
| CVE-2026-59848 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 5.3 MEDIUM |
| A flaw was found in libssh. A malicious SFTP server can send responses for unknown request IDs that libssh clients keep queued indefinitely, causing unbounded memory growth and client-side denial of service. | |||||
| CVE-2026-59846 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 3.9 LOW |
| A flaw was found in libssh. A malicious username expanded through %r in ProxyCommand handling can inject shell metacharacters, exposing environment variables and causing unintended shell behavior. | |||||
| CVE-2026-59845 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 5.3 MEDIUM |
| A flaw was found in libssh. When ProxyCommand is used, an unchecked fork() failure can be stored as process ID -1; during cleanup, signals may then be sent across the caller's accessible process tree, leading to local denial of service. | |||||
| CVE-2026-59844 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 6.5 MEDIUM |
| A flaw was found in libssh. A remote authenticated client can issue SSH_FXP_READ requests with an arbitrarily large length, causing a libssh SFTP server to allocate excessive memory and potentially exhaust it through repeated requests. | |||||
| CVE-2026-59843 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 6.5 MEDIUM |
| A flaw was found in libssh. A remote authenticated peer can advertise a zero maximum packet size in SSH_MSG_CHANNEL_OPEN, causing later channel writes to loop indefinitely and consume CPU, leading to denial of service. | |||||
| CVE-2025-71407 | 2026-09-01 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected as a duplicate. | |||||
| CVE-2025-71406 | 2026-09-01 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected as a duplicate. | |||||
| CVE-2025-71346 | 2026-09-01 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected as a duplicate. | |||||
| CVE-2024-58378 | 2026-09-01 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected as a duplicate. | |||||
| CVE-2024-58377 | 2026-09-01 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected as a duplicate. | |||||
| CVE-2026-67558 | 2026-09-01 | N/A | 7.4 HIGH | ||
| The Mira Android companion app v4.5.15.4 identifies the paired Mira hormone analyzer by performing a substring match against the BLE advertisement name only, with no cryptographic peripheral authentication, MAC allowlist, or bonded-identity check. An attacker could capture live session token information and inject forged hormone measurements into the victim's cloud record and clinical trend view. | |||||
| CVE-2026-68067 | 2026-09-01 | N/A | 9.8 CRITICAL | ||
| The login endpoint on the Mira cloud API accepts any format-valid string in the password field and returns a live active session token for the account matching the supplied email address. An attacker could use an email address to control cloud accounts and access hormone record information and account settings. | |||||
| CVE-2026-66832 | 2026-09-01 | N/A | 6.5 MEDIUM | ||
| When the Mira Android app opens in-app WebView content (e.g., shop redirect flows), the user's live session token is appended to the URL as a query string parameter, and a persistent user identifier is included in the WebView's User-Agent header. Both are then transmitted to third-party web properties, referrer logs, and any JavaScript running in the WebView context. | |||||
| CVE-2026-64934 | 2026-09-01 | N/A | 4.3 MEDIUM | ||
| The Mira cloud API accepts the firmware version reported by the companion app as authoritative for a given device, without independently attesting the version from the device itself. An authenticated attacker could submit arbitrary firmware version strings for their own device, allowing them to evade vendor-side vulnerable-fleet analytics, suppress security update prompts to the user, and misrepresent patch-adoption metrics. | |||||
| CVE-2026-67568 | 2026-09-01 | N/A | 9.1 CRITICAL | ||
| The distributed Mira Android APK v4.5.15.4 allows an attacker read/write access to reproductive health profiles from internet connected hosts, which could result in forgery, deletion, or destruction of health information. | |||||
| CVE-2026-66340 | 2026-09-01 | N/A | 5.3 MEDIUM | ||
| The Mira cloud authentication endpoints do not enforce per-account rate limiting, per-IP throttling, or account lockout after repeated failed login attempts. An attacker can use brute-force methods to obtain gain access to user accounts. | |||||
| CVE-2026-81633 | 2026-09-01 | N/A | N/A | ||
| Improper Input Validation vulnerability in ash-project ash_graphql allows an unauthenticated client to crash a relay node(id: ...) query with an unhandled KeyError. AshGraphql.Graphql.Resolver.resolve_node/2 decodes the client-supplied global ID with decode_relay_id/1, which only base64-decodes the string and splits it on : without validating the type segment. The decoded type is passed straight to Map.fetch!(type_to_domain_and_resource_map, type). Because fetch! raises on a missing key, a relay ID whose type segment is a valid atom that is not a relay-exposed type aborts the resolver before its resolve/2 clauses and their rescue handlers run, so the error never becomes a GraphQL error and may expose a stacktrace. Common resource names are easy to guess. The fix uses Map.fetch/2 and returns an Invalid node id error for unknown types. This issue affects ash_graphql: from 0.27.0 before 1.11.0. | |||||
| CVE-2026-75759 | 2026-09-01 | N/A | N/A | ||
| Improper Verification of Cryptographic Signature vulnerability in erlef oidcc allows an unauthenticated attacker to impersonate an arbitrary user via an encrypted ID token or JARM response carrying no nested signature. OpenID Connect Core 1.0 section 2 requires that an encrypted ID token be signed then encrypted, with the result being a Nested JWT, and JARM processing rule 5 requires the client to check the signature unconditionally. oidcc instead accepted a JWE wrapping unsigned claims as fully validated, so anyone holding the relying party's public encryption key could mint a token with an arbitrary sub, iss, and aud without possessing the provider's signing key. In oidcc_jwt_util:verify_decrypted_token/4, a decrypted payload that is not a signed JWS fell back to parsing the plaintext claims and returning them with no verifying key. oidcc_token:int_validate_jwt/4 then matched on the JOSE structure type rather than on whether a signature had been verified, and returned success. The JARM path in oidcc_token:validate_jarm/3 is reachable through the browser front channel. UserInfo responses are not affected, because OpenID Connect Core 1.0 section 5.3.2 permits them to be encrypted without also being signed. This issue affects oidcc: from 3.2.0-beta.1 before 3.9.0. | |||||
| CVE-2026-81322 | 2026-09-01 | N/A | N/A | ||
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in ash-project ash_cloak allows anyone with access to logs, error trackers, or crash reports, or anyone who can trigger a validation error, to recover the plaintext of a field the library encrypts. AshCloak.Transformers.SetUpEncryption removes each cloaked attribute from the action's accept list and adds an action argument that carries the plaintext into the encryption change. That argument is built with sensitive?: attr.sensitive?, inheriting the flag from the source attribute, so a cloaked attribute declared without sensitive? true produces a non-sensitive argument. It is the only place the cleartext value lives, and the one place Ash will not redact: it appears verbatim in inspect(changeset), Ash.Error.Invalid and validation error messages, telemetry, :sys dumps, and error-tracker payloads. The generated encrypted attribute and decrypt calculation are already hardcoded sensitive. This issue affects ash_cloak: from 0.1.0 before 0.4.0. | |||||