Latest News

The Weave server API allows remote users to fetch files from a specific directory, but due to a lack of input validation, it is possible to traverse and leak arbitrary files remotely. In various common scenarios, this allows a low-privileged user to assume the role of the server admin.

### Impact It is possible for an attacker to craft malicious Urls that certain functions in IdentityServer will incorrectly treat as local and trusted. If such a Url is returned as a redirect, some browsers will follow it to a third-party, untrusted site. _Note: by itself, this vulnerability does **not** allow an attacker to obtain user credentials, authorization codes, access tokens, refresh tokens, or identity tokens. An attacker could however exploit this vulnerability as part of a phishing attack designed to steal user credentials._ ### Affected Methods - In the `DefaultIdentityServerInteractionService`, the `GetAuthorizationContextAsync` method may return non-null and the `IsValidReturnUrl` method may return true for malicious Urls, indicating incorrectly that they can be safely redirected to. _UI code calling these two methods is the most commonly used code path that will expose the vulnerability. The default UI templates rely on this behavior in the Login, Challenge, Conse...

### Impact The file upload widget is vulnerable to XSS payloads in filenames. Access permission to upload files is required. As such, in most cases only authenticated editors and administrators will have the required permission. It is not persistent, i.e. the payload is only executed during the upload. In effect, an attacker will have to trick an editor/administrator into uploading a strangely named file. The fix ensures XSS is escaped. ### Patches See "Patched versions". Commit: https://github.com/ibexa/admin-ui/commit/8dc413fad1045fcfbe65dbcb0bea8516accc4c3e ### Workarounds None. ### References - https://developers.ibexa.co/security-advisories/ibexa-sa-2024-004-dom-based-xss-in-file-upload - https://github.com/ibexa/admin-ui/commit/8dc413fad1045fcfbe65dbcb0bea8516accc4c3e - https://github.com/ezsystems/ezplatform-admin-ui/security/advisories/GHSA-gc5h-6jx9-q2qh ### Credit This vulnerability was discovered and reported to Ibexa by Alec Romano: https://github.com/4rdr We thank them...

### Impact Any user with edit right on any page can perform arbitrary remote code execution by adding instances of `XWiki.SearchSuggestConfig` and `XWiki.SearchSuggestSourceClass` to their user profile or any other page. This compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on an instance, as a user without script nor programming rights, add an object of type `XWiki.SearchSuggestConfig` to your profile page, and an object of type `XWiki.SearchSuggestSourceClass` as well. On this last object, set both `name` and `icon` properties to `$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')")` and `limit` and `engine` to `{{/html}}{{async}}{{velocity}}$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')"){{/velocity}}{{/async}}`. Save and display the page. If the logs contain any message `ERROR ...

### Impact When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment. In order to reproduce, as any user, create a file named `"><img src=1 onerror=alert(1)>.jpg`. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display "1", then the instance is vulnerable. ### Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. ### Workarounds We're not aware of any workaround except upgrading. ### References * https://jira.xwiki.org/browse/XWIKI-19611 * https://jira.xwiki.org/browse/XWIKI-21769 * h...

### Impact When a user has edit but not view right on a page in XWiki, that user can delete the page and replace it by a page with new content without having delete right. The previous version of the page is moved into the recycle bin and can be restored from there by an admin. As the user is recorded as deleter, the user would in theory also be able to view the deleted content, but this is not directly possible as rights of the previous version are transferred to the new page and thus the user still doesn't have view right on the page. From all we examined, it therefore doesn't seem to be possible to exploit this to gain any rights. To reproduce, just replace `view` by `edit` in the URL of a page that you cannot view but edit and save. This should send the page to the recycle bin and replace it by an empty one if the XWiki installation is vulnerable. After the fix, an error is displayed when saving. ### Patches This has been patched in XWiki 14.10.21, 15.5.5 and 15.10.6 by cancelli...

OpenMediaVault allows an authenticated user to create cron jobs as root on the system. An attacker can abuse this by sending a POST request via rpc.php to schedule and execute a cron entry that runs arbitrary commands as root on the system. All OpenMediaVault versions including the latest release 7.4.2-2 are vulnerable.

Readymade Real Estate Script suffers from remote blind SQL injection and cross site scripting vulnerabilities.

Ubuntu Security Notice 6934-1 - Multiple security issues were discovered in MySQL and this update includes new upstream MySQL versions to fix these issues. MySQL has been updated to 8.0.39 in Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. In addition to security fixes, the updated packages contain bug fixes, new features, and possibly incompatible changes.

Ubuntu Security Notice 6932-1 - It was discovered that the Hotspot component of OpenJDK 21 was not properly performing bounds when handling certain UTF-8 strings, which could lead to a buffer overflow. An attacker could possibly use this issue to cause a denial of service or execute arbitrary code. It was discovered that the Hotspot component of OpenJDK 21 could be made to run into an infinite loop. If an automated system were tricked into processing excessively large symbols, an attacker could possibly use this issue to cause a denial of service.