CVE-2025-50979: NodeBB · SQL Injection
Source CVE Database V5
Not known to be exploited · CVSS 8.6 High.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 9.7% chance of exploitation in 30 days – higher than 95% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 27 Aug 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
Immediate mitigation should focus on patching or upgrading NodeBB to a version where this vulnerability is fixed once available. In the absence of an official patch, organizations should implement strict input validation and sanitization on the search query parameter at the application or web server level to block suspicious payloads. Employing Web Application Firewalls (WAFs) with custom rules to detect and block SQL injection patterns targeting the /api/v3/search/categories endpoint can reduce risk. Restricting direct database access and enforcing least privilege principles on database users can limit the impact of a successful injection. Monitoring logs for unusual query patterns or error messages related to PostgreSQL can help detect exploitation attempts early. Additionally, organizations should conduct security assessments and penetration testing focused on API endpoints to identify and remediate injection flaws proactively.
Description
NodeBB v4.3.0 is vulnerable to SQL injection in its search-categories API endpoint (/api/v3/search/categories). The search query parameter is not properly sanitized, allowing unauthenticated, remote attackers to inject boolean-based blind and PostgreSQL error-based payloads.