Septembre 2026

wolfSSL · Wolfssl wolfssl

When an application enables both OCSP and CRL revocation checking on one WOLFSSL_CTX or certificate manager, wolfSSL skips the CRL check for any peer certificate that carries no Authority Information Access OCSP URL, and accepts a certificate the loaded CRL lists as revoked. The soft-fail policy for a missing responder collapses the OCSP result onto success before the code decides whether the CRL fallback is still needed, so "no responder exists" becomes indistinguishable from "the responder answered good". Affected builds define both HAVE_OCSP and HAVE_CRL: --enable-ocsp --enable-crl directly, and implicitly --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-lighty, --enable-wpas, --enable-strongswan, --enable-mosquitto, --enable-jni, --enable-openvpn and --enable-krb. An application is affected only if it calls both wolfSSL_CTX_EnableOCSP() (or wolfSSL_EnableOCSP() / wolfSSL_CertManagerEnableOCSP()) and wolfSSL_CTX_EnableCRL() (or the equivalents) with a CRL loaded; an application that uses OCSP stapling alone through wolfSSL_CTX_EnableOCSPStapling() is not affected, because that sets up a separate OCSP instance. The defect sits in ProcessPeerCerts() and is reachable over TLS 1.0 through TLS 1.3 and DTLS, both on a client verifying a server certificate and on a server verifying a client certificate under mutual or post-handshake authentication. When the skipped check falls on a chain certificate rather than the leaf, the unchecked intermediate is promoted into the certificate manager and stays a trusted signer for every later connection on that context, so an affected long-running process needs its WOLFSSL_CTX torn down and not only its library replaced. All wolfSSL versions from 5.9.2 and earlier are affected; on versions 5.9.1 and 5.9.2 the WOLFSSL_OCSP_CHECKALL configuration fails closed with OCSP_NEED_URL, which leaves wolfSSL_CTX_EnableOCSP() without CHECKALL as the exposed configuration on 5.9.2.

wolfSSL · Wolfssl wolfssl

Without NO_SESSION_CACHE_REF, wolfSSL_get_session() does not return a session object but a ClientSession reference of the form {row, index, hash(sessionID)} into the process-global SessionCache, and ClientSessionToSession() validates it against that hash alone. Because the TLS 1.2 session ID is chosen by the server and sent in clear, AddSessionToCache() matches any other server's session on the same ID and overwrites the client-side entry with that server's master secret, cipher suite and version, while the handle continues to resolve; nothing on the write path compares the peer, the application's server ID or the WOLFSSL_CTX. Resuming through the handle then produces an abbreviated handshake in which no Certificate message is sent, so neither chain verification nor wolfSSL_check_domain_name() runs, and the attacker is accepted as the original server for the whole of that connection. Affected builds are those leaving NO_SESSION_CACHE_REF, NO_SESSION_CACHE, NO_CLIENT_CACHE and TITAN_SESSION_CACHE all undefined, which includes a plain ./configure, --enable-opensslextra and --enable-opensslall; fifteen integration options define NO_SESSION_CACHE_REF and are therefore not affected, among them --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-wpas and the rest of the OPENSSL_COMPATIBLE_DEFAULTS family, and --enable-leanpsk, --enable-leantls, --enable-lowresource and --enable-tinytls13 disable the cache outright. The application must use the legacy reference flow, wolfSSL_get_session() or SSL_get_session() followed by wolfSSL_set_session(); wolfSSL_get1_session() returns the session object itself and is not affected, nor are wolfSSL_SetServerID() lookups. Only TLS 1.2 and below and DTLS 1.2 and below are reachable, since TLS 1.3 and ticket resumption with an empty ServerHello session ID both use a client-chosen cache key. The poisoned entry lives in the process-global cache, so it crosses WOLFSSL_CTX boundaries and persists until the entry is evicted or the session times out, 500 seconds by default. Releases v5.3.0 through v5.9.2 are affected; the fix adds a per-write generation counter to the cache and raises WOLFSSL_CACHE_VERSION from 2 to 3, so a cache persisted by an older build is rejected by a fixed one.

PHP Group PHP · Php php

When the http:// stream wrapper follows a redirect it forwards the user-supplied Authorization, Cookie and Proxy-Authorization headers unchanged, even when the redirect target is a different host, a different port, or a downgrade from HTTPS to HTTP. A server that can steer a redirect therefore receives credentials that were only meant for the original origin. This is the same class of issue that libcurl fixed in 7.58.0 ( CVE-2018-1000007 https://github.com/advisories/GHSA-g7x2-hrfp-pv5f ).

