Source
ghsa
### Impact It's possible for a user to pass a relative file path for the snapshot name and reach outside of the project directory into the machine running the test. Example: ```js cy.get('h1').matchImageSnapshot('../../../ignore-relative-dirs') ``` The above will create an `ignore-relative-dirs.png` three levels up ### Patches Fixed in `8.0.2` ### Workarounds Validate all the existing uses of `matchImageSnapshot` to ensure correct use of the filename argument. Example: ```js // snapshot name will be the test title cy.matchImageSnapshot(); // snapshot name will be the name passed in cy.matchImageSnapshot('login'); ``` ### References https://github.com/simonsmith/cypress-image-snapshot/issues/15
A Command injection vulnerability in RaspAP 2.8.0 thru 2.8.7 allows unauthenticated attackers to execute arbitrary commands via the `cfg_id` parameter in `/ajax/openvpn/activate_ovpncfg.php` and `/ajax/openvpn/del_ovpncfg.php`.
A Command injection vulnerability in RaspAP 2.8.0 thru 2.9.2 allows an authenticated attacker to execute arbitrary OS commands as root via the `entity` POST parameters in `/ajax/networking/get_wgkey.php`.
Versions of the package underscore-keypath from 0.0.11 are vulnerable to Prototype Pollution via the name argument of the `setProperty()` function. Exploiting this vulnerability is possible due to improper input sanitization which allows the usage of arguments like `__proto__`.
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...