ghsa

In Appwrite CLI before 3.0.0, when using the login command, the credentials of the Appwrite user are stored in a ~/.appwrite/prefs.json file with 0644 as UNIX permissions. Any user of the local system can access those credentials.

Qualys Jenkins Plugin for Policy Compliance prior to version and including 1.0.5 was identified to be affected by a security flaw, which was missing a permission check while performing a connectivity check to Qualys Cloud Services. This allowed any user with login access and access to configure or edit jobs to utilize the plugin to configure a potential rouge endpoint via which it was possible to control response for certain request which could be injected with XSS payloads leading to XSS while processing the response data.

Qualys Jenkins Plugin for Policy Compliance prior to version and including 1.0.5 was identified to be affected by a security flaw, which was missing a permission check while performing a connectivity check to Qualys Cloud Services. This allowed any user with login access to configure or edit jobs to utilize the plugin and configure potential a rouge endpoint via which it was possible to control response for certain request which could be injected with XXE payloads leading to XXE while processing the response data

Qualys Jenkins Plugin for WAS prior to version and including 2.0.11 was identified to be affected by a security flaw, which was missing a permission check while performing a connectivity check to Qualys Cloud Services. This allowed any user with login access to configure or edit jobs to utilize the plugin and configure potential a rouge endpoint via which it was possible to control response for certain request which could be injected with XXE payloads leading to XXE while processing the response data

juzaweb <= 3.4 is vulnerable to Incorrect Access Control, resulting in an application outage after a 500 HTTP status code. The payload in the timezone field was not correctly validated.

Race condition in snap-confine's must_mkdir_and_open_with_perms()

### Impact On some platforms, when an attacker can time decapsulation of Kyber on forged cipher texts, they could possibly learn (parts of) the secret key. Does not apply to ephemeral usage, such as when used in the regular way in TLS. ### Patches Patched in 1.3.7. ### References - [kyberslash.cr.yp.to](https://kyberslash.cr.yp.to/)

### Impact A user able to attach a file to a page can post a malformed TAR file by manipulating file modification times headers, which when parsed by Tika, could cause a denial of service issue via CPU consumption. ### Patches This vulnerability has been patched in XWiki 14.10.18, 15.5.3 and 15.8 RC1. ### Workarounds The workaround is to download [commons-compress 1.24](https://search.maven.org/remotecontent?filepath=org/apache/commons/commons-compress/1.24.0/commons-compress-1.24.0.jar) and replace the one located in XWiki `WEB-INF/lib/` folder. ### References https://jira.xwiki.org/browse/XCOMMONS-2796 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)

### Impact XWiki is vulnerable to a remote code execution (RCE) attack through its user registration feature. This issue allows an attacker to execute arbitrary code by crafting malicious payloads in the "first name" or "last name" fields during user registration. This impacts all installations that have user registration enabled for guests. To reproduce, register with any username and password and the following payload as "first name": `]]{{/html}}{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack succeeded){{/groovy}}{{/async}}`. In the following page that confirms the success of the registration, the full first name should be displayed, linking to the created user. If the formatting is broken and a log message with content "ERROR attacker - Attack succeeded!" is logged, the attack succeeded. ### Patches This vulnerability has been patched in XWiki 14.10.17, 15.5.3 and 15.8 RC1. ### Workarounds In the administration of your wiki, under "Users & Rights" > "Reg...

### Impact The rollback action is missing a right protection: it means that a user can rollback to a previous version of the page to gain rights they don't have anymore. This vulnerability impacts all version of XWiki since rollback action is available. ### Patches The problem has been patched in XWiki 14.10.16, 15.5.3 and 15.8-rc-1 by ensuring that the rights are checked before performing the rollback. ### Workarounds There's no workaround for this vulnerability, except paying attention to delete old versions of documents that could allow users to gain more rights. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-21257 * Commit: [4de72875ca49602796165412741033bfdbf1e680](https://github.com/xwiki/xwiki-platform/commit/4de72875ca49602796165412741033bfdbf1e680) ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@x...