CVE-2026-43053

MEDIUMNVD 4.74.7
EchelonGraph scoreMEDIUM confidence

Score 4.7 from GitHub Security Advisory published 2026-05-01. NVD baseline CVSS 4.7; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, nvd
Trending — 3 sources updated this week
4.7
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: 0%CVSS: 4.7Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

In the Linux kernel, the following vulnerability has been resolved:

xfs: close crash window in attr dabtree inactivation

When inactivating an inode with node-format extended attributes, xfs_attr3_node_inactive() invalidates all child leaf/node blocks via xfs_trans_binval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfs_attr_inactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers.

However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlog_recover_process_iunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure:

XFS (pmem0): Metadata corruption detected at xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78 XFS (pmem0): Unmount and run xfs_repair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117

Fix this in two places:

In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfs_da3_node_verify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state.

In xfs_attr_inactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation.

CVSS v3
4.7
EG Score
4.7(medium)
EG Risk
26(Track)
EG Risk 26/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity47% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS
0.1%
KEV
Not listed

Published

May 1, 2026

Last Modified

May 7, 2026

Vendor Advisories for CVE-2026-43053(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Patch Availability(1)

Vendor / EcosystemFixed in / PatchReleasedSource
linuxKernel @ 6.19.12osv

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 3× in last 7d / 10× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-23 03:13 UTCEG score recompute
  2. 2026-07-22 14:08 UTCEPSS rescore
  3. 2026-07-19 19:18 UTCOSV refresh
  4. 2026-07-12 05:46 UTCEPSS rescore
  5. 2026-07-08 15:16 UTCEPSS rescore
  6. 2026-07-07 13:46 UTCEPSS rescore
  7. 2026-07-05 02:30 UTCEPSS rescore
  8. 2026-07-01 15:06 UTCEPSS rescore
  9. 2026-06-28 04:56 UTCEPSS rescore
  10. 2026-06-23 21:33 UTCEPSS rescore
  11. 2026-06-18 17:52 UTCEPSS rescore
  12. 2026-06-18 17:52 UTCEPSS rescore
  13. 2026-06-17 17:53 UTCEPSS rescore
  14. 2026-06-15 17:49 UTCEPSS rescore
  15. 2026-06-14 08:49 UTCGHSA enrichment
  16. 2026-06-13 23:00 UTCEPSS rescore
  17. 2026-06-12 23:12 UTCEPSS rescore
  18. 2026-06-12 23:12 UTCEPSS rescore
  19. 2026-06-12 08:53 UTCGHSA enrichment
  20. 2026-06-11 14:00 UTCEPSS rescore
  21. 2026-06-11 09:06 UTCGHSA enrichment
  22. 2026-06-10 22:18 UTCEPSS rescore
  23. 2026-06-10 13:22 UTCEPSS rescore
  24. 2026-06-10 13:22 UTCEPSS rescore
  25. 2026-06-10 09:22 UTCGHSA enrichment
Show 39 more
  1. 2026-06-09 09:40 UTCGHSA enrichment
  2. 2026-06-08 14:17 UTCEPSS rescore
  3. 2026-06-08 14:17 UTCEPSS rescore
  4. 2026-06-08 08:55 UTCGHSA enrichment
  5. 2026-06-07 09:13 UTCGHSA enrichment
  6. 2026-06-06 13:47 UTCEPSS rescore
  7. 2026-06-06 13:47 UTCEPSS rescore
  8. 2026-06-06 09:30 UTCGHSA enrichment
  9. 2026-06-05 22:47 UTCEPSS rescore
  10. 2026-06-05 09:49 UTCGHSA enrichment
  11. 2026-06-05 06:10 UTCEPSS rescore
  12. 2026-06-05 06:10 UTCEPSS rescore
  13. 2026-06-04 13:12 UTCEPSS rescore
  14. 2026-06-04 13:12 UTCEPSS rescore
  15. 2026-06-04 09:45 UTCGHSA enrichment
  16. 2026-06-03 10:01 UTCGHSA enrichment
  17. 2026-06-02 20:13 UTCEPSS rescore
  18. 2026-06-02 10:03 UTCGHSA enrichment
  19. 2026-06-01 13:52 UTCEPSS rescore
  20. 2026-06-01 13:52 UTCEPSS rescore
  21. 2026-06-01 10:20 UTCGHSA enrichment
  22. 2026-05-31 22:30 UTCEPSS rescore
  23. 2026-05-31 22:30 UTCEPSS rescore
  24. 2026-05-31 00:16 UTCEPSS rescore
  25. 2026-05-31 00:16 UTCEPSS rescore
  26. 2026-05-29 13:44 UTCEPSS rescore
  27. 2026-05-29 13:44 UTCEPSS rescore
  28. 2026-05-28 13:44 UTCEPSS rescore
  29. 2026-05-28 13:44 UTCEPSS rescore
  30. 2026-05-27 13:40 UTCEPSS rescore
  31. 2026-05-27 13:40 UTCEPSS rescore
  32. 2026-05-26 13:44 UTCEPSS rescore
  33. 2026-05-26 07:18 UTCEPSS rescore
  34. 2026-05-20 22:38 UTCEPSS rescore
  35. 2026-05-20 22:38 UTCEPSS rescore
  36. 2026-05-20 14:50 UTCEG score recompute
  37. 2026-05-20 14:49 UTCGHSA enrichment
  38. 2026-05-20 11:22 UTCEPSS rescore
  39. 2026-05-20 11:22 UTCEPSS rescore

Frequently asked(5)

What is CVE-2026-43053?
CVE-2026-43053 is a medium vulnerability published on May 1, 2026. In the Linux kernel, the following vulnerability has been resolved: xfs: close crash window in attr dabtree inactivation When inactivating an inode with node-format extended attributes, xfsattr3node_inactive() invalidates all child leaf/node blocks via xfstransbinval(), but intentionally does not…
When was CVE-2026-43053 disclosed?
CVE-2026-43053 was first published in the National Vulnerability Database on May 1, 2026, with the most recent update on May 7, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-43053 actively exploited?
CVE-2026-43053 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.1% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
What is the CVSS score of CVE-2026-43053?
CVE-2026-43053 has a CVSS v3 base score of 4.7 (NVD).
How do I remediate CVE-2026-43053?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-43053, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-43053

Explore →

Is Your Infrastructure Affected by CVE-2026-43053?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.