MISP SQL injection exposed API keys and threat intelligence

At a glance

What this is: This is a vulnerability analysis showing how authenticated SQL injection in MISP’s event listing endpoint could expose stored API keys, threat intelligence, and database internals.

Why it matters: It matters because threat-intelligence platforms concentrate high-value non-human credentials and sensitive data, so a single input-validation flaw can become an identity, access, and exposure issue for analysts, integrations, and automation.

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.

Context

MISP is a threat-intelligence platform, so its security boundary includes both data sensitivity and the identity material used to access that data. When API keys and analyst workflows are tied to the same interface, a single authenticated flaw can become a cross-account exposure path rather than a narrow application bug.

This vulnerability shows why validation at the request layer is not enough when user-controlled sorting logic reaches the database unsafely. In platforms that store indicators, event notes, and API credentials together, SQL injection can expose non-human identities as readily as it exposes records.

Key questions

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. In practice that means injected SQL can manipulate result logic, leak rows through side effects, and bypass the assumptions that input filtering was supposed to enforce.

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. If an attacker can read those tables, they can reuse the recovered secrets or API keys to impersonate users, including privileged accounts, without needing to crack passwords or defeat interactive login controls.

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. Web application firewalls, input validation and prepared statements reduce exposure, but logs still matter for spotting probing and exploitation. Correlate spikes in failed requests, odd payloads and database errors with affected endpoints and user sessions.

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.

Technical breakdown

How ORDER BY injection works in an authenticated API flow

The flaw sits in the sort parameter of the POST /events/index endpoint, where attacker-controlled input reaches the SQL ORDER BY clause without a field whitelist. Even when quotes and commas are blocked, permissive character allowlists can still allow subqueries, functions, and parentheses that alter query execution. In this case, the attacker can turn sorting logic into a database execution primitive while remaining inside an authenticated request path. See the SQL Injection Prevention Guide.

Practical implication: Validate sort fields against an explicit whitelist before query construction, not after partial character filtering.

How boolean-blind and time-based extraction turn a query into an oracle

Boolean-blind SQL injection relies on observable differences in application behaviour, here HTTP 200 versus HTTP 500, to infer whether a condition is true or false. Time-based injection adds a second channel by using SLEEP to measure whether injected SQL executed. Together, these techniques let an attacker recover arbitrary strings one character at a time from any table the database user can read, even when direct query output is never returned.

Practical implication: Treat differential responses and timing variance as exploitation signals and look for them in logs, reverse proxies, and WAF telemetry.

Why exposed API keys turn database read access into platform takeover

In MISP, API authkeys are themselves non-human identities with account-level authority. If the users table is readable through SQL injection, recovered authkeys can be reused to impersonate other users, including privileged administrators, without password theft or interactive compromise. That means the real asset at risk is not just the database row but the delegated trust represented by each key. See the API Key Management Guide.

Practical implication: Manage API keys as high-value credentials with inventory, rotation, scope review, and rapid revocation when exposure is suspected.

Threat narrative

Attacker objective: The attacker aims to extract stored API keys and sensitive intelligence data, then reuse those keys to expand access across the platform.

1. Entry occurs through an authenticated POST /events/index request, where the attacker controls the order parameter in the event listing query.
2. Credential and data harvesting follow because injected SQL can read any table accessible to the MISP database user, including users.authkey and event records.
3. Escalation happens when extracted API keys are reused to impersonate other accounts, including administrative identities, across the platform.
4. Impact is full compromise of the MISP installation’s threat intelligence, user credentials, and trusted synchronization relationships.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

API keys in a threat-intelligence platform are non-human identities, not mere access tokens: once the database can expose the users table, the blast radius includes account impersonation, privilege reuse, and lateral movement between analysts, automations, and administrators. That makes non-human identity governance directly relevant, because key inventory and revocation are part of the security model, not an afterthought. The practical conclusion is simple: if keys can be read from a backend table, the identity architecture has already failed.

Boolean-blind SQL injection remains operationally dangerous even when direct exfiltration is blocked: the HTTP 200 versus HTTP 500 oracle and the SLEEP timing channel give attackers a reliable extraction path under noisy conditions. This is where detection has to look beyond payload signatures and into behaviour, including repeated probes, timing deltas, and systematic enumeration patterns. Security teams should treat query-behaviour telemetry as part of application defence, not just a SOC concern.

Threat-intelligence platform exposure: the specific failure mode is the collapse of trust between a shared intelligence database and the credentials that protect it. MISP deployments often combine sensitive indicators, analyst annotations, and API credentials in one system, so a database read flaw becomes both a data breach and an identity breach. Practitioners should design for compartmentalisation, because a shared store amplifies the consequences of any one injection point.

The wider lesson is about delegated trust in security tooling: many teams distribute API keys broadly to analysts, integrations, and automation because the workflow demands it. That convenience becomes risk when the platform itself lets one authenticated user mine the credentials of others. The governance implication is that privilege scope, key issuance, and backend query safety have to be managed together, not as separate controls.

What this signals

Shared threat-intelligence platforms create concentrated identity risk: when analysts, automation, and partner feeds all depend on the same backend, a single injection flaw can expose both content and credentials. The security lesson is that platform convenience increases the value of backend query safety, compartmentalised access, and key lifecycle control.

Privilege amplification starts with delegated access, not with admin compromise: once a platform stores reusable API keys in readable tables, the attacker does not need to steal a password to expand access. The governance problem is the assumption that API keys are merely transport credentials, when in practice they are account-level authority embedded in machine workflows.

Query-behaviour monitoring should become part of application defence: repeated probing, timing deltas, and error-based oracles are observable before data extraction is complete. Teams that already monitor for unusual API use should extend that discipline to parameter patterns and response anomalies, because the attack surface here is both data and identity.

For practitioners

• 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. See the API Key Management Guide.
• 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.
• Restrict distribution of high-privilege automation keys Limit API key issuance to documented business need and remove shared keys from analyst tools, integrations, and automation jobs that do not require them.

Key takeaways

• The vulnerability shows how unsafe query construction in a threat-intelligence platform can expose both sensitive records and the machine credentials that protect them.
• Safe Security’s analysis ties the issue to authenticated SQL injection, with API keys and database internals among the exposed assets.
• Whitelisting query fields, rotating exposed API keys, and monitoring for oracle-style request patterns are the controls that most directly limit this failure mode.

Related NHI Mgmt Group resources: API Key Management Guide · Ultimate Guide to NHIs: What are Non-Human Identities · Vulnerability Management Guide · SOC Guide

Key terms

• Blind SQL Injection: Blind SQL injection is a variant where the application does not return obvious database output or errors, so the attacker infers information from timing or true-false response differences. It is harder to spot and often requires behaviour-based detection.
• Order by injection: A form of SQL injection where user-controlled sort input is inserted into an ORDER BY clause without strict validation. Even when obvious characters are filtered, subqueries or functions may still alter execution, making a seemingly low-risk sorting field into a data-extraction path.
• API authkey: An API authkey is a machine credential used to authenticate automated or programmatic access to a platform. In practice it behaves like a non-human identity, so compromise or disclosure can grant account-level access and may require the same urgency as a password reset or token revocation.
• Threat Intelligence Platform (TIP): A Threat Intelligence Platform (TIP) is a system for collecting, normalising, enriching, and sharing threat intelligence across security teams and tools. It helps analysts manage indicators, context, and prioritisation, but poor curation can flood detections with stale or low-value data. Defenders should track source quality, expiry, and analyst feedback.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is relevant when teams need to connect identity lifecycle controls to platform and automation risk.