CISA Confirms Gitea Is Actively Being Exploited, a Video Platform Vendor Won't Answer Its Own Bug Report, and One Webpage Visit Can Now Permanently Poison Your Local AI Agent

Start with the vulnerability that's already being exploited, not just disclosed. CISA added CVE-2026-60004, a critical code-injection flaw in Gitea, to its Known Exploited Vulnerabilities catalog on Tuesday, giving federal agencies until August 28 to patch. Gitea is the open-source, self-hosted alternative to GitHub and GitLab that a huge number of organizations run themselves specifically to keep their source code off someone else's cloud — and the bug, scored a near-maximum 9.8, sits in the diffpatch API endpoint that processes repository patches. An attacker with ordinary repository write access can submit a malicious patch that plants an executable Git hook, then runs arbitrary shell commands as the Gitea service account. The detail that turns this from "bad" into "reachable by basically anyone" is Gitea's default configuration: self-registration is enabled out of the box, meaning an unauthenticated visitor can simply create an account, spin up a new repository, and grant themselves exactly the write access the exploit chain requires — no prior credentials, no social engineering, just Gitea's own default settings working as designed.

We already have a concrete look at what exploitation looks like in practice. A developer posting on the Russian blogging platform Habr described their own Gitea instance getting hit: their hosting provider flagged the server for running at over 70% CPU utilization for an extended period, a violation of the hosting terms that triggered an investigation and led straight back to CVE-2026-60004 being used to drop a cryptocurrency-mining payload. Because Gitea was running inside an unprivileged Docker container, the miner didn't survive a restart — a small mercy that had nothing to do with the vulnerability itself and everything to do with how that particular server happened to be configured. Shadowserver currently tracks nearly 5,000 Gitea instances exposed to the open internet, with no visibility into how many are honeypots or already patched. If you're one of them, the fix is version 1.27.1 or later, but patching alone isn't the whole job here: any instance that had self-registration enabled and internet exposure during the vulnerable window should be treated as a potential incident-response case, not a routine update, since the exploit path required no credentials at all.

The second story is the kind that should worry you more than a flashier zero-day, precisely because there's no patch to apply. The CERT Coordination Center disclosed two vulnerabilities in Kaltura's HTML5 video player library — CVE-2026-19913 and CVE-2026-19912 — that let a completely unauthenticated, remote attacker read arbitrary files off a server and execute code on it. Both trace back to the same root cause: the player's mwEmbedLoader.php endpoint accepts a user-controlled ServiceUrl parameter, and Kaltura's own client library fetches whatever URL is supplied and blindly deserializes the response using PHP's unserialize() function, with no validation of source, scheme, or content. Point that parameter at a local file:// path, and a deserialization failure reflects the raw file contents straight back in the error message — an attacker can read database credentials, administrative secrets, or API keys this way alone. The second bug goes further: insufficient sanitization of a separate parameter lets an attacker use directory-traversal sequences to redirect where the application writes cache files, and on a default file-based cache backend, that translates into planting and executing a malicious PHP payload.

Here's the part that should genuinely concern anyone running Kaltura, or anyone whose vendor evaluation process assumes "we'll just wait for the patch": CERT/CC said plainly that it was "unable to reach Kaltura to coordinate these vulnerabilities." No patch exists, and there's no public indication one is coming. Making this materially worse, the affected endpoint is also exposed on Kaltura's shared, multi-tenant CDN infrastructure — meaning this isn't contained to individual self-hosted deployments, it potentially touches every customer sharing those hosts. CERT/CC's interim guidance is the only option on the table right now: restrict or disable external access to the mwEmbedLoader.php endpoint entirely, and if that's not feasible, enforce a strict allow-list on the ServiceUrl parameter that permits only legitimate backend API URLs. If Kaltura is anywhere in your video infrastructure, today is the day to implement that mitigation directly, because "wait for the vendor" isn't currently a functioning plan.

The third story carries the widest potential blast radius of the day simply because of how many applications run on the underlying framework. Vercel shipped patches for two critical Next.js vulnerabilities. The first, CVE-2026-75604, enables unauthenticated remote code execution specifically on Windows-hosted Next.js servers running both the Pages Router and App Router without Cache Components — Linux and macOS deployments aren't affected by this particular bug, but there's no workaround for the ones that are. A public proof-of-concept is already circulating on GitHub, validated against Next.js 16.2.11, which manipulates the server's page and app cache paths to achieve code execution. The second flaw, scored even higher at 9.5, lives in the image optimization pipeline: a vulnerability in the underlying libheif library (used via the sharp package) means a specially crafted AVIF image file can trigger remote code execution the moment Next.js's Image Optimization API processes it — no authentication needed, just an application willing to optimize an attacker-supplied image, which describes an enormous share of what Next.js sites actually do by default. Vercel's own managed hosting has already disabled AVIF processing across its Image Optimization service, so applications hosted directly on Vercel are protected without any action needed. Everyone self-hosting Next.js is not so lucky: patch to 15.5.24 or 16.3.3 immediately, and if you're running a Windows-hosted deployment specifically, treat this with real urgency given the public exploit code already available.

