ghsa

### Summary An attacker can forge a request to redirect an authenticated user to any arbitrary website. ### Details On the login page, we have a `redirect` field which is the location where the server will redirect the user. This URI is not verified, and can be an arbitrary URI. Paired with a parameter pollution, we can hide our malicious URI (ex: `https://dns.com/?param1=im_hidden_if_theres_lot_of_args?param1=bbb`). ### PoC https://diracx-cert.app.cern.ch/auth?redirect=https://ipcim.com/en/where/?dsdsd=qsqsfsjfnsfniizaeiaapzqlalkqkaizqqijsjaopmqmxna?redirect=https://diracx-cert-app.cern.ch/auth This POC can leak user's position. ### Impact This could be used for phishing and extracting new data (such as redirecting to a new "log in" page, and asking users to reenter credentials).

Grafana is an open-source platform for monitoring and observability. The Grafana Alerting DingDing integration was not properly protected and could be exposed to users with Viewer permission. Fixed in versions 10.4.19+security-01, 11.2.10+security-01, 11.3.7+security-01, 11.4.5+security-01, 11.5.5+security-01, 11.6.2+security-01 and 12.0.1+security-01

### Summary The escapeParameterHtml: true option in Vue I18n is designed to protect against HTML/script injection by escaping interpolated parameters. However, this setting fails to prevent execution of certain tag-based payloads, such as <img src=x onerror=...>, if the interpolated value is inserted inside an HTML context using v-html. This may lead to a DOM-based XSS vulnerability, even when using escapeParameterHtml: true, if a translation string includes minor HTML and is rendered via v-html. ### Details When escapeParameterHtml: true is enabled, it correctly escapes common injection points. However, it does not sanitize entire attribute contexts, which can be used as XSS vectors via: `<img src=x onerror=alert(1)> ` ### PoC In your Vue I18n configuration: ``` const i18n = createI18n({ escapeParameterHtml: true, messages: { en: { vulnerable: 'Caution: <img src=x onerror="{payload}">' } } }); ``` Use this interpolated payload: `const payload = '<script>aler...

### Summary A Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint `Filebrowser-Server-IP:PORT/files/{file-name}` . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making it unresponsive. ### Details The endpoint ` /api/resources/{file-name}` accepts `PUT` requests with plain text file content. Uploading an extremely large file (e.g., ~1.5 GB) succeeds without issue. However, when the server attempts to open and read this file, it performs the read operation in an unbounded or inefficient way, leading to excessive memory usage. This approach attempts to read the entire file into memory at once. For large files, this causes memory exhaustion resulting in a cras...

The crate [`slice-ring-buffer`](https://crates.io/crates/slice-ring-buffer) was developed as a fork of [`slice-deque`](https://crates.io/crates/slice-deque) to continue maintenance and provide security patches, since the latter has been officially unmaintained ([RUSTSEC-2020-0158](https://rustsec.org/advisories/RUSTSEC-2020-0158.html)). While `slice-ring-buffer` has addressed some previously reported memory safety issues inherited from its fork origin ([RUSTSEC-2021-0047](https://rustsec.org/advisories/RUSTSEC-2021-0047.html)), it still retains multiple unresolved memory corruption vulnerabilities. Specifically, we have discovered four new memory safety bugs, each resulting in double-free violations that can occur when only safe APIs are invoked. These vulnerabilities correspond to four distinct safe APIs in the crate, each exposing unsound and vulnerable behavior due to incorrect usage of unsafe code internally. Unfortunately, the maintainer doesn't have much availability to resolv...

### Summary File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE's listed in this report for further reference and system standards. In summary, the main issue is: - Tokens remain valid after logout (session replay attacks) In this report, I used docker as the documentation instruct: ``` docker run \ -v filebrowser_data:/srv \ -v filebrowser_database:/database \ -v filebrowser_config:/config \ -p 8080:80 \ filebrowser/filebrowser ``` ### Details **Issue: Tokens remain valid after logout (session replay attacks)** After logging in and receiving a JWT token, the user can explicitly "log out." However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request: ``` POST /api/login HTTP/1.1 Host: machine.local:8090 Cont...

In Eclipse GlassFish version 6.2.5, it is possible to perform a Server Side Request Forgery attack using specific endpoints.

In Eclipse GlassFish version 7.0.15 is possible to perform Stored Cross-site Scripting attacks by modifying the configuration file in the underlying operating system.

In Eclipse GlassFish version 7.0.15, it is possible to perform Reflected Cross-Site Scripting attacks through the Administration Console.

In Eclipse GlassFish version 7.0.15, it is possible to perform Stored Cross-Site Scripting attacks through the Administration Console.