Export limit exceeded: 420535 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 420535 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3221 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-47825 | 2 Spring, Vmware | 2 Spring Cloud Gateway, Spring Cloud Gateway | 2026-10-01 | 8.6 High |
| Spring Cloud Gateway Server forwards the X-Forwarded-For and Forwarded headers from untrusted proxies in certain configuration scenarios. This affects both the WebMVC and WebFlux Gateway Servers. Affected versions: Spring Cloud Gateway 3.1.x (fix 3.1.13). Spring Cloud Gateway 4.1.x (fix 4.1.13). Spring Cloud Gateway 4.2.x (fix 4.2.9). Spring Cloud Gateway 4.3.x (fix 4.3.5). Spring Cloud Gateway 5.0.x (fix 5.0.2). | ||||
| CVE-2026-87004 | 1 Quenary | 1 Tugtainer | 2026-10-01 | 8.1 High |
| Tugtainer is a self-hosted app for automating updates of Docker containers. Prior to version 1.31.3, when the OIDC login flow completes, backend/modules/auth/providers/auth_oidc_provider.py decodes the id_token returned by the identity provider's token endpoint using jose.jwt.get_unverified_claims() instead of jwt.decode(). This skips signature verification, audience (aud) validation, issuer (iss) validation, and expiry (exp) checking entirely. The extracted claims (email/sub/preferred_username) are then used directly as the user_id for the resulting Tugtainer session. This issue has been patched in version 1.31.3. | ||||
| CVE-2026-16272 | 1 Paytr | 1 Paytr Virtual Pos Iframe Api (v9x) Whmcs Module | 2026-10-01 | 9.1 Critical |
| Use of less trusted source vulnerability in PayTR Payment and Electronic Money Institution Inc. PayTR Virtual Pos iFrame API WHMCS Module allows Exploitation of Trusted Identifiers. This issue affects PayTR Virtual Pos iFrame API WHMCS Module: from v9.0.0 before v9.0.3. | ||||
| CVE-2026-102312 | 1 Google | 2 Android, Chrome | 2026-09-30 | 4.3 Medium |
| UI misrepresentation in Omnibox in Google Chrome on on Android prior to 154.0.8037.92 allowed a remote attacker to spoof address bar via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-47554 | 1 Nvidia | 5 Geforce, Nvs, Quadro and 2 more | 2026-09-30 | 7.1 High |
| NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer where improper verification of cryptographic signatures may cause signature verification to be bypassed under memory pressure. A successful exploit of this vulnerability might lead to denial of service and data tampering. | ||||
| CVE-2026-18825 | 1 Antono | 1 Connect-cors | 2026-09-30 | N/A |
| An Origin Validation Error in the middleware of the connect-xcors npm package allows an attacker to bypass origin verification and perform a cross domain authenticated request. | ||||
| CVE-2026-102310 | 1 Google | 1 Chrome | 2026-09-30 | 6.5 Medium |
| Missing authorization in Payments in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-100293 | 1 Anjvision | 1 Yssd-rtmp-h5 | 2026-09-30 | 8.8 High |
| In Anjvision YSSD‑RTMP‑H5 firmware version 3.3.2.4, both the local and cloud update mechanisms apply new firmware without any cryptographic verification, relying only on basic hashing. This design allows an attacker who can reach the update routine to introduce untrusted firmware images that the device will accept as valid. | ||||
| CVE-2026-102878 | 1 Hangwin | 1 Mcp-chrome-bridge | 2026-09-30 | 8.1 High |
| mcp-chrome-bridge through 1.0.31 contains an origin validation error in the native-server HTTP API that allows attackers to bypass CORS restrictions. Attackers can craft malicious web pages that make cross-origin requests to the local server and invoke browser automation tools including script execution, page content reading, and screenshot capture. | ||||
| CVE-2026-91191 | 1 Lantronix | 1 G520 Series | 2026-09-30 | 7.5 High |
| The device's update mechanism includes conditions that allow unauthorized software packages to be accepted as authentic. During the boot process, the stock done function disables signature verification in the OPKG configuration before restoring optional packages from a writable, unsigned feed. Separately, the publicly distributed SDK contains the production private key whose corresponding public key is trusted by both stable and beta firmware builds. Either issue undermines package authenticity, and together they allow an attacker to provide packages that appear valid to the system. Even if signature enforcement is restored, the exposed production key enables an attacker to generate signatures that the device will continue to trust. An attacker who can supply a malicious package may be able to execute arbitrary code with root privileges during installation. | ||||
| CVE-2026-13720 | 1 Grafana | 2 Grafana, Grafana Enterprise | 2026-09-30 | 5.4 Medium |
| An Editor can set file-provisioning metadata (the grafana.app/managedBy, grafana.app/managerId and grafana.app/sourcePath annotations) when creating a dashboard through the dashboard API, because these fields were stored without an authorization check. The dashboard then appears file-provisioned, and administrators can no longer update or delete it through Grafana. The impact is limited to the same organization and no data is exposed. | ||||
| CVE-2026-102320 | 1 Google | 1 Chrome | 2026-09-30 | 6.5 Medium |
| Missing authorization in CORS in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-102330 | 1 Google | 1 Chrome | 2026-09-30 | 6.5 Medium |
| Incorrect authorization in SiteIsolation in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-100653 | 1 Vllm | 1 Vllm | 2026-09-30 | 6.5 Medium |
| vLLM is an inference and serving engine for large language models. In versions from 0.22.1 through 0.28.0, the operator-supplied model revision pin (--revision / --code-revision) is not propagated to several Hugging Face artifact loads for the FunAudioChat and Tarsier2 architectures: the WhisperFeatureExtractor and speech_tokenizer PreTrainedTokenizerFast loads in vllm/model_executor/models/funaudiochat.py and the Qwen2VLConfig.from_pretrained call used by Tarsier2ProcessingInfo in vllm/model_executor/models/qwen2_vl.py. As a result, deployments pinned to a reviewed revision still resolve these behavior-affecting processor, tokenizer, and config artifacts from the repository's default revision, so a later change to the upstream default branch can alter audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. This is a supply-chain integrity and reproducibility failure for pinned deployments; it is residual to the earlier fix tracked as GHSA-3ww4-5jv9-j5gm / CVE-2026-47155 and does not constitute remote code execution or a trust_remote_code=False bypass. The issue is fixed in version 0.28.0. | ||||
| CVE-2026-95317 | 1 Google | 1 Chrome | 2026-09-30 | 3.1 Low |
| Incorrect authorization in MediaCapture in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to obtain cross-origin data via a crafted Chrome extension. (Chromium security severity: Medium) | ||||
| CVE-2026-95352 | 1 Google | 1 Chrome | 2026-09-30 | 5.4 Medium |
| Incorrect authorization in DevTools in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted Chrome extension. (Chromium security severity: Low) | ||||
| CVE-2026-16745 | 2 Red Hat, Redhat | 2 Red Hat Openshift Ai (rhoai), Openshift Ai | 2026-09-30 | 8.8 High |
| A flaw was found in odh-dashboard, the web console component of Red Hat OpenShift AI (RHOAI). Due to incorrect network binding, a malicious actor within the cluster can bypass authentication and impersonate any user by providing an arbitrary access token. This allows an attacker to gain unauthorized access to the Kubernetes API, potentially leading to arbitrary code execution, privilege escalation, or information disclosure. | ||||
| CVE-2025-71422 | 1 Edgelesssys | 1 Contrast | 2026-09-30 | 5.7 Medium |
| Contrast is a Kubernetes runtime for confidential containers. In versions before 1.12.1, the secure persistent volume feature is vulnerable to a malicious host supplying a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted. Contrast v1.12.1 ships cryptsetup 2.8.1, which disables null ciphers in keyslots when the passphrase is non-empty; v1.13.0 adds detached-header validation in guest memory and integrity protection for secure persistent storage. Contrast persistent volumes were not integrity protected, so integrity impact is not considered. | ||||
| CVE-2026-102508 | 1 Apache | 1 Plc4x | 2026-09-30 | N/A |
| Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client. The defect manifests differently depending on the version: - In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password. - In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default. - In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint. Users checking only for one of these mechanisms may wrongly conclude they are unaffected. This issue affects Apache PLC4X: from 0.9.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the connection if the negotiated security policy is weaker than the configured one. | ||||
| CVE-2026-100646 | 2 B3log, Siyuan | 2 Siyuan, Siyuan | 2026-09-30 | 8.1 High |
| SiYuan is a self-hosted personal knowledge management system. In versions up to and including 3.8.3, the kernel's authentication guards (CheckAuth in kernel/model/session.go and IsSessionOriginAllowed in kernel/util/net.go) fail open when the HTTP Origin header is absent, on the incorrect assumption that any browser-initiated cross-site request carries an Origin. Because browsers omit Origin on cross-site top-level GET navigations and no-cors GET subresource loads — and the session cookie is SameSite=Lax — a single cross-site GET issued from any attacker-controlled web page is granted RoleAdministrator, both on default installations with no access-authorization code and on password-protected instances with a live session. Combined with content-type sniffing on the /api/network/proxy endpoint, which allows attacker-controlled HTML to be served under SiYuan's own origin, this permits an unauthenticated remote attacker to execute arbitrary script in the SiYuan origin (http://127.0.0.1:6806), invoke administrator APIs, and exfiltrate the persistent kernel API token. This issue is fixed in version 3.8.4. | ||||