CVE-2026-2648 Heap Overflow in PDFium Fixed in Chrome 145

A newly disclosed high‑severity vulnerability in Chromium’s PDF rendering engine, PDFium, has been assigned CVE‑2026‑2648 and patched upstream in Chrome 145.0.7632.109 (and sibling builds). The flaw is a heap buffer overflow that — when triggered by a specially crafted PDF — can result in out‑of‑bounds writes and potentially enable remote code execution from a web context. Google’s February 18, 2026 Stable update lists the issue (reported by researcher soiax) among three security fixes in the release.

Background / Overview​

PDFium is Chromium’s bundled PDF renderer and is widely used across Chromium‑based browsers, including Google Chrome and Microsoft Edge (Chromium‑based). Because Chromium is an upstream open‑source project, security fixes made in Chromium are propagated into downstream browsers over time; Microsoft tracks these fixes and ingests relevant upstream patches into Edge, documenting ingestion status in its Security Update Guide and related channels. Administrators who run Edge should therefore treat Chromium CVEs as relevant to their environment and monitor Edge release notes and Microsoft’s update tracking for confirmation of ingestion.
The vulnerability’s public metadata is concise but consistent across multiple vulnerability databases: NVD describes CVE‑2026‑2648 as a heap buffer overflow in PDFium affecting Chrome versions prior to 145.0.7632.109, while several third‑party vulnerability trackers (Tenable, PT Security/dbugs, and others) report the CVSSv3 vector and high severity rating. The Chromium issue tracker reference (CRBug 477033835) is cited by public advisories as the upstream bug ID.

---

What the technical data says​

The defect class: heap buffer overflow (CWE‑122)​

A heap buffer overflow occurs when code writes more data to a heap‑allocated buffer than the memory reserved for it, or when indexing calculations permit writes outside the intended bounds. In sandboxed browsers the impact of such a defect depends on exploitability: a successful out‑of‑bounds write can corrupt adjacent heap metadata, function pointers, or other control structures that an attacker may leverage to alter program flow. PDFium runs inside the renderer process sandbox in Chromium, which limits but does not eliminate the severity of memory‑corruption bugs when complex parsing of untrusted PDF content is involved. The public advisories classify CVE‑2026‑2648 under CWE‑122.

Affected versions and fix build​

Google’s Chrome Releases entry for February 18, 2026 lists the fix in the Stable channel builds: 145.0.7632.109/110 for Windows and macOS (and corresponding 144.x Linux builds), and explicitly calls out [477033835] High CVE‑2026‑2648: Heap buffer overflow in PDFium, reported by soiax. NVD reiterates the “prior to 145.0.7632.109” affected version line. If your browsers are on earlier 145.x or any 144.x/earlier Chromium builds, they are within the vulnerable window until updated.

Severity and exploitability​

Public trackers and risk engines place CVE‑2026‑2648 at High severity. Several sources list a CVSS v3.x base around 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), indicating network‑deliverable attacks, no required privileges, user interaction required (e.g., the victim must open a crafted PDF or visit a page that triggers the PDF renderer), and high impacts to confidentiality/integrity/availability. These ratings are consistent across Tenable, PT Security, and other databases that aggregated the Chrome release data. There is no authoritative public indication — at the time of writing — of an exploit in the wild for this specific CVE; several vulnerability feeds state “no public exploit available.” That status should be treated as time‑sensitive and monitored closely.

Upstream traceability​

The Chromium issue tracker reference number included in vendor notes (CRBug 477033835) provides internal context for the patch; Chrome’s team often restricts detailed bug reports until a majority of users are protected. That practice is standard for memory‑corruption bugs that have significant exploit potential. The reduced public detail is a tradeoff between transparency and preventing pre‑patch exploitation.

---

Why this matters for Windows and enterprise Edge users​

• Microsoft Edge (Chromium‑based) builds its browser on Chromium source code; therefore, critical fixes in Chromium are relevant to Edge and must be ingested into Edge builds before Edge users are protected. Microsoft publicly tracks these ingestion events in the Security Update Guide and release notes, but ingestion can lag the upstream Chrome release by the time Microsoft performs its own build/test cycle and issues Edge updates. Enterprise patch cycles should therefore expect a brief, measurable delay between Google’s stable release and Edge’s corresponding update.
• PDF rendering remains a high‑value target for attackers: PDFs are common, contain complex binary and text structures, and are processed by large codebases that frequently expose subtle parsing bugs. A heap buffer overflow in PDFium can be exploited by attackers who can trick users into opening a malicious PDF, or by web content that forces the browser to load and render a hostile PDF payload — making the vulnerability relevant for both web browsing and file‑handling threat models.
• Enterprise controls that centralize PDF handling (for example, DLP scanners, secure document viewers, or gateway‑level PDF sanitizers) can reduce exposure during the window before endpoints are updated, but completeness depends on deployment and inspection capabilities.

---

Recommended immediate actions (desktop users and administrators)​

