Every story tagged Cryptography, curated for CIOs and IT leaders — ranked by source credibility, engagement, and freshness.
164 stories · open in the command center
Ethereum leaders are warning that rapid advances in AI-driven mathematics could weaken today’s cryptographic assumptions sooner than many organizations expect, potentially threatening private keys and even some quantum-resistant schemes. For CIOs and technology leaders, the strategic takeaway is that crypto agility, key-management hygiene, and orderly migration planning are becoming urgent resilience issues—not just a blockchain concern—as the pace of AI progress may outstrip existing security roadmaps. IT organizations should treat this as a signal to inventory exposed cryptographic assets, reassess signing and key-rotation practices, and prepare controlled migration procedures to reduce operational and security risk.
Vitalik Buterin’s warning underscores a rising enterprise risk: AI may accelerate mathematical advances enough to weaken today’s cryptography, putting digital assets, identities, and trusted communications at greater risk. For CIOs and technology leaders, the strategic implication is clear—organizations need cryptographic agility, strong key-management discipline, and a practical migration path to more resilient or post-quantum approaches before a breakthrough forces an emergency response.
AI labs are reportedly beginning to test whether frontier models can help break important cryptographic protocols, signaling a shift from abstract AI risk to direct security and resilience concerns for enterprises. For CIOs, this raises the strategic stakes around protecting identity systems, encryption keys, and sensitive data, while also suggesting that IT and security teams may need to reassess assumptions about the long-term strength of current cryptographic controls in an AI-accelerated threat landscape.
Express Gateway through 1.16.11 contains a hardcoded cryptographic key vulnerability that allows attackers with datastore access to decrypt stored OAuth 2.0 token secrets via the default crypto.cipherKey 'sensitiveKey'. Attackers who can read Redis can decrypt tokenEncrypted values and combine them with stored token IDs to obtain valid bearer tokens for any user.
Attackers hijacked multiple country-code top-level domains to issue counterfeit TLS certificates for Google and other major services, demonstrating that DNS and certificate-validation weaknesses can be exploited to impersonate trusted digital properties at scale. For CIOs and technology leaders, this highlights that browser-side protections are not enough: IT must treat certificate governance, DNS integrity, and continuous monitoring as core controls for protecting customer trust, transaction security, and brand reputation. The incident also underscores the operational risk of slow certificate revocation and the need for layered defenses across web, identity, and infrastructure teams.
A Forescout study of 2.5 million healthcare devices finds the sector is broadly unprepared for post-quantum cryptography, especially in Internet-exposed systems and on difficult-to-update OT/IoMT assets that support critical clinical operations. For CIOs and technology leaders, the business risk is long-lived sensitive patient data being captured now and decrypted later, while the strategic challenge is that quantum readiness will require a coordinated, multi-year modernization effort across security, infrastructure, clinical engineering, procurement, compliance, and device vendors—not just an IT patch cycle.
In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnosti...
In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwi...
In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, a...
This report highlights a serious trust and supply-chain risk in a widely used proxy/security component: a certificate verification bypass could expose traffic to man-in-the-middle attacks, while the issue was allegedly fixed without transparent disclosure to users. For CIOs and technology leaders, the strategic takeaway is that even infrastructure and security tools can introduce hidden exposure, making third-party software governance, rapid vulnerability communication, and configuration control critical to organizational resilience and customer trust.
A high-severity vulnerability in Bouncy Castle for Java LTS affects one-shot native packet ciphers across several AES modes, creating potential cryptographic risk for applications that rely on this library. For CIOs and technology leaders, this is a supply-chain and application-runtime issue that could impact data confidentiality and trust in encryption controls, making rapid patching and asset visibility critical. IT organizations should treat this as a prioritized dependency remediation effort across Java estates, not just a single-library update.
This vulnerability in Bouncy Castle for Java affects applications using its high-level OpenPGP certificate API and could undermine trust validation by allowing improperly handled third-party certifications or trust packets. For CIOs, the business risk is unauthorized identity trust or message/signature spoofing in systems that depend on PGP-based security, making dependency visibility and rapid remediation critical for reducing operational and supply-chain exposure.
This CVE affects Bouncy Castle for Java versions before 1.86 and centers on BLS12_381 key validation logic, which can weaken cryptographic trust in applications that rely on these libraries. For CIOs and technology leaders, the business risk is potential compromise of authentication, signatures, or other integrity controls in Java-based systems, making this a priority dependency issue for any organization using Bouncy Castle in security-sensitive workloads.
This high-severity CVE in Bouncy Castle for Java before 1.86 affects validation of MLS external commit proposal lists, creating a risk that could undermine the integrity of secure messaging and collaborative workflows built on the library. For CIOs and IT leaders, the key issue is third-party dependency exposure: any Java application using this crypto library may need urgent remediation to avoid security, compliance, and trust impacts.
Exposure of the message authentication key through the encryption keystream in the stream mode of IesEngine (an IesEngine constructed without a block cipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who has observed one encrypted message with known plaintext to forge shorter messages of their choosing that the recipient accepts as authentic, via a crafted ciphertext and MAC tag, because the MAC key was taken from the key derivation output directly after a keystream as long as the message, while the derivation input depends only on the static key pair and fixed parameters. The keystream revealed by that one message therefore contains the MAC key for every sufficiently shorter message.
Loop with unreachable exit condition in Pkcs12Store.GetCertificateChain in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a crafted PKCS#12 file to an application that loads it and requests a key entry's certificate chain to cause a denial of service, in which the call never returns and consumes CPU and memory until an OutOfMemoryException, via certificates whose issuer links form a cycle, for example two certificates whose AuthorityKeyIdentifier extensions each identify the other's public key. This happens because the chain-building loop stops only when no issuer is found or a certificate links to itself, and keeps no record of certificates already visited. The key-identifier links are followed without checking signatures.
Improper verification of cryptographic signature in the attribute certificate path validator (PkixAttrCertPathValidator, also used by PkixAttrCertPathBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker to have a forged X.509 attribute certificate accepted as valid, and so obtain whatever roles or privileges an application grants on the strength of its attributes, via an attribute certificate that names a trusted attribute authority as its issuer but was not signed by it, because the RFC 3281 validation steps check the holder and issuer certification paths, validity period, extensions and revocation status but never verify the attribute certificate's signature with the issuer's public key. Only applications that use these classes to validate attribute certificates are affected.
Loop with unreachable exit condition in the PKCS#12 key derivation (Pkcs12ParametersGenerator) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a PKCS#12 (PFX) file, or a PKCS#8 encrypted private key that uses a PKCS#12 password-based encryption algorithm, to cause a denial of service through CPU exhaustion via an iteration count of zero or below, because the derivation loop ran until its counter equalled the count, so for such a count it wrapped through about 2^32 iterations before the MAC or the password could be checked. A 75-byte PFX file with a negative MacData iteration count kept Pkcs12Store.Load busy for many minutes.
Improper certificate validation in PkixNameConstraintValidator (ExtractHostFromURL) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a name-constrained subordinate CA, or anyone able to obtain certificates with chosen subjectAltName URIs from such a CA, to bypass permitted or excluded uniformResourceIdentifier name constraints during certification path validation via a URI whose path, query, fragment or userinfo contains characters such as '@' or ':', because the host was extracted by string slicing without first isolating the RFC 3986 authority component, so the host compared against the constraints could differ from the URI's actual host.
Uncontrolled recursion in the ASN.1 parser (Asn1InputStream, Asn1StreamParser) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker to cause a denial of service via a crafted ASN.1 encoding of deeply nested constructed elements (for example SEQUENCE inside SEQUENCE, in definite-length DER or indefinite-length BER form), because each nesting level is parsed by a further recursive call with no bound on depth. About 2,000 levels (8 KB of DER) are enough to exhaust a 1.5 MB thread stack, the .NET main-thread default on Windows, and raise a StackOverflowException, which .NET cannot catch and which terminates the whole process; on threads with larger stacks, parse time instead grows quadratically with depth (about 9 seconds of CPU for a 64 KB input). Any path that parses untrusted ASN.1 is exposed, including X.509 certificates and CRLs, CMS/PKCS#7, PKCS#8/PKCS#12, OCSP and TLS Certificate messages.
An improper verification of cryptographic signature vulnerability exists in protocol gateways because the device does not properly verify the cryptographic authenticity of firmware images before installation. An attacker with high privileges and access to the firmware update interface could provide a specially crafted or modified firmware image, causing it to be installed on the device. Successful exploitation could allow the attacker to execute unauthorized code, compromise the integrity and availability of the device, and persist malicious modifications across subsequent firmware updates.
The article argues that Git 3.0’s move to SHA-256 by default will impose broad migration, tooling, and operational costs on engineering organizations while delivering little practical security value for most businesses. For CIOs and technology leaders, the strategic implication is that a standards-driven cryptography change can create significant platform friction, vendor and ecosystem compatibility issues, and productivity loss across IT and software teams unless adoption is carefully staged and justified by real risk.
EU regulators are scrutinizing Binance’s use of a legal exemption to keep serving customers without a license, underscoring how quickly regulatory gaps can become existential business risk for digital and platform-based firms. For CIOs and technology leaders, the key implication is that market access now depends as much on provable compliance, customer segmentation, and audit-ready controls as it does on product capability—making governance, identity, data retention, and jurisdiction-aware system design core IT priorities.
This case underscores that insider threats can create major financial, legal, and reputational exposure even inside highly trusted law-enforcement or security organizations. For CIOs and technology leaders, it highlights the need for stronger privileged-access controls, tamper-evident audit trails, and tighter segregation of duties around sensitive digital assets and investigative data.
Cloudflare’s plan to issue quantum-safe TLS certificates is an early sign that post-quantum security is moving from theory to practical infrastructure, with potential to preserve web trust without adding major latency or bandwidth overhead. For CIOs and IT leaders, this signals that certificate management, PKI, browser compatibility, and vendor roadmaps will need to be revisited well before quantum attacks become realistic, especially for organizations with long-lived data, regulated workloads, or internet-facing services.
In Anjvision YSSD‑RTMP‑H5 firmware version 3.3.2.4, both the local and cloud update mechanisms apply new firmware without any cryptographic verification, relying only on basic hashing. This design allows an attacker who can reach the update routine to introduce untrusted firmware images that the device will accept as valid.
Salmon’s new Execution Verification Infrastructure (EVI) adds a cryptographically verifiable audit layer for AI agents and autonomous systems, recording who acted, what they did, and how state changed across tools, APIs, code, and infrastructure. For CIOs, the strategic implication is clear: as agentic AI moves from assistance to execution in production environments, traditional identity, authorization, and observability controls are no longer enough without machine-verifiable proof of execution for security, governance, compliance, and incident response.
In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix wrong return code to engine in asynch callbacks When crypto_finalize_hash_request() or crypto_finalize_skcipher_request() explicitly completes a request, the do_one_request callback must return 0 to indicate successful handling. Returning a negative error code causes the crypto engine to assume the driver failed to take ownership and triggers a second completion via crypto_request_complete(), resulting in a double completion. This pattern occurs in paes_s390.c 4 times and once in phmac_s390.c. Fixed in phmac_do_one_request() and all four paes do_one_request callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit finalization instead of propagating the error code.
`@bsv/wallet-toolbox` provides BRC-100 wallet signing and storage components, while `@bsv/wallet-toolbox-client` and `@bsv/wallet-toolbox-mobile` provide client-focused distributions for standard and mobile applications using wallet storage services. A vulnerability in these packages causes transactions created through a remote `StorageClient` to trust output locking scripts returned by the storage provider without verifying that they match the outputs requested by the caller. A malicious or compromised storage provider can substitute a recipient script or inject an additional output, causing the wallet to sign and broadcast a transaction that redirects funds while the application and user interface continue to display the intended recipient. Source and npm publication history indicate that stable versions `@bsv/wallet-toolbox` and `@bsv/wallet-toolbox-client` from 1.1.47 through 2.3.3, and `@bsv/wallet-toolbox-mobile` from its initial 1.3.21 release through 2.3.3, are affected. All...
This episode underscores that the post-quantum transition is becoming a strategic IT priority, not a distant research topic: once cryptographically relevant quantum computers arrive, today’s public-key protections could be undermined, creating major risk for data, identity, and network trust. For CIOs and technology leaders, the business implication is clear—organizations need to begin planning for crypto-agility now, so infrastructure, vendors, and internal systems can be updated without disruptive last-minute replacement cycles.