Exposure to Detection in Under an Hour

A vulnerability becomes public at a specific moment. It becomes useful to an attacker shortly after that, and in several of the cases below the interval was short enough that the first public proof of concept and the first opportunistic scanning were the same afternoon. The number that decides your outcome is not the CVSS score. It is the gap between those moments and the moment you can answer a plain question: did this already happen here.

That question is answerable from telemetry you are probably already collecting, and the answer does not require the patch. What follows is six flaws we have reported on, what each one actually does at the protocol level, where it has been seen in the wild, how it ranks, and the detection logic that catches it. The queries are the ones our feed ships, written against OCSF-normalized data.

1. Oracle WebLogic, IIOP to unauthenticated compromise

CVE-2020-2551 is a deserialization flaw in the IIOP implementation of Oracle WebLogic Server. IIOP is the CORBA wire protocol, and WebLogic exposes it on the same default listener as T3, TCP 7001. An unauthenticated remote attacker who can reach that port can compromise the server. There is no credential step and no user interaction. The reason a 2020 identifier still matters is that WebLogic is middleware: it sits behind other things, it is rarely the system anyone is actively modernizing, and the listener is frequently reachable from more of the internal network than its owners believe.

We covered the family in our reporting on the Oracle WebLogic Proxy Plug-in flaw that CISA added to the Known Exploited Vulnerabilities catalog, rated CVSS 10.0, unauthenticated, and exploited in the wild. The pattern across that family is consistent: the exposure is a listener, not a web path, so it does not appear in web logs and it does not show up in the application dashboards anyone watches.

That also makes it one of the easier things to detect, because the signal is a connection rather than a payload. If nothing in your estate should be reaching a WebLogic IIOP listener, any connection to it is worth a look.

index=netsyslog dst_endpoint.port=7001

2. ownCloud, a 2023 bypass that exfiltrated nuclear research records

CVE-2023-49105 is an improper authentication flaw in ownCloud. The WebDAV and API endpoints accept pre-signed URL parameters, and the signature validation can be satisfied without valid credentials. An attacker who knows a username can construct a request carrying OC-Signature, OC-Credential, OC-Date, OC-Expires and OC-Verb parameters and then read, write, move or delete that user's files. Pre-signed URLs exist so that a client can hand a time-limited link to a third party. The flaw turns that convenience into unauthenticated file access.

This one is in the list because of where it went. We reported that a Chinese-speaking operator chained this 2023 bypass into the theft of 176 files, roughly 372 MB, from a Philippine nuclear research body. The vulnerability was three years old at the time of the intrusion and a patch had been available for most of that period. The gap that mattered was not the patch window. It was that nobody was watching WebDAV request parameters on a file-sync appliance.

The detection keys on the shape of the request rather than on any payload, which is what makes it durable: the parameter names are the flaw, and an attacker cannot avoid them while still exploiting it.

index=owncloud "cs-uri-stem" IN ("*/remote.php/dav/*", "*/remote.php/webdav/*", "*/dav/files/*")
  "cs-uri-query"="*OC-Signature=*" "cs-uri-query"="*OC-Credential=*"
  "cs-uri-query" IN ("*OC-Verb=PUT*", "*OC-Verb=DELETE*", "*OC-Verb=MOVE*", "*OC-Verb=COPY*")

3. ServiceNow AI Platform, unauthenticated code execution

CVE-2026-6875 is a code injection flaw, CWE-94, in the ServiceNow AI Platform, reachable by an unauthenticated attacker over the network. ServiceNow code injection has a long and specific shape: the platform evaluates Jelly templates, and expressions written as jelly:core tags, jvar references or gs. calls run server side. Historically these have been reached through endpoints that accept template content before an authentication decision has been made, which is why login.do and stats.do keep appearing in exploitation traffic for a platform that is otherwise well defended.

We reported this as one of three CVSS 10.0 flaws ServiceNow patched on 27 August 2026, all reachable without authentication, alongside a SQL injection in the same AI tier. The AI endpoints are the new part. A platform that was already a high-value target for identity and workflow data now has an additional unauthenticated surface attached to it, and that surface was added faster than most customers' review processes could evaluate it.

index=servicenow "cs-uri-stem" IN ("/login.do", "/stats.do", "/api/now/ai", "/api/sn_nowassist/ai")
  "cs-uri-query" IN ("*<j:jelly*", "*jelly:core*", "*${jvar_*", "*$[gs.*",
                     "*GlideRecord(*", "*gs.executeNow*", "*java.lang.Runtime*", "*ProcessBuilder*")

4. GitLab, a GraphQL directive that answers to nobody

CVE-2026-19478 is a GraphQL directive handling flaw in GitLab CE and EE. Affected builds run from 18.2 through 18.11.10, 19.0 through 19.0.7, 19.1 through 19.1.5, and 19.2 through 19.2.3. A directive in a GraphQL document is a modifier attached to a field or a fragment, and it is processed by the server before the resolver's own authorization logic runs. Mishandling one means a document can reach behavior it was never authorized for. In this case an unauthenticated remote user can modify or delete public projects and user data.

The significance is the blast radius rather than the access level. A Git forge is where build pipelines, deploy credentials and release history live, and project deletion is not a confidentiality problem, it is an availability and integrity problem that can take a release train down. We covered GitLab's CVSS 10.0 pre-auth file read in the commits API in the same period, which shipped with a three day patch window, so this is a product under sustained unauthenticated pressure rather than a single bad release.

