Vulnerabilities

Use of weak SSH cryptographic algorithms in Canon EOS Network Setting Tool Version 1.5.0 or earlier

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc (GRPC.Compressor.Gzip, GRPC.Message modules) allows a denial of service via a gzip decompression bomb.<br /> <br /> This vulnerability is associated with program files lib/grpc/compressor/gzip.ex, lib/grpc/message.ex and program routines &amp;#39;Elixir.GRPC.Compressor.Gzip&amp;#39;:decompress/1, &amp;#39;Elixir.GRPC.Message&amp;#39;:from_data/2.<br /> <br /> &amp;#39;Elixir.GRPC.Compressor.Gzip&amp;#39;:decompress/1 calls :zlib.gunzip/1 directly on attacker-controlled bytes with no decompressed-size limit, ratio check, or incremental decoding. Because this module is the registered gzip GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries the grpc-encoding: gzip header. :zlib.gunzip/1 allocates the entire decompressed result as a single binary, so a small highly compressible payload (for example a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single call. The max_receive_message_length limit is enforced only against the already-decompressed message, so it provides no protection. An unauthenticated remote peer can send a single crafted frame to exhaust the BEAM node&amp;#39;s heap and trigger an out-of-memory kill.<br /> <br /> This issue affects grpc: from 0.4.0 before 1.0.0.

Authorization Bypass Through User-Controlled Key vulnerability in elixir-grpc grpc allows authenticated attackers to access or modify resources belonging to other users by smuggling a conflicting value for any path-bound field via the query string or request body.<br /> <br /> In &amp;#39;Elixir.GRPC.Server.Transcode&amp;#39;:map_request/5 (lib/grpc/server/transcode.ex), all three clauses use Map.merge/2 with path bindings as the first argument, giving them the lowest merge precedence. A request such as GET /users/me/profile?user_id=victim (or a POST with {"user_id": "victim"} when body: "*") yields a decoded protobuf struct where the path-bound field carries the attacker-supplied value rather than the router-extracted value. Any handler that uses the path-bound field for authorization, multi-tenancy scoping, or ownership checks is silently bypassed.<br /> <br /> This issue affects grpc from 0.8.0 before 1.0.0.

Deserialization of Untrusted Data and Allocation of Resources Without Limits or Throttling vulnerabilities in elixir-grpc grpc allow unauthenticated attackers to crash the BEAM node via atom table exhaustion and, when a decoded term flows into a call site that invokes it, achieve remote code execution on the server.<br /> <br /> &amp;#39;Elixir.GRPC.Codec.Erlpack&amp;#39;:decode/2 (lib/grpc/codec/erlpack.ex) calls :erlang.binary_to_term/1 on the raw gRPC message body without the :safe option, no size bound, and no type guard. Any unauthenticated peer that sends a request with Content-Type: application/grpc+erlpack can send a crafted payload that mints arbitrary new atoms (which are never garbage-collected, exhausting the bounded atom table and crashing the VM) or that encodes a fun term which, if applied anywhere downstream, executes attacker-controlled code inside the server process.<br /> <br /> This issue affects grpc from 0.4.0 before 1.0.0.

Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc allows unauthenticated attackers to exhaust the BEAM&amp;#39;s memory and crash the server by streaming a large or slow-trickle unary request body.<br /> <br /> &amp;#39;Elixir.GRPC.Server.Adapters.Cowboy.Handler&amp;#39;:read_full_body/3 (lib/grpc/server/adapters/cowboy/handler.ex) accumulates every received chunk into a single growing binary with no size cap. Additionally, when the client omits the grpc-timeout header, the per-chunk read timeout resolves to :infinity, allowing a slow-trickle client to keep the connection alive indefinitely while memory grows. A single connection is sufficient to exhaust server memory and crash the node.<br /> <br /> This issue affects grpc from 0.3.1 before 1.0.0.

The browserstack-cypress-cli is BrowserStack&amp;#39;s CLI which allows users to run Cypress tests on BrowserStack. Versions prior to 1.36.4 are vulnerable to OS command injection via the cypress_config_file configuration parameter. In readCypressConfigUtil.js, the loadJsFile() function constructs a shell command by interpolating the user-controlled cypress_config_filepath value into a template literal, then executes it via child_process.execSync(). Shell metacharacters in the config path (specifically " and ;) allow breaking out of the quoted argument and injecting arbitrary commands. This issue has been fixed in version 1.36.6.

