| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV
(RFC 8452) mishandle the authentication of AAD (Additional Authenticated
Data) with an empty ciphertext allowing a forgery of such messages.
Impact summary: An attacker can forge empty messages with arbitrary AAD
to the victim's application using these ciphers.
AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD
modes: they accept a key, nonce, optional AAD (bytes that are authenticated
but not encrypted), and plaintext, and produces ciphertext plus a 16-byte
tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only
if the tag is verified succesfully.
In OpenSSL's provider implementation of these ciphers, the expected tag is
computed only when decryption function is invoked with non-empty data.
If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without
invocation of the ciphertext update, which can happen when the received
ciphertext length is zero, the tag is never recalculated and still holds its
all-zeros value.
When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty
ciphertext, and all-zeros tag passes authentication under any key they do not
know, single-shot. When AES-SIV is used, for mounting the attack it's
necessary for the application to reuse the decryption context without
resetting the key.
AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since
OpenSSL 3.2.
No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support
either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must
implement their own protocol and use the EVP interface. Also they must skip the
ciphertext update when a message with an empty ciphertext arrives.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as these algorithms are not FIPS approved and the affected code is
outside the OpenSSL FIPS module boundary. |
| Unauthenticated Broken Authentication in Masteriyo - LMS <= 2.1.8 versions. |
| A guessable session cookie vulnerability exists in the Web Interface functionality of GeoVision LPC2011/LPC2211 1.10. A specially crafted series of HTTP requests can lead to an authentication bypas. An attacker can bruteforce session cookies to trigger this vulnerability. |
| A flaw was found in Samba’s certificate auto-enrollment Group Policy handling. When certificate auto-enrollment is enabled, Samba may retrieve a CA certificate over an unencrypted HTTP connection and install it into the local trust store without proper verification. An attacker with the ability to intercept or redirect network traffic could exploit this behavior to supply a malicious certificate authority certificate, potentially allowing interception or spoofing of trusted communications. |
| 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). |
| User interface (ui) misrepresentation of critical information in Microsoft Exchange Server allows an unauthorized attacker to perform spoofing over a network. |
| Mastodon is a free, open-source social network server based on ActivityPub. In versions there is a missing condition in the check if remote accounts consented to be featured in a remote Collection could lead to attackers bypassing the check and faking consent. An attacker could forge the FeatureAuthorization object that is used to verify consent to be featured in a Collection and thus make it appear as if an account is allowed to be in a Collection when it actually is not. While the FeatureAuthorization must reside on the same domain as the object it is for, a check is missing to make sure said object is actually the same as in the Collection item. This allows an attacker to forge the authorization. Mastodon servers are affected only if running the main branch or nightly builds who have opted into testing the experimental "Collections" feature by setting the environment variable EXPERIMENTAL_FEATURES to a value including collections. This has been patched in version 4.6.0-beta.1. |
| Issue Summary: The PKCS#12 file processing fails to perform sufficient input
validation for files that use Password-Based Message Authentication Code 1
(PBMAC1) integrity mechanism allowing a certificate and private key forgery.
Impact Summary: An attacker impersonating a user can cause a service reading
PKCS#12 files to accept forged certificates and private keys with a 1 in 256
probability.
If a service accepting PKCS#12 files is using passwords for authenticating
the received files, the attacker can create unencrypted PKCS#12 files that
use PBMAC1 authentication that specifies an HMAC key of only one byte, allowing
them to craft a file that will be accepted with a 1 in 256 probability.
That would then cause the service to accept a certificate and private key
controlled by the attacker.
The FIPS modules are not affected by this issue, as the affected code is
outside the OpenSSL FIPS module boundary. |
| Nuxt is an open-source web development framework for Vue.js. In Nuxt versions 3.1.0 to before 3.21.6 and 4.0.0-alpha.1 to before 4.4.6 and @nuxt/nitro-server versions 3.20.0 to before 3.21.6 and 4.0.0-alpha.1 to before 4.4.6, the /__nuxt_island/* endpoint accepts attacker-controlled props query/body parameters and renders any island component without verifying that the URL-resident hash (<Name>_<hashId>.json) was actually issued for those inputs by <NuxtIsland>. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query. This issue has been patched in versions 3.21.6 and 4.4.6. |
| The Model Context Protocol has a security warning advising servers to validate the "Origin" header on all incoming connections to prevent DNS rebinding attacks. Prior to the v0.25.0 release, users had no way to validate the origin's host. In v0.25.0, a new "--allowed-hosts" flag was introduced alongside the existing "--allowed-origins" flag, enabling users to specify permitted hosts at server startup. Both flags default to "*", allowing users to implement strict access controls as needed without breaking existing setups. If either flag is set to "*", the server will output a startup warning about potential vulnerabilities. Documentation has also been updated to highlight these security considerations. |
| Impact: When a user-configured proxy on webpack-dev-server has a broad context (e.g. /) and ws: true, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and Origin header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket).
Patches: Fixed in webpack-dev-server@5.2.5.
Workarounds: Scope user-defined proxy context to specific paths instead of /, or omit ws: true from the proxy entry when WebSocket forwarding is not required. |
| Axios is a promise based HTTP client for the browser and Node.js. From 1.15.2 to before 1.16.0, nested objects created by utils.merge() (e.g., config.proxy) are still constructed as plain {} with Object.prototype in their chain. The setProxy() function at lib/adapters/http.js:209-223 reads proxy.username, proxy.password, and proxy.auth without hasOwnProperty checks. When Object.prototype.username is polluted, setProxy() constructs a Proxy-Authorization header with attacker-controlled credentials and injects it into every proxied HTTP request. This vulnerability is fixed in 1.16.0. |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as 'token is valid, ODCID starts at offset 0', causing the server to call quiche_accept as if the client's address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct 'no token handler' semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply. Version 4.2.15.Final patches the issue. |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DNS resolver uses a predictable PRNG for generating DNS transaction IDs and defaults to a static UDP source port. This combination reduces the entropy of DNS queries, enabling DNS Cache Poisoning (Kaminsky attack). Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Insufficient policy enforcement in DevTools in Google Chrome prior to 149.0.7827.115 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: High) |
| Cloud Foundry UAA incorrectly treated XML encryption to the Service Provider (confidentiality) as a substitute for XML signatures from the Identity Provider (authenticity) in two SAML flows: the OAuth 2.0 SAML2 bearer grant (token endpoint) and browser SSO (ACS) when wantAssertionSigned is set to false. Assertions or responses that were unsigned but contained encrypted content could still be accepted. Encryption uses the SP's public key from published metadata, therefore, any party, not only a trusted IdP, can produce ciphertext UAA can decrypt; successful decryption therefore does not prove the IdP issued the message.
Affected versions:
Cloud Foundry UAA (uaa_release) 2.0.0 through 78.13.0.
Cloud Foundry CF Deployment all versions through 56.1.0. |
| Since Spring Security SAML decrypts SAML Responses as well as elements of SAML LogoutRequests and LogoutResponses without requiring a valid signature, attackers may be able to craft these SAML payloads and use the Service Provider as a decryption oracle.
Affected versions:
Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5. |
