Threat Intelligence Database
Comprehensive database of the latest cyber threats affecting organizations worldwide. Filter and search to find specific threat intelligence relevant to your organization.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threat Intelligence
Click on any threat for detailed analysis and mitigation recommendations
0 phpMyFAQ versions 4.1.0 through 4.1.10 contain a missing authorization vulnerability in the MCP server's faq_search tool. This flaw allows MCP clients to bypass user and group permission checks when performing search queries, enabling unauthorized reading of restricted FAQs. The vulnerability arises because the Search::searchDatabase() function does not enforce access controls. The issue has a medium severity rating with a CVSS score of 4.8. Join the discussion | CVE Database V5 | 10/11/2026, 15:31:07 UTC Added: 10/11/2026, 13:49:05 UTC |
0 phpMyFAQ versions prior to 4.1.6 contain an SQL injection vulnerability in the StopWords::add() method. This method improperly constructs an SQL INSERT statement by directly embedding user-supplied input without proper escaping. An authenticated administrator with access to the stop-word management feature can exploit this flaw to inject arbitrary SQL commands. The vulnerability is fixed in version 4.1.6. Join the discussion | CVE Database V5 | 09/24/2026, 16:35:02 UTC Added: 09/24/2026, 16:48:27 UTC |
phpMyFAQ is an open source FAQ web application. Versions 3.2.0 through 4.1.5 contain an authentication bypass in its public two-factor authentication verification flow: an unauthenticated attacker can submit an account’s numeric user ID and a valid or brute-forced six-digit TOTP code without first authenticating with the account password, allowing takeover of any 2FA-enabled account, including administrator accounts. Version 4.1.6 is patched by binding TOTP verification to a session established after successful password authentication and limiting failed TOTP attempts. No official workaround is documented; affected installations should upgrade to 4.1.6 or later. Join the discussion | CVE Database V5 | 09/24/2026, 14:59:35 UTC Added: 09/24/2026, 15:18:23 UTC |
0 phpMyFAQ is an open source FAQ web application. A stored cross-site scripting (XSS) vulnerability in versions prior to 4.2.0-alpha allows any unauthenticated user (or low-privileged registered user) to inject arbitrary JavaScript that executes in an administrator's browser when they review or edit a user-submitted FAQ entry. This leads to admin account takeover via session theft. The vulnerability exists because `html_entity_decode()` converts HTML entities into executable HTML after `strip_tags()` has already passed them through, and the admin template renders the content with Twig's `|raw` filter without any output sanitization. Version 4.2.0-alpha fixes the issue. Join the discussion | CVE Database V5 | 09/24/2026, 14:21:17 UTC Added: 09/24/2026, 14:49:17 UTC |
0 phpMyFAQ versions prior to 4.1.7 contain a missing authorization vulnerability where parent FAQ visibility checks are not enforced before returning child resources such as comments and attachments. This allows unauthenticated attackers to access restricted comment text, commenter email addresses, and attachment filenames for FAQ entries they cannot directly access. Join the discussion | CVE Database V5 | 08/19/2026, 14:02:00 UTC Added: 08/19/2026, 14:23:50 UTC |
phpMyFAQ versions before 4.1.7 have an authentication bypass vulnerability due to failure to persist the WebAuthn login challenge. This allows an attacker who captures a valid WebAuthn assertion to replay it indefinitely and authenticate as the user without interaction or hardware key. Join the discussion | CVE Database V5 | 08/19/2026, 14:01:59 UTC Added: 08/19/2026, 14:23:50 UTC |
0 phpMyFAQ versions before 4.1.7, when using the native pgsql PHP extension for PostgreSQL, improperly handle wildcard escaping in SQL LIKE queries. This flaw allows unauthenticated attackers to submit wildcard characters in the public FAQ search form, causing broad pattern matches and expensive sequential scans that can lead to denial of service. The issue does not affect the PDO PostgreSQL backend and does not enable SQL injection or data exfiltration. Join the discussion | CVE Database V5 | 08/19/2026, 14:01:58 UTC Added: 08/19/2026, 14:23:50 UTC |
0 phpMyFAQ versions before 4.1.7 have a missing authorization vulnerability in the admin API read endpoints related to LDAP, Elasticsearch, OpenSearch, and dashboard configuration. This flaw allows any authenticated user to access sensitive administrative data without proper permission checks. Exploitation can reveal LDAP server topology, bind account names, search bases, index statistics, and site analytics. Join the discussion | CVE Database V5 | 08/19/2026, 14:01:57 UTC Added: 08/19/2026, 14:23:50 UTC |
phpMyFAQ versions before 4.1.6 have a vulnerability where HTML in FAQ answers is not properly sanitized before generating PDFs using TCPDF. An attacker with permission to create or edit FAQ content can embed an <img> tag referencing local files under the web root's content/ directory. When the PDF is generated, phpMyFAQ tries to read the referenced file, causing an error that results in an uncaught exception. This exception discloses part of the file's contents in the stack trace to any user triggering the PDF export. The disclosed content is truncated by default but can be configured to reveal entire files, including sensitive data like database credentials. Join the discussion | CVE Database V5 | 08/19/2026, 14:01:57 UTC Added: 08/19/2026, 14:23:50 UTC |
0 phpMyFAQ versions 3.1.0 through 4.1.6 contain an authentication bypass vulnerability in AuthLdap::create(). When LDAP authentication is enabled, after a successful LDAP bind the code calls User::setStatus('active') unconditionally, which overwrites the account_status column of a pre-existing local account from 'blocked' to 'active'. As a result, a user whose local phpMyFAQ account has been administratively blocked can restore their account and log in by authenticating via LDAP. The state transition is not logged, so administrators cannot detect that the block was overridden. Fixed in 4.1.7. Join the discussion | CVE Database V5 | 08/19/2026, 14:01:55 UTC Added: 08/19/2026, 14:23:50 UTC |
Showing 1 to 10 of 44 results