#git

### Summary The traefik docker container uses 100% CPU when it serves as its own backend, which is an automatically generated route resulting from the Docker integration in the default configuration. ### Details While attempting to set up Traefik to handle traffic for Docker containers, I observed in the webUI a rule with the following information: `Host(traefik-service) | webwebsecure | traefik-service@docker | traefik-service` I assumed that this is something internal; however, I wondered why it would have a host rule on the web entrypoint configured. So I have send a request with that hostname with `curl -v --resolve "traefik-service:80:xxx.xxx.xxx.xxx" http://traefik-service`. That made my whole server unresponsive. I assume the name comes from a docker container with that name, traefik itself: ``` localhost ~ # docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS ...

## Impact There is a potential vulnerability in Traefik managing the ACME HTTP challenge. When Traefik is configured to use the [HTTPChallenge](https://doc.traefik.io/traefik/https/acme/#httpchallenge) to generate and renew the Let's Encrypt TLS certificates, the delay authorized to solve the challenge (50 seconds) can be exploited by attackers ([slowloris attack](https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/)). ## Patches - https://github.com/traefik/traefik/releases/tag/v2.10.6 - https://github.com/traefik/traefik/releases/tag/v3.0.0-beta5 ## Workarounds Replace the HTTPChallenge with the [TLSChallenge](https://doc.traefik.io/traefik/https/acme/#tlschallenge) or the [DNSChallenge](https://doc.traefik.io/traefik/https/acme/#dnschallenge). ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

### Summary When a request is sent to Traefik with a URL fragment, Traefik automatically URL encodes and forwards the fragment to the backend server. This violates the RFC because in the origin-form the URL should only contain the absolute path and the query. When this is combined with another frontend proxy like Nginx, it can be used to bypass frontend proxy URI-based access control restrictions. ### Details For example, we have this Nginx configuration: ``` location /admin { deny all; return 403; } ``` This can be bypassed when the attacker is requesting to /#/../admin This won’t be vulnerable if the backend server follows the RFC and ignores any characters after the fragment. However, if Nginx is chained with another reverse proxy which automatically URL encode the character # (Traefik) the URL will become /%23/../admin And allow the attacker to completely bypass the Access Restriction from the Nginx Front-End proxy. Here is a diagram to summarize the attack: ![i...

An issue exists in SoftIron HyperCloud where compute nodes may come online immediately without following the correct initialization process.  In this instance, workloads may be scheduled on these nodes and deploy to a failed or erroneous state, which impacts the availability of these workloads that may be deployed during this time window. This issue impacts HyperCloud versions from 2.0.0 to before 2.0.3.

Before Go 1.20, the RSA based TLS key exchanges used the math/big library, which is not constant time. RSA blinding was applied to prevent timing attacks, but analysis shows this may not have been fully effective. In particular it appears as if the removal of PKCS#1 padding may leak timing information, which in turn could be used to recover session key bits. In Go 1.20, the crypto/tls library switched to a fully constant time RSA implementation, which we do not believe exhibits any timing side channels.

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/nav/update.

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/slide/update.

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/friend_link/update.

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/slide/save.

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) via /admin/slide/delete.