Crypt::DSA versions before 1.21 for Perl reused the nonce across signatures, leading to private-key recovery.<br /> <br /> Crypt::DSA::sign caches the per-signature nonce material in the Key object without ever clearing it.<br /> <br /> The first sign() on a Key object picks a nonce, and every later sign() on that same object reuses it, producing an identical "r".<br /> <br /> Keys used to sign more than once with an affected version should be considered compromised.

Potential security vulnerabilities have been identified in the HP One <br /> Agent for certain HP PC products, which might allow<br /> for escalation of privilege and/or denial of service. HP <br /> is releasing software updates to mitigate these potential <br /> vulnerabilities.

Versions prior to 2.6.6 are vulnerable to prototype pollution via crafted missing-key strings when used to persist missing translation keys (e.g. via i18next-http-middleware&amp;#39;s missingKeyHandler exposed to untrusted input). Backend.writeFile() splits each queued missing-key string on the configured keySeparator (default .) before calling the internal setPath() walker. The walker (getLastOfPath in lib/utils.js) did not guard against unsafe segments, so a key like "__proto__.polluted" was split into ["__proto__", "polluted"] and walked straight into Object.prototype, allowing an attacker to write arbitrary properties onto the global object prototype. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. Applications are affected only if the missingKeyHandler (or another route that forwards untrusted request bodies to i18next.t(..., { ... }) with saveMissing: true) is reachable by untrusted users and the default behaviour of splitting missing-key strings on keySeparator is in use (i.e. keySeparator is not false). Apps that do not expose missing-key persistence to untrusted input are not directly affected through this attack path. This issue has been fixed in version 2.6.6. If developers using the library are unable to upgrade immediately, they should take the following precautions: do not expose i18next-http-middleware&amp;#39;s missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), disable missing-key persistence (saveMissing: false, or no backend.create implementation) when accepting writes from untrusted input, and set keySeparator: false in their i18next options to disable backend key splitting (note: this also disables nested translation keys).

i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. In versions prior to 3.9.7, the missingKeyHandler blocked the literal request-body keys __proto__, constructor, and prototype (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as "__proto__.polluted". Downstream backends that split the missing-key string on a configured keySeparator (notably i18next-fs-backend ≤ 2.6.5) hand these keys to an unguarded setPath() walker that writes to Object.prototype. Applications that expose missingKeyHandler to untrusted input AND use i18next-fs-backend ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. This issue has been fixed in version 3.9.7. If developers cannot upgrade immediately, they should do the following: do not expose missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), add a request-body filter ahead of the handler that rejects any top-level key containing __proto__, constructor, or prototype after splitting on their configured keySeparator, and disable missing-key persistence (saveMissing: false) when accepting writes from untrusted input.

Slim is a PHP micro framework that enables users to write simple web applications and APIs. In versions 4.4.0 through 4.15, if an application uses HttpException::setTitle() and/or setDescription() to include untrusted/request-derived data in the error title or description (e.g. "No products found matching &amp;#39;{$query}&amp;#39;."), an attacker could inject arbitrary HTML/JavaScript that executes in the victim&amp;#39;s browser when they encounter an HTML error page generated by Slim. The vulnerability is present even with displayErrorDetails = false as the unescaped title and description are rendered on this error path. Built-in exceptions (HttpNotFoundException, HttpBadRequestException, etc.) ship plain-text defaults, so a vanilla Slim app with no user code is not exploitable. Only applications that feed untrusted data into setTitle() and/or setDescription() are affected. The issue has been fixed in 4.15.2. If developers are unable to immediately update their applications, they can work around this issue by avoiding passing untrusted/request-derived data into HttpException::setTitle() and setDescription() and using static, plain-text error copy instead.<br /> They should also register a custom error renderer (an ErrorRendererInterface implementation, or a subclass of HtmlErrorRenderer that escapes the title and description) for the HTML media type.

Socket versions before 2.041 for Perl have an out-of-bounds heap read.<br /> <br /> In Socket.xs, pack_ip_mreq_source() checks the length of its source argument before the argument is read, so the check tests the byte length carried over from the preceding multiaddr argument instead. Both addresses occupy a 4-byte field, so a valid multiaddr lets a source of any length pass the check, and the source is then copied into the 4-byte imr_sourceaddr field with a fixed-size copy. A source shorter than 4 bytes is not rejected, and the copy reads up to 3 bytes past the end of its buffer.<br /> <br /> Calling pack_ip_mreq_source() with a source value shorter than 4 bytes copies adjacent heap memory into the returned packed structure.