R3Dpower

Name of the Vulnerable Software and Affected Versions Directus versions prior to 11.17.0 Description The Directus file management API contains a broken access control issue that allows authenticated users to overwrite files belonging to other users by manipulating the `filename disk` parameter in the `PATCH /files/{id}` endpoint. By setting this value to match the storage path of another user's file, an attacker can overwrite the file's content and manipulate metadata fields like `uploaded by` to hide the tampering. This can lead to unauthorized file overwrites, potential remote code execution if the storage backend is shared with the extensions location, and data integrity compromise. Recommendations Update to version 11.17.0 or later.

Name of the Vulnerable Software and Affected Versions: Directus versions prior to 10.13.4 Directus versions prior to 11.2.0 Description: The Comment feature in Directus has a filter to prevent users from adding restricted characters, such as HTML tags. However, this filter operates on the client-side, which can be bypassed, making the application vulnerable to HTML Injection. This issue can be exploited by directly sending a request to the endpoint, such as `PATCH /activity/comment/3 HTTP/2`, with a payload containing restricted characters, for example, `"comment": "<h1>TEST <p style="color:red">HTML INJECTION</p> <a href="//evil.com">Test Link</a></h1>"`. The introduction of session cookies makes this issue exploitable, allowing a malicious script to perform authenticated actions on the current user's behalf. Recommendations: For versions prior to 10.13.4, update to version 10.13.4 or later. For versions prior to 11.2.0, update to version 11.2.0 or later. As a temporary workaround, consider disabling the Comment feature until a patch is available. Restrict access to the `/activity/comment` endpoint to minimize the risk of exploitation. Avoid using the `comment` parameter in the affected API endpoint until the issue is resolved.

The issue allows a user to bypass the block on localhost access by using other registered loopback devices, such as `127.0.0.2` through `127.127.127.127`. This can be exploited to achieve full SSRF. The problem arises when relying on the default `0.0.0.0` filter to block access to localhost.