ghsa

OS Command Injection in GitHub repository mlflow/mlflow prior to 2.6.0.

HashiCorp's Vault and Vault Enterprise are vulnerable to user enumeration when using the LDAP auth method. An attacker may submit requests of existent and non-existent LDAP users and observe the response from Vault to check if the account is valid on the LDAP server. This vulnerability is fixed in Vault 1.14.1 and 1.13.5.

## Impact If configured to send emails using TLS, Sydent does not verify SMTP servers' certificates. This makes Sydent's emails vulnerable to interception via a [man-in-the-middle (MITM) attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack). Attackers with privileged access to the network can intercept room invitations and address confirmation emails. CVSS 3.1 overall score: 3.3 - [AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/CR:L/IR:L/AR:X/MAV:A/MAC:H/MPR:N/MUI:N/MS:C/MC:L/MI:L/MA:N](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/CR:L/IR:L/AR:X/MAV:A/MAC:H/MPR:N/MUI:N/MS:C/MC:L/MI:L/MA:N&version=3.1) _Reported by Martin Schobert, [Pentagrid AG](https://pentagrid.ch/)._ ### Details Sydent can be configured to send emails over a TLS-encrypted socket by setting ```yaml email: tlsmode: "TLS" # or the legacy value "SSL" ``` in its config file. Alternatively it can be configured to use [Opportunistic TLS](https://en.wikipedia.or...

### Summary The connection is not using TLS for communication ### Details In the configuration of the irc connection, [you are disabling tls](https://github.com/Xithrius/twitch-tui/blob/340afc3c8c07a83289fe6ef614aa7563c8b70756/src/twitch/connection.rs#L23) which makes all communication to twitch irc servers unencrypted. ### PoC You can verify by using tcpdump/wireshark that traffic is unencrypted. ### Impact Communication can be sniffed, even auth tokens.

TinyMCE 4.x is vulnerable to several XSS vectors, which had been patched in later versions. Two of these have been identified as affecting `silverstripe/admin`. Only Silverstripe CMS 4 is affected by this issue. It's not possible to upgrade Silverstripe CMS 4 to use a more recent release of TinyMCE without introducing breaking changes. Instead, the security patches that shipped in later releases of TinyMCE have been backported to the TinyMCE version bundled in `silverstripe/admin`. Silverstripe CMS 5 is not affected by those vulnerabilities because it uses TinyMCE 6. You can find more information about the underlying vulnerabilities in those GitHub security advisories: - [GHSA-5h9g-x5rv-25wg Cross-site scripting vulnerability in TinyMCE](https://github.com/advisories/GHSA-5h9g-x5rv-25wg) - [GHSA-w7jx-j77m-wp65 Cross-site scripting vulnerability in TinyMCE](https://github.com/advisories/GHSA-w7jx-j77m-wp65)

When a new `Member` record was created in the cms it was possible to set a blank password. If an attacker knows the email address of the user with the blank password then they can attempt to log in using an empty password. The default member authenticator, login form and basic auth all require a non-empty password, however if a custom authentication method is used it may allow a successful login with the empty password. Starting with this release, blank passwords are no no longer allowed when members are created in the CMS. Programatically created `Member` records, such as those used in unit tests, still allow blank passwords. You may have some `Member` records in your system already which have empty passwords. To detect these, you can loop over all `Member` records with `Member::get()` and pass each record into the below method. It might be sensible to create a [`BuildTask`](https://api.silverstripe.org/5/SilverStripe/Dev/BuildTask.html) for this purpose. ```php private function...

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.16.

Improper Neutralization of Formula Elements in a CSV File in GitHub repository thorsten/phpmyfaq prior to 3.1.16.

Apache NiFi 0.0.2 through 1.22.0 include Processors and Controller Services that support HTTP URL references for retrieving drivers, which allows an authenticated and authorized user to configure a location that enables custom code execution. The resolution introduces a new Required Permission for referencing remote resources, restricting configuration of these components to privileged users. The permission prevents unprivileged users from configuring Processors and Controller Services annotated with the new Reference Remote Resources restriction. Upgrading to Apache NiFi 1.23.0 is the recommended mitigation.

### Impact An high-privileged user could create a Package referencing an arbitrarily large image containing that Crossplane would then parse, possibly resulting in exhausting all the available memory and therefore in the container being OOMKilled. The impact is low due to the high privileges required to be able to create the Package and the eventually consistency nature of controller. ### Patches The problem has been fixed in 1.11.5, 1.12.3 and 1.13.0, all the supported versions of Crossplane at the time of writing. ### Workarounds Only using images from trusted sources and keeping Package editing/creating privileges to administrators only, which should be both considered already best practices. ### References See `ADA-XP-23-16` in the Security Audit's [report](https://github.com/crossplane/crossplane/blob/ac8b24fe739c5d942ea885157148497f196c3dd3/security/ADA-security-audit-23.pdf). ### Credits This was reported as `ADA-XP-23-16` by @AdamKorcz and @DavidKorczynski from Ada Lo...