Host key substitution in wolfSSH clients using ECDSA host keys lets an unauthenticated, network-positioned attacker have the client import an attacker-chosen public key, because ParseECCPubKey() derives the curve from the untrusted KEXDH_REPLY blob rather than from the negotiated host key algorithm, so the attacker's own signature over the substituted key verifies successfully. Exploitation is doubly gated: the attacker must hold an active man-in-the-middle position able to rewrite the key exchange reply, and the client must be deployed with a lax public-key verification callback such as trust-on-first-use, an algorithm-name-only check, or fingerprint matching performed against the already-parsed key. No public exploit code has been identified at time of analysis; the vendor's CVSS 4.0 score of 9.0 (Critical) overstates realistic urgency for most fleets, and our independent assessment maps the same defect to CVSS 3.1 7.4 (High) with AC:H.
Improper JWT/OAuth bearer-token validation in Apache Impala executors (versions 4.1.0 through 4.5.2) lets remote, unauthenticated attackers read resources exposed by an executor's internal webserver, because JWT signatures are never verified and any syntactically valid token is accepted. The exposure is conditional: it only applies where the executor webserver has been explicitly configured to accept JWT/OAuth bearer-token authentication, which is not the default, and the attacker must have network reachability to that webserver endpoint. EPSS is low (0.20%, ~9th percentile) and no public exploit code or confirmed active exploitation has been identified at time of analysis, but the flaw is trivially exploitable once the non-default configuration is in place; the assessed impact is high confidentiality with limited integrity loss, and the vendor fix is Impala 4.5.3 or disabling JWT/OAuth on executors.