Bug bounty

Bug bounty roundup: 12 disclosed reports worth reading

By Yaali. November 10, 2026, 7 min read, Bug bounty, Vulnerabilities.

Twelve HackerOne reports disclosed from 26 October to 8 November 2026: a Trellix signup bypass and eleven curl bugs, many of them fixes that did not hold.

This roundup covers 12 bug bounty reports that HackerOne programs made public between 26 October and 8 November 2026. Few reports surfaced in the last 48 hours, so the window is the last two weeks, minus everything the 6, 8 and 9 November roundups already covered and anything we could not confirm in both archives we read. That leaves one web application chain at Trellix and eleven reports against curl, grouped here into ten sections.

The theme is fixes that did not hold. Six of the curl reports describe a regression or an incomplete fix: an OCSP check deleted by a refactor, a session cache rewrite that dropped a scheme check added after a 2016 audit, a cookie fix that left the same failure reachable. None of the 12 reports lists a bounty, and curl's site still shows no published advisories for 8.23.0, with the next release scheduled for 9 December 2026.

Broken access control on a Trellix customer portal

t4f3 chained three weaknesses on healthwatch.trellix.com. The signup form checked the company email domain only in the browser, so editing the intercepted request registered an account with an outside address, which then sat pending admin approval. The forgotten-password flow did not check that status: resetting the password activated the account and logged it in. Once inside, the /api/ApiV1/GetCustomerDetailByEmail endpoint returned every customer business name with the internal staff emails tied to each, which the reporter matched against public profiles.

Each step is a server-side check that lived somewhere else. Validate the domain on the server, refuse resets for pending accounts, and scope API results to the caller. Program: Trellix. Severity: medium (CVSS 5.3). Reporter: t4f3. Report: https://hackerone.com/reports/3417759

curl with GnuTLS accepted a five-byte OCSP staple

--cert-status (CURLOPT_SSL_VERIFYSTATUS in libcurl) asks the server for a stapled OCSP response, a CA-signed statement that the certificate is not revoked, and must fail if the response is missing, invalid or says revoked. matty69v found that in curl 8.22.0 and 8.23.0 built with GnuTLS, a commit that removed curl's own OCSP signature verification also removed the status checks, so any staple passed. A local server with a revoked certificate stapling a bogus, unsigned five-byte tryLater response got HTTP 200, where the OpenSSL backend exited with error 91. This brings back CVE-2024-8096. A later curl report references the fix that restores the status check in curl's development tree. Program: curl. Severity: medium. Reporter: matty69v. Report: https://hackerone.com/reports/4116076

Apple SecTrust builds of curl trusted forged and stale staples

sujitjaunjal filed two related reports. In OpenSSL builds that use Apple SecTrust to check the chain, curl skips its own staple check and leaves it to SecTrust, which runs a best-effort revocation policy. A staple with a forged signature, a "good" one 20 days past its expiry, or an "unknown" one all returned HTTP 200 with --ca-native --cert-status, while --cacert on the same binary rejected all three (curl 8.20.0 to 8.23.0, medium). The proposed fix requires a positive response when --cert-status is set.

The second report covers GnuTLS with SecTrust, as MacPorts ships curl +gnutls +sectrust. When GnuTLS rejects a chain, curl asks SecTrust, without passing the staple, and drops the GnuTLS verdict, so a correctly signed "revoked" staple passes on 8.23.0 with default options (low). If you rely on --cert-status on macOS, test it with a revoked certificate. Program: curl. Reporter: sujitjaunjal. Reports: https://hackerone.com/reports/4118610 and https://hackerone.com/reports/4122300

Two use-after-free bugs in curl's OpenSSL provider support

Setting CURLOPT_SSLENGINE to an OpenSSL 3 provider name makes libcurl create a private library context that it frees in curl_easy_cleanup(). moltenbit showed that since 8.23.0 the certificate store cached per multi handle can outlive that context when CURLOPT_CAPATH is set, so the next verification on the same multi handle reads freed memory. A server only needs a forged leaf naming a CA from the victim's CApath as issuer; on OpenSSL 3.5.5, a 327-byte certificate extension took over the freed block and set the pointer libcrypto read (medium).

