| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in GIMP. Opening a crafted XCF that selects a path and then fails to load that path can cause a use-after-free in the main process, leading to a crash and potentially arbitrary code execution. |
| Summary
Before version 0.8.1, Pingora's HTTP/2 server used the h2 crate's default limits unless the application set its own 16 MiB decoded header-list size and no limit on concurrent streams. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.
Impact
Remote, unauthenticated denial of service against any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max_header_list_size and max_concurrent_streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
*
Upgrade to pingora 0.8.1 or later (fix: https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd ). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.
*
Applications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits. |
| Ning compress-lzf before 1.2.0 contains an out-of-bounds memory access vulnerability in the sun.misc.Unsafe based UnsafeChunkDecoder that fails to validate back-references and literal runs. Attackers can supply crafted LZF streams to applications using the default LZFDecoder to leak unrelated JVM heap memory into decompressed output or crash the JVM. |
| LangAlpha through 2026.09.07 contains an indirect prompt injection vulnerability that allows remote attackers to execute shell commands or Python by planting instructions in web content retrieved by the agent. Because Bash and ExecuteCode lack an allow-list and human-in-the-loop approval, attackers can run code in the workspace sandbox and exfiltrate vault secrets from _internal/.vault_secrets.json. |
| LangAlpha through 2026.09.07 contains an improper isolation vulnerability that places all tenants' sandbox containers on Docker's shared default bridge network with inter-container communication enabled. Authenticated users with code execution in their own sandbox can connect directly to other tenants' containers, bypassing require_workspace_owner checks to read files such as vault secrets from exposed servers. |
| piflow 2.0.0 through 2.0.1 contains a remote code execution vulnerability in its DeepAgents chat agent, whose POST /chat and POST /chat/stream endpoints lack authentication. Attackers can instruct the agent to call the exec_shell tool, which runs arbitrary commands via subprocess.run without human approval or an allow-list, exposing environment secrets such as LLM API keys and database credentials. |
| JoySafeter through 1.0.0 contains a remote code execution vulnerability that allows authenticated users to run operating system commands via an unsandboxed execute tool in Copilot standard mode. Attackers can self-register, select standard mode in the WebSocket chat.start extension, and have the agent invoke subprocess.run with shell=True on the host to access other tenants' data and server secrets. |
| OpenSRE through 0.1.2026.10.19 contains an approval gate bypass vulnerability that allows attackers to execute shell_run commands without confirmation because the headless presenter's execution_allowed() always returns True. Attackers can inject instructions into alerts or Slack messages triaged by the agent to run commands on the host and exfiltrate LLM, Slack and cloud credentials. |
| EvoScientist 0.1.0 before 0.2.5 contains an approval bypass vulnerability that allows attackers to run host shell commands by delegating them to async sub-agents lacking an interrupt_on gate. Attackers can plant instructions in ingested content such as fetched web pages, so the agent calls start_async_task and runs commands with user privileges and environment secrets. |
| Letta through 0.16.8 contains an authentication bypass vulnerability that allows API callers to impersonate other users by supplying a self-asserted user_id HTTP header. Attackers can set user_id to another tenant's ID, even with LETTA_SERVER_SECURE enabled, to read and modify that user's agents, memory and configuration. |
| Letta through 0.16.8 contains an information disclosure vulnerability that allows users running tools to read server secrets because LocalSandbox subprocesses inherit the full server environment. Attackers can run code via POST /v1/tools/run or custom tools to read LETTA_PG_URI, POSTGRES_PASSWORD, and provider API keys, then access cross-tenant database data. |
| Summary
Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.
Root cause
*
HTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.
*
HTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.
*
The HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.
Impact
A remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:
*
Cache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host).
*
Host-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.
Deployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76
*
If you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'. |
| Summary
Before version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client's Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.
Impact
Specifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go's net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.
Note that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded , https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee
*
Do not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.
*
If you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers. |
| In the RingRTC library before 2.72.0 for Signal, a peer that saturates a call's FSM queue can interfere with the ability of a local hangup to tear the call (with its audio and perhaps also video track) down. |
| UnRTF by GNU Project is vulnerable to out-of-bounds write. If a user opens an RTF file crafted by an attacker, it may lead to a denial-of-service (DoS) condition. |
| Hidden functionality issue exists in Multiple DVRs (Digital Video Recorders) provided by Atsumi Electric Co., Ltd. A user who can log in to the product with the administrator privilege may upgrade the affected product to unauthorized firmware. |
| Hidden functionality issue exists in Multiple DVRs (Digital Video Recorders) provided by Atsumi Electric Co., Ltd. A user who can log in to the product with the administrator privilege may execute arbitrary OS commands. |
| The EventON - Subscriber plugin for WordPress is vulnerable to generic SQL Injection via the 'email' parameter in all versions up to, and including, 1.4.5 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. |
| The Easy Property Listings WordPress plugin before 3.5.28 does not restrict which listing fields it adds to the public REST API output, allowing unauthenticated users to read details a site has chosen to hide on published listings, such as the asking price, sold price, street address and exact map coordinates. |
| The Easy Property Listings WordPress plugin before 3.5.27 does not perform authorisation checks on several of its contact-management read AJAX actions, allowing any authenticated user with a role as low as subscriber to read other users' CRM contact and lead records, including their private activity notes. |
