CVE-2026-0392
eParakstītājs 3.0 for Windows before version 1.10.0 retrieves and executes its automatic updates over a channel that is not authenticated or
CVSS
—
Sin CVSS
EPSS
0.1%
p0
KEV
—
Exploit Today
0
0-100
Publicado: 3 ago 2026 · Última mod.: 23 oct 2026 · CWE-295 · CWE-347 · CWE-494
0.1%EPSS · 30 días0.1%
2026-10-022026-10-30
eParakstītājs 3.0 for Windows before version 1.10.0 retrieves and executes its automatic updates over a channel that is not authenticated or integrity-protected. On each launch the application fetches an update descriptor (XML) over TLS but accepts any TLS certificate (a permissive TrustManager and a HostnameVerifier that always returns true), does not verify any digital signature on the update descriptor, and does not verify the Authenticode signature or a checksum of the downloaded installer before running it. A man-in-the-middle attacker able to redirect www.eparaksts.lv can serve a crafted update descriptor pointing to an attacker-controlled executable, which the client downloads and executes, resulting in arbitrary code execution on the victim host.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1176818.0 ALT—
——0A flaw was found in konflux-ci. This vulnerability allows privilege escalation when the user interface proxy automatically disables Transport Layer Security (TLS) certificate verification for connections to internal backend services in environments lacking a default service certificate authority. Because the proxy attaches a cluster-scoped authentication token with user impersonation rights to these requests, an adjacent network attacker capable of intercepting traffic can capture the credentials to gain full administrative control of the cluster.11hCVE-2026-631828.1 ALT—
——0LightSAML 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.22hCVE-2026-465607.5 ALT—
——0Open 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.1dCVE-2026-1186979.0 CRÍ—
——0In JetBrains Toolbox App before 3.9.1 and 3.8.2; IntelliJ IDEA before 2026.3 and 2026.2.4, the jetbrainsd daemon trusted compromised intermediate certificates16hCVE-2026-112816——
——0Improper certificate validation in the HTTPS listener in Canonical LXD 4.0.14, 5.0.10, 5.21.8, 6.9 before 4.0.15, 5.0.11, 5.21.9, 6.10.1 allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster and managed virtual machines via a crafted certificate chain.16hCVE-2026-119037——
——0Business::GoCardless versions before 1.01 for Perl accept forged webhooks when a configured webhook secret is undef or empty.
signature_valid uses each configured secret as the HMAC key, and nothing rejects undef or an empty string, both of which Digest::SHA treats as an empty key. A secret read from an unset environment variable, or an empty entry in a list of rotated secrets, is used as is.
A remote attacker can sign a forged webhook with an empty key and have it accepted as sent by GoCardless.1d