CVE-2026-108602: DNS-Based SSRF in Helicone’s Jawn Webhook Sender Reaches Internal HTTPS Services

Summary

Helicone through version v2025.08.21-1 contains a server-side request forgery vulnerability, classified as CWE-918, in the webhook sender of its Jawn service. According to the vulnerability description, an authenticated organization user can abuse the webhook feature by supplying hostnames that resolve to private addresses. In the more advanced variant, a public hostname is made to DNS-rebind to a loopback or internal address, causing the Jawn webhook sender to fire blind POST requests at internal HTTPS services.

The issue was discovered by HaiND from the Post and Telecommunication Institute of Technology, and the CVE was assigned by VulnCheck, which also published an advisory. CVSS v4.0 scores the vulnerability 5.3 out of 10 (Medium) with the vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. In plain terms: the flaw is reachable over a network, requires no user interaction and no special preconditions beyond low privileges (a regular organization account), and its assessed impact is a low integrity effect on the vulnerable system, with no confidentiality or availability impact scored.

Technical Analysis

CWE-918 covers server-side request forgery: a class of flaws in which a server feature accepts a user-controlled URL and makes the server itself issue requests to it, letting an attacker reach network locations that are only reachable from the server's own network position. That is the pattern described for Helicone. The referenced source files place the webhook handling logic in valhalla/jawn/src/controllers/public/webhookController.ts (lines 64–85) and the request-issuing logic in valhalla/jawn/src/lib/clients/webhookSender.ts (lines 11–76), both under the valhalla directory of the repository. The controller sits in the public controllers path and, per the description, is associated with webhook creation; the sender is the client that transmits the requests.

The description states that the sender issues POST requests. When a webhook's target is an attacker-chosen hostname, the sender must resolve that hostname through DNS and then connect. The vulnerability arises because hostnames that resolve to private addresses are accepted and used. Two attack variants are described:

Direct private-address resolution: an authenticated user registers a webhook whose hostname resolves to a loopback or internal address. The sender resolves the name and connects to the private address, reaching services that should only be reachable from inside the network.
DNS rebinding: the attacker controls DNS for a public hostname. The name initially resolves to a public address and later to a private one. Rebinding matters either because hostname validation is absent or because any validation and the actual connection happen at different moments — a time-of-check-to-time-of-use gap. The description does not fully disclose which applies here.

The requests are described as blind: the attacker does not receive the responses generated by the internal service. What the attacker controls is the fact of the request — its method (POST) and its destination, since the hostname comes from the webhook — while the response stays inside the network. Whether the sender verifies TLS certificates, follows redirects, or applies any hostname filtering is not fully disclosed in the available sources; the discoverer's writeup and the VulnCheck advisory are the best references for those specifics.

DNS-based SSRF deserves emphasis as a sub-class. IP-based denylists are trivial to implement but check the wrong thing when the input is a hostname: the name is what the application sees, while the address is what the socket library sees, and the two are connected only through a DNS lookup that can return different answers at different times. A control that rejects literal addresses like 127.0.0.1 does nothing against a hostname that resolves to it, and a control that resolves and validates can still be beaten if the resolution used for validation is not the same resolution used for the connection. The description's phrasing — hostnames that "resolve or DNS-rebind" to loopback or internal addresses — maps directly onto both failure modes.

The CVSS v4.0 vector is consistent with a blind, integrity-focused SSRF. The attack vector is network (AV:N), attack complexity is low (AC:L), there are no attack requirements (AT:N), the required privileges are low (PR:L — an authenticated organization user), and no user interaction is needed (UI:N). Impacts on the vulnerable system are scored as no confidentiality impact (VC:N), low integrity impact (VI:L), and no availability impact (VA:N). The subsequent-system metrics are all none (SC:N/SI:N/SA:N), meaning the assessed impact does not propagate beyond the system making the requests. The resulting score is 5.3, Medium.

Affected Software and Versions

The affected product is Helicone, whose source code is published at github.com/Helicone/helicone. The vulnerability applies to Helicone through version v2025.08.21-1 — that is, every release up to and including v2025.08.21-1 falls within the advisory's affected range. The provided data does not disclose a fixed version, so operators should consult the Helicone repository and the VulnCheck advisory for current patch status. No other affected components or branches are named in the provided data.

Two clarifications from the NVD record: the structured vendor and product fields are not populated, but the description and references unambiguously identify Helicone and its Jawn component. The issue is also not listed in CISA's Known Exploited Vulnerabilities catalog (KEV: false), and no exploitation status beyond that is provided.

Impact

The concrete impact described is that the Jawn webhook sender can be steered into sending blind POST requests to internal HTTPS services. The significance of that depends on how internal services treat unsolicited POSTs:

Integrity impact on internal services (VI:L): internal services frequently trust traffic that originates from inside the network perimeter. A POST arriving from a trusted application server can reach endpoints that change state. The low integrity score in the CVSS vector reflects this assessed capability, though the description does not enumerate specific internal endpoints.
No confidentiality impact scored (VC:N): because the requests are blind, the attacker does not read responses, and the vector scores no confidentiality impact on the vulnerable system.
No availability impact scored (VA:N): the described attack does not include a denial-of-service component.
HTTPS constraint: the described requests target internal HTTPS services, so the practical target set is services the sender's TLS stack will connect to. Details such as certificate verification behavior are not fully disclosed.

