← Back to Feed CACHED · 2026-06-30 01:52:35 · CACHE_KEY CVE-2026-48294
CVE-2026-48294 · CWE-79 · Disclosed 2026-06-17

Adobe Acrobat PDF Extension

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"UXSS in a browser extension with shrinking installed base — real but not the fire drill Adobe's 7.4 implies."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a weaponized PDF to the victim

Attacker crafts a PDF containing the UXSS payload — typically malformed annotation, embedded JS, or XFA content that triggers the parser bug in the extension's renderer. Delivery is via phishing email attachment, drive-by download, or a link to attacker-controlled web hosting. The PDF needs to be opened through the Adobe extension specifically, not Chrome's native viewer.
Conditions required:
  • 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
Where this breaks in practice:
  • 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=false and disable extension overrides
Detection/coverage: Most EDRs do NOT have a signature for in-extension UXSS payloads; YARA on PDF structures (suspicious /JS, /AA, /XFA) is the practical detection. Tenable/Qualys/Rapid7 detect the extension version itself via browser-extension inventory plugins.
STEP 02

Trigger the UXSS in the extension's renderer

When the extension parses the PDF, the payload escapes the PDF's same-origin sandbox and obtains a script execution context that the browser treats as belonging to other origins (the *Universal* part of UXSS). The attacker now has DOM-level scripting capability against arbitrary sites the victim is logged into.
Conditions required:
  • Extension version ≤ 26.5.2.2
  • Extension's content-script / renderer privilege model is reachable from the parsed PDF
Where this breaks in practice:
  • Chrome's site isolation (Spectre-era mitigation) limits *some* cross-process reads, though UXSS by definition routes around same-origin policy
  • Extensions with host_permissions scoped to specific origins limit the reachable target set
Detection/coverage: None reliable at the endpoint — the abuse happens entirely inside the browser process tree. Browser telemetry (Chrome Enterprise reporting) can flag unusual extension behavior but not this specific class.
STEP 03

Read or exfiltrate cross-origin data

With UXSS primitive in hand, the attacker enumerates open tabs / cached origins, fetches authenticated responses (HTML, JSON), and exfiltrates session cookies that are not HttpOnly, CSRF tokens, profile data, mailbox contents, etc. Exfiltration is HTTPS POST to an attacker endpoint — looks like normal browser traffic.
Conditions required:
  • 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
Where this breaks in practice:
  • HttpOnly cookies 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
Detection/coverage: SaaS-side anomaly detection (Microsoft Entra Risky Sign-in, Google Workspace context-aware access) catches session replay from new geos. Browser-egress DLP (Netskope, Zscaler) can catch large outbound POSTs.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNo confirmed exploitation as of 2026-06-30. Not on CISA KEV. No public IOC sets from Mandiant, Unit 42, or Talos.
Public PoCNo 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.
EPSS0.00591 (~0.6% probability of exploitation in next 30 days) — bottom decile.
KEV statusNot listed on CISA KEV as of 2026-06-30.
CVSS vectorCVSS: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 versionsAdobe Acrobat PDF Extension for Chrome ≤ 26.5.2.2
Fixed versionAdobe Acrobat PDF Extension 26.5.3.0 or later (auto-updated via Chrome Web Store for most users)
Exposure populationChrome 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.
Disclosed2026-06-17 via Adobe security bulletin (APSB-series)
ReporterCredited to an external researcher per Adobe advisory (specific name not disclosed in initial bulletin)
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

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.

HIGH vulnerability mechanics and CVSS interpretation
MEDIUM enterprise installed-base estimate of the Acrobat Chrome extension
HIGH absence of in-the-wild exploitation as of 2026-06-30

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. Force-update or force-pin the extension to ≥ 26.5.3.0 — Push the fixed version via Chrome Enterprise policy ExtensionInstallForcelist with version pin, or block the vulnerable version via ExtensionSettings → 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#!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
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull a Chrome extension inventory across the fleet and identify which business units actually run the Adobe Acrobat extension — most won't. Per the noisgate mitigation SLA for MEDIUM there is *no mitigation SLA — go straight to the 365-day remediation window* — push the fixed version (≥ 26.5.3.0) via Chrome Enterprise 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

  1. Adobe Security Bulletins index
  2. Adobe APSB26-43 bulletin
  3. Adobe APSB26-44 bulletin
  4. TechTarget — Adobe Acrobat Chrome extension risks
  5. Malwarebytes — Adobe Reader zero-day coverage (2026)
  6. CVE Details — Adobe Acrobat Reader product page
  7. FIRST EPSS data
  8. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.