Source
ghsa
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Superset. Specifically, certain engine-specific functions are not checked, which allows attackers to bypass Apache Superset's SQL authorization. This issue is a follow-up to CVE-2024-39887 with additional disallowed PostgreSQL functions now included: query_to_xml_and_xmlschema, table_to_xml, table_to_xml_and_xmlschema. This issue affects Apache Superset: <4.1.0. Users are recommended to upgrade to version 4.1.0, which fixes the issue or add these Postgres functions to the config set DISALLOWED_SQL_FUNCTIONS.
nanoid (aka Nano ID) before 5.0.9 mishandles non-integer values. 3.3.8 is also a fixed version.
### Impact Due to some data types not being natively representable for the available storage options, shared_preferences_android serializes and deserializes special string prefixes to store these unrepresentable data types. This allows arbitrary classes to be deserialized leading to arbitrary code execution. As a result, Files containing the preferences can be overwritten with a malicious one with a deserialization payload that triggers as soon as the data is loaded from the disk. ### Patches 2.3.4 ### Workarounds Update to the latest version of shared_preferences_android that contains the changes to address this vulnerability. ### References TBD ### For more information See [our community page](https://dart.dev/community) to find ways to contact the team. ### Thanks Thank you so much to Oskar Zeino-Mahmalat from sonarsource for finding and reporting this issue!
### Summary Exposure of database (ie postgreSQL) server's credential when connection to DB fails. ### Details Exposed database credentials upon misconfig/DoS @ permalink: https://github.com/thorsten/phpMyFAQ/blob/main/phpmyfaq/src/phpMyFAQ/Setup/Installer.php#L694 ### PoC When postgreSQL server is unreachable, an error would be thrown exposing the credentials of the database. For instance, when "http://<phpmyfaq-instance>:8080/setup/index.php" is hit when the database instance/server is down, then credentials are exposed, for instance: ``` ( ! ) Warning: pg_connect(): Unable to connect to PostgreSQL server: connection to server at "127.0.0.1", port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78 Call Stack # Time Memory Function Location 1 0.0404 453880 {main}( ) .../index.php:0 2 1.1341 610016 phpMyFAQ\Setup\Installer->startInstall( $setup = ??? ) .../index.php...
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (Applications that use the jsonfield.has_key lookup via __ are unaffected.)
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.
A stored cross-site scripting (XSS) vulnerability in the Device Settings section of LibreNMS v24.9.0 to v24.10.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Display Name parameter.
### Impact The regular expression that is vulnerable to backtracking can be generated in the 0.1.x release of `path-to-regexp`, originally reported here: https://github.com/advisories/GHSA-9wv6-86v2-598j ### Patches Upgrade to 0.1.12. ### Workarounds Avoid using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking. ### References - https://github.com/advisories/GHSA-9wv6-86v2-598j - https://blakeembrey.com/posts/2024-09-web-redos/
### Summary The Comment feature has implemented a filter to prevent users from adding restricted characters, such as HTML tags. However, this filter operates on the client-side, which can be bypassed, making the application vulnerable to HTML Injection. ### Details The Comment feature implements a character filter on the client-side, this can be bypassed by directly sending a request to the endpoint. Example Request: ``` PATCH /activity/comment/3 HTTP/2 Host: directus.local { "comment": "<h1>TEST <p style=\"color:red\">HTML INJECTION</p> <a href=\"//evil.com\">Test Link</a></h1>" } ``` Example Response: ```json { "data": { "id": 3, "action": "comment", "user": "288fdccc-399a-40a1-ac63-811bf62e6a18", "timestamp": "2023-09-06T02:23:40.740Z", "ip": "10.42.0.1", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36", "collection": "directus_files", "item": "7247dda1-c386-4e7a-...
### Summary sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients...