#java

The Trix editor, in versions prior to 2.1.9 and 1.3.3, is vulnerable to XSS + mutation XSS attacks when pasting malicious code. ### Impact An attacker could trick a user to copy and paste malicious code that would execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed. ### Patches Update Recommendation: Users should upgrade to Trix editor version 2.1.9 or later, which uses [DOMPurify](https://github.com/cure53/DOMPurify) to sanitize the pasted content. If using Trix 1.x, upgrade to version 1.3.3 or later. ### Mitigations This is not really a workaround but something that should be considered in addition to upgrading to the patched version. If affected users can disallow browsers that don't support a Content Security Policy, then this would be an effective workaround for this and all XSS vulnerabilities. Set CSP policies such as script-src 'self' to ensure th...

Researchers demonstrate a proof-of-concept cyberattack vector that gets around remote, on-premises, and local versions of browser isolation security technology to send malicious communications from an attacker-controlled server.

We can anticipate a growing number of emerging vulnerabilities in the near future, emphasizing the need for an effective prioritization strategy.

The "Census of Free and Open Source Software" report, which identifies the most critical software projects, sees more cloud infrastructure and Python software designated as critical software components.

### Summary sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients...

Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core This function when called triggers a manual panic in the thread containing the runtime. It can be fixed by stubbing out the exposed op: ```javascript Deno.core.ops.op_panic = (msg) => { throw new Error(msg) }; ```

Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core This function when called triggers a manual panic in the thread containing the runtime, breaking sandboxing It can be fixed by stubbing out the exposed op: ```javascript Deno.core.ops.op_panic = (msg) => { throw new Error(msg) }; ```

Earlier today, a publish-access account was compromised for `@solana/web3.js`, a JavaScript library that is commonly used by Solana dapps. This allowed an attacker to publish unauthorized and malicious packages that were modified, allowing them to steal private key material and drain funds from dapps, like bots, that handle private keys directly. This issue should not affect non-custodial wallets, as they generally do not expose private keys during transactions. This is not an issue with the Solana protocol itself, but with a specific JavaScript client library and only appears to affect projects that directly handle private keys and that updated within the window of 3:20pm UTC and 8:25pm UTC on Tuesday, December 3, 2024. These two unauthorized versions (1.95.6 and 1.95.7) were caught within hours and have since been unpublished. We are asking all Solana app developers to upgrade to version 1.95.8. Developers pinned to `latest` should also upgrade to 1.95.8. Developers that suspect t...

### Summary The application allows users to upload files with scripts in the filename parameter. As a result, a malicious user can upload a script file to the system. When users in the application use the "Diff or Compare" functionality, they are affected by a Stored Cross-Site Scripting vulnerability. ### Details I found a Stored Cross-Site Scripting vulnerability in the "Diff or Compare" functionality. This issue occurs because the upload functionality allows users to upload files with special characters such as <, >, /, and " in the filename. This vulnerability can be mitigated by restricting file uploads to filenames containing only whitelisted characters, such as A-Z, 0-9, and specific special characters permitted by business requirements, like - or _ . ### PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._ 1. On MobSF version 4.2.8, I clicked on "Unload & Analyze" button. ![0](https://github.com/user-attachments/assets/489013...

A novel backdoor malware and a loader that customizes payload names for each victim have been added to the threat group's cybercriminal tool set.