For defenders, the useful framing is positional: the webhook sender is a network-position primitive. Even without response data, an attacker who can choose the destination of server-originated POSTs can interact with internal services that were never meant to be exposed to user-influenced traffic. That is also why the vulnerability requires so little: no exploit primitives beyond a valid account and a hostname the attacker can point somewhere useful.

Exploitation Scenario

The following scenario is illustrative and is derived directly from the vulnerability description; it is not a documented exploit chain.

An attacker obtains a low-privileged, authenticated account within an organization on a Helicone deployment — the PR:L prerequisite in the CVSS vector.
Using the webhook creation flow handled by the Jawn controller, the attacker registers a webhook whose target is a public hostname under their control, for example one served by DNS they operate.
The attacker configures the hostname's DNS records so the name resolves to a public IP on an initial query and to 127.0.0.1 or an internal address on a later query — the DNS rebinding pattern named in the description.
When the Jawn webhook sender resolves the hostname and issues its POST, the rebinding causes the connection to land on a loopback or internal address, delivering a blind POST to an internal HTTPS service.
Because the request is blind, the attacker confirms success indirectly — through side effects on the targeted internal service — rather than by reading a response.

The simpler variant skips the rebinding choreography: if hostnames that simply resolve to private addresses are accepted, the attacker points the webhook at such a name directly. The description explicitly allows for both paths ("resolve or DNS-rebind").

Detection and Mitigation

Detection. Operators of self-hosted Helicone deployments can look for the described behavior on their own infrastructure:

Review stored webhook configurations for hostnames, and resolve them independently to see whether any currently resolve to loopback or private ranges.
Monitor DNS queries and outbound connections originating from the host running the Jawn service, flagging POSTs from the webhook sender that are destined for loopback or internal addresses.
Audit the referenced code paths — webhookController.ts lines 64–85 and webhookSender.ts lines 11–76 — to determine what hostname validation, if any, is applied before the sender connects.

Mitigation. The provided references do not disclose a patched release, so the following are standard SSRF countermeasures mapped to the described weakness; treat them as engineering guidance rather than an official fix:

Resolve the webhook hostname server-side and validate every returned address against a denylist covering loopback, private (RFC1918), link-local, and otherwise non-routable ranges before connecting.
Defeat rebinding by connecting to the validated IP instead of re-resolving, and re-validate immediately before the socket is opened so the check and the connection cannot be separated in time.
Restrict the webhook sender's egress with network rules so it can only reach approved external destinations, and segment it away from internal services.
Constrain the webhook feature itself through scheme allowlisting and, where feasible, destination allowlisting for organization-supplied webhook targets.

Because the affected range is "through v2025.08.21-1," any deployment running that version or older should be treated as potentially vulnerable until the project publishes guidance. Verifying a fix: after any patch, re-test the two described variants against your own instance — a webhook whose hostname resolves to a private address, and a rebinding hostname — and confirm the sender refuses to connect to non-public addresses at connection time.

Bug Bounty Angle

This vulnerability is a textbook example of why webhook and URL-fetch features deserve a mandatory slot in every web application test plan. Points worth internalizing from this case:

Low privilege is enough. PR:L means a plain authenticated organization user is the entire prerequisite. Features available to ordinary tenants — webhooks, imports, integrations, URL fetchers — are high-yield SSRF surface precisely because every account can reach them.
Test both DNS variants. First try a hostname that resolves straight to a private address. If that is filtered, move to DNS rebinding, where validation and the fetch happen at different moments. The description of this CVE confirms both paths were relevant.
Blind does not mean worthless. With no response returned, impact is demonstrated through side effects on services you control in your own lab — which is exactly what a self-hosted, source-published target like Helicone enables: reproduce the deployment locally, point the webhook at your own internal service, and document the blind POST.
Read the code, not just the advisory. Because the source is published on GitHub, the referenced line ranges (webhookController.ts 64–85, webhookSender.ts 11–76) let you read the exact code involved — and later, any patch — before you ever send a request.
Methodology is public. The discoverer's HackMD writeup documents the DNS-based SSRF approach against this exact target, and the VulnCheck advisory corroborates it — both are legitimate study material for building your own rebinding test methodology.

One boundary note: this class of bug is only safely testable against deployments you own or are explicitly authorized to test. A webhook registered on a production service makes someone else's server emit requests — never aim that capability at networks you do not have permission to touch.

Frequently Asked Questions

What is CVE-2026-108602?

CVE-2026-108602 is a server-side request forgery (CWE-918) in the Jawn webhook sender of Helicone through v2025.08.21-1. Authenticated organization users can supply hostnames that resolve or DNS-rebind to loopback or internal addresses, causing blind POST requests to internal HTTPS services.

How severe is CVE-2026-108602?

CVSS v4.0 rates it 5.3 (Medium): AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N. It is network-exploitable with low privileges and no user interaction, with a low integrity impact and no assessed confidentiality or availability impact.

Who discovered CVE-2026-108602?

The vulnerability was discovered by HaiND from the Post and Telecommunication Institute of Technology. The CVE was assigned by VulnCheck, which published an advisory; a technical writeup is available on HackMD.

Is there a fixed version of Helicone for this issue?

The provided references do not disclose a fixed version; the affected range is through v2025.08.21-1. Check the Helicone GitHub repository and the VulnCheck advisory for current patch status.

Discovery and Credits

Discovered by HaiND from the Post and Telecommunication Institute of Technology. CVE assigned by VulnCheck. Technical details are documented in the discoverer's HackMD writeup and VulnCheck's advisory.