Apply the upstream guidance immediately: update browsers and validate ingestion for downstream products. Because this is a memory‑corruption issue in a widely used component, treat the CVE as high priority.

• Verify browser versions now:
• For Chrome: open Chrome → Help and feedback → About Google Chrome and confirm you are on 145.0.7632.109 (Windows/macOS) or later. Relaunch to finish installation if an update is pending.
• For Microsoft Edge: open Edge → Settings and more → Help and feedback → About Microsoft Edge to check the installed version; confirm Microsoft’s release notes state the Chromium fix has been ingested. Microsoft documents ingestion events in the Security Update Guide and Edge relnotes; administrators should consult those internal feeds and their patch management systems.
• Prioritize patch deployment:
• For single machines: update the browser immediately and restart.
• For enterprises: add the Chrome 145.0.7632.109/Edge equivalent to the highest‑priority patch window (out‑of‑band if possible). Test in a small pilot group, then push broadly after successful verification.
• Apply compensating controls while you patch:
• Block untrusted PDF downloads at the gateway, or force PDF rendering with a hardened, server‑side sanitizer.
• Configure endpoint protection to treat browser PDF rendering as high‑risk: enable EDR memory protection features and enable crash/behavior monitoring to detect suspicious renderer crashes.
• Reduce attack surface by disabling automatic opening of PDFs in the browser where operationally feasible, and require users to save and scan PDFs before opening. (This raises UX friction, so use selectively.)
• Monitor for exploit indicators:
• Watch public threat intelligence feeds, NVD/Tenable/PT/other trackers, and vendor advisories for proof‑of‑concept code or reports of exploitation.
• Incorporate detection rules in SIEM/EDR that look for anomalous renderer crashes or high rates of PDF parsing failures.

---

Enterprise patch guidance and timing considerations​

Patching a critical browser component in the enterprise includes more than flipping an update switch. The downstream ingestion model (Chromium → Browser vendors → Enterprise deployments) introduces an operational cadence:

• Google issues a Chromium/Chrome fix and publishes the Stable channel update. That update becomes the authoritative fix; Chrome users get patched quickly via the auto‑update mechanism.
• Microsoft performs its own testing, integrates the Chromium patch into an Edge build, and publishes Edge updates when ready; this creates the ingestion window that enterprises must track. The Microsoft Security Update Guide and Edge release notes are the authoritative sources to confirm whether Edge contains the Chromium fix.

Operational recommendations:

• Maintain a close patch‑testing pipeline that shortens the time from vendor release to enterprise deployment. Automate version checks and have a defined escalation path for High and Critical browser CVEs.
• Use canary/QA groups and feature flags where possible to validate the business impact of the updated browser builds before organization‑wide rollout.
• Ensure remote workers are prompted to restart their browsers; many fixes are downloaded automatically but not applied until the browser relaunches.

---

Attack surface and exploit scenarios​

The most likely exploitation path is social engineering or web drive‑by delivery where the attacker either convinces a user to open a malicious PDF or places a malicious PDF on a compromised or attacker‑controlled site that the victim visits. A crafted PDF triggers the overflow during parsing, and with a successful exploit chain the attacker might escape or subvert renderer sandboxing to run arbitrary code in the context of the user.
Key mitigations that limit exploit success include:

• Sandboxing and process isolation (already core parts of modern Chromium architecture).
• Control‑flow and memory safety hardening (e.g., Control Flow Integrity, ASLR, heap hardening) which raise the difficulty of reliable exploitation.
• EDR and exploit mitigation tooling that interrupt known exploitation patterns or lateral movement attempts that would follow a browser compromise.

Even with those mitigations, the presence of any heap overflow in a complex parser merits immediate treatment as a high‑risk problem until patches are applied.

---

What we know — and what remains uncertain​

What we know:

• CVE‑2026‑2648 is a heap buffer overflow in PDFium, fixed in Chrome 145.0.7632.109. The upstream Chromium issue ID and Chrome Releases entry list soiax as the reporter.
• Public vulnerability trackers consistently rate the flaw High (CVSS in the high‑8 range) and recommend updating to the fixed builds.
• There is, at the time of publication, no widely published exploit PoC or confirmed in‑the‑wild exploit for this specific CVE; several aggregators state “no public exploit available.” However, this is a live security situation and the status can change quickly.

What remains uncertain or purposely withheld:

• The Chrome team and many vendors withhold detailed exploitability specifics and proof code until the majority of users have updated to reduce the risk of active exploitation. That means the public technical details may be intentionally limited. If exploit code is developed privately or discovered in the wild, vendor advisories and security feeds will disclose it in follow‑on notifications.

Because of those uncertainties, defenders must assume worst‑case feasibility and act accordingly: patch quickly, apply temporary mitigations, and monitor for tradecraft that exploits PDF processing.

---

Practical mitigations beyond patching​

Short-term operational mitigations can reduce exposure while organizations complete patch testing and deployment.

