| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| LibJWT is a C JSON Web Token Library. From 3.0.0 to 3.3.2, libjwt accepts an RSA JWK that does not contain an alg parameter as the verification key for an HS256/HS384/HS512 token. In the OpenSSL backend, this causes HMAC verification to run with a zero-length key, so an attacker can forge a valid JWT without knowing any secret or RSA private key. This is an algorithm-confusion authentication bypass. It affects applications that load RSA keys from JWKS where alg is omitted, which is valid JWK syntax and common in real deployments, and then choose the verification algorithm from the JWT header, for example in a kid lookup callback. This vulnerability is fixed in 3.3.3. |
| Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. Prior to 0.16.0, gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git's EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. This vulnerability is fixed in 0.16.0. |
| The bitcoinj library is a Java implementation of the Bitcoin protocol. Prior to 0.17.1, ScriptExecution.correctlySpends() contains two fast-path verification bugs for standard P2PKH and native P2WPKH spends in core/src/main/java/org/bitcoinj/script/ScriptExecution.java. In both branches, bitcoinj verifies an attacker-controlled signature/public-key pair but fails to verify that the public key is the one committed to by the output being spent. As a result, any attacker keypair can satisfy bitcoinj's local verification for arbitrary P2PKH and P2WPKH outputs. This vulnerability is fixed in 0.17.1. |
| Insufficient policy enforcement in Network in Google Chrome on Android prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Next.js is a React framework for building full-stack web applications. From 12.2.0 to before 15.5.16 and 16.2.5, an external client could send a x-nextjs-data header on a normal request to a path handled by middleware that returns a redirect. When that happened, the middleware/proxy could treat the request as a data request and replace the standard Location redirect header with the internal x-nextjs-redirect header. Browsers do not follow x-nextjs-redirect, so the response became an unusable redirect for normal clients. If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a Location header, causing a denial of service for that redirect path until the cache entry expired or was purged. This vulnerability is fixed in 15.5.16 and 16.2.5. |
| Apache::Session::Generate::SHA256 versions before 1.3.19 for Perl create insecure session ids.
Apache::Session::Generate::SHA256 generated session ids insecurely. The default session id generator returns a SHA-256 hash of the built-in rand() function, the epoch time, and the PID, that is hashed again. These are predictable, low-entropy sources. Predicable session ids could allow an attacker to gain access to systems.
Note that version 1.3.19 has a fallback without warning to use insecure session generation method if the call to Crypt::URandom::urandom fails. However, this is unlikely as Crypt::URandom is a hardcoded requirement of the module.
This issue is similar to CVE-2025-40931 for Apache::Session::Generate::MD5. |
| Inappropriate implementation in ANGLE in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Note Mark is an open-source note-taking application. Prior to 0.19.4, no minimum length or entropy is enforced on the JWT_SECRET configuration value. The application accepts any base64-decodable secret regardless of size, including secrets as short as 1 byte. This vulnerability is fixed in 0.19.4. |
| Side-channel information leakage in Navigation in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Gradient is a nix-based continuous integration system. In 1.1.0, when GRADIENT_DISCOVERABLE=true (the default, and the NixOS module default), anyone who can reach /proto can register as a worker without any credentials by sending a fresh, never-registered worker UUID. The resulting session has PeerAuth::Open, i.e. it sees jobs from every organisation, and can immediately NarPush/NarUploaded arbitrary store paths into nar_storage and the cached_path table. This vulnerability is fixed in 1.1.1. |
| Improper verification of cryptographic signature in the Radeon RGB tool could allow a malicious file placed in the installation directory to be run with elevated privileges potentially leading to arbitrary code execution. |
| Spring Cloud AWS simplifies using AWS managed services in a Spring and Spring Boot applications. From 3.0.0 to 4.0.1, pplications using Spring Cloud AWS SNS HTTP/HTTPS endpoint support (@NotificationMessageMapping, @NotificationSubscriptionMapping, @NotificationUnsubscribeConfirmationMapping) did not verify the signature of incoming SNS messages. An unauthenticated attacker who knows the endpoint URL could send crafted HTTP POST requests mimicking SNS Notification or SubscriptionConfirmation messages. This vulnerability is fixed in 4.0.2. |
| RMCP is an official Rust SDK for the Model Context Protocol. Prior to version 1.4.0, the rmcp crate's Streamable HTTP server transport (crates/rmcp/src/transport/streamable_http_server/) did not validate the incoming Host header. This allowed a malicious public website, via a DNS rebinding attack, to send authenticated requests to an MCP server running on the victim's loopback or private-network interface. This vulnerability is fixed in 1.4.0. |
| CubeCart is an ecommerce software solution. Prior to 6.7.2, CubeCart 6.6.x – 6.7.1 builds CC_STORE_URL directly from the Host request header at bootstrap, with no allowlist. The constant is embedded verbatim into transactional email links, most critically the password-reset link in User::passwordRequest() (and the admin equivalent in Admin::passwordRequest()). An unauthenticated attacker who knows a target email can POST /index.php?_a=recover with Host: evil.com; CubeCart writes a fresh verify token (valid 3,600 s) and emails the victim a link http://evil.com/index.php?_a=recovery&validate=<TOKEN>. The token is valid against the legitimate store — capturing the victim's click on evil.com yields full account takeover, or store takeover when an admin email is targeted. This vulnerability is fixed in 6.7.2. |
| Using libcurl, when a custom `Host:` header is first set for an HTTP request
and a second request is subsequently done using the same *easy handle* but
without the custom `Host:` header set, the second request would use stale
information and pass on cookies meant for the first host in the second
request. Leak them. |
| azureauthextension is the Azure Authenticator Extension. From 0.124.0 to 0.150.0, a server-side authentication bypass in azureauthextension allows any party who holds a single valid Azure access token for any scope the collector's configured identity can mint for to authenticate to any OpenTelemetry receiver that uses auth: azure_auth. The extension's Authenticate method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality — and the scope for that server-side token request is taken from the client-supplied Host header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching Host. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens). |
| An authentication bypass vulnerability in Palo Alto Networks PAN-OS® software enables an unauthenticated attacker with network access to bypass authentication controls when Cloud Authentication Service (CAS) is enabled.
The risk is higher if CAS is enabled on the management interface and lower when any other login interfaces are used.
The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses according to our recommended best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .
This issue is applicable to PAN-OS software on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series).
Cloud NGFW and Prisma Access® are not impacted by this vulnerability. |
| Roadiz is a polymorphic content management system based on a node system. Prior to versions 2.3.43, 2.5.45, 2.6.31, and 2.7.18, the roadiz/openid package generates an OIDC nonce in OAuth2LinkGenerator::generate() and includes it in the authorization request sent to the identity provider, but never stores it and never validates it on the callback. The OpenIdJwtConfigurationFactory validation chain does not include a nonce constraint, and OpenIdAuthenticator::authenticate() never checks the nonce claim in the returned ID token against a stored value. This issue has been patched in versions 2.3.43, 2.5.45, 2.6.31, and 2.7.18. |
| apko allows users to build and publish OCI container images built from apk packages. Prior to version 1.2.7, apko verifies the signature on APKINDEX.tar.gz but never compares individually downloaded .apk packages against the checksum recorded in the signed index. The checksum is parsed and available via ChecksumString(), and the downloaded package control hash is computed, but the two values are never compared in getPackageImpl(). Mismatched packages are silently accepted. An attacker who can substitute download responses (compromised mirror, HTTP repository, poisoned CDN cache) can install arbitrary packages into built images. This issue has been patched in version 1.2.7. |
| Cleanuparr is a tool for automating the cleanup of unwanted or blocked files in Sonarr, Radarr, and supported download clients like qBittorrent. Prior to 2.9.10, TrustedNetworkAuthenticationHandler.ResolveClientIp parses the leftmost entry of the X-Forwarded-For header as the client IP. That entry is attacker-controlled — X-Forwarded-For is append-only, so the leftmost value is whatever the original HTTP client claimed. By sending a spoofed local IP in the header, an unauthenticated remote attacker passes the trusted-network check and is logged in as the Cleanuparr administrator. This vulnerability is fixed in 2.9.10. |
