ghsa

Jenkins Fortify Plugin 22.1.38 and earlier does not perform permission checks in several HTTP endpoints. This allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Fortify Plugin 22.2.39 requires POST requests and the appropriate permissions for the affected HTTP endpoints.

Jenkins Fortify Plugin 22.1.38 and earlier does not escape the error message for a form validation method. This results in an HTML injection vulnerability. Fortify Plugin 22.2.39 removes HTML tags from the error message.

Jenkins Fortify Plugin 22.1.38 and earlier does not perform permission checks in several HTTP endpoints. This allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Fortify Plugin 22.2.39 requires POST requests and the appropriate permissions for the affected HTTP endpoints.

### Impact This vulnerability has the potential to steal a user's cookie and gain unauthorized access to that user's account through the stolen cookie or redirect users to other malicious sites. ### Patches Update to version 10.6.8 or apply this patch manually https://github.com/pimcore/pimcore/commit/234c0c02ea7502071b00ab673fbe4a6ac253080e.patch ### Workarounds Apply patch https://github.com/pimcore/pimcore/commit/234c0c02ea7502071b00ab673fbe4a6ac253080e.patch manually. ### References https://huntr.dev/bounties/245a8785-0fc0-4561-b181-fa20f869d993/

# Description wallabag was discovered to contain a Cross-Site Request Forgery (CSRF) which allows attackers to arbitrarily reset annotations, entries and tags, by the GET request to `/reset/annotations`, `/reset/entries`, `/reset/tags`, `/reset/archived`. This vulnerability has a CVSSv3.1 score of 4.3. **You should immediately patch your instance to version 2.6.3 or higher if you have more than one user and/or having open registration**. # Resolution These actions are now doable only via POST method, which ensures that we can't do them via a 3rd-party website. # Credits We would like to thank @zpbrent for reporting this issue through huntr.dev. Reference: https://huntr.dev/bounties/4ee0ef74-e4d4-46e7-a05c-076bce522299/

# Description wallabag was discovered to contain a Cross-Site Request Forgery (CSRF) which allows attackers to arbitrarily delete API key via `/developer/client/delete/{id}` This vulnerability has a CVSSv3.1 score of 6.5. **You should immediately patch your instance to version 2.6.3 or higher if you have more than one user and/or having open registration**. # Resolution This action is now doable only via POST method, which ensures that we can't do it via a 3rd-party website. # Credits We would like to thank @tht1997 for reporting this issue through huntr.dev. Reference: https://huntr.dev/bounties/5ab1b206-5fe8-4737-b275-d705e76f193a/

### Summary The lack of checking of current timestamp allows a LogoutRequest XML to be reused multiple times even when the current time is past the NotOnOrAfter. ### Details It was noticed that in the validatePostRequestAsync() flow in saml.js, the current timestamp is never checked. This could present a vulnerability where a user who has an XML LogoutRequest could validated it if the IssueInstance and the NotOnOrAfter are valid along with valid credentials (signature, certificate etc.). ### PoC I was able to validate a sample valid LogoutRequest XML multiple times through postman by sending it to my endpoint regardless if the current present time was past the NotOnOrAfter time. After some further testing, it seems that only the IssueInstance is checked against NotOnOrAfter. Not sure if this was the intended behaviour but I believe having a never expiring valid LogoutRequest could be dangerous. ### Impact This could impact the user where they would be logged out from an expire...

### Impact Any registered user can use the content field of their user profile page to execute arbitrary scripts with programming rights, thus effectively performing rights escalation. The problem is present [since version 4.3M2](https://jira.xwiki.org/browse/XWIKI-7369) when AppWithinMinutes Application added support for the Content field, allowing any wiki page (including the user profile page) to use its content as an AWM Content field, which has a custom displayer that executes the content with the rights of the ``AppWithinMinutes.Content`` author, rather than the rights of the content author. ### Patches The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262 . The fix is in the content of the [AppWithinMinutes.Content](https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262#diff-850f6875c40cf7932f40a985e99679a041891c6ee75d10239c06921c0019cf78R82) page that ...

### Impact Any registered user can exploit a stored XSS through their user profile by setting the payload as the value of the time zone user preference. Even though the time zone is selected from a drop down (no free text value) it can still be set from JavaScript (using the browser developer tools) or by calling the save URL on the user profile with the right query string. Once the time zone is set it is displayed without escaping which means the payload gets executed for any user that visits the malicious user profile, allowing the attacker to steal information and even gain more access rights (escalation to programming rights). The problem is present [since version 4.1M2](https://jira.xwiki.org/browse/XWIKI-7847) when the time zone user preference was introduced. ### Patches The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/d11ca5d781f8a42a85bc98eb82306c1431e764d4 . The main fix is in the [``displayer_timezone.vm``](https://g...

### Summary Bypassing the validatePath function can lead to potential Remote Code Execution (Post-authentication, ALLOW_ADMIN_CHANGES=true) ### Details In bootstrap.php, the SystemPaths path is set as below. ```php // Set the vendor path. By default assume that it's 4 levels up from here $vendorPath = $findConfigPath('--vendorPath', 'CRAFT_VENDOR_PATH') ?? dirname(__DIR__, 3); // Set the "project root" path that contains config/, storage/, etc. By default assume that it's up a level from vendor/. $rootPath = $findConfigPath('--basePath', 'CRAFT_BASE_PATH') ?? dirname($vendorPath); // By default the remaining directories will be in the base directory $dotenvPath = $findConfigPath('--dotenvPath', 'CRAFT_DOTENV_PATH') ?? "$rootPath/.env"; $configPath = $findConfigPath('--configPath', 'CRAFT_CONFIG_PATH') ?? "$rootPath/config"; $contentMigrationsPath = $findConfigPath('--contentMigrationsPath', 'CRAFT_CONTENT_MIGRATIONS_PATH') ?? "$rootPath/migrations"; $storagePath = $findConfigPath('...