| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Gitea versions from 1.5.0 before 1.26.3 have a TOTP single-use enforcement defect that allows a valid TOTP code to be accepted more than once across web two-factor authentication flows and the Basic Auth X-Gitea-OTP path. |
| Gitea versions before 1.25.5 do not consistently enforce OAuth2 authorization code expiry and single-use behavior during token exchange. |
| NodeBB does not bind the claimed author of an inbound ActivityPub object to the authenticated remote actor. The inbound middleware verifies the HTTP-signature actor and checks the origin of object.id, but never validates that attributedTo corresponds to the sender. In the object mock, attributedTo is used directly as a uid, and actors.assert silently ignores numeric identifiers (filtering them out without re-deriving the uid), so a federated remote actor can set attributedTo to a bare numeric value such as 1 and have the resulting post or private message created with that local uid as author, including the administrator account. This lets a remote attacker forge posts and direct messages attributed to arbitrary local users. Requires the ActivityPub/federation feature to be enabled. |
| Improper certificate validation vulnerability in B&R Industrial Automation GmbH APROL.
This issue affects APROL: before R 4.4-01P5. |
| Authentication Bypass by Spoofing vulnerability in Apache IoTDB.
Certain Thrift RPC query handlers lack strict validation of the sessionId
parameter. An attacker can construct requests with a forged sessionId and,
without performing openSession authentication, receive valid query results.
This allows authentication bypass and unauthorized reading of time-series
data.
This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.
Users are recommended to upgrade to version 2.0.8, which fixes the issue. |
| A vulnerability exists where a new transfer that uses STARTTLS to upgrade the
connection might reuse an existing live connection even though the TLS
configuration mismatches so it should not. |
| In this scenario, libcurl first uses a proper HTTP/3 server for the initial
transfers, and when it makes a second transfer to the same site it has been
replaced by the attacker's impostor machine - without a valid certificate.
When libcurl returns to the hostname the second time with a cached SSL session
(`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the
`CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might
send off the second request's bytes on that new connection *before* enforcing
the certificate verification failure. Potentially leaking sensitive
information. |
| The silent Just-In-Time (JIT) provisioning feature in federated authentication implementations fails to properly segregate user roles during account creation when a federated user shares a username with a local user. This allows the provisioning process to overwrite existing roles of local users with roles assigned to the federated user.
Exploitation requires a federated identity provider (IDP) with silent JIT provisioning enabled and an attacker's knowledge of a local user's username. When these conditions are met, a malicious individual can leverage the JIT provisioning process to modify the roles of local users. The overwritten roles are limited to those defined within the federated IDP, typically granting minimal access rights unless explicitly configured otherwise by the federated IDP administrator. |
| Improper certificate validation and a time-of-check time-of-use (TOCTOU) race condition in the PrivilegedHelperTool XPC service in Cato Client before v.5.13.1 on macOS allows a local authenticated attacker to escalate privileges to root via a self-signed certificate that bypasses the XPC caller verification and a symlink swap during package installation. |
| A vulnerability was discovered on Stormshield Network Security 4.3.0 to 4.3.41 (included), 4.4.0 to 4.8.15 (included) , 5.0.2 EA to 5.0.5 (included)
A revoked client certificate can still be used to authenticate to the captive‑admin portal, allowing an attacker who possesses the revoked certificate to gain administrative access. |
| FUXA versions 1.3.1 and prior contain an authentication bypass vulnerability via dot-segment path normalization in the REST API. The API router fails to normalize dot-segment sequences before applying authentication middleware, allowing unauthenticated requests to access protected endpoints by prefixing paths with dot-segments such as /api/./users, /api/./roles, and /api/project/../users. These requests bypass authentication checks and return sensitive user and role data without credentials. |
| A SAML authentication replay vulnerability in Rancher's Assertion
Consumer Service (ACS) handler did not enforce
one-time use of SAML assertion, potentially allowing person in the middle attacks against Rancher, affecting Rancher 2.14.0 before 2.14.3, |
| Woodpecker before 3.15.0 matches the ApprovalAllowedUsers bypass list against pipeline.Author. For the GitLab forge driver, pipeline.Author is populated from the git commit author name (commit.author.name) carried in the webhook payload, which is attacker-controlled and not verified by GitLab. A user who can open a merge request from a fork can set the commit author name to match an entry in ApprovalAllowedUsers, causing needsApproval to return false so the pipeline runs without the required approval. This defeats the fork-approval security boundary and allows execution of attacker-controlled pipeline steps on a Woodpecker agent and exfiltration of CI secrets exposed to the run. Other built-in forge drivers (Gitea, Forgejo, GitHub, Bitbucket) derive pipeline.Author from the forge-validated sender/actor identity and are not affected. |
| Improper Authentication vulnerability in Apache Tomcat allowed a replay attack against the EncryptionInterceptor in the cluster component.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.22, from 10.1.0-M1 through 10.1.55, from 9.0.13 through 9.0.18, from 8.5.38 through 8.5.100, from 7.0.100 through 7.0.109.
Users are recommended to upgrade to version 11.0.23, 10.1.56, 9.0.119, which fixes the issue. |
| A flaw was found in Podman. The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry. This issue results in a Man In The Middle attack. |
| A heap-buffer-overread vulnerability was found in GnuTLS in how it handles the Certificate Transparency (CT) Signed Certificate Timestamp (SCT) extension during X.509 certificate parsing. This flaw allows a malicious user to create a certificate containing a malformed SCT extension (OID 1.3.6.1.4.1.11129.2.4.2) that contains sensitive data. This issue leads to the exposure of confidential information when GnuTLS verifies certificates from certain websites when the certificate (SCT) is not checked correctly. |
| A flaw in Node.js TLS host verification can cause an attacker to bypass certification validation.
This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**. |
| Certificates with wildcard DNS SANs (e.g. *.example.com) bypassed CA name-constraint checks. A certificate with a wildcard DNS SAN that should be rejected by the issuing CA's permitted/excluded DNS name constraints could be accepted. |
| X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts. |
| Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all. |