vansukmbg found the same lifetime gap on another path: a connection waiting for TLS shutdown on the multi interface still uses the context after the easy handle frees it (low). Both need provider use and the multi interface, which curl --parallel also uses. Program: curl. Reports: https://hackerone.com/reports/4122239 and https://hackerone.com/reports/4116527

curl reused an FTPS TLS session for HTTPS

stze found that the TLS session cache key in curl 8.12.0 to 8.23.0 holds the host, port and TLS settings but not the URL scheme. Cure53 reported exactly this in curl's 2016 audit and it was fixed; the 8.12.0 cache rewrite lost the check. An active network attacker who redirects an HTTPS connection to an FTPS data port can have curl resume the FTPS session and accept a planted file as a verified HTTPS response. The preconditions are rare and the rating is low, but it shows why old audit findings deserve regression tests. Program: curl. Severity: low. Reporter: stze. Report: https://hackerone.com/reports/4122175

Schannel resumption kept a client certificate across a redirect

johnnykao reported that curl 8.23.0 with Schannel, the Windows TLS stack, resumes a cached TLS session after a cross-origin redirect even when automatic client certificate selection (CURLSSLOPT_AUTO_CLIENT_CERT) should no longer apply. The server sees the original mutual TLS (mTLS) identity on a new TCP connection; with session caching off, the same handshake fails for lack of a certificate. It describes the earlier fix as covering connection reuse but not resumption. Program: curl. Severity: low. Reporter: johnnykao. Report: https://hackerone.com/reports/4136767

A failed redirect made the next upload send freed memory

1rhino2 found that when a server answers a POST with a redirect curl cannot follow, libcurl keeps the previous request's body reader. If the application reuses the easy handle for an upload without curl_easy_reset(), the next transfer reads 64 KB blocks from freed memory and sends them to the FTP, SFTP or TFTP server, or writes them to a local file. Under AddressSanitizer this is a heap use-after-free; with smaller bodies, transfer two silently uploads stale bytes. Affected range: 8.16.0 to 8.23.0. Program: curl. Severity: low. Reporter: 1rhino2. Report: https://hackerone.com/reports/4123190

curl -OJ emptied the file it said it would not overwrite

-O -J saves under the filename the server sends and refuses to overwrite an existing file. matty69v showed that a response with a filename-less Content-Disposition: inline header before one naming an existing file makes curl open the URL-derived name for writing first. A malicious server can truncate report.pdf to 0 bytes while curl exits with error 23 saying it refused. Affects the curl tool in 8.22.0 and 8.23.0. Program: curl. Severity: low. Reporter: matty69v. Report: https://hackerone.com/reports/4124849

samueloph showed that a fix for an earlier cookie jar bug still lets the parser reject lines of 5,047 characters or more. A saved line includes the domain and path, which do not count toward the Set-Cookie length limit when the server omits them, so a 4,000-byte cookie set at a 1,500-byte URL path produced a 5,539-character line. Every later run reading that jar failed with exit code 100, and with the common -b jar -c jar setup the next run rewrote the jar empty, for every site. Program: curl. Severity: low. Reporter: samueloph. Report: https://hackerone.com/reports/4112912

Pausing from a callback triggered a double free

rat5ak found that libcurl's output writer keeps a buffer pointer across the application's write callback. If the application pauses and then resumes the transfer from inside a callback, a nested flush frees that buffer and the outer loop reads and frees it again; a plain -O2 build crashed in free() 20 times out of 20. A server cannot trigger it alone, but applications that pause from callbacks on 8.20.0 to 8.22.0 or the development tree should watch for the fix. Program: curl. Severity: low. Reporter: rat5ak. Report: https://hackerone.com/reports/4102061

What to take from this batch

When a fix removes or moves a check, write the test that would have caught the original bug and keep it: two of the curl regressions are checks that disappeared during refactors. In your own estate, test security options against a server built to fail them: a revoked certificate for --cert-status, a cross-origin redirect for client certificates.

Our web application penetration testing works through signup, reset and authorization flows like the Trellix chain, and red team code review reads source for missing checks and lifetime bugs. Open the chat and Yaali, our AI agent, will pass your question to an engineer.