ghsa

### Impact The create action is vulnerable to a CSRF attack, allowing script and thus remote code execution when targeting a user with script/programming right, thus compromising the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, the XWiki syntax `[[image:path:/xwiki/bin/create/Foo/WebHome?template=&parent=Main.WebHome&title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22)]]` can be added to any place that supports XWiki syntax like a comment. When a user with script right views this image and a log message `ERROR foo - Script executed!` appears in the log, the XWiki installation is vulnerable. ### Patches This has been patched in XWiki 14.10.9 and 15.4RC1 by requiring a CSRF token for the actual page creation. ### Workarounds There are no known workarounds. ### References * https://jira.xwiki.org/browse/XWIKI-20849 * https://github.com/xwiki/xwiki-platform/commit/4b20528808d0c311290b0d9ab2cfc44063380ef7

There is a possible file disclosure of locally encrypted files in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-38037. Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.7.1, 6.1.7.5 # Impact ActiveSupport::EncryptedFile writes contents that will be encrypted to a temporary file. The temporary file’s permissions are defaulted to the user’s current umask settings, meaning that it’s possible for other users on the same system to read the contents of the temporary file. Attackers that have access to the file system could possibly read the contents of this temporary file while a user is editing it. All users running an affected release should either upgrade or use one of the workarounds immediately. # Releases The fixed releases are available at the normal locations. # Workarounds To work around this issue, you can set your umask to be more restrictive like this: ```ruby $ umask 0077 ```

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 these vulnerabilities. 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 these vulnerabilities because it uses TinyMCE 6.

Apache Airflow SMTP Provider before 1.3.0, Apache Airflow IMAP Provider before 3.3.0, and Apache Airflow before 2.7.0 are affected by the Validation of OpenSSL Certificate vulnerability. The default SSL context with SSL library did not check a server's X.509 certificate.  Instead, the code accepted any certificate, which could result in the disclosure of mail server credentials or mail contents when the client connects to an attacker in a MITM position. Users are strongly advised to upgrade to Apache Airflow version 2.7.0 or newer, Apache Airflow IMAP Provider version 3.3.0 or newer, and Apache Airflow SMTP Provider version 1.3.0 or newer to mitigate the risk associated with this vulnerability

Apache Airflow, in versions prior to 2.7.0, contains a security vulnerability that can be exploited by an authenticated user possessing Connection edit privileges. This vulnerability allows the user to access connection information and exploit the test connection feature by sending many requests, leading to a denial of service (DoS) condition on the server. Furthermore, malicious actors can leverage this vulnerability to establish harmful connections with the server. Users of Apache Airflow are strongly advised to upgrade to version 2.7.0 or newer to mitigate the risk associated with this vulnerability. Additionally, administrators are encouraged to review and adjust user permissions to restrict access to sensitive functionalities, reducing the attack surface.

The session fixation vulnerability allowed the authenticated user to continue accessing Airflow webserver even after the password of the user has been reset by the admin - up until the expiry of the session of the user. Other than manually cleaning the session database (for database session backend), or changing the secure_key and restarting the webserver, there were no mechanisms to force-logout the user (and all other users with that). With this fix implemented, when using the database session backend, the existing sessions of the user are invalidated when the password of the user is reset. When using the securecookie session backend, the sessions are NOT invalidated and still require changing the secure key and restarting the webserver (and logging out all other users), but the user resetting the password is informed about it with a flash message warning displayed in the UI. Documentation is also updated explaining this behaviour. Users of Apache Airflow are advised to upgrade to ...

### Impact All versions of Argo CD starting from v2.6.0 have a bug where open web terminal sessions do not expire. This bug allows users to send any websocket messages even if the token has already expired. The most straightforward scenario is when a user opens the terminal view and leaves it open for an extended period. This allows the user to view sensitive information even when they should have been logged out already. ### Patches A patch for this vulnerability has been released in the following Argo CD version: * v2.6.14 * v2.7.12 * v2.8.1 ### Workarounds The only way to completely resolve the issue is to upgrade. #### Mitigations Disable web-based terminal or define RBAC rules to it [https://argo-cd.readthedocs.io/en/latest/operator-manual/web_based_terminal/](https://argo-cd.readthedocs.io/en/latest/operator-manual/web_based_terminal/) ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Argo CD issue tracker](https://gi...

The json2xml package for Python allows an error in typecode decoding enabling a remote attack that can lead to an exception, causing a denial of service.

An issue was discovered in the hcaptcha (aka hCaptcha for EXT:form) extension before 2.1.2 for TYPO3. It fails to check that the required captcha field is submitted in the form data. allowing a remote user to bypass the CAPTCHA check.

An issue in langchain v.0.0.171 allows a remote attacker to execute arbitrary code via the via the a json file to the load_prompt parameter.