CVE-2026-69646
Improper verification of cryptographic signature in Skype for Business allows an unauthorized attacker to perform spoofing over an adjacent
CVSS
8.3
High
EPSS
—
KEV
—
Exploit Today
—
0-100
Published: Sep 8, 2026 · Last modified: Sep 8, 2026 · CWE-347
Not enough EPSS history yet.
Improper verification of cryptographic signature in Skype for Business allows an unauthorized attacker to perform spoofing over an adjacent network.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-86080——
———n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the GitHub Trigger generated a webhook secret but discarded it when GitHub returned HTTP 422 and the node reused an existing webhook. Workflow static data then retained webhookId without webhookSecret, and X-Hub-Signature-256 verification accepted deliveries without a stored secret. The affected logic includes packages/nodes-base/nodes/Github/GithubTriggerHelpers.ts and the 422 webhook reuse path. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.6hCVE-2026-570987.5 HIG—
———Improper verification of cryptographic signature in Windows RDP Client allows an unauthorized attacker to disclose information over a network.7hCVE-2026-77105——
———CommServe contained a cryptographic signature verification issue affecting privilege management. Software customers upgrade to resolved maintenance release. Update CommServe and Web Server.14hCVE-2026-142967.5 HIG1.4%
——0When using the Direct XIP
update strategy, the main application image starts other cores (i.e. radio
core), based on the currently active slot without additional verification. The
MCUboot in the bare (upstream) configuration assumes that if there is at least
a single slot for each image available, the system is bootable and continues
the boot process. This may lead to a situation when MCUboot picks different
slot for different images (i.e. (a) for the main application and (b) for the
radio image), boots the main application (from slot (a)) that afterwards starts
the radio image by providing an address of the unauthenticated slot ((a)
instead of (b)).13hCVE-2026-863049.8 CRI1.2%
——0MojoX::Authentication versions before 0.006 for Perl allow SAML authentication bypass because parse_assertion builds Net::SAML2::Binding::POST without a trust anchor.
parse_assertion in MojoX::Authentication::Model::SAML2 calls Net::SAML2::Binding::POST->new with no cacert, cert_text or anchors argument, then passes the returned XML to Net::SAML2::Protocol::Assertion->new_from_xml with the IdP signing certificate as cacert. In Net::SAML2 before 0.86 that certificate guards only encrypted assertions, so the signature on an unencrypted assertion is checked against the certificate the response itself carries.
An attacker starts a SAML login, then posts a response signed with a certificate of their own. The audience, InResponseTo and timestamp checks that follow are all satisfiable by the attacker, so the response authenticates any NameID it carries.9hCVE-2026-67278—6.2%
——2MikroTik RouterOS accepts malformed RSA/PKCS#1 v1.5 signatures during X.509 validation. Because its trust store includes an e=3 root CA, an attacker controlling or redirecting an outbound RouterOS TLS connection can use the root’s public certificate - without its private key - to forge a trusted intermediate and issue certificates for arbitrary hostnames, enabling TLS server impersonation.
This issue affects only 7.x branch was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable)12h