☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N 🐛 CWE-201
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-80255

CVE-2026-80255 Vulnerability in Haxx
📅 PUBLISHED: 2026-09-06 00:00 UTC 🔄 UPDATED: 2026-10-02 19:31 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CONFIRMED — 3+ independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: Public
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.48%
👁️
0.48% probability
12.0× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1557
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
Affected: Curl — upgrade to patched release
CVSS VECTOR BREAKDOWN 7.5
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: N Privileges Required None
UI: N User Interaction None
S: U Scope Unchanged
C: H Confidentiality High
I: N Integrity None
A: N Availability None
7.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-80255 is a cookie attribute parsing flaw in curl (Haxx). When a server sends a Set-Cookie: header that uses a horizontal tab (ASCII 0x09) instead of a space (ASCII 0x20) immediately before the Secure attribute, curl fails to recognize that attribute and stores the cookie without its Secure flag. The cookie can subsequently be transmitted in cleartext over HTTP to the same host, exposing its value to any network observer. Curl is embedded in countless applications, libraries, CLI toolchains, CI/CD systems, container images, and IoT/embedded devices; systems that handle session or authentication cookies over mixed HTTP/HTTPS are the primary risk group. Rated CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) with a low EPSS of 0.00514, the flaw favors confidentiality loss via on-path attackers rather than direct remote code execution.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

Secure is a cookie attribute defined in RFC 6265 that instructs a user agent to restrict the cookie to "secure" channels (HTTPS). A conforming client must not transmit a Secure cookie over an insecure transport. curl's cookie engine parses Set-Cookie headers to build its cookie jar and to decide whether each cookie is eligible for a given request.

The defect lies in the tokenization of the attribute list within the Set-Cookie header. Per RFC 6265 grammar, attributes are delimited by specific separators, and the header format expects a space between the cookie value and subsequent attributes. curl's parser, however, incorrectly handles a horizontal tab (ASCII 0x09) used where a space (ASCII 0x20) would normally appear immediately before the Secure attribute. Instead of treating the tab as insignificant whitespace and recognizing Secure, the parser fails to associate the attribute with the cookie. The cookie is therefore stored in curl's cookie jar without the Secure flag set.

A stored, non-Secure cookie is released to any subsequent request to the same host — including requests issued over plaintext HTTP. When the value is sent over HTTP, it is transmitted in cleartext and is fully visible to any observer on the path. This is a classic confidentiality-downgrade vulnerability. The mechanism is deterministic and requires no user interaction, matching the CVSS AC:L/PR:N/UI:N components.

Important scoping notes rooted strictly in the description:

  • The trigger is server-side or on-path injection of a malformed Set-Cookie: header. An attacker must induce curl to ingest such a header. This can arise from a malicious/compromised origin, a redirect chain, an on-path intermediary, or cache/proxy poisoning that emits the malformed header.
  • The flaw is in attribute recognition, not in cookie encryption. curl is a transport/HTTP client, not a cookie store with encryption; the bug is purely a parser mis-association of the Secure token.
  • No further parser internals, function names, or file paths are asserted here, because the supplied NVD description does not expose them. Any code-level identifiers not present in the source text would be speculation.

The relevant weakness classification is CWE-201 (information exposure through sent data), consistent with the CNA's categorization: sensitive cookie contents are sent over an unintended (cleartext) channel.

Exploitation Scenarios

The attack is an on-path / header-injection chain. Because no public exploit code is listed (Exploit Code: NO, Nuclei template: NO) and the CVE description is header-semantic only, the following is described at the vulnerability-class level. No PoC is publicly enumerated; the chain is inferred from the cookie-parsing vulnerability class.

  1. Reconnaissance / target identification. The attacker identifies targets that (a) use curl or curl-based libraries to make HTTP(S) requests to a host, and (b) allow or cause subsequent requests to the same host over plaintext HTTP. Candidates include CI/CD runners that fetch from mixed-scheme endpoints, CLI tooling that follows redirects, containerized jobs, and embedded/ IoT agents. Because curl is a library, the "target" is often an application embedding libcurl rather than a standalone endpoint.

  2. Inducing the malformed header. The attacker causes curl to receive a Set-Cookie: header containing a horizontal tab immediately before Secure. In a network scenario, this occurs when the attacker is positioned as an on-path intermediary (rogue Wi-Fi, ARP/DNS spoofing, malicious proxy) or when the origin itself is attacker-controlled (a site curl is directed to, a redirect target, or a poisoned cache/proxy response). The tab-vs-space substitution is the entire trigger: it is not the cookie value but the delimiter that defeats attribute recognition.

  3. Payload / execution at the vulnerability-class level. No code is executed in the target process; the "payload" is the malformed header. curl parses it, fails to set the Secure attribute on the stored cookie, and retains the cookie in its jar as non-Secure.

  4. Post-exploitation impact. On the next request to the same host over plaintext HTTP, curl releases the cookie without the Secure restriction. The on-path attacker — now possibly no longer required to rewrite headers — captures the cleartext Cookie: value. That value typically represents a session identifier or authentication token. The consequence is session hijacking / credential theft and onward account or API abuse, with high confidentiality impact (C:H) and no direct integrity or availability effect (I:N/A:N).

