Hot CVEs — July 2026: Five Critical Vulnerabilities Your Team Needs to Patch Right Now
The exploitation window has collapsed to hours. These five CVEs from 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. Here's what they are and what to do.
Hot CVEs — July 2026: Five Critical Vulnerabilities Your Team Needs to Patch Right Now
The exploitation window has collapsed. Disclosure-to-exploit timelines are measured in hours, not weeks. These five CVEs from late June 2026 span Git hosting, AI infrastructure, media processing, service mesh, and workflow automation — and every one of them has a fix available today. Here's what they are, why they matter, and what to do about each one.
Every month, thousands of new CVEs enter the vulnerability database. Most don't warrant immediate attention. These five do. They affect widely deployed open-source infrastructure — 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.
This is our July 2026 Hot CVEs roundup. Patch first, read second.
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
What It Is
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.
Why It's Dangerous
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).
What to Do
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) in app.ini. These mitigations reduce exposure but don't fully prevent exploitation by users with write access to existing repositories where rebase is enabled.
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
What It Is
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.
Why It's Dangerous
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.
What to Do
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, organizations should also audit their 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.
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
What It Is
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.
Why It's Dangerous
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.
What to Do
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.
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
What It Is
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.
Why It's Dangerous
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.
What to Do
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_count and max_request_headers_kb settings 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.
CVE-2026-47210 — n8n: Expression Injection to Remote Code Execution
Severity: CRITICAL (CVSS 9.8) | Published: June 12, 2026 | Fix: Yes | CISA KEV: No
What It Is
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.
Why It's Dangerous
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.
What to Do
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.
The Common Thread
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. They're foundational infrastructure. 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.
The exploitation window has collapsed to hours. Public proof-of-concept code appears within days. Automated scanning tools probe the entire internet for vulnerable instances continuously.
Patch now. Validate later. The order matters.
How Trusteed Helps You Stay Ahead
Tracking individual CVEs is necessary but insufficient. What organizations need is continuous, automated visibility into which of these vulnerabilities affect their specific environment — and which ones are actually exploitable.
Trusteed's CTEM platform provides exactly this:
Asset discovery finds every instance of Gogs, LiteLLM, FFmpeg, Envoy, and n8n running in your environment — including the ones your team didn't know about. Vulnerability scanning with over 100,000 checks detects these CVEs across infrastructure, web applications, and cloud configurations. Exploitability-aware prioritization combines CVSS severity with EPSS probability, KEV status, and business context to ensure your team patches what actually matters first. Change-triggered rescanning detects when new vulnerable instances appear and validates that patches actually worked. And noise-aware IP intelligence suppresses the commodity scanner traffic that buries real exploitation attempts in your SIEM.
Don't wait for the next Hot CVEs list. Start scanning for free or talk to an expert to see how Trusteed catches critical vulnerabilities before attackers weaponize them.
This post was published on the Trusteed Blog. Trusteed provides always-on agentic CTEM — discovering assets, scanning for vulnerabilities, prioritizing by exploitability, and verifying remediation — so your team patches what matters before the exploitation window closes.