Search: 5.1.8.7

Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 Mattermost fail to apply allocation limits to the byte-string decode paths in its WebSocket msgpack decoder, which allows an authenticated remote attacker to cause excessive server memory allocation via a crafted binary WebSocket frame declaring a Bin32 payload length of up to 4,294,967,295 bytes.. Mattermost Advisory ID: MMSA-2026-00768

Mattermost versions <=11.9 11.1.9 11.5.8 11.10.7.0 fail to validate Zoom chat line length before slicing which allows an authenticated attacker to crash the Agents plugin via summarizing a Zoom chat transcription containing short continuation lines. Mattermost Advisory ID: MMSA-2026-00723

Insufficient Session Expiration vulnerability in Apache Camel Keycloak component. This issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2. When token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak's OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token's expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation's recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.16.x, 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory.

Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. When the CoAP consumer could not build its response once the route had completed, CamelCoapResource caught the resulting exception and sent its message back to the CoAP client as the payload of a 5.00 Internal Server Error response. The typical case is a type conversion failure: the consumer converts the final message body to the byte[] payload, and the CamelCoapMaxAge and CamelCoapETag headers to their types, after the route has returned, and therefore outside the route's error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value's string form, and ends with the class name and message of the underlying cause, so a remote CoAP client could read internal detail about the deployment: class and package names, the string form of the value, such as the path of a file body, and whatever the cause carries, which in practice can include paths, host names and connection detail of a backend. The consumer had no option to suppress this, unlike the HTTP consumers, which offer a muteException option for that purpose. The exception raised by a failing route was not sent: the consumer did not check whether the exchange had failed, and answered a route failure with 2.05 Content and whatever body the message held at that point. Reaching the disclosure therefore requires a route whose completed response a remote client can make unconvertible, which depends on how the route is written. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. The upgrade is enough on its own: the new muteException consumer option defaults to true on all three fixed release lines, so the error response carries no payload without any configuration change. For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer.

A vulnerability was determined in DedeCMS 5.7.118. This vulnerability affects the function common.inc.php::_RunMagicQuotes of the file plus/ad_js.php of the component Advertisement Rendering. Executing a manipulation of the argument aid can lead to code injection. The attack can be executed remotely.

A vulnerability in virtualenv's xonsh activation script allows attacker-controlled prompt text to become executable code during environment activation if the xonsh source decoding uses legacy multibyte encodings like GBK or Big5. This occurs because the UTF-8 encoded activation script is read with a different codec, causing escape characters to be misinterpreted and enabling code injection. The issue affects POSIX activation scripts and requires an attacker to control the prompt or destination argument passed to virtualenv and a user to activate the environment with the affected encoding. A fix is available in virtualenv version 2.5.1_1.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer builds the command line of the external docling tool and appends to it the custom arguments supplied in the CamelDoclingCustomArguments header, a list of strings whose flags the fix for CVE-2026-40047 restricted to an allowlist. That fix also introduced validatePathSafety to keep path-like argument values inside the intended directory, but the method only looked for relative traversal: it rejected a value containing a traversal sequence such as ../ and a value whose normalized form still held a .. element. It never checked whether a value was an absolute path, and an absolute path without traversal segments contains neither, so it passed unchanged. Every path-like value went through this check, whether it was a separate list element following its flag or was attached to the flag after an equals sign, so an absolute path was accepted in either form, for example as the directory given to the allowlisted --artifacts-path flag, which tells docling where to find its model artifacts. Such a value reached the docling command line as given, so a party able to choose the custom arguments could point the docling process at any directory the Camel process can access, outside the working directory that the check was meant to keep path values in, which is the outcome the CVE-2026-40047 fix set out to prevent. Only the CLI mode, which is the default, passes custom arguments to docling. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments.

CVE-2026-95664 is an Expression Language Injection vulnerability in the Apache Camel AWS2-s3 component affecting versions from 4.8.0 before 4.18.5 and from 4.19.0 before 4.22.2. The issue arises because the key used by the aws2-s3 producer is taken from a message header and evaluated as a Simple language expression if it contains certain markers, allowing untrusted input to be executed. This can lead to unauthorized access to JVM system properties, environment variables, and invocation of methods on beans, potentially exposing sensitive information. The vulnerability is fixed in versions 4.18.5 and 4.22.2. Users are advised to upgrade to these versions or 4.23.0 or later. Workarounds include removing or validating the CamelAwsS3Key header to prevent untrusted expressions from being evaluated.

The OPay Payment Gateway for WooCommerce WordPress plugin through 2.5.5 does not properly verify that payment notifications originate from the payment provider, as the secret used to validate their signature is empty by default, allowing unauthenticated attackers to forge a valid notification and mark arbitrary orders as paid, cancelled or failed.

CVE-2026-116124 is a heap-based buffer overflow vulnerability in GNOME libgsf versions 1.14.0 through 1.14.19. The flaw exists in the ole_info_read_metabat function within the OLE2 Parser component, allowing remote attackers to trigger the overflow. This vulnerability has a medium severity rating with a CVSS 4.0 score of 5.3. A patch identified by commit a8e25560b74f84c3f86df6ca0ac59195fa5af68a is available to address the issue.

Pillow is a Python imaging library. From 5.3.0 until 13.0.0, Pillow can return uninitialized memory as pixels when libtiff performs a short decode of JPEG-compressed or Group 4 fax TIFF data. The _decodeStrip and _decodeTile buffers can be larger than the bytes written by libtiff, but Pillow converts the expected rows without clearing the unwritten tail. The tile path is affected from 5.3.0 and the strip path from 6.0.0. An attacker can supply a crafted TIFF to an application that loads and returns or re-encodes its pixels. This can disclose stale heap contents without memory corruption or a process crash. This issue is fixed in version 13.0.0.

