Threats Tagged 'packagist'

MantisBT versions 2.28.3 and earlier contain a SQL injection vulnerability in core/history_api.php. The vulnerability arises because the history_order configuration value is used directly in a SQL ORDER BY clause without sanitization or validation. An administrator can set this value via the web UI or REST API, enabling injection that triggers when any user views a bug with history entries. This can lead to sensitive data exposure and, with certain MySQL privileges, remote code execution.

MantisBT versions 2.28.3 and earlier contain a critical authentication bypass vulnerability in the SOAP API's mci_check_login() function. This flaw allows any user who knows any valid cookie_string and a target username to authenticate as that user, including administrators, without knowing their password. The vulnerability is exploitable with zero prior access on default installations because self-registration is enabled by default. The REST API and Web UI are not affected. Exploitation grants full administrator access to the SOAP API, enabling read/write access to all issues, data exfiltration, and destructive operations across projects.

MantisBT versions 1.3.0 up to 2.28.3 contain a remote code execution vulnerability in the admin Manage Configuration feature (adm_config_set.php). The vulnerability arises because the configuration value is evaluated via PHP's eval() with a return prefix, but PHP hoists class declarations even past return statements. An attacker with administrator access to the web UI can define a class that hijacks autoloaded classes, leading to arbitrary code execution as the web server user. The REST API is not affected. A patch fixing this issue is available in version 2.28.4.

MantisBT versions from 2.8.0 up to but not including 2.28.4 contain a vulnerability where a user with the update bug threshold permission (UPDATER by default) can change an issue's status via the REST and SOAP APIs, even if the configuration requires a higher permission level (DEVELOPER by default) to set status. This leads to unauthorized changes in the issue workflow.

Koel version prior to 9.7.0 contains an authenticated blind Server-Side Request Forgery (SSRF) vulnerability in its Subsonic-compatible podcast channel creation route. Unlike the main podcast subscription API, which uses SafeUrl validation to block private/internal URLs, the Subsonic route lacks this protection, allowing authenticated users to supply private URLs that Koel fetches server-side during podcast parsing. This enables SSRF to internal network destinations accessible from the Koel server. The vulnerability was confirmed in version 9.6.0 and allows internal HTTP requests to loopback, Docker bridge, and RFC1918 addresses. No public exploit is known, and the impact is limited to SSRF-based internal request execution without confirmed data exfiltration.

Koel version 9.6.0 contains an authenticated Server-Side Request Forgery (SSRF) vulnerability via its Subsonic-compatible internet radio station endpoints. Unlike the regular web API, these endpoints do not validate radio station URLs, allowing an authenticated user to create or update a radio station with a private/internal URL. When the station is streamed, Koel fetches the URL server-side and returns the full HTTP response body to the user, enabling full-read SSRF. This vulnerability affects versions prior to 9.7.0.

Koel before version 9.7.0 contains a Server-Side Request Forgery (SSRF) vulnerability in its Subsonic API podcast feed URL handling. Authenticated users can supply internal or loopback URLs as podcast feed sources, causing the Koel backend to make unauthorized requests to internal network services. Additionally, redirect handling in podcast streaming does not re-validate final URLs after redirects, allowing SSRF via redirect chains. This can expose internal HTTP endpoints to blind SSRF attacks. The vulnerability arises from insufficient validation of feed URLs before server-side fetching and incomplete redirect validation.

Koel versions prior to 9.7.1 contain an incomplete fix for CVE-2026-47260, resulting in systemic server-side request forgery (SSRF) vulnerabilities in podcast and radio fetch paths. The initial URL safety check is bypassed by HTTP 302 redirects to internal addresses on most fetch paths, except one. Additionally, DNS rebinding attacks can bypass host validation due to separate DNS resolution at validation and connection time. Authenticated non-admin users can exploit this to make the Koel server issue requests to internal or cloud metadata endpoints, potentially exposing sensitive internal resources such as cloud instance metadata and IAM credentials.

Koel version 9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation API endpoint due to missing validation bail in URL validation rules. This allows any authenticated user to coerce the server into making HTTP HEAD/GET requests to arbitrary internal hosts. The vulnerability is blind SSRF, meaning the response body is not returned, but distinct validation error messages enable internal network reachability detection. The flaw arises because the SafeUrl validation rule rejects private/reserved addresses but does not stop further validation, allowing the HasAudioContentType rule to issue requests to these URLs without additional checks. This can lead to internal host discovery and potential side effects from internal endpoints.

Koel versions prior to 9.7.1 contain a server-side request forgery (SSRF) vulnerability due to improper IP address validation in the isPublicHost() function. The function fails to recognize IPv6 transition addresses (NAT64 and 6to4) that embed private IPv4 addresses, allowing attackers to bypass the public IP check. An attacker can craft a podcast RSS feed with an enclosure URL resolving to such an IPv6 address, causing Koel to fetch internal network resources or cloud metadata endpoints and return the response to the attacker. This leads to full-read SSRF with disclosure of internal service data.