Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,132 detections
Filters
Last updated
All Time
Detection languages
761
532
431
179
94
Contributors
499
335
285
191
168
Categories
1,525
1,087
390
369
240
Platforms
934
681
611
142
99
Products / Services
552
383
359
337
293
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
2,132
CVEs
51
50
44
42
29
IDS Classtypes
320
140
29
13
5
IDS Protocols
454
34
13
5
4
Detects HTTP POST requests to a Gitea repository's diffpatch API endpoint whose body contains both a real git diff header and the malicious 'hooks/post-index-change' file path used by the CVE-2026-60004 exploit chain to plant an executable Git hook via an add/add merge collision.
This rule detects potential exploitation attempts (CVE-2026-59822) against LiteLLM MCP tool endpoints. It identifies HTTP requests where the authorization bearer token is unusually short (<= 12 chars), lacks the 'sk-' prefix, and does not appear to be a valid JWT, yet successfully results in a 200 OK status, indicating a potential bypass of authentication logic.
This rule detects anomalous high-frequency, short-duration bursts of CAPWAP (Control and Provisioning of Wireless Access Points) traffic originating from external sources and targeting internal FortiGate devices. This behavior is indicative of automated exploitation attempts, specifically targeting known heap-grooming activities used in vulnerabilities like CVE-2023-27997, which rely on repetitive 'Add-Station' operations. Legitimate controller traffic is filtered by focusing on internal-to-internal communication patterns.
Detects requests to a LiteLLM proxy that have been assigned the 'PROXY_ADMIN' role despite the absence of valid authentication credentials (Authorization headers, JWT tokens, or OAuth2 tokens). This pattern typically indicates that the LiteLLM instance is misconfigured, specifically that a 'master_key' is missing, causing the proxy to default to a permissive mode where every request is treated as having administrative privileges.
Detects requests to a LiteLLM proxy that have been assigned the 'PROXY_ADMIN' role despite the absence of valid authentication credentials (Authorization headers, JWT tokens, or OAuth2 tokens). This pattern typically indicates that the LiteLLM instance is misconfigured, specifically that a 'master_key' is missing, causing the proxy to default to a permissive mode where every request is treated as having administrative privileges.
Detects requests to a LiteLLM proxy that have been assigned the 'PROXY_ADMIN' role despite the absence of valid authentication credentials (Authorization headers, JWT tokens, or OAuth2 tokens). This pattern typically indicates that the LiteLLM instance is misconfigured, specifically that a 'master_key' is missing, causing the proxy to default to a permissive mode where every request is treated as having administrative privileges.
Detects instances where a LiteLLM proxy is utilized to invoke sensitive Model Context Protocol (MCP) tools (e.g., database, github, slack, jira, ci/cd) while authentication is bypassed ('allow_all_keys=true') and no explicit API key is provided. This indicates a potential unauthorized access attempt to sensitive integrations via a misconfigured proxy.
Detects instances where a LiteLLM proxy is utilized to invoke sensitive Model Context Protocol (MCP) tools (e.g., database, github, slack, jira, ci/cd) while authentication is bypassed ('allow_all_keys=true') and no explicit API key is provided. This indicates a potential unauthorized access attempt to sensitive integrations via a misconfigured proxy.
Detects instances where a LiteLLM proxy is utilized to invoke sensitive Model Context Protocol (MCP) tools (e.g., database, github, slack, jira, ci/cd) while authentication is bypassed ('allow_all_keys=true') and no explicit API key is provided. This indicates a potential unauthorized access attempt to sensitive integrations via a misconfigured proxy.
Detects instances where a LiteLLM proxy is utilized to invoke sensitive Model Context Protocol (MCP) tools (e.g., database, github, slack, jira, ci/cd) while authentication is bypassed ('allow_all_keys=true') and no explicit API key is provided. This indicates a potential unauthorized access attempt to sensitive integrations via a misconfigured proxy.
Detects incoming HTTP requests to sensitive LiteLLM endpoints (/mcp and /guardrails) which are typically intended for internal or controlled use. Exposing these to the public internet may allow unauthorized individuals to interact with, enumerate, or exploit the LiteLLM framework's capabilities.
Detects the creation or update of LiteLLM custom code guardrails that include suspicious Python snippets, specifically 'import os' and 'os.popen', which are indicative of attempts to execute arbitrary OS commands via guardrail logic (CVE-2026-59821).
Detects the creation or update of LiteLLM custom code guardrails that include suspicious Python snippets, specifically 'import os' and 'os.popen', which are indicative of attempts to execute arbitrary OS commands via guardrail logic (CVE-2026-59821).
Detects network-based exploitation attempts against Dahua Easy4IP P2P relay infrastructure, including reconnaissance probes, unauthorized relay usage, and credential theft attempts via WSSE authentication.
Detects anomalous HTTP POST requests to the Keycloak '/login-actions/reset-credentials' endpoint that lack required action tokens (e.g., 'key=' or 'execution=' parameters). This behavior is indicative of an exploitation attempt targeting CVE-2026-18963, potentially aimed at bypassing authentication or triggering unauthorized credential reset flows.
This rule monitors for various types of events (user logons, network connections, API audits, cloud app events, and email traffic) originating from a specific CIDR block (160.79.104.0/21), which is flagged as suspicious or unauthorized.
Detects network connections from Windows hosts to known IP addresses and domain names associated with the exploitation infrastructure used in CVE-2026-18577, targeting N-able N-central servers.
This rule detects IDS/IPS or vulnerability management alerts triggered by exploitation attempts targeting the Cisco IOS XR control plane, specifically related to CVE-2026-20212.
This rule detects potential Server-Side Request Forgery (SSRF) activity where web application or runtime processes attempt to access the Cloud Instance Metadata Service (IMDS) or container task metadata endpoints. By monitoring network connections and application logs, the rule filters out known legitimate metadata clients and identifies suspicious processes frequently associated with web-based vulnerabilities that are repeatedly querying sensitive metadata paths.
Detects the initialization of containerized LLM-based gateway services (e.g., litellm, ollama) followed closely in time by high-volume network traffic containing suspicious web injection payloads (e.g., SQLi, XSS, SSRF). The rule correlates process execution events for container launches with network activity originating from the same device to identify potential unauthorized or unsupervised automated exploitation.
Detects instances where a development-oriented web server (such as Vite or Node.js) is configured to bind to all network interfaces ('0.0.0.0') and is simultaneously receiving inbound connections from non-private, external IP addresses on a common development port (5173). This rule filters out common CI/CD environments to focus on potentially insecure exposure of development tools to the public internet.
Page 37 of 102