@apexacc/cli is distributed by "Apex Accelerator" (Apex Arena), a fake Web3 accelerator that lures crypto founders with free AI credits and audits. Elastic Security Labs (REF8801, published 2026-10-12) found it is a repackaged Oh My Pi coding agent (1,351 of 1,363 files identical) with malicious additions that hijack the developer's AI coding agent: it overwrites OPENROUTER_BASE_URL so model traffic (prompts, files read, tool results) goes to attacker infrastructure at arena.apexaccs.org; persists an attacker-controlled remote MCP server in ~/.apex/agent/mcp.json; and defaults tool approval to "yolo". A bootstrap retrieves commands from vrf.apexaccs.org: on macOS it drops CloudSyncD (fake password prompt, credential theft, C2 ccmihr.com); on Windows a staged loader chain ends in an infostealer that exfiltrates browser credentials, wallets, messengers, VPN clients and Claude/Cursor/Windsurf configs over Telegram. Elastic analyzed version 1.6.1 and traced the bootstrap to the earliest preserved version (script host arenapex.cloud). The package was still live on npm (latest 1.6.2) with no OSV record as of 2026-10-16. Independently confirmed by static inspection of the live 1.6.2 npm tarball (sha256 7ca5e3908dd8721d0cf6af2488f0825c0d91a5e0b7c8529ef830141a4a3ba31f) on 2026-10-16, without execution: the bin launcher apex.cjs (sha256 4029192a44ee738deba9aa53b57550075cb8fd170a63f0636dea5452256f2175) runs when the user invokes the CLI (no install script). On Windows it sets the current user's PowerShell execution policy to RemoteSigned (no elevation needed), and on Windows 11 it launches a hidden, elevated (UAC RunAs) PowerShell that attempts to add a Defender exclusion for ~/.apex and to set HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy VerifiedAndReputablePolicyState=0 (disabling Smart App Control). From 1.5.122 (2026-09-17) through 1.6.2 those two commands are built in a JavaScript template literal with single backslashes, so the shipped paths are mangled (the exclusion lands on a sibling path '<home>.apex' and the registry key is invalid) and both likely fail; the UAC prompt still appears. Versions 1.5.120 (registry change) and 1.5.121 (adds the Defender exclusion), both 2026-09-17, carried correctly escaped versions of these commands without an elevation prompt, effective only when already running as administrator. The execution-policy change first appears in 1.6.2. It then downloads a ~114MB native binary from GitHub releases of apexaccs/copilot into ~/.apex/bin, and on macOS an additional apex-verify-darwin helper. Both GitHub repositories referenced by the package versions (apexaccs/copilot, Apex-Accelerator/apexcli) return 404 as of 2026-10-16. All versions affected. Indicators from Elastic's report. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c174007782646e1fdfd9806ecd699e427fd36661dd7137fa462672f41aee6e79) On CLI startup (invoked via npx per the package README), apex.cjs unconditionally detects Windows 11 and launches a hidden, UAC-elevated PowerShell via Start-Process -Verb RunAs -WindowStyle Hidden with a UTF-16LE base64 -EncodedCommand payload. The elevated payload (a) calls Add-MpPreference -ExclusionPath on %USERPROFILE%\.apex to whitelist the package directory in Windows Defender, and (b) writes HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy VerifiedAndReputablePolicyState=0 via reg add, disabling Smart App Control / Code Integrity enforcement machine-wide. The elevation path uses underscore-prefixed identifiers (_ps, _enc, _sp, _osv, _isWin11, _home), a hidden window, base64 command encoding, and a broad try/catch that silently swallows errors. After weakening the host, the CLI downloads a ~105MB apex-<platform>.exe (and an optional native.node addon) from the publisher's GitHub Releases with no hash or signature verification, chmods 0755, and executes it via spawnSync with inherited stdio and the full process.env. The security-policy downgrade is not consistent with any documented function of an AI CLI and converts an otherwise routine publisher-pinned binary fetch into execution of unverified code under a machine-wide-weakened Windows security posture.

A flaw has been found in openbq-org OpenBB up to 4.7.2/5.0.0. This affects an unknown part of the file openbb_platform/core/openbb_core/app/model/api_settings.py of the component Local API Server. This manipulation causes improper access controls. Remote exploitation of the attack is possible. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A security update for python3-urllib3 addresses a denial of service vulnerability caused by unbounded memory allocation in the chunk parser (CVE-2026-97689). This flaw could allow an attacker to cause a denial of service condition. The vulnerability affects versions of python3-urllib3 prior to 1.26.5-8.el9_8.2. A fixed version is available and should be applied to mitigate the issue.

An out-of-bounds write vulnerability (CVE-2026-111497) was discovered in the Google Brotli decoder, a lossless compression algorithm used in various Red Hat Enterprise Linux 8 distributions. This vulnerability could potentially lead to memory corruption. A security update fixing this issue is available in brotli version 1.0.6-5.el8_10.

Libreswan, an IPsec and IKE implementation for Linux, has multiple security vulnerabilities including a use-after-free bug in IKEv2 when using IKE-over-TCP (CVE-2026-94453), a denial of service via bogus X.509 certificates (CVE-2026-77205), and a null pointer dereference in PKCS#7 bundles with no certificates (CVE-2026-77207). These issues affect versions prior to 5.3.3-1.el10_2. A security update fixing these vulnerabilities is available.