#java

Improper sanitisation in `main/inc/lib/fileUpload.lib.php` in Chamilo LMS <= v1.11.20 on Windows and Apache installations allows unauthenticated attackers to bypass file upload security protections and obtain remote code execution via uploading of `.htaccess` file. This vulnerability may be exploited by privileged attackers or chained with unauthenticated arbitrary file write vulnerabilities, such as CVE-2023-3533, to achieve remote code execution.

Path traversal in file upload functionality in `/main/webservices/additional_webservices.php` in Chamilo LMS <= v1.11.20 allows unauthenticated attackers to perform stored cross-site scripting attacks and obtain remote code execution via arbitrary file write.

Command injection in `/main/webservices/additional_webservices.php` in Chamilo LMS <= v1.11.20 allows unauthenticated attackers to obtain remote code execution via improper neutralisation of special characters. This is a bypass of CVE-2023-34960.

An issue in jflyfox jfinalCMS v.5.1.0 allows a remote attacker to execute arbitrary code via a crafted script to the login.jsp component in the template management module.

Apache NiFi 0.7.0 through 1.23.2 include the JoltTransformJSON Processor, which provides an advanced configuration user interface that is vulnerable to DOM-based cross-site scripting. If an authenticated user, who is authorized to configure a JoltTransformJSON Processor, visits a crafted URL, then arbitrary JavaScript code can be executed within the session context of the authenticated user. Upgrading to Apache NiFi 1.24.0 or 2.0.0-M1 is the recommended mitigation.

A vulnerability has been identified in Pachno 1.0.6 allowing an authenticated attacker to execute a cross-site scripting (XSS) attack. The vulnerability exists due to inadequate input validation in the Project Description and comments, which enables an attacker to inject malicious java script.

### Summary A Server-Side Request Forgery (SSRF) Vulnerability is present in applications utilizing the `google-translate-api-browser` package and exposing the `translateOptions` to the end user. An attacker can set a malicious `tld`, causing the application to return unsafe URLs pointing towards local resources. ### Details The `translateOptions.tld` field is not properly sanitized before being placed in the Google translate URL. This can allow an attacker with control over the `translateOptions` to set the `tld` to a payload such as `@127.0.0.1`. This causes the full URL to become `https://[email protected]/...`, where `translate.google.` is the username used to connect to localhost. ### PoC Imagine a server running the following code (closely mimicking the code present in the package's README): ```javascript const express = require('express'); const { generateRequestUrl, normaliseResponse } = require('google-translate-api-browser'); const https = require('https'); const...

Apache NiFi 0.7.0 through 1.23.2 include the JoltTransformJSON Processor, which provides an advanced configuration user interface that is vulnerable to DOM-based cross-site scripting. If an authenticated user, who is authorized to configure a JoltTransformJSON Processor, visits a crafted URL, then arbitrary JavaScript code can be executed within the session context of the authenticated user. Upgrading to Apache NiFi 1.24.0 or 2.0.0-M1 is the recommended mitigation.

An issue in OwnCast v.0.1.1 allows a remote attacker to execute arbitrary code and obtain sensitive information via the authHost parameter of the indieauth function.

### Impact The `Validator.isValidSafeHTML` method can result in false negatives where it reports some input as safe (i.e., returns true), but really isn't, and using that same input as-is can in certain circumstances result in XSS vulnerabilities. Because this method cannot be fixed, it is being deprecated and will be removed in one years time from when this advisory is published. Full details may be found in [ESAPI Security Bulletin #12](https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/ESAPI-security-bulletin12.pdf). Note that all versions of ESAPI, that have this method (which dates back to at least the ESAPI 1.3 release more than 15 years ago) have this issue and it will continue to exist until we remove these two methods in a future ESAPI release. ### Patches There is no patch. We do not believe that it is possible to patch this pretentiously named method other then perhaps renaming it to something like Validator.mightThisBeValidSafeHTML to dissuade developer...