Authenticated SQL injection in MISP exposes threat intel data

At a glance

What this is: This is a threat research write-up on CVE-2026-44381, an authenticated SQL injection in MISP’s event index flow that can leak threat intelligence data through boolean-blind and time-based oracles.

Why it matters: It matters because threat intelligence platforms often sit close to sensitive indicators, internal investigations, and sharing workflows, so an injection flaw can turn ordinary analyst access into unintended data exposure.

Context

SQL injection remains a control failure, not just a code defect: when user-controlled input reaches query structure, an application can expose data even if the attacker is already authenticated. In a threat intelligence platform, that risk is sharper because the system stores high-value indicators, reports, and relationship data that should not be broadly readable.

This case sits at the intersection of application security and identity governance. Authenticated access is not the same as authorised access to every query path, and the problem is compounded when analyst workflows rely on shared or inherited permissions. The relevant guardrail is to treat query construction and access boundaries as separate controls, not as the same problem.

Key questions

Q: What fails when an authenticated search parameter can alter SQL structure?

A: The failure is a trust boundary collapse between application authentication and database authorisation. A logged-in user should not be able to reshape a query in ways that expose additional rows, fields, or timing signals. When structural parameters are injectable, the system treats user input as part of the query plan, which turns ordinary access into a data disclosure path.

Q: Why does SQL injection still matter when authentication is already in place?

A: Authentication does not protect an application that can be tricked into issuing malicious SQL on behalf of a logged-in user or service account. Once the query is altered, the attacker inherits the application’s effective database permissions. That means weak query handling can bypass otherwise sound login controls and expose sensitive data or alter 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. 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 prioritise query parameterisation or database privilege reduction first?

A: They should do both, but privilege reduction is the faster containment step when a vulnerable query path already exists. Parameterisation removes the injection mechanism, while least-privilege database rights limit blast radius if a flaw remains. For platforms handling sensitive intelligence or operational data, leaving either control incomplete preserves avoidable exposure.

Technical breakdown

How ORDER BY injection turns a search endpoint into an oracle

ORDER BY injection occurs when an application allows attacker-influenced values to affect sorting logic inside a SQL statement. Unlike simple value injection, this pattern often survives basic filtering because the attacker is not breaking syntax directly but manipulating how the database evaluates ordering, comparisons, or expressions. In MISP’s case, the event index request path creates a query surface where the attacker can infer data through boolean-blind differences or timing changes rather than visible errors. That makes the flaw harder to spot in logs and harder to catch with superficial input validation. Practical implication: separate user input from any SQL clause that can change query structure, not just WHERE conditions. See the SQL Injection Prevention Guide.

Practical implication: block user influence over SQL clause construction and review every search and sort parameter as executable query logic.

Why authenticated access does not neutralise SQL injection risk

Authenticated SQL injection is especially dangerous because the security assumption shifts from external attacker to trusted user, and that trust often lowers scrutiny. But SQL injection does not require unauthenticated access to be harmful. If the application lets a logged-in user shape database queries, the attacker can still extract records, enumerate fields, or pivot into administrative data depending on the privilege of the backend account. In platforms that support collaboration or incident sharing, this can collapse tenancy or role boundaries if the application-level controls are weak. Practical implication: treat authenticated injection flaws as privilege boundary failures, not as lower-severity edge cases. See the IAM and Identity Provider Buyer's Guide.

Practical implication: scope backend database privileges tightly and assume any authenticated injection path can become a data disclosure event.

Boolean-blind and time-based extraction show a control gap in detection

Boolean-blind SQL injection works by comparing responses that differ only when a predicate evaluates true or false. Time-based extraction works by forcing the database to delay one branch of a condition so the attacker can infer hidden values from response latency. Both techniques are effective when the application returns stable responses and the database accepts attacker-shaped expressions. They also bypass many content-based filters because the payload may never need to display the stolen data directly. For defenders, that means generic WAF signatures are not enough if the vulnerable query path still exists. Practical implication: monitor for anomalous latency, repeated parameter variation, and response-differential probing on high-value search endpoints. See the Web Application Attacks Guide.

Practical implication: instrument query latency and repeated probing patterns on sensitive endpoints instead of relying on payload signatures alone.

Threat narrative

Attacker objective: The attacker aims to extract sensitive threat intelligence records or platform data from MISP without needing direct database access.

1. Entry occurs through an authenticated POST request to MISP’s event index endpoint, where the attacker can influence the ORDER BY parameter.
2. Credentialed access to the application is then used to steer database query logic and extract information through boolean-blind or time-based responses.
3. The attacker can infer sensitive threat intelligence data from the platform without needing direct result-set visibility, undermining confidentiality and trust in shared intelligence workflows.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

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

