Redirect-based SSRF in the Infisical webhook handler
Infisical checked the webhook URL against internal ranges, then dispatched with a client that follows redirects — so a public URL answering “go here instead” reached the internal metadata endpoints the check existed to protect.
Validation ran once, on the first URL — never on where that URL sent the server next
The mitigation was already written. It was just never called.
Infisical is an open-source secrets-management platform. Its webhook feature lets an authenticated user register a URL that Infisical contacts when an event fires. The handler validated the supplied URL against private and internal ranges — then sent the request with a redirect-following client.
The check that redirects walked around
Public URL → 302 → internal address
- Identifier
- CVE requestedpending MITRE assignment
- Severity
- Highresearcher assessment · CVSS vector pending
- Weakness
- Server-Side Request ForgeryCWE-918 · redirect bypass
- Disclosed
- 2026-04-03security@infisical.com · Infisical Cloud
- Fixed
- PR #6004commit 35ed274 (2026-04-10) · v0.159.10 (2026-04-14)
- Vendor
- Infisical Inc.acknowledged, remediated
- Vector
- Remoterequires authenticated user
- Recognition
- Creditedv0.159.10 release notes, Security section
A validated URL, followed to somewhere it was never validated
The request was sent with the default axios client, which follows HTTP redirects up to five hops. The SSRF check ran only on the initial URL, never on redirect targets.
The codebase already contained a redirect-safe path — a helper that sets maxRedirects: 0 and re-validates before each request. It was not applied to the webhook handler.
The mitigation was already written. It was just never called.
A redirect-safe request path existed in the same codebase. The webhook handler simply did not use it.
The check it had just performed, defeated by a single redirect
An authenticated user could register a webhook pointing at an attacker-controlled public server that passed validation, then have that server answer with an HTTP 302 pointing to an internal address — 169.254.169.254, 127.0.0.1, or a 10.0.0.0/8 host.
The class is established. MITRE has assigned CVEs for redirect and blind SSRF on equivalent evidence: CVE-2025-4581 (Liferay), CVE-2025-20371 (Splunk), CVE-2024-49336 (IBM Guardium). The unused in-repo mitigation makes the exposure unambiguous.
# public host — IP-range check passes webhook url: https://attacker.example/hook → accepted webhook stored
HTTP/1.1 302 Found Location: http://169.254.169.254/latest/meta-data/ → default client follows
server 3.215.209.139 (axios/1.14.0) → followed the redirect to an arbitrary destination
“…our April 3 response was inaccurate. The fix to the webhook handler was not in place at the time of your disclosure, and it was committed after your report was made.”
— Infisical, May 6, 2026Answered in twenty minutes, corrected seven days later
The disclosure was sent on April 3, 2026 at 10:51 AM ET. Twenty minutes later the vendor replied that the issue had already been addressed prior to the disclosure. The commit history does not support that: the handler was hardened in commit 35ed2744 on April 10 — seven days after — shipping as PR #6004 in v0.159.10.
The v0.159.10 release notes credit the finding to Drew Morana. The published record now reflects what occurred.
Reach into internal services and cloud metadata
In its vulnerable window, an authenticated Infisical user could make the server contact internal services and cloud metadata addresses it should never reach — the classic path to credential and configuration disclosure in a cloud deployment.
The issue is remediated in v0.159.10 and later. Operators on earlier versions should upgrade. Affected operators requiring remediation guidance should contact Whitenbaker Security Research.
Disclosed. Reported with file, function, line, and one-line remediation. Confirmed live against app.infisical.com.
“Already addressed.” Vendor replied, twenty minutes later — a claim the commit history does not support.
Fix committed. Commit 35ed2744 (PR #6004) hardened the handler — seven days after disclosure.
Shipped in v0.159.10. Release notes credit the finding to Drew Morana.
Vendor acknowledgment. Infisical acknowledged in writing that the April 3 reply was inaccurate and the fix post-dated the disclosure.
CVE requested. Filed with MITRE with version and commit identifiers. This advisory stands as the public reference.
Whitenbaker
Adversarial security research — silent-patch detection, vulnerability disclosure, and the gap between what vendors ship and what they tell you.
Drew Morana · @dmoranaPublished for coordinated disclosure and defensive purposes. Findings confirmed against Infisical Cloud, the public commit history, and the vendor’s written correspondence. © 2026 Whitenbaker. All rights reserved.