Infinit3I

An issue exists where the `SAML.verifySamlResponseSignature` function calls `OpenSAML SignatureValidator.validate` without first applying `SAMLSignatureProfileValidator`. This allows the system to accept a cryptographically valid signature that references an XML element different from the Response or Assertion used for authentication. An attacker can move a signed element within the document and provide a malicious identity-bearing element, leading to XML Signature Wrapping, which enables authentication as another identity provider user. This affects both response-level and assertion-level signing paths, and remains reachable during SP-initiated login even if `allowIDPInitiatedLogin` is disabled.

An issue exists in the `SAML.handleCallback()` function where it fails to consume RelayState, record assertion identifiers, or enforce `Response.InResponseTo`. In Service Provider (SP)-initiated flows, an attacker with a valid SAML response and matching RelayState can resubmit them to the `/recipe/saml/callback` endpoint before the assertion expires. In Identity Provider (IdP)-initiated flows, assertions can be replayed without RelayState. Additionally, the lack of `Response.InResponseTo` checks allows an active login to be completed using an assertion for a different identity and bypasses the `allowIDPInitiatedLogin=false` setting. The callback also fails to validate Destination or SubjectConfirmationData Recipient and NotOnOrAfter, resulting in the creation of a new authorization code for the captured user's identity.

A SQL injection issue exists in the Mautic administration interface at the '/s/ajax' endpoint. The problem occurs because a request parameter used to select the contact field for searching is not properly validated before being included in a database query. Any authenticated user, regardless of their assigned role or permissions, can exploit this using blind techniques—such as boolean-based or time-based methods—to execute arbitrary SQL queries. This allows the attacker to read sensitive information from the database, including user accounts, email addresses, password hashes, contact data, and campaign content.

An issue exists where the `ApplicationModel.ts` model accepts a caller-chosen application authorization identifier. The endpoint 'applications/:id/confirm' binds this identifier to a logged-in user via a generic consent page. Subsequently, the public endpoint 'packages/server/src/routes/api/application auth.ts' passes this identifier to the `createAppPassword()` function without authenticating or binding the redeemer. This allows an attacker to trick a victim into approving a malicious identifier, obtain a durable application ID and password, and exchange these credentials for a session with full read and write access to the victim's synchronized data.

An issue exists in the `host port()` function within `adminer/include/functions.inc.php` where the login `server` string is improperly parsed. The port capture group requires digits anchored to the end of the string; if a server value contains a non-digit tail, the regex fails and the entire string is returned as the host with an empty port. This allows a remote, unauthenticated attacker to bypass the privileged-port restriction in `adminer/include/auth.inc.php` by submitting a crafted value, such as `127.0.0.1:80/x`. Consequently, the mysqli/mysqlnd client re-parses the host and port, enabling server-side request forgery (SSRF) and blind internal port scanning by observing connection responses (connection refused, handshake, or timeout) before credentials are validated.

The software prepends the client-supplied `X-Forwarded-Prefix` header to `$ SERVER["REQUEST URI"]` without performing a trusted-proxy check or validating the prefix value. An attacker can provide an absolute URL via the `X-Forwarded-Prefix` header, which is then incorporated into Location redirect headers, the Set-Cookie path attribute, and self-referential links. This allows for an authenticated open redirect following state-changing POST requests, unauthenticated control over the session cookie path attribute, and the poisoning of self-referential links. Header splitting and Cross-Site Scripting (XSS) are not possible as Carriage Return/Line Feed (CR/LF) characters cannot be injected.

A server-side request forgery (SSRF) issue exists in the login form's server field validator. The validator only checks leading integers for privileged ports and does not reject non-numeric port values. This allows attackers to inject PDO DSN keys, such as `host=` and `port=`, into the `server` parameter to bypass restrictions on privileged ports and establish TCP connections to arbitrary internal hosts and ports before authentication.

An incomplete fix in the validation guard within `bootstrap.inc.php` allows certain values in the `X-Forwarded-Prefix` header to bypass security checks. While the system blocks prefixes starting with `//`, it permits values where the second character is a backslash, such as `/evil.com`. Since browsers normalize backslashes to forward slashes, this network-path reference persists in the `REQUEST URI` and reaches the `cookie path()` function, which affects the Set-Cookie Path attribute. This issue can be exploited if clients can set the `X-Forwarded-Prefix` header, typically due to a misconfigured or absent reverse proxy, resulting in anomalous cookie-path scoping.