Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-fr2g-9hjm-wr23: NATS.io: Adding accounts for just the system account adds auth bypass

(This advisory is canonically <https://advisories.nats.io/CVE/secnote-2023-01.txt>) ## Background NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing. NATS users exist within accounts, and once using accounts, the old authorization block is not applicable. ## Problem Description Without any authorization rules in the nats-server, users can connect without authentication. Before nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an "authorization" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, "$G". Users inside accounts go into the newer "accounts" block. If an "accounts" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. Wh...

ghsa
#ios#git#auth
GHSA-jrf2-h5j6-3rrq: Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free

### Impact First, a little bit of background. So, in the beginning, Bunkum's `AuthenticationService` only supported injecting `IUser`s. However, as Refresh and SoundShapesServer implemented permissions systems support for injecting `IToken`s into endpoints was added. All was well until 4.0. Bunkum 4.0 then changed to enforce relations between `IToken`s and `IUser`s. This wasn't implemented in a very good way in the `AuthenticationService`, and ended up breaking caching in such a way that cached tokens would persist after the lifetime of the request - since we tried to cache both tokens and users. From that point until now, from what I understand, Bunkum was attempting to use that cached token at the start of the next request once cached. Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of `IToken.User`. So in other words, a use-af...

GHSA-r344-xw3p-2frj: Apollo Router vulnerable to Improper Check or Handling of Exceptional Conditions

### Impact The Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability which causes the Router to panic and terminate when a multi-part response is sent. When users send queries to the router that uses the `@defer` or Subscriptions, the Router will panic. To be vulnerable, users of Router must have a coprocessor with `coprocessor.supergraph.response` configured in their `router.yaml` and also to support either `@defer` or Subscriptions. ### Patches Router version 1.33.0 has a fix for this vulnerability. https://github.com/apollographql/router/pull/4014 fixes the issue. ### Workarounds For affected versions, avoid using the coprocessor supergraph response: ```yml # do not use this stage in your coprocessor configuration coprocessor: supergraph: response: ``` Or you can disable defer and subscriptions support: ```y...

GHSA-fc75-58r8-rm3h: Wagtail vulnerable to disclosure of user names via admin bulk action views

### Impact A user with a limited-permission editor account for the Wagtail admin can make a direct URL request to the admin view that handles bulk actions on user accounts. While authentication rules prevent the user from making any changes, the error message discloses the display names of user accounts, and by modifying URL parameters, the user can retrieve the display name for any user. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. ### Patches Patched versions have been released as Wagtail 4.1.9 (LTS), 5.0.5 and 5.1.3. The fix is also included in Release Candidate 1 of the forthcoming Wagtail 5.2 release. ### Workarounds None. ### Acknowledgements Many thanks to @quyenheu for reporting this issue. ### For more information If you have any questions or comments about this advisory: * Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html) * Email us at [[email protected]](mailto:security@wagtail...

GHSA-rxrc-rgv4-jpvx: React Developer Tools extension Improper Authorization vulnerability

The React Developer Tools extension registers a message listener with window.addEventListener('message', <listener>) in a content script that is accessible to any webpage that is active in the browser. Within the listener is code that requests a URL derived from the received message via fetch(). The URL is not validated or sanitised before it is fetched, thus allowing a malicious web page to arbitrarily fetch URL’s via the victim's browser.

GHSA-72qw-p7hh-m3ff: TorBot vulnerable to Inefficient Regular Expression Complexity in validate_link

### Summary _The torbot.modules.validators.validate_link function uses the python-validators URL validation regex. This particular regular expression has an exponential complexity which allows an attacker to cause an application crash using a well-crafted argument.._ ### Details https://github.com/DedSecInside/TorBot/blob/d2b89192379ad033ffc7044efff26e16ccc02d5a/torbot/modules/validators.py#L13 An attacker can use a well-crafted URL argument to exploit the vulnerability in the regular expression and cause a Denial of Service on the system. ### PoC I have uploaded a secret gist containing a PoC (https://gist.github.com/ikkebr/6041055314f1cfb8e65b2a1acbaae12c). By adding one special character at the end of the user argument of the URL, the regular expression will take exponentially longer to compute. For a string of size 10k, the regex will take 0.01s without the well-crafted URL and 1.3s with the well-crafted URL exploit. For a string of size 50k, the regex will take 0.03s without t...

GHSA-jj32-3pf5-5mv5: Apache InLong Deserialization of Untrusted Data Vulnerability

Deserialization of Untrusted Data Vulnerability in Apache Software Foundation Apache InLong. This issue affects Apache InLong: from 1.4.0 through 1.8.0, the attacker can use \t to bypass. Users are advised to upgrade to Apache InLong's 1.9.0 or cherry-pick [1] to solve it. [1] https://github.com/apache/inlong/pull/8814

GHSA-7w8v-5fcq-pvqw: Apache Shenyu Server Side Request Forgery vulnerability

There exists an SSRF (Server-Side Request Forgery) vulnerability located at the `/sandbox/proxyGateway` endpoint. This vulnerability allows us to manipulate arbitrary requests and retrieve corresponding responses by inputting any URL into the requestUrl parameter. Of particular concern is our ability to exert control over the HTTP method, cookies, IP address, and headers. This effectively grants us the capability to dispatch complete HTTP requests to hosts of our choosing. This issue affects Apache ShenYu: 2.5.1. Upgrade to Apache ShenYu 2.6.0 or apply patch  https://github.com/apache/shenyu/pull/4776  .

GHSA-c827-hfw6-qwvm: rustix's `rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion

### Summary When using `rustix::fs::Dir` using the `linux_raw` backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in `rustix::fs::Dir::read_more`, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. ### Details #### Discovery The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. See [this post](https://github.com/imsnif/bandwhich/issues/284#issuecomment-1754321993) and the [Discord thread](https://discord.com/channels/273534239310479360/1161137828395237556) for details. #### Diagnosis This issue is caused by the combination of two independent bugs: 1. Stuck iterator - The `rustix::fs::Dir` iterator can fail to halt after encountering an IO error, causing the caller to be stuck in an infinite loop. 2. Memory...

GHSA-jg82-xh3w-rhxx: Synchrony deobfuscator prototype pollution vulnerability leading to arbitrary code execution

### Impact A `__proto__` pollution vulnerability exists in synchrony versions before v2.4.4. Successful exploitation could lead to arbitrary code execution. ### Summary A `__proto__` pollution vulnerability exists in the [LiteralMap] transformer allowing crafted input to modify properties in the Object prototype. When executing in Node.js, due to use of the `prettier` module, defining a `parser` property on `__proto__` with a path to a JS module on disk [causes a `require` of the value][prettier/src/main/parser.js] which can lead to arbitrary code execution. ### Patch A fix has been released in `[email protected]`. ### Mitigation - Upgrade synchrony to v2.4.4 - Launch node with the [--disable-proto=delete][disable-proto] or [--disable-proto=throw][disable-proto] flag ### Proof of Concept Craft a malicious input file named `poc.js` as follows: ```js // Malicious code to be run after this file is imported. Logs the result of shell command "dir" to the console. console.log(req...