Source
ghsa
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) }; ```
When given a valid UTF8 string "ö\x1b😀", the function in crates/anstream/src/adapter/strip.rs will be confused. The UTF8 bytes are \xc3\xb6 then \x1b then \xf0\x9f\x98\x80. When looping over "non-printable bytes" \x1b\xf0 will be considered as some non-printable sequence. This will produce a broken str from the incorrectly segmented bytes via str::from_utf8_unchecked, and that should never happen. Full credit goes to @Ralith who reviewed this code and asked @burakemir to follow up.
The borsh serialization of the HashMap did not follow the borsh specification. It potentially produced non-canonical encodings dependent on insertion order. It also did not perform canonicty checks on decoding. This can result in consensus splits and cause equivalent objects to be considered distinct. This was patched in 0.15.1.
Affected versions allow populating a DistributedSlice of T with elements of an arbitrary other type that coerces to T. For example, elements of type `&&str` could end up in a slice of type `[&str]`, since `&&str` coerces to `&str` via a deref coercion. The flaw was corrected by implementing typechecking for distributed slice elements in such a way that coercion no longer occurs. The element's type must be a subtype of the slice's declared element type.
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 A security vulnerability has been identified in GitHub CLI that could create or overwrite files in unintended directories when users download a malicious GitHub Actions workflow artifact through `gh run download`. ### Details This vulnerability stems from a GitHub Actions workflow artifact named `..` when downloaded using `gh run download`. The artifact name and `--dir` flag are used to determine the artifact’s download path. When the artifact is named `..`, the resulting files within the artifact are extracted exactly 1 directory higher than the specified `--dir` flag value. In `2.63.1`, `gh run download` will not download artifacts named `..` and `.` and instead exit with the following error message: ``` error downloading ..: would result in path traversal ``` ### Impact Successful exploitation heightens the risk of local path traversal attack vectors exactly 1 directory higher than intended. ### Remediation and Mitigation 1. Upgrade `gh` to `2.63.1` 2. Implem...
An implementation bug in the Kolide Agent (known as `launcher`) allows for local privilege escalation to the SYSTEM user on Windows 10 and 11. Impacted versions include versions >= 1.5.3 and the fix has been released in 1.12.3. The bug was introduced in version 1.5.3 when launcher started storing upgraded binaries in the ProgramData directory (#1510). This move to the new directory meant the launcher root directory inherited default permissions that are not as strict as the previous location. These incorrect default permissions in conjunction with an omitted SystemDrive environmental variable (when launcher starts osqueryd), allows a malicious actor with access to the local Windows device to successfully place an arbitrary DLL into the osqueryd process's search path. Under some circumstances, this DLL will be executed when osqueryd performs a WMI query. This combination of events could then allow the attacker to escalate their privileges to SYSTEM. This issue was found by Bryan Alex...
### 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. .