websocket-driver is a WebSocket protocol handler with pluggable I/O. Prior to 0.8.1, when websocket-driver is used to implement a WebSocket server on top of a TCP server using WebSocket::Driver.server() or to complement a WebSocket client, a peer can make a single connection consume an unbounded amount of memory by sending an HTTP request or response with a never-ending list of headers. This can lead to the receiving process running out of memory. This issue is fixed in version 0.8.1.

## Summary There is a critical vulnerability in Traefik's default HTTP reverse proxy that leads to unauthenticated cross-user response poisoning. When a client opens an HTTP/2 or HTTP/3 `CONNECT` request, Traefik forwards it — body included — to an HTTP/1.1 upstream over a shared `net/http.Transport`. If the upstream answers the CONNECT with a keep-alive non-2xx response without draining the body, the now-desynchronized backend socket is returned to Traefik's shared connection pool and reused for other clients, letting an attacker make a different client read a response the attacker smuggled — which may be another user's authenticated or private content. The entrypoint's `sanitizePath` option (default `true`) is not a reliable defense: backends that answer `CONNECT /` with a keep-alive non-2xx remain exploitable. The experimental FastProxy implementation was not affected. The issue is fixed by deferring the forwarded CONNECT payload until the backend accepts the tunnel, by not returning CONNECT connections to the shared idle pool, and by discarding the CONNECT body in the ForwardAuth path. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.53 - https://github.com/traefik/traefik/releases/tag/v3.6.24 - https://github.com/traefik/traefik/releases/tag/v3.7.9 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ## Summary Traefik's default reverse proxy forwards a plain HTTP/2 or HTTP/3 `CONNECT` request and its body to an HTTP/1.1 upstream through a shared `net/http.Transport`. When the upstream answers the CONNECT with a keep-alive non-2xx response and does not drain the body, Traefik returns the now desynchronized backend socket to its shared pool and reuses it for other clients. An unauthenticated attacker uses this to make a different client read the attacker's smuggled response. Traefik's default proxy is `net/http/httputil.ReverseProxy` over a shared `http.Transport`, so it inherits the same root cause as the Caddy `reverse_proxy` CONNECT pool poisoning. Traefik ships one partial mitigation Caddy does not. The entrypoint option `sanitizePath` (default `true`) rewrites the forwarded CONNECT's empty path to `/`, so Traefik emits `CONNECT /` instead of authority-form `CONNECT host:port`. This is not a reliable defense. It avoids the smuggle only against backends that reject `CONNECT /` by closing the connection (Apache, nginx). Backends that answer `CONNECT /` with a keep-alive non-2xx and leave the body undrained still cross. That set includes any Go `net/http` server and gunicorn/Flask. Confirmed on the official image `traefik:v3.6.23` (a currently supported release), default configuration, against stock `go-httpbin` (Go) and `kennethreitz/httpbin` (Python gunicorn/Flask), attacker and victim in separate containers, over both HTTP/2 and HTTP/3. ## Affected - `traefik:v3.6.23` (official image) and current v3, default configuration, standard proxy to an HTTP/1.1 upstream. Backend keep-alive pooling is on by default (`MaxIdleConnsPerHost` 200). - Attacker frontend is HTTP/2 or HTTP/3. An HTTP/1.1 frontend is not affected. - The upstream keeps the connection alive after a non-2xx to the forwarded CONNECT and does not drain the body. - The experimental FastProxy implementation is not affected (see Not affected). ## Details Three behaviors compose. 1. Traefik forwards a plain CONNECT as an ordinary proxied request. The default proxy is `httputil.ReverseProxy` with a shared `http.Transport` (`pkg/proxy/httputil/proxy.go`). The director assigns the outbound `URL.Host` directly and does not reject CONNECT, leaving the request body a live stream. The client places a raw HTTP/1.1 request in that body (H2/H3 DATA frames), which is written onto the backend socket after the CONNECT header block. 2. `net/http` writes the CONNECT body unframed and pools the socket. For a CONNECT the transport writes the body with no `Content-Length` and no `Transfer-Encoding`. The upstream answers a keep-alive non-2xx and parses the trailing bytes as a pipelined request. Go reads the non-2xx response and returns the socket to the shared idle pool once the request body reaches EOF (the `wroteRequest` gate), while the smuggled request's response is still pending. 3. Desynchronized reuse. The smuggled request targets a slow endpoint so its response arrives after the socket is pooled. A different client that reuses the socket reads the pending smuggled response as its own. `sanitizePath` (default `true`, `pkg/server/server_entrypoint_tcp.go`) calls `req.URL.JoinPath()`, which turns the CONNECT's empty path into `/`. Traefik emits `CONNECT /`. Whether that stops the smuggle depends only on the backend: Apache and nginx answer `400 Bad Request` with `Connection: close` (socket torn down, no cross); Go `net/http` and gunicorn/Flask answer a keep-alive non-2xx and pipeline the trailing bytes (cross). With `sanitizePath` off, Traefik emits authority-form `CONNECT host:port`, which Apache answers with a keep-alive `405`. HTTP/2 and HTTP/3 only. Pooling requires the forwarded request body to reach EOF. An H2/H3 client half-closes the CONNECT stream (END_STREAM), so the body reaches EOF while the connection stays open and the socket is pooled. An H1 CONNECT body is the tunnel and cannot reach EOF without closing the connection, so the socket is closed, not pooled. HTTP/3 routes to the same handler chain as HTTPS. ## Backend behavior "Armed" means the backend answers with a keep-alive non-2xx and parses the trailing undrained bytes as a pipelined request. Default Traefik emits `CONNECT /`; with `sanitizePath: false` it emits authority-form `CONNECT host:port`. | Backend (stock image) | Server | `CONNECT /` (default) | authority-form CONNECT | |-------------------------|----------------|----------------------------|------------------------| | `mccutchen/go-httpbin` | Go net/http | armed (405 keep-alive) | armed | | `traefik/whoami` | Go net/http | armed (200 keep-alive) | armed | | `caddy:2` | Go net/http | armed (405 keep-alive) | armed | | `kennethreitz/httpbin` | gunicorn/Flask | armed (405 keep-alive) | armed | | `httpd:2.4` | Apache | not armed (400 close) | armed (405 keep-alive) | | `nginx:alpine` | nginx | not armed (400 close) | not armed (400 close) | | `tomcat:10` | Tomcat | not armed (501 close) | - | | node `http` | Node.js | not armed (closes) | - | | `python -m http.server` | Python stdlib | not armed (501 close) | - | ## Impact Unauthenticated cross-user HTTP response poisoning. One client receives another client's response, which can be authenticated or private content, or an attacker-chosen response. Blast radius depends on the pool. With the default pool and a slow smuggled endpoint the crossing is reliable for a converging victim. With a bounded pool one desync shifts the whole response queue: measured with `MaxIdleConnsPerHost 1` and a slow victim endpoint, 8 of 8 sequential victims read a response that was not their own (1 the attacker's, 7 another user's, 0 their own). Traefik does not expose `MaxConnsPerHost`, so the parallel cascade is weaker than Caddy's. ## Proof of concept `poc/run.sh` runs the official `traefik:v3.6.23` image fronting real off-the-shelf backends over HTTP/1.1, with attacker and victim in separate containers. Requires docker and python3. It builds the attack client, pulls the stock images, and runs the scenarios below. The attacker opens an H2 or H3 `CONNECT` to Traefik and sends a raw HTTP/1.1 `GET /delay/2?tag=ATTACKERSMUGGLED` as the CONNECT body, then half-closes the stream. Traefik forwards the CONNECT to the Go/Python backend, the backend answers a keep-alive non-2xx, keeps the socket, and parses the trailing GET as a pipelined request, so a response to it is queued on that socket. `net/http` returns the socket to Traefik's shared pool. The victim then sends `GET /get?tag=VICTIMOWN` on its own connection, Traefik reuses the pooled backend socket, and the victim reads the queued `/delay` response instead of its own. `CROSS` means the victim received a response that was not its own. ## Expected output from poc ``` == core: DEFAULT config, cross-user poisoning vs real off-the-shelf backends == [core-go-h2] h2->h2 CROSS [core-go-h3] h3->h3 CROSS [core-go-x] h2->h3 CROSS [core-py-h2] h2->h2 CROSS [core-py-h3] h3->h3 CROSS == mechanism: sanitizePath off -> stock Apache 405 (the direct Caddy analogue) == [mech-ap-h2] h2->h2 CROSS [mech-ap-h3] h3->h3 CROSS == controls: must NOT cross == [ctl-apache] h2->h2 NO_CROSS [ctl-pooloff] h2->h2 NO_CROSS [ctl-kaoff] h2->h2 NO_CROSS == safe variant: experimental FastProxy chunk-frames the CONNECT body == [safe-fast] h2->h2 NO_CROSS == cascade: bounded pool, one desync poisons a queue of victims == smuggled=1 other_user=7 own=0 of 8 (cross-user poisoned=8) RESULT: PASS ``` - Core rows. DEFAULT Traefik config against a Go backend (`go-httpbin`) and a Python gunicorn/Flask backend (`kennethreitz/httpbin`), for H2->H2, H3->H3, and H2->H3. The victim reads the attacker's smuggled response. - Mechanism rows. `sanitizePath` off and stock Apache. Traefik emits authority-form `CONNECT apache-backend:80`, Apache answers a keep-alive `405`, and it crosses. This is the direct Caddy analogue and proves the full mechanism including Apache. - Control rows. `ctl-apache` runs the default config against Apache, which closes `CONNECT /`; `ctl-pooloff` disables Traefik backend reuse (`maxIdleConnsPerHost: -1`); `ctl-kaoff` runs Apache with `KeepAlive Off`. All three print `NO_CROSS`, so the crossing depends on backend socket reuse, not pipelining or a shared client. - Safe variant. Experimental FastProxy against the Go backend prints `NO_CROSS` because it chunk-frames the CONNECT body. - Cascade. `MaxIdleConnsPerHost 1` and a slow victim endpoint. One CONNECT desync shifts the queue: of 8 sequential victims, 1 reads the attacker's smuggled response, 7 read another user's response, 0 read their own. The captured crossing (`poc/evidence/RELEASE_v3.6.23_victim.json`): the victim sent `GET /get?tag=VICTIM_OWN` and received a 200 whose body is the response to `GET /delay/2?tag=ATTACKER_SMUGGLED` with the echoed header `X-Smuggled: released-v3.6.23`, none of which the victim sent. ## Not affected - HTTP/1.1 frontend. An H1 CONNECT body cannot reach EOF without closing the connection, so the backend socket is not pooled. - Experimental FastProxy (`experimental.fastProxy`). It chunk-frames the forwarded CONNECT body (`Transfer-Encoding: chunked`, captured in `poc/evidence/wire_fastproxy_chunked.txt`), so the trailing bytes are read as the CONNECT body, not a pipelined request. `safe-fast` is `NO_CROSS`. ## ForwardAuth The ForwardAuth middleware with `forwardBody: true` and `preserveRequestMethod: true` re-issues the request to the auth server as a CONNECT with the buffered body re-attached and `ContentLength` never set (`pkg/middlewares/auth/forward.go`). The auth client writes that body unframed to the auth server (captured on the wire), so a keep-alive non-2xx from the auth server poisons the shared auth-client pool the same way. ## Root cause `net/http` pools a connection after a keep-alive non-2xx response to a CONNECT whose body it wrote unframed. Traefik's default proxy forwards client CONNECT through a shared `net/http.Transport` and applies no CONNECT rejection. `sanitizePath` changes the emitted request target but does not remove the defect. Traefik's own FastProxy implementation frames the CONNECT body and does not cross, which shows this is a property of the httputil/`net/http` path, not fixed by path normalization. ## POC [poc.zip](https://github.com/user-attachments/files/29963125/poc.zip) </details> ---

