#xss

Reflected cross-site scripting (XSS) vulnerability in the Language Override edit screen in Liferay Portal 7.4.3.8 through 7.4.3.97, and Liferay DXP 2023.Q3 before patch 5, and 7.4 update 4 through 92 allows remote attackers to inject arbitrary web script or HTML via the `_com_liferay_portal_language_override_web_internal_portlet_PLOPortlet_key` parameter.

Reflected cross-site scripting (XSS) vulnerability on the add assignees to a role page in Liferay Portal 7.3.3 through 7.4.3.97, and Liferay DXP 2023.Q3 before patch 6, 7.4 GA through update 92, and 7.3 before update 34 allows remote attackers to inject arbitrary web script or HTML via the `_com_liferay_roles_admin_web_portlet_RolesAdminPortlet_tabs2` parameter.

Reflected cross-site scripting (XSS) vulnerability in the instance settings for Accounts in Liferay Portal 7.4.3.44 through 7.4.3.97, and Liferay DXP 2023.Q3 before patch 6, and 7.4 update 44 through 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into the “Blocked Email Domains” text field

Cross-site scripting (XSS) vulnerability in HtmlUtil.escapeJsLink in Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions allows remote attackers to inject arbitrary web script or HTML via crafted javascript: style links.

Stored cross-site scripting (XSS) vulnerability in Message Board widget in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via the filename of an attachment.

Stored cross-site scripting (XSS) vulnerability in Expando module's geolocation custom fields in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into the name text field of a geolocation custom field.

### Impact A maliciously crafted xAPI statement could be used to perform script or other tag injection in the LRS Statement Browser. ### Patches The problem is patched in version 1.2.17 of the LRS library and [version 0.7.5 of SQL LRS](https://github.com/yetanalytics/lrsql/releases/tag/v0.7.5). ### Workarounds No workarounds exist, we recommend upgrading to version 1.2.17 of the library or version 0.7.5 of SQL LRS immediately. ### References * [LRS Tag](https://github.com/yetanalytics/lrs/releases/tag/v1.2.17) * [LRS lib on Clojars](https://clojars.org/com.yetanalytics/lrs/versions/1.2.17) * [SQL LRS 0.7.5 Release](https://github.com/yetanalytics/lrsql/releases/tag/v0.7.5)

We have identified a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint of MeshCentral. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. To demonstrate the impact of the vulnerability we developed a proof-of-concept which leveraged the cross-site websocket hijacking vulnerability to read the server configuration file to leak the sessionKey variable, generating login tokens, and generating an authentication cookie. The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to “control.ashx” as the victim user within MeshCentral. There are some caveats to exploiting this issue however as MeshCentral configures `SameSite=Lax` security setting on cookies which introduces some add...

### Impact The dynamic file upload feature is subject to potential XSS attach in case the attacker manages to modify the file names of the records being uploaded to the server. This appears in sections where the user controls the file upload dialogs themselves and has the technical knowledge to change the file names through the dynamic upload endpoint. Therefore I believe it would require the attacker to control the whole session of the particular user but in any case, this needs to be fixed. Successful exploit of this vulneratibility would require the user to have successfully uploaded a file blob to the server with a malicious file name and then have the possibility to direct the other user to the edit page of the record where the attachment is attached. The users are able to craft the direct upload requests themselves controlling the file name that gets stored to the database as shown here: https://github.com/rails/rails/blob/a967d355c6fee9ad9b8bd115d43bc8b0fc207e7e/activestorage...

U.S. and U.K. authorities have seized the darknet websites run by LockBit, a prolific and destructive ransomware group that has claimed more than 2,000 victims worldwide and extorted over $120 million in payments. Instead of listing data stolen from ransomware victims who didn't pay, LockBit's victim shaming website now offers free recovery tools, as well as news about arrests and criminal charges involving LockBit affiliates.