CVE-2026-91908
Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Improper Verification of Cryptographic Signature vulnerability. A high priv
CVSS
5.7
Medium
EPSS
—
KEV
—
Exploit Today
—
0-100
Published: Nov 2, 2026 · Last modified: Nov 2, 2026 · CWE-347
Not enough EPSS history yet.
Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Improper Verification of Cryptographic Signature vulnerability. A high privileged attacker with adjacent network access could potentially exploit this vulnerability, leading to Code execution.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1204597.4 HIG—
———python-jose through 3.5.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge JWTs because HMACKey and CryptographyHMACKey accept zero-length HMAC secrets. When an application's HS256/HS384/HS512 verification key resolves to empty, such as an oct JWK with empty k, attackers can forge tokens with arbitrary claims that jwt.decode accepts.4hCVE-2026-919056.4 MED—
———Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Improper Verification of Cryptographic Signature vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Filesystem access for attacker.3hCVE-2026-1175494.2 MED—
——0@fastify/secure-session is a session plugin for Fastify that stores an encrypted session in a cookie. In versions 7.5.0 through 8.4.1, when the plugin is configured with the signed cookie option, it calls the cookie unsign routine but, when the signature check reports the value as invalid, still passes the original cookie value to the session decoder, so a session whose signature did not validate is decrypted anyway. The practical effect appears when an application supplies the cookie signing secret independently of the session encryption key and rotates only the signing secret to retire existing sessions while keeping the encryption key active, because a holder of an old session cookie can strip the now obsolete signature and keep using the session. The attacker must already possess an unexpired encrypted session cookie and needs neither secret, and cannot forge session data, extend expiry, or survive rotation of the encryption key. The issue is fixed in @fastify/secure-session 8.4.2, which no longer decodes the session when the signed cookie option is set and the signature check fails, and users should upgrade to 8.4.2 or later. As a workaround, rotate the session encryption key rather than relying on rotation of the cookie signing secret alone.2hCVE-2026-116474—3.1%
——1The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance in every repository where they appear, including pull requests to repositories the user cannot write to. The impact is limited to the displayed signature status: enforcement such as required signed commits only checks that a signature is verified and is unaffected, and no access is gained. The `/api/v1/user` routes now reject system users.1dCVE-2026-631828.1 HIG4.3%
——1LightSAML implements SAML 2.0 data model classes, XML serialization and deserialization, XML security, certificate support, and message bindings. Prior to 4.7.1 and 5.0.1, LightSAML and xmlseclibs disagree about which assertion an inbound SAML signature covers. `Response::deserialize` uses `manyElementsFromXml` to collect only direct-child `saml:Assertion` elements of `samlp:Response`, and `AssertionSignatureValidatorAction` validates their `ds:Signature` using an out-of-band trusted IdP credential resolved by Issuer, not a key from the document. `XMLSecurityDSig::validateReference()` removes the enveloped signature from the shared DOM, but `processRefNode()` resolves `Reference URI="#id"` document-wide through an XPath of the form `//*[@Id]` and takes `item(0)`, which need not be the assertion whose claims LightSAML consumes. An attacker who has captured one genuinely signed assertion, such as an earlier login response, can place its signature-stripped bytes earlier in `samlp:Extensions` and present a forged direct-child assertion with the same ID and copied genuine signature. Validation then covers the hidden genuine bytes while LightSAML surfaces unsigned attacker-controlled `Subject/NameID`, `Conditions`, and `Attributes`, enabling authentication bypass or privilege escalation even when signature validation is required. The behavior was confirmed in versions 5.0.0 and 4.6.1. This issue is fixed in versions 4.7.1 and 5.0.1.3dCVE-2026-465607.5 HIG8.2%
——2Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, the `RADIUS` authentication module opens an unconnected datagram socket and trusts the first UDP datagram received on the client source port. The receive path does not verify the source IP and port, match the response identifier to the outstanding request, or verify the RFC 2865 `Response Authenticator`; the RFC 2869 `Message-Authenticator` is neither sent nor required. Any non-Reject/non-Challenge packet is treated as success. On a deployment with a `RADIUS` module instance enabled on a login chain, an unauthenticated network attacker can race the real server on-path or spray forged `Access-Accept` packets off-path and obtain a session for any `RADIUS`-mapped username without knowing the shared secret. Unlike CVE-2024-3596, exploitation requires no MD5 chosen-prefix forgery because no response authenticator is checked. The resulting session carries the impersonated principal's privileges. This issue is fixed in version 16.1.1.3d