| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A improper neutralization of special elements used in a command ('command injection') vulnerability in Fortinet FortiMail 8.0.0 through 8.0.2, FortiMail 7.6.0 through 7.6.6, FortiMail 7.4.0 through 7.4.8, FortiMail 7.2 all versions may allow an authenticated remote attacker with domain admin or admin privileges to delete users of other tenant domains on a paired FortiAuthenticator, execute arbitrary code as root or arbitrary CLI commands, and read or write arbitrary files as root via crafted HTTP requests to the administrative interface. |
| A allocation of resources without limits or throttling vulnerability in Fortinet FortiAuthenticator 8.0.0 through 8.0.3, FortiAuthenticator 6.6.0 through 6.6.10 may allow an unauthenticated attacker to exhaust system resources, potentially resulting in a denial of service (DoS). |
| Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc_server allows unauthenticated attackers to exhaust server memory via client-streaming or bidirectional-streaming requests.
The streaming read clause of GRPC.Server.Adapters.Cowboy.Handler.info/3 (grpc_server/lib/grpc/server/adapters/cowboy/handler.ex) asks Cowboy for up to 8,000,000 bytes per read and compares the running total with max_body_size only after the read returns. The gRPC length prefix of a message is not checked before the message is buffered. Each stream can therefore buffer up to one full read beyond the configured limit before it is refused, and many concurrent streams exhaust node memory. Releases before 1.0.6 apply no limit to streaming requests at all.
This issue affects grpc_server: from 1.0.0 before 1.1.0. |
| Missing Release of Resource after Effective Lifetime vulnerability in elixir-grpc grpc_server allows a client to stall all later calls on a shared HTTP/2 connection via calls that the server refuses while their DATA frames are in flight.
The stream handler grpc_stream_h (grpc_server/src/grpc_stream_h.erl) requests flow from Cowboy only for request data that has arrived. When the server refuses a call early, for example because the body exceeds max_body_size or the method is not implemented, Cowboy drops the DATA frames still in flight for that stream. Their bytes are not returned to the connection flow-control window. After enough refused calls the window is empty. No call on that connection can then send a request body, and each call waits until its deadline. Other connections are not affected.
This issue affects grpc_server: from 1.0.0 before 1.1.0. |
| clnttcp_call() in lib/rpc/clnt_tcp.c in MIT Kerberos 5 (aka krb5) does not free the RPC reply verifier between retries, which allows remote attackers to cause a denial of service (memory leak in GSS-RPC client programs) by injecting RPC replies with mismatched XIDs or by triggering authentication retries. |
| P-Net before 1.0.4 keeps the RPC session that is allocated for a fragment of a request with an unknown activity UUID, without a timeout, when the rest of the request never arrives. A session that does not get an Application Relationship is also kept after the response. Repeated fragments or requests with different activity UUIDs exhaust the available sessions, one UDP packet per session. Once they are exhausted the device no longer answers a Connect request until it is restarted. An unauthenticated attacker with ADJACENT network access can use this to cause a denial of service. |
| clean_client() in lib/rpc/svc_auth_gssapi.c in MIT Kerberos 5 (aka krb5) restarts its scan from the head of the client list after each removal, resulting in quadratic CPU cost. Remote attackers can cause a denial of service (CPU consumption in kadmind) by accumulating a large number of AUTH_GSSAPI client entries. |
| The AUTH_GSSAPI handler in lib/rpc/svc_auth_gssapi.c in MIT Kerberos 5 (aka krb5) 1.5.2 and later allows remote attackers to cause a denial of service (memory exhaustion in kadmind) by sending repeated failed AUTH_GSSAPI_INIT requests. Each failed request allocates client state that is only freed after a 15-minute expiration timeout, allowing an attacker to accumulate memory faster than it is reclaimed. |
| The AUTH_GSSAPI handler in lib/rpc/svc_auth_gssapi.c in MIT Kerberos 5 (aka krb5) does not free decoded arguments on certain error paths, which allows remote attackers to cause a denial of service (memory exhaustion in kadmind) via crafted AUTH_GSSAPI_INIT requests that trigger authentication failures. |
| The GSS-RPC transport layer in MIT Kerberos 5 (aka krb5) 1.4 and later does not release the previous authentication context when a client switches from an RPCSEC_GSS or AUTH_GSSAPI flavor to a non-GSS flavor on the same TCP connection. This allows remote attackers to cause a denial of service (memory exhaustion in kadmind) by repeatedly establishing and abandoning GSS authentication contexts. |
| The GSS-RPC layer in MIT Kerberos 5 (aka krb5) does not enforce size limits on XDR-decoded data, which allows remote authenticated users to cause a denial of service (memory exhaustion or excessive CPU consumption in kadmind) via crafted RPC requests that trigger unbounded memory allocations during XDR decoding. |
| krb5_ktkdb_get_entry() in lib/kdb/keytab.c in MIT Kerberos 5 (aka krb5) 1.2.8 and later does not free decrypted key material when a post-decryption check fails, which allows remote attackers to cause a denial of service (memory leak in the KDC or kadmind) via requests that repeatedly trigger key decryption failures. |
| xdr_krb5_tl_data() in lib/kadm5/kadm_rpc_xdr.c in MIT Kerberos 5 (aka krb5) does not free partially decoded data on failure, which allows remote authenticated users to cause a denial of service (memory leak in kadmind) via crafted RPC requests that trigger a decode failure. |
| The RPCSEC_GSS authentication routines in lib/rpc/authgss_prot.c in MIT Kerberos 5 (aka krb5) 1.4 and later do not free partially decoded buffers on failure, which allows remote attackers to cause a denial of service (memory leak in kadmind) via crafted RPCSEC_GSS messages. |
| Active Storage makes it simple to upload and reference files in cloud services and attach those files to Active Record objects. From 8.0 until 8.0.5.2 and 8.1.4.1, when Active Storage serves a file through its proxy controllers, ActiveStorage::Streaming#send_blob_stream handles an error from the storage service by calling head to send a 404 or 500 response. If the error occurs after the first chunk has been written, the response is already committed, and head replaces the response body while the server is still reading the original ActionController::Live buffer. That buffer is never closed, so the server thread handling the request blocks until the process restarts. Repeated failed downloads could exhaust the server's threads, possibly resulting in a DoS vulnerability. Applications are affected when they store files on a service that streams a download in several requests, such as Amazon S3, an S3-compatible service or Google Cloud Storage, and draw Active Storage's default routes. The proxy routes are drawn whether or not proxy mode is the default for the application. A file deleted while it is being served, or any other storage error partway through a download, triggers the condition. This issue is fixed in versions 8.1.4.1 and 8.0.5.2. |
| NocoDB before 2026.09.0 contains an uncontrolled resource consumption vulnerability that allows authenticated users to bypass bulk row-count limits by using session authentication instead of API tokens. Attackers with Editor write permission on one table can submit hundreds of thousands of rows to v1 and v2 bulk write routes, exhausting database connections, CPU, and memory. |
| NocoDB before 2026.08.1 contains an uncontrolled resource consumption vulnerability that allows unauthenticated attackers to exhaust server resources by sending unbounded filter arrays to shared-view bulk endpoints. Attackers with a shared view UUID can POST a large body of minimal filter objects, triggering a full database query per entry, to crash the NocoDB process. |
| NocoDB before 2026.06.2 contains an attachment size limit bypass that allows authenticated Editor users to store oversized files because data-attachment-v3.service.ts trusts the remote server's advertised content length. Attackers can point the v3 upload-by-URL endpoint at a server that understates or omits its length to exhaust disk space or storage quota. |
| vLLM 0.30.0 before 0.31.0 contains a resource exhaustion vulnerability in OpenCVDynamicOpenPanguVideoBackend, which uses request-controlled num_frames without an effective ceiling. Unauthenticated attackers can send /v1/chat/completions or /tokenize requests selecting the openpangu video_backend with a huge num_frames, forcing np.linspace allocations and CPU work that OOM-kill the API server. |
| vLLM from 0.24.0 before 0.31.0 contains a resource exhaustion vulnerability in the MiniMax M3 VL video processor, which accepts request-level min_pixels without range or min_pixels <= max_pixels validation. Its video-wide pixel budget is enforced only when max_long_side_pixel is set, and that value defaults to None. API clients can supply a large min_pixels via mm_processor_kwargs to enlarge every decoded frame, causing excessive CPU and host-memory consumption that may disrupt workers or the service. |
