#vulnerability

Cross-Site Scripting vulnerability in Algernon v1.17.4 allows attackers to execute arbitrary code via injecting a crafted payload into a filename.

Jenkins Coverage Plugin 2.3054.ve1ff7b_a_a_123b_ and earlier does not validate the configured coverage results ID when creating coverage results, only when submitting the job configuration through the UI, allowing attackers with Item/Configure permission to use a `javascript:` scheme URL as identifier by configuring the job through the REST API, resulting in a stored cross-site scripting (XSS) vulnerability.

Jenkins Redpen - Pipeline Reporter for Jira Plugin 1.054.v7b_9517b_6b_202 and earlier does not correctly perform path validation of the workspace directory while uploading artifacts to Jira, allowing attackers with Item/Configure permission to retrieve files present on the Jenkins controller workspace directory.

Jenkins Git client Plugin 6.4.0 and earlier does not not correctly escape the path to the workspace directory as part of an argument in a temporary shell script generated by the plugin, allowing attackers able to control the workspace directory name to inject arbitrary OS commands.

Jenkins 2.540 and earlier, LTS 2.528.2 and earlier does not properly close HTTP-based CLI connections when the connection stream becomes corrupted, allowing unauthenticated attackers to cause a denial of service.

A cross-site request forgery (CSRF) vulnerability in Jenkins 2.540 and earlier, LTS 2.528.2 and earlier allows attackers to trick users into logging in to the attacker's account.

1Panel versions 1.10.33 - 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the Change Username functionality available from the settings panel (/settings/panel). The endpoint does not implement CSRF protections such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a username-change request; when a victim visits the page while authenticated, the browser includes valid session cookies and the request succeeds. This allows an attacker to change the victim’s 1Panel username without consent. After the change, the victim is logged out and unable to log in with the previous username, resulting in account lockout and denial of service.

### Impact The vulnerability is in the password change dialog in the back office. During the transition from v4 to v5 a mistake was made in the validation code which caused the validation of the previous password to not run as expected. This made it possible for a logged in user to change password in the back office without knowing the previous password. For example if someone logs in, leaves their workstation unlocked, and another person uses the same machine. ### Credit The issue was reported to us by Code-Rhapsodie. We thank them for their responsible disclosure! https://www.code-rhapsodie.fr/ ### Patches - See "Patched versions". - https://github.com/ibexa/user/commit/9d485bf385e6401c9f7ee80287d8ccd00f73dcf4 ### Workarounds None.

### Summary Zitadel's User Service discloses the total number of instance users to unauthorized users. ### Impact The ZITADEL User Service exposes the total number of users within an instance to any authenticated user, regardless of their specific permissions. While this does not leak individual user data or PII, disclosing the total user count via the `totalResult` field constitutes an information disclosure vulnerability that may be sensitive in certain contexts. ### Affected Versions Systems running one of the following version are affected: - **4.x**: `4.0.0-rc.1` through `4.7.1` - **3.x**: `3.0.0-rc.1` through `3.4.4` - **2.x**: `2.44.0` through `2.71.19` ### Patches The vulnerability has been addressed in the latest release. The patch resolves the issue and returns the `totalResult` value corresponding to the number of instance users for whom the querying user has read permission. - 4.x: Upgrade to >=[4.7.2](https://github.com/zitadel/zitadel/releases/tag/v4.7.2) - 3.x: ...

### Summary `redirect_url` is treated as safe when `url.Parse(...).IsAbs()` is false. Protocol-relative URLs like `//ikotaslabs.com` have an empty scheme and pass that check, allowing post-login redirects to attacker-controlled sites. ### Details - `url.Parse("//ikotaslabs.com")` => empty Scheme, Host="ikotaslabs.com". - `IsAbs()` returns false for `//ikotaslabs.com`, so the code treats it as allowed. - Browser resolves `//ikotaslabs.com` to current-origin scheme (e.g. `https://ikotaslabs.com`), enabling phishing flows after login. ### PoC 1. Send or visit: `http://localhost/login?redirect_url=//ikotaslabs.com` 2. Complete normal login flow. 3. After login the app redirects to `https://ikotaslabs.com` (or `http://` depending on origin). ### Acknowledgements This vulnerability was discovered using the automated vulnerability analysis tools **VulScribe** and **PwnML**. The research and tool development were conducted with support from the **MITOU Advanced Program (未踏アドバンスト事業)*...