ghsa

### Impact This only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` [fuses](https://www.electronjs.org/docs/latest/tutorial/fuses) enabled. Apps without these fuses enabled are not impacted. Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the `resources` folder in your app installation on Windows which these fuses are supposed to protect against. ### Workarounds There are no app side workarounds, you must update to a patched version of Electron. ### Fixed Versions * `38.0.0-beta.6` * `37.3.1` * `36.8.1` * `35.7.5` ### For more information If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org)

When Claude Code was started in a new directory, it displayed a warning asking, "Do you trust the files in this folder?". This warning did not properly document that selecting "Yes, proceed" would allow Claude Code to execute files in the folder without additional confirmation. This may not have been clear to a user so we have updated the warning to clarify this functionality.  Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to https://hackerone.com/avivdon for reporting this issue!

### Impact A Cross-Site Scripting (XSS) vulnerability has been discovered in the CKEditor 5 clipboard package. This vulnerability could be triggered by a specific user action, leading to unauthorized JavaScript code execution, if the attacker managed to insert a malicious content into the editor, which might happen with a very specific editor configuration. This vulnerability affects **only** installations where the editor configuration meets one of the following criteria: - [HTML embed plugin](https://ckeditor.com/docs/ckeditor5/latest/features/html/html-embed.html) is enabled - Custom plugin introducing editable element which implements view [`RawElement`](https://ckeditor.com/docs/ckeditor5/latest/api/module_engine_view_rawelement-ViewRawElement.html) is enabled ### Patches The problem has been recognized and patched. The fix will be available in version 46.0.3 (and above), and explicitly in version 45.2.2. ### For more information Email us at [security@cksource.com](mailto:secur...

### Summary With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. ### Details `BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. Tested on 4.1.118, but there were no changes to the decoder since. ### PoC Run this test case with `-Xmx1G`: ```java import io.netty.buffer.Unpooled; import io.netty.channel.embedded.EmbeddedChannel; import java.util.Base64; public class T { public static void main(String[] args) { EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1...

### Impact It's possible to get access and read configuration files by using URLs such as `http://localhost:8080/bin/ssx/Main/WebHome?resource=../../WEB-INF/xwiki.cfg&minify=false`. This can apparently be reproduced on Tomcat instances. ### Patches This has been patched in 17.4.0-rc-1, 16.10.7. ### Workarounds There is no known workaround, other than upgrading XWiki. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org) ### Attribution The vulnerability was reported by Gregor Neumann.

### Impact It's possible to get access and read configuration files by using URLs such as `http://localhost:8080/xwiki/webjars/wiki%3Axwiki/..%2F..%2F..%2F..%2F..%2FWEB-INF%2Fxwiki.cfg`. The trick here is to encode the / which is decoded when parsing the URL segment, but not re-encoded when assembling the file path. ### Patches This has been patched in 17.4.0-rc-1, 16.10.7. ### Workarounds There is no known workaround, other than upgrading XWiki. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)

In Jenkins Git client Plugin 6.3.2 and earlier, Git URL field form validation responses differ based on whether the specified file path exists on the controller when specifying `amazon-s3` protocol for use with JGit, allowing attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system.

Jenkins global-build-stats Plugin 322.v22f4db_18e2dd and earlier does not perform permission checks in its REST API endpoints, allowing attackers with Overall/Read permission to enumerate graph IDs. This has been patched in version 347.v32a_eb_0493c4f.

A missing permission check in Jenkins OpenTelemetry Plugin 3.1543.v8446b_92b_cd64 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Incorrect Default Permissions vulnerability in Apache DolphinScheduler. This issue affects Apache DolphinScheduler: before 3.2.2. Users are recommended to upgrade to version 3.3.1, which fixes the issue.