CVE Feed

A flaw has been found in mruby 3.1.0. Affected is the function udiv of the file bigint.c. Executing a manipulation can lead to floating point comparison with incorrect operator. It is possible to launch the attack remotely. The exploit has been published and may be used. It is best practice to apply a patch to resolve this issue.

A vulnerability was detected in code-projects Assessment Management 1.0. The affected element is an unknown function of the file /welcome.php. The manipulation of the argument userid results in sql injection. The attack may be launched remotely. The exploit is now public and may be used.

An unauthenticated denial-of-service vulnerability was identified in TP-Link TL-MR100 v3.2, TL-MR150 v3.2, TL-MR6400 v8.0 and Archer MR600 v2, due to improper handling of exceptional request conditions that may lead to a NULL pointer dereference.  A remote attacker on an adjacent network can send a specially crated HTTP request to trigger a crash of the HTTP service process. Successful exploitation may cause the HTTP service to crash, making the web management interface and HTTP-dependent functionality temporarily unavailable.

Pcapng file parser crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

X.509IF protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

A vulnerability was identified in chenhg5 cc-connect up to 1.4.1. This affects the function shellExecCommand of the file core/engine.go of the component Management API. Such manipulation of the argument exec leads to os command injection. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The reported GitHub issue was closed automatically due to inactivity.

H.245 protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

BUSMASTER file parser abnormal exit in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Crash in sharkd in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Crash in sharkd in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Tektronix K12xx file parser crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Kerberos protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Bluetooth HFP Profile protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Bluetooth BR/EDR FHS protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

CMS protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

3gpp phone log file parser crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

A vulnerability was found in chenhg5 cc-connect up to 1.4.1. Affected by this vulnerability is the function Authenticate of the file core/webhook.go. The manipulation of the argument exec results in code injection. The attack may be performed from remote. The exploit has been made public and could be used. The reported GitHub issue was closed automatically due to inactivity.

ESS protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

SSH protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Bluetooth AVRCP Profile protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

RRC protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

C12.22 protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

UMTS FP protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

RDP protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Crash in the Wireshark dissection engine in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

C12.22 protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

ERF file parser crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Catapult DCT2000 file parser crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

Bluetooth Attribute Protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

CMS protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service

A security flaw has been discovered in TRENDnet TEW-755AP up to 20260702. This affects the function log_email_server of the file /cgi-bin/email.cgi of the component ssi. Performing a manipulation results in command injection. The attack is possible to be carried out remotely. The exploit has been released to the public and may be used for attacks.

Agno's PythonTools in libs/agno/agno/tools/python.py contains a path traversal vulnerability that allows attackers to read, write, or execute arbitrary files by supplying parent-directory traversal sequences in the file_name argument passed to read_file, save_to_file, or run_python_file tool actions. Attackers can inject traversal sequences such as '../../../../../../etc/passwd' through direct tool invocation or via prompt injection embedded in agent-processed content to escape the intended base_dir boundary and achieve arbitrary file read, arbitrary file write, or arbitrary Python code execution within the process user's authority.

A vulnerability was identified in TRENDnet TEW-755AP up to 20260702. Affected by this issue is some unknown functionality of the file /cgi-bin/wan.cgi of the component ssi. Such manipulation of the argument cameo.wan.wan_pppoe_password_00 leads to stack-based buffer overflow. The attack can be executed remotely. The exploit is publicly available and might be used.

LMDeploy deserializes disaggregated-serving peer messages with pickle. The handle_zmq_recv coroutine in lmdeploy/pytorch/disagg/conn/engine_conn.py reads peer-to-peer cache-free requests with recv_pyobj(), which deserializes the received bytes with pickle.loads(), and the isinstance check against DistServeCacheFreeRequest runs only after deserialization has already completed. The peer that supplies those bytes is caller-controlled: p2p_connect passes remote_engine_endpoint_info.zmq_address from the request body to connect() on the ZMQ PULL socket, and the POST /distserve/p2p_initialize and /distserve/p2p_connect endpoints in lmdeploy/serve/openai/api_server.py apply no authentication unless the server is started with api_keys, which defaults to None. A remote attacker can direct an engine to pull from a ZMQ endpoint under their control and execute arbitrary code in the engine process. Deployments that do not enable disaggregated serving are not affected, because the receive loop is only started once the migration backend accepts the connection.

Tina is a headless content management system. Prior to 2.5.2, the TinaCMS CLI package's Vite dev server packages/@tinacms/cli/src/next/vite/cors.ts origin callback returns false for a disallowed origin but does not reject the request, and packages/@tinacms/cli/src/next/vite/plugins.ts still routes POST /media/upload/* to mediaRouter.handlePost. The upload code in packages/@tinacms/cli/src/next/commands/dev-command/server/media.ts writes attacker-controlled multipart contents inside the configured media root. A remote attacker can cause a developer's browser to submit this state-changing request by inducing the developer to visit an attacker-controlled page while tinacms dev is running. This issue is fixed in version 2.5.2.

In Splunk On-Call (VictorOps) app versions below 1.0.43 on Splunkbase, a user who does not hold the "admin" or "power" Splunk roles could read a partially masked Application Programming Interface (API) key from the App Key Value Store (KV Store). The exposure is possible because the Splunk On-Call (VictorOps) app does not fully mask the API key before storing it in a KV Store collection that the user can read. For more information see About the app key value store (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/9.2/administer-the-app-key-value-store/about-the-app-key-value-store) in the Splunk documentation.

In Splunk MCP Server app versions below 1.2.1, a user who holds the "admin" Splunk role could execute arbitrary commands on the underlying operating system. The vulnerability is possible because of missing input validation in the app's credential management component, which deserializes stored data without checking whether the content is of the expected type.

