CVE-2026-44852
An authenticated remote code execution vulnerability exists in the AOS-8 and AOS-10 web-based management interface. A vulnerability in the c
CVSS
7.2
Alto
EPSS
0.4%
p38
KEV
—
Exploit Today
11
0-100
Publicado: 12 may 2026 · Última mod.: 26 oct 2026 · CWE-296
0.4%EPSS · 30 días0.6%
2026-10-052026-11-02
An authenticated remote code execution vulnerability exists in the AOS-8 and AOS-10 web-based management interface. A vulnerability in the certificate download functionality could allow an authenticated remote attacker to overwrite arbitrary files on the underlying operating system by exploiting improper input validation in the file path parameter. Successful exploitation could allow the attacker to execute arbitrary commands on the underlying operating system as a privileged user.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-96770—24.9%
——7All published s2s-proxy versions through 0.2.2 are affected. In versions 0.1.16 through 0.2.2, TLS server listeners use Go's RequireAnyClientCert mode when skipCAVerification is false. This mode checks that the client holds the certificate's private key but does not verify the certificate against the configured CA. An attacker can therefore use a self-signed certificate and key to establish a TLS and yamux connection, then invoke RPCs allowed by the proxy's configuration and Temporal credentials. No certificate or private key trusted by the deployment, and no Temporal credential, is required.40dCVE-2026-735423.7 BAJ7.3%
——2Multiple SEIKO EPSON printers and scanners contain revoked root certificates. A man-in-the-middle attack may allow an attacker to obtain communication data transmitted by the product. As for the details of the affected products and versions, refer to the vendor's information.67dCVE-2026-240668.4 ALT2.0%
——1Slate Digital Connect 1.37.0 for macOS installs a privileged helper tool, com.slatedigital.connect.privileged.helper.tool, which exposes the XPC service com.slatedigital.connect.privileged.helper.tool2. The helper validates connecting XPC clients by checking only the subject.OU value of the client's signing certificate and does not verify that the certificate chains to a trusted code-signing authority. A local attacker can sign a malicious client with a self-signed certificate containing the expected organizational unit value and connect to the privileged XPC service. This allows unauthorized access to privileged helper functionality and may lead to local privilege escalation.8dCVE-2026-427894.8 MED32.3%
——10Improper Following of a Certificate's Chain of Trust vulnerability in Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.
In lib/public_key/src/pubkey_cert.erl, pubkey_cert:validate_extensions/7 contains two flaws that together allow a certificate with basicConstraints cA:false and no keyUsage extension to be used as an intermediate issuer in a chain passed to public_key:pkix_path_validation/3: the cA:false clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the keyUsage check only fires when the extension is present, so a certificate lacking keyUsage entirely bypasses the keyCertSign enforcement.
Any party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim's trust store, can use that certificate's private key to sign forged leaf certificates for arbitrary identities. public_key:pkix_path_validation/3 accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP ssl application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to public_key from 0.22 before 1.17.1.7, 1.20.3.6, and 1.21.8. Whether OTP before OTP 17.0, corresponding to public_key before 0.22, is affected is unknown.8dCVE-2026-337796.5 MED1.9%
——1An Improper Following of a Certificate's Chain of Trust vulnerability in J-Web of Juniper Networks Junos OS on SRX Series allows a PITM to intercept the communication of the device and get access to confidential information and potentially modify it.
When an SRX device is provisioned to connect to Security Director (SD) cloud, it doesn't perform sufficient verification of the received server certificate. This allows a PITM to intercept the communication between the SRX and SD cloud and access credentials and other sensitive information.
This issue affects Junos OS:
* all versions before 22.4R3-S9,
* 23.2 versions before 23.2R2-S6,
* 23.4 versions before 23.4R2-S7,
* 24.2 versions before 24.2R2-S3,
* 24.4 versions before 24.4R2-S2,
* 25.2 versions before 25.2R1-S2, 25.2R2.8dCVE-2026-271348.1 ALT32.8%
——10Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions 0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used.112d