websocket-driver is a WebSocket protocol handler with pluggable I/O. Prior to 0.7.5, the frame format in draft versions of the WebSocket protocol includes a length header that allows an arbitrarily large integer to be encoded as a sequence of bytes with the high bit set. By sending an indefinite sequence of bytes with values 0x80 or above, a client can make the server parse these bytes into an ever-growing integer in lib/websocket/driver/draft75.js; because JavaScript numbers are 64-bit floating point values, this number will eventually lose precision and lead to the subsequent payload being parsed incorrectly. This issue is fixed in version 0.7.5.

MessagePack is the serializer implementation for Python msgpack.org. Prior to 1.2.1, there is an Out-of-bounds read/crash on Unpacker reuse after a caught error, potentially leading to a DoS attack. If the Unpacker is used repeatedly after an error occurs, the process may crash with a SEGV. This issue has been fixed in version 1.2.1.

Incorrect authorization in the aggregation pipeline tool in Amazon AWS Labs DocumentDB MCP Server before 1.0.12 might allow an authenticated MCP client to perform inappropriate write operations on the connected database via write-capable aggregation pipeline stages that bypass the read-only mode enforcement logic. To remediate this issue, users should upgrade to version 1.0.12 or later.

Improper limitation of a pathname to a restricted directory in the get_resource tool in Amazon awslabs.aws-transform-mcp-server 0.1.0 through 0.1.4 might allow a context-dependent actor to write arbitrary files outside the intended working directory via the savePath parameter. To remediate this issue, users should upgrade to version 0.1.5 or later.

