Latest News

Improper access control in Visual Studio Code allows an authorized attacker to elevate privileges locally.

Google has shipped patches for 62 vulnerabilities, two of which it said have been exploited in the wild. The two high-severity vulnerabilities are listed below - CVE-2024-53150 (CVSS score: 7.8) - An out-of-bounds flaw in the USB sub-component of Kernel that could result in information disclosure CVE-2024-53197 (CVSS score: 7.8) - A privilege escalation flaw in the USB sub-component of Kernel

A new Neptune RAT variant is being shared via YouTube and Telegram, targeting Windows users to steal passwords and deliver additional malware components.

The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`. Thank you to Austin Bonander for finding and reporting this issue.

### Impact Incorrect `number` DER encoding can lead to denial on service for absolute values in the range `2**31` -- `2**32 - 1`. The arithmetic in the `numBitLen` didn't take into account that values in this range could result in a negative result upon applying the `>>` operator, leading to an infinite loop. In addition, `number` encoding had a few other issues that resulted it in it not encoding values correctly. ### Patches The issue is patched in version `1.0.4`. Users are recommended to upgrade as soon as possible. ### Workarounds If upgrading is not an option, the issue can be mitigated by validating inputs to `Asn1Integer` to ensure that they are not smaller than `-2**31 + 1` and no larger than `2**31 - 1`. Although `Asn1Integer` supports `bigint` inputs, some additional implementation issues make using `bigint` as a mitigation inviable, as it will result in incorrect values. If upgrading is not an option and range checks are impractical or undesirable, input to `Asn1Inte...

### Summary Using timeit.timeit() function, which is a built-in python library function to execute remote pickle file. ### Details Pickle’s deserialization process is known to allow execution of function via reduce method. While Picklescan is meant to detect such exploits, this attack evades detection by calling built-in python library function like **timeit.timeit()**. And since timeit library wasn't inside unsafe globals blacklist, it may not raise red flag in the security scan. The attack payload executes in the following steps: First, the attacker craft the payload by calling to **timeit.timeit()** function from timeit library in __reduce__ method Then, inside reduce method, the attacker import dangerous libarary like os and calling **os.system()** to run OS commands, for example: curl command. And then the attacker send this malicious pickle file to the victim. Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn...

### Impact When generating an ESTree from a value with a property named `__proto__`, `valueToEstree` would generate an object that specifies a prototype instead. Example: ```js import { generate } from 'astring' import { valueToEstree } from 'estree-util-value-to-estree' const estree = valueToEstree({ ['__proto__']: {} }) const code = generate(estree) console.log(code) ``` Output: ```js { "__proto__": {} } ``` ### Patches This was fixed in version [3.3.3](https://github.com/remcohaszing/estree-util-value-to-estree/releases/tag/v3.3.3). ### Workarounds If you control the input, don’t specify a property named `__proto__`. If you don’t control the output, strip any properties named `__proto__` before passing it to `valueToEstree`.

# Impact ## Summary A vulnerability in Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service in applications. ## Details Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved. ## Fix/Mitigation The validation logic has been updated to process each named fragment only once, preventing redundant traversal. # Patches This has been remediated in `apollo-compiler` version 1.27.0. # Workarounds No known direct workarounds exist. ## Acknowledgements We appreciate the efforts of the security community in identifying and improving the performance and security of query validation mechanisms.

# Impact ## Summary A vulnerability in Apollo Gateway allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically due to internal optimizations being frequently bypassed. This could lead to excessive resource consumption and denial of service. ## Details The query planner includes an optimization that significantly speeds up planning for applicable GraphQL selections. However, queries with deeply nested and reused named fragments can generate many selections where this optimization does not apply, leading to significantly longer planning times. Because the query planner does not enforce a timeout, a small number of such queries can render gateway inoperable. ## Fix/Mitigation - A new **Query Optimization Limit** metric has been added: - This metric approximates the number of selections that cannot be skipped by the existing optimization. - The metric is checked against a limit to prevent excessive computation. Given...

# Impact ## Summary A vulnerability in Apollo Gateway allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. This could lead to excessive resource consumption and denial of service. ## Details Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved. ## Fix/Mitigation A new **Query Fragment Expansion Limit** metric has been introduced: - This metric computes the number of selections a query would have if its fragment spreads were fully expanded. - The metric is checked against a limit to prevent excessive computation. # Patches This has been remediated in `@apollo/gateway` version 2.10.1. # Workarounds No known direct workarounds exist. # References [Query Planning Documentation](https://www.apollographql.com/docs/graphos/reference/federation/query-plans) ...