Skip to content

CVE-2026-53240

is CVE-2026-53240real, exploitable, or a false positive? Here's the community verdict.

signals

public sources

Exploited in wild
Not listed
CISA KEV
Base severity
8.8 High
CVSS
Exploitation prob.
0.2%
FIRST EPSS
Weakness
Not classified
CWE

High CVSS base score, but low real-world exploitation probability (EPSS). Likely less urgent than the score implies.

baseline read

auto · not a community verdict

Real, but low real-world risk

A genuine vulnerability on paper, but EPSS shows little real-world exploitation — the base score may overstate urgency. This is not the same as a false positive.

Based on CVSS · FIRST EPSS

Confirm or dispute →

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spin_unlock and this read, a concurrent CPU running iptfs_reassem_cont() (or the drop_timer hrtimer) can complete reassembly, NULL xtfs->ra_newskb, and free the skb. The check then evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb operate on the freed skb — a use-after-free in skbuff_head_cache. Replace the unlocked read with a local bool that records whether first_skb was handed to the reassembly state in the current call. The flag is set after the existing spin_unlock, before the break, using the pointer equality that is stable at that point (first_skb == skb iff first_skb was stored in ra_newskb).

Published

Embed this verdict
TruePositive verdict for CVE-2026-53240
Markdown
[![TruePositive verdict](https://www.truepositive.app/cve/CVE-2026-53240/badge.svg)](https://www.truepositive.app/cve/CVE-2026-53240)
HTML
<a href="https://www.truepositive.app/cve/CVE-2026-53240"><img src="https://www.truepositive.app/cve/CVE-2026-53240/badge.svg" alt="TruePositive verdict for CVE-2026-53240"></a>

Live badge that updates automatically as the community verdict changes.

Community ground truth

Be the first practitioner to weigh in

So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.

🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.

In your experience, is this finding real and exploitable?

0 verdicts
Not a real issue

No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.

Field notes & remediation

Verdicts are the quick signal. Notes are the evidence and fixes behind them.

No notes yet. Be the first to share what you saw, or a fix that worked.

    Add a field note or remediationoptional
    Note type

    What are you adding?

    Markdown supported · minimum 20 characters.