Authenticated access is not a substitute for query trust. This case shows how application-layer authentication can coexist with a broken authorisation boundary inside the database layer. When the query itself becomes attacker-influenced, the control failure is not just SQL injection but an assumption that logged-in users should be trusted to shape query structure. Practitioners should treat authenticated injection paths as governance failures across both application security and data access control.

Threat intelligence platforms deserve stricter query governance than ordinary web apps. MISP stores indicators, incident context, and sharing data that can carry operational sensitivity far beyond a typical CRUD application. That means the security model has to account for analyst collaboration, inherited visibility, and backend privilege scope at the same time. A platform that supports intelligence exchange but allows query manipulation is exposing the wrong layer of trust.

Blind extraction is a detection problem, not only a patching problem. Boolean-blind and time-based SQL injection often produce subtle signals rather than obvious crashes or alerts. That makes anomaly detection around latency, repetition, and parameter variation part of the control surface. For security teams running threat-sharing systems, the issue is not merely whether the flaw exists, but whether monitoring can recognise exploitation before sensitive records are enumerated.

Query parameterisation is the right named concept here because the flaw sits in a structural trust decision. The issue is not simply unsafe input handling, but the decision to let a user-controlled sort parameter influence SQL logic. That design choice creates a durable attack path even in authenticated contexts. Practitioner conclusion: review every endpoint where user input can alter SQL clauses, not only those that return data directly.

Identity boundaries still matter in non-human systems. Although the article is about application vulnerability research, the governance lesson is identity-adjacent: authenticated sessions, service accounts, and analyst roles all rely on the assumption that backend actions stay within intended scope. When query logic can be steered, the application effectively expands the caller's reach beyond the permissions the interface was meant to express. Practitioners should align application authorization checks with database privilege design.

What this signals

Query parameterisation debt: the longer a platform allows user-controlled sort and filter fields to shape SQL logic, the more likely that an authenticated flaw becomes a data disclosure event. The governance problem is not only code quality but the persistence of structural trust in endpoints that should never accept executable query choices.

Threat intelligence platforms deserve the same access scepticism practitioners already apply to privileged admin tooling. Once analysts, integrations, and service accounts can reach sensitive datasets through dynamic query paths, the programme needs stronger separation between identity, application logic, and data-layer privilege. The next control question is whether monitoring can see blind exploitation before intelligence data is enumerated.

For practitioners

• Lock down SQL clause construction Remove user influence from ORDER BY and similar structural SQL elements, then review every endpoint that dynamically builds queries from request parameters.
• Reduce backend database privileges Run the MISP application with the minimum database rights needed for its actual query set, so an injection path cannot expose broader tables or administrative data.
• Add latency and repetition monitoring Alert on repeated parameter variation, unusual response timing, and probing of sensitive search endpoints that could indicate boolean-blind or time-based extraction.
• Review trust boundaries in analyst workflows Check whether shared roles, inherited access, or broad analyst permissions make a successful injection more damaging than the endpoint alone suggests.
• Test high-value endpoints for blind injection Use controlled validation on event search and sort paths to confirm whether response differences or timing changes can be weaponised for extraction.

Key takeaways

• The core issue is not just SQL injection, but the collapse of a query trust boundary inside an authenticated threat intelligence workflow.
• Blind extraction techniques can expose sensitive platform data without obvious errors, so exploitation may look like normal application use unless telemetry is tuned for it.
• Limiting database rights and removing user control over SQL structure are the controls most likely to contain the damage if this flaw appears in production.

Related NHI Mgmt Group resources: SQL Injection Prevention Guide · IAM and Identity Provider Buyer's Guide · Workforce Identity Security Guide · Breach and Attack Simulation (BAS) Guide

Key terms

• Unauthenticated SQL Injection: An unauthenticated SQL injection is a flaw that lets an external attacker alter database queries without logging in. It usually appears where application code accepts user input and passes it into query-building logic without strict validation or parameterization.
• Boolean-Blind Oracle: A response pattern that reveals hidden database information through differences in true-or-false outcomes rather than direct output. Attackers use repeated requests and compare small response changes to infer data without seeing the actual records returned.
• Time-Based Oracle: A side channel where query timing reveals whether a condition evaluated in a certain way. If an application or database responds more slowly when a predicate is true, an attacker can extract information by measuring latency across many requests.
• Query Parameterization: Query parameterization is a safe way to build dynamic database queries by separating the query structure from the supplied values. It prevents attackers from changing the meaning of SQL statements, including clauses that would otherwise expose data, alter records, or execute unintended commands.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.