In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user positioned in the network path could read or alter all relevant data sent from the connector when Kerberos authentication is used with Hypertext Transfer Protocol (HTTP) Event Collector in Splunk Enterprise. The vulnerability is possible because the Kerberos authentication path does not apply the configured certificate validation options when it builds the HTTP client. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka), Security configurations for Splunk Connect for Kafka (https://help.splunk.com/en/splunk-enterprise/get-data-in/splunk-connect-for-kafka/2.2/configure/security-configurations-for-splunk-connect-for-kafka), and Set up and use HTTP Event Collector with configuration files (https://help.splunk.com/en/splunk-enterprise/get-data-in/get-started-with-getting-data-in/9.4/get-data-with-http-event-collector/set-up-and-use-http-event-collector-with-configuration-files) in the Splunk documentation.

In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user who can reach the Kafka Connect Representational State Transfer (REST) API could configure a non-secure Hypertext Transfer Protocol (HTTP) Event Collector endpoint in Splunk Enterprise that causes the connector to send authentication credentials to an attacker-controlled server, allowing for exposure of credentials that compromise all relevant data sent through the connector and limited alteration of event delivery. The vulnerability is possible because HTTP Event Collector endpoint validation does not require secure transport by default. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka), Data ingestion parameters for Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/overview/data-ingestion-parameters-for-splunk-connect-for-kafka), and Set up and use HTTP Event Collector with configuration files (https://help.splunk.com/en/splunk-enterprise/get-data-in/get-started-with-getting-data-in/9.4/get-data-with-http-event-collector/set-up-and-use-http-event-collector-with-configuration-files) in the Splunk documentation.

In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user who can reach the Kafka Connect Representational State Transfer (REST) API could configure timestamp extraction with a crafted regular expression and matching event data to block a Kafka Connect worker thread, stopping event delivery for the affected connector. The vulnerability is possible because timestamp extraction evaluates customer-supplied regular expressions without a time limit. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka) and Data ingestion parameters for Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/overview/data-ingestion-parameters-for-splunk-connect-for-kafka) in the Splunk documentation.

In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user who can reach the Kafka Connect Representational State Transfer (REST) API and influence responses from a Hypertext Transfer Protocol (HTTP) Event Collector endpoint in Splunk Enterprise could cause the connector to retry failed event batches until event delivery stops. The vulnerability is possible because HTTP Event Collector delivery retry handling uses an unbounded default for failed batches instead of a finite retry limit. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka), Data ingestion parameters for Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/overview/data-ingestion-parameters-for-splunk-connect-for-kafka), and Set up and use HTTP Event Collector with configuration files (https://help.splunk.com/en/splunk-enterprise/get-data-in/get-started-with-getting-data-in/9.4/get-data-with-http-event-collector/set-up-and-use-http-event-collector-with-configuration-files) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.1, a user who holds the "power" Splunk role could modify app-provided scheduled searches to run arbitrary Search Processing Language (SPL) using the permissions of the search owner, which could allow access to all relevant data and affect system integrity. The vulnerability is possible because Splunk AI Toolkit gives the "power" Splunk role permission to modify scheduled searches that run using the permissions of the search owner.

In Splunk AI Toolkit versions below 6.0.1, a user who does not hold the "admin" or "power" Splunk roles could delete the experiment history of another user without permission through the Representational State Transfer (REST) API. The vulnerability is possible because Splunk AI Toolkit deletes experiment history before it verifies that the user can delete the associated experiment. For more information see Experiment Assistants (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/use-ai-toolkit/5.6.4/experiment-assistants) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a user who holds the "power" Splunk role could access and delete all relevant data in experiment history, including data associated with other users. The vulnerability is possible because Splunk AI Toolkit does not preserve the trusted experiment scope when it processes caller-controlled query values before accessing restricted history data. For more information see Experiment Assistants (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/use-ai-toolkit/5.6.4/experiment-assistants) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a user that holds a role with the schedule_search capability could cause a scheduled search to load and deserialize a model file through the apply search command. The improper access control is possible because Splunk AI Toolkit does not mark the apply search command as risky. For more information see Troubleshoot the AI Toolkit (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/5.7.3/troubleshooting-the-ai-toolkit/troubleshoot-the-ai-toolkit) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a user who holds the "power" Splunk role could execute arbitrary code on the Splunk server by loading a model file containing crafted sparse matrix data. The deserialization of untrusted data is possible because a model codec in Splunk AI Toolkit deserializes sparse matrix data without guarding against embedded pickle content. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a low-privileged user who does not hold the "admin" or "power" Splunk roles could start, stop, and configure containers, and read or modify connection and configuration data through the Representational State Transfer (REST) API. The missing authorization is possible because multiple REST API handlers in Splunk AI Toolkit do not enforce authorization checks. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a user who can upload models could overwrite a model being uploaded by another user by sending a concurrent upload request for the same model name, causing the resulting model lookup entry to reference attacker-controlled content. The race condition is possible because Splunk AI Toolkit does not verify that the uploaded content belongs to the request that creates the model lookup entry. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could obtain predictable or default credentials for connected container services. The use of hard-coded credentials is possible because Splunk AI Toolkit generates or stores credentials for connected container services using predictable or hard-coded default values. For more information see Connections tab in the AI Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/use-ai-toolkit/5.7.2/ai-toolkit-commands-macros-and-visualizations/connections-tab-in-the-ai-toolkit) in the Splunk documentation.

In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The improper privilege management is possible because the Agent Run History handler replaces the calling user session key with a system authentication token before it performs search operations. For more information see AI Toolkit Agent Launchpad (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/6.0.0/ai-toolkit-connections-containers-and-agents/ai-toolkit-agent-launchpad) in the Splunk documentation.