Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,084 detections
Filters
Last updated
All Time
Detection languages
418
193
163
156
81
Contributors
381
251
92
71
40
Categories
498
271
255
135
123
Platforms
443
441
267
121
114
Products / Services
10,665
9,773
6,704
4,421
3,749
1,084
MITRE Techniques
278
229
180
177
151
CVEs
17
15
13
13
8
IDS Classtypes
4
IDS Protocols
4
Detects Ruby source files containing a hardcoded RubyGems API key (rubygems_ prefixed token) used for unauthorized gem publish/push actions, as seen in the yardxabc889 package from the GemStuffer campaign
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.
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 the use of the default, hardcoded 'sk-1234' secret key for HS256 JWT signing in LiteLLM proxy logs. This configuration is insecure and allows for the forgery of arbitrary user session tokens.
Detects the use of the default, hardcoded 'sk-1234' secret key for HS256 JWT signing in LiteLLM proxy logs. This configuration is insecure and allows for the forgery of arbitrary user session tokens.
Detects the use of the default, hardcoded 'sk-1234' secret key for HS256 JWT signing in LiteLLM proxy logs. This configuration is insecure and allows for the forgery of arbitrary user session tokens.
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).
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 text/report artifacts (markdown, JSON, plain text) produced by an autonomous AI-driven vulnerability research pipeline that decompiles binaries, traces cross-references, hypothesizes memory-safety flaws, and generates/debugs proof-of-concept exploits
Detects anomalous unauthenticated password reset requests targeting the Keycloak reset-credentials endpoint. The rule monitors for high-volume password reset attempts from single source IP addresses, specifically flagging those that target common administrative usernames or attempt to reset passwords across multiple distinct user accounts, which may indicate exploitation attempts (e.g., CVE-2026-18963).
This rule identifies successful user sign-ins (ResultType 0) originating from specific Autonomous System Numbers (197540, 216154) where Multi-Factor Authentication (MFA) was not required or not recorded, and where Conditional Access policies either did not apply or succeeded without enforcing MFA.
This rule identifies successful user sign-ins (ResultType 0) originating from specific Autonomous System Numbers (197540, 216154) where Multi-Factor Authentication (MFA) was not required or not recorded, and where Conditional Access policies either did not apply or succeeded without enforcing MFA.
Detects instances where the Grafana MCP (Model Context Protocol) server's service account identity executes administrative tools (such as 'grafana_api_request') within a session that lacks a verified, prior authentication event (bearer token). This pattern suggests an adversary may be spoofing or hijacking a privileged service account session to perform unauthorized administrative actions.
Detects changes to Keycloak realm configurations that enable the 'Forgot password' (resetPasswordAllowed) setting. This specific configuration change is associated with temporary mitigation strategies for CVE-2026-18963 on known-vulnerable versions of Keycloak.
Page 26 of 52