Because exploitation depends on positioning (an on-path attacker or control of the origin that emits the header), it is not an internet-mass-exploitable RCE. This aligns with the low EPSS (0.00514) despite the availability of a public description.

Impact Assessment

  • Confidentiality (High, C:H): The core impact. Cookie values — including session and auth tokens — can be intercepted in cleartext. This can lead to account takeover, session replay, and lateral movement into authenticated APIs the cookie protects.
  • Integrity / Availability (None, I:N / A:N): The flaw does not permit modification of data or disruption of services on its own; it is an information-disclosure issue.
  • Attack Vector / Complexity / Privileges / UI (AV:N / AC:L / PR:N / UI:N): Network-reachable, low complexity, no privileges, no user interaction to trigger the parser defect — though the practical attack still requires on-path positioning or a malicious origin.
  • Scope (S:U): Impact remains within the vulnerable component's security authority per the vector.
  • Blast radius: curl is ubiquitous (operating systems, package managers, container base images, CI/CD, CMS plugins, embedded devices). Any deployment that relies on curl's cookie engine to honor Secure on mixed-scheme requests is exposed. Multi-tenant CI/CD and ephemeral container environments are especially attractive because cleartext HTTP egress is common and session cookies frequently appear.
  • Business impact: Credential/session compromise, data exfiltration, regulatory exposure (privacy/PCI where cookies are session tokens), and downstream account compromise. Because curl is embedded, patching requires updating both the curl package and every vendored/static libcurl in applications.

Detection Guidance

Detection must target (a) the malformed Set-Cookie header with a tab before Secure, and (b) cleartext cookie egress that should have been Secure. The parser defect is client-side, so host-side detection focuses on curl version/inventory and header anomalies; network-side detection focuses on tab-injection in HTTP responses and on Cookie: values over plaintext HTTP.

Sigma Rule

title: Possible curl Secure-Cookie Downgrade via Tab-Delimited Set-Cookie Header
id: 3f9c2a10-7db2-4c11-9a55-curl80255
status: experimental
description: Detects inbound/observed HTTP response headers where a horizontal tab precedes the cookie Secure attribute, matching the parsing trigger for CVE-2026-80255 (curl Secure attribute bypass).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-80255
author: valtersit.com
date: 2026-01-01
tags:
  - attack.t1557
  - attack.t1040
logsource:
  category: webserver
  product: generic
detection:
  selection:
    # Matches Set-Cookie headers with a tab (\t = 0x09) immediately before Secure
    # Word/RE-based matching varies by Sigma backend
    cs-uri-query|re: '(?i)Set-Cookie:.*\x09Secure'
  selection_body:
    cs-uri-query|contains: "\tSecure"
  condition: selection or selection_body
falsepositives:
  - Benign servers mis-emitting tabs (rare, non-conformant)
  - Unrelated tab usage in query strings
level: medium

Note: Sigma backends encode tab characters inconsistently. The \x09 regex form targets Splunk/Elastic regex processors. Tune per backend; the canonical indicator is a tab (0x09) byte between the cookie value and the string Secure.

YARA Rule

rule CVE_2026_80255_curl_secure_tab_downgrade
{
    meta:
        author      = "valtersit.com"
        description = "Detects Set-Cookie headers abusing a horizontal tab before the Secure attribute (CVE-2026-80255)"
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2026-80255"
        date        = "2026-01-01"

    strings:
        $setcookie = "Set-Cookie:" ascii nocase
        $secure    = "Secure" ascii nocase
        // tab (0x09) immediately before Secure
        $tabsecure = { 09 53 65 63 75 72 65 }

    condition:
        $setcookie and $tabsecure
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-80255 curl Secure-cookie downgrade - tab before Secure attribute in Set-Cookie"; flow:from_server,established; http.header_names; content:"Set-Cookie"; nocase; http.header; content:"|09|Secure"; nocase; reference:cve,2026-80255; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-80255; classtype:attempted-recon; sid:8025501; rev:1;)

Note: The pipe-encoded |09| matches the literal horizontal tab byte immediately preceding Secure. Validate offset/behavior on your Suricata build; some deployments prefer a pcre alternative: http.header; pcre:"/Set-Cookie:[^\r\n]*\x09Secure/i";.

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where http.response.headers.content : "*Set-Cookie*"
      and http.response.headers.content : "*\tSecure*" ]
  [ network where http.request.method == "GET"
      and url.scheme == "http"
      and http.request.headers.content : "*Cookie*" ]

