Source
ghsa
### Summary `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network input. ### Details Verified at `0.22` and `0.23` `rustls`, but 0.21 and 0.20 release lines are also affected. When using a blocking rustls server, if a client send a `close_notify` message immediately after `client_hello`, the server's `complete_io` will get in an infinite loop where: - `eof`: false - `until_handshaked`: true - `self.is_handshaking()`: true - `self.wants_write()`: false - `self.wants_read()`: false ### PoC 1. Run simple server: `cargo run --bin simpleserver test-ca/rsa/end.fullchain test-ca/rsa/end.key` 2. Run following python script ```python3 #!/usr/bin/env python3 import socket sock = socket.socket() sock.connect(("localhost", 4443)) print("Sending client hello...") # Fake handshake data of a client hello message. fake_handshake = """ 1603 0100 c801 0000 c403 03ec 12dd 1764 a439 fd7e 8c85 46b8 4d1e a...
TCPDF version <=6.7.4 is vulnerable to ReDoS (Regular Expression Denial of Service) if parsing an untrusted HTML page with a crafted color.
### Summary This is basically [GHSA-88j4-pcx8-q4q](https://github.com/louislam/uptime-kuma/security/advisories/GHSA-88j4-pcx8-q4q3) but instead of changing passwords, when enabling authentication. ### PoC - Open Uptime Kuma with authentication disabled - Enable authentication using another window - Access the platform using the previously logged-in window - Note that access (read-write) remains despite the enabled authentication - Expected behaviour: - After enabling authentication, all previously connected sessions should be invalidated, requiring users to log in. - Actual behaviour: - The system retains sessions and never logs out users unless explicitly done by clicking logout or refreshing the page. ### Impact See [GHSA-g9v2-wqcj-j99g](https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g) and [GHSA-88j4-pcx8-q4q](https://github.com/louislam/uptime-kuma/security/advisories/GHSA-88j4-pcx8-q4q3) TBH this is quite a niche edge case, so I don't know if ...
In 26.0.0 and 26.0.1, IPv6 is not disabled on network interfaces, including those belonging to networks where `--ipv6=false`. ### Impact A container with an `ipvlan` or `macvlan` interface will normally be configured to share an external network link with the host machine. Because of this direct access, with IPv6 enabled: - Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses. - If router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses. - The interface will be a member of IPv6 multicast groups. This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface. A container with an unexpected IPv6 address can do anything a container configured with an IPv6 address can do. That is, listen for connections on its IPv6 address, open connections to other nodes on the network over IPv6, or attempt a DoS attack by flooding packets from i...
### Impact When authenticating as a superuser to Sentry with a username and password, the password is leaked as cleartext in logs under the _event_: `auth-index.validate_superuser`. An attacker with access to the log data could use these leaked credentials to login to the Sentry system as superuser. ### Patches - Sentry SaaS users do not need to take any action. - Self-hosted users on affected versions should upgrade to 24.4.1 or later. ### Workarounds Users can configure the logging level to exclude logs of the `INFO` level and only generate logs for levels at `WARNING` or more. For details on configuring self-hosted Sentry's logging level see our documentation at: https://develop.sentry.dev/config/#logging ### References - Bug introduced in https://github.com/getsentry/sentry/pull/66393 - Security fix in https://github.com/getsentry/sentry/pull/69148
### Summary 源码中密码校验处使用 != 符号,而不是`hmac.Equal`,这可能导致产生计时攻击漏洞,从而爆破密码。 建议使用 `hmac.Equal` 比对密码。 ### Details https://github.com/1Panel-dev/1Panel/blob/dev/backend/app/service/auth.go#L81C5-L81C26 ### PoC ### Impact 该产品的所有使用者。
### Summary Observed a HTML Injection vulnerbaility in the Home page of Dolibarr Application. This vulnerability allows an attacker to inject arbitrary HTML tags and manipulate the rendered content in the application's response. Specifically, I was able to successfully inject a new HTML tag into the returned document and, as a result, was able to comment out some part of the Dolibarr App Home page HTML code. This behavior can be exploited to perform various attacks like Cross-Site Scripting (XSS). ### Details 1. Navigate to the login page of Dolibarr application. 2. Submit a login request with the following payload in an arbitrarily supplied body parameter: "**u70ea%22%3e%3c!--HTML_Injection_By_Sai"=1** **HTTP Post Request:** POST /dolibarr/index.php?mainmenu=home HTTP/1.1 Host: 192.168.37.129 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept...
An issue inandrei-tatar nora-firebase-common between v.1.0.41 and v.1.12.2 allows a remote attacker to execute arbitrary code via a crafted script to the updateState parameter of the updateStateInternal method.
### Summary A XSS vulnerability exists on index pages for static file handling. ### Details When using `web.static(..., show_index=True)`, the resulting index pages do not escape file names. If users can upload files with arbitrary filenames to the static directory, the server is vulnerable to XSS attacks. ### Workaround We have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected. Other users can disable `show_index` if unable to upgrade. ----- Patch: https://github.com/aio-libs/aiohttp/pull/8319/files
Airflow versions 2.7.0 through 2.8.4 have a vulnerability that allows an authenticated user to see sensitive provider configuration via the "configuration" UI page when "non-sensitive-only" was set as "webserver.expose_config" configuration (The celery provider is the only community provider currently that has sensitive configurations). You should migrate to Airflow 2.9 or change your "expose_config" configuration to False as a workaround. This is similar, but different to CVE-2023-46288 https://github.com/advisories/GHSA-9qqg-mh7c-chfq which concerned API, not UI configuration page.