Latest News

A missing permission check in Jenkins 2.540 and earlier, LTS 2.528.2 and earlier allows attackers with View/Read permission to view encrypted password values in views.

An issue in sd command v1.0.0 and before allows attackers to escalate privileges to root via a crafted command.

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 (未踏アドバンスト事業)*...

The update patches three zero-days and introduces a new PowerShell warning meant to help you avoid accidentally running unsafe code from the web.

### Summary The TIM (PSX TIM) image parser in ImageMagick contains a critical integer overflow vulnerability in the `ReadTIMImage` function (`coders/tim.c`). The code reads `width` and `height` (16-bit values) from the file header and calculates `image_size = 2 * width * height` without checking for overflow. On 32-bit systems (or where `size_t` is 32-bit), this calculation can overflow if `width` and `height` are large (e.g., 65535), wrapping around to a small value. This results in a small heap allocation via `AcquireQuantumMemory` and later operations relying on the dimensions can trigger an out of bounds read. ### Vulnerable Code File: `coders/tim.c` ```c width=ReadBlobLSBShort(image); height=ReadBlobLSBShort(image); image_size=2*width*height; // Line 234 - NO OVERFLOW CHECK! ``` ### Impact This vulnerability can lead to Arbitrary Memory Disclosure due to an out of bounds read on 32-bit systems.

### Impact Any user who can edit their own user profile or any other document can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The reason is that rendering output is included as content of HTML macros with insufficient escaping, and it is thus possible to close the HTML macro and inject script macros that are executed with programming rights. To demonstrate, the content `{{html}}{{/html {{/html}}}}` can be inserted into any field of the user profile that supports wiki syntax like the "About" field. If this leads to the display of raw HTML, the instance is vulnerable. ### Patches This problem has been patched by extending the escaping introduced by [XRENDERING-693](https://jira.xwiki.org/browse/XRENDERING-693) to also cover closing HTML macros that have spaces after the macro name in XWiki 16.10.10, 17.4.3 and 17.6.0RC1. A [similar fix](https://github.com/xwiki/xwik...

### Impact XWiki's REST API doesn't enforce any limits for the number of items that can be requested in a single request at the moment. Depending on the number of pages in the wiki and the memory configuration, this can lead to slowness and unavailability of the wiki. As an example, the `/rest/wikis/xwiki/spaces` resource returns all spaces on the wiki by default, which are basically all pages. ### Patches XWiki 17.7.0RC1, 17.4.4 and 16.10.11 introduce a configurable limit, limiting responses to 1000 items by default. Requesting larger limits leads to an error now. ### Workarounds We're not aware of any workaround, except denying access to the affected REST resources in a proxy in front of XWiki.