Last updated: July 5, 2026 at 9:01 AM UTC
All 557 Vulnerability 199 Breach 106 Threat 245 Defense 7
Tag: rce (62 articles)Clear

ChromaDB CVE-2026-45829: unauthenticated RCE via pre-auth model load - 73% of internet-exposed servers vulnerable

HiddenLayer has disclosed a maximum-severity unauthenticated remote-code-execution vulnerability, CVE-2026-45829, in ChromaDB's Python FastAPI server. ChromaDB is one of the most popular vector databases backing retrieval-augmented-generation pipelines, with about 14 million monthly PyPI downloads. A vulnerable endpoint marked as authenticated lets an attacker embed model settings before authentication is checked, so a crafted request makes ChromaDB load a malicious model from Hugging Face and execute it locally. The auth check fires only after the payload has already run. The bug was introduced in 1.0.0 and was still present in 1.5.8. HiddenLayer's Shodan sweep shows ~73% of internet-exposed Chroma instances are vulnerable.

Check
List Python ChromaDB deployments and versions. Check whether the FastAPI HTTP server is reachable beyond its host network. Capture access logs to /api/v1/auth endpoints since 2026-02-17.
Affected
ChromaDB Python FastAPI server 1.0.0 through at least 1.5.8 (1.5.9 status unclear) that exposes the HTTP server to the network. Rust frontend and local-only Python deployments are not affected.
Fix
Move to the Rust frontend, or take the Python HTTP server off the network and front it with an authenticated reverse proxy. Restrict the ChromaDB API port to localhost or VPC-only.

SEPPmail Secure Email Gateway RCE chain allows attacker to read all mail traffic and persist on the gateway

Researchers have disclosed a chain of vulnerabilities in SEPPmail Secure Email Gateway that lets an attacker turn unauthenticated web requests into remote code execution by inflating the SEPPMaillog file past its 10,000 KB limit, which forces newsyslog to rotate logs and signal syslogd to reload its configuration. Combined with the other flaws in the chain, the attacker reads all mail traffic on the appliance and persists indefinitely. SEPPmail has patched CVE-2026-44128 in version 15.0.2.1, CVE-2026-44126 in 15.0.3, and the rest in 15.0.4. The disclosure follows last month's CVE-2026-27441 (CVSS 9.5) OS command-execution fix in the same appliance.

Check
Inventory SEPPmail Secure Email Gateway appliances and exact versions. Pull web access logs for unusually large or repeated requests that could bloat SEPPMaillog past its rotation threshold.
Affected
SEPPmail appliances on versions earlier than 15.0.4. Last month's CVE-2026-27441 (CVSS 9.5) OS-command-execution flaw in the same product remains relevant if unpatched.
Fix
Upgrade SEPPmail to 15.0.4 immediately. If you cannot, restrict admin and webmail interfaces to a management VLAN behind VPN and monitor log file sizes for unusual growth.

NGINX 'Rift' heap overflow CVE-2026-42945 now seeing exploitation attempts in VulnCheck honeypots

The 18-year-old heap overflow in NGINX's rewrite module, CVE-2026-42945, disclosed last week as part of the 'Rift' bug cluster, is now seeing real exploitation attempts. AI-native security firm VulnCheck says its honeypot networks have caught attackers probing the flaw, though the goal of the campaigns is not yet clear. The vulnerability lets an unauthenticated attacker crash NGINX worker processes by sending crafted HTTP requests. Turning that crash into remote code execution requires the target host to have Address Space Layout Randomization (ASLR) disabled, which is uncommon by default, but the worker-crash denial-of-service is exploitable on its own and rated urgent.

Check
Search NGINX error logs for unusual worker crashes since 2026-05-13. Identify servers running NGINX open source before 1.30.1/1.31.0 or NGINX Plus before R32 P6 / R36 P4.
Affected
NGINX open source 0.6.27 through 1.30.0; NGINX Plus R32 through R36. Exploitable for DoS by default; RCE requires ASLR disabled on the target host.
Fix
Upgrade open source NGINX to 1.30.1 (stable) or 1.31.0 (mainline), or NGINX Plus to R32 P6 / R36 P4. Confirm ASLR remains enabled (default on supported Linux distributions).

openDCIM RCE chain weaponized in the wild - Chinese attacker uses AI vuln scanner Vulnhuntr to drop PHP web shells

VulnCheck says attackers are chaining three critical bugs (CVE-2026-28515, CVE-2026-28517, CVE-2026-28516) in openDCIM, an open-source data center management web app, to drop PHP web shells on exposed installs. All three rate CVSS 9.3 and cover missing authorization, OS command injection, and SQL injection. They can be combined over five HTTP requests to land a reverse shell. The activity comes from a single Chinese IP using what VulnCheck describes as a customized version of Vulnhuntr, a public AI-driven vulnerability discovery tool. The campaign is one of the first publicly documented cases of an open-source AI vuln scanner being repurposed for real-world exploitation.