Interpretation: Detects a malformed Set-Cookie (tab before Secure) followed by a cleartext HTTP request carrying a Cookie: header to the same origin — the exploitation window for the downgraded cookie. Field names (http.response.headers.content, url.scheme) should be mapped to your Elastic packetbeat/Zeek data model.

Splunk SPL Query

index=proxy OR index=http sourcetype=access_combined OR sourcetype=pan:traffic
| eval raw=_raw
| where match(raw, "(?i)Set-Cookie:[^\r\n]*\x09Secure")
    OR match(raw, "(?i)Set-Cookie:.*\tSecure")
| table _time host src_ip dest_host uri raw
| sort - _time

Companion query for cleartext cookie egress that should have been Secure:

index=proxy http_method=GET url_scheme=http
| search http_request_headers="*Cookie*"
| where NOT match(url, "(?i)^https")
| stats count values(dest_host) as hosts by src_ip
| sort - count

Wazuh OSSEC Rule

<group name="web,cve-2026-80255,cookie_downgrade,">
  <rule id="802550" level="10">
    <decoded_as>json</decoded_as>
    <field name="http.response.headers">Set-Cookie</field>
    <regex type="pcre2">Set-Cookie:[^\r\n]*\x09Secure</regex>
    <description>CVE-2026-80255: Set-Cookie with horizontal tab before Secure attribute (curl Secure flag bypass)</description>
    <mitre>
      <id>T1557</id>
      <id>T1040</id>
    </mitre>
    <group>cve_2026_80255,</group>
  </rule>

  <rule id="802551" level="12">
    <if_sid>802550</if_sid>
    <field name="url.scheme">http</field>
    <description>CVE-2026-80255: Potential cleartext transmission of cookie after Secure-flag downgrade</description>
    <group>cve_2026_80255,</group>
  </rule>
</group>

Note: The parent rule (802550) matches the malformed header; the child rule (802551) escalates when a cleartext HTTP request follows. Confirm PCRE2 tab escape (\x09) support in your Wazuh version; if unsupported, pre-normalize tabs to a sentinel token in the decoder.

Mitigation & Patch Guidance

Patch confidence: 3/4 — LIKELY (2 independent sources confirm fix). Both NVD and Debian track a fix. Exact fixed version is not enumerated in the supplied data; verify against the upstream curl advisory and the Debian security tracker.

1) Immediate mitigations

  • Inventory curl/libcurl. Curl is embedded in applications, base images, and static builds; identify both the curl/libcurl package version and vendored copies.
  • Prefer HTTPS end-to-end. Because exploitation requires subsequent cleartext HTTP to the same host, eliminating cleartext HTTP egress for cookie-bearing requests neutralizes the practical impact.
  • Restrict on-path exposure. Enforce TLS for all requests that carry cookies, use HSTS, and avoid untrusted Wi-Fi/proxies for cookie-authenticated sessions.
  • Sanitize/harden upstream headers. Intermediate proxies or header-normalizing middleware can reject or normalize Set-Cookie headers containing non-conforming whitespace (tabs) before Secure, blocking the trigger. Treat control bytes in header tokens as suspicious.
  • Reduce cookie sensitivity. Shorten cookie lifetimes, rotate session tokens, and use HttpOnly/SameSite to limit damage if a token is captured.

2) Patch / upgrade steps

  • Upgrade curl/libcurl to the upstream patched release documented in the curl security advisory; apply the distro (Debian, etc.) patched package where available.
  • Rebuild any applications that vendor/static-link libcurl against the fixed library.
  • Rebuild container base images and re-deploy CI/CD runners and embedded firmware to pull the fixed library.
  • Validate post-patch by confirming that a Set-Cookie: header with a tab before Secure results in the cookie being stored with the Secure flag (i.e., not sent over plaintext HTTP).

3) Long-term hardening

  • Maintain an SBOM and continuous curl/libcurl version monitoring across all artifacts.
  • Enforce TLS-only policy for cookie-authenticated flows; treat cleartext HTTP as untrusted for session data.
  • Add regression tests to CI that fuzz Set-Cookie attribute delimiters (space vs tab vs other control bytes) for any client-side cookie engine.
  • Subscribe to curl/OSS security feeds and fast-track high-severity parser fixes.
  • Deploy the network detections above (malformed header + cleartext cookie egress) as compensating monitoring where patching lags.

References

CISA KEV status: Not listed (CISA KEV: NO). No public exploit code or Nuclei template is enumerated (Exploit Code: NO, Nuclei Template: NO), and EPSS is low (0.00514, ~42.1st percentile), indicating no confirmed widespread exploitation activity at report time. No specific threat-actor campaign is attributed in the supplied data.

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

product:

💣 PoC CODE AVAILABLE

Exploit code for this CVE is tracked in our database. Access poc_code via API Pro.

[ API_PRO ] →
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-80255/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.