• Gateway and proxy PDF inspection: configure web proxies or secure web gateways to inspect (or block) PDF content from untrusted sources and enforce download restrictions for PDFs from external domains.
• PDF sanitization/flattening: replace incoming PDFs with sanitized versions that strip dynamic features and scripts, or use server‑side renderers to convert PDFs to images before delivery to endpoints.
• Reduce browser PDF surface area: where possible, change browser settings to download PDFs by default instead of opening them in the in‑browser PDFium renderer, so documents can be scanned by AV/DLP systems first.
• Endpoint hardening: ensure EDR solutions have rules that flag unusual renderer process behavior or repeated PDF parsing errors; enable exploit mitigation features that prevent common heap‑spraying and ROP techniques.
• User awareness: alert users not to open unexpected PDFs and to validate attachments through secure channels before opening.

These mitigations are not replacements for the upstream fix but buy time for safe, tested rollouts in larger environments.

---

For developers and security teams: code‑level and forensic considerations​

• Developers who maintain PDF‑handling integrations or server‑side PDF tooling should audit libraries that rely on PDFium or similar PDF parsers. A variant of this bug or related parsing mistakes can appear in other PDF engines, so dependency tracking is critical.
• Forensic practitioners investigating suspected exploitation should capture renderer crash dumps, look for abnormal memory corruption and allocation patterns in the PDF parsing flow, and preserve logs showing downloads, navigations, and file accesses around the time of the crash.
• If you operate any PDF processing servers (e.g., OCR pipelines, document ingestion services), ensure they are updated and run with least privilege and strict sandboxing, because server‑side batches may process untrusted PDFs at scale.

---

How to confirm your environment is safe​

• Check browser versions on endpoints and servers. Confirm Chrome is at 145.0.7632.109 or later; for Edge, confirm Microsoft’s Edge relnotes or the Security Update Guide show ingestion and that your installed Edge build includes the relevant Chromium commit.
• Validate update application:
• For Chrome: visit About → confirm update applied and relaunch.
• For managed fleets: verify your update management system recorded the successful installation and relaunch cycles.
• Monitor vulnerability and threat feeds: subscribe to the NVD entry for CVE‑2026‑2648 and vendor advisories to receive changes in exploit status. NVD’s entry was published on February 18, 2026 and references Chrome’s release entry and the upstream issue tracker for traceability.
• Consider rolling out additional hardening for high‑risk user groups who frequently handle untrusted PDFs (legal, finance, HR) until the environment is systematically patched.

---

Strengths and limitations of the public disclosures​

Strengths:

• Google released a fixed build quickly and documented the CVE and affected build numbers in the Chrome Releases post; this transparency gives administrators an explicit version to target for remediation.
• Public trackers (NVD, Tenable, PT Security) aggregated the details and provided CVSS vectors that help organizations prioritize triage.

Limitations and risks:

• Limited public technical detail: as is standard for memory corruption bugs that could be exploited, detailed technical write‑ups and proof‑of‑concepts are withheld. That reduces immediate ability for defenders to write fine‑grained detections but is intended to reduce opportunity for adversaries.
• The ingestion lag for downstream browsers (notably Microsoft Edge) creates a short but real window where Chrome users might be patched but Edge users remain vulnerable until Microsoft’s builds include the fix and administrators deploy Edge updates. Enterprises must track vendor ingestion and test accordingly.

---

Recommended detection and post‑patch validation checklist​

• Confirm fixed build(s) installed and engines restarted.
• Validate there are no unexplained renderer crashes in your EDR or SIEM for 24–72 hours post‑patch in the environment.
• Run a targeted audit of inbound PDF handling: sample recent PDFs delivered via email and web to confirm gateway scanners and AV detect known manipulations and do not crash parsers.
• Update any internal CVE inventories and patch tickets with references to Chrome 145.0.7632.109 and the corresponding Edge build once Microsoft confirms ingestion.
• For high‑security environments, consider adding a short window of heightened monitoring for lateral movement and privilege escalation after patch deployment to detect limited exploitation attempts.

---

Final analysis — what organizations should do today​

Treat CVE‑2026‑2648 as a high‑priority remediation item: update affected browsers to the fixed Chromium builds (Chrome 145.0.7632.109 or later) and confirm ingestion and deployment for Microsoft Edge. Use compensating controls such as gateway PDF inspection, disabling in‑browser PDF rendering where feasible, and strengthening endpoint exploit mitigation while your patch program completes.
While current public sources report no known public exploit code, the vulnerability’s class (heap buffer overflow in a widely used parser) and replicated ratings (High / CVSS ~8.8) justify urgent action. Maintain a watch on the NVD entry and vendor advisories for any shifts in exploit status or the release of additional technical details, and keep update‑and‑restart processes automated where possible to close the window of exposure quickly.

---

CVE‑2026‑2648 is a timely reminder that even well‑maintained, sandboxed components require immediate attention when memory‑corruption bugs surface. Rapid patching, sensible mitigations, and operational readiness to respond to downstream ingestion windows will be the decisive controls that protect users and organizations from attackers seeking to weaponize complex document formats.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center