| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insufficient verification of data authenticity may allow a local attacker to bypass Secure Debug Unlock (SDU), potentially resulting in unauthorized debug access. |
| If an attacker was able to perform a man-in-the-middle attack on an SMTP or POP3 server connection using STARTTLS, the attacker could inject server responses before the TLS handshake completed. Thunderbird would process these responses after the handshake, as if they had been received from the server over the encrypted connection. This could be used to make Thunderbird report a different outcome for sending or fetching mail, and to show attacker-controlled text in error messages. The encrypted connection itself was not compromised, and credentials were not exposed. Connections using SSL/TLS instead of STARTTLS were not affected. This vulnerability was fixed in Thunderbird 160 and Thunderbird 153.7. |
| A origin validation error vulnerability in Fortinet FortiClientMac 7.4.0 through 7.4.7, FortiClientWindows 7.4.0 through 7.4.7, FortiClientWindows 7.2.0 through 7.2.14, FortiClientWindowsPAM 7.4.7, FortiClientWindowsPAM 7.2.14 may allow an unauthorized remote attacker to execute unauthorized code or commands. Successful exploitation requires interaction with the victim. |
| Improper verification of cryptographic signature in Windows Installer allows an unauthorized attacker to bypass a security feature over a network. |
| Improper state validation in ANGLE in Google Chrome on on Windows prior to 157.0.8103.78 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Missing authorization in V8 in Google Chrome prior to 157.0.8103.78 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Missing authorization in V8 in Google Chrome prior to 157.0.8103.78 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Improper input validation in Core in Google Chrome on on Android prior to 157.0.8103.78 allowed a local attacker to bypass web origin policy via a co-installed app. (Chromium security severity: High) |
| Missing authorization in ImageCapture in Google Chrome prior to 157.0.8103.78 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Incorrect authorization in Layout in Google Chrome prior to 157.0.8103.78 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Zipline 4.3.2 before 4.8.0 contains a rate limit bypass vulnerability that allows unauthenticated attackers to evade throttling by spoofing X-Forwarded-For headers when core.trustProxy is enabled. Attackers can send a different X-Forwarded-For value per request to obtain fresh rate-limit buckets, enabling unlimited guessing of login passwords, TOTP codes, and file and URL passwords. |
| The ePayco Payment Gateway for WooCommerce WordPress plugin before 8.4.7 does not properly verify the authenticity of payment confirmation requests, allowing unauthenticated attackers to mark orders as paid without a valid gateway signature. |
| Helio is an MCP proxy that sits between AI agents and the tools they use. Prior to version 0.8.0, the dashboard sideband (default 127.0.0.1:3100) validated CORS request origins by matching the hostname against a private-network string prefix (10., 172.16.–172.31., 192.168.) rather than validating an IP address. A public DNS name such as 192.168.attacker.com, 10.evil.io, or 172.16.pwn.example also satisfies that prefix, so the proxy echoed the attacker origin in Access-Control-Allow-Origin. This issue has been patched in version 0.8.0. |
| Origin validation error in SQL Server allows an authorized attacker to elevate privileges over a network. |
| Generation of Predictable Numbers or Identifiers vulnerability in Erlang/OTP kernel (inet_res, inet_db modules) allows DNS Cache Poisoning.
The built-in DNS resolver (inet_res) uses a sequential, process-global 16-bit transaction ID for UDP queries and does not implement source port randomization. Response validation relies almost entirely on this ID, making DNS cache poisoning practical for an attacker who can observe one query or predict the next ID. This conflicts with RFC 5452 recommendations for mitigating forged DNS answers.
inet_res is intended for use in trusted network environments and with trusted recursive resolvers. Earlier documentation did not clearly state this deployment assumption, which could lead users to deploy the resolver in environments where spoofed DNS responses are possible.
This vulnerability is associated with program files lib/kernel/src/inet_db.erl and lib/kernel/src/inet_res.erl.
This issue affects OTP from OTP 17.0 before OTP 26.2.5.19, OTP 27.3.4.10, and OTP 28.4.2, corresponding to kernel from 3.0 before 9.2.4.11, 10.2.7.4, and 10.6.2. |
| Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows OCSP designated-responder authorization bypass via missing signature verification.
The OCSP response validation in public_key:pkix_ocsp_validate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid.
This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the public_key:pkix_ocsp_validate/5 API directly are also affected, with impact depending on usage context.
This vulnerability is associated with program files lib/public_key/src/pubkey_ocsp.erl and program routines pubkey_ocsp:is_authorized_responder/3.
This issue affects OTP from OTP 27.0 before OTP 27.3.4.10 and OTP 28.4.2, corresponding to public_key from 1.16 before 1.17.1.2 and 1.20.3, and ssl from 11.2 before 11.2.12.7 and 11.5.4. |
| Origin Validation Error vulnerability in Apache XML Graphics Batik: the external resource same-origin check does not compare the URL protocol
This issue affects Apache XML Graphics Batik: through 1.19.
Users are recommended to upgrade to version 1.20, which fixes the issue. |
| Improper verification of cryptographic signature in Windows Remote Procedure Call Runtime allows an unauthorized attacker to execute code over a network. |
| SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.7, 11.4.7, and 12.0.10, SAML.verifySamlResponseSignature calls OpenSAML SignatureValidator.validate without first applying SAMLSignatureProfileValidator. The Core can therefore accept a cryptographically valid signature that references a different XML element from the Response or Assertion whose NameID and attributes are used for authentication. An ordinary user of the configured identity provider can move a genuinely signed element elsewhere in the document while supplying an attacker-authored identity-bearing element, causing XML Signature Wrapping authentication as another IdP user. Both response-level and assertion-level signing paths are affected, and SP-initiated login remains reachable without enabling allowIDPInitiatedLogin. This issue is fixed in versions 11.3.7, 11.4.7, and 12.0.10. |
| SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, SAML.handleCallback does not consume RelayState, record assertion identifiers, or enforce Response.InResponseTo. In the SP-initiated flow, an attacker who obtains a legitimately issued, still-valid SAML response and its matching RelayState can resubmit the pair to /recipe/saml/callback before the assertion's NotOnOrAfter time; in the IdP-initiated flow, the assertion can be replayed without RelayState. The missing Response.InResponseTo check also permits an in-progress login to be completed with an assertion for a different identity and fails to enforce allowIDPInitiatedLogin=false. The callback does not validate Destination or SubjectConfirmationData Recipient and NotOnOrAfter, and each accepted callback mints a fresh, independently redeemable authorization code carrying the captured user's identity. This issue is fixed in versions 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1. |