Dromara mayfly-go

A security vulnerability has been detected in Dromara mayfly-go up to 1.11.5. The affected element is an unknown function of the file server/internal/ai/api/ai.go of the component AI Assistant. The manipulation leads to missing authorization. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. The identifier of the patch is 74bcb926eb4f5f94e7681144d7bf2168a0ec7cde. Applying a patch is the recommended action to fix this issue. The whitelist bypass is one-token wide. Any compound command containing curl, wget or sed auto-runs without approval; approval is granted by the same session user (self-approval). This issue got fixed with a silent patch.

tornadoweb tornado

Tornado before 6.5.7 contains a credential leak vulnerability in CurlAsyncHTTPClient where pycurl handles are reused across requests without proper state clearing. Attackers can obtain sensitive credentials by issuing requests through the same client instance, allowing TLS certificates or proxy authentication to persist across unintended requests.

tornadoweb tornado

Tornado before 6.4.1 contains a CRLF injection vulnerability in CurlAsyncHTTPClient that fails to reject carriage return and line feed characters in request headers. Attackers can inject CRLF sequences into header values to inject arbitrary headers or construct entirely new HTTP requests.

pyload

pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev101, is_global_address in src/pyload/core/utils/web/check.py relies on Python's global-address classification without examining IPv4 destinations embedded in 6to4 or NAT64 IPv6 addresses. A low-privileged user can submit an IPv6 literal through parse_urls to the pre-resolution is_global_host guard. Because host_to_ip is pinned to AF_INET, that guard does not evaluate a hostname's AAAA result. Separately, curl resolves hostnames before the pycurl PREREQFUNC in src/pyload/core/network/http/http_request.py applies the same vulnerable is_global_address check to the actual connection address, so a transition-form AAAA result can be permitted even when it terminates at an embedded loopback, private, CGNAT, or link-local IPv4 address. Exploitation requires the pyLoad host to route the applicable transition mechanism, including 6to4 on affected Python 3.9 through 3.11 deployments or NAT64 on a network with a NAT64 gateway. Successful exploitation can enable internal-network reconnaissance, timing-based confirmation, limited service disruption, or cloud metadata disclosure where the wrapped address is routable. This issue is fixed in version 0.5.0b3.dev101.

kagisearch smallweb

A security flaw has been discovered in kagisearch smallweb up to 0ecb9c48edbf98dc7e934b54fbac43869e64b4cf. The affected element is the function index of the file app/sw.py of the component Query String Rendering. Performing a manipulation of the argument qs results in cross site scripting. The attack is possible to be carried out remotely. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The patch is named 00b68144e583f20a6b67e29cf01bc07f57979ffb. It is recommended to apply a patch to fix this issue. Exploitability requires a raw HTTP request carrying unencoded double-quote characters in the query string - Werkzeug's request.query_string returns the raw request-target, and ordinary browsers percent-encode " as %22, so the payload only lands via netcat/curl-style raw sockets.

Concrete CMS · Concretecms concrete cms

Concrete CMS versions 9.5.0 through 9.5.2 are vulnerable to Open Redirect via the rcURL parameter. An attacker can craft a single link on the site's own domain that sends a user to an arbitrary external site immediately after authentication, facilitating phishing and credential theft. The same handling is present in the registration flow, giving a second entry point on sites with registration enabled. Concrete CMS versions prior to 9.5.0 do not include the rcURL parameter or this allowlist and are not affected. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.3 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Michal M. for reporting.

espocrm

EspoCRM before 10.0.4 is vulnerable to server-side request forgery. HostCheck::ipAddressIsNotInternal(), which validates outbound URLs to block requests to internal/private IP addresses, strips ::ffff: (IPv4-mapped IPv6) prefixes but does not recognize IPv6 transition addresses that embed private IPv4 addresses: NAT64 (64:ff9b::), 6to4 (2002::), and Teredo (2001:0000::). An attacker who controls a domain with AAAA records pointing to such transition addresses can bypass both the internal-host validation and the CURLOPT_RESOLVE IP-pinning check, causing EspoCRM to issue outbound requests to internal network services. Affected paths include POST /Attachment/fromImageUrl, reachable by any authenticated user with attachment access, and outbound webhook delivery, which requires an admin or API user.