Signal

SEALSQ and WISeKey reported QSOC progress, targeting a Q4 2026 SpaceX launch for a post-quantum security cloud in space.

Aviz’s blog describes next-gen DPI using payload intelligence, dynamic updates, and JSON/Kafka metadata exports for observability.

Netskope Threat Labs says OAuth authorization abuse persists after consent, and AI agents increase token exposure without review or rotation.

Dell’Oro projects 6G RAN capex will reach $0.5T by 2034 and cumulative 6G RAN revenue will exceed $100B in the first six years.

Overview A vulnerability has been discovered in the Haskell TLS software stack, commonly used by applications built in the Haskell programming language to securely connect to servers over the internet. Specifically, the libraries "crypton-x509-validation" fail to enforce a key security feature called NameConstraints, a standard defined in RFC 5280 that helps organizations control which domains a certificate authority (CA) is allowed to issue certificates for. This vulnerability allows an attacker with access to the sub-CA to create certificates that will validate successfully with any Haskell TLS connection, allowing the attacker access to full session visibility. Version 1.91 for crypton-x509-validation have been released to address the vulnerability, tracked as CVE-2026-9648. Description Haskell is a programming language often used in enterprise, academic, and financial systems such as banks, insurance companies, and data processing platforms, which use it for backend services like fraud detection, risk modeling, and other sensitive connections. The Haskell TLS software stack is the implementation used by Haskell applications to establish secure HTTPS or TLS connections to servers, just like OpenSSL or Go’s TLS libraries do in other ecosystems. A vulnerability has been discovered within the stack; crypton-x509-validation, which do not enforce the NameContstraints security feature that other libraries, such as OpenSSL or Go, do. The description for CVE-2026-9648 is as follows: The crypton-x509-validation Haskell library fails to enforce X.509 NameConstraints, allowing TLS clients to accept certificates whose Subject Alternative Names fall outside the issuing CA’s permitted subtrees. This oversight enables an attacker who compromises a name-constrained sub-CA to impersonate domains beyond its intended scope. NameConstraints are a security mechanism in digital certificates that tell a CA exactly which domains it’s allowed to issue certificates for. The crypton-x509-validation, which handle certificate validation in Haskell’s TLS connections, ignore these constraints entirely, so they never check whether a certificate’s Subject Alternative Name (SAN) falls within what the issuing CA is permitted to cover. This enables a threat actor who gains access to a sub-CA key to create a certificate that includes a SAN for a protected domain, tricking Haskell clients into accepting it and enabling full impersonation of those services. Practically, a TA could set up a web server presenting the malicious CA, tracking any Haskell client to connect to the malicious web server, allowing them to capture any credentials or sensitive data transferred during the process. Impact An attacker that successfully exploits CVE-2026-9648 can capture any traffic sent between a Haskell client to their server, potentially giving access to sensitive financial information, credential theft, and secret theft. This vulnerability is likely to affect industries that use delegated PKI structures, or structures that allow delegated systems to create and assign their own CAs. This is typical in banks or other financial industries. Solution The vulnerability requires considerable setup and victim interaction in order to be successful, but vulnerable parties should update their libraries to version 1.9.1 of the crypton-x509-validation libraries as soon as possible, as all version prior are vulnerable. Acknowledgements Thanks to the reporter, Ben Smyth.This document was written by Christopher Cullen.

MSX launched X Card, integrating digital asset accounts with Visa payments, Google Pay, remittances, and ATM withdrawals with PCI DSS Level 1.