Hot CVEs — July 2026: Five Critical Vulnerabilities Your Team Needs to Patch Right Now
Five CVEs from late June 2026 affect foundational open-source infrastructure — Git hosting, AI gateways, media processing, service mesh, and workflow automation. Each has a fix available, public PoC code circulating, and a blast radius measured in thousands of exposed instances.
Hot CVEs — July 2026: Five Critical Vulnerabilities Your Team Needs to Patch Right Now
TL;DR
Five critical vulnerabilities disclosed in late June 2026 affect widely deployed open-source infrastructure: Gogs (CVSS 9.9), LiteLLM (CVSS 9.5), FFmpeg (CVSS 8.8), Envoy (CVSS 7.5), and n8n (CVSS 9.8). Every one has a fix available today, and public proof-of-concept code is already circulating for several. The exploitation window has collapsed to hours, with automated scanning tools probing the internet continuously for vulnerable instances. Patch first, read second.
What this is
This is a roundup of five CVEs from late June 2026 that warrant immediate attention. They affect foundational open-source infrastructure — Git hosting, AI gateways, media processing, service mesh, and workflow automation — the kind of software that runs quietly in the background of production environments until someone weaponizes a flaw and it becomes the loudest thing in the building. Each entry covers what the vulnerability is, why it is dangerous, and what to do about it.
Why it matters
These five CVEs share a pattern that defines the vulnerability landscape in 2026: widely deployed open-source infrastructure with massive blast radius. Gogs hosts source code — the crown jewel of any software organization. LiteLLM proxies every LLM API call in your AI stack. FFmpeg processes media in hundreds of downstream applications. Envoy routes traffic for entire microservice architectures. n8n orchestrates workflows across 400+ integrated services with stored credentials for each one. None of these are niche tools. A single vulnerability in any of them cascades through the supply chain to affect thousands of downstream deployments. And in every case, the exploitation barrier is low: a pull request, a manipulated header, a crafted video file, a malicious HTTP/2 request, a workflow expression. Public proof-of-concept code appears within days, and automated scanning tools probe the entire internet for vulnerable instances continuously.
How it works
CVE-2026-52806 — Gogs: One Pull Request to Own the Server
Severity: CRITICAL (CVSS 9.9) | Published: June 23, 2026 | Fix: Yes (v0.14.3) | CISA KEV: No
An argument injection vulnerability (CWE-88) in Gogs, one of the most popular self-hosted Git services with roughly 50,000 GitHub stars and over 1,100 internet-facing instances visible on Shodan. The flaw allows any authenticated user to achieve remote code execution on the server by creating a pull request with a malicious branch name that injects the --exec flag into the git rebase command during a "Rebase before merging" operation.
This vulnerability is self-contained and requires zero interaction from other users. The attacker operates entirely within their own account and repository. Since Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1), an unauthenticated attacker can simply create an account, create a repository, enable rebase merging, and exploit the flaw — all without any administrator involvement.
Successful exploitation grants arbitrary command execution as the Gogs process user (typically git), enabling full server compromise, cross-tenant data breach (reading all private repositories on the instance), credential theft (password hashes, API tokens, SSH keys, 2FA secrets), lateral movement to network-accessible systems, and silent code modification in any hosted repository for supply chain attacks.
Rapid7, who discovered the vulnerability, has released a Metasploit module that automates the full exploit chain. Public proof-of-concept code is available for all three Gogs RCE vulnerabilities disclosed alongside this one (CVE-2026-52813 and CVE-2026-52811).
CVE-2026-49468 — LiteLLM: Authentication Bypass via Host Header Injection
Severity: CRITICAL (CVSS 9.5) | Published: June 22, 2026 | Fix: Yes (v1.84.0) | CISA KEV: No
An authentication bypass vulnerability in LiteLLM, the widely used AI Gateway and proxy server that provides a unified OpenAI-compatible API for calling multiple LLM providers. The flaw resides in the get_request_route() function in LiteLLM's proxy authentication layer, where the application determines the request path using request.url.path. In Starlette-based applications, this path can be reconstructed using the client-supplied Host header, allowing an attacker to manipulate request routing and bypass authentication entirely.
LiteLLM sits at the center of AI infrastructure for thousands of organizations. It's the gateway between applications and LLM providers — handling API keys, routing decisions, usage tracking, and access controls. An authentication bypass at this layer exposes every LLM credential, every API key, and every model interaction flowing through the proxy.
The vulnerability requires no authentication (PR:N), no user interaction (UI:N), and has low attack complexity (AC:L), making it remotely exploitable under specific deployment conditions. This is the latest in a troubling pattern for LiteLLM — the project has accumulated 16 CVEs across 2024–2026, including three Critical-rated advisories and a supply chain compromise in March 2026 where two published PyPI packages contained credential-harvesting malware.
CVE-2026-8461 — FFmpeg "PixelSmash": A 50KB Video File That Owns Your Server
Severity: HIGH (CVSS 8.8) | Published: June 18, 2026 | Fix: Yes (v8.1.2) | CISA KEV: No
A heap out-of-bounds write vulnerability in FFmpeg's MagicYUV decoder (libavcodec/magicyuv.c), dubbed "PixelSmash" by its discoverers at JFrog Security Research. The flaw stems from a rounding mismatch between how FFmpeg's frame allocator and the MagicYUV decoder compute chroma plane heights when processing video slices. A crafted AVI, MKV, or MOV file — as small as 50KB — triggers 640 fully attacker-controlled bytes of heap overflow.
FFmpeg is arguably the most widely deployed media processing framework in the world. It's bundled into or linked by virtually every application that handles video — from desktop players (Kodi, mpv, VLC) to Linux thumbnail generators (GNOME, KDE, XFCE file managers), self-hosted media servers (Jellyfin, Emby, Nextcloud, Immich, PhotoPrism), streaming infrastructure (OBS Studio), chat platforms (Slack, Discord, Telegram, WhatsApp use FFmpeg for server-side video previews), and AI/ML pipelines (vLLM and other frameworks that process video data).
This is a supply chain vulnerability: a single bug in a single codec decoder inside FFmpeg cascades to every application that links libavcodec. The MagicYUV decoder is enabled by default in every upstream FFmpeg build.
JFrog demonstrated full remote code execution against Jellyfin 10.11.9 and Nextcloud by simply uploading a crafted AVI file. On Jellyfin, the automated library scan triggered ffprobe, which processed the malicious file and allowed the attacker to hijack execution flow. The exploit requires ASLR to be disabled or a separate information disclosure bug to be chained for ASLR bypass — but even with ASLR enabled, the vulnerability reliably causes denial-of-service through crashes and silent heap corruption. Four public proof-of-concept exploits are already available on GitHub.
CVE-2026-47774 — Envoy: HTTP/2 Cookie Header DoS (Zero-Day)
Severity: HIGH (CVSS 7.5) | Published: June 17, 2026 | Fix: Yes | CISA KEV: No
A denial-of-service vulnerability in Envoy, the high-performance edge and service proxy that powers a significant portion of modern cloud-native infrastructure including AWS App Mesh, Google Cloud's Traffic Director, and Istio service mesh. The flaw allows an attacker to craft a malicious HTTP/2 request with a specially constructed cookie header that causes resource exhaustion and service disruption.
Envoy sits at the network edge of cloud-native architectures. It handles ingress traffic, service-to-service communication, and load balancing for microservice deployments across AWS, GCP, and Azure. A DoS vulnerability at this layer can take down entire service meshes, disrupting all applications routing through the affected proxy.
The vulnerability is a confirmed zero-day — it was observed in the wild before the patch was available. Envoy maintainers published mitigation patches that make cookie header count and overall size subject to Envoy's header map limits. However, early deployment of the mitigation revealed an important operational consideration: the fix can inadvertently affect legitimate traffic. By default, Envoy limits total header count to 100 and overall header size to 60KB. Applications that use a high number of individual cookies or very large cookies can exceed these limits after the mitigation is applied, resulting in legitimate requests being reset. The vulnerability also affects AWS ECS Service Connect Agent, which bundles Envoy for service mesh functionality in Amazon's container orchestration platform.
CVE-2026-47210 — n8n: Expression Injection to Remote Code Execution
Severity: CRITICAL (CVSS 9.8) | Published: June 12, 2026 | Fix: Yes | CISA KEV: No
A remote code execution vulnerability in n8n, the open-source workflow automation platform with over 57,000 weekly npm downloads and 100,000+ internet-facing instances. The flaw exists in n8n's expression evaluation system, where user-supplied JavaScript expressions during workflow configuration are evaluated in an execution context that is not sufficiently isolated from the underlying runtime. An authenticated user with workflow creation or editing permissions can exploit this to execute arbitrary operating system commands with the privileges of the n8n process.
n8n is increasingly deployed as the central orchestration layer for business process automation, AI agent workflows, and security operations. It integrates with over 400 third-party services — including cloud providers, databases, communication platforms, CRM systems, and payment processors. A successful compromise of an n8n instance doesn't just give the attacker control of the server. It gives them access to every credential stored in n8n's database: AWS keys, database passwords, OAuth tokens, API keys for every connected service.
This is the latest in a series of critical RCE vulnerabilities affecting n8n. Prior flaws include CVE-2025-68613 (CVSS 9.9, expression injection), CVE-2026-27577 (sandbox escape), CVE-2026-27493 (double-evaluation in Form nodes enabling unauthenticated exploitation), and CVE-2026-27497 (SQL query mode code execution). The pattern is consistent: n8n's core value proposition — executing user-defined logic across integrated services — creates a fundamentally large attack surface when expression evaluation isn't properly sandboxed. The Canadian Centre for Cyber Security and multiple national CERTs have issued advisories for n8n vulnerabilities. Resecurity identified over 103,000 potentially vulnerable n8n instances globally.
Detection and response
The hypothesis for each of these CVEs is that a vulnerable instance is reachable and exploitable in your environment; the evidence that confirms or rejects it is an exposed asset, a version match, a response difference, or an advisory match.
For CVE-2026-52806, look for internet-facing Gogs instances and confirm the running version is below 0.14.3; check whether open registration is enabled and whether rebase merging is available.
For CVE-2026-49468, identify LiteLLM proxies exposed to the internet and verify the version is below 1.84.0; check whether the deployment sits behind a CDN, WAF, or reverse proxy that enforces strict Host header validation.
For CVE-2026-8461, inventory every application that bundles or links FFmpeg and verify the bundled version is below 8.1.2; check whether untrusted media uploads are accepted and whether AVI, MKV, or MOV formats are essential to operations.
For CVE-2026-47774, identify Envoy deployments and confirm whether the mitigation patches have been applied; review cookie usage to determine whether legitimate requests would exceed the default header count limit of 100 or the 60KB overall header size limit after the fix.
For CVE-2026-47210, identify internet-facing n8n instances and verify the version is patched; check which users have workflow creation or editing permissions and whether credentials are stored in the n8n database.
What to do
Gogs (CVE-2026-52806): Upgrade to Gogs 0.14.3 immediately. If you cannot upgrade right away, disable open registration (
DISABLE_REGISTRATION = true) and restrict repository creation (MAX_CREATION_LIMIT = 0) inapp.ini. These mitigations reduce exposure but don't fully prevent exploitation by users with write access to existing repositories where rebase is enabled.LiteLLM (CVE-2026-49468): Upgrade to LiteLLM version 1.84.0. The fix requires no configuration changes. If immediate upgrade isn't possible, place the LiteLLM proxy behind a trusted upstream component (CDN, WAF, reverse proxy) that enforces strict Host header validation. Environments already behind CDNs, WAFs, or load balancers with host-based routing are naturally resistant to this attack. LiteLLM Cloud customers are unaffected. Given LiteLLM's security history, audit your deployment for any exposure to the March 2026 supply chain compromise (versions 1.82.7 and 1.82.8) and rotate any credentials that may have been observed by the malicious packages.
FFmpeg (CVE-2026-8461): Upgrade FFmpeg to version 8.1.2 or later. Identify all applications in your environment that bundle or link FFmpeg and verify their bundled version. Jellyfin has updated its bundled FFmpeg. PhotoPrism is implementing format blocklists. For systems where patching isn't immediately feasible, consider blocklisting AVI, MKV, and MOV formats if they're not essential to operations, and restrict untrusted media file uploads.
Envoy (CVE-2026-47774): Apply the patches published by Envoy maintainers. Before deploying, evaluate your application's cookie usage: if a client sends 90 cookie crumbs and 15 other headers, the request will exceed the default header count limit of 100 and be rejected. Adjust
max_request_headers_countandmax_request_headers_kbsettings as needed for your application profile. For environments where the fix cannot be immediately applied, consider implementing HTTP/2 cookie header inspection at the load balancer or WAF layer upstream of Envoy.n8n (CVE-2026-47210): Update n8n to the latest patched version immediately. If immediate patching is not possible, restrict workflow creation and editing permissions to fully trusted users only, and deploy n8n in a hardened environment with restricted OS privileges and network access. Rotate any credentials stored in n8n's database, especially if you suspect your instance may have been exposed. These workarounds do not fully eliminate the risk and should only be used as short-term measures.
FAQ
What are the five CVEs in this roundup?
CVE-2026-52806 (Gogs, CVSS 9.9), CVE-2026-49468 (LiteLLM, CVSS 9.5), CVE-2026-8461 (FFmpeg, CVSS 8.8), CVE-2026-47774 (Envoy, CVSS 7.5), and CVE-2026-47210 (n8n, CVSS 9.8).
Do all five have fixes available?
Yes. Gogs is fixed in v0.14.3, LiteLLM in v1.84.0, FFmpeg in v8.1.2, Envoy has patches published by its maintainers, and n8n has a patched version available.
Are any of these on the CISA KEV catalog?
No. None of the five is listed on CISA KEV as of publication.
Which of these have public proof-of-concept code?
Public proof-of-concept code is available for all three Gogs RCE vulnerabilities disclosed alongside CVE-2026-52806 (CVE-2026-52813 and CVE-2026-52811). Rapid7 has released a Metasploit module that automates the full exploit chain for CVE-2026-52806. Four public proof-of-concept exploits are already available on GitHub for CVE-2026-8461.
What is the common thread across these five CVEs?
They are all widely deployed open-source infrastructure with massive blast radius. A single vulnerability in any of them cascades through the supply chain to affect thousands of downstream deployments, and the exploitation barrier is low in every case.
What should I do first?
Patch now. Validate later. The order matters. Each entry above lists the specific upgrade version and any interim mitigations if immediate patching is not possible.