Insufficient input validation in Amazon Bedrock AgentCore harness might allow an authenticated remote user to execute configured tools bypassing model invocation and security controls via crafted content blocks in conversation messages. AWS has addressed this issue. No customer action is required.

An uncontrolled search path element in Kiro CLI before version 2.10.0 on Windows might allow a remote unauthenticated actor to execute arbitrary code via a maliciously crafted project directory containing an executable that bypasses workspace trust protections when a local user starts Kiro CLI in the directory. To remediate this issue, users should upgrade to version 2.10.0 or higher.

An uncontrolled search path element in Kiro IDE before version 1.0.228 on Windows might allow a remote unauthenticated actor to execute arbitrary code via a maliciously crafted project directory containing an executable that bypasses workspace trust protections when a local user opens the directory. To remediate this issue, users should upgrade to version 1.0.228 or higher.

In Apache CXF's DefaultEncryptingOAuthDataProvider, revoked access tokens still decrypt successfully, and TokenIntrospectionService reports active:true. The same applies to refresh tokens. This violates the RFC stipulations that 'The authorization server MUST invalidate the token.' and 'introspection of a revoked token MUST return {"active":false}'. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

It was not possible to govern the rate at which the broker would respond to an echo flow, enabling an authenticated attacker to cause excessive resource usage and potential denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

