| 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. |
| 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. |
| 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, a licensed deployment with a configured SAML client can authenticate an identity from an assertion that did not satisfy the audience check. When the identity provider uses assertion-level signing, an attacker who has a still-valid IdP-signed assertion naming the victim for any audience and the attacker's own valid assertion for the target audience can combine them because validateSamlResponseAudience accepts an audience from one assertion while extractAllClaims takes the final NameID and attributes from another; response-level signing does not expose this multi-assertion variant. Independently, an assertion from an identity provider configured for the target deployment but issued to another SuperTokens deployment using the shared default saml_sp_entity_id can satisfy the target's audience check. Successful exploitation authenticates the attacker as the victim IdP user. 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. |
| soapbar is a SOAP library for Python — client, server, and WSDL handling. Prior to version 0.13.0, verify_envelope_bsp() derived its trust anchor from the message it was verifying. It read the X.509 certificate out of the caller-untrusted wsse:BinarySecurityToken, validated only that certificate's not-before / not-after dates, and then verified the signature against that same certificate. There was no CA-chain validation, no issuer/subject allowlist, and no pinning. A successful verify_envelope_bsp() therefore proved only that the envelope was signed by whoever supplied the embedded certificate — never that it was signed by a trusted party. An attacker who mints their own certificate, signs a forged envelope, and embeds that certificate in the token passes verification. Any consumer that treats a successful BSP verification as authentication can be impersonated (signature forgery / authentication bypass). verify_envelope() (which pins a caller-supplied x509_cert) was not affected — the flaw was specific to the BSP variant whose trust anchor came from the message. This issue has been patched in version 0.13.0. |
| Authlib (v1.8.0 and below) contains a signature verification bypass vulnerability. The JsonWebSignature.deserialize_json() method accepts a JSON Serialization JWS object and returns the payload as successfully verified without checking for a signature and without requiring a cryptographic key. |
| The CatalogX WordPress plugin before 6.1.3 does not sanitise or escape content that an unauthenticated user can store before including it in the product enquiry notification email sent to the site administrator, allowing unauthenticated attackers to inject arbitrary content into that email, which is delivered when an unrelated visitor later submits a product enquiry. |
| The WP Express Checkout WordPress plugin before 2.4.9 does not verify server-side that a payment was actually completed before marking an order as paid, allowing unauthenticated users to forge a completed order without paying. |
| When independent Grafana instances share the same [rendering] renderer_token, an image renderer key issued by one instance is accepted by the others, so a user on one instance could act as the user with the same ID on another (origin validation error). This affects instances with the renderAuthJWT feature toggle enabled, the default from Grafana 13.0.0. |
