A leaky PDF preview pane that lets one tab peek into another
CVE-2026-48294 is a Universal Cross-Site Scripting (UXSS) flaw in the Adobe Acrobat PDF Extension for Chrome, versions 26.5.2.2 and earlier. When a user opens a malicious PDF inside the extension's viewer, attacker-controlled script breaks out of the PDF's origin and executes in the context of *other* origins the browser has loaded. That means cookies, DOM contents, and authenticated session data from any same-browser tab — webmail, SaaS dashboards, internal apps — can be read and exfiltrated. No file write, no RCE, no privilege escalation on the host: it's a pure cross-origin data disclosure inside the browser sandbox.
Adobe scored this HIGH (7.4) with Scope:Changed and Confidentiality:High, which is technically defensible — UXSS is supposed to be one of the worst things a browser-resident bug can do. But the *practitioner* reality is different: the Acrobat Chrome extension is opt-in, increasingly displaced by Chrome's built-in PDF viewer, and requires the victim to actually open the malicious PDF *through the extension* (UI:R). On a managed 10k-host fleet where the extension was never pushed, this is paperwork. Where it WAS pushed (legal, AEC, compliance teams), it's a real but bounded data-disclosure problem — not a fleet-compromise problem.
3 steps from start to impact.
Deliver a weaponized PDF to the victim
- Victim has the Adobe Acrobat Chrome extension installed and enabled
- Extension is set as the default PDF handler (overriding Chrome's built-in viewer)
- Victim opens the attacker's PDF
- Chrome ships its own PDF viewer by default — the Adobe extension must be explicitly installed and chosen as handler
- Secure email gateways (Proofpoint, Mimecast, Microsoft Defender for O365) sandbox-detonate PDFs with suspicious JS/XFA
- Modern Chrome enterprise policies often pin the built-in viewer via
AlwaysOpenPdfExternally=falseand disable extension overrides
Trigger the UXSS in the extension's renderer
- Extension version ≤ 26.5.2.2
- Extension's content-script / renderer privilege model is reachable from the parsed PDF
- Chrome's site isolation (Spectre-era mitigation) limits *some* cross-process reads, though UXSS by definition routes around same-origin policy
- Extensions with
host_permissionsscoped to specific origins limit the reachable target set
Read or exfiltrate cross-origin data
HttpOnly, CSRF tokens, profile data, mailbox contents, etc. Exfiltration is HTTPS POST to an attacker endpoint — looks like normal browser traffic.- Victim has authenticated sessions to high-value web apps in the same browser profile
- Target apps do not enforce strict cookie scoping or rely on browser-resident tokens
HttpOnlycookies cannot be read via script — token-bound SaaS (Microsoft 365, Google Workspace) blunts session theft- Short-lived OAuth bearer tokens reduce replay window
- SaaS conditional-access tied to device posture invalidates stolen session on first replay from new IP
The supporting signals.
| In-the-wild exploitation | No confirmed exploitation as of 2026-06-30. Not on CISA KEV. No public IOC sets from Mandiant, Unit 42, or Talos. |
|---|---|
| Public PoC | No public PoC repo identified on GitHub or ExploitDB at time of assessment. UXSS class is well-understood; a competent researcher could reproduce from the advisory in days. |
| EPSS | 0.00591 (~0.6% probability of exploitation in next 30 days) — bottom decile. |
| KEV status | Not listed on CISA KEV as of 2026-06-30. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N — network reachable, no privs, user interaction required, scope changed, confidentiality-only impact. No integrity or availability hit. |
| Affected versions | Adobe Acrobat PDF Extension for Chrome ≤ 26.5.2.2 |
| Fixed version | Adobe Acrobat PDF Extension 26.5.3.0 or later (auto-updated via Chrome Web Store for most users) |
| Exposure population | Chrome Web Store reports the Acrobat extension at low-tens-of-millions installs globally — but the enterprise managed install base is much narrower, concentrated in legal/AEC/finance verticals where Acrobat is the document standard. |
| Disclosed | 2026-06-17 via Adobe security bulletin (APSB-series) |
| Reporter | Credited to an external researcher per Adobe advisory (specific name not disclosed in initial bulletin) |
noisgate verdict.
Downgraded from Adobe's HIGH (7.4) to MEDIUM because the decisive friction is user interaction through an opt-in browser extension that has a shrinking installed base, combined with Confidentiality-only impact bounded by the browser sandbox. Blast radius is one user's browser session — not the host, not the network, not the fleet.
Why this verdict
- User interaction required (UI:R) through a specific extension — victim must both have the Adobe extension installed AND open the malicious PDF through it. Chrome's default viewer is unaffected, eliminating the majority of the Chrome installed base.
- Confidentiality-only, bounded to the browser — no RCE on the host, no privilege escalation, no integrity/availability impact. Blast radius is session data the victim's browser already holds.
- Role multiplier: The affected component is a browser extension on user workstations, not an identity provider, hypervisor, CA, backup admin host, or kernel-mode agent. Even in the worst plausible enterprise role (a paralegal opening case PDFs), the chain ends at *that user's* webmail/SaaS session — not domain takeover, not fleet compromise, not supply chain. The HIGH/CRITICAL role floor does not apply.
- EPSS 0.006 and no KEV / no public PoC — empirical exploitation pressure is in the bottom decile.
- Auto-update path exists — Chrome Web Store pushes the extension update silently to most users, meaning the population at risk decays naturally within the assessment window.
Why not higher?
HIGH (Adobe's call) overweights the Scope:Changed flag without accounting for the opt-in, niche-deployment nature of the extension or the absence of integrity/availability impact. There is no documented path from this bug to host code execution, lateral movement, or persistence — all of which would be required to justify a HIGH on a 10k-host risk model.
Why not lower?
Cannot drop to LOW because UXSS is a genuine cross-origin breakage that can yield session theft against high-value SaaS, and the bug is in a real product with a real (if narrowing) install base. Treating it as IGNORE would be wrong — legal/AEC/finance teams running the extension on workstations with authenticated O365/Workspace sessions are credibly exposed.
What to do — in priority order.
- Inventory Chrome extensions across the fleet for the Acrobat plugin — Use Chrome Enterprise / Workspace admin console or your endpoint manager (Intune, Jamf, Workspace ONE) to enumerate which hosts have the Adobe Acrobat Chrome extension. You can't prioritize a population you haven't measured. MEDIUM verdict has no mitigation SLA — complete inventory as backlog hygiene but ideally within the first 30 days so you know the exposed set.
- Force-update or force-pin the extension to ≥ 26.5.3.0 — Push the fixed version via Chrome Enterprise policy
ExtensionInstallForcelistwith version pin, or block the vulnerable version viaExtensionSettings → minimum_version_required. Auto-update normally handles this within 24–48 hours of release, but enterprise-managed Chrome may have update-pinning that delays the rollout. Confirm by the 365-day remediation window. - Disable the Acrobat extension where Chrome's built-in viewer suffices — For business units that don't actively use Acrobat-specific features (form filling, e-sign workflow), uninstall the extension entirely via
ExtensionInstallBlocklist. This is the highest-leverage permanent control — removes the attack surface rather than chasing patches. - Tune mail gateway for hostile PDF detonation — Ensure Proofpoint/Mimecast/Defender for O365 sandbox is detonating inbound PDFs with active content. This is general PDF-borne-attack hygiene but is the upstream choke point that catches the delivery step before the user clicks.
- EDR signatures for this CVE — the abuse happens entirely inside the Chrome renderer process; behavioral EDR sees benign chrome.exe activity.
- Web Application Firewalls — the vuln triggers client-side in the user's browser; no server-side request signature to match.
- MFA on downstream SaaS — the attack steals an already-authenticated session, so MFA at login is bypassed. Only token binding / device-bound credentials / risk-based step-up help.
- Disabling JavaScript in PDFs via Acrobat preferences — this control applies to the desktop Reader, not the Chrome extension's parser path.
Crowdsourced verification payload.
Run on a Windows endpoint as the logged-in user (extension state is per-user profile). Invoke as .\Check-AcrobatExt.ps1 from PowerShell. No admin required. Outputs VULNERABLE, PATCHED, or UNKNOWN.
#!powershell
# Check-AcrobatExt.ps1 — detect Adobe Acrobat Chrome extension version for CVE-2026-48294
# Extension ID: efaidnbmnnnibpcajpcglclefindmkaj (Adobe Acrobat: PDF edit, convert, sign tools)
$ExtId = 'efaidnbmnnnibpcajpcglclefindmkaj'
$FixedV = [version]'26.5.3.0'
$BadCeil = [version]'26.5.2.2'
$profileRoot = Join-Path $env:LOCALAPPDATA 'Google\Chrome\User Data'
if (-not (Test-Path $profileRoot)) {
Write-Output 'UNKNOWN: Chrome user data directory not found'
exit 2
}
$found = $false
$worst = $null
Get-ChildItem -Path $profileRoot -Directory | Where-Object {
$_.Name -eq 'Default' -or $_.Name -like 'Profile*'
} | ForEach-Object {
$extDir = Join-Path $_.FullName "Extensions\$ExtId"
if (Test-Path $extDir) {
Get-ChildItem -Path $extDir -Directory | ForEach-Object {
try {
$v = [version]$_.Name
$found = $true
if (-not $worst -or $v -lt $worst) { $worst = $v }
} catch { }
}
}
}
if (-not $found) {
Write-Output 'PATCHED: Acrobat Chrome extension not installed'
exit 0
}
if ($worst -le $BadCeil) {
Write-Output "VULNERABLE: Acrobat extension $worst <= $BadCeil (CVE-2026-48294)"
exit 1
} elseif ($worst -ge $FixedV) {
Write-Output "PATCHED: Acrobat extension $worst >= $FixedV"
exit 0
} else {
Write-Output "UNKNOWN: Acrobat extension $worst — manual review"
exit 2
}
If you remember one thing.
ExtensionInstallForcelist policy or block the extension entirely where it isn't needed, completing the noisgate remediation SLA of ≤ 365 days. If your monitoring picks up active exploitation or a public PoC drops, re-trigger this assessment immediately — UXSS bugs occasionally get weaponized in browser-credential-theft campaigns and the verdict moves up fast if EPSS climbs.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.