Check
Identify openDCIM installs in your environment (check internal asset inventory and external attack surface). Review web server logs for /report_network_map.php access patterns since February 2026.
Affected
openDCIM versions before the February 2026 fix that addressed CVE-2026-28515, CVE-2026-28517, and CVE-2026-28516. Internet-exposed instances are at highest risk.
Fix
Upgrade openDCIM to the patched release. Remove internet exposure and put the app behind an authenticated reverse-proxy or VPN. Block the Chinese IP cluster VulnCheck has flagged.

NGINX Rift: 18-year-old heap overflow in the rewrite module lets anyone on the internet crash or take over an NGINX server (CVE-2026-42945)

An AI-discovered bug hidden in NGINX since 2008 lets anyone on the internet crash NGINX worker processes or, with ASLR disabled, run code on the server using a single crafted HTTP request. The flaw, named NGINX Rift (CVE-2026-42945, CVSS 9.2), sits in the rewrite module that powers URL rewriting in almost every NGINX deployment. It triggers when a config uses a rewrite directive with unnamed regex captures and a question mark, followed by another rewrite, if, or set directive - a common pattern in API gateway setups. NGINX runs roughly a third of the websites on the public internet.

Check
Grep your NGINX configs for rewrite directives that combine unnamed captures ($1, $2) with question marks in the replacement, and inventory the NGINX version on every reverse proxy you operate.
Affected
NGINX Open Source 0.6.27 through 1.30.0; NGINX Plus R32 through R36; NGINX Instance Manager, App Protect WAF, Gateway Fabric, and Ingress Controller across multiple versions.
Fix
Upgrade NGINX Open Source to 1.31.0 or 1.30.1; NGINX Plus users to R36 P4 or R32 P6. If patching is delayed, swap unnamed captures for named captures ((?<name>...)) in every affected rewrite directive.

Critical Ollama flaw lets unauthenticated attackers read server memory - 300,000 instances exposed (CVE-2026-7482)

Researchers at Cyera disclosed a critical bug in Ollama, the open-source tool that runs large language models locally on laptops and servers. The flaw, called Bleeding Llama (CVE-2026-7482), lets anyone with network access send a malformed model file and read raw process memory back - which typically contains API keys, environment variables, system prompts, and other users' chat history. Ollama ships without authentication by default, so an estimated 300,000 instances are exposed on the internet. Ollama 0.17.1 fixes it. Separately, Striga disclosed two unpatched Ollama Windows desktop flaws (CVE-2026-42248 and CVE-2026-42249) that chain into persistent code execution at login.

Check
Inventory all Ollama instances across servers and developer laptops. Check whether any are reachable from outside their host or trusted network, and verify the running version.
Affected
Ollama versions before 0.17.1 on every platform (CVE-2026-7482, CVSS 9.1, unauthenticated heap out-of-bounds read in the GGUF model loader exploitable via /api/create and /api/push). Ollama Windows desktop client on all currently-released builds (CVE-2026-42248 and CVE-2026-42249, CVSS 7.7 each, unpatched). Internet-exposed and developer-laptop instances are at highest risk.
Fix
Upgrade all Ollama servers to 0.17.1 or later immediately to fix Bleeding Llama. Restrict the Ollama API to localhost or an internal network only - never expose port 11434 to the internet. Place an authenticating reverse proxy in front of any shared Ollama deployment. For Windows desktop clients, monitor for an update that addresses CVE-2026-42248 and CVE-2026-42249; consider blocking auto-update traffic until a patched build ships.

Apache web server has a critical flaw in HTTP/2 that crashes servers and could let attackers run code (CVE-2026-23918)

Apache patched a double-free vulnerability in mod_http2 yesterday. CVE-2026-23918 (CVSS 8.8) lets a remote attacker crash the server immediately, with a path to remote code execution under specific memory-layout conditions. The bug is in the stream cleanup code in h2_mplx.c and is triggered by a crafted sequence of HTTP/2 frames including an early stream reset. mod_http2 ships in default Apache builds and HTTP/2 is widely enabled in production. The MPM prefork worker is not affected. Researchers warn practical RCE requires an info leak and probabilistic heap spray, but in lab conditions execution lands in minutes.

