Public exploits have been released for the critical “wp2shell” remote code execution vulnerabilities affecting WordPress Core, making it imperative that administrators patch their sites immediately. […]

Overview
A denial-of-service (DoS) vulnerability exists in some HTTP/2 server implementations that fail to adequately limit resource consumption when buffering response data under stalled flow-control conditions. A remote, unauthenticated attacker can trigger memory exhaustion and service interruption by using standard flow-control parameters such as SETTINGS_INITIAL_WINDOW_SIZE = 0 to stall outbound data for multiple simultaneous request streams.
Description
HTTP/2 is a widely used application-layer protocol that supports multiplexing, header compression, and flow-control mechanisms to regulate the transmission of data between web browsers and servers. Flow control is designed to prevent senders from overwhelming receivers and relies on client-advertised window sizes to determine the maximum volume of unacknowledged data that can be in transit at any given time.
A client can intentionally stall outbound flow control by withholding WINDOW_UPDATE frames or by advertising SETTINGS_INITIAL_WINDOW_SIZE = 0. In some HTTP/2 implementations, the server continues processing requests and generating complete response bodies even though it is unable to transmit them. The resulting response data remains buffered in memory, and each stalled stream retains its allocated buffer until the connection closes or a timeout occurs.
An attacker can exploit this behavior by opening many simultaneous streams and requesting large resources, causing the server to accumulate large amounts of buffered response data. In environments with permissive resource limits, this can lead to excessive memory consumption, swap exhaustion, service instability, and, in severe cases, system crashes. Even under more conservative limits, the attack can exhaust worker or connection resources and degrade service availability.
Impact
A remote, unauthenticated attacker can cause denial-of-service conditions on affected HTTP/2 server implementations. Under high resource limits, an attacker may be able to induce unbounded memory amplification resulting in OOM kills, severe swap thrashing, or full system unresponsiveness. Under default or lower limits, the attack can exhaust available connections or worker resources, temporarily preventing new clients from establishing sessions and degrading overall service availability.
Solution
Several vendors have addressed this vulnerability in recent updates; see the Vendor Information section for individual CVEs and remediation details. Implementations that enforce memory ceilings, restrict concurrent stream counts, and actively terminate stalled connections can substantially reduce the risk of denial-of-service conditions.
Acknowledgements
Thanks to the Okta Red Team for researching and reporting this vulnerability. This document was written by Molly Jaconski.

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, edwardav970@gmail.com.
This document was written by Christopher Cullen.