In Apache CXF's DefaultEncryptingCodeDataProvider, a captured authorization code can be redeemed an unlimited number of times due to a flaw in the implementation of the removeCodeGrant functionality. This violates the RFC requirement that "The authorization code MUST NOT be used more than once." Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

It was not possible to govern the maximum number of transfer frames per incoming delivery, enabling an authenticated attacker to cause excessive resource usage and potential denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

An authenticated attacker can craft a disposition frame with large or illegal ranges causing excessive CPU usage due to naive range handling, leading to denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

An authenticated attacker could exceed the session flow control incoming window potentially leading to denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

A pre-authentication attacker could leverage unbounded symbol value caching to cause resource exhaustion leading to denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service. This issue affects Apache Qpid Broker-J: through 10.0.1. Users are recommended to upgrade to version 10.1.0, which fixes the issue.

It was not possible to govern the maximum number of transfer frames per incoming delivery, enabling an authenticated attacker to cause excessive resource usage and potential denial of service. This issue affects Apache Qpid ProtonJ2: through 1.1.0. Users are recommended to upgrade to version 1.2.0, which fixes the issue

An authenticated attacker could exceed the session flow control incoming window potentially leading to denial of service. This issue affects Apache Qpid ProtonJ2: through 1.1.0. Users are recommended to upgrade to version 1.2.0, which fixes the issue.

A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid ProtonJ2: through 1.1.0. Users are recommended to upgrade to version 1.2.0, which fixes the issue.

A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service. This issue affects Apache Qpid ProtonJ2: through 1.1.0. Users are recommended to upgrade to version 1.2.0, which fixes the issue.

A pre-authentication attacker could leverage unbounded symbol value caching to cause resource exhaustion leading to denial of service. This issue affects Apache Qpid ProtonJ2: through 1.1.0. Users are recommended to upgrade to version 1.2.0, which fixes the issue.

It was not possible to govern the maximum number of transfer frames per incoming delivery, enabling an authenticated attacker to cause excessive resource usage and potential denial of service This issue affects Apache Qpid Proton-Dotnet: through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue.

An authenticated attacker can craft a disposition frame with large or illegal ranges causing excessive CPU usage due to naive range handling, leading to denial of service. This issue affects Apache Qpid Proton-Dotnet: through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue.

