Critical Apache bRPC Flaw Turns Heap Profiling Endpoint Into Remote Code Execution Vector

According to research from Simcha Kosman, a senior cyber researcher at CyberArk Labs, a critical remote code execution flaw in Apache bRPC has put a spotlight on a class of debugging features that quietly sit inside many production systems, rarely scrutinized until something goes wrong.

Tracked as CVE-2025-60021 and scored at a near-maximum CVSS 9.8, the vulnerability affects all versions of Apache bRPC prior to 1.15.0. It stems from a command injection issue in the framework’s /pprof/heap endpoint, a diagnostic interface designed to help engineers analyze memory usage in running services. When reachable, the flaw allows an attacker to execute arbitrary commands with the privileges of the bRPC process, effectively handing over control of the service.

Debugging tools that never quite leave production

Apache bRPC is widely used in high-performance backend environments where services need to communicate with minimal latency. Like many modern RPC frameworks, it ships with built-in profiling and debugging endpoints under /pprof/*, enabling engineers to gather CPU and memory snapshots without stopping or attaching debuggers to live systems.

These endpoints are typically intended for internal or administrative networks, but in practice they often remain enabled in production. Misconfigurations can expose them to the public internet, and even when they are kept internal, they still present an attractive target for insiders, compromised services, or attackers who have already gained a foothold.

The /pprof/heap endpoint is particularly sensitive because it executes an external profiling tool to generate heap reports. That execution path is where things went wrong.

How a profiling option became an attack vector

At the core of CVE-2025-60021 is a parameter called extra_options, meant to let engineers tweak how heap profiling is performed. In vulnerable versions of bRPC, user-supplied values for this parameter were appended directly to a command string without validation.

Because the resulting command was later executed by the system, an attacker could inject shell metacharacters into extra_options and alter what actually ran. If the endpoint was reachable over HTTP, that translated directly into remote code execution.

A trivial example shows how an injected option could create arbitrary files on the server. More sophisticated payloads could just as easily install backdoors or pivot deeper into a backend environment.

Exposure in the wild

Debugging endpoints are not supposed to be internet-facing, but scans suggest that reality does not always match intent. At the time of analysis, Shodan reported hundreds of publicly reachable /pprof/* endpoints, including nearly two hundred /pprof/heap instances. While those numbers do not confirm how many systems are running vulnerable versions of Apache bRPC, they underscore how often profiling interfaces end up exposed.

Even in environments where access is limited to internal networks, the risk remains. Backend services often run with elevated privileges, and compromising one can provide a launchpad to much more sensitive infrastructure.

Fixes, mitigations, and defense in depth

The Apache bRPC maintainers addressed the issue in version 1.15.0 by replacing the free-form extra_options handling with a strict allowlist of supported profiling flags. That change prevents untrusted input from ever being incorporated into an executed command. The fix was merged in pull request #3101 and released publicly before the CVE was disclosed.

Users who cannot immediately upgrade are advised to apply the patch directly and to take additional hardening steps. Security teams recommend treating /pprof/* endpoints as admin-only surfaces, binding them to localhost, restricting access at the network layer, or placing them behind authenticated reverse proxies. In many production environments, disabling heap profiling entirely unless it is actively needed is the safest option.

AI-assisted vulnerability discovery

The bug was uncovered during a broader analysis of diagnostic and debugging surfaces using Vulnhalla, an internal tool developed by CyberArk Labs. Vulnhalla runs CodeQL queries at scale and applies a large language model to help triage which findings are most likely to be exploitable. In this case, the tool flagged the pattern for manual review, leading researchers to confirm the command injection path.

The disclosure followed coordinated vulnerability disclosure best practices, with the issue reported to the Apache bRPC maintainers in August 2025, fixed in September, released in October, and publicly assigned a CVE in January 2026.

The incident serves as a reminder that observability and debugging features, while invaluable to engineers, can quietly become high-impact attack surfaces when they are left exposed or insufficiently hardened.