The detection is deliberately simple. Anonymous POSTs to the GraphQL endpoint that succeed are worth reviewing on a self-managed instance, because on most deployments there should be very few of them.

(index=webserver OR index=web) "cs-method"="POST" "cs-uri-stem"="/api/graphql"
  "cs-username"="-" "sc-status" IN (200, 201)

5. Gitea, a patch API that writes an executable Git hook

CVE-2026-60004 is a code injection flaw in the Gitea diffpatch API. A caller with repository write access can submit a patch that writes an executable file into the repository's hooks directory. Git hooks execute on the server as part of normal repository operations, so a post-receive or update hook planted this way runs the next time anyone pushes. The path from write access to server-side code execution is short, and on an instance that allows open signup, write access to some repository is not a meaningful barrier.

We reported it as a CVSS 9.8 flaw under active exploitation, added to the CISA KEV catalog with a federal patch deadline of 28 August 2026, where open registration turns the signup form into the first step of the chain. Self-hosted Git forges tend to be run by the engineering organization rather than by IT, which usually means they are patched attentively and monitored barely at all.

(index=gitea OR index=web) "cs-method" IN ("POST", "PATCH", "PUT")
  "cs-uri-stem"="*/diffpatch*" "sc-status" IN (200, 201, 202, 204)
  OR "cs-uri-query" IN ("*.git/hooks*", "*hooks/post-receive*", "*hooks/pre-receive*", "*hooks/update*")

6. Claude Code, a worktree path confusion that escapes the sandbox

CVE-2026-55607 is a sandbox escape in Claude Code, tracked as GHSA-7835-87q9-rgvv. The mechanism is path confusion through Git worktrees: an attacker creates a worktree named .git, combines that with symlink manipulation, and reaches the Git fsmonitor execution path. The payoff is the ability to overwrite shell startup files, .zshenv in particular, which executes on the next non-interactive shell invocation. That is persistence on a developer workstation, reached from nothing more than a cloned repository.

We covered this alongside the broader Manifold Security disclosure of eight flaws across seven command line AI coding agents, where a repository's own .git configuration was enough to turn Claude Code, Codex and Cursor into attacker-controlled shells. The reason this belongs in the same article as a WebLogic listener is that it is the same category of mistake in a newer place: a tool that processes untrusted input from a repository, running with the privileges of the person who cloned it.

Developer endpoints are the weakest telemetry surface in most organizations, which is exactly backwards given what credentials live there.

index=macos TargetFilename="*/.git"
  OR TargetFilename IN ("*/.zshenv", "*/.zshrc", "*/.bash_profile", "*/.bashrc", "*/.profile")

What these six have in common

None of them required a novel technique. Every one is reachable by an unauthenticated or low-privilege caller, every one is detectable from telemetry most organizations already collect, and in every case the detection is a shape rather than a signature: a port, a set of query parameters, a template expression, an anonymous mutation, a path, a filename. Shapes survive repackaging in a way that hashes and payload strings do not.

They also share a failure mode. The WebLogic listener is not in web logs. The ownCloud parameters are in a file-sync appliance nobody forwards. The ServiceNow endpoints sit in a SaaS tenant. The Git forge is owned by engineering. The developer laptop is the least instrumented machine in the building. In each case the data needed to answer "did this happen here" exists somewhere, and the gap is that it has never been in one queryable place at one time.

Exposure to detection, in under an hour

This is the part we build for. When a flaw goes public, the useful output is not an advisory summary. It is a query that runs against your own data and returns rows or returns nothing, because either answer is actionable and the summary is neither. Our feed ships that query, as Sigma for portability and as Caver SPL for immediate execution, and it ships within the hour of public exposure rather than on the next content release cycle.

An hour is the right target because it is shorter than the interval that actually matters. The exploitation we keep reporting does not begin the moment a CVE is reserved. It begins when a working proof of concept circulates, and that is reliably measured in hours to days after disclosure, not minutes. A detection that arrives inside the hour is in place before the opportunistic scanning starts, which is the whole point. A detection that arrives next Tuesday is archaeology.

Every detection ships with the Caver SPL already written, which is the difference between receiving intelligence and receiving something you can run. A Sigma rule still has to be translated into whatever your platform speaks, and that translation is where most feeds quietly hand the work back to you.

Detection is half of it, response is the other half

A query that finds the pattern is worth something only if you can act on what it returns, and acting means three things in quick succession. Scope, which is every host and account that matched, not the first one. History, which is whether the pattern ran before you had the detection, since several of the flaws above were exploited for months before anyone wrote a rule. Containment, which is the decision you make with the first two in hand.

History is the one that gets skipped, and it is the one that decides whether you are responding to an incident or discovering you had one. Retrospective matching is a storage question before it is a detection question: a new rule is only as good as the window of data you kept, and most organizations quietly keep a shorter window than they believe because retention is priced per gigabyte and the bill decides the policy. Caver exists because that tradeoff is a false one. Cheaper storage and faster queries mean the window stays long enough that a rule written today can be run against the months before it existed.

That is the capability the six flaws above argue for. The ownCloud bypass was three years old when it was used against a nuclear research body. The Gitea flaw was exploited before its federal deadline. The WebLogic listener has been reachable in some estates since 2020. In each case the organization that does well is not the one that patched fastest. It is the one that could ask, on the day the advisory landed, whether it had already happened, and get an answer from data it still had.

RedEye can assess which of the three steps gives way first in your environment, and where your current retention stops a retrospective question from being answerable at all.