Skip to main content

Enterprise Technology Signals

Signals are individual enterprise-technology developments, captured as they happen: product launches, funding, partnerships, executive moves, vulnerabilities, and announcements across cloud infrastructure, networking, security, and AI. The feed updates throughout each weekday. Browse the latest below, or search the full knowledge graph. Looking for the weekly synthesis? See Briefs

VU#326070: SGLang contains a vulnerable pickle deserialization vulnerability through the expert-parallel subsystem

Overview A Pickle deserialization vulnerability has been discovered within the SGLang project, enabling an attacker to perform remote code execution (RCE) on the target vulnerable server. In order for an attacker to exploit this vulnerability, the expert-parallel backup subsystem must be enabled, and an attacker must have network access to the SGLang service. No patch is available at this time, and no response was obtained from the project maintainers during coordination. Description SGLang is an open-source framework for serving large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. A vulnerability has been discovered within the tool and is tracked as follows: CVE-2026-14890 SGLang uses an expert-parallel backup subsystem designed to handle the large amount of compute and memory constraints associated with different model types. This system, when running, exposes a ZeroMQ PULL socket on a routable network interface that does not contain authentication or deserialization safeguards, allowing an attacker to provide a malicious pickle file that results in unauthenticated remote code execution when the feature is enabled and the service is reachable over the network. The vulnerability is caused by the ZeroMQ PULL socket in expert_backup_manager.py binding to an external IP address with no authentication, meaning that any process that can reach the endpoint can send a payload that eventually gets deserialized with Pickle. This vulnerability is structurally similar to CVE-2026-7301 and CVE-2026-7304 in that it enables unauthenticated remote code execution via unsafe deserialization of data through pickle.loads(), but differs by occurring in the expert-parallel backup subsystem, rather than the multimodal scheduler or custom logit processor interfaces. Impact If exploited, this vulnerability could allow an unauthenticated attacker to achieve remote code execution on the host running SGLang. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation. Solution Until a patch is available, affected users should consider the following mitigations: Mitigations Restrict access to the service interfaces and ensure they are not exposed to untrusted networks. Implement network segmentation and access controls to prevent unauthorized interaction with the vulnerable endpoints. Change SGLANG_USE_PICKLE_IPC to "false" within environ.py. The SGLang maintainers have made strides in addressing pickle deserialization vulnerabilities, and have begun to work to refactor the code base with msgpack to prevent deserialization issues such as CVE-2026-14890, but the SGLANG_USE_PICKLE_IPC defaults to true within the codebase at the time of writing. Acknowledgements Thanks to the reporter, [email protected]. This document was written by Christopher Cullen.

CISA updates node-forge for signature forgery flaws in RSA-PKCS#1 and Ed25519

Overview Two distinct cryptographic signature verification vulnerabilities exist in Digital Bazaar node-forge, a widely used JavaScript library implementing cryptographic primitives for Node.js and browser environments. These vulnerabilities allow attackers to forge RSA (PKCS#1 v1.5) and Ed25519 signatures under specific, exploitable conditions. Description Both vulnerabilities stem from insufficient enforcement of canonical cryptographic structures during verification: in the RSA case, non-standard ASN.1 encodings and undersized padding are accepted; in the Ed25519 case, non-canonical signature scalars are not rejected. As a result, node-forge accepts signatures that appear valid internally but are rejected by industry-standard libraries such as OpenSSL and Node.js’s native crypto module. The vulnerabilities affect node-forge versions 0.1.2 through 1.3.3 for RSA-PKCS#1 v1.5, and 0.7.4 through 1.3.3 for Ed25519. Both issues were resolved in v1.4.0, released on 2026-04-05. CVE-2026-33894 arises in lib/rsa.js, where RSASSA-PKCS1-v1_5 verification accepts forged signatures due to two related flaws. First, the ASN.1 parser for DigestInfo permits non-canonical encodings—specifically, structures with more than the two required fields (algorithm OID and octet string), including attacker-controlled additional data. Second, the PKCS#1 v1.5 decoding logic fails to enforce the RFC 2313 requirement that the padding string (PS) must be at least 8 bytes. These combined weaknesses enable attackers to construct specially crafted signatures, particularly with low public exponents (e.g., e = 3), that node-forge validates successfully while standard implementations correctly reject them. CVE-2026-33895 resides in lib/ed25519.js, where signature verification does not enforce scalar canonicality as mandated by RFC 8032. The scalar S (last 32 bytes of the signature) is used without ensuring it lies within the valid range [0, L−1], where L is the Ed25519 group order. Consequently, signatures with S′ = S + k·L (e.g., S + L) verify as valid in node-forge, even though canonical implementations such as Node.js crypto and OpenSSL reject them. This undermines assumptions about signature uniqueness and enables substitution attacks in systems relying on strict byte-for-byte signature validity—for instance, audit logs, token binding, or attestation protocols. Impact The most immediate concern is integrity: attackers may forge signatures for arbitrary messages in the RSA case or mutate valid Ed25519 signatures in ways that remain accepted by node-forge. Such forgery enables bypassing authentication, code-signing, or session-bound token validations, especially in workflows where node-forge is used as the sole verification engine. The scope is broad. Any application using node-forge’s default verification APIs—including JOSE libraries like node-jose, certificate tooling from Adobe and Expo, and custom PKI integrations—is potentially affected. Because the vulnerabilities manifest in the default configuration (i.e., no unusual flags or options required), unpatched deployments face exposure without any operator action. Exploitation is straightforward. Public proofs of concept demonstrate RSA forgery with low-exponent keys and Ed25519 scalar manipulation with minimal effort, and both attacks work over the network against remote endpoints performing verification. Solution The vulnerabilities have been fully addressed in node-forge v1.4.0, released on 2026-04-05. This release enforces strict canonical validation: RSA verification now rejects non-canonical DigestInfo structures and enforces PS greater than or equal to 8 bytes of padding, while Ed25519 verification explicitly checks that S < L. After upgrading, users can verify the fix by running the included test suite, which includes dedicated test cases for both CVEs. If you maintain downstream packages that depend on node-forge, update your dependency lockfiles and test thoroughly with v1.4.0 before releasing. Even indirect usage through frameworks, build tools, or security plugins may expose your users to risk until the transitive dependency is upgraded. Mitigations If immediate upgrade is not possible due to legacy dependencies or indirect usage in transitive dependencies, the following interim measures are recommended: 1. Audit all call sites invoking forge.pki.publicKey.verify(), ed25519.verify(), or JOSE-based verification routes. 2. Where feasible, fall back to Node.js native crypto.verify() for RSA and Ed25519 validation, particularly in high-assurance flows such as code signing or identity assertion. 3. In critical workflows, consider implementing cross-library verification: for instance, compute the signature with node-forge but validate it using the Node.js crypto module as a secondary check. It is important to note that options such as_parseAllDigestBytes: true do not mitigate these vulnerabilities, as they neither enforce ASN.1 strictness nor padding length. Relying on them may create a false sense of security. Acknowledgements This vulnerability was discovered by Austin Chu, Sohee Kim, and Corban Villa, of the University of California, Berkeley, as part of a security research project. This AI-assisted vulnerability note was prepared by Timur Snoke.

The Savvy CIO Podcast Series Starts July 22

“The Savvy CIO” podcast series starts July 22, with 10 Season One episodes featuring Bradd Busick and guests including IBM and IDC.