Topic starter
25/10/2026 11:11 am
TL;DR: An authenticated MISP user could turn the events listing order parameter into SQL injection and expose stored API keys, event data, and database internals, according to Safe Security. That makes query whitelisting and key rotation part of platform governance, not just coding hygiene.
Editorial analysis by NHI Mgmt Group, based on content published by Safe Security: “CVE-2026-44381 MISP Threat Intelligence Platform Authenticated SQL Injection via ORDER BY Parameter POST /events/index — Boolean-Blind + Time-Based Oracle”.
By the numbers:
- over 6,000 organizations worldwide use MISP, including national CERTs, financial sector ISACs, government agencies, and security operations teams.
- CVE-2026-44381 is rated MEDIUM with a CVSS 5.3 score.
Key questions
Q: Why does a read-only SQL injection path still create account takeover risk in shared platforms?
A: Because the database often stores credentials, tokens, and other delegated trust material alongside normal records.
Q: How can security teams detect SQL injection?
A: Security teams detect SQL injection by monitoring application and database logs for malformed queries, repeated syntax errors, unexpected query patterns and parameter abuse.
Q: What breaks when an authenticated API parameter reaches SQL ordering logic without a whitelist?
A: The application loses control of query structure, so an attacker can turn a harmless-looking sort field into a database execution primitive.
Practitioner guidance
- Whitelisting of all user-controlled sort fields Replace character allowlists with explicit field-name whitelists for every endpoint that maps request data into SQL ordering logic.
- Rotate and revoke exposed API authkeys Assume any authkey reachable through the affected database path may already be compromised, then issue new keys and revoke unused ones.
- Hunt for extraction and oracle patterns in logs Review requests to POST /events/index for parentheses, SELECT, SLEEP, information_schema, and hex literals, then correlate them with abnormal timing or error spikes.
Bottom line: The vulnerability shows how unsafe query construction in a threat-intelligence platform can expose both sensitive records and the machine credentials that protect them.
Glossary terms: Threat Intelligence Platform (TIP), Blind SQL Injection, Order by injection, API authkey
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:14 pm
ORDER BY validation failure is the core governance gap here: the vulnerable code trusted a user-controlled sort field after only superficial character filtering. That is not a syntax-sanitisation issue alone, it is a trust-boundary failure between application logic and SQL execution. In platforms that hold intelligence data and credentials together, any route that lets untrusted input shape query structure becomes a cross-domain exposure path. Practitioners should treat whitelist-based query construction as the minimum standard for sensitive platform interfaces.
A question worth separating out:
Q: Should organisations treat API keys in security tools as privileged identities?
A: Yes. In systems that expose sensitive intelligence or automation capabilities, API keys function as machine identities with real authority, so they need inventory, ownership, scope review, rotation, and rapid revocation. If a backend flaw can reveal those keys, the platform has crossed from application risk into identity governance failure.
👉 Read our full editorial: MISP SQL injection exposed API keys and threat intelligence
This post was modified 7 days ago by NHI Mgmt Group