An authenticated attacker could exceed the session flow control incoming window potentially leading to denial of service. This issue affects Apache Qpid Proton-Dotnet: through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue.

A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid Proton-Dotnet through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue

pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service. This issue affects Apache Qpid Proton-Dotnet: through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue.

A pre-authentication attacker could leverage unbounded symbol value caching to cause resource exhaustion leading to denial of service. This issue affects Apache Qpid Proton-Dotnet: through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue.

Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

It was not possible to govern the maximum number of transfer frames per incoming delivery, enabling an authenticated attacker to cause excessive resource usage and potential denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue.

An authenticated attacker can craft a disposition frame with large or illegal ranges causing excessive CPU usage due to naive range handling, leading to denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue.

An authenticated attacker could exceed the session flow control incoming window potentially leading to denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue.

A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue.

A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue.

A pre-authentication attacker could leverage unbounded symbol value caching to cause resource exhaustion leading to denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue.

Apache CXF’s OIDC relying-party token validation could accept self-issued ID tokens without enforcing required claim checks (issuer/subject/audience/time and sub_jwk binding), enabling authentication bypass with crafted tokens. However, note that self-issued ID tokens are not accepted by default in the validator. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fixes this issue.

Apache CXF reads a top-level WSDL through its hardened StaxUtils path, which disables XML DTDs and external entities. However, any <wsdl:import> or <xsd:import> referenced from that top-level WSDL is handed off to WSDL4J, which does not disable DOCTYPE declarations or external entities. As a result, the protections applied to the top-level document do not extend to imported documents, leaving imported WSDL/XSD content vulnerable to XML External Entity (XXE) attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

An incomplete fix for CVE-2026-50645 means that it is still possible to perform a denial of service attack on Apache CXF by sending a message with many attachment headers. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Apache Polaris did not consistently validate storage locations supplied during table and view registration. An authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog's storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog's allowed storage locations. If the catalog's underlying credentials could read an object outside that boundary, this could disclose limited information from the object. Polaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary. This second condition did not itself cause Polaris to read the referenced external locations during registration. The demonstrated impact is limited to confidentiality. No unauthorized data modification or availability impact has been demonstrated. The server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog's underlying storage credentials can read. Exploitation requires an authenticated principal with table- or view-registration privileges.

Apache CXF's JwtRequestCodeFilter copies all claims from a signed request JWT into the authorization parameter map without excluding security-sensitive parameters. A client that can produce a validly-signed request JWT (e.g., one whose client_secret is known or compromised) can thereby substitute the code_challenge, code_challenge_method, nonce, and state values that were set in the outer HTTP request, undermining PKCE integrity and OpenID Connect replay protection. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

** UNSUPPORTED WHEN ASSIGNED ** Stack-based Buffer Overflow vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Memory Allocation with Excessive Size Value vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Deserialization of Untrusted Data vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Uncontrolled Recursion vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

In Apache CXF's OAuth2 Dynamic Client Registration endpoint, the authorization server accepts and stores the `scope` value supplied in the client registration request verbatim, without validating it against an AS-defined allowlist. This could lead to a client self-assigning privileged scopes at registration time. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Insufficient Session Expiration vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.1. Administrative API keys remained usable after the owning administrator was demoted or the account was marked inactive, suspended, or deleted, allowing continued access until the keys were explicitly removed. Users are recommended to upgrade to version 2.0.2, which fixes the issue.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.1. Deleted or pending answers could be retrieved by unauthorized users through the single-answer read path when the parent question remained visible, exposing answer content that should not have been accessible. Users are recommended to upgrade to version 2.0.2, which fixes the issue.

Apache CXF allows to set a limit on the number of form parameters in a JAX-RS message via the "maxFormParameterCount" configuration option. However, no default limit is set which may lead to denial of service attacks when processing  requests with very large numbers of form parameters. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue by using a default limit of 500 parameters.

A race condition in JCacheCodeDataProvider allows an attacker to redeem a single authorization code multiple times via concurrent requests, resulting in the issuance of multiple distinct, valid access tokens. Users are recommended to upgrade to versions 4.2.3, 4.1.8 or 3.6.12, which fix this issue.