Source
ghsa
### Summary Graylog utilises only one single source port for DNS queries. ### Details Graylog seems to bind a single socket for outgoing DNS queries. That socket is bound to a random port number which is not changed again. This goes against recommended practice since 2008, when Dan Kaminsky discovered how easy is to carry out DNS cache poisoning attacks. In order to prevent cache poisoning with spoofed DNS responses, it is necessary to maximise the uncertainty in the choice of a source port for a DNS query. ### PoC The attached figure shows the source ports distribution difference between Graylog configured to use a data adapter based on DNS queries and ISC Bind. The source port distribution of the DNS queries sent from Graylog to a recursive DNS name server running Bind (CLIENT_QUERY) are depicted in purple, while the queries sent from the recursive DNS server to the authoritatives (RESOLVER_QUERY) are plotted in green color. As it can be observed, in contrast to ISC Bind which ...
### Summary In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. ### Details Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the...
### Impact A path traversal (directory traversal) vulnerability affects fides versions lower than `2.15.1`, allowing remote attackers to access arbitrary files on the fides webserver container's filesystem. ### Patches The vulnerability is patched in fides `2.15.1`. Users should upgrade to this version. ### Workarounds If the Fides webserver API is not directly accessible to attackers and is instead deployed behind a reverse proxy as recommended in Ethyca's [security best practice documentation](https://docs.ethyca.com/docs/configuration/security-practices#reverse-proxy), and the reverse proxy is an AWS application load balancer, the vulnerability can't be exploited by these attackers. An AWS application load balancer will reject this attack with a 400 error. Additionally, any secrets supplied to the container using environment variables rather than a `fides.toml` configuration file are not affected by this vulnerability.
### Impact During file downloads, yt-dlp or the external downloaders that yt-dlp employs may leak cookies on HTTP redirects to a different host, or leak them when the host for download fragments differs from their parent manifest's host. This vulnerable behavior is present in all versions of [youtube-dl](https://github.com/ytdl-org/youtube-dl), [youtube-dlc](https://github.com/blackjack4494/yt-dlc) and [yt-dlp](https://github.com/yt-dlp/yt-dlp) released since 2015.01.25. All native and external downloaders are affected, except for `curl` and `httpie` (httpie version 3.1.0 or later). At the file download stage, all cookies are passed by yt-dlp to the file downloader as a `Cookie` header, thereby losing their scope. This also occurs in yt-dlp's info JSON output, which may be used by external tools. As a result, the downloader or external tool may indiscriminately send cookies with requests to domains or paths for which the cookies are not scoped. An example of a potential attack scena...
### Impact Using carefully crafted input, an attacker may be able to sneak arbitrary HTML and CSS through Sanitize `>= 3.0.0, < 6.0.2` when Sanitize is configured to use the built-in "relaxed" config or when using a custom config that allows `style` elements and one or more CSS at-rules. This could result in XSS (cross-site scripting) or other undesired behavior when the malicious HTML and CSS are rendered in a browser. ### Patches Sanitize `>= 6.0.2` performs additional escaping of CSS in `style` element content, which fixes this issue. ### Workarounds Users who are unable to upgrade can prevent this issue by using a Sanitize config that doesn't allow `style` elements, using a Sanitize config that doesn't allow CSS at-rules, or by manually escaping the character sequence `</` as `<\/` in `style` element content. ### Credit This issue was found by @cure53 during an audit of a project that uses Sanitize and was reported by one of that project's maintainers. Thank you!
Streampark allows any users to upload a jar as application, but there is no mandatory verification of the uploaded file type. This means users may upload some high-risk files, and may upload them to any directory. Users of the affected versions should upgrade to Apache StreamPark 2.0.0 or later.
Apache StreamPark 1.0.0 before 2.0.0 When the user successfully logs in, to modify his profile, the username will be passed to the server-layer as a parameter, but not verified whether the user name is the currently logged user and whether the user is legal, This will allow malicious attackers to send any username to modify and reset the account, Users of the affected versions should upgrade to Apache StreamPark 2.0.0 or later.
An authenticated user with specific data permissions could access database connections stored passwords by requesting a specific REST API. This issue affects Apache Superset version 1.3.0 up to 2.0.1.
A malicious actor who has been authenticated and granted specific permissions in Apache Superset may use the import dataset feature in order to conduct Server-Side Request Forgery attacks and query internal resources on behalf of the server where Superset is deployed. This vulnerability exists in Apache Superset versions up to and including 2.0.1.
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.5.0. By manipulating the "orderType" parameter and the ordering of the returned content using an SQL injection attack, an attacker can extract the username of the user with ID 1 from the "user" table, one character at a time. Users are advised to upgrade to Apache InLong's 1.6.0 or cherry-pick PR #7530 to solve it.