ghsa

### Summary Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. ### Details DNS Messages are not authenticated. They do not guarantee that - received RRs are authentic - not received RRs do not exist - all or any received records in a response relate to the request Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) 1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases 2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) 3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's ta...

When editing a user, group or any object in the Syncope Console, HTML tags could be added to any text field and could lead to potential exploits. The same vulnerability was found in the Syncope Enduser, when editing "Personal Information" or "User Requests". Users are recommended to upgrade to version 3.0.8, which fixes this issue.

For RocketMQ versions 5.2.0 and below, under certain conditions, there is a risk of exposure of sensitive Information to an unauthorized actor even if RocketMQ is enabled with authentication and authorization functions. An attacker, possessing regular user privileges or listed in the IP whitelist, could potentially acquire the administrator's account and password through specific interfaces. Such an action would grant them full control over RocketMQ, provided they have access to the broker IP address list. To mitigate these security threats, it is strongly advised that users upgrade to version 5.3.0 or newer. Additionally, we recommend users to use RocketMQ ACL 2.0 instead of the original RocketMQ ACL when upgrading to version Apache RocketMQ 5.3.0.

In SFTPGo 2.6.2, the JWT implementation lacks certain security measures, such as using JWT ID (JTI) claims, nonces, and proper expiration and invalidation mechanisms.

Backdrop CMS before 1.27.3 and 1.28.x before 1.28.2 does not sufficiently sanitize field labels before they are displayed in certain places. This vulnerability is mitigated by the fact that an attacker must have a role with the "administer fields" permission.

The H2O machine learning platform uses "Iced" classes as the primary means of moving Java Objects around the cluster. The Iced format supports inclusion of serialized Java objects. When a model is deserialized, any class is allowed to be deserialized (no class whitelist). An attacker can construct a crafted Iced model that uses Java gadgets and leads to arbitrary code execution when imported to the H2O platform.

RAIL documents are an XML-based format invented by Guardrails AI to enforce formatting checks on LLM outputs. Guardrails users that consume RAIL documents from external sources are vulnerable to XXE, which may cause leakage of internal file data via the SYSTEM entity.

Cross Site Request Forgery vulnerability in ProcessWire v.3.0.229 allows a remote attacker to execute arbitrary code via a crafted HTML file to the comments functionality.

An arbitrary file upload vulnerability in the image upload function of Automad v2.0.0 allows attackers to execute arbitrary code via a crafted file.

In janeczku Calibre-Web 0.6.0 to 0.6.21, the edit_book_comments function is vulnerable to Cross Site Scripting (XSS) due to improper sanitization performed by the clean_string function. The vulnerability arises from the way the clean_string function handles HTML sanitization.