Check
Identify Apache HTTP Server 2.4.66 installations. Run 'httpd -v' or 'apache2 -v' on each server, and check whether mod_http2 is enabled with 'apache2ctl -M | grep http2'.
Affected
Apache HTTP Server 2.4.66 with mod_http2 enabled (default in most builds). CVE-2026-23918, CVSS 8.8. The MPM prefork worker is not affected; MPM event and worker (default in modern installs) are vulnerable. No public proof-of-concept yet but exploitation is straightforward for DoS. Internet-facing Apache servers running HTTP/2 are at acute risk.
Fix
Upgrade to Apache HTTP Server 2.4.67. If immediate upgrade isn't possible, disable mod_http2 with 'a2dismod http2' - but this drops HTTP/2 support entirely. The 2.4.67 release also patches mod_rewrite (CVE-2026-24072), mod_proxy_ajp (CVE-2026-28780), mod_md, and mod_dav_lock - apply all fixes together.

Google patched a critical 'Gemini CLI' bug that let attackers run code on developer machines through CI pipelines (CVSS 10.0)

Google patched a critical flaw in Gemini CLI, the command-line tool developers use to interact with Gemini models from CI pipelines and dev workstations. CVSS 10.0. The bug let an attacker execute arbitrary code on the developer's machine by feeding crafted input to the CLI - specifically through the same pattern that compromised LiteLLM and several other AI tools recently. A separate but related set of flaws in Cursor, the AI-powered IDE, also enables code execution. The pattern across all these AI dev tools is the same: input validation gaps where attacker-controlled prompts or model output reach a shell or code execution path.

Check
Upgrade Gemini CLI on every developer machine and CI runner today, and update Cursor to the latest version through the in-app updater.
Affected
Developers and CI/CD pipelines using Gemini CLI before the May 2026 patch. Cursor IDE users on versions before the recent security release. The broader pattern affects every AI command-line tool and IDE extension that processes untrusted input - LiteLLM, LMDeploy, MCP servers, Anthropic's MCP STDIO design, and the npm @validate-sdk/v2 trojan share the same root cause.
Fix
Upgrade Gemini CLI and confirm via 'gemini --version'. Update Cursor through the in-app updater. For CI pipelines, pin Gemini CLI version and rebuild base images. Treat all AI CLI tools as code execution surfaces and run them in sandboxed environments. Audit for any unusual outbound connections from dev machines or CI runners that ran Gemini CLI in the past month.

GitHub patched a flaw in March that let any developer take over millions of repos with a single 'git push' - 88% of self-hosted GitHub Enterprise Servers still haven't installed the fix (CVE-2026-3854)

Update on the GitHub flaw covered yesterday: Wiz, who found the bug, published its full disclosure showing 88% of self-hosted GitHub Enterprise Servers were still unpatched at public disclosure on April 28. The bug let any user with push access to one repository run code on the GitHub server itself with a single 'git push'. On GitHub.com, the same bug exposed millions of public and private repositories belonging to other users sharing the same storage node. GitHub.com was patched within 75 minutes, but Enterprise Server installs need patching manually. Wiz found the bug using AI-augmented reverse engineering on closed-source GitHub binaries.

Check
If you run a self-hosted GitHub Enterprise Server, check today whether you're on a patched version and upgrade if not.
Affected
Self-hosted GitHub Enterprise Server instances on versions before the March 2026 patches. CVSS 8.7. Wiz data shows 88% of GHES instances were unpatched at disclosure. The bug needs push access to any repository, including one the attacker creates themselves. GitHub.com and Enterprise Cloud variants are already patched.
Fix
Upgrade to GHES 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0, or later. Audit /var/log/github-audit.log for push operations with semicolons or unusual special characters in push option values - that's the exploit signature. Until patched, restrict push access and remove unnecessary repository creators.

Critical GitHub flaw lets a single 'git push' run code remotely on the server - patched, but most self-hosted GitHub Enterprise instances haven't updated yet (CVE-2026-3854)

Researchers disclosed CVE-2026-3854, a critical GitHub Enterprise Server flaw that lets anyone with push access execute arbitrary commands on the GitHub server with a single git push. The bug is in how Enterprise Server handles repository hooks during push operations - a crafted commit message or filename bypasses the sanitization that normally prevents shell injection. GitHub patched it last week, but self-hosted instances need to apply the patch manually, and telemetry shows most haven't yet. Anyone with developer-level access to a vulnerable Enterprise Server can take over the entire instance, then pivot into every repository and CI/CD secret it hosts.

Check
If you run a self-hosted GitHub Enterprise Server, apply the latest patch this week and review push activity from any low-privilege accounts since the patch was released.
Affected
Self-hosted GitHub Enterprise Server instances on versions before the April 2026 patch. The bug requires push access to any repository, which means every developer with commit rights is a potential entry point. CI/CD secrets, signing keys, and source code are exposed. GitHub.com (the SaaS product) is not affected.
Fix
Upgrade GitHub Enterprise Server to the patched release per GitHub's advisory. Until patched, restrict push access to trusted accounts and require code review on all pushes. Audit Enterprise Server logs for unusual git operations or shell processes spawning from the GitHub system user. Rotate any CI/CD secrets, signing keys, and webhook tokens stored on the server.