CVE-2026-43967 absinthe-graphql CVE debrief

Who should care

Teams running Elixir applications that expose Absinthe GraphQL endpoints, especially where clients can submit arbitrary GraphQL documents. Security and platform owners should prioritize this if the service is internet-facing or accepts untrusted query bodies.

Technical summary

The affected phase is `Elixir.Absinthe.Phase.Document.Validation.UniqueFragmentNames`: `run/2` iterates over fragments and calls `duplicate?/2`, which performs `Enum.count(fragments, &(&1.name == name))`. Because that count is a linear scan repeated for each fragment, validation cost grows as O(N²) for attacker-controlled `input.fragments`. The supplied advisory states the issue affects absinthe from 1.2.0 before 1.10.2 and can be reached unauthenticated through the query body.

Defensive priority

High. The flaw is network-reachable, requires no authentication, and can produce disproportionate CPU consumption from a single request, making it suitable for denial-of-service pressure on exposed GraphQL services.

Recommended defensive actions

• Upgrade Absinthe to 1.10.2 or later.
• Confirm the deployed package version matches the fixed range in the advisory and commit reference.
• Review GraphQL ingress controls for maximum document size and request rate limiting.
• Monitor CPU spikes and validation latency on GraphQL endpoints for unusually large or fragment-heavy documents.
• Treat unauthenticated GraphQL query submission as a denial-of-service attack surface and harden edge protections accordingly.

Evidence notes

This debrief is based on the supplied CVE description and official references: the ERLEF CNA page, the Absinthe GitHub commit, the GitHub security advisory, and the OSV record. NVD lists the CVE as "Undergoing Analysis" at the time of the source item. The vendor attribution in the supplied corpus is low confidence, so the product name Absinthe is used directly rather than a broader vendor claim.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.