The fourth story is the one worth sitting with longest, because it's a preview of a threat category that's going to get much more common as local AI agents proliferate. Oasis Security, now part of Cyera, disclosed CVE-2026-65105 in NVIDIA NemoClaw, an open-source reference stack for running AI agents like OpenClaw inside NVIDIA's OpenShell sandboxes using a local Ollama instance for inference. The sandbox itself works as intended, walling off the file system, network, and processes the agent can touch. The problem is one configuration line: NemoClaw starts Ollama with OLLAMA_HOST=0.0.0.0:11434, binding the model server to every network interface on the machine rather than just localhost, and Ollama itself skips Host header validation on non-loopback bindings. That combination opens the door to DNS rebinding — a well-documented browser-based technique — letting an attacker-controlled webpage reach the Ollama API directly the moment someone simply visits it, no credentials, no download, no phishing link clicked.

Once an attacker has that access, they can rewrite the model's chat template — the layer that wraps every conversation before the model reads it — to silently inject hidden instructions. Oasis Security's finding on why this matters more than a typical prompt injection is the detail worth remembering: template poisoning survives even when the AI agent's own application sends its own system prompt on every request, because the poisoned template gets applied underneath that, invisible to anything inspecting the conversation at the API level. "The client cannot detect or prevent this," Oasis Security put it, "the template is a model-level property invisible to API consumers." A single drive-by webpage visit converts into a permanently, silently compromised agent that carries out an attacker's hidden instructions in every subsequent conversation — and since the whole point of an agent is that it has tools and access, a compromised agent inherits every permission it was ever granted. NemoClaw version 0.0.35 fixes this on macOS and Linux by rearchitecting the setup entirely — Ollama now binds to loopback only, with a token-gated reverse proxy handling anything that legitimately needs external access. Windows and WSL users have no fix at all; the current Windows release just adds a warning rather than a remediation. If NemoClaw or a similar local-Ollama agent setup is running anywhere in your environment, block untrusted access to port 11434 today, and if you're on Windows, treat the exposure as live until a real patch ships.

One more story broke as this article was going to press, and it's close to home for this site specifically. A pro-Russian hacktivist group calling itself Server Killers claimed on Telegram Wednesday to be behind an ongoing denial-of-service campaign against Norwegian government digital services, declaring what it called "cyberwar" on Norway. The group's stated motive, in its own words, is Norway and Ukraine renewing their defense and security cooperation agreement on August 23 — centered on a drone deal — with Norway continuing to strengthen Ukrainian defense capability through its Nansen program, the roughly NOK 275 billion Ukraine support package running through 2030. Prime Minister Jonas Gahr Støre and Ukrainian President Volodymyr Zelenskyy signed the underlying strategic partnership in Kyiv two days earlier.

The actual target has been the Norwegian Digitalisation Agency (Digdir), whose digital services are delivered through a private operating partner, Vivicta. The attack is now in its third day, arriving in waves rather than continuously, with affected services intermittently back online between hits. Norwegian police (Kripos) confirmed it has opened an investigation based on reports filed by Digdir and Vivicta covering denial-of-service activity against their infrastructure going back earlier in the summer, and Norway's domestic security service (PST) said it's informed and in contact with authorities on the matter. Server Killers has made similar claims before, attributing past attacks on Denmark, Poland, Romania, Spain, Canada, and the UK to those countries' support for Ukraine — a pattern of self-attribution worth treating with the appropriate skepticism it deserves: a hacktivist group's own Telegram claims about which attacks belong to them are not independently verified, and groups in this category have a documented incentive to claim credit broadly for attention regardless of their actual technical contribution. What is independently confirmed is the denial-of-service activity itself and the ongoing law enforcement investigation into it — the attribution to Server Killers specifically rests on the group's own word so far.

Five stories, one thread running under every single one: none of them required a genuinely novel attack technique, and every one of them was reachable specifically because a default configuration — open self-registration, an unvalidated URL parameter, a Windows-specific code path, a model server bound to every interface, or simply enough compromised or borrowed bandwidth to run a sustained flood — did exactly what it was built to do, or exactly what a determined attacker needed it to do. Gitea's registration flow worked. Kaltura's video player fetched the URL it was told to fetch. Next.js optimized the image it was given. NemoClaw's Ollama instance accepted the connection it was configured to accept. Attackers didn't need to break any of these systems. They needed to